DongHyeonkaandClaude Opus 5
ab59130196
이번 파이프라인 작업과 무관하게 작업 트리에 남아 있던 것을 그대로 올린다. 사용자가 「전부 커밋」으로 정했고, 이번 작업과 섞이지 않게 커밋만 나눴다. 대부분은 clean-architecture-backend-template 의 그림 정본 재배치다 — final/assets/diagrams/<이름>/ 에 있던 것이 CLAUDE.md 가 적은 배치인 final/assets/<이름>/ 로 옮겨졌고 .techviz/<이름>/ 이 함께 들어왔다. 삽입 줄의 대부분(3.15M)이 그 .techviz context.json 이다. 그 밖에 ca-tmpl·document-haness 의 정리, .claude/agents/ 열한 개, writing-practitioner-guides 스킬, .playwright-mcp 세션 산출물, scripts/check-ssot-facts.py 와 그 시험이 들어 있다. 이 커밋의 내용은 내가 만든 것이 아니라 이전 세션이 남긴 것이고 검증하지 않았다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.3 KiB
kind, slug, title, topic, project, status, sourceRevision, rootTreeNode, verifiedOn
| kind | slug | title | topic | project | status | sourceRevision | rootTreeNode | verifiedOn |
|---|---|---|---|---|---|---|---|---|
| REFERENCE | check-which-duplicate-is-wired | 중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다 | duplicate-mechanisms | clean-architecture-backend-template | 게시 전 | 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916 | reference:check-which-duplicate-is-wired |
중복 장치를 찾으면 어느 쪽이 조립됐는지 먼저 확인한다
같은 일을 하는 구현이 둘 있을 때 정교한 쪽을 읽고 판정해서, 실제로 도는 약한 쪽을 놓치는 것을 막는다. 정교한 구현은 늦게 만들어지고 배선이 뒤따르지 않는 경우가 많아, 그동안 원래 있던 사본이 계속 돈다.
목적
같은 일을 하는 구현이 둘 있을 때 정교한 쪽을 읽고 판정해서, 실제로 도는 약한 쪽을 놓치는 것을 막는다.
규칙
-
조립된 쪽을 먼저 찾는다 어느 쪽이 스테레오타입을 갖는지, 어느 쪽이 빈으로 만들어지는지, 어느 쪽이 설정에서 지목되는지를 본다.
-
만들어지는 것과 호출되는 것을 나눠 센다 빈이 있다는 것과 그것을 주입받아 부르는 코드가 있다는 것은 다르다. 세 단계로 나눈다. 만들어지는가, 주입되는가, 호출되는가.
-
약한 쪽이 도는 경우가 흔하다 정교한 구현은 늦게 만들어지고 배선이 뒤따르지 않는 경우가 많다. 그동안 원래 있던 사본이 계속 돈다.
-
인프라 설정도 중복의 한쪽이다 같은 판정이 애플리케이션 코드와 프록시 설정에 각각 있으면, 도는 것은 대개 프록시 쪽이다.
-
정본을 정하는 것이 수정이다 둘 다 살려 두면 다음 사람이 어느 쪽을 고쳐야 하는지 모른다.
적용 조건
같은 개념의 구현이 둘 이상 발견되는 모든 경우
플랫폼과 애플리케이션이 한 저장소에 함께 있는 경우 특히
예외
의도적으로 계층별로 다른 강도를 두는 경우가 있다. 그때는 어느 계층이 무엇을 보장하는지가 문서에 있어야 하고, 약한 쪽이 강한 쪽을 우회하는 경로가 없어야 한다.
예시
전체 트랜잭션 재시도 코디네이터는 빈으로 만들어지고 주입받아 호출하는 코드가 0 이다.
웹푸시 구독 값은 클라이언트가 준 엔드포인트를 자기 private 검사로만 확인하고, 플랫폼의 목적지 정책을 지나지 않는다.
forwarded 헤더 신뢰 판정은 421 줄의 Java 정책과 Nginx 설정 양쪽에 있고, 도는 것은 Nginx 쪽이다.
outbox 는 두 스택으로 구현되어 있고 출하되는 것은 application-core 쪽이다.
관계
- 재시도 코디네이터는 빈이지만 그것을 어디에도 적용하지 않는다 두 번째 규칙이 필요한 사례다.
- 클라이언트가 준 엔드포인트가 SSRF 가드가 아니라 약한 private 사본을 지났다 세 번째 규칙의 사례다.
- forwarded 헤더 신뢰 판정이 Nginx에 있고 Java 정책 421 LOC은 대부분 참조되지 않는다 네 번째 규칙의 사례다.
- 조립 결함을 판정하려면 조립하는 쪽을 먼저 읽어야 한다 같은 계열의 상위 규칙이다.