클로드 코드 서브에이전트 vs 에이전트 팀 비교: 컨텍스트 관리와 실제 작업 성능 실험

핵심 메시지

• 작업이 커질수록 문제는 컨텍스트 창이다. 한도를 넘지 않아도 창이 차오르면 성능이 떨어지는 현상이 관찰된다.
• 서브에이전트는 새 인스턴스에 일을 떼어 주는 방식으로, 결과만 주 에이전트에 보고돼 컨텍스트를 아낀다.
• 에이전트 팀은 서브에이전트들이 공유 작업 목록을 직접 갱신하고 서로 대화할 수 있게 해 이 병목을 완화한다.
• 세 가지 작업 실험에서 팀은 대체로 빨랐지만 토큰을 더 썼고, 결과 품질은 서브에이전트가 일관되게 나았다.
• 진행자는 품질 차이의 원인을 구조 자체보다 아직 실험 단계인 기능의 미성숙에 있다고 봤다.

쉽게 이해하기

클로드 코드를 뜯어 보면 두 축으로 나뉜다. 요청을 받아 답을 만드는 언어 모델과, 그 모델을 둘러싼 도구와 기능들이다. 로컬 파일 접근, 웹 검색, 터미널 명령 실행, 이전 대화 압축, 작업 목록 작성처럼 모델 바깥에 붙은 장치가 실제 작업 능력을 만든다. 그러나 하나의 에이전트에 복잡한 일을 몰아주면 한계가 드러난다.

그 한계의 이름이 컨텍스트다. 시스템 메시지, 사용하는 도구 정보, 사용자 요청, 추론 흔적, 도구 호출과 그 결과가 모두 같은 창에 쌓인다. 한도를 넘으면 정보가 아예 전달되지 않고, 넘지 않아도 창이 절반을 넘어 차오를 무렵부터 성능이 떨어지는 '컨텍스트 부패' 현상이 관찰된다. 그래서 어떤 정보를 언제 창에 올릴지 관리하는 일이 중요해진다.

서브에이전트는 이 문제를 위임으로 푼다. 주 에이전트가 작업의 일부 또는 전부를 새로 띄운 클로드 코드 인스턴스에 넘기고, 그 인스턴스는 일을 마친 뒤 결과만 보고한다. 조사처럼 토큰을 많이 먹는 작업에서 특히 효과가 큰데, 검색 과정의 잡음이 주 에이전트의 창에 들어오지 않기 때문이다. 기본으로 제공되는 것도 몇 가지 있고, 직접 만들 수도 있다.

다만 서브에이전트에도 병목이 남는다. 모든 정보가 주 에이전트를 거쳐야 하므로 서브에이전트끼리 직접 대화할 수 없고, 결국 주 에이전트의 컨텍스트 문제도 되돌아온다. 에이전트 팀은 공유 작업 목록을 두고 각 에이전트가 직접 작업을 가져가고 완료 표시를 하며 서로 이야기하도록 만들어 이 지점을 완화한다. 대신 구조가 복잡해지고 잘못된 정보가 서로 번질 위험이 생긴다.

진행자는 두 방식을 세 작업에 붙여 비교했다. 지역 중견기업 연락처 50건 정리, 유튜브 재생목록을 강의처럼 보여 주는 웹 앱 만들기, 그리고 랜딩 페이지 설계와 문구 작성이다. 시작 문구는 에이전트 팀을 쓰라고 지시한 첫 줄만 빼고 동일하게 맞췄고, 비용을 아끼기 위해 작업마다 한 번씩만 실행했다.

주요 인사이트

• 연락처 정리 작업에서 팀은 8분 빨랐고 토큰을 약 3만 더 썼다. 그런데 50건 가운데 이메일을 채운 것은 8건뿐이었고, 서브에이전트 방식은 전원의 이메일을 채웠다. 빠른 완료가 좋은 완료는 아니었다.
• 웹 앱 만들기처럼 병렬로 쪼개기 어려운 작업에서는 팀을 띄워도 각 에이전트가 앞 단계에 막혀 순차 실행됐다. 구조를 병렬로 만들어도 작업의 성질이 순차라면 시간 이득이 나오지 않는다.
• 랜딩 페이지에서는 결과가 갈렸다. 디자인과 자주 묻는 질문 구성은 서브에이전트가 나았고, 문구 자체는 팀이 나았다. 팀이 배경과 문구 작성 관행을 더 오래 조사한 것이 원인으로 지목됐다.
• 토큰 증가폭은 예상보다 작았다. 진행자는 두세 배를 예상했지만 실제로는 소폭 증가에 그쳤다.
• 선택 기준은 단순하다. 순차적으로 이어지는 작업에는 서브에이전트가, 병렬로 쪼갤 수 있는 작업에는 에이전트 팀이 어울린다. 서브에이전트 구조는 잘못된 결과가 주 에이전트에서 한 번 검토되므로 실수가 번지지 않지만, 팀은 오류가 서로에게 전파될 수 있다.

자주 묻는 질문

관련 AI 소식