코드베이스 온보딩을 위한 Claude Code: 앱을 맵핑하는 프롬프트

당신이 배우려는 것(그리고 나중에 해도 되는 것들)

무작위로 파일을 읽는 건 느리게 느껴집니다. 대부분의 코드베이스는 이야기가 아닌 형태로 정리되어 있어요. 폴더를 열면 중요한 것처럼 보이는 이름이 열 개쯤 보이고 하나를 클릭하면 헬퍼, 설정 파일, 엣지 케이스로 빠져들기 쉽습니다. 한 시간 뒤에는 세부사항은 많지만 여전히 앱이 어떻게 동작하는지 설명하지 못할 때가 많습니다.

온보딩 동안 Claude Code의 더 나은 목표는 간단한 멘탈 맵을 만드는 것입니다. 그 맵은 세 가지 질문에 답해야 합니다:

• 주요 모듈은 무엇인가?
• 사용자가 트리거하는 핵심 흐름은 무엇인가?
• 프로덕션을 망가뜨리거나 버그를 일으킬 수 있는 위험한 영역은 어디인가?

1~2일 안에 "충분한" 온보딩은 "모든 클래스를 설명할 수 있다"가 아닙니다. 대신 아래에 가깝습니다:

• 중요한 5–8개 모듈의 이름과 각 모듈의 책임을 말할 수 있다.
• 실제 사용자 흐름 2–3개를 처음부터 끝까지 추적할 수 있다(UI나 API 진입부터 DB까지).
• 최상위 위험(결제, 인증, 데이터 쓰기, 백그라운드 작업)과 그것들이 어디에 있는지 안다.
• 무엇을 테스트하고 누구에게 물어봐야 하는지 알고 있어 작은 변경을 안전하게 할 수 있다.

깊은 리팩터, 모든 추상화를 완벽히 이해하기, 거의 건드리지 않는 오래된 코드를 읽는 것은 빠른 성과를 주지 못할 때가 많으니 우선순위에서 미뤄도 됩니다.

온보딩을 "거리 이름을 외우는 것"이 아니라 "지도를 그리는 것"으로 생각하세요. 프롬프트는 항상 "시스템에서 내가 어디에 있고, 다음에 무슨 일이 일어나며, 여기서 무엇이 잘못될 수 있나?"로 되돌아가게 해야 합니다. 그게 있으면 세부사항은 필요할 때 배우기 쉬워집니다.

준비 작업: 모든 것을 다 하려 하지 말고 필요한 맥락을 확보하세요

질문을 시작하기 전에 첫날에 보통 필요한 기본 항목들을 모으세요. Claude Code는 실제 파일, 실제 설정, 재현할 수 있는 실제 동작에 반응할 때 가장 잘 작동합니다.

먼저 접근 권한과 실행 환경을 확보하세요. 리포를 클론하고, 의존성을 설치하고, 앱(또는 최소한 일부)을 로컬에서 실행할 수 있는지 확인하세요. 로컬 설정이 어렵다면 스테이징 환경과 로그가 어디에 있는지 접근권을 받아 코드가 실제로 무엇을 하는지 검증할 수 있게 하세요.

다음으로 "진실의 출처" 문서를 찾으세요. 팀이 실제로 변경 시 업데이트하는 문서(README, 짧은 아키텍처 노트, ADR 폴더, 런북, 배포 노트)를 찾는 것입니다. 지저분하더라도 모듈과 흐름에 이름을 붙여 Q&A 결과를 훨씬 정확하게 만듭니다.

범위를 일찍 정하세요. 많은 리포지토리는 여러 앱, 서비스, 공유 패키지를 포함합니다. "API와 빌링 워커만" 혹은 "웹 앱과 인증 흐름만" 같은 경계를 정하세요. 명확한 범위는 끝없는 여지를 막아줍니다.

어시스턴트가 추측하지 않게 당신이 원하지 않는 가정들을 적어두세요. 사소해 보이지만 나중에 잘못된 멘탈 모델로 인해 시간을 낭비하지 않게 해줍니다.

간단한 준비 체크리스트 예시는 다음과 같습니다:

• 리포지토리 접근 권한, 필요한 권한, 테스트 실행 방법 확인
• 환경 설정 노트(env vars, 시드 데이터, 기능 플래그)와 로그/메트릭 보는 곳 수집
• 현재 진실 문서(README, 아키텍처 노트, ADR, 런북) 식별
• 이번 온보딩 패스의 범위와 명시적 제외 항목 정의
• 안전 규칙 설정: 비밀, API 키, 토큰, 고객 개인정보, 민감한 내용이 포함된 프로덕션 로그는 절대 붙여넣지 않기

무언가가 빠져 있다면 팀원에게 물어볼 질문으로 캡처하세요. 맥락이 없다고 추측으로 해결하려 하지 마세요.

멘탈 맵: 탐색하면서 캡처해야 할 것들

멘탈 맵은 이 앱의 주요 부분이 무엇이고, 서로 어떻게 통신하며, 어디서 문제가 생길 수 있는지를 답하는 작은 메모셋입니다. 잘 하면 온보딩은 파일을 훑는 일이 아니라 재사용 가능한 그림을 그리는 일이 됩니다.

결과물을 먼저 정의하세요. 실용적인 모듈 목록을 원합니다. 각 모듈에 대해 무엇을 하는지, 누가 소유하는지(알면 팀이나 사람), 핵심 의존성(다른 모듈, 서비스, DB, 외부 API)을 적으세요. 또한 주요 진입점(UI 라우트, API 엔드포인트, 백그라운드 잡, 예약 작업)을 기록하세요.

다음으로 중요한 사용자 여정을 몇 개 골라보세요. 3~5개면 충분합니다. 결제, 권한, 데이터 변경에 영향을 주는 흐름을 선택하세요. 예: 가입 및 이메일 확인, 유료 플랜/구매 생성, 관리자 권한 변경, 그리고 대부분 사용자가 의존하는 일일 핵심 흐름.

수집을 시작하기 전에 리스크 라벨을 어떻게 붙일지 결정하세요. 나중에 빠르게 훑어볼 수 있도록 카테고리는 단순하게 유지하세요. 유용한 카테고리는 보안, 데이터 무결성, 가동 시간, 비용입니다. 어떤 항목을 위험으로 표시하면 이유를 한 문장으로 적고, 안전하다는 것을 증명할 방법(테스트, 로그, 권한 확인)을 덧붙이세요.

일관된 형식을 사용하면 메모를 다시 쓰지 않고 온보딩 문서로 바꿀 수 있습니다:

• 모듈: 목적, 진입점, 의존성, 오너
• 핵심 흐름: 트리거, 단계, 기록되는 데이터, 실패 지점
• 데이터: 건드리는 테이블/컬렉션, 중요한 필드, 제약조건
• 리스크: 카테고리, 최악의 영향, 모니터링 방법, 롤백 방법
• 미해결 질문: 아직 모르는 것, 누구에게 물어볼지

예시: Checkout이 Billing을 호출해 payments와 invoices에 쓰는 경우, 데이터 무결성 및 비용 리스크로 태그하세요. 재시도가 어디서 발생하는지, 이중 청구를 방지하는 요소가 무엇인지 기록합니다.

코드베이스를 탐색하는 단계별 Q&A 프롬프트

새 리포지토리에 합류하면 빠른 방향 파악이 목표지 완벽한 이해가 아닙니다. 아래 프롬프트는 작은 안전한 단계로 멘탈 맵을 쌓게 도와줍니다.

탑레벨 폴더(또는 붙여넣은 부분)를 어시스턴트에게 보여주고 투어를 요청하세요. 각 라운드는 집중해서 진행하고, 읽을 다음 파일을 알려주는 질문 하나로 마무리하세요.

1) Repo tour
"Here is the top-level folder list: \u003cpaste\u003e. Explain what each folder likely contains and which ones matter for core product behavior."

2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."

3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."

4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."

5) Flow trace
"Trace this flow end-to-end: \u003cflow\u003e. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."

6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."

구체적 예: "사용자가 가입하고 첫 프로젝트를 만드는" 흐름을 맵핑할 때는 API 라우트 핸들러, 검증, DB 쓰기, 이메일 전송이나 리소스 프로비저닝을 담당하는 비동기 작업을 요청하세요. 그런 다음 "사용자가 프로젝트를 삭제할 때" 흐름도 다시 추적해 정리 작업에서의 구멍을 찾아보세요.

답변을 실행 가능하게 하려면 구체적 산출물을 요구하세요:

• 파일 경로와 함수 이름
• 명확히 구분된 가정과 알려지지 않은 점
• "X를 바꾸면 무엇이 깨지나?" 같은 의존성 질문
• 다음 10분 안에 읽을 수 있는 작은 읽기 과제 하나

답변을 캡처해 유용하게 유지하는 법

가장 큰 온보딩 이득은 흩어진 Q&A를 다른 개발자가 재사용할 수 있는 메모로 바꾸는 것입니다. 메모가 당신만 이해할 수 있으면 같은 탐색을 반복하게 됩니다.

간단한 구조가 긴 문서보다 낫습니다. 각 탐색 세션 후 답변을 다섯 가지 작은 산출물(한 파일 또는 문서로 합쳐도 됨)로 저장하세요: 모듈 테이블, 용어집, 핵심 흐름, 미해결 항목, 리스크 레지스터.

여기에 붙여넣어 진행하면서 채워 넣을 수 있는 간단한 템플릿이 있습니다:

Module table
- Module:
  Owns:
  Touches:
  Entry points:

Glossary
- Term:
  Meaning:
  Code name(s):

Key flow (name)
1.
2.
3.

Unknowns
- Question:
  Best person to ask:
  Where to look next:

Risk register
- Risk:
  Location:
  Why it matters:
  How to verify:

핵심 흐름은 의도적으로 짧게 유지하세요. 예: 1) 사용자가 로그인, 2) 백엔드가 세션 생성, 3) 클라이언트가 대시보드 로드, 4) API가 데이터 조회, 5) UI가 렌더 및 오류 처리. 흐름을 다섯 단계로 못 줄이면 로그인과 대시보드 로드처럼 분리하세요.

Claude Code를 사용할 때는 모든 답변에 한 줄을 추가하세요: "이걸 어떻게 테스트하나?" 이 한 줄이 수동적인 메모를 실행 가능한 체크리스트로 바꿉니다. 특히 미해결 항목과 리스크가 겹칠 때 유용합니다.

Koder.ai 같은 바이브-코딩 플랫폼을 사용하면 이런 식의 메모가 생성된 변경의 부작용을 찾는 데에도 도움이 됩니다. 접촉점이 많은 모듈은 변경이 집중되는 경향이 있습니다.

적은 파일 읽기로 위험한 영역 빠르게 찾기

코드베이스의 리스크는 드물게 무작위로 배치됩니다. 인증, 데이터 변경, 외부 시스템 통신, 백그라운드 작업처럼 결정이 모이는 곳에 집중합니다. 몇 가지 표적 질문과 간단한 검색으로 대부분 찾을 수 있습니다.

먼저 정체성 관련 부분을 살펴보세요. 인증(로그인, 세션, 토큰)이 어디서 일어나는지, 권한 결정(역할 검사, 기능 플래그, 소유권 규칙)이 어디에 있는지 물어보세요. 흔한 함정은 UI, API 핸들러, DB 쿼리에 검사가 분산되어 단일 출처가 없는 경우입니다.

다음으로 쓰기 경로를 맵하세요. 레코드를 생성/수정/삭제하는 엔드포인트나 함수, 시간이 지남에 따라 데이터를 바꾸는 마이그레이션, 백그라운드 잡을 포함하세요. 많은 미스터리 버그는 비동기 워커가 요청 종료 후에 예상치 못한 값을 쓰는 데서 옵니다.

리스크를 빠르게 드러내는 프롬프트 예시:

• "[리소스 X]에 대한 권한을 강제하는 모든 위치를 나열하세요. 최종 게이트는 어디인가?"
• "[테이블/엔티티 X]를 쓰는 전체 경로를 보여주세요: API 핸들러 -> 서비스 -> DB 호출. 검증은 어디에 있나?"
• "외부 통합(결제, 이메일, 웹훅, 서드파티 API)이 무엇이 있고, 재시도/타임아웃은 어디에 설정되어 있나?"
• "작업이 두 번 실행될 수 있는 곳은 어디인가(큐, 고루틴, 크론)? 멱등성은 어떻게 보장되나?"
• "조용히 망가질 수 있는 부분은 무엇이며, 어떻게 알 수 있나(로그, 메트릭, 알림, 대시보드)?"

그다음 설정과 비밀 관리도 확인하세요. 환경 변수, 런타임 설정 파일, 기본값 폴백을 찾아보세요. 기본값은 유용하지만 값이 빠져서 개발 키가 프로덕션에 사용되는 것처럼 잘못된 구성일 때 위험할 수 있습니다.

간단한 예: Go 백엔드와 PostgreSQL 조합에서, 실패 시 재시도하는 "이메일 전송" 잡이 멱등성 키 없이 재시도하면 사용자에게 중복 이메일이 갈 수 있습니다. 실패를 단지 경고 로그만 남기고 알림이 없다면 조용히 망가지는 고위험 영역입니다. 이런 부분은 문서화하고 일찍 테스트할 가치가 있습니다.

예시 워크스루: 하나의 실제 사용자 흐름 맵핑하기

하나의 실제 흐름을 사용해 시스템을 처음부터 끝까지 실선으로 연결하세요. 로그인 흐름은 라우팅, 검증, 세션/토큰, DB 조회를 건드리기 때문에 시작 흐름으로 좋습니다.

시나리오: React 웹 앱이 Go API를 호출하고 API는 PostgreSQL을 읽고 씁니다. 목표는 모든 파일을 이해하는 것이 아니라 "사용자가 로그인 버튼을 클릭하면 다음에 어떤 코드가 실행되고 어떤 데이터가 이동하며 무엇이 깨질 수 있나?"에 답하는 것입니다. 이렇게 하면 온보딩이 구체적으로 유지됩니다.

브라우저에서 데이터베이스까지 흐름을 맵핑하기

UI에서 시작해 한 홉씩 앞으로 걸어가세요. 구체적 파일명, 함수, 요청/응답 형태를 물어보세요.

• "로그인 화면의 React 라우트/페이지를 찾아라. 어떤 컴포넌트가 렌더하고 제출 시 어떤 액션이 발생하나?"
• "API 클라이언트 호출은 어디에서 이루어지나(fetch/axios 등)? 정확한 URL 경로, 메서드, 헤더, 바디는 무엇인가?"
• "Go 쪽에서 해당 경로의 핸들러는 어디에 등록되나? 라우터 설정과 핸들러 함수를 보여달라."
• "핸들러 내부에서 입력 검증은 어디에서 이루어지나(프론트엔드, 백엔드, 둘 다)? 규칙은 무엇이고 오류는 어디서 포맷되나?"
• "로그인에 어떤 DB 쿼리가 실행되나? 레포지토리/SQL 파일을 가리키고 건드리는 테이블/컬럼, 트랜잭션이나 락이 있는지 적어라."

각 답변 후 멘탈 맵에 한 줄을 적으세요: "UI 컴포넌트 -> API 엔드포인트 -> 핸들러 -> 서비스 -> DB 쿼리 -> 응답." 이름을 포함하세요, 단순히 "어떤 함수"라고 적지 마세요.

빠른 실행으로 확인하기

경로를 확보한 후 작은 테스트 실행으로 확인하세요. 맵핑한 코드 경로가 실제로 사용되는 경로인지 확인하는 단계입니다.

브라우저 개발자 도구에서 네트워크 요청(경로, 상태 코드, 응답 바디)을 관찰하세요. 핸들러와 DB 호출 주변에 로그(가능하면 요청 ID)를 추가하세요. PostgreSQL에서 예상 변경사항(예: last_login_at, 세션, 감사 행)을 쿼리해 확인하세요. 실패 상황(잘못된 비밀번호, 누락 필드)을 강제로 발생시켜 에러 메시지가 어디서 만들어지고 어디에 표시되는지 적어두세요. 성공과 실패의 예상 응답(상태 코드와 주요 필드)을 기록해 다음 개발자가 빠르게 확인할 수 있게 하세요.

이 단일 흐름은 소유 경계(무엇을 UI가 신뢰하고 API가 강제하며 오류가 어디서 사라지거나 중복 처리되는지)를 드러냅니다.

멘탈 맵을 짧은 온보딩 문서로 바꾸기

괜찮은 멘탈 맵을 얻었으면 1–2페이지의 노트로 정리하세요. 목표는 완전함이 아니라 다음 개발자가 "이 앱이 무엇이고, 어디를 먼저 봐야 하며, 무엇이 가장 깨지기 쉬운가"를 빠르게 알게 하는 것입니다.

Claude Code를 사용하는 경우 이 문서를 Q&A의 산출물로 취급하세요: 명확하고 구체적이며 빠르게 훑어볼 수 있어야 합니다.

간단한 1–2페이지 구조

문서는 예측 가능해야 사람들이 빠르게 찾습니다. 좋은 구조는 다음과 같습니다:

• 목적: 앱이 무엇을 하는지, 누가 사용하는지, "완료"의 기준
• 아키텍처 요약: 주요 서비스, 데이터 저장소, 요청이 시스템을 통과하는 방식
• 실행 방법: 필요 전제조건, 앱을 시작하는 한 줄 명령, 테스트 실행 한 줄 명령
• 위치 안내: 중요한 폴더와 진입점 역할을 하는 5–10개 파일
• 핵심 흐름 및 리스크: 중요한 여정의 짧은 추적과 변경 후 검증 방법

실용적으로 만들기

"어디에 있는가" 섹션에는 "Auth는 X에서 시작, 세션 로직은 Y, UI 라우트는 Z"처럼 포인터를 넣으세요. 전체 트리를 덤프하지 말고 사람들이 실제로 건드릴 것만 고르세요.

"핵심 흐름"은 각 단계에 파일명을 적어 4–7단계로 줄이세요: 트리거, 컨트롤러/핸들러, 핵심 모듈, DB 호출, 외부 효과(이메일 전송, 상태 업데이트, 잡 큐잉). "위험한 영역"에는 실패 모드와 가장 빠른 안전 검증(특정 테스트, 스모크 실행, 관찰할 로그)을 적으세요.

마지막으로 누군가가 안전하게 기여할 수 있게 작은 첫 작업 목록을 넣으세요:

• 한 화면의 문구 수정이나 검증 규칙 업데이트
• 발견한 헬퍼 주위에 작은 단위 테스트 추가
• 재현 가능한 저위험 버그 고치기
• 가드레일 추가: 더 나은 오류 메시지, 입력 체크, 타임아웃
• 프로덕션 배포 담당자와 도메인 관련 질문을 할 사람 적기

흔한 실수와 피하는 방법

어시스턴트에 "리포 전체 설명"을 요청하는 것이 가장 빠르게 낭비하는 방법입니다. 긴 요약이 나오지만 모호하게 남기기 쉽습니다. 대신 하나의 작은 조각(한 모듈과 한 사용자 흐름)을 선택한 뒤 외곽으로 확장하세요.

두 번째로 흔한 실수는 어떤 여정이 중요한지 지정하지 않는 것입니다. "체크아웃", "로그인", "관리자 편집"처럼 구체적으로 시작하지 않으면 답변이 일반적인 아키텍처 얘기로 흐릅니다. 각 세션 시작 시 한 가지 구체적 목표를 정하세요: "가입 흐름의 엔드투엔드 이해를 도와줘. 검증, 오류 상태, 데이터 저장 위치 포함." 같은 식으로요.

또 다른 함정은 어시스턴트가 추측하게 두는 것입니다. 불확실한 부분은 반드시 불확실하다고 라벨링하게 하세요. 코드에서 증명할 수 있는 것과 추론한 것을 분리하게 하세요.

미해결 항목을 가시화하세요

노트에서는 간단한 규칙을 사용하세요: 모든 주장은 다음 중 하나로 태그됩니다.

• 코드에서 확인됨
• 앱을 실행해 확인됨
• 가정(확인 필요)
• 알 수 없음(맥락 부족)

구조 없는 메모 수집도 문제입니다. 채팅 스니펫 더미는 멘탈 맵으로 바꾸기 어렵습니다. 일관된 템플릿을 유지하세요: 관여 모듈, 진입점, 핵심 함수와 파일, 건드리는 데이터, 부수 효과, 에러 경로, 테스트할 항목.

출력물을 사실로 취급하지 마세요

Claude Code를 써도 출력은 초안으로 취급하세요. 특히 프로덕션에 영향을 줄 수 있는 부분(인증, 결제, 권한, 백그라운드 작업, 마이그레이션)은 반드시 실행 환경에서 확인하세요.

실용적 예: 어시스턴트가 "비밀번호 재설정이 X를 통해 이메일을 보낸다"고 하면 dev 환경에서 재설정을 트리거하고 로그나 이메일 샌드박스를 확인해 사실 여부를 검증하세요. 이 현실 검증이 잘못된 이야기 속으로 온보딩되는 일을 막습니다.

"온보딩 완료"라 말하기 전의 빠른 체크리스트

리포를 외울 필요는 없습니다. 안전한 변경을 할 수 있고 실제 이슈를 디버그하며 다음 사람에게 시스템을 설명할 수 있는 자신감이 필요합니다.

완료라고 할 수 있으려면 다음을 추측 없이 대답할 수 있어야 합니다:

• 코드의 다섯 가지 가장 중요한 영역과 각 영역의 책임(예: UI, API 레이어, 백그라운드 잡, 데이터 접근, 통합).
• 두 개의 가치 있는 사용자 여정을 끝까지 설명하고 각 여정의 시작 파일/함수 위치를 가리킬 수 있는가.
• 인증이 어디서 강제되는지, 역할/권한이 어디에서 정의되고 검사되는지 가리킬 수 있는가.
• 가장 위험한 DB 쓰기(결제, 권한, 삭제, 상태 전환)를 말할 수 있고 각 변경을 안전하게 테스트하는 방법을 설명할 수 있는가.
• 새 개발자에게 10분 이내에 읽을 수 있는 짧은 온보딩 노트를 건네고 어디서 시작할지 알려줄 수 있는가.

하나가 부족하면 넓게 훑지 말고 작은 집중 패스를 하세요. 한 흐름을 골라 DB 경계까지 따라가고 멈춘 뒤 배운 것을 적으세요. 모호한 부분은 문단으로 적지 말고 질문으로 캡처하세요. "역할 X가 어디 생성되나?"가 "인증이 혼란스럽다"보다 유용합니다.

마지막 테스트: 기능 플래그 뒤에 있는 작은 기능을 추가하라고 했을 때 건드릴 파일, 실행할 테스트, 관찰할 실패 모드를 말할 수 있으면 충분히 온보딩된 것입니다.

다음 단계: 지도를 최신으로 유지하고 인수인계를 쉽게 하기

멘탈 맵은 현실과 일치할 때만 유용합니다. 행동에 영향을 주는 변경이 있을 때마다 바로 업데이트하세요. 일회성 작업이 아니라 살아있는 문서로 취급하세요.

가벼운 루틴이 큰 개편보다 낫습니다. 이미 하고 있는 작업에 업데이트를 묶으세요:

• 각 기능 후: 모듈 목록과 영향을 받은 주요 흐름 업데이트
• 각 인시던트 후: 트리거, 영향, 정확한 수정 위치 추가
• 위험한 리팩터 후: 무엇이 바뀌었고 무엇이 호환된 상태인지 기록
• 릴리스 전: 상위 3개 리스크 영역과 테스트 경로 재확인
• 한 달에 한 번: 오래된 노트 삭제 및 주요 모듈 오너 확인

온보딩 문서를 코드 근처에 두고 코드베이스와 동일한 규율로 버전 관리하세요. 작은 diff는 읽힙니다. 큰 문서 개편은 보통 건너뛰어집니다.

배포가 위험하면 다음 사람이 빠르게 복구할 수 있도록 무엇이 바뀌었고 무엇을 관찰해야 하며 어떻게 롤백하는지 적어두세요. 스냅샷과 롤백을 지원하면 스냅샷 이름, 이유, 수정 후의 "정상" 상태를 적어두세요.

Koder.ai를 사용하면(본문에 koder.ai 표기) 플래닝 모드가 Q&A에서 일관된 모듈 맵과 온보딩 노트를 초안화하는 데 도움을 주고, 소스 코드 내보내기는 리뷰어가 결과를 검증하기 쉽게 합니다.

마지막으로 다음 개발자가 추측하지 않고 따라할 수 있는 인수인계 체크리스트를 정의하세요:

• 먼저 읽어야 할 것(2–3개 파일/문서)과 그 이유
• 로컬에서 실행할 것(명령, env vars, 시드 데이터)
• 검증할 것(하나의 정상 경로와 하나의 실패 케이스)
• 날카로운 부분(위험한 모듈, 플래키 테스트, 까다로운 설정)
• 무엇을 누구에게 물어볼지(핵심 흐름의 오너)

잘 하면 Claude Code를 사용한 코드베이스 온보딩이 습관이 됩니다: 각 변경은 다음 사람을 위한 더 명확한 지도를 남깁니다.