DongHyeonkaandClaude Opus 5
193da20d09
게시된 Reference 15편이 전부 규칙을 `### N. 제목` 으로 쓰고 적용 조건·예외·예시를 항목으로 쓴다. 내 15편은 규칙을 `**굵게**` 로, 나머지 셋을 문단으로 쓰고 있었다 — Studio 의 rules[]·applyWhen[]·exceptions[]·examples[] 는 배열이라 문단으로 두면 항목이 하나로 접힌다. 규칙 68개를 `### N. 제목` 으로 바꿨다 (편당 3~7개, 게시된 것은 4~10개) 적용 조건·예외·예시를 항목으로 갈랐다. 한 항목뿐이던 아홉 편은 조건을 나눠 적었다 주제 6 은 본문을 다시 썼다 — location = 이 정확히 일치하는 경로만 잡아 27개가 얼어붙은 구조, 여덟 곳이 우는 시점을 셋으로 가른 표, digest 를 다시 계산할 때 옛 값을 먼저 재현하는 이유. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.9 KiB
kind, slug, title, topic, topicName, project, status, verifiedOn, sourceRevision, source
| kind | slug | title | topic | topicName | project | status | verifiedOn | sourceRevision | source | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| REFERENCE | verify-at-the-end-of-the-value-journey | 한 경계를 고쳤으면 값의 여정 끝에서 확인한다 | values-lost-between-boundaries | 값이 경계에서 사라진다 | TechLog | 게시 전 | 2026-09-04 | tech-log@2026-09-02 |
|
한 경계를 고쳤으면 값의 여정 끝에서 확인한다
값이 여러 경계를 갈아타는 구조에서 한 경계를 고치고 「고쳤다」고 판단해 세 번 틀렸다. 타입 검사도 단위 테스트도 「코드를 읽어 보니 맞다」도 전부 중간 지점이다. 배포본에서 그 값이 실제로 그려지는 곳까지 가서 확인한다.
관계
- 관계의 요약이 경계 세 곳을 지나며 사라졌다 한 경계를 고치고 판단해 두 번 틀린 사건이다.
- 공개 화면 한 줄이 그려지기까지 값이 지나는 경계 열한 개 왜 중간 확인이 부족한지가 그 개념에 있다.
- TypeScript 가 검사를 놓아 주는 네 곳 타입 통과가 반영의 증거가 아닌 이유가 그 개념에 있다.
목적
「고쳤다」는 판단이 틀리는 것을 막는다.
값이 열한 경계를 지나는 구조에서 한 경계만 보고 판단하면, 다음 경계가 같은 값을 다시 버려도 알 수 없다. 이 저장소에서 그 판단이 세 번 틀렸다.
규칙
1. 고친 값이 실제로 그려지는 곳까지 가서 본다
배포본에서 그 화면을 열거나 실제 요청을 보내 응답을 읽는다. 관계 요약은 세 경계에서 연달아 버려졌고, 매번 화면을 보고 나서야 다음 경계가 버리는 것을 알았다.
2. 타입 검사 통과를 반영의 증거로 쓰지 않는다
메서드 매개변수의 bivariance, as 단언, 검사 대상이 없는 tsconfig 가 각각 통과시킨 사례가 있다. 통과는 「코드가 맞다」가 아니라 「검사가 그 질문을 하지 않았다」를 뜻할 수 있다.
3. 게이트웨이를 실제로 불러 어떤 연산이 나가는지 확인한다
등록을 빠뜨린 연산은 옆 분기로 떨어지므로 서버는 정상 응답을 준다. 나가는 경로를 봐야 알 수 있다.
4. 여정이 끝나는 곳을 먼저 정하고 시작한다
어디까지 가면 확인이 끝나는지 모르면 중간에서 멈추게 된다. 공개 화면의 한 줄이면 그 줄이 그려지는 화면이 끝이다.
5. 검사가 덮는 구간을 적어 둔다
값이 아니라 이름을 지키는 검사를 두면 여정의 한 구간을 그 검사가 대신한다. 그 구간이 어디까지인지 적어 두지 않으면 다음 사람이 검사를 여정 전체로 읽는다.
적용 조건
-
값이 계약·매퍼·포트를 여러 번 갈아타는 구조에서 「고쳤다」를 판단할 때. 계약을 소유한 저장소가 따로 있고 생성기를 지나 들어오면 특히 걸린다.
-
앞선 커밋이 같은 값을 고치려다 못 고친 이력이 있으면 반드시 건다. 그 커밋이 무엇을 근거로 고쳤다고 판단했는지가 대개 중간 지점이다.
예외
-
경계가 하나뿐이거나 고친 그 곳이 여정의 끝이면 중간 확인으로 충분하다.
-
배포본을 열 수 없는 변경 — 아직 배포되지 않은 경로 — 은 여정의 끝까지 갈 수 없다. 그때는 어디까지 확인했는지를 적는다.
예시
-
관계 요약을 세 번 고쳤다. 매번 화면을 보고 나서야 다음 경계가 버리는 것을 알았다.
-
개념 삭제가 계속 질문 삭제 경로로 나갔다. 타입 검사가 통과해서 반영된 줄 알았고, 배포된 번들의 서버 로그에서 404 를 보고 알았다.
-
CONCEPT 을 질문 삭제로 되돌려 가드가 깨지는 것을 확인했다.
-
한 경계를 고치고 판단해 세 번 틀렸다. 값이 지나는 경계가 열한 개다.