【Claude Code】Agent Teams에 ‘화이트보드’ 하나를 놓았더니, 분업이 협업으로 바뀌었다

URL: https://zenn.dev/happy_elements/articles/da2dda3618425c

Title: 【Claude Code】Agent Teams에 ‘화이트보드’ 하나를 놓았더니, 분업이 협업으로 바뀌었다

‘화이트보드’ 하나를 놓았더니, 분업이 협업으로 바뀌었다

Claude Code의 Agent Teams로 같은 분석 태스크를 2번 실행했습니다.

1회차는 기본 구성으로 2명의 에이전트에게 각각 다른 역할을 할당해 병렬 실행했습니다. 결과는 품질 높은 독립 리포트 2개였습니다. 하지만 두 결과를 나란히 놓고 보면, 서로의 내용을 참조한 문장이 어디에도 없었습니다.

2회차는 리더가 공유 Markdown 파일(화이트보드) 하나를 준비했을 뿐입니다. 결과는 이렇게 달라졌습니다.

SendMessage(Agent Teams 표준 메시지 기능)는 ‘대화’이고, 화이트보드는 ‘공유 지식’입니다. 화이트보드가 팀워크를 촉진하는 건 인간과 AI 모두 비슷한 듯합니다.

실험 상세: 무엇이 일어났나

태스크 설계

목표: Next.js App Router의 아키텍처 베스트 프랙티스를 분석한다

팀 구성: Agent A(라우팅·데이터 페칭 담당) + Agent B(성능 최적화 담당)

Case 1(기본 구성): 각자 완벽하지만, 서로를 모른다

Agent A는 라우팅과 데이터 페칭을 포괄적으로 분석했습니다. Server Components에서의 fetch, generateStaticParams, Parallel Routes, Intercepting Routes 등.

Agent B는 성능을 자세히 정리했습니다. 이미지 최적화, next/font, Route Segment Config, Partial Prerendering(PPR) 설정 방법 등.

문제: 두 리포트는 각각 완성도가 높지만 서로를 참조하지 않습니다. Agent A는 Server Component에서의 fetch를 분석했지만 캐시 전략과의 관계는 다루지 않았습니다. Agent B는 캐시 설정 방법을 분석했지만 어떤 데이터 페칭 패턴과 조합해야 하는지에는 언급하지 않았습니다.

Case 2(화이트보드 있음): 예측하고, 참조하고, 검증한다

Agent A가 화이트보드에 기록한 내용 중에는 이런 섹션이 등장했습니다.

markdown
### Agent B에게 인수인계(성능에 영향을 줄 법한 설계 판단)
- Next.js 15 이후, fetch는 기본적으로 비캐시 → 명시적으로 `cache: 'force-cache'` 지정이 필요
- fetch는 layout/page/generateMetadata 사이에서 자동으로 중복 제거됨(Request Memoization)
- generateStaticParams로 프리렌더링되는 페이지 → 빌드 시점에 캐시됨
- Parallel Routes(@folder)는 독립적으로 스트리밍 가능 → loading.tsx 배치가 핵심

Agent A는 자신의 담당 범위를 넘어, Agent B의 일에 도움이 될 법한 ‘예측’을 남겨두고 있었습니다.

Agent B는 이 화이트보드를 읽고 나서 분석을 시작했습니다. 그 결과, Case 1에는 없던 섹션이 생겼습니다.

markdown
### Agent A의 데이터 페칭 설계 → 성능에 미치는 영향
- Next.js 15의 기본 비캐시 → 의도적으로 `force-cache`나 `revalidate`를
  설정하지 않으면 SSR마다 fetch가 실행됨. revalidate 값이 TTFB에 직결
- fetch의 Request Memoization → 동일 렌더링 경로에서 같은 URL+옵션의
  fetch는 자동으로 1회로 합쳐짐. 다만 ORM 등은 React cache()로 명시적으로 메모이제이션 필요
- Parallel Routes + Suspense → 각 @slot이 독립 스트리밍 가능.
  가장 느린 slot이 페이지 전체 LCP를 결정

### Agent A가 예측한 설계 판단 — 성능 검증 결과
- fetch 기본 비캐시 → ✅ 확인. `use cache` 디렉티브로 명시적으로 캐시 가능
- fetch 중복 제거 → ✅ 확인. layout/page/generateMetadata 사이에서 동작
- generateStaticParams → ✅ 빌드 시 캐시 확인. dynamicParams: false로 미생성 페이지를 404 처리 가능
- Parallel Routes + streaming → ✅ 확인. 다만 error.tsx 배치로 개별 에러 바운더리가 필요

게다가 Case 1에는 없던 ‘횡단적 관찰’ 섹션도 생겨났습니다.

markdown
## Cross-Cutting Observations
1. fetch의 캐시 전략은 ‘데이터 페칭 설계’와 ‘성능’
   두 문맥 모두에서 이해해야 한다 — 한쪽만 보면 설계 판단을 그르칠 수 있다
2. layout.tsx는 ‘라우팅 구조’인 동시에 ‘캐시 경계’이기도 하다
3. Suspense boundary 배치는 라우팅 설계와 Core Web Vitals를
   모두 고려해 결정해야 한다
4. Route Segment Config(dynamic, revalidate)는
   데이터 페칭 설계와 성능 튜닝의 접점이다

화이트보드 패턴: 5분 만에 시험해볼 템플릿

화이트보드 패턴은 팀 멤버가 읽고 쓸 수 있는 공유 Markdown 파일을 하나 두는 접근입니다. Agent Teams의 표준 기능이 아니라, 리더의 프롬프트에 포함시키는 패턴입니다.

text
리더가 화이트보드 생성 → Agent A 실행·기록 → Agent B가 읽은 뒤 실행

이번 실험은 A → B 순차 실행이었지만, B → A 순서나, 둘이 병렬로 화이트보드를 공유하는 구성도 가능합니다.

아래 템플릿을 리더의 프롬프트에 그대로 포함해 사용할 수 있습니다.

markdown
# Whiteboard: {주제}

## Goal
{팀이 최종적으로 답해야 하는 질문}

## Team Structure
- Agent A: {담당 영역}
- Agent B: {담당 영역}

## How Our Work Connects
{두 사람의 작업 연결 지점을 명시}

## Key Questions
1. {양쪽 관점이 모두 필요한 질문}
2. {양쪽 관점이 모두 필요한 질문}
3. {양쪽 관점이 모두 필요한 질문}

---

## Agent A Findings
(Agent A: 여기에 작성)

## Agent B Findings
(Agent B: 여기에 작성)

## Cross-Cutting Observations
(누구든: 횡단적 관찰을 작성)

포인트는 3가지입니다.

1. 목표를 명시 — 무엇을 위해 분석하는가
2. 연결 지점을 명시 — 두 사람의 일이 어떻게 연결되는가
3. 작성 칸을 구조화 — 각 에이전트가 쓸 자리와, 횡단 관찰을 쓰는 공유 공간

왜 이걸로 달라지는가

Agent Teams의 기본: 사실은 공유되지 않는다

Agent Teams에서 팀원 간에 공유되는 것과 공유되지 않는 것을 정리해보면 다음과 같습니다.

공식 문서에도 각 에이전트는 독립된 컨텍스트 윈도우를 가지며 대화 기록은 공유되지 않는다고 명시되어 있습니다. 연계 수단은 SendMessage(메시징)와 태스크 리스트로 제한됩니다.

즉 표준 정보 공유 수단은 SendMessage와 태스크 리스트뿐입니다. 대화 기록도 리더의 지식도 팀원에게는 승계되지 않습니다.

인간 팀에서도 똑같은 일이 일어난다

생각해보면, 이는 인간 팀에서도 흔한 이야기입니다.

Slack으로 메시지만 주고받아서는 팀이 ‘분업’에 머무릅니다. 하지만 회의실 화이트보드에 목표와 진행 상황을 적어두는 순간 멤버들의 움직임이 바뀌는 경험을 해본 적이 있지 않나요?

팀 연구 분야에서는 이를 **‘공유 멘탈 모델(shared mental model)’**이라 부릅니다. 팀 멤버가 동일한 전체 그림을 가짐으로써, 명시적 지시가 없어도 서로의 행동을 예측하고 조정할 수 있게 된다는 관점입니다.

화이트보드가 수행하는 역할을 정리하면 이렇습니다.

즉 화이트보드는 채팅으로는 전달되기 어려운 **‘전체상’과 ‘연결’**을 가시화합니다.

사실 40년 전부터 있던 아이디어

이 접근에는 선행 연구도 있습니다. 1986년에 Nii가 제안한 **Blackboard Architecture**는 여러 에이전트가 공유 지식 베이스를 읽고 쓰며 협조하는 아키텍처입니다.

2025년 연구(Han & Zhang)에서는 LLM 멀티 에이전트 시스템에 이 아키텍처를 적용한 결과, 정적 멀티 에이전트 시스템과 동등 이상 성능을 달성하면서도 토큰 소비도 크게 줄일 수 있었다고 보고합니다.

Agent Teams에서의 ‘화이트보드’는 이 Blackboard Architecture의 경량 구현으로 볼 수도 있을 듯합니다.

실전: 구분 사용과 주의점

언제 사용할까

언제 사용하지 않을까

화이트보드가 언제나 최선은 아닙니다.

• 완전히 독립적인 태스크 — 서로 다른 리포지토리 변경, 공유 컨텍스트가 없는 작업. 화이트보드를 둬도 읽을 이유가 없어 오버헤드만 늘어납니다.
• 단순 병렬 실행 — ‘테스트 작성’과 ‘문서 작성’처럼 접점이 적은 작업. SendMessage로 충분합니다.
• 3명 이상의 팀 — 화이트보드 구조가 복잡해져 오히려 혼란스러울 수 있습니다. 이 경우 역할별로 섹션을 나누거나, 여러 화이트보드로 분할하는 등의 공이 필요합니다.

리더의 역할 변화

화이트보드 패턴에서는 리더의 역할이 바뀝니다. 팀원은 파일 쓰기 권한이 제한될 수 있으므로, 리더가 팀원의 발견을 화이트보드에 옮겨 적어야 하는 경우가 있습니다.

겉보기엔 번거롭지만, 인간 팀의 리더가 하는 역할과 비슷합니다. 회의에서 화이트보드에 요점을 정리하는 퍼실리테이터, Slack에서 중요한 논의를 요약해 올리는 매니저. 하고 있는 일은 같다고 느낍니다. 팀의 지식을 가시화하고, 구조화하고, 필요한 사람에게 전달하는 것.

리더의 일은 ‘작업 지시’가 아니라 ‘지식 퍼실리테이션’이 됩니다.

왜 ‘파일’인가

화이트보드 구현에는 여러 선택지가 있습니다.

파일의 가장 큰 강점은 지속성입니다. 대화가 끝난 뒤에도 파일은 남습니다. 화이트보드는 ‘코디네이션 도구’이자 ‘팀의 결과물’이기도 합니다. 이 이중 역할이 파일 기반의 강점입니다.

정리

Agent Teams에서 역할만 나누면 ‘분업’에 그칩니다. 화이트보드를 놓으면 ‘협업’으로 바뀝니다.

1. 목표와 연결 지점을 공유한다 — 각 에이전트가 전체상을 의식할 수 있다
2. 발견사항을 축적한다 — 앞 에이전트의 지식이 다음의 출발점이 된다
3. 횡단적 통찰이 생긴다 — 독립 작업에서는 나오지 않는, 영역을 가로지르는 깨달음이 출현한다

화이트보드는 Agent Teams의 표준 기능이 아니라, Markdown 파일 하나로 구현 가능한 단순한 패턴입니다. 다음에 Agent Teams를 사용할 때, 리더 프롬프트에 ‘화이트보드’를 포함해보는 것도 좋을지 모릅니다.

참고문헌

• Nii, H.P. (1986). "The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures." AI Magazine, 7(2).
• Han, B. & Zhang, S. (2025). "Exploring Advanced LLM Multi-Agent Systems Based on Blackboard Architecture." arXiv.