클로드 코드 Team 기능 완전 가이드 (총 9편) | 6편 리서치/기획 팀 운영 모델 설계: 경쟁 가설과 교차 검증으로 결론의 질을 올리는 법

시리즈: 클로드 코드 Team 기능 완전 가이드 (총 9편) | 6편

리서치/기획 팀 운영 모델 설계: 경쟁 가설과 교차 검증으로 결론의 질을 올리는 법

리서치와 기획에서 Team 기능의 핵심 가치는 "빨리 조사하기"가 아니라 "경쟁 가설 기반의 교차 검증"이에요. 각자 열심히 했는데 결론이 합쳐지지 않는 참사, 한 번쯤 겪어보셨죠? 이걸 구조적으로 막으려면 역할 분리와 산출물 템플릿 설계가 핵심이에요.

Summary

• 리서치/기획 팀의 핵심 가치는 단순 요약이 아니라 "근거의 추적 가능성"과 "가정의 노출"이에요
• 권장 팀 구성은 Researcher(2), Comparator, Architect, Risk Checker, Writer(옵션) 총 5~6명이에요
• 산출물 템플릿(비교표, ADR, PoC 계획서)이 "컨텍스트 공유 장치" 역할을 해요
• 가장 위험한 실패 모드는 "각자 열심히 했는데 결론이 합쳐지지 않는" 상태예요

이 글의 대상

• 기술 검토나 도구 평가를 팀 단위로 진행하려는 리드/매니저
• 리서치 결과를 의사결정에 바로 연결하고 싶은 아키텍트
• AI 에이전트 팀으로 기획 워크플로를 자동화하려는 분

목차

1. 리서치 팀에서 Team 기능이 빛나는 이유
2. 권장 팀 구성: 5~6명 역할 분배
3. 각 역할의 구체적 업무
4. 산출물 템플릿 = 컨텍스트 공유 장치
5. 가장 위험한 실패 모드와 예방법
6. 운영 흐름 종합

---

1. 리서치 팀에서 Team 기능이 빛나는 이유

리서치를 혼자 하면 빠지기 쉬운 함정이 있어요. 자기가 찾은 정보에 확증 편향이 생기는 거예요. "이게 좋다"고 결론 내리고 나면, 그 결론을 뒷받침하는 정보만 더 찾게 되거든요.

Team 기능으로 여러 에이전트를 돌리면 이 문제를 구조적으로 깰 수 있어요. 핵심은 경쟁 가설이에요. 한 에이전트가 "A가 낫다"고 조사하는 동안, 다른 에이전트는 "B가 낫다"는 관점에서 조사하는 거죠.

단순 요약보다 중요한 두 가지가 있어요:

• 근거의 추적 가능성: 어디서 나온 정보인지 출처가 명확해야 해요
• 가정의 노출: "이건 사실"이 아니라 "이건 가정"이라고 구분해야 해요

이 두 가지가 갖춰져야 의사결정자가 리서치 결과를 신뢰하고 쓸 수 있어요.

2. 권장 팀 구성: 5~6명 역할 분배

역할	인원	핵심 미션
Researcher	2명	서로 다른 범위에서 정보 수집
Comparator	1명	비교표 작성, 결정 요인 도출
Architect	1명	ADR 초안, PoC 아키텍처 설계
Risk Checker	1명	가정/리스크 도출, 우선순위화
Writer (옵션)	1명	최종 보고서 통합 및 정리

Researcher를 2명 두는 게 포인트예요. 1명이면 확증 편향에 빠지기 쉽고, 3명 이상이면 조율 비용이 커져요. 2명이 서로 다른 범위를 맡아서 독립적으로 조사하는 게 최적이에요.

3. 각 역할의 구체적 업무

Researcher (2명)

두 Researcher는 범위를 명확히 나눠야 해요. 겹치면 중복 작업이고, 빠지면 블라인드 스팟이에요.

Researcher A	Researcher B
공식 문서, 기술 스펙, 벤치마크	사용자 사례, 커뮤니티 피드백, 제약사항
가격/요금 구조, SLA	운영 리스크, 마이그레이션 비용
"이 기술이 뭘 할 수 있는가"	"이 기술을 쓰면 뭐가 위험한가"

이렇게 나누면 자연스럽게 긍정/부정 양면이 수집돼요.

Comparator (1명)

Researcher들의 결과를 받아서 정량/정성 비교표를 만들어요.

비교표에 들어가야 할 항목은 이래요:

• 비교 항목 (기능, 성능, 가격 등)
• 출처 (어디서 나온 데이터인지)
• 장점/단점
• 운영 복잡도
• 비용 (초기 + 운영)
• PoC 난이도

여기서 핵심은 결정 요인(Decision Driver)을 뽑아내는 거예요. "이 중에서 우리 상황에 가장 중요한 기준이 뭔지"를 명시하는 거죠.

Architect (1명)

Comparator의 비교 결과를 바탕으로 ADR(Architecture Decision Record) 초안을 작성해요.

ADR에는 이런 내용이 들어가요:

• 의사결정 배경 (왜 이 결정이 필요한지)
• 검토한 대안들
• 선택한 대안과 근거
• 예상되는 결과와 트레이드오프
• PoC 성공 기준

Architect는 또한 PoC를 한다면 어떤 아키텍처로, 어떤 성공 기준으로 진행할지도 설계해요.

Risk Checker (1명)

전체 리서치 결과에서 가정과 리스크를 뽑아내는 역할이에요. 다른 팀원들이 "사실"이라고 적은 것 중에 실은 "가정"인 것들을 걸러내요.

리스크 평가는 확률 x 임팩트 매트릭스로 우선순위를 매겨요.

리스크	확률	임팩트	우선순위
벤더 락인	높음	높음	최우선
API 제한 변경	중간	높음	높음
학습 곡선	높음	낮음	중간

이렇게 정리하면 의사결정자가 "어떤 리스크를 감수할 건지" 판단하기가 훨씬 쉬워져요.

Writer (옵션, 1명)

나머지 팀원들의 산출물을 하나의 보고서로 통합해요. 팀 규모가 작거나 리더가 직접 정리할 수 있다면 생략해도 돼요.

4. 산출물 템플릿 = 컨텍스트 공유 장치

여기가 정말 중요한 부분이에요. 템플릿이 곧 컨텍스트 공유 장치예요.

에이전트 팀에서 가장 어려운 건 "다른 팀원이 뭘 했는지 아는 것"이에요. 사람이면 회의를 하면 되지만, 에이전트끼리는 정해진 형식으로 산출물을 주고받아야 해요. 그래서 템플릿이 중요한 거예요.

핵심 산출물 세 가지

1. 비교표 (Comparator 산출물)

| 항목 | 옵션 A | 옵션 B | 출처 |
|------|--------|--------|------|
| 가격 | $X/월  | $Y/월  | [링크] |
| 성능 | 100ms  | 150ms  | [벤치마크] |
| 운영 복잡도 | 낮음 | 중간 | [사례] |
| PoC 난이도 | 쉬움 | 보통 | [문서] |

2. ADR (Architect 산출물)

# ADR-001: [제목]
## 배경
## 검토 대안
## 결정
## 근거
## 결과 및 트레이드오프
## PoC 성공 기준

3. PoC 계획서 (Architect 산출물)

# PoC 계획서
## 검증 목표
## 아키텍처
## 성공 기준 (정량)
## 일정
## 필요 리소스

이 세 가지 템플릿만 있으면, 각 역할이 만든 결과물이 자연스럽게 하나의 의사결정 흐름으로 이어져요.

5. 가장 위험한 실패 모드와 예방법

리서치/기획 팀에서 가장 위험한 실패는 뭘까요?

"각자 열심히 했는데 결론이 합쳐지지 않는" 상태

Researcher A는 "옵션 A가 좋다"고 했고, Researcher B는 "옵션 B가 좋다"고 했는데, Comparator가 두 결과를 비교하려고 보니 기준 자체가 달라서 합칠 수 없는 경우예요.

이걸 막으려면 시작 전에 세 가지를 맞춰야 해요:

맞춰야 할 것	구체적으로
비교 기준	"이 항목들을 반드시 포함해서 조사하세요" 목록
출처 형식	"출처는 이름 형식으로, 접근일 포함"
결론 형식	"장점 3개, 단점 3개, 종합 평가 1줄" 형식 지정

리더가 태스크를 배정할 때 이 세 가지를 템플릿으로 넘겨주면 돼요. 그러면 각 에이전트가 같은 형식으로 결과를 내놓으니까, Comparator가 바로 합칠 수 있어요.

6. 운영 흐름 종합

전체를 하나로 이으면 이런 흐름이에요.

[리더] 리서치 질문 정의 + 비교 기준 + 템플릿 배포
    ↓
[Researcher A] 공식 문서/스펙/가격 조사  ─┐
[Researcher B] 사례/제약/운영 리스크 조사 ─┤ (병렬)
                                           ↓
[Comparator] 비교표 작성 + 결정 요인 도출
    ↓
[Architect] ADR 초안 + PoC 설계 ──┐
[Risk Checker] 가정/리스크 평가 ──┤ (병렬)
    ↓
[Writer/리더] 최종 보고서 통합

Researcher 2명이 병렬로 조사하고, 그 결과를 Comparator가 합치고, 다시 Architect와 Risk Checker가 병렬로 각자 분석하는 구조예요. 순차적으로 했으면 5단계인 걸, 병렬화로 3단계로 줄이는 거죠.

---

핵심 정리

1. 리서치 Team의 핵심 가치: 경쟁 가설 기반의 교차 검증 (확증 편향 방지)
2. Researcher 2명을 범위 분리해서 배치 → 자연스럽게 긍정/부정 양면 수집
3. 산출물 템플릿(비교표, ADR, PoC 계획서)이 컨텍스트 공유 장치 역할
4. 시작 전에 비교 기준, 출처 형식, 결론 형식을 통일해야 결론이 합쳐짐
5. 가장 위험한 실패: "각자 열심히 했는데 결론이 합쳐지지 않는" 상태

FAQ

Q. Researcher를 3명 이상 두면 더 좋지 않아요?

A. 조사 범위가 넓으면 3명도 괜찮지만, 보통은 2명이 최적이에요. 3명 이상이면 조율 비용이 급격히 올라가고, 범위 분리도 어려워져요. 2명이 "기술 스펙 vs 운영 현실"로 나누는 게 가장 효율적이에요.

Q. Comparator 없이 Researcher가 직접 비교하면 안 되나요?

A. 가능은 하지만 추천하지 않아요. 자기가 조사한 내용에 편향이 생기기 쉽거든요. 별도 역할이 "중립적 입장에서" 비교하는 게 결과의 신뢰도를 높여요.

Q. ADR이 뭐예요? 꼭 써야 해요?

A. Architecture Decision Record의 약자로, "왜 이 결정을 내렸는지"를 기록하는 문서예요. 꼭 써야 하는 건 아니지만, 나중에 "왜 이걸로 했더라?" 할 때 엄청 유용해요. 팀 규모가 커질수록 가치가 올라가요.

Q. Risk Checker가 찾은 리스크를 누가 해결해요?

A. Risk Checker는 리스크를 발견하고 우선순위를 매기는 역할이에요. 실제 해결은 의사결정자(리더)가 판단해요. "이 리스크는 감수한다" 또는 "이 리스크 때문에 대안을 택한다" 같은 결정을 내리는 거죠.

Q. 산출물 템플릿을 처음부터 다 만들어야 해요?

A. 이 글에서 제시한 세 가지(비교표, ADR, PoC 계획서)를 그대로 쓰면 돼요. 프로젝트 성격에 맞게 항목을 추가하거나 빼면 되고요. 핵심은 "모든 팀원이 같은 형식으로 결과를 내는 것"이에요.

Q. 개발 팀(5편)과 리서치 팀(6편)을 섞어서 운영할 수 있어요?

A. 그럼요. 오히려 현실에서는 섞어서 쓰는 경우가 많아요. 기획 단계에서는 리서치 팀 모델로, 구현 단계에서는 개발 팀 모델로 전환하면 돼요. Team 기능은 구성을 유연하게 바꿀 수 있으니까요.

Q. Writer 역할을 리더가 겸하면 안 되나요?

A. 충분히 가능해요. 팀 규모가 작거나 리더가 직접 보고서를 정리하는 걸 선호한다면 Writer를 따로 두지 않아도 돼요. Writer는 산출물이 많아서 통합 작업 자체가 큰 일이 될 때 추가하면 좋아요.

참고 자료 (References)

데이터 출처

출처	설명	링크
Agent Teams 공식 문서 (EN)	Team 기능 전체 가이드	Agent Teams (EN)
Agent Teams 공식 문서 (KO)	Team 기능 한국어 가이드	Agent Teams (KO)
Hooks Guide	훅 설정 및 활용법	Hooks Guide
ADR GitHub 템플릿	ADR 작성 가이드 및 예시	ADR GitHub
Google Code Review Guide	코드 리뷰 모범 사례	Google Code Review

핵심 인용

"리서치에서 가장 위험한 실패는 '각자 열심히 했는데 결론이 합쳐지지 않는' 상태다." -- 교차 검증 원칙

다음 편 예고

[7편] 가드레일 패키지 - 권한, 승인, Hooks로 팀을 안전하게

• 권한 상속 구조와 단일 실패 지점(SPOF)
• Plan approval로 위험 작업에 승인 단계 넣기
• Hooks로 완료 조건을 코드로 강제하기