DongHyeonkaandClaude Opus 5
fd221353a3
SSOT 를 저장소에서 확인해 더 보강하고 그것으로 다시 썼다.
§7.2 참조 검사 SQL 을 문자열로 조립하는 실제 코드 — 컴파일러가 표 이름도
컬럼 이름도 보지 않는다는 것이 그 모양에서 드러난다
§11.2 section-heading-rank 가 미디어 쿼리 값을 먼저 걷어내는 이유(테스트 주석)
§16.1 질문 삭제는 참조가 둘뿐이라 같은 문제가 덜하다는 대조
Case 열 편과 Question 셋을 다시 썼다. Question 은 사실·가정·미지수·제약을 갈라
채우고 선택지마다 무엇을 감수하는지 적었다 — 오류 코드를 나누면 계약과 반입한 두
저장소가 함께 움직인다는 것처럼.
SSOT 62,643 → 68,319 자. 검사 넷 전부 통과한다.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.5 KiB
kind, slug, title, topic, topicName, project, status, questionStatus, evidence, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | questionStatus | evidence | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| QUESTION | the-conclusion-line-does-not-follow-the-records | 축의 결론 문장과 기록 수는 기록을 붙여도 따라오지 않는다 | an-axis-inside-a-topic | 주제 안의 축 | TechLog | 게시 전 | OPEN |
|
tech-log@2026-09-02 |
|
축의 결론 문장과 기록 수는 기록을 붙여도 따라오지 않는다
홈의 비교 구역에서 줄은 문서가 아니라 축이다. 기록을 스무 개 붙여도 줄 수는 늘지 않고, 줄에 보이는 결론 문장은 축에 손으로 쓴 글이라 누가 고치기 전까지 바뀌지 않는다. 주제 화면에는 축마다 기록 수가 붙는데 홈에는 없다.
관계
- 주제를 넷으로 쪼개지 않고 주제 안에 축을 하나 뒀다 이 결정으로 감수한 비용이 이 질문이다.
- 홈의 비교 구역이 세 번 바뀌었다 이 화면을 세 번 고친 기록이다.
- 프록시 지표가 아니라 보이는 것을 측정한다 화면에서 무엇이 달라지는지 확인하는 방법이 그 기준에 있다.
사실
홈의 비교 구역에서 한 줄은 축 하나다. 기록을 스무 개 붙여도 줄 수는 그대로다.
줄에 보이는 결론 문장은 축에 손으로 쓴 글이다. 기록을 붙여도 그 문장은 누가 고치기 전까지 그대로다.
주제 화면에는 축마다 「기록 N」이 붙는다. 홈에는 그 수가 없다.
그래서 기록 1개짜리 축과 20개짜리 축이 홈에서 똑같아 보인다.
홈이 처음 보내는 요청은 목록 하나와 주제 하나로 고정돼 있다. 상세는 고른 탭만 그때 받아 캐시한다.
주제의 논지와 축의 결론은 2026-09-01 에 AI 가 써서 DB 에 직접 넣은 초안이다. 사용자 검토 대상이고 아직 검토되지 않았다.
가정
결론을 사람이 쓰게 한 것이 의도라고 보고 있다. 요약은 「무엇인가」이고 결론은 「무엇을 알게 됐나」라서 기록의 요약 첫 줄을 잘라 쓰면 안 된다고 판단했는데, 그 판단이 지금도 맞는지 다시 보지 않았다.
기록 수는 유도할 수 있다고 보고 있다. 주제 화면이 이미 그 수를 그리므로 같은 값을 홈에 붙이면 된다고 짐작하지만, 홈의 목록 호출이 그 수를 싣는지 확인하지 않았다.
미지수
홈에 기록 수를 붙이면 축에 기록을 더했을 때 화면이 달라지는가. 달라진다면 결론 문장이 낡았다는 것도 같은 화면에서 드러나는가.
결론을 사람이 갱신해야 한다는 것을 화면이 말해야 하는가. 말한다면 어디에 말해야 읽히는가 — 공개 화면에 적으면 독자가 그것을 읽고, Studio 에만 적으면 작성자만 읽는다.
DB 에 직접 넣은 초안을 누가 언제 검토하는가. 검토 전까지 그 문장을 공개 화면에 그대로 둘지.
제약
축의 요약과 결론은 기록을 합쳐 자동으로 만들지 않는다. 결론은 비교표가 읽는 칸이라 기록의 요약 첫 줄을 잘라 쓰면 안 된다.
홈이 처음 보내는 요청은 목록 하나와 주제 하나로 고정한다. 기록 수를 붙이려고 주제마다 상세를 미리 받지 않는다.
선택지
홈 비교표에 기록 수를 붙인다 목록 호출이 이미 그 수를 실을 수 있으면 요청이 늘지 않는다. 결론 문장은 그대로 사람이 쓴다. 기록이 늘면 수가 바뀌므로 결론만 낡은 상태가 화면에 드러난다.
결론 문장이 마지막으로 고쳐진 때를 함께 보인다 기록이 그 뒤에 늘었으면 낡았다는 것이 드러난다. 화면에 날짜가 하나 더 늘고, 독자에게는 필요 없는 값이 보인다.
결론을 쓰지 않은 축은 결론 줄을 비운다 쓰지 않은 것과 낡은 것을 구분한다. 지금은 초안이 들어 있어 둘이 같아 보인다.
다음 검증
- 홈의 목록 호출 응답에 축별 기록 수가 실려 있는지 확인하고, 없으면 싣는 비용을 잰다
- 축 하나에 기록을 더하고 홈에서 무엇이 달라지고 무엇이 그대로인지 화면으로 가른다
- DB 에 직접 넣은 주제 논지와 축 결론을 사용자가 검토하고, 남길 것과 지울 것을 가른다
닫는 조건 : 축에 기록을 더했을 때 자동으로 따라오는 것과 사람이 고쳐야 하는 것이 화면에서 구분되면 닫는다