DongHyeonkaandClaude Opus 5
6feee5ba57
writing-as-the-person-who-did-it 을 서브에이전트 셋으로 나눠 56편에 적용했다. 56편 중 20편만 고쳤다 — 나머지 36편은 SSOT 를 절 단위로 대조했을 때 옮길 흔적이 이미 옮겨져 있었거나 없었다. 없는 목소리를 채우지 않는다. 옮긴 것은 전부 SSOT 의 어느 절에서 왔는지 댈 수 있다. §3.4 「눈으로 찾을 일이 아니었다」— 세 계약을 파싱해 뽑은 이유 §4.3 구현하지 않기로 한 것과 빠뜨린 것은 다르다 §8.5 표의 마지막 줄을 더할 때 이 목록을 또 빠뜨렸다 §9.4 「왜 주제 링크가 탐색으로 가지?」— 우회를 남겨 두면 계속 나온 질문 §11.3 「세 버튼」을 실제 이름으로 되돌리고 두 언어가 섞인 것을 그 자리에 §12.2 막지 않은 대신 메모리에 남긴 것 §13.1 여섯 벌 인용이 어느 커밋이 짚은 말인지 §13.3 고쳐 쓴 첫 안이 거절당한 것과 사용자가 고른 말 두 쌍 §14.3 「문서가 그대로 나온다」는 구조 차이가 아니라 내용 양의 차이라는 정정 §16.1 삭제가 막힌 실제 기록 이름과 그것을 막은 프로젝트 링크 §16.9 주제 논지와 축 결론이 AI 가 써서 DB 에 직접 넣은 미검토 초안이라는 것 §17.5 바운딩 박스로 잘못 지목한 대상이 「판단 기준」이었다는 것 검증 환경의 커밋 해시 하나가 틀려 있었다(ca1cfa2 → ca1fc92). SSOT §13.1 과 부록 A 가 적은 값이고 저장소에 그 커밋이 있다. 검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS · check_evidence --repo 문제 없음 · verify-tech-log-tree 프로젝트 5 error 0 warn 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
4.5 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | ||
|---|---|---|---|---|---|---|---|---|---|---|---|
| CASE | nine-names-for-five-kinds | 한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다 | one-thing-many-names | 같은 것이 화면마다 다른 이름 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다
홈 한 화면에 문서 종류 이름이 아홉 개 떠 있었다. 최근 기록 목록은 계약의 enum 이름을, 바로 아래 「종류별로 읽기」는 사람이 붙인 이름을 쓰고 있었다. 독자는 둘이 같은 것이라는 단서를 어디서도 받지 못했다. 표가 화면마다 복사되어 여섯 벌이었기 때문이다.
관계
- 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다 이 표를 한 곳으로 모은 뒤에 이름 자체를 다시 정한 기록이다.
- 개념을 하나 더하자 열세 곳이 그것을 조용히 삼켰다 같은 종류 목록이 코드 쪽에서 갈라진 사건이다.
- 톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다 같은 시기에 문구를 다룬 기준이다.
문제
홈 화면 하나에 종류 이름이 아홉 개 있었다.
최근 기록 목록: CASE · CONCEPT · OPEN QUESTION · REFERENCE
바로 아래 「종류별로 읽기」: 검증 기록 · 동작 원리 · 적용 기준 · 열린 질문
두 목록이 같은 다섯 종류를 가리키는데 이름이 겹치지 않는다. 독자는 그 둘이 같은 것이라는 단서를 받지 못한다.
결론
표가 화면마다 복사되어 여섯 벌이었고 그래서 갈라졌다: 같은 QUESTION 이 공개 화면에서 "Open Question", 작업본 목록과 게시 기록에서 "Question", 편집기 상태 줄에서 "QUESTION" 이었다. 쓰는 사람은 같은 문서를 화면마다 다른 이름으로 만난다.
종류에서 이름으로 가는 표 하나로 모았다.
편집기 칸 이름도 공개 화면과 맞췄다.
검증 환경
tech-log-frontend : dc2fda7 · ca1fc92 · 82e992d 확인 방식 : 한 화면에 동시에 뜨는 종류 이름을 세고, 표가 몇 벌인지 확인
재현 조건
- 홈 화면을 열고 최근 기록 목록과 「종류별로 읽기」를 함께 본다
- 두 목록에서 같은 종류를 가리키는 이름을 대조한다
- 작업본 목록·게시 기록·편집기 상태 줄에서 같은 종류의 이름을 확인한다
본문
한 화면에 아홉 개
최근 기록 목록: CASE · CONCEPT · OPEN QUESTION · REFERENCE
바로 아래 「종류별로 읽기」: 검증 기록 · 동작 원리 · 적용 기준 · 열린 질문
두 목록이 세로로 붙어 있다. 위는 계약의 enum 이름을, 아래는 사람이 붙인 이름을 쓴다.
이 화면은 이름을 바꾸기 전보다 나빠졌다. 바꾸기 전에는 양쪽이 다 enum 이름이라 적어도 같아 보였다.
표가 여섯 벌이었다
종류 이름을 한 곳에 모은 커밋이 원인을 이렇게 적어 두었다.
표가 화면마다 복사되어 여섯 벌이었고 그래서 갈라졌다: 같은 QUESTION 이 공개 화면에서 "Open Question", 작업본 목록과 게시 기록에서 "Question", 편집기 상태 줄에서 "QUESTION" 이었다. 쓰는 사람은 같은 문서를 화면마다 다른 이름으로 만난다.
표 하나로 모았다
종류에서 표시 이름으로 가는 표를 하나 만들고 여섯 곳이 그것을 쓰게 했다. 종류가 늘면 그 표에서 빠진 값을 컴파일러가 잡는다.
편집기 칸 이름도 맞췄다
같은 문제가 칸 이름에도 있었다. 편집기에서 「목적」이라 부른 칸이 공개 화면에서는 다른 이름으로 나왔다.
목적 → 이 기준을 쓰는 이유 규칙 → 판단 기준
적용 조건 → 적용할 때 예외 → 예외와 주의
사실 → 확인한 사실 미지수 → 남은 미지수
선택지 → 검토한 선택지
쓰는 사람이 지금 채우는 칸이 공개 화면 어디로 가는지 외우지 않아도 되게 했다.
확인하지 못한 것
이름을 바꾸기 전보다 나빠진 화면이 홈 하나였다는 것은 화면으로 확인했다. 다른 화면에서 두 이름이 같이 뜨는 곳을 전수로 세지는 않았다.