DongHyeonkaandClaude Opus 5
0650d91def
rewriting-technical-prose-naturally 를 서브에이전트 셋으로 나눠 56편에 적용했다. ai-tells.md 의 첫 절대로 다른 표현으로 바꾸는 대신 문장을 통째로 지웠다. 설명한 것의 중요성을 다시 평가하는 꼬리 19 이미 설명한 것을 추상어로 되풀이 19 독자에게 읽는 법을 지시하거나 오해를 가정 9 자료가 뒷받침하지 않는 덧붙인 이득 4 문서군 전체의 문형 편중도 풀었다 — 함께 27→7(한 묶음), 그대로 22→12(두 묶음), 하게 된다 1→0. 한 편에서 세 번 반복되던 「같은 병이 ~에서도 났다」와 두 기록에 같은 문장으로 있던 세 쌍을 갈랐다. 계약 제목 「여덟 자리」가 본문의 「여덟 곳」과 어긋나 있었다. 제목이 spatial-metaphor 규칙에도 걸리므로 계약과 기록을 함께 「여덟 곳」으로 맞췄다. 검사 넷 전부 통과한다 — check_prose 56편 error 0 · check_body PASS · check_evidence --repo 문제 없음 · verify-tech-log-tree error 0 warn 0. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.6 KiB
kind, slug, title, topic, topicName, project, status, lastVerifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | lastVerifiedOn | sourceRevision | source | |
|---|---|---|---|---|---|---|---|---|---|---|
| CASE | renaming-the-kinds-twice | 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다 | one-thing-many-names | 같은 것이 화면마다 다른 이름 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다
이 저장소의 종류 이름은 글을 담아 둔 방식의 이름이었다. 독자는 그 말을 배우고 나서야 목록을 읽을 수 있었고, 뜻풀이는 홈 바닥 2,000px 아래에 있었다. 이름이 하는 일을 말하게 바꿨다가, 그 안이 기술 기록의 톤에 비해 가벼워 문어체로 다시 세웠다.
관계
- 한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다 이 이름을 한 곳으로 모은 뒤에 이 변경이 왔다.
- 톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다 두 번째 안이 왜 필요했는지가 그 기준에 있다.
- slug 생성이 한글을 버려 주제 만들기가 간헐적으로 실패했다 이름을 주소로 옮기는 다른 사건이다.
문제
종류 이름이 Case, Reference, Open Question 이었다. 이것은 글을 담아 둔 방식의 이름이다.
독자는 그 말을 배우고 나서야 목록을 읽을 수 있었고, 정작 뜻풀이는 홈 바닥 2,000px 아래에 있었다.
결론
두 번 바꿨다.
1차 : 이름이 하는 일을 말하게 했다 — 직접 해보니 · 다음에 쓸 기준 · 아직 모르는 것 · 어떻게 동작하나 · 이렇게 하기로 2차 : 하는 일을 말하는 방향은 두고 문어체로 다시 세웠다 — 검증 기록 · 적용 기준 · 열린 질문 · 동작 원리 · 설계 결정
1차 안이 기술 기록의 톤에 비해 가벼웠다.
계약의 kind 는 그대로 뒀다. 바꾸는 것은 화면에 보이는 이름뿐이다.
검증 환경
tech-log-frontend : a6413d0 → af5a6bb 계약 : RecordKind 다섯 값은 변경 없음 확인 방식 : 화면의 표시 이름과 계약의 kind 를 대조
재현 조건
- 공개 화면에서 종류 배지와 「종류별로 읽기」의 이름을 본다
- 편집기의 새 문서 화면에서 같은 종류의 이름을 본다
- 계약의 kind 값과 대조한다
본문
담아 둔 방식의 이름
Case, Reference, Open Question 은 그 글을 어떤 형식에 담았는지를 말한다. 그 글이 독자에게 무엇을 주는지는 말하지 않는다.
독자는 그 말을 먼저 배워야 목록을 읽을 수 있었다. 뜻풀이는 홈 바닥 2,000px 아래에 있었다.
1차 — 하는 일을 말하게 했다
Case → 직접 해보니 Reference → 다음에 쓸 기준
Question → 아직 모르는 것 Concept → 어떻게 동작하나
Decision → 이렇게 하기로
2차 — 문어체로 다시 세웠다
1차 안이 기술 기록의 톤에 비해 가벼웠다. 역할은 그대로 말하되 문어체로 바꿨다.
CASE → 검증 기록 CONCEPT → 동작 원리
REFERENCE → 적용 기준 DECISION → 설계 결정
QUESTION → 열린 질문
계약의 kind 는 그대로 뒀다
바꾼 것은 화면에 보이는 이름이다. 계약의 RecordKind 는 다섯 값 그대로이고 주소도 바뀌지 않았다.
확인하지 못한 것
바꾼 이름이 읽기 쉬워졌는지는 재지 않았다. 1차 안이 가볍다는 판단은 사용자의 지적이고 측정이 아니다.