화면 속 AI 사무실에서 에이전트들이 각자의 자리를 차지하고 있습니다. 누군가는 자료를 찾고 누군가는 글을 쓰고 누군가는 결과를 검토합니다. 작업이 전달될 때마다 상태가 바뀌고 작은 캐릭터들이 움직입니다. 보고 있으면 작은 팀 하나가 내 일을 대신하고 있다는 느낌이 듭니다.
AI사무실 예시
그런데 그 장면을 보다 보면 문득 이런 생각도 듭니다. 이건 일을 더 잘하기 위해 만든 사무실일까요? 아니면 예전에 싸이월드 미니룸을 꾸미던 것처럼, 나만의 공간과 조직을 만들어 보는 재미에 가까울까요?
물론 둘 다일 수 있습니다. 재미있게 만든 도구가 실제로 유용할 수도 있죠. 다만 화면을 꾸미는 즐거움과 업무가 줄어드는 효과는 따로 확인할 필요가 있습니다. 에이전트들이 바쁘게 움직이는 모습만으로는 내 일이 얼마나 줄었는지 알 수 없으니까요.
이번 글에서는 AI 사무실과 멀티 에이전트 오케스트레이션이 어떤 상황에서 도움이 되는지, 실제 공개 사례에서는 무엇이 달랐는지, 그리고 우리는 무엇을 기준으로 그 필요성을 판단해야 하는지 이야기해 보려고 합니다.
자, 시작할게요!
내가 만든 작은 회사가 생긴다는 즐거움
AI 사무실이 흥미로운 이유는 이해할 수 있습니다.
채팅창에 질문하고 답변을 받는 것과 내가 구성한 팀이 역할을 나눠 일하는 모습을 보는 것은 느낌이 다릅니다. 기획 담당이 있고 개발 담당이 있고 검토 담당이 있습니다. 이름을 붙이고 자리를 배치하면 추상적이던 AI가 조금 더 구체적인 존재처럼 느껴집니다.
싸이월드 미니룸도 그랬습니다. 가구를 놓고 벽지를 바꾸고 미니미를 배치하면서 내 공간을 만들었습니다. 현실의 일을 처리해 주는 공간은 아니었지만 꾸미고 보여 주는 과정만으로 충분히 재미있었죠.
AI 사무실에도 그런 즐거움이 있을 수 있습니다. 내 취향대로 팀을 구성하고 작업 방식을 정하고 그 안에서 무언가가 돌아가도록 만드는 재미입니다. 혼자 일하더라도 작은 조직을 운영하는 듯한 기분을 느낄 수 있고요.
이것만으로도 실험할 이유는 있습니다. 취미로 만들 수도 있고 에이전트의 작동 방식을 익히는 학습 도구로 사용할 수도 있습니다. 모든 시도가 당장 돈을 벌거나 시간을 아껴 줘야 하는 것은 아닙니다.
다만 "재미있어서 만들었다"와 "이렇게 해야 일이 더 잘된다"는 서로 다른 주장입니다.
앞의 말은 취향과 경험에 관한 이야기입니다. 뒤의 말에는 비교할 수 있는 결과가 필요합니다. 한 에이전트로 처리했을 때보다 무엇이 나아졌는지 살펴봐야 하죠.
누군가의 화면만 보고 그 사람이 재미를 위해 만들었는지, 효율을 위해 만들었는지 단정할 수는 없습니다. 내가 도입할 때는 질문해 볼 수 있습니다.
나는 지금 어떤 즐거움을 얻고 싶은 걸까요? 혹은 어떤 일을 줄이고 싶은 걸까요?
사람이 일하는 모양을 그대로 옮길 필요는 없습니다
여러 에이전트에게 작업을 나누고 실행 순서를 조율하고 결과를 모으는 구조를 흔히 오케스트레이션이라고 부릅니다.
이때 쉽게 떠올릴 수 있는 모델은 회사의 조직도입니다. 기획자가 방향을 정하고 작성자가 만들고 검토자가 확인한 다음 관리자가 최종 결과를 정리하는 식입니다.
익숙한 구조라 이해하기는 쉽습니다. 하지만 사람이 그렇게 일한다는 이유만으로 AI도 같은 구조를 따라야 할까요?
짧은 소개글 하나를 다듬는 상황을 생각해 보겠습니다.
원고와 독자, 원하는 말투, 수정 기준을 한 에이전트에게 전달할 수 있습니다. 결과를 읽고 필요한 부분만 추가로 고치면 됩니다.
여기에 기획자, 작성자, 비평가, 교정자를 따로 둘 수도 있습니다. 기획자가 방향을 정리하고 작성자가 다시 쓰고 비평가가 문제를 지적하고 교정자가 문장을 손봅니다.
단계가 많아지면 과정은 더 전문적으로 보입니다. 하지만 같은 원고를 여러 번 전달하고 수정했다는 사실만으로 결과가 더 좋아졌다고 말할 수는 없습니다.
처음 원고에 담겨 있던 개인적인 말투가 사라질 수도 있습니다. 검토자마다 다른 취향을 적용해 글의 방향이 흔들릴 수도 있고요. 마지막에는 사람이 처음 의도대로 다시 고쳐야 할 수도 있습니다.
반대로 출처가 많은 보고서라면 자료 확인과 문장 편집을 나누는 편이 도움이 될 수 있습니다. 한쪽은 주장과 근거를 대조하고 다른 쪽은 글의 흐름을 살피도록 하는 것입니다.
역할을 나눈 이유는 각 역할이 해결하는 문제로 설명할 수 있어야 합니다.
Anthropic도 단순한 구조에서 시작하라고 권합니다
Anthropic은 「Building effective agents」에서 다음과 같이 권합니다.
finding the simplest solution possible, and only increasing complexity when needed.
가능한 한 단순한 해결책을 찾고, 필요할 때만 복잡도를 높이라는 뜻입니다. 또한 미리 정해진 경로를 따르는 '워크플로'와 모델이 상황에 따라 과정과 도구 사용을 결정하는 '에이전트'를 구분합니다. 여러 역할이 순서대로 등장한다고 모두 자율적으로 협업하는 팀인 것은 아닙니다.
이 원칙을 적용하면 출발점이 달라집니다.
"어떤 역할을 더 만들까?"를 고민하기 전에 지금 방식으로 해결되지 않는 문제가 무엇인지 확인하는 것입니다.
결과가 부정확하다면 자료가 부족한 것인지, 지시가 모호한 것인지, 검증 과정이 빠진 것인지 살펴볼 수 있습니다. 작업이 느리다면 서로 독립적인 일을 순서대로 처리하고 있는지 확인할 수 있고요.
문제에 따라 해결책도 달라집니다. 참고 자료를 추가하면 될 수도 있고 요청을 구체적으로 바꾸면 될 수도 있습니다. 별도의 검토 역할이나 병렬 실행이 필요한 경우도 있을 것입니다.
에이전트를 추가하는 것은 그중 하나의 선택지입니다. 문제를 확인하기도 전에 조직도부터 크게 만들 필요는 없습니다.
참고로 이 글은 2024년 12월에 발행됐으며 현재 페이지에는 당시와 도구 환경이 달라졌다는 안내가 있습니다. 여기서는 특정 도구의 사용법보다 구조를 판단하는 원칙을 참고했습니다.
실제 사례에서는 어떤 일을 나눴을까요?
그렇다면 여러 에이전트가 효과를 낸 실제 사례도 있을까요?
Anthropic은 2025년 6월 Claude Research의 멀티 에이전트 구조를 공개했습니다. 대표 사례는 S&P 500 정보기술 기업들의 이사회 구성원을 모두 조사하는 작업입니다. 회사 측 설명에 따르면 단일 에이전트는 순차 검색으로 답을 완성하지 못했지만 멀티 에이전트 시스템은 작업을 나눠 정답을 찾았습니다.
이 사례에서는 조사 범위를 나누기 쉽다는 점에 주목할 수 있습니다. 한 기업의 이사회 구성원을 찾는 동안 다른 기업의 조사 결과를 기다릴 필요는 없습니다. 독립적으로 자료를 찾고 마지막에 기준을 맞춰 모을 수 있습니다.
다만 이 결과만으로 모든 조사에 여러 에이전트가 필요하다고 말할 수는 없습니다. Anthropic은 자사 데이터에서 멀티 에이전트 시스템이 일반 채팅보다 약 15배의 토큰을 사용했다고도 밝혔습니다. '단일 에이전트 대비 15배'라는 뜻은 아닙니다. 성과와 함께 자원 사용량도 봐야 합니다.
개발 사례에서는 작업을 나누는 방식의 중요성이 더 선명하게 드러납니다.
Anthropic의 Nicholas Carlini는 2026년 2월, 에이전트 16개로 C 컴파일러를 만드는 실험을 공개했습니다. 약 2주 동안 2,000회에 가까운 세션과 약 2만 달러의 API 비용을 들여 Linux 6.9를 빌드할 수 있는 컴파일러를 만들었다고 보고했습니다. 이는 능력의 한계를 시험한 연구 실험으로, 단일 에이전트보다 비용 효율적임을 입증한 비교 실험은 아닙니다.
흥미로운 부분은 중간에 작업이 막힌 이유입니다. 서로 다른 실패 테스트를 수정할 때는 병렬 작업이 가능했습니다. 하지만 커널 빌드 단계에서는 에이전트들이 같은 버그에 매달리고 서로의 수정을 덮어썼습니다. 작성자가 GCC를 활용해 문제를 분리하는 테스트 환경을 만든 뒤에야 서로 다른 버그를 병렬로 수정할 수 있었습니다. 중앙 조정 에이전트는 사용하지 않았습니다.
이 사례를 보면 에이전트를 많이 실행하는 것만으로는 부족하다는 해석이 가능합니다. 각자가 다른 문제를 맡을 수 있어야 하고 작업 결과를 확인할 방법도 있어야 합니다.
그렇다면 사무실처럼 보여 주는 화면은 언제 유용할까요?
여기서 질문을 하나 더 나눠 볼 필요가 있습니다.
여러 에이전트를 사용하는 것이 유용한지와 그 에이전트들을 사무실처럼 보여 주는 것이 유용한지는 별개의 문제입니다.
작업을 잘 나눠 실행하더라도 사무실 화면은 필요하지 않을 수 있습니다. 반대로 실행 구조는 단순하더라도 여러 작업의 진행 상황을 모아 보여 주는 화면은 도움이 될 수 있고요.
사무실 형태를 업무에 활용한다면 여러 일이 동시에 진행되고 담당 사이에서 일이 넘어가며 사람이 중간에 판단해야 하는 상황을 생각해 볼 수 있습니다.
아래는 검증된 도입 성과가 아니라, 이런 작업 특성을 바탕으로 구성해 본 활용 예시입니다.
이런 업무에서는 캐릭터를 배치하는 것보다 상태와 결과를 어떻게 보여 주느냐가 중요해집니다.
누가 바쁘게 움직이는지보다, 어떤 일이 끝났고 무엇이 막혔으며 내가 어디에 개입해야 하는지가 잘 보여야 합니다.
작은 웹서비스의 운영실을 만든다면
조금 더 구체적으로, 혼자 운영하는 웹서비스에 AI 사무실을 적용한다고 가정해 보겠습니다.
필요한 데이터와 도구에 연결돼 있다는 전제에서, 등록 검토 담당은 새로 들어온 게시물의 필수 정보와 링크를 확인할 수 있습니다. 운영 점검 담당은 접속 오류와 깨진 이미지를 찾고 콘텐츠 담당은 소개할 만한 게시물을 모아 뉴스레터 초안을 준비할 수 있습니다.
문의 담당은 들어온 질문을 분류하고 관련 기록을 찾아 답변 초안을 만듭니다. 개발 담당은 확인된 버그를 재현하고 수정안을 준비할 수 있고요.
이때 화면에는 다음과 같은 정보가 표시될 수 있습니다.
등록 검토: 필수 정보 누락 2건, 운영자 확인 대기
운영 점검: 접속 오류 1건, 재확인 중
콘텐츠: 소개 후보 정리 완료, 원고 승인 대기
문의 처리: 버그 제보 1건, 재현 작업으로 전달
개발: 재현 완료, 수정안 테스트 중
이런 화면이라면 각 대화창을 돌아다니며 진행 상황을 물을 필요가 줄어들 수 있습니다. 사용자는 자신의 판단이 필요한 작업을 선택해 확인할 수 있죠.
다만 이 업무들을 모두 중앙 에이전트가 조율해야 하는 것은 아닙니다.
서로 관련 없는 정기 점검이라면 각각 실행하고 결과만 모아 보여 줘도 됩니다. 중앙에 '팀장'을 두더라도 다음 작업을 결정할 일이 없다면 역할이 모호해질 수 있습니다.
반면 접속 오류를 발견한 뒤 원인을 조사하고 코드 문제라면 수정 작업을 만들고 테스트 결과에 따라 재수정하거나 사람에게 확인을 요청한다면 조율할 일이 생깁니다.
앞 단계의 결과에 따라 다음 작업이 달라지는 것입니다. 이런 상황에서는 오케스트레이션이 무엇을 하는지 구체적으로 설명할 수 있습니다.
콘텐츠 제작도 작업의 규모에 따라 달라집니다
글을 만드는 일도 마찬가지입니다.
짧은 게시글 하나를 다듬는 데 여러 담당자를 두는 것과 주간 뉴스레터를 반복 제작하는 것은 상황이 다릅니다.
뉴스레터에 여러 주제를 담고 각 주제의 출처를 확인하고 이미지와 채널별 게시물까지 준비한다면 동시에 진행할 수 있는 일이 생깁니다. 어떤 주제는 자료가 충분하지만 다른 주제는 근거가 부족할 수도 있습니다. 원고는 완성됐어도 이미지 확인이 남아 있을 수 있고요.
이때 작업 화면은 전체 제작 상황을 파악하는 데 쓰일 수 있습니다.
다만 모든 원고를 기획자, 작성자, 비평가, 교정자에게 차례로 전달해야 한다는 뜻은 아닙니다. 출처 확인이 필요한 글에 검증 단계를 추가하고 이미지를 쓰는 글에 제작 작업을 붙이는 식으로 실제 필요에 맞춰 구성할 수 있습니다.
매번 같은 부서를 모두 거치게 하기보다 그 작업에 필요한 과정이 무엇인지 보는 편이 합리적입니다.
역할을 나누면 인수인계도 생깁니다
팀을 만들 때는 각자가 맡을 일에 먼저 눈이 갑니다. 실제 운영에서는 역할 사이를 연결하는 일도 필요합니다.
자료 조사 담당이 링크 열 개를 찾았다고 해 보겠습니다. 작성 담당에게 링크만 넘기면 충분할까요? 각 자료가 어떤 주장을 뒷받침하는지, 서로 충돌하는 내용은 없는지, 확인하지 못한 부분은 무엇인지도 전달해야 하지 않을까요?
요약본만 넘기면 원자료의 중요한 조건을 놓칠 수 있습니다. 반대로 모든 자료와 중간 대화를 넘기면 다음 담당자가 정리해야 할 맥락이 많아집니다.
검토 의견을 어떻게 처리할지도 정해야 합니다. "내용이 부족하다"는 피드백을 받았을 때 누가 무엇을 다시 조사할까요? 두 검토자가 반대 의견을 내면 어떤 기준으로 선택할까요?
이런 결정이 빠져 있으면 사람이 중간에 들어가 교통정리를 하게 됩니다.
자료를 찾고 글을 쓰는 팀을 만들었는데 정작 나는 각 담당자의 결과를 옮기고 설명하고 다시 요청하는 일을 계속하고 있을 수도 있습니다.
그렇다면 작성 업무가 줄어든 만큼 관리 업무가 늘어난 것은 아닌지 확인해야 합니다.
검토 담당이 있다는 것과 검증됐다는 것은 다릅니다
검토 역할은 특히 믿음직하게 느껴집니다. 누군가 한 번 더 봤다는 사실만으로 결과가 안전해 보이기 때문입니다.
하지만 검토 담당에게 어떤 자료와 기준을 줬는지에 따라 확인할 수 있는 범위가 달라집니다.
원고에 어떤 서비스의 무료 이용 범위가 잘못 적혀 있다고 해 보겠습니다. 검토자가 원고만 읽는다면 문장이 자연스러운지는 판단할 수 있어도 실제 정책과 일치하는지는 확인하지 못할 수 있습니다.
이때는 '꼼꼼한 검토자'라는 이름보다 공식 자료에 접근하는 방법과 확인할 항목이 필요합니다. 이용 조건을 대조하고 확인 날짜를 남기고 확인하지 못한 내용은 표시하도록 해야 합니다.
Anthropic도 명확한 평가 기준이 있고 반복 수정의 가치가 측정될 때 결과를 평가하고 개선하는 방식이 적합하다고 설명합니다.
검토자를 추가하기 전에 먼저 물어볼 수 있습니다.
이 담당자는 무엇을 확인할 수 있을까요? 확인했다는 근거는 무엇으로 남길까요? 문제가 없다는 판단을 나는 어디까지 믿을 수 있을까요?
비용은 사용 요금에만 찍히지 않습니다
오케스트레이션의 비용을 생각하면 모델 호출 횟수나 사용 요금부터 떠올리기 쉽습니다. 혼자 일하는 입장에서는 다른 비용도 중요합니다.
지시문을 관리하는 시간, 결과 형식을 맞추는 시간, 멈춘 작업을 다시 실행하는 시간, 최종 결과를 읽고 판단하는 시간이 그렇습니다.
순서대로 처리하는 단계가 늘어나면 앞 단계가 끝날 때까지 기다려야 합니다. 동시에 실행하면 결과를 모으고 충돌을 정리하는 일이 남습니다.
결국 실행이 끝나는 시간만으로는 충분하지 않습니다. 내가 실제로 사용할 수 있는 상태가 될 때까지 얼마나 걸렸는지가 중요합니다.
열 분 만에 초안이 나왔지만 사람이 한 시간 동안 고쳐야 했다면 초안 생성 시간만 보고 효율적이었다고 말하기 어렵습니다. 반대로 실행은 조금 더 걸렸어도 수정할 부분이 크게 줄었다면 내 작업에는 더 나은 방식일 수 있습니다.
작은 서비스를 혼자 운영한다면 유지할 시스템이 하나 늘어난다는 점도 생각해 볼 만합니다. 기능을 만들고 문의에 답하고 운영 문제를 처리하는 사이에 에이전트 시스템 자체도 돌봐야 하니까요.
자동화를 유지하는 일이 본래 하려던 일을 계속 밀어낸다면 구조를 줄이거나 바꾸는 선택도 필요합니다.
도입하기 전에는 같은 일을 간단한 방식으로 해 봅니다
내게 오케스트레이션이 필요한지 알고 싶다면 비교 대상부터 마련할 수 있습니다.
한 에이전트에게 필요한 자료와 구체적인 기준을 주고 같은 일을 시켜 보는 것입니다. 대충 요청한 결과와 정교하게 설계한 팀의 결과를 비교하면 역할 분담 자체가 얼마나 도움이 됐는지 구분하기 어렵습니다.
뉴스레터 원고를 만든다면 독자, 분량, 말투, 반드시 다룰 질문, 출처 표기 방식까지 같은 조건으로 맞춰 볼 수 있습니다.
그다음에는 마음에 드는 결과 한 번만 보지 말고 실제로 반복할 만한 작업 몇 개에서 차이를 살펴봅니다.
비교 항목은 다음 정도로 시작할 수 있습니다.
최종 결과를 사용할 수 있을 때까지 걸린 시간
사람이 수정하거나 개입한 시간
빠진 핵심 내용과 잘못된 근거
실패하거나 다시 실행한 횟수
전체 사용 비용
글이라면 문장이 매끄러워졌는지와 내가 하려던 말이 살아 있는지도 함께 봐야 합니다. 더 정돈됐지만 개성이 사라진 글이라면 내 목적에는 개선이 아닐 수 있으니까요.
여러 역할을 둔 방식에서 반복적으로 이점이 확인된다면 유지할 이유가 생깁니다. 차이가 거의 없다면 더 단순한 방식으로 돌아가도 됩니다.
한 번 만든 팀을 계속 유지해야 할 의무는 없습니다.
미니룸을 꾸미는 재미라고 말해도 괜찮습니다
AI 사무실을 만드는 사람이 어떤 이유로 사용하는지, 얼마나 많은 사람이 실제 업무 효율을 얻고 있는지는 화면 몇 개만 보고 알 수 없습니다.
누군가는 학습을 위해 만들고 누군가는 재미로 꾸미고 누군가는 반복 업무를 줄이는 데 사용할 것입니다. 같은 사람에게 여러 목적이 섞여 있을 수도 있고요.
그래서 AI 사무실을 꾸미는 즐거움 자체를 문제 삼고 싶지는 않습니다. 예전의 미니룸처럼 내 공간을 만들고 이름을 붙이고 그 안에서 무언가가 움직이는 모습을 보는 일은 충분히 재미있을 수 있습니다.
다만 업무 도구로 소개하거나 도입할 때는 그다음 이야기가 필요합니다.
이 구조를 쓰기 전에는 어떤 문제가 있었을까요? 역할을 나눈 뒤 그 문제가 어떻게 달라졌을까요? 결과를 얻기까지 사람이 해야 할 일은 얼마나 줄었을까요?
"에이전트가 다섯 명입니다"보다 "매번 빠뜨리던 출처 확인을 잡아 줍니다"라는 설명이 더 도움이 됩니다. "하루 종일 자동으로 돌아갑니다"보다 "내가 개입해야 하는 지점이 이만큼 줄었습니다"라는 설명이 필요하고요.
AI 사무실을 다 꾸민 뒤에는 잠깐 화면에서 눈을 떼고 결과를 봤으면 합니다.
작업이 끝난 뒤 내게 무엇이 남았는지. 그 결과를 얻기 위해 내가 해야 했던 일은 얼마나 됐는지. 다음에도 이 방식으로 하고 싶은지.
미니룸을 꾸미고 싶었던 날이라면 즐거웠다는 것으로 충분할 수 있습니다. 일을 줄이고 싶었던 날이라면 실제로 일이 줄었는지까지 확인해야겠죠.
참고 자료
Anthropic,
Anthropic,
Nicholas Carlini, Anthropic,
공개 사례의 결과는 해당 작성자의 보고를 기준으로 소개했습니다. 미니룸 비유와 웹서비스 운영실·콘텐츠 제작 예시는 이를 바탕으로 확장한 필자의 해석과 제안이며, 별도로 검증된 생산성 향상 사례는 아닙니다.