바이너리를 뜯어본 개발자
2025년 12월 18일, 개발자 Mike Kelly가 자기 컴퓨터에 설치된 Claude Code 바이너리를 뜯어봤다. strings 명령어로 실행 파일 안의 문자열을 추출하는, 개발자라면 한 번쯤 해봤을 법한 호기심이었다.
strings ~/.local/share/claude/versions/2.1.29 | grep TeammateTool
결과가 나왔다. TeammateTool, TeamCreate, SendMessage. 아직 공개되지 않은 기능의 흔적이 바이너리 안에 고스란히 남아 있었다. Kelly가 이 발견을 Hacker News에 올리자 281포인트에 207개 댓글이 달렸다. "Claude Code가 멀티 에이전트를 준비하고 있다"는 소문이 개발자 커뮤니티에 빠르게 번졌다.
한 달 뒤, paddo.dev의 기술 블로그가 더 깊이 파고들었다. 바이너리에서 13개의 TeammateTool 오퍼레이션을 찾아내 문서화했다. 팀 생성, 태스크 관리, 에이전트 간 메시지 전송까지. 완성된 협업 프로토콜이 코드 안에 이미 들어 있었다.
2026년 2월, Anthropic이 Claude Opus 4.6과 함께 이 기능을 "Agent Teams"라는 이름으로 공식 출시했다. 바이너리에 숨겨져 있던 것이 정식 기능이 되기까지 약 두 달. 아직 experimental 태그가 붙어 있다.
에이전트 하나의 한계
LLM에는 피할 수 없는 약점이 있다. 컨텍스트 윈도우가 길어질수록 성능이 떨어진다. 컨텍스트 윈도우란 AI가 한 번에 읽고 처리할 수 있는 텍스트의 양인데, 여기에 정보가 쌓일수록 모델은 초반 내용을 놓치거나 지시를 무시하는 빈도가 높아진다. 모델을 아무리 키워도 이 문제는 근본적으로 해결되지 않는다고 Google의 Addy Osmani도 지적한 바 있다.
혼자 일하는 에이전트는 이 약점에 정면으로 부딪힌다. 코드를 읽고, 분석하고, 수정하고, 테스트하는 모든 과정이 하나의 컨텍스트 윈도우 안에서 벌어진다. 프로젝트가 커지면 컨텍스트도 커지고, 에이전트는 점점 멍해진다. 시험 범위가 넓어질수록 벼락치기 효율이 떨어지는 것과 비슷하다.
Claude Code에는 이미 "subagent"라는 우회로가 있었다. 메인 에이전트가 하위 에이전트를 불러 특정 작업을 맡기고 결과만 받아오는 방식이다. 부모가 아이에게 심부름을 시키는 구조라고 보면 된다. 그런데 subagent는 부모에게만 보고할 수 있다. 하위 에이전트끼리는 서로의 존재조차 모른다.
Agent Teams는 여기서 한 걸음 더 나간다. 부모-자식이 아니라 팀 리더와 팀원의 구조다.
첫째, 공유 태스크 리스트가 있다. 모든 팀원이 같은 태스크 목록을 보고 의존성을 추적하고 완료 상태를 업데이트한다. 누가 뭘 하고 있는지 팀 전체가 안다.
둘째, 메일박스가 있다. 팀원끼리 직접 메시지를 주고받을 수 있다. 프론트엔드 담당 에이전트가 백엔드 담당에게 "이 API의 응답 형식이 뭐야?"라고 직접 물을 수 있다. subagent 구조에서는 불가능했던 일이다.
| 항목 | Subagent (기존) | Agent Teams |
|---|---|---|
| 구조 | 부모-자식 (트리형) | 팀 리더-팀원 (플랫) |
| 통신 | 부모에게만 보고 | 팀원 간 직접 메시지 |
| 작업 관리 | 메인 에이전트가 전부 관장 | 공유 태스크 리스트로 자율 조율 |
| 컨텍스트 | 부모 컨텍스트에 결과 요약 반환 | 각 팀원이 독립 컨텍스트 유지 |
| 적합한 작업 | 결과만 필요한 단순 위임 | 논의와 협업이 필요한 복합 작업 |
결국 "더 똑똑한 AI"가 아니라 "분업"이라는 오래된 답이다. 한 에이전트가 모든 걸 기억하려 하지 않고, 각자 맡은 영역만 깊이 판다. 인간 조직이 복잡한 문제를 풀어온 방식 그대로다.
이 블로그가 바로 Agent Teams 산출물이다
지금 읽고 있는 이 글은 Agent Teams로 만들어지고 있다. 과장이 아니다. dainus.ai 블로그 시스템은 6단계 에이전트 파이프라인으로 돌아간다.
Scout가 웹을 뒤져 주제 관련 최신 자료를 모은다. Analyst가 그 자료를 분석해서 글의 뼈대와 핵심 논점을 설계한다. Draft-Writer가 초안을 쓴다(바로 이 단계다). Korean-Polish가 번역체와 상투어를 걷어내고 한국어 문장 품질을 끌어올린다. Visual이 인포그래픽을 만든다. 마지막으로 DB 에이전트가 Neo4j 그래프 데이터베이스에 메타데이터를 저장한다.
이 구조를 만드는 데 필요한 건 두 가지뿐이다.
먼저, 환경변수 하나를 켠다.
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
그다음, CLAUDE.md 파일에 각 에이전트의 역할과 작업 규칙을 적어둔다. CLAUDE.md는 Claude Code가 프로젝트에 진입할 때 가장 먼저 읽는 설정 파일이다. "Scout는 Perplexity API로 리서치한다", "Draft-Writer는 이런 원칙으로 글을 쓴다", "Korean-Polish는 번역체를 근절한다"고 적어두면, 팀 리더가 이 지시를 각 팀원에게 전달한다.
이 시스템이 만드는 실질적 차이는 "컨텍스트 분리"에서 나온다. Scout가 수집한 자료는 Scout의 컨텍스트 안에서 정리되고, 정제된 결과물만 파일로 넘어간다. Draft-Writer는 리서치 과정의 시행착오를 알 필요가 없다. 자기 앞에 놓인 정리된 자료만 보고 글을 쓴다. 각 단계가 깨끗한 컨텍스트 윈도우에서 시작하니, 앞 단계의 잡음이 다음 단계를 오염시키지 않는다.
이걸 에이전트 하나가 전부 하면 어떻게 될까? 리서치 결과와 글쓰기 원칙과 한국어 교정 규칙이 전부 하나의 컨텍스트에 쌓인다. 글이 후반부로 갈수록 초반의 지시를 잊기 시작한다. 분량이 길어지면 할루시네이션, 그러니까 사실이 아닌 내용을 자신 있게 서술하는 현상도 늘어난다. 에이전트를 나누는 것만으로 이 문제가 상당 부분 해소된다.
팀 리더에게 "블로그 초안을 작성해줘"라고 한 마디 하면, 리더가 Scout를 띄우고, Scout 결과를 Analyst에게 넘기고, Analyst 결과를 Draft-Writer에게 넘기는 과정이 자동으로 흘러간다. 중간에 Shift+Down으로 각 팀원의 작업 상태를 직접 확인할 수도 있다.
비용은 얼마나 드는가
Hacker News에서 가장 많이 나온 반응은 "비용"이었다. 한 댓글이 핵심을 찔렀다. "이미 비싼 AI를 for 루프에 넣는 것."
틀린 말은 아니다. Agent Teams는 각 팀원이 독립된 Claude 인스턴스를 돌린다. 팀원 6명이 각자 컨텍스트를 유지한다는 건 토큰 소비가 6배 가까이 늘어날 수 있다는 뜻이다. 커뮤니티에서 레거시 Java를 C# .NET으로 포팅한 사례가 있었는데, 9개 에이전트(Manager, Product Owner, Scrum Master, Architect 등)를 운영한 결과 "최고 품질 코드"를 얻었지만 비용은 단일 에이전트의 10배였다.
그런데 비교 대상을 바꾸면 계산이 달라진다. 시니어 개발자 6명이 일주일 걸릴 작업을 에이전트 팀이 몇 시간 만에 끝냈다면, 토큰 비용 수십 달러는 인건비에 비하면 작다. 물론 "에이전트 팀이 정말 그 품질을 내느냐"가 관건이고, 이건 작업 종류에 따라 갈린다.
Agent Teams가 빛나는 경우는 분명하다. 독립적인 작업을 병렬로 돌릴 수 있을 때다. 보안, 성능, 테스트를 각각 전담 리뷰어에게 맡기는 코드 리뷰. 프론트엔드와 백엔드를 동시에 짜는 기능 개발. 여러 가설을 한꺼번에 검증하는 디버깅. 이런 경우에는 분업의 효율이 비용을 상쇄한다.
반대로, 순차적으로 진행해야 하는 작업이나 강하게 엮인 코드를 고치는 경우에는 오히려 비효율적이다. 팀원끼리 같은 파일을 동시에 건드리면 덮어쓰기 충돌이 난다. 에이전트가 잘못된 방향으로 달려가는 것을 사람이 잡아주지 않으면, 여러 에이전트가 동시에 잘못된 방향으로 질주하는 결과가 나온다.
Addy Osmani가 짚은 경고 하나. "activity ≠ value." 에이전트 6개가 바쁘게 돌아간다고 가치 있는 결과물이 나오는 건 아니다. 토큰을 태우는 것과 문제를 해결하는 것은 다르다. "이 작업에 팀이 필요한가, 혼자로 충분한가"를 판단하는 건 여전히 사람의 몫이다.
기술적 한계도 짚어야 한다. 세션이 끊기면 팀을 복원할 수 없다(/resume이 팀원에게는 작동하지 않는다). 세션당 팀 하나만 운영할 수 있고, 팀 안에서 또 다른 팀을 만드는 중첩도 안 된다. Split pane 모드는 tmux나 iTerm2에서만 작동하며, VS Code 터미널이나 Windows Terminal에서는 지원하지 않는다.
코딩 에이전트, 개인에서 조직으로
Claude Code만 이 방향으로 가는 건 아니다. GitHub은 Agent HQ를 통해 Copilot, Claude, Codex를 하나의 허브에서 동시에 운영하는 구조를 만들고 있다. Google은 Antigravity라는 Agent-First IDE를 준비 중이다. Devin은 아예 자율 소프트웨어 엔지니어를 표방한다.
코딩 에이전트가 "개인 비서"에서 "프로젝트 팀"으로 바뀌는 흐름은 뚜렷하다. Claude Code Agent Teams는 이 전환의 첫 네이티브 구현이다. 별도 도구나 오케스트레이션 프레임워크 없이, 터미널 안에서 자연어 한 마디로 팀을 꾸릴 수 있다.
다만 지금은 시작이지 완성이 아니다. experimental 태그가 붙어 있는 데는 이유가 있다. 멀티 에이전트 협업이 단일 에이전트보다 일관되게 나은 조건이 뭔지, 비용 균형점은 어디인지, 사람의 감독은 어느 수준이 적절한지. 이 질문들에 대한 답은 아직 커뮤니티가 실험을 통해 찾아가는 중이다.
에이전트 하나의 컨텍스트 윈도우 안에서 모든 걸 해결하려는 시대는 끝나가고 있다. 그 다음이 "팀"인지, 또 다른 형태인지는 지금 이 도구를 직접 써보는 사람들에게 달려 있다.