04. 에이전트와 작업 실행하기

목표

에이전트가 불필요하게 범위를 넓히지 않도록 실행 계획을 만들고, 검토 가능한 첫 변경을 완성합니다.

핵심 설명

에이전트에게 한 번에 많은 일을 맡기는 것이 항상 빠르지는 않습니다. 먼저 현재 상태 확인 → 최소 변경 → 검증 → 결과 해석 순서로 계획합니다. 각 단계에는 입력, 예상 산출물, 검증 방법이 있어야 합니다.

한 에이전트가 관련 파일을 따라가며 구현하는 편이 문맥을 유지하기 쉬운 경우가 많습니다. 병렬 작업은 서로 독립적인 조사, 접근성 검토, 테스트 분석처럼 같은 파일을 동시에 바꾸지 않는 일에 적합합니다. 같은 코드 경계를 여러 에이전트가 수정하면 병합 비용과 판단 충돌이 커질 수 있습니다.

작업 요청에는 01단계의 결과와 02·03단계의 경계를 함께 제공합니다. 구현 상세를 과도하게 지시하기보다 확인해야 할 사실, 수정 범위, 검증 명령, 보고할 불확실성을 분명히 합니다. 에이전트의 완료 보고는 증거가 아니라 검토할 주장입니다. diff와 검증 결과를 직접 확인합니다.

체크리스트

• 계획의 각 단계가 하나의 확인 가능한 결과를 만듭니다.
• 한 번에 진행 중인 핵심 구현 단계가 명확합니다.
• 병렬 작업은 파일과 판단 경계가 독립적입니다.
• 사용자 결과와 무관한 리팩터링을 포함하지 않습니다.
• 에이전트가 모르는 점과 추정을 보고하도록 요청했습니다.
• 코드 변경 뒤 실행할 검증과 diff 검토가 계획에 있습니다.
• 외부 효과가 있는 행동은 승인 전에 실행하지 않습니다.

직접 해보기

문의 폼 예시를 다음처럼 나눠 봅니다.

1. 폼 제출 경로와 기존 테스트를 확인한다.
2. 진행 중 상태를 한 곳에서 관리하도록 최소 변경한다.
3. 버튼 클릭과 Enter 제출이 같은 경로를 쓰는지 검사한다.
4. 성공·실패·재시도 동작을 모의 응답으로 검증한다.
5. diff에서 요구 밖 변경이 없는지 확인한다.

에이전트에게 실행을 맡긴 뒤 보고서만 읽지 말고, 변경된 파일과 diff를 작업 브리프의 각 조건에 대조합니다.

완료 근거

• 변경된 각 파일이 작업 목표와 연결됩니다.
• 요구와 무관한 변경이 diff에 섞이지 않았습니다.
• 사용한 가정과 남은 불확실성이 드러납니다.
• 첫 검증 결과가 다음 행동을 선택할 만큼 구체적입니다.

다음은 결과를 증거로 해석하는 05. 증거로 검증 루프 돌리기입니다.