Zoom Out: 길을 잃었을 때 AI에게 먼저 지도를 그리게 하기

가장 짧지만 유용함

/zoom-out은 Matt의 안정적인 엔지니어링 스킬 중 가장 짧을 수 있습니다. 핵심 지시는 한 문장으로 요약될 수 있습니다.

이 코드에 익숙하지 않습니다. 추상화 수준을 한 단계 높여 관련 모듈과 호출자 지도를 프로젝트 도메인 언어로 그려주세요.

이것은 코드를 작성하거나 리팩토링하기 위한 것이 아닙니다. 이것은 매우 흔한 상태를 처리하는 데 사용됩니다: 당신과 AI 모두 특정 파일에 집중하고 있지만, 왜 이 파일이 존재하는지 잊기 시작할 때입니다.

해결하는 실패 패턴

AI 코딩은 쉽게 지역 최적화에 빠질 수 있습니다.

1. 사용자가 파일을 지정합니다.
2. AI가 이 파일을 읽습니다.
3. AI가 지역 코드에 따라 의도를 추측합니다.
4. 수정 후 상위 호출자, 도메인 규칙 또는 ADR이 이 수정 사항을 지원하지 않는다는 것을 발견합니다.

인간도 마찬가지입니다. 디버깅을 오래 하면 특정 함수에 집중하게 되고 시스템 내에서의 위치를 잊어버립니다.

/zoom-out은 이러한 터널 시야를 차단하는 역할을 합니다. 에이전트가 구현을 일시 중지하고 먼저 다음 질문에 답하도록 합니다.

• 이 코드는 어떤 도메인 개념에 속합니까?
• 누가 그것을 호출합니까?
• 그것은 누구를 호출합니까?
• 그것 뒤에 있는 불변량은 무엇입니까?
• CONTEXT.md의 용어와 어떻게 대응됩니까?
• 특정 ADR에 의해 제약을 받습니까?

/improve-codebase-architecture와의 차이점

/zoom-out과 /improve-codebase-architecture는 모두 시스템 전체를 보지만 목표는 완전히 다릅니다.

/zoom-out은 "이것에 대해 설명해 주세요"와 더 유사합니다. 리팩토링 제안을 서두르거나 코드를 직접 수정해서는 안 됩니다. 그 임무는 인지 부하를 줄이는 것입니다.

도메인 용어를 강조하는 이유

이 스킬은 프로젝트의 도메인 용어집을 사용하도록 명시적으로 요구합니다. 그 이유는 다음과 같습니다. 파일 이름만 사용하여 설명하면 AI가 다음과 같은 내용을 쉽게 출력할 수 있습니다.

OrderService는 OrderRepository를 호출하고, OrderRepository는 db 클라이언트를 호출합니다.

이것은 설명처럼 들리지만 실제로는 설명하지 않은 것입니다. 더 유용한 지도는 다음과 같아야 합니다.

결제 흐름에서 Order Draft는 사용자가 아직 결제하기 전의 임시 주문입니다.
Order Finalization은 Draft를 변경 불가능한 Order로 변환하고 재고 예약을 트리거합니다.
`OrderService.finalize()`는 이 변환의 심(seam)이며, 주로 결제 콜백 및 관리자 재시도에서 호출됩니다.

두 번째 설명은 코드를 비즈니스 언어로 되돌립니다. "누가 누구를 호출하는지"만 아는 것이 아니라 "왜 존재하는지"도 알게 됩니다.

언제 사용하기에 적합한가

다음과 같은 시나리오에서 /zoom-out을 적극적으로 호출하는 것이 좋습니다.

• 익숙하지 않은 모듈을 맡기 전
• 버그를 수정하지만 관련 호출 체인을 아직 확신하지 못할 때
• AI가 생성한 코드를 검토 중이며 올바른 수준을 수정했는지 알 수 없을 때
• PRD 작성을 준비 중이며 모듈 경계를 확인하고 싶을 때
• 이미 3개의 파일을 보았지만 시스템 다이어그램을 형성하지 못했을 때
• /improve-codebase-architecture를 실행할 준비가 되었지만 아직 후보 영역을 확신하지 못할 때

이것은 "시작하기 전 5분"으로 특히 적합합니다. 어떤 버그는 코드가 어렵기 때문이 아니라 처음부터 잘못된 수준으로 보기 때문입니다.

재사용 가능한 출력 형식

원본 스킬은 매우 짧지만, 사용할 때 AI가 이 형식으로 출력하도록 하는 것이 좋습니다.

## 시스템 내 이 코드의 위치

## 주요 도메인 용어

## 주요 모듈

| 모듈 | 책임 | 호출자 | 호출 대상 |
|---|---|---|---|

## 주요 흐름

## 알려진 제약 조건 / ADR

## 먼저 봐야 할 파일

이 형식은 일반적인 설명보다 더 안정적이며 후속 /to-prd 또는 /diagnose의 컨텍스트로 변환하기에 더 적합합니다.

계획 모드로 사용하지 마세요

/zoom-out의 위험은 AI가 지도를 설명한 후 "이렇게 수정할 수 있습니다"라고 제안하는 것입니다. 코드를 이해하기만 하려면 명확하게 제한해야 합니다.

구현 계획은 제시하지 말고, 파일을 수정하지 말고, 구조만 설명하세요.

그 가치는 의사 결정과 이해를 분리하는 데 있습니다. 이해가 불분명할 때 제안하는 것은 종종 오해를 더 보기 좋게 포장하는 것일 뿐입니다.

제 사용 제안

/zoom-out은 다른 스킬과 조합하기에 좋습니다.

• /zoom-out → /diagnose: 먼저 시스템 지도를 보고 피드백 루프를 구축합니다.
• /zoom-out → /grill-with-docs: 먼저 기존 도메인 언어를 이해하고 새로운 요구 사항을 질문합니다.
• /zoom-out → /to-prd: 먼저 모듈 위치를 확인하고 PRD를 작성합니다.
• /zoom-out → /improve-codebase-architecture: 먼저 지도를 그리고 얕은/깊은 문제를 찾습니다.

이것은 완전한 프로세스가 아니라 브레이크일 뿐입니다. AI가 지역 파일에서 더 많은 것을 수정하기 시작할 때 먼저 zoom out하게 하면 종종 나중에 다시 작업하는 시간을 절약할 수 있습니다.

참고 자료

다음 글: Prototype: 폐기 가능한 코드로 디자인 질문에 답하기.