PM 혼자 하루 8시간 일하는 것과, PM이 4명의 에이전트를 운영하며 병렬로 일하는 것의 차이를 생각해보세요.

전자는 선형적입니다. 리서치가 끝나야 분석이 시작되고, 분석이 끝나야 문서가 만들어집니다.

후자는 병렬입니다. 리서처 에이전트가 데이터를 모으는 동안, 엔지니어 에이전트는 기술 검토를 하고, 마케터 에이전트는 포지셔닝 초안을 씁니다. 결과물은 동시에 나옵니다.

Claude Code의 에이전트 시스템은 이 두 번째 방식을 가능하게 합니다.

에이전트란 무엇인가

Claude Code에서 에이전트는 .claude/agents/ 폴더에 마크다운 파일로 정의됩니다. 각 에이전트는 역할, 전문성, 행동 원칙을 가집니다.

my-project/
└── .claude/
    └── agents/
        ├── researcher.md    # 리서처 에이전트
        ├── engineer.md      # 엔지니어 에이전트
        └── marketer.md      # 마케터 에이전트

파일 구조가 팀 조직도입니다.

에이전트 정의 작성법

각 에이전트 파일은 해당 역할의 전문가처럼 행동하도록 정의됩니다.

<!-- .claude/agents/researcher.md -->
---
name: researcher
description: 유저 리서치, 시장 분석, 경쟁사 조사를 담당하는 에이전트
tools: ["read", "web_search"]
---

당신은 시니어 UX 리서처입니다.

## 역할
- 사용자 인터뷰 데이터를 분석해 패턴을 발견합니다
- 경쟁사 제품의 강약점을 구조화합니다
- 데이터 기반으로 기회 영역을 정의합니다

## 출력 원칙
- 항상 데이터나 근거를 함께 제시합니다
- "왜(Why)"를 중심으로 인사이트를 작성합니다
- 마케팅 언어보다 사용자 언어로 씁니다

이 파일 하나가 리서처 에이전트의 “정체성”입니다.

병렬 실행: PRD 리뷰 예시

PRD 초안이 있을 때, 세 에이전트에게 동시에 리뷰를 요청하는 방법입니다.

# Claude Code에게 병렬 실행을 요청하는 방법
claude "draft-prd.md를 researcher, engineer, marketer 에이전트가 
각각 리뷰해서 피드백을 정리해줘. 세 가지 관점을 비교표로 정리."

Claude Code는 세 에이전트를 병렬로 실행합니다. 각 에이전트는 자신의 역할 정의에 따라 다른 관점으로 같은 문서를 분석합니다.

리서처 에이전트가 보는 것:

  • “이 PRD에서 사용자 조사 근거가 부족한 부분이 있습니다”
  • “가정(assumption)으로 처리된 내용 중 검증이 필요한 것들”

엔지니어 에이전트가 보는 것:

  • “이 기능의 기술적 복잡도는 M(2주) 수준입니다”
  • “스펙 3번은 기술적으로 구현이 어렵습니다. 대안을 제안합니다”

마케터 에이전트가 보는 것:

  • “타겟 페르소나가 명확하지 않습니다”
  • “이 기능의 차별화 포인트가 경쟁사와 겹칩니다”

세 관점을 10분 안에 얻습니다. 팀 회의 없이.

실전 에이전트 팀 구성 예시

제가 실제로 사용하는 에이전트 팀 구성입니다.

에이전트주요 역할트리거 상황
researcher데이터 분석, 인터뷰 정리”이 데이터 분석해줘”
engineer기술 검토, 복잡도 산정”이게 구현 가능한지 봐줘”
writer문서 작성, 편집”이 내용 PRD로 정리해줘”
critic가정 검증, 반론 제시”이 결정 반박해봐”
growth성장 지표, 실험 설계”이 기능 AB 테스트 어떻게 설계해?”

critic 에이전트가 특히 유용합니다. “이 의사결정에 반론을 제시해줘”라고 하면 PM이 놓치기 쉬운 맹점을 찾아줍니다. 에코 챔버를 방지하는 장치입니다.

Human-in-the-Loop: 언제 개입해야 하는가

에이전트를 쓴다고 해서 PM이 루프 밖으로 나가면 안 됩니다. 세 가지 원칙을 지킵니다.

에이전트에게 완전히 맡기는 것:

  • 반복적이고 패턴이 명확한 작업 (데이터 포매팅, 보고서 초안)
  • 시간이 많이 걸리고 창의성이 덜 필요한 작업 (경쟁사 기능 목록 정리)

PM이 검토하고 판단하는 것:

  • 에이전트 결과물의 방향성이 맞는지 확인
  • 서로 다른 에이전트 의견 중 무엇을 선택할지

PM만 할 수 있는 것:

  • “이 기능을 만들 것인가, 말 것인가”의 최종 결정
  • 이해관계자 관계 관리
  • 회사의 전략적 방향과 정합성 판단

에이전트는 레버리지를 높이는 도구이지, 책임을 이전하는 도구가 아닙니다.

시작하는 방법

에이전트 시스템을 처음 도입할 때 권장하는 순서입니다.

  1. 가장 반복적인 작업 하나를 선택합니다 — 예: 주간 보고서 작성
  2. 그 작업을 가장 잘 아는 “이상적인 사람”을 상상합니다 — 어떻게 접근하고, 무엇을 중요하게 여기는지
  3. 그 사람의 페르소나를 에이전트 파일에 씁니다
  4. 실제로 사용하고 결과를 보정합니다 — 에이전트 정의는 첫 번째 버전이 최선이 아닙니다

에이전트를 정의하는 행위 자체가 “이 작업을 어떻게 잘 하는가”를 명문화하는 과정입니다. PM의 암묵지를 코드로 만드는 것과 같습니다.

자주 묻는 질문

Q. 에이전트가 틀린 판단을 내리면 어떻게 하나요? 에이전트는 도구입니다. 틀린 결과가 나오면 에이전트 정의를 수정합니다. “이런 경우에는 이렇게 판단해”라는 예외 규칙을 추가하는 방식으로 점점 정교해집니다. 사람 팀원을 훈련시키는 것과 동일한 과정입니다.

Q. 몇 개의 에이전트부터 시작하면 좋을까요? 1개로 시작하세요. 가장 자주 반복하는 작업 하나에 에이전트 하나를 만들고, 2주 동안 써보세요. 그 다음에 두 번째를 만드는 것이 올바른 순서입니다. 처음부터 5개 만들면 어떤 에이전트가 잘 작동하는지 파악이 어렵습니다.