에이전트 팀 설계: 혼자 잘하는 AI vs 함께 학습하는 AI

핵심 이슈: 에이전트는 이제 혼자 일하지 않는다

Claude Code 기반 Harness 플러그인(geeknews)과 에이전트 간 디버깅 이력 공유 실험(Prior, dev.to)이 거의 동시에 공개됐다. 표면적으로는 서로 다른 주제처럼 보이지만, 두 사례가 함께 가리키는 방향은 하나다. 에이전트를 단독 실행 단위로 설계하던 시대가 끝났다는 것. 이제 질문은 '어떤 에이전트를 쓸까'가 아니라 '에이전트들을 어떻게 팀으로 묶을까'로 바뀌었다.

맥락 해석: 두 가지 팀 설계 전략

전략 1: 역할 분담형 팀 — Harness 아키텍처

Harness 플러그인은 Claude Code의 .claude/agents/ 디렉토리에 전문 역할별 에이전트 정의 파일을 자동 생성한다. analyst.md, builder.md, qa.md 같은 파일이 각각의 에이전트 '페르소나'를 정의하고, 오케스트레이터가 태스크를 분배한다. 지원하는 아키텍처 패턴은 여섯 가지다.

• 파이프라인: 순차 의존 작업 (기술 문서 생성, 배포 흐름)
• 팬아웃/팬인: 병렬 독립 작업 (코드 리뷰—보안·성능·스타일을 동시에)
• 전문가 풀: 상황별 선택 호출
• 생성-검증: 생성 후 품질 검수
• 감독자: 중앙 에이전트가 동적 분배 (유튜브 콘텐츠 기획)
• 계층적 위임: 상위→하위 재귀적 위임 (데이터 파이프라인 설계)

실행 모드도 명확히 나뉜다. 협업이 필요한 복잡한 작업엔 TeamCreate + SendMessage 방식의 에이전트 팀을, 단발성 작업엔 서브 에이전트 직접 호출을 쓴다. 이미 10개 도메인, 100개 팀 구성 템플릿이 1,808개 마크다운 파일 형태로 공개(revfactory/harness-100)된 상태다.

이 설계의 핵심은 역할 분리다. 에이전트마다 책임 범위를 명확히 정의하고, 오케스트레이터가 태스크 흐름을 제어한다. 사람 팀에서 PM이 스프린트를 분배하는 구조와 거의 동일하다.

전략 2: 집단 학습형 팀 — Prior의 디버깅 이력 공유

Prior 실험(dev.to)은 다른 각도에서 팀 설계를 풀었다. 핵심 문제 인식은 이거다. "에이전트가 세션을 끝내면 그 안에서 얻은 지식도 함께 사라진다. 다음 에이전트는 같은 실수를 처음부터 반복한다."

Prior는 에이전트가 해결한 문제와 시도했다가 실패한 접근법을 공유 지식 베이스에 기록한다. 다음 에이전트가 동일한 에러를 만났을 때, 처음부터 디버깅하는 대신 이 베이스를 검색해서 해결책을 바로 가져간다.

실험 설계는 엄격했다. TanStack Start v1, LWJGL + Vulkan, Electron + 네이티브 모듈 등 10개 스택을 각각 두 번 빌드했다. 첫 번째(Cold) 에이전트는 Prior 없이 빌드하고 해결책을 기록했다. 두 번째(Warm) 에이전트는 같은 스펙, 같은 모델 버전으로 시작하되 첫 에이전트의 기록을 검색할 수 있었다. 두 에이전트 사이의 유일한 연결고리는 지식 베이스뿐이었다.

결과는 예상보다 훨씬 드라마틱했다.

가장 중요한 발견: 에러 후 검색이 아니라 에러 전 검색

Prior 실험에서 가장 인상적인 발견은 지표가 아니라 행동 패턴 변화였다. 연구팀은 Warm 에이전트가 에러를 만났을 때 Prior를 검색할 거라 예상했다. 실제로는 달랐다.

TanStack Start Warm 에이전트는 코드를 한 줄도 쓰기 전에 "TanStack Start v1 createServerFn setup issues"를 검색했다. 그 한 번의 검색으로 Cold 에이전트가 삽질을 통해 발견한 두 가지 API 변경 사항을 파악했고, 처음부터 올바른 패턴으로 시작했다. 에러 자체를 만나지 않았다.

반면 Nuxt 4 Warm 에이전트는 에러가 발생한 후에야 검색했다. 일부 유용한 결과를 찾았지만 여전히 5개의 에러를 만났다. "막히면 검색"이 아니라 "시작 전에 검색"이 핵심 행동 패턴이다. 이걸 에이전트 프롬프트 설계에 명시적으로 반영해야 한다.

챗봇에서 자율 에이전트로: 컨텍스트 엔지니어링의 진화

dev.to의 또 다른 사례(Trust, Philosophy, Context, Harness)는 이 흐름을 개인 워크플로우 관점에서 보여준다. 저자는 4단계 진화 경로를 직접 밟았다. 신뢰(AI를 동료로 대하기) → 프롬프트 엔지니어링(철학적 사고 틀 적용) → 컨텍스트 엔지니어링(세션 간 지식 지속성 설계) → 하네스 엔지니어링(신뢰성과 관찰 가능성을 갖춘 에이전트 시스템 구축).

주목할 건 3단계 컨텍스트 엔지니어링이다. 저자는 350개 이상의 인덱싱된 과거 발견을 시맨틱 검색으로 자동 서피싱하는 훅을 구축했다. 매 메시지마다 자동으로 실행되어 관련 결과를 컨텍스트로 주입한다. 명시적으로 요청하지 않아도. 이건 Prior의 에이전트 간 지식 공유와 구조적으로 동일한 접근이다. 한쪽은 개인 워크플로우에서, 다른 쪽은 에이전트 팀 레벨에서 같은 문제를 풀고 있다.

시사점: AI-First 팀 리더가 지금 결정해야 할 것

1. 아키텍처 패턴 선택이 설계의 시작이다

Harness가 제시한 6가지 패턴 중 어느 것도 만능이 아니다. 코드 리뷰처럼 독립적인 관점이 병렬로 필요한 작업엔 팬아웃/팬인이 맞다. 배포 파이프라인처럼 순서 의존성이 있는 작업엔 파이프라인 패턴이 맞다. 먼저 태스크의 의존성 구조를 파악하고, 그다음 패턴을 고른다. 역순으로 하면 과도한 오케스트레이션 비용을 치르게 된다.

2. 에이전트의 실패 이력을 팀 자산으로 만들어라

Prior 실험에서 가장 고무적인 결과는 Rust 프로젝트 에이전트가 기록한 Axum 라우팅 문법 수정이 나중에 완전히 다른 Rust 프로젝트 에이전트에 의해 재사용됐다는 것이다. 이건 지식 네트워크 효과다. 팀이 .claude/ 폴더에 에이전트 정의를 쌓아가는 것처럼, 에이전트가 만나는 에러와 해결책도 팀 공유 지식 베이스로 쌓여야 한다. 지금 당장 에이전트 디버깅 세션 결과를 CLAUDE.md나 별도 지식 파일에 반영하는 프로세스를 만들어라.

3. 단순함이 첫 번째 원칙이다

dev.to 저자는 32개 전문 에이전트 역할과 LangGraph 오케스트레이션 프레임워크를 모두 검토하고 거부했다. 이유는 단순하다. "아직 갖지 않은 문제를 해결하는 것들이었다." 실제로 구축한 건 프롬프트 파일 + cron + claude -p → Slack이다. Harness도 처음부터 감독자 패턴을 쓸 필요가 없다. 파이프라인 패턴으로 시작해서 병목이 생기면 확장하는 게 맞다.

전망: 에이전트 팀의 다음 전선

두 가지 진화 방향이 수렴하고 있다. Harness가 제시하는 역할 기반 분업 구조와 Prior가 실험한 세션 초월 집단 학습이다. 단기적으로는 두 접근이 별도 도구로 운용되겠지만, 중기적으로는 통합된 형태가 등장할 가능성이 높다. 에이전트가 역할을 수행하면서 동시에 팀 공유 지식 베이스에 기여하고, 다음 에이전트가 그 지식을 사전 검색으로 흡수한 뒤 태스크를 시작하는 구조.

실제로 Prior 실험에서 Prior의 가치가 집중된 영역은 명확했다. 신규 프레임워크, 비주류 스택, 트레이닝 데이터가 얇은 도구. Django나 표준 React 같은 안정된 스택에선 효과가 미미했다. 이 패턴은 팀에게 중요한 시사점을 준다. AI-First 팀이 가장 먼저 집단 지식 공유 시스템을 구축해야 할 영역은 빠르게 변하는 최신 스택과 내부 레거시 시스템이다. 모델이 모르는 영역에서 팀의 경험이 가장 강력한 자산이 된다.

에이전트는 이제 혼자 잘하는 것만으로는 부족하다. 팀으로 묶이고, 서로의 실패에서 배우고, 다음 에이전트에게 더 나은 출발점을 물려주는 구조가 진짜 경쟁력이다.