02. 필요한 컨텍스트 고르기

목표

작업에 필요한 사실을 찾고, 각 사실의 권위 있는 출처와 아직 모르는 부분을 컨텍스트 맵으로 정리합니다.

핵심 설명

컨텍스트는 프롬프트에 붙이는 긴 배경 설명만 뜻하지 않습니다. 저장소 규칙, 관련 코드, API 계약, 테스트, 오류 메시지, 도구 설명처럼 현재 판단에 쓰이는 정보 전체입니다. 중요한 것은 양이 아니라 관련성과 최신성입니다.

먼저 저장소의 작업 지침과 변경 상태를 확인합니다. 그다음 사용자 동작에서 시작해 화면, 이벤트 처리, API, 테스트 순서로 호출 경로를 따라갑니다. 공개 카피나 정책처럼 별도 원문이 있는 정보는 실제 화면 파일만 보고 결정하지 않습니다. 어떤 파일이 권위 있는 출처인지 기록합니다.

문의 폼 예시라면 폼 HTML, 제출 핸들러, API 요청·응답, 기존 테스트, 개인정보 처리 경계가 주요 컨텍스트입니다. 관련 없는 문서, 오래된 작업 기록, 실제 비밀값과 사용자 데이터는 넣지 않습니다. 테스트 실패가 새 사실을 드러내면 그 결과가 다음 판단의 컨텍스트가 됩니다.

체크리스트

• 저장소 지침과 현재 변경 상태를 확인했습니다.
• 사용자 동작에서 시작해 관련 코드 경로를 따라갔습니다.
• 각 요구사항의 권위 있는 출처를 구분했습니다.
• 기존 테스트와 실행 명령을 찾았습니다.
• 모르는 사실과 추정한 사실을 구분했습니다.
• 비밀값과 실제 사용자 데이터를 컨텍스트에서 제외했습니다.
• 관련 없는 파일을 “혹시 몰라서” 전부 전달하지 않았습니다.

직접 해보기

확인할 질문 | 읽을 위치 | 권위 수준 | 작업에 필요한 이유
현재 UI는?   |           |           |
요청 계약은? |           |           |
검증 명령은? |           |           |
수정 금지는? |           |           |
아직 모르는 것은?        |           |

작업에 직접 필요한 파일을 3~7개 정도로 먼저 좁혀 봅니다. 숫자는 규칙이 아니라 시작점입니다. 호출 경로가 더 넓다면 이유를 적고 추가합니다.

완료 근거

• 관련 파일마다 읽는 이유가 적혀 있습니다.
• 사용자 동작부터 데이터 또는 API 경계까지 흐름을 설명할 수 있습니다.
• 요구와 충돌할 수 있는 저장소 규칙을 찾았습니다.
• 추정으로 남은 부분과 확인 방법이 보입니다.
• 민감한 정보가 컨텍스트에 포함되지 않았습니다.

다음은 실행과 검증의 조건을 준비하는 03. 안전한 실행 환경 만들기입니다.