AI 에이전트는 부서별로 만드는 게 아닙니다

한줄 요약: 에이전트로 가상 오피스를 꾸리는 것이 중요한 게 아닙니다. 누가 계획하고 누가 실행하는지 정하지 않고 조직도만 옮기면 정보가 샙니다. 메인 에이전트 하나에 스킬을 붙이고, 서브에이전트는 아래 네 경우에 맞을 때만 둡니다.

목차

1. 조직도를 옮긴 에이전트에서 생기는 일
2. 메인 에이전트 하나에 스킬을 붙이기
3. 서브에이전트를 따로 둘 4가지 경우
4. 필자는 담당 에이전트를 이렇게 나눠 씁니다
5. 나눌지 합칠지는 채점해 보고 정하기

1. 조직도를 옮긴 에이전트에서 생기는 일

에이전트 홍보를 보면 가상 오피스 화면이 자주 나옵니다. 영업, 분석, 마케터 에이전트를 하나씩 만들고, 그 위에 일을 나눠 주는 관리자 에이전트를 둡니다. 회사 조직도를 그대로 옮기니 1인 창업을 한 것 같은 만족감이 듭니다.

그런데 이 구조가 정말 효과가 있을까요? 앤트로픽은 2026년 10월 22일 「Building agents: When to fold subagents into your main agent loop」를 공개했습니다. 기업들이 팀마다 서브에이전트를 하나씩 주다 보니 에이전트 구조가 조직도의 복사본이 되어 간다는 내용입니다.

예를 들어 관리자 에이전트가 “A사 제안서를 써 달라”는 일을 셋에게 나눠 주면, 각자 자기 몫의 요약만 돌려줍니다. 분석 에이전트가 찾은 “A사 작년 예산 삭감” 한 줄이 요약에 못 들면 최종 제안서에서 빠집니다. 앤트로픽은 이 현상을 귓속말로 말을 전하다 내용이 바뀌는 전화 게임에 빗댔습니다.

2. 메인 에이전트 하나에 스킬을 붙이기

처음부터 메인 에이전트 하나가 계획을 세우고, 일마다 맞는 스킬을 꺼내 쓰면 됩니다. 한 에이전트가 같은 맥락을 보니 넘기다 빠지는 정보가 없고, 계획이 틀렸으면 그 자리에서 고칩니다.

• 두 구조를 비교한 고객사 한 곳에서는 하나로 돌린 쪽이 약 2배 빨랐습니다.
• 앤트로픽은 성능이 높은 모델용 클로드 코드 시스템 프롬프트를 80% 넘게 줄였습니다. 스킬과 도구를 필요할 때만 읽게 한 조치도 여기에 포함됩니다.

3. 서브에이전트를 따로 둘 4가지 경우

앤트로픽도 서브에이전트를 버리라고 하지는 않았습니다. 쓸 때를 세 조건으로 들었는데, 셋째 조건(도구 선택 또는 지시 충돌)을 둘로 나눠 보면 네 경우입니다.

경우	한 줄 설명
맥락 비대	쌓인 대화와 자료 때문에 성능 저하가 측정됨
병렬 작업	서로 기다리지 않는 일을 새 맥락으로 동시에 처리
도구 선택	도구가 많아 맞는 도구를 잘 못 고름
지시 충돌	시스템 프롬프트의 규칙끼리 부딪침

맥락 비대: 쌓인 자료에 눌려 답이 나빠질 때

에이전트 하나에 대화, 자료, 중간 결과가 계속 쌓이면 앞에서 받은 지시를 놓치기 쉽습니다. 계약서 수백 쪽을 한 에이전트가 다 읽고 요약까지 하는 일이 그렇습니다.

• 나누기 전에: 스킬과 도구를 필요할 때만 읽게 합니다. 앤트로픽은 이 방식이 팀들이 서브에이전트로 나누던 주된 이유를 없앤다고 썼습니다.
• 그래도 나빠지면: 서브에이전트가 자료를 읽고 짧은 결과만 돌려주게 합니다. 기준은 느낌이 아니라 측정된 성능 저하입니다.

병렬 작업: 서로 기다리지 않는 일을 동시에 할 때

기사 세 편을 기자 셋이 나눠 쓰면 일찍 끝납니다. 경쟁사 세 곳을 따로 조사하는 일도 같습니다. 서브에이전트마다 새 맥락으로 시작하고, 일이 끝나면 그 맥락은 버립니다.

• 잘 맞는 일: 서로 독립된 조사, 경계가 분명한 별개 작업
• 맞지 않는 일: 앞 단계 결과를 이어받는 일. 앤트로픽은 이런 에이전트는 오히려 합칠 후보라고 했습니다.

도구 선택: 도구가 많아 고르기를 헷갈릴 때

메일, 캘린더, 고객 관리, 회계 시스템마다 도구를 하나씩 붙이면 도구 수가 금방 늘어납니다. 앤트로픽은 시스템 프롬프트의 도구 정의가 30개에서 50개를 넘으면 도구 선택이 나빠지기 쉽다고 썼습니다.

• 나누기 전에: 도구를 시스템마다가 아니라 사용자가 하려는 일별로 묶고, 필요할 때 찾아 불러오게 합니다.
• 그래도 맞는 도구를 못 고르면: 그 도구 묶음을 쓰는 서브에이전트를 따로 둡니다.

지시 충돌: 규칙끼리 부딪칠 때

팀마다 시스템 프롬프트에 한 줄씩 보태면 규칙이 서로 부딪치고 말투가 흔들립니다. 보고서는 존댓말로, 메신저는 반말로 쓰라는 규칙을 한 에이전트에 모두 주면 보고서에 반말이 섞여 나옵니다.

• 나누기 전에: 작은 중앙 팀 하나가 시스템 프롬프트를 맡아, 새 규칙이 들어오기 전에 검토합니다.
• 그래도 한 프롬프트에 담을 수 없으면: 규칙이 다른 쪽을 서브에이전트로 나눕니다.

4. 필자는 담당 에이전트를 이렇게 나눠 씁니다

저도 고객(영업과 컨설팅), 콘텐츠, 마케팅, 분석, 세무, 개발 여섯 담당을 에이전트로 둡니다. 다만 담당을 부르는 기준은 부서가 아니라 일의 길이입니다.

구성 요소	맡는 일
메인 대화	담당 고르기, 브리핑 작성, 결과 전달, 사람 승인 받기
담당 에이전트 6개	담당별 정의 문서를 읽고 초안 작성, 사람 답을 받아 이어 쓰기
검수 에이전트	블로그, Threads, 강의 자료 등 산출물별 검토. 만든 쪽과 다른 맥락
업무 보드	담당끼리 넘기는 일과 사람 확인을 기다리는 일의 기록

• 발송, 발행, 결제, 배포 같은 사람 몫은 담당 에이전트가 하지 않습니다. 메인 대화가 제게 승인을 받아 처리합니다.
• 영업 담당과 컨설팅 담당은 원래 따로였습니다. 같은 고객 건을 번갈아 고치며 일정 변경과 납품 확인이 둘 사이를 오가서, 같은 평가 문제로 비교한 뒤 하나로 합쳤습니다. 품질과 비용은 같았고 넘기는 문서가 줄었습니다.
• 맞는 담당이 없는 일은 범용 에이전트에 넘기지 않고 메인 대화가 직접 합니다. 같은 모델에 브리핑만 한 번 더 끼기 때문입니다.

넘기다 정보가 새지 않게 하는 규칙

전화 게임을 막으려고 넘기는 자리마다 규칙을 둡니다.

넘기는 자리	규칙
메인에서 담당으로	사용자 입력은 요약 없이 원문 그대로, 기준 문서는 경로로, 이미 정한 사실과 금지 사항 명시
사람 답을 받은 뒤	새 에이전트 대신 같은 에이전트를 이어서 호출
담당에서 메인으로	정의에 없어 스스로 판단한 것을 따로 보고
담당에서 담당으로	업무 보드의 건 번호와 그 행 원문 전달
결과를 사람에게	메인 대화가 산출물을 직접 열어 본 뒤 전달

사람과 함께 보는 업무 보드

담당끼리 주고받는 일은 구글 시트 한 장(work-pending)에 모읍니다. 에이전트는 이 시트를 읽고 쓰고, 저는 같은 시트를 눈으로 봅니다.

• 대기 탭은 회신을 기다리거나, 제가 처리하거나, 다른 담당에게 넘긴 일입니다.
• 건 탭은 외부와 맺은 약속 하나가 한 줄이고, 담당이 넘길 일을 여기에 적습니다.
• 매일 아침 대조 작업이 메일, 캘린더, 슬랙과 시트를 비교해 빠진 사실을 기록 탭에 쌓습니다.

5. 나눌지 합칠지는 채점해 보고 정하기

나눌지 합칠지는 느낌으로 정하지 않습니다. 앤트로픽은 두 구조를 같은 문제로 채점해 보고 정하라고 권했습니다. 채점용 모범 답안은 10개로도 시작할 수 있다고 했습니다.

• 자주 들어오는 요청을 10개 적고, 좋은 답이 갖출 것을 채점 기준표(루브릭)로 붙입니다.
• 함께 돌아가는 에이전트 연결과 꼭 지킬 규칙마다 문제를 하나씩 넣습니다.
• 합친 구조와 나눈 구조에 같은 문제를 여러 번 풀게 합니다.
• 총점만 보지 말고 통과하던 문제 가운데 실패로 바뀐 것을 봅니다.
• 답만 보지 말고 맞는 스킬과 도구를 불렀는지도 봅니다.