여러 에이전트 굴리기

02이 차시를 마치면

• 1.작업을 여러 에이전트에 나눠 맡길 수 있는지 판단하는 기준을 설명할 수 있다.
• 2.여러 에이전트에게 하위 작업을 동시에 맡기고(팬아웃) 결과를 하나로 모을 수 있다(팬인).
• 3.git worktree로 여러 에이전트가 같은 저장소에서 충돌 없이 병렬 작업하게 만들 수 있다.
• 4.만든 사람과 검증하는 사람의 역할을 분리해 적대적 리뷰 에이전트를 운용할 수 있다.
• 5.탐색–구현–검증으로 이어지는 멀티에이전트 워크플로를 설계할 수 있다.

03왜 필요한가

회원가입 폼 추가, 관리자 목록 화면 추가, 기존 기능 테스트 보강을 같은 날 끝내야 한다고 해보자. 이걸 한 에이전트 세션에 순서대로 다 시키면, 세션이 길어질수록 앞에서 준 지시를 뒤에서 놓치기 시작하고(1차시에서 다룬 컨텍스트 예산 소진), 세 가지 작업이 서로 다른 시점의 결정을 뒤섞어 처리한다. 게다가 그 코드를 짠 같은 에이전트가 스스로 검증까지 맡으면, 자기가 만든 실수를 자기가 못 잡는 일이 흔하게 생긴다.

• ·한 세션이 여러 작업을 순서대로 처리하면 먼저 처리한 작업의 맥락이 뒤 작업에 뒤섞여 들어간다.
• ·세션이 길어질수록 컨텍스트가 예산처럼 소진돼 뒷부분에서 앞의 지시나 결정을 놓친다.
• ·코드를 만든 에이전트가 스스로 검증까지 하면 자신의 실수를 스스로 못 잡는 경우가 많다.
• ·여러 작업을 동시에 진행하고 싶어도 같은 저장소를 동시에 건드리면 파일 충돌이 난다.

04개념 설명

05실습 가이드

1. 1. 오늘 작업을 독립 단위로 쪼개보기

   • -지금 진행 중인 프로젝트에서 서로 결과물이 겹치지 않는 작업 2~3개를 고른다.
   • -P8-1 프롬프트로 이 작업들이 정말 독립적인지, 순서 의존이 숨어 있지 않은지 점검받는다.
   • -점검 결과를 반영해 최종적으로 나눌 작업 목록을 확정한다.

   예상 결과 — 서로 독립적이라고 확인된 작업 2~3개의 목록이 만들어진다.

   안 될 때 — 점검 결과 순서 의존이 있다고 나오면, 그 두 작업은 나누지 않고 한 에이전트에게 순서대로 맡긴다.

2. 2. worktree로 작업 폴더 나누기

   • -터미널에서 각 작업마다 새 브랜치와 worktree를 하나씩 만든다.
   • -각 worktree 폴더가 독립된 폴더로 실제 파일 시스템에 생성됐는지 확인한다.
   • -VS Code에서 각 worktree 폴더를 별도 창으로 열어둔다.

   예상 결과 — 작업 개수만큼 독립된 worktree 폴더와 브랜치가 만들어지고, 각각 별도 창으로 열려 있다.

   안 될 때 — worktree 생성 명령이 실패하면 이미 같은 이름의 브랜치가 있는지 먼저 확인한다. 브랜치 이름을 바꾸거나 기존 브랜치를 정리한 뒤 다시 시도한다.

3. 3. 여러 에이전트에게 동시에 맡기기(팬아웃)

   • -각 worktree 창에서 Claude Code(또는 터미널 세션)를 하나씩 띄운다.
   • -P8-2 프롬프트를 각 작업에 맞게 채워, 서로 다른 세션에 동시에 지시를 내린다.
   • -각 세션이 독립적으로 작업을 진행하는 동안 다른 세션을 건드리지 않고 기다린다.

   예상 결과 — 여러 개의 에이전트 세션이 각자의 worktree 안에서 동시에 작업을 진행한다.

   안 될 때 — 세션이 서로 다른 worktree가 아니라 같은 폴더를 보고 있다면, 각 터미널이 올바른 worktree 경로에서 열렸는지 다시 확인한다.

4. 4. 진행 상황 확인하기

   • -각 세션이 끝났다고 알려오면, 바로 병합하지 말고 실제로 동작하는지 그 worktree 안에서 먼저 실행해본다.
   • -끝나지 않은 세션이 있다면 다른 세션 결과를 검토하는 동안 계속 진행시켜둔다.

   예상 결과 — 각 worktree에서 만들어진 결과물이 실제로 동작하는지 개별적으로 확인된다.

   안 될 때 — 완료했다는 말과 달리 실행이 안 되면, 그 세션에 실행 결과(에러 포함)를 그대로 알려주고 고치게 한다.

5. 5. 결과를 하나로 모으기(팬인)

   • -P8-4 프롬프트로 각 브랜치가 같은 파일을 건드렸는지 충돌 여부를 점검받는다.
   • -충돌이 없는 브랜치부터 순서대로 원래 브랜치에 병합한다.
   • -병합 후 전체를 한 번 더 실행해 개별로는 잘 되던 기능들이 합쳐진 뒤에도 잘 동작하는지 확인한다.

   예상 결과 — 모든 브랜치가 충돌 없이 하나로 병합되고, 합쳐진 상태에서도 전체가 정상 동작한다.

   안 될 때 — 병합 중 충돌이 나면 어느 쪽 변경을 기준으로 할지 직접 판단하거나, 두 변경 내용을 AI에게 보여주고 병합안을 요청한다.

6. 6. 적대적 리뷰 에이전트에게 검증 맡기기

   • -병합된 결과물을 만든 세션과는 다른 새 세션을 하나 연다.
   • -P8-3 프롬프트로 이 새 세션에게 '문제를 찾는 것'을 목표로 하는 검증 역할을 맡긴다.
   • -찾아낸 문제 목록을 받는다.

   예상 결과 — 생성 과정에서는 드러나지 않았던 문제(엣지 케이스, 누락된 처리 등)가 검증 에이전트를 통해 최소 하나 이상 발견된다.

   안 될 때 — 검증 에이전트가 '문제 없음'만 반복하면, 프롬프트에 '반드시 하나 이상의 의심되는 지점을 지적하라'는 조건을 추가해 다시 요청한다.

7. 7. 검증 결과 반영하기

   • -검증 에이전트가 찾은 문제를 원래 작업을 만든 에이전트(또는 새 세션)에게 그대로 전달한다.
   • -수정된 결과를 다시 실행해 문제가 실제로 해결됐는지 확인한다.
   • -필요하면 검증 에이전트에게 같은 부분을 한 번 더 확인받는다.

   예상 결과 — 검증에서 지적된 문제가 수정되고, 재검증에서 같은 문제가 다시 나오지 않는다.

   안 될 때 — 수정 후에도 같은 문제가 반복되면, 문제의 근본 원인이 코드가 아니라 애초의 작업 지시(요구사항)에 있는지 다시 살펴본다.

8. 8. 정리하기

   • -모든 병합과 검증이 끝난 브랜치의 worktree를 제거한다.
   • -더 이상 필요 없는 브랜치도 함께 정리한다.
   • -오늘 나눈 작업 기준, 팬아웃·팬인 과정, 검증에서 나온 문제를 간단히 기록해둔다.

   예상 결과 — worktree와 브랜치가 정리되고, 오늘 진행한 워크플로가 기록으로 남는다.

   안 될 때 — worktree 제거가 안 되면 해당 폴더에서 실행 중인 프로세스(에디터, 터미널)가 남아 있는지 확인하고 종료한 뒤 다시 시도한다.

06실전 프롬프트

지금 프로젝트에서 이 작업들을 동시에 진행하고 싶어.

1. [작업 1 설명]
2. [작업 2 설명]
3. [작업 3 설명]

이 작업들이 서로 파일이나 로직을 겹치지 않고
독립적으로 진행할 수 있는지 점검해줘.

순서를 지켜야 하거나 서로 의존하는 부분이 있다면
어떤 부분이 그런지 짚어주고,
동시에 진행해도 되는 조합으로 다시 나눠줘.

지금 이 폴더(worktree)에서 다음 작업만 진행해줘.

작업: [이 세션이 맡을 작업 하나]
완료 조건: [이 작업이 끝났다고 볼 수 있는 기준]

다른 작업(예: [다른 세션이 맡은 작업])은
다른 곳에서 별도로 진행 중이니까 건드리지 마.

작업이 끝나면 어떻게 테스트해서
완료 조건을 만족했는지 확인했는지도 같이 알려줘.

너는 이 코드를 만든 사람이 아니라 검증하는 사람이야.
이 코드가 맞다고 가정하지 말고,
무엇이 틀렸거나 빠졌을 수 있는지부터 찾아줘.

[검증할 코드 또는 변경 내용]

다음 관점에서 최소 하나 이상 의심되는 지점을 지적해줘.
1. 입력값이 예상과 다를 때 어떻게 되는지
2. 에러가 났을 때 처리가 되는지
3. 원래 있던 기능이 이번 변경으로 망가지지 않았는지

"문제 없음"으로만 끝내지 말고,
확신이 안 서는 부분은 확신이 안 선다고 그대로 말해줘.

이 브랜치들을 하나로 합치려고 해.

[브랜치 목록 또는 각 브랜치에서 바뀐 파일 목록]

1. 같은 파일을 두 개 이상의 브랜치가 동시에 건드렸는지 확인해줘.
2. 겹치는 부분이 있다면 어떤 순서로 병합해야
   충돌이 덜 나는지 알려줘.
3. 병합 후에 반드시 다시 확인해봐야 할 부분도 짚어줘.

브랜치를 병합했더니 충돌이 났어.

[충돌 메시지 또는 충돌 표시가 있는 파일 내용 전체]

각 브랜치가 이 부분을 왜 이렇게 바꿨는지는
[각 브랜치가 하려던 작업 설명]이야.

어느 쪽을 기준으로 합쳐야 하는지 판단해서
정리된 코드를 주고, 왜 그렇게 판단했는지도 설명해줘.

07이것만은 주의

08자가 점검

09과제

지금 진행 중인 프로젝트에서 서로 독립적인 작업 2~3개를 골라, worktree로 나눠 각각 에이전트에게 맡기고(팬아웃), 결과를 모아 병합한 뒤(팬인) 별도의 적대적 리뷰 에이전트로 검증하는 전체 흐름을 한 번 실습해본다.

제출 형식 — ① 작업을 나눈 기준과 각 worktree/브랜치 목록 ② 팬아웃에 사용한 프롬프트와 각 세션의 결과 요약 ③ 적대적 리뷰 에이전트가 찾아낸 문제와 수정 여부를 정리한 문서로 제출한다.

10더 알아보기

팬아웃(fan-out)

— 하나의 큰 작업을 여러 개의 독립적인 하위 작업으로 나눠 여러 에이전트에 동시에 맡기는 것.

팬인(fan-in)

— 여러 에이전트가 각자 끝낸 결과를 검토하고 하나로 합치는 것.

git worktree

— 하나의 git 저장소를 여러 개의 독립된 작업 폴더로 동시에 꺼내놓아, 브랜치별로 충돌 없이 병렬 작업하게 하는 기능.

적대적 리뷰 에이전트

— 코드를 만든 에이전트와 분리해, '문제가 없다'는 전제 없이 문제를 찾는 것을 목표로 검증을 맡는 에이전트.

다음 차시 예고 — 다음 차시에서는 오늘 만든 결과물을 다른 사람에게 보여줘도 부끄럽지 않은 프로덕션 품질(디자인 시스템, 접근성, 흔한 취약점 점검)로 끌어올리는 법을 다룹니다.