에이전트로 업무 효율 높이기 ② 총괄 하나와 역할별 담당으로 팀 나누기

먼저 결론

• 일이 늘어나면 총괄 에이전트 하나 + 역할별 담당 에이전트로 나눕니다.
• 총괄은 요청을 받아 나눠 맡기고, 진행 상황을 점검하고, 결과를 모아 보고합니다. 담당자는 자기 스킬과 권한만 가집니다.
• 담당자마다 필요한 권한만 줍니다. 업체에 연락할 일이 없는 담당자에게는 메일 권한을 주지 않습니다.
• 팀을 만든 뒤에는 그림(다이어그램)으로 그려 구조를 확인합니다.

연재 순서: ① 맡길 일을 고르고 목표·데이터·스킬 준비하기 · ② 총괄 하나와 역할별 담당으로 팀 나누기 · ③ 예약 실행으로 매일 돌리고 마지막 확인은 사람이

팀으로 나누면 지시가 짧아진다

AI로 일하다 보면 이것저것 동시에 돌리게 됩니다. 혼자 다 관리하기가 어렵습니다.

그래서 메인 에이전트 하나를 두고 서브 에이전트를 둡니다. 사람은 메인과만 이야기하고, 실제 일은 각 담당이 하며, 메인이 총괄합니다. 회사 규모가 커지면 팀장 아래 실무자를 두는 것과 같은 구조입니다.

에이전트가 혼자 다 하지 않는 방식도 같은 구조입니다. 필요한 순간에 동료 에이전트를 불러 함께 일하고, 일이 끝나면 돌려보냅니다.

팀으로 나누면 좋은 점은 세 가지입니다.

첫째, 지시가 짧아집니다. 담당자마다 자기 일의 스킬이 있으니 총괄에게는 "숙소 견적 세 곳 비교해 줘" 한 마디면 됩니다.

둘째, 권한을 좁힐 수 있습니다. 업체에 견적을 요청하는 메일 권한은 견적 담당에게만, 일정표 작성 스킬은 기획 담당에게만 줍니다.

셋째, 문제가 생긴 곳을 찾기 쉽습니다. 일정이 이상하면 행사기획 담당의 스킬만, 금액이 이상하면 견적 담당의 스킬만 고치면 됩니다.

사례 A. 결정은 사람이, 점검은 팀장 에이전트가

실적 우수자를 위한 회사 프로모션 여행을 준비한다고 가정하고 에이전트 팀을 짜 보겠습니다. 일정, 행사, 숙소·항공·버스·식당 견적이 동시에 움직이고, 결정할 사람은 따로 있는 전형적인 일입니다.

팀은 셋으로 나눴습니다.

실제 흐름은 이렇습니다.

1. 사람이 팀장에게 말한다. "11월 둘째 주, 40명, 2박 3일 국내 여행으로 준비해. 예산은 1인당 얼마 이내."
2. 팀장이 진행 항목을 만든다. 일정 확정, 이벤트 기획, 항목별 견적, 참가자 안내 같은 항목에 담당과 마감일을 붙인다.
3. 행사기획 담당이 일자별 일정표와 이벤트 안을 두세 가지 만든다.
4. 행사견적 담당이 그 일정에 맞춰 업체별 견적 요청 메일 초안을 쓴다. 사람이 확인하고 보내면, 받은 견적을 항목별 비교표로 정리한다.
5. 팀장이 매일 진행 항목을 점검한다. "숙소 견적 3곳 중 2곳 도착, 버스 견적 미도착, 일정안 B가 예산 초과" 처럼 끝난 것·남은 것·막힌 것을 나눠 보고한다.
6. 사람은 보고를 보고 일정안과 업체만 결정한다.

포인트는 결정은 사람이, 정리와 점검은 에이전트가 맡는다는 것입니다. 특히 팀장의 진행 점검이 핵심입니다.

담당이 셋만 돼도 누가 어디까지 했는지 사람이 챙기기 어렵습니다. 팀장이 진행 항목 표를 기준으로 매일 확인하니 빠지는 일이 줄어듭니다.

실무 팁도 몇 가지 있습니다. 평소 업무에는 가장 비싼 모델보다 한 단계 아래 모델로도 충분합니다(예: Opus 대신 Sonnet). 기획처럼 판단이 많은 담당에만 높은 모델을 씁니다.

견적 요청처럼 회사 밖으로 나가는 메일은 처음에는 초안까지만 맡깁니다. 금액과 인원이 틀린 메일이 업체로 나가면 되돌리기 어렵습니다.

진행 항목 표는 팀원 모두가 같은 파일을 보게 합니다. 담당마다 따로 메모하면 팀장이 점검할 기준이 사라집니다.

사례 B. 잘 된 작업 하나에서 팀을 뽑아냈다

이번에는 VS Code 안에서 Claude Code로 보고서를 만드는 팀입니다. 결과는 내 PC 폴더에 저장하고 보고는 텔레그램으로 받습니다. 결과 파일은 회사 밖으로 나가지 않고, 나는 휴대폰으로 끝났다는 소식과 요약만 받는 구조입니다.

만드는 순서는 이렇습니다.

1. 에이전트 하나에게 먼저 시켜 본다. 예를 들어 "이번 주 실적 엑셀을 읽어 본부별 요약 보고서를 만들고 보고서/2026-10-4주.md로 저장해 줘." 보고서 형식(결론 먼저, 표는 5줄 이내)도 이때 정한다.
2. 결과가 잘 나오면 팀과 지침으로 만든다. "세션이 끝나도 이 작업을 다시 잘할 수 있도록 지침과 에이전트 팀을 구성해 줘"라고 요청하면, 작업 폴더에 지침 파일과 에이전트 정의 파일이 생긴다. 예를 들면 자료 읽기 담당, 보고서 작성 담당, 검토 담당 셋이다.
3. 저장 규칙을 지침에 적는다. 저장 폴더, 파일 이름 규칙(날짜 포함), 원본 파일은 고치지 않고 사본으로 작업한다는 것까지 적는다.
4. 텔레그램 보고를 붙인다. 텔레그램에서 봇을 만들어 받은 토큰은 PC의 설정에만 두고, 작업이 끝나면 봇이 세 가지를 보내게 한다.
   • 보고서 요약 3줄
   • 저장한 파일 위치
   • 확인한 것과 확인 못 한 것
5. 같은 지침으로 다시 돌려 본다. 결과를 지우고 새 세션에서 "이 지침과 팀을 써서 다시 해 줘"라고 하면, 거의 같은 보고서가 같은 폴더에 저장되고 같은 형식의 텔레그램 보고가 온다.

요점은 텔레그램에 보고서 원문을 보내지 않고 요약과 위치만 보내는 것입니다. 회사 자료는 PC에 남기고, 메신저에는 "끝났다, 어디 있다, 무엇을 확인해야 한다"만 갑니다.

저도 이 블로그에 에이전트가 글을 올리면 텔레그램으로 알림과 발행 버튼을 받습니다. 컴퓨터 앞에 없어도 결과가 나왔는지 바로 알 수 있습니다.

사례 A가 처음부터 역할을 설계하는 방식이라면, 사례 B는 잘 된 작업에서 팀을 뽑아내는 방식입니다. 처음 시작하는 분에게는 B가 더 쉽습니다.

무엇을 나눠야 할지 모를 때는 일단 한 번 해 봅니다. 그다음 에이전트에게 나누게 하면 됩니다.

에이전트가 늘면 그림으로 그려 봐야 보인다

에이전트가 여러 개가 되면 누가 무엇을 하는지 헷갈립니다. 팀을 다 만든 뒤에는 Claude의 다이어그램 스킬로 현재 작업 공간의 구조를 그림으로 그려 달라고 요청합니다.

처음 그림이 어려우면 고쳐 요청합니다. "역할은 나뉘어 있지만 결과는 같은 폴더에 쌓이고 보고는 텔레그램으로 간다는 점이 보이게 다시 그려 줘" 같은 식입니다.

이 방법은 내가 만든 시스템뿐 아니라 낯선 업무나 서비스를 빠르게 파악할 때도 씁니다. 예를 들어 이커머스 고객 상담 체계를 조사해 문의 유형별 흐름을 그림으로 정리할 수 있습니다.

검토 담당은 만든 담당과 분리해야 했다

저는 Claude Code로 업무 도구를 만들 때 비슷한 구조를 씁니다. 큰 작업은 조사, 구현, 검토를 다른 에이전트에게 나눠 맡기고, 저는 총괄 에이전트와만 이야기합니다.

써 보며 정한 첫 규칙은 검토 담당을 만든 담당과 분리하는 것입니다. 자기가 만든 결과를 스스로 검토하면 놓치는 것이 많았습니다.

업무 도구를 만들 때 다른 AI 도구에 코드 점검을 맡긴 적이 있습니다. 문제 7건이 나왔습니다. 저는 그대로 고치지 않고 "무조건 수용하지 말고 코드로 확인해서 우선순위를 다시 정해 줘"라고 했습니다.

7건 모두 사실이었습니다. 다만 당시 실제로 열려 있는 위험은 한 건뿐이라는 판단이 나왔고, 그것부터 막았습니다. 과한 제안 몇 가지는 근거와 함께 하지 않기로 했습니다.

둘째, 총괄에게 "결과만 보고해"라고 하지 않습니다. "확인한 것과 확인 못 한 것을 나눠 보고해"라고 지시합니다. 이 한 줄로 "다 됐다는데 안 되는" 일이 줄었습니다.

셋째, 외부로 나가는 동작(메일 발송, 글 공개, 배포)은 사람 승인 뒤에 합니다. 업체나 고객에게 바로 가는 결과물은 처음 몇 주 동안 발송 전에 한 번 보는 편이 안전합니다.

넷째, 같은 폴더를 두 에이전트가 동시에 고치지 않습니다. 다른 세션에서 이 사이트를 크게 바꾸는 작업이 진행 중일 때가 있었습니다. 그때 작은 수정은 별도 작업 폴더(git worktree)를 만들어 따로 했습니다. 서로의 미완성 작업이 섞여 배포되는 일을 막을 수 있었습니다.

최근에 이 사이트의 프로젝트 소개 여섯 개를 채울 때도 이 구조로 일했습니다. 프로젝트마다 작업 폴더와 기록이 따로 있어서, 조사 담당 에이전트 여섯에게 하나씩 맡겨 동시에 읽게 했습니다. 담당에게 준 규칙은 네 가지였습니다.

1. 읽기만 하고 아무것도 고치지 않는다.
2. 주장마다 근거 파일을 적는다.
3. 확인 못 한 것은 "확인 못 함"으로 적는다.
4. 회사명·실명은 값을 적지 말고 종류만 보고한다.

총괄은 보고를 모아 소개 글을 쓰고, 다시 읽으면서 근거보다 앞서 나간 문장을 고쳤습니다. 예를 들어 문서에 없는 "그동안 손으로 하느라 불편했다" 같은 문장은 "~하려고 만들었다"로 낮췄습니다.

여섯 곳 조사가 동시에 끝났습니다. 무엇이 확인된 사실이고 무엇이 확인 못 한 것인지도 분명하게 남았습니다.

역할을 나눌 때 먼저 정할 것은 누가 결정하고 누가 점검하는지였습니다.

다음 편에서는 이렇게 만든 팀이 사람이 말하지 않아도 매일 돌아가게 하는 방법과, 결과를 믿고 쓸 수 있게 만드는 확인 장치를 정리합니다.