AI가 코드를 빠르게 작성하더라도 변경할 때마다 여러 파일의 세부 구현을 알아야 한다면 유지보수가 어려울 수 있습니다. 깊은 모듈을 살펴보는 목적은 복잡한 일을 무조건 한 파일로 합치는 것이 아니라, 사용자가 알아야 할 인터페이스와 내부 구현의 책임을 명확히 하는 것입니다.
깊은 모듈과 얕은 모듈
음식 주문을 예로 들어 보겠습니다. 손님이 메뉴를 선택하면 내부에서 재료 준비와 조리가 이뤄지는 구조는 인터페이스를 간단히 이해하는 비유가 됩니다. 반대로 손님이 조리 도구와 온도까지 지정해야 한다면 호출자가 내부 세부사항을 많이 알아야 합니다. 이는 개념을 이해하기 위한 예시이며 실제 소프트웨어의 설계 품질은 맥락에 따라 판단해야 합니다.
Matt Pocock의 스킬 저장소는 코드베이스의 구조 개선 기회를 찾는 스킬을 소개합니다. 기존 도메인 용어와 의사결정 기록을 살피고, 변경할 위치와 인터페이스를 검토하는 접근입니다. 영상에서 소개된 파일명과 구현 방식은 버전에 따라 달라질 수 있습니다.
삭제 테스트는 무엇을 묻나요?
한 모듈을 없앤다고 가정했을 때 복잡성이 함께 사라지는지, 아니면 다른 호출자에게 흩어지는지 생각해 볼 수 있습니다. 주변으로 중요한 책임이 퍼진다면 그 모듈의 경계가 유용할 수 있습니다. 이 질문은 설계 토론을 위한 사고 실험이지 실제 코드를 삭제하라는 지시나 자동 판정 공식이 아닙니다.
AI와 구조를 검토할 때
- 실제로 변경하기 어렵거나 규칙이 여러 곳에 흩어진 사례를 찾습니다.
- 호출자가 알아야 하는 정보와 모듈 내부의 책임을 구분합니다.
- 대안을 비교하고 기존 동작을 어떤 테스트로 확인할지 정합니다.
- 변경 범위를 작게 잡고 기존 사용자 동작을 확인합니다.
테스트를 무조건 삭제하거나 내부 구조만 보는 테스트를 모두 없애는 것이 목표는 아닙니다. 중요한 동작을 적절한 경계에서 검증하고, 변경 후에도 필요한 보호가 남는지 살펴야 합니다.
토큰 수치보다 실제 작업을 기준으로
구조가 명확하면 관련 코드를 찾는 데 도움이 될 수 있지만, 특정 토큰 수 이상에서 AI가 반드시 실패하거나 리팩터링으로 비용이 일정 비율 감소한다는 근거는 확인되지 않았습니다. 실제 프로젝트에서 관련 파일을 찾는 시간, 변경 범위, 테스트와 오류를 비교하는 편이 유용합니다.
다음 한 걸음
내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.