처음에는 에이전트를 많이 부르면 일이 더 좋아질 줄 알았다.

PR을 검토할 때 보안 담당, 테스트 담당, 유지보수 담당을 나누면 그럴듯해 보인다. 문서 릴리스도 기술 검토 담당, 작성 담당, 공개 안전성 검수 담당을 나누면 더 체계적으로 보인다. 여기에 동시에 실행까지 붙이면 더 빠를 것 같았다.

그런데 에이전트를 여러 명 쓰는 건 곧바로 팀을 만든다는 뜻이 아니다. 메인이 감당해야 할 중간 출력을 잠깐 밖으로 빼는 것이다.

그래서 내가 지금 쓰는 가장 쉬운 구분은 이렇다.

서브에이전트는 역할을 나누는 말이고,
병렬 에이전트는 동시에 실행하는 방식이다.

역할을 나눴다고 항상 동시에 돌릴 필요는 없다. 동시에 돌린다고 해서 좋은 위임이 되는 것도 아니다. 먼저 이 둘을 나눠야 한다.

메인 에이전트가 역할을 나누고 독립 작업만 병렬로 돌린 뒤 최종 검수로 회수하는 구조.

왼쪽은 역할을 나누는 구조이고, 오른쪽은 독립 작업을 동시에 돌린 뒤 최종 책임을 메인이 회수하는 구조다.

서브에이전트는 보조 작업자다

서브에이전트는 메인 에이전트에게서 특정 일을 맡는 보조 작업자다.

예를 들어 고객용 설치 가이드 하나를 만들 때 메인 에이전트가 모든 일을 다 들고 있으면 부담이 커진다. 자료 조사, 문서 구조, 예시 판단, 공개 안전성, 미리보기 확인까지 한 대화에 계속 쌓인다. 처음에는 편하지만, 중간 출력이 길어질수록 핵심 결정이 묻힌다.

이때 서브에이전트로 역할을 나눈다.

  • 조사 담당은 공식 문서와 확인된 사실만 본다.
  • 문서 작성 담당은 고객이 읽을 흐름을 만든다.
  • 검수 담당은 공개 위험, 고객 오해, 도구 동작 정확성을 본다.
  • 메인은 최종 반영, 검증, 릴리스 판단을 맡는다.

이 구조의 핵심은 “여러 명이라 더 똑똑하다”가 아니다. 중간 작업을 메인 문맥에서 분리하고, 마지막에 필요한 요약만 돌려받는 것이다.

문서 릴리스에서도 이 차이가 중요하다. 초안 작성 에이전트와 공개 안전성 검수 에이전트가 각각 좋은 말을 해도, 공개 전환과 원격 저장소 반영(push) 판단은 메인이 회수해야 한다. 여러 에이전트가 말했다고 공개 책임이 여러 곳으로 나뉘지는 않는다.

OpenAI Codex 문서도 서브에이전트 작업 흐름(subagent workflow)을 메인 대화의 요구사항, 결정, 최종 산출물과 길고 지저분한 중간 조사나 검토 출력을 나누는 방식으로 설명한다. Claude Code 쪽 문서도 서브에이전트(subagent)를 별도 문맥에서 집중 작업을 맡기는 방식으로 설명한다. 도구마다 구현은 다르지만 운영 기준은 비슷하다. 메인은 방향과 책임을 잡고, 서브에이전트는 좁은 일을 맡는다.

병렬 에이전트는 동시에 돌리는 방식이다

병렬 에이전트라는 말에서는 작업자 수보다 여러 작업의 동시 진행이 중요하다.

예를 들어 PR 하나를 검토한다고 하자.

에이전트 1: 보안 위험만 본다.
에이전트 2: 테스트 누락만 본다.
에이전트 3: 유지보수 위험만 본다.

이 세 작업은 서로 독립적이다. 보안 검토자가 테스트 검토자의 결과를 기다릴 필요가 없다. 이런 경우에는 병렬로 돌릴 가치가 있다. 시간이 줄고, 각 관점이 서로 덜 섞인다.

반대로 이런 작업은 병렬에 잘 맞지 않는다.

에이전트 1: 같은 파일의 함수 이름을 바꾼다.
에이전트 2: 같은 파일의 호출부를 고친다.
에이전트 3: 같은 파일의 테스트를 바로 수정한다.

겉으로는 일이 나뉜 것 같지만, 실제로는 서로의 변경을 알아야 한다. 같은 파일을 동시에 고치면 충돌이 생기고, 누가 마지막 책임자인지 흐려진다. 이때는 병렬보다 순차가 낫다.

내 기준은 단순하다.

읽기와 검토는 병렬 후보,
쓰기와 배포는 단일 책임 후보.

읽기, 조사, 로그 분석, 여러 파일의 독립 검토는 병렬에 잘 맞는다. 코드 수정, 문서 최종 반영, 변경 저장(commit), 원격 저장소 반영(push), 배포(deploy)는 메인 또는 하나의 책임자에게 모으는 편이 안전하다.

둘은 겹칠 수 있지만 같은 말은 아니다

서브에이전트와 병렬 에이전트는 때로 겹친다.

메인이 세 명의 서브에이전트에게 각각 다른 검토를 맡기고 동시에 돌리면, 그건 서브에이전트를 병렬로 쓴 것이다.

하지만 항상 그런 것은 아니다.

한 명의 서브에이전트를 순차적으로 불러도 된다. 먼저 조사 담당에게 근거를 받는다. 그다음 문서 작성 담당에게 초안을 맡긴다. 마지막으로 검수 담당에게 위험을 본다. 이 흐름은 서브에이전트를 쓰지만 병렬은 아니다.

반대로 여러 독립 세션을 사람이 직접 띄워 동시에 작업하게 하는 방법도 있다. 넓게 보면 병렬 작업이지만, 한 메인 에이전트가 서브에이전트를 관리하는 구조와는 다르다.

그래서 용어를 이렇게 나누면 헷갈림이 줄어든다.

서브에이전트: 누가 어떤 역할을 맡는가.
병렬 에이전트: 그 역할들을 동시에 실행하는가.
메인 에이전트: 결과를 모아 최종 결정을 누가 책임지는가.

이 세 문장을 나눠서 보면 “에이전트를 몇 명 부를까”보다 먼저 “이 작업이 독립적인가”를 묻게 된다.

병렬이 도움이 되는 작업

병렬 에이전트가 도움이 되는 작업에는 공통점이 있다.

첫째, 작업이 서로 독립적이다. 한 에이전트의 결과가 다른 에이전트의 출발 조건이 아니어야 한다.

둘째, 결과를 합치는 기준이 분명하다. 각 에이전트가 긴 이야기를 돌려주지 않고, 메인이 비교하기 좋은 같은 형식의 요약을 줘야 한다.

셋째, 실패해도 되돌리기 쉽다. 읽기, 조사, 검토는 틀려도 다시 확인하면 된다. 반면 배포나 실제 서비스 데이터베이스(production DB) 변경은 병렬로 여러 에이전트가 건드리면 사고 범위가 커진다.

예를 들어 이런 요청은 병렬에 잘 맞는다.

이 설치 가이드를 세 관점에서 검토해줘.
- 처음 쓰는 고객도 이해하는가
- 공개하면 안 되는 정보가 없는가
- 주장과 근거가 맞는가

각 관점은 독립적으로 보고,
마지막에 메인이 중복 지적을 합쳐줘.

이 요청은 역할, 독립성, 결과 형식이 보인다. 메인은 최종 판단을 잃지 않는다.

반대로 이런 요청은 약하다.

여러 에이전트를 써서 이 기능을 빨리 완성해줘.

이 문장에는 역할도, 충돌 범위도, 결과 형식도 없다. 병렬로 돌릴 수는 있어도 좋은 위임은 아니다.

서브에이전트가 필요 없는 작업

서브에이전트는 많이 쓸수록 좋은 장치가 아니다.

작은 오탈자 수정, 한 문단 다듬기, 단일 파일의 작은 버그 수정처럼 작업이 작고 순서가 분명하면 메인이 직접 하는 편이 낫다. 서브에이전트를 부르면 입력을 다시 설명하고, 결과를 다시 읽고, 메인이 다시 통합해야 한다. 이때는 작업보다 조율 비용이 더 크다.

또 하나는 강하게 연결된 순차 작업이다.

예를 들어 “먼저 실패하는 테스트(failing test)를 재현하고, 원인을 찾고, 그 원인에 맞게 한 줄을 고친다”는 작업은 단계가 이어져 있다. 이걸 병렬로 쪼개면 각 에이전트가 서로 다른 가설을 만들고, 메인은 오히려 정리 비용을 떠안는다.

그래서 나는 시작 전에 이렇게 묻는다.

  • 이 작업은 여러 관점이 독립적으로 볼 수 있는가.
  • 각 에이전트가 같은 파일을 동시에 수정하지 않는가.
  • 돌아온 결과를 메인이 비교할 수 있는 형식이 있는가.
  • 중간 결과가 길어져도 메인 문맥에서 빼는 가치가 있는가.
  • 실패했을 때 어느 에이전트의 기준을 고쳐야 하는지 보이는가.

여기서 답이 흐리면 에이전트를 더 부르는 것보다 작업을 더 작게 자르는 편이 낫다.

좋은 위임은 네 칸으로 시작한다

좋은 위임은 멋진 프롬프트보다 네 칸에서 시작한다.

받은 자료: 무엇을 보고 판단할까.
맡은 역할: 이 에이전트는 무엇만 맡을까.
돌려줄 것: 어떤 형식으로 돌려줄까.
멈춤 조건: 어디서 멈추고 메인에게 돌려줄까.

예를 들어 문서 검수를 맡긴다면 이렇게 쓸 수 있다.

받은 자료:
- 공개 전 설치 가이드 초안
- 목표 독자: 제품을 처음 설치하는 개발자

맡은 역할:
- 처음 설치하는 사용자가 헷갈릴 문장만 찾는다.
- 사실 확인이나 배포 판단은 하지 않는다.

돌려줄 것:
- 가장 중요한 수정 3개
- 위치, 이유, 바로 고칠 문장

멈춤 조건:
- 내부 정보나 비공개 고객 정보가 보이면 수정하지 말고 보고한다.
- 문서를 공개해도 된다는 최종 판단은 메인에게 남긴다.

이 정도만 있어도 결과가 훨씬 다루기 쉬워진다. 에이전트가 무엇을 봐야 하는지, 무엇을 넘기면 안 되는지, 메인이 무엇을 책임져야 하는지가 보이기 때문이다.

메인은 마지막 작성자여야 한다

서브에이전트와 병렬 에이전트를 쓰더라도 마지막 책임은 메인에게 있어야 한다.

이건 문장상 멋진 원칙이 아니라 실제 운영 기준이다. 여러 에이전트가 각자 좋은 의견을 내도 최종 파일에 무엇을 반영할지, 무엇을 버릴지, 어떤 검증을 실행할지는 한 곳에서 결정해야 한다.

문서 릴리스라면 메인이 최종 문체, 공개 안전성, 공개 플래그, 빌드(build) 또는 미리보기 결과를 본다. 코드 작업이라면 메인이 변경 범위, 테스트, 변경 저장(commit) 대상, 원격 저장소 반영(push) 여부를 본다. 콘텐츠 배포라면 메인이 비공개 소스 변경과 공개 산출물 경계를 다시 확인한다.

Codex Skill 글에서 Skill과 AGENTS.md, hook, CI를 나눠 본 이유도 여기에 있다. 반복 절차를 나누는 것은 좋지만, 실행 경계까지 흐리면 위험하다.

Hook 글에서 말한 것처럼 위험 작업은 자동화보다 멈춤 조건이 먼저다. 병렬 에이전트도 마찬가지다. 더 빨리 끝내는 것이 목표가 아니라, 무엇을 동시에 해도 되는지와 무엇은 한 사람이 책임져야 하는지를 나누는 것이 먼저다.

여러 명을 부른 뒤 해야 할 일

병렬 검수에서 세 에이전트가 모두 다른 지적을 가져왔다고 해도 최종 문서나 PR에 들어갈 변경은 하나다.

메인은 그 지적을 합치고, 충돌하는 판단을 버리고, 실제 파일에 남길 변경만 고른다. 이 단계를 흐리면 에이전트 숫자가 늘수록 작업이 좋아지는 것이 아니라 중간 출력만 늘어난다.

처음에는 한 명의 보조 검토자만 써도 충분하다. 익숙해진 뒤에 독립적인 검토 세 개를 병렬로 나누면 된다. 중요한 것은 에이전트 숫자가 아니라 메인이 마지막 작성자라는 사실이다.

참고