DongHyeonkaandClaude Opus 5
e9f6a93327
§1.4 로 세운 도메인·비즈니스 규칙을 그것이 실제로 설명하는 기록에 넣었다. 프로젝트가 문서 게시 파이프라인을 안 타는 이유 → 화면 다섯이 비어 있던 Case 홈 focus 설정이 FK 없이 사는 설계 → 「열린 질문이 없습니다」 Case 결정이 자기 화면을 안 갖는 이유 → 목록이 문서 전체를 실어야 했던 Case 게시가 단계마다 다른 코드로 거절하는 설계 → 화면이 추측 셋을 출력한 Case (반대 사례) 종류마다 애그리거트와 테이블이 다르다 → 매퍼가 종류를 판정해야 하는 Case 축을 지우면 연결만 끊고 주제를 지우면 거절하는 이유 → 축 Concept 개념이 문서 테이블에 얹힌다 → 열세 곳 Case 화면 상태와 도메인 상태가 원래 갈려 있었다 → 이름을 두 번 바꾼 Case Case 본문 중앙값 675 → 1,342 자. 검사 넷 전부 통과한다. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
123 lines
5.6 KiB
Markdown
123 lines
5.6 KiB
Markdown
---
|
|
kind: CASE
|
|
slug: renaming-the-kinds-twice
|
|
title: 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다
|
|
topic: one-thing-many-names
|
|
topicName: 같은 것이 화면마다 다른 이름
|
|
project: TechLog
|
|
status: 게시 전
|
|
lastVerifiedOn: 2026-09-04
|
|
sourceRevision: tech-log@2026-09-02
|
|
source:
|
|
- final/document.md#§13.2
|
|
---
|
|
|
|
# 종류 이름을 두 번 바꿨다 — 화면의 이름과 계약의 kind 를 갈랐다
|
|
|
|
이 저장소의 종류 이름은 글을 담아 둔 방식의 이름이었다. 독자는 그 말을 배우고 나서야 목록을 읽을 수 있었고, 뜻풀이는 홈 바닥 2,000px 아래에 있었다. 이름이 하는 일을 말하게 바꿨다가, 그 안이 기술 기록의 톤에 비해 가벼워 문어체로 다시 세웠다.
|
|
|
|
## 관계
|
|
|
|
- **한 화면에 종류 이름이 아홉 개 떠 있었다 — 표가 여섯 벌이었다**
|
|
이 이름을 한 곳으로 모은 뒤에 이 변경이 왔다.
|
|
- **톤을 지적받으면 고쳐 쓰지 말고 어떤 말을 쓸지 묻는다**
|
|
두 번째 안이 왜 필요했는지가 그 기준에 있다.
|
|
- **slug 생성이 한글을 버려 주제 만들기가 간헐적으로 실패했다**
|
|
이름을 주소로 옮기는 다른 사건이다.
|
|
|
|
## 문제
|
|
|
|
종류 이름이 Case, Reference, Open Question 이었다. 이것은 글을 담아 둔 방식의 이름이다.
|
|
|
|
독자는 그 말을 배우고 나서야 목록을 읽을 수 있었고, 정작 뜻풀이는 홈 바닥 2,000px 아래에 있었다.
|
|
|
|
## 결론
|
|
|
|
두 번 바꿨다.
|
|
|
|
1차 : 이름이 하는 일을 말하게 했다 — 직접 해보니 · 다음에 쓸 기준 · 아직 모르는 것 · 어떻게 동작하나 · 이렇게 하기로
|
|
2차 : 하는 일을 말하는 방향은 두고 문어체로 다시 세웠다 — 검증 기록 · 적용 기준 · 열린 질문 · 동작 원리 · 설계 결정
|
|
|
|
1차 안이 기술 기록의 톤에 비해 가벼웠다.
|
|
|
|
계약의 kind 는 그대로 뒀다. 바꾸는 것은 화면에 보이는 이름뿐이다.
|
|
|
|
## 검증 환경
|
|
|
|
tech-log-frontend : a6413d0 → af5a6bb
|
|
계약 : RecordKind 다섯 값은 변경 없음
|
|
확인 방식 : 화면의 표시 이름과 계약의 kind 를 대조
|
|
|
|
## 재현 조건
|
|
|
|
1. 공개 화면에서 종류 배지와 「종류별로 읽기」의 이름을 본다
|
|
2. 편집기의 새 문서 화면에서 같은 종류의 이름을 본다
|
|
3. 계약의 kind 값과 대조한다
|
|
|
|
## 본문
|
|
|
|
<!-- body:start -->
|
|
|
|
## 담아 둔 방식의 이름
|
|
|
|
Case, Reference, Open Question 은 그 글을 어떤 형식에 담았는지를 말한다. 그 글이 독자에게 무엇을 주는지는 말하지 않는다.
|
|
|
|
독자는 그 말을 먼저 배워야 목록을 읽을 수 있었고, 뜻풀이는 홈 바닥 2,000px 아래에 있었다. 목록을 훑는 사람이 거기까지 내려가지 않는다.
|
|
|
|
## 1차 — 하는 일을 말하게 했다
|
|
|
|
```text
|
|
Case → 직접 해보니 Reference → 다음에 쓸 기준
|
|
Question → 아직 모르는 것 Concept → 어떻게 동작하나
|
|
Decision → 이렇게 하기로
|
|
```
|
|
|
|
이름만 읽어도 그 글이 무엇을 주는지 알 수 있다. 뜻풀이를 찾아 내려갈 이유가 없어진다.
|
|
|
|
## 2차 — 문어체로 다시 세웠다
|
|
|
|
**그런데 이게 기술 기록의 톤에 비해 가벼웠다.** 역할은 그대로 말하되 문어체로 바꿨다.
|
|
|
|
```text
|
|
CASE → 검증 기록 CONCEPT → 동작 원리
|
|
REFERENCE → 적용 기준 DECISION → 설계 결정
|
|
QUESTION → 열린 질문
|
|
```
|
|
|
|
두 안이 말하는 것은 같다. 「직접 해보니」와 「검증 기록」은 둘 다 그 글이 재현한 결과라고 말한다. 갈린 것은 이 사이트의 다른 글들이 쓰는 어조와 맞느냐였다.
|
|
|
|
## 이름 표가 하나였기 때문에 두 번 바꿀 수 있었다
|
|
|
|
이름을 바꾸는 작업이 한 파일을 고치는 일이 됐다. 표가 화면마다 복사돼 있던 때였다면 두 번 바꾸는 동안 여섯 벌이 두 번씩 갈렸을 것이다.
|
|
|
|
같은 파일에 표가 하나 더 있다. 다섯 종류를 셋으로 접어 지식의 상태로 만드는 표다 — 확인한 것, 정리한 것, 아직 모르는 것.
|
|
|
|
> 미해결이 이 기록의 가장 정직한 신호인데 다섯 종류가 같은 회색 11px 로 나오면 그것이 가장 안 보인다.
|
|
|
|
이름을 바꿔도 이 표는 그대로였다. 표시 이름과 지식 상태가 다른 축이라 따로 두었기 때문이다.
|
|
|
|
## 화면 이름과 도메인 상태는 원래 다르다
|
|
|
|
이 저장소는 화면에 보이는 값과 도메인이 들고 있는 값을 이미 갈라 두고 있었다.
|
|
|
|
| 계약이 화면에 주는 값 | 도메인이 들고 있는 값 |
|
|
|---|---|
|
|
| 질문 상태 : OPEN · RESOLVED | OPEN · INVESTIGATING · PAUSED · RESOLVED |
|
|
| 결정 상태 : PROPOSED · ADOPTED | PROPOSED · ACCEPTED |
|
|
|
|
질문 상태 셋이 화면에서 하나로 접히고, 그 역방향 변환은 도메인 상태를 덮어쓰지 않는다. 결정의 `ACCEPTED` 는 화면에서 `ADOPTED` 로 보인다.
|
|
|
|
종류 이름을 두 번 바꾸면서 계약을 건드리지 않은 것은 새로 정한 규칙이 아니라 이미 있던 규칙을 따랐다.
|
|
|
|
## 계약의 kind 는 그대로 뒀다
|
|
|
|
바꾼 것은 화면에 보이는 이름이다. 계약의 종류 값은 다섯 그대로이고 주소도 그대로다.
|
|
|
|
표시 이름과 계약 값을 갈라 두었기 때문에 두 번 바꾸면서 계약을 한 번도 건드리지 않았다. 계약을 바꿨다면 반입한 두 저장소가 함께 움직여야 했고, 이미 게시된 주소도 함께 흔들렸을 것이다.
|
|
|
|
## 확인하지 못한 것
|
|
|
|
바꾼 이름이 읽기 쉬워졌는지는 재지 않았다. 1차 안이 가볍다는 판단은 사용자의 지적이고 측정이 아니다.
|
|
|
|
<!-- body:end -->
|