document-haness/docs/TechLog/tech-log-studio/one-thing-many-names/case/case-nine-names-for-five-kinds.md

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	final/document.md#§13.1 final/document.md#§13.5

한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다

홈 한 화면에 문서 종류 이름이 아홉 개 떠 있었다. 최근 기록 목록은 계약의 enum 이름을, 바로 아래 「종류별로 읽기」는 사람이 붙인 이름을 쓰고 있었다. 독자는 둘이 같은 것이라는 단서를 어디서도 받지 못했다. 표가 화면마다 복사되어 여섯 벌이었기 때문이다.

관계

• 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다 이 표를 한 곳으로 모은 뒤에 이름 자체를 다시 정한 기록이다.
• 개념을 하나 더하자 열세 곳이 그것을 조용히 삼켰다 같은 종류 목록이 코드 쪽에서 갈라진 사건이다.
• 톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다 같은 시기에 문구를 다룬 기준이다.

문제

홈 화면 하나에 종류 이름이 아홉 개 있었다.

text 최근 기록 목록: CASE · CONCEPT · OPEN QUESTION · REFERENCE 바로 아래 「종류별로 읽기」: 검증 기록 · 동작 원리 · 적용 기준 · 열린 질문

두 목록이 같은 다섯 종류를 가리키는데 이름이 겹치지 않는다. 독자는 그 둘이 같은 것이라는 단서를 받지 못한다.

결론

표가 화면마다 복사되어 여섯 벌이었고 그래서 갈라졌다: 같은 QUESTION 이 공개 화면에서 "Open Question", 작업본 목록과 게시 기록에서 "Question", 편집기 상태 줄에서 "QUESTION" 이었다. 쓰는 사람은 같은 문서를 화면마다 다른 이름으로 만난다.

종류에서 이름으로 가는 표 하나로 모았다.

편집기 칸 이름도 공개 화면과 맞췄다.

검증 환경

tech-log-frontend : dc2fda7 · ca1fc92 · 82e992d 확인 방식 : 한 화면에 동시에 뜨는 종류 이름을 세고, 표가 몇 벌인지 확인

재현 조건

1. 홈 화면을 열고 최근 기록 목록과 「종류별로 읽기」를 함께 본다
2. 두 목록에서 같은 종류를 가리키는 이름을 대조한다
3. 작업본 목록·게시 기록·편집기 상태 줄에서 같은 종류의 이름을 확인한다

본문

한 화면에 아홉 개

최근 기록 목록:      CASE · CONCEPT · OPEN QUESTION · REFERENCE
바로 아래 「종류별로 읽기」: 검증 기록 · 동작 원리 · 적용 기준 · 열린 질문

두 목록이 세로로 붙어 있다. 위는 계약의 enum 이름을, 아래는 사람이 붙인 이름을 쓴다. 독자는 둘이 같은 것이라는 단서를 어디서도 받지 못했다.

이름을 바꾸기 전에는 양쪽이 다 enum 이름이었으므로 적어도 같아 보였다. 이 화면은 이름을 바꾸면서 나빠졌다.

표가 여섯 벌이었다

종류 이름을 한 곳에 모은 커밋이 원인을 이렇게 적어 두었다.

표가 화면마다 복사되어 여섯 벌이었고 그래서 갈라졌다: 같은 QUESTION 이 공개 화면에서 "Open Question", 작업본 목록과 게시 기록에서 "Question", 편집기 상태 줄에서 "QUESTION" 이었다. 쓰는 사람은 같은 문서를 화면마다 다른 이름으로 만난다.

여섯 벌이 동시에 틀린 것이 아니다. 이름을 바꿀 때 그중 일부만 고쳤고, 어느 것을 고쳤는지가 화면마다 달랐다.

표 하나로 모았다

종류에서 표시 이름으로 가는 표를 하나 만들고 여섯 곳이 그것을 쓰게 했다. 그 표의 javadoc 이 왜 한 곳에 있는지를 적는다.

한 곳에 두면 다음에 종류가 늘어날 때도 한 번만 고친다. 종류를 더하면 이 표가 비어 있는 것을 타입이 잡는다 — Record<RecordKind, string> 이므로 빠진 종류가 있으면 컴파일되지 않는다.

같은 파일에 표가 하나 더 있다. 다섯 종류를 셋으로 접어 지식의 상태로 만드는 표다.

독자가 실제로 구분해야 하는 것은 지식의 상태다. 다섯 종류를 셋으로 접는다 — 확인한 것, 정리한 것, 아직 모르는 것. 목록에서 미해결만 눈에 띄게 하는 것이 이 표의 쓰임이다. 미해결이 이 기록의 가장 정직한 신호인데 다섯 종류가 같은 회색 11px 로 나오면 그것이 가장 안 보인다.

편집기 칸 이름도 맞췄다

같은 문제가 칸 이름에도 있었다. 편집기에서 「목적」이라 부른 칸이 공개 화면에서는 다른 이름으로 나왔다.

목적      → 이 기준을 쓰는 이유       규칙   → 판단 기준
적용 조건  → 적용할 때               예외   → 예외와 주의
사실      → 확인한 사실              미지수 → 남은 미지수
선택지    → 검토한 선택지

쓰는 사람이 지금 채우는 칸이 공개 화면 어디로 가는지 외우지 않아도 되게 했다.

확인하지 못한 것

이름을 바꾸기 전보다 나빠진 화면이 홈이라는 것은 화면으로 확인했다. 다른 화면에서 두 이름이 같이 뜨는 곳을 전수로 세지는 않았다.