codebase-design
명확한 인터페이스를 가진 딥 모듈 설계
대부분의 코드베이스는 큰 인터페이스와 얇은 구현을 가진 얕은 모듈로 인해 어려움을 겪습니다. 이 스킬은 딥 모듈을 설계하고, 시임(seam)의 위치를 결정하며, 코드를 더 테스트 가능하고 유지보수하기 쉽게 만들기 위한 공유 어휘와 방법론을 제공합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"codebase-design" 사용 중입니다. processOrder 함수를 리뷰하세요. 이것은 딥 모듈인가요?
예상 결과:
- 현재 얕은 모듈입니다: processOrder(order)는 내부적으로 자체 StripeGateway를 생성합니다.
- 딥 버전: processOrder(order, paymentGateway)는 게이트웨이를 의존성으로 받습니다.
- 호출자는 함수를 변경하지 않고 테스트 또는 mock 게이트웨이로 대체할 수 있습니다.
- 인터페이스에 파라미터가 하나 더 추가되지만 모듈이 테스트 가능해집니다.
"codebase-design" 사용 중입니다. Redis 캐시 의존성을 어떻게 분류해야 하나요?
예상 결과:
- Redis는 local-substitutable입니다: 테스트에서 ioredis-mock 또는 testcontainers-redis를 실행할 수 있습니다.
- 대체가 존재하면 딥닝 가능합니다.
- 테스트 스위트에서 대체로 실행하며 테스트하세요.
- 외부 인터페이스에 포트는 없고 내부 시임만 있습니다.
보안 감사
안전The codebase-design skill is a pure documentation skill providing vocabulary and methodology for designing deep modules. All 35 static findings are false positives: 'Weak cryptographic algorithm' detections are triggered by the word 'deep' (confused with DES cipher references in unrelated codebases), 'Ruby/shell backtick execution' matches markdown backtick formatting for code blocks, and 'System reconnaissance' is a misidentification of architectural vocabulary. No executable code, scripts, or data flows exist in any file.
위험 요인
품질 점수
만들 수 있는 것
새로운 모듈 인터페이스 설계
개발자가 호출자에 대한 최대 레버리지와 테스트에 대한 최소 표면적을 가진 새로운 기능의 깔끔한 인터페이스를 설계하려고 합니다.
얕은 모듈을 딥 모듈로 리팩토링
엔지니어링 팀이 얇은 구현을 가진 얕은 모듈을 축적했으며, 이를 더 깊고 테스트 가능한 단위로 통합하려고 합니다.
공유 아키텍처 어휘 확립
팀이 코드 리뷰와 설계 논의에서 모듈 경계, 시임, 어댑터에 대해 논의하기 위한 일관된 언어가 필요합니다.
이 프롬프트를 사용해 보세요
[모듈 이름] 인터페이스를 리뷰하세요. 깊은 모듈인가요, 얕은 모듈인가요? 메서드 수를 줄이거나 파라미터를 단순화할 수 있나요? 구현 내부에 숨길 수 있는 복잡성은 무엇인가요?
관련된 [N]개의 얕은 모듈들을 살펴보세요. 이들을 병합하면 더 깊은 모듈이 생성될까요? 의존성을 in-process, local-substitutable, remote-but-owned, true external로 분류하세요.
[기능]에 대해 시임을 어디에 배치해야 할지 결정해야 합니다. 삭제 테스트를 적용하세요: 이 모듈을 삭제하면 복잡성이 사라지나요, 아니면 퍼지나요? 포트가 있어야 하나요, 아니면 내부 시임만으로 충분한가요?
[모듈]에 대해 근본적으로 다른 인터페이스를 설계하기 위해 3개의 서브에이전트를 생성하세요. 에이전트 1은 인터페이스를 최소화하고, 에이전트 2는 유연성을 최대화하며, 에이전트 3은 가장 일반적인 호출자에 최적화해야 합니다.
모범 사례
- 이 스킬의 정확한 어휘를 팀과 문서 전반에서 일관되게 사용하세요
- 모듈이 그 가치를 충족하고 있는지 확인하기 위해 삭제 테스트를 적용하세요
- 최소 두 개의 어댑터가 정당화될 때만 포트를 도입하세요
- 모듈의 인터페이스에서 테스트를 작성하고, 인터페이스 너머로 테스트하지 마세요
- 더 많은 것을 추가하기 전에 두 개의 어댑터 (프로덕션과 테스트)를 위해 설계하세요
피하기
- 이 스킬의 정확한 용어 대신 'component', 'service', 'API', 'boundary'로 대체하기
- 어댑터가 하나만 있는 시임 도입
- 내부 상태에 접근하여 인터페이스 너머로 테스트하기
- 구현-라인 대 인터페이스-라인의 비율로 깊이를 취급하기
- 통합 후 얕은 모듈에 대한 기존 단위 테스트를 유지하기