6부 30장. 싱글 에이전트와 멀티 에이전트

앞 장에서는 에이전트를 능력의 층위로 나누어 보았다. 도구를 쓸 수 있는지, 계획할 수 있는지, 실행할 수 있는지를 구분하면 에이전트를 훨씬 정확하게 볼 수 있다고 했다.

이번에는 다른 질문을 해 보자.

에이전트가 몇 명처럼 일하느냐에 따라 성격이 달라질까?

답은 그렇다이다. 어떤 시스템은 하나의 에이전트가 처음부터 끝까지 일을 처리한다. 어떤 시스템은 여러 에이전트가 역할을 나누어 협업한다. 겉으로 보기에는 둘 다 "AI가 일을 해 준다"로 보이지만, 내부 구조는 꽤 다르다.

이 차이를 이해하면 복잡한 일을 왜 굳이 여러 에이전트로 쪼개는지, 또 언제는 하나로 충분한지 감이 잡힌다. 결국 중요한 것은 "더 많으냐"가 아니라 "어떻게 나누느냐"다.

에이전트 수가 왜 중요한가

사람이 일하는 모습을 떠올리면 이해가 쉽다. 혼자서 기획도 하고, 조사도 하고, 글도 쓰고, 검토도 하고, 발표까지 하는 사람이 있다. 반면 어떤 일은 조사 담당, 작성 담당, 검토 담당이 나뉘어 있는 팀이 더 잘 해낸다.

AI도 비슷하다. 하나의 에이전트가 모든 단계를 맡는 구조가 있고, 역할별로 분리된 여러 에이전트가 협력하는 구조가 있다.

단순한 일에서는 혼자 하는 편이 빠르다. 하지만 일이 길어지고 복잡해질수록, 한 에이전트에게 모든 판단과 모든 문맥을 몰아주는 방식은 점점 버거워진다. 그래서 멀티 에이전트 구조가 등장한다.

즉, 싱글 에이전트와 멀티 에이전트의 차이는 단순히 숫자의 차이가 아니다. 작업을 나누는 방식의 차이, 그리고 복잡성을 다루는 방식의 차이다.

싱글 에이전트란 무엇인가

싱글 에이전트는 하나의 에이전트가 사용자의 요청을 받아 계획하고, 필요한 도구를 쓰고, 결과를 만들어 내는 구조다. 쉽게 말해 한 명의 AI 작업자가 처음부터 끝까지 일하는 방식이다.

예를 들어 사용자가 "이 제품 소개서를 읽고 발표용 5분 스크립트를 써 줘"라고 하면, 하나의 에이전트가 문서를 읽고 핵심을 뽑고 초안을 만들고 길이를 조정하는 식이다.

많은 AI 도구는 실제로 이 구조에 가깝다. 겉보기에는 여러 단계를 거치는 것처럼 보여도, 내부적으로는 하나의 에이전트가 차례로 처리하는 경우가 많다.

싱글 에이전트의 가장 큰 장점은 단순함이다. 설계가 쉽고, 추적이 쉽고, 속도도 빠른 편이다. 특히 작업 범위가 명확할 때는 아주 효율적이다.

싱글 에이전트가 잘 맞는 일

싱글 에이전트는 다음처럼 흐름이 비교적 짧고 목표가 분명한 일에 잘 맞는다.

• 한 문서를 요약하거나 정리하는 일

• 이메일 초안을 쓰거나 문장을 다듬는 일

• 코드 한 파일의 버그를 찾고 수정안을 제안하는 일

• 정해진 형식의 보고서를 만드는 일

• 회의록을 읽고 액션 아이템을 뽑는 일

이런 작업은 보통 한 덩어리의 문맥 안에서 해결할 수 있다. 역할을 나눌 필요보다, 한 번에 집중해서 처리하는 편이 더 빠르다.

쉽게 말해 방 청소 한 번 하는데 청소 팀을 다섯 명 부를 필요는 없는 것이다.

싱글 에이전트의 장점

싱글 에이전트 구조가 사랑받는 이유는 분명하다.

첫째, 설계가 간단하다. 누가 무엇을 할지 나눌 필요가 없고, 한 에이전트에게 목표와 입력, 제약, 출력 형식을 잘 주면 된다.

둘째, 비용과 지연이 상대적으로 적다. 여러 에이전트가 서로 메시지를 주고받지 않으니 호출 횟수도 줄고, 응답도 단순해진다.

셋째, 디버깅이 쉽다. 결과가 이상하면 그 에이전트의 프롬프트, 도구 사용, 입력 문맥을 보면 된다. 어디에서 사고가 났는지 찾기가 비교적 쉽다.

넷째, 일관성이 좋다. 하나의 에이전트가 전체 결과를 만들기 때문에 말투, 기준, 구조가 덜 흔들릴 수 있다.

특히 실무에서는 이 단순함이 큰 힘이 된다. 잘 만든 싱글 에이전트 하나가 어설픈 멀티 에이전트 시스템보다 훨씬 실용적인 경우가 많다.

싱글 에이전트의 한계

하지만 일이 복잡해질수록 한 명에게 너무 많은 일을 시키는 문제가 드러난다.

하나의 에이전트가 조사자이면서 기획자이고, 작성자이면서 검토자이고, 실행자이기까지 하면 머릿속에 들고 있어야 할 문맥이 급격히 늘어난다. 무엇을 먼저 해야 하는지, 어디까지 끝났는지, 어떤 기준으로 검토해야 하는지를 한 번에 관리해야 한다.

그러다 보면 몇 가지 문제가 자주 생긴다.

• 긴 작업에서 문맥이 뒤섞인다.

• 조사와 판단과 작성이 서로 영향을 주며 품질이 흔들린다.

• 자기 결과를 자기 기준으로 검토하다 보니 허점이 잘 안 보인다.

• 작업이 길어질수록 중간 상태 관리가 어려워진다.

사람으로 치면 혼자 회의도 하고 메모도 하고 발표 자료도 만들고 마지막 검토도 하다 보니, 결국 중요한 오타를 본인이 못 보고 넘기는 상황과 비슷하다.

멀티 에이전트란 무엇인가

멀티 에이전트는 여러 에이전트가 역할을 나누어 협력하는 구조다. 여기서 중요한 것은 "여러 모델"이 아니라 "여러 역할"이다.

이 말은 꽤 중요하다. 멀티 에이전트라고 해서 반드시 서로 다른 회사의 모델을 섞어 써야 하는 것은 아니다. 같은 모델을 여러 개 띄워도 된다. 핵심은 각 에이전트가 맡는 책임과 문맥이 다르다는 점이다.

예를 들어 하나는 자료 조사만 한다. 다른 하나는 조사 결과를 바탕으로 초안을 쓴다. 또 다른 하나는 비평과 검토를 맡는다. 그리고 마지막 하나는 사용자 승인 없이는 실행하지 않는 관리자 역할을 맡을 수 있다.

이렇게 되면 전체 작업은 팀처럼 움직인다. 한 명의 만능 노동자가 아니라, 역할이 분리된 작은 조직이 되는 셈이다.

왜 복잡한 일을 여러 에이전트로 나누는가

복잡한 일은 보통 한 종류의 생각으로 끝나지 않는다. 자료를 찾는 일, 계획을 세우는 일, 실행하는 일, 오류를 점검하는 일은 비슷해 보여도 서로 다른 성격을 가진다.

예를 들어 "시장 조사 보고서를 만들고, 발표 자료까지 준비하고, 내부 공유 문서로 변환하라"는 요청을 생각해 보자. 여기에는 조사, 비교, 구조화, 작성, 편집, 검토, 형식 변환 같은 단계가 뒤섞여 있다.

이때 하나의 에이전트가 모든 것을 한 번에 처리하면, 앞 단계에서 수집한 정보와 뒤 단계의 형식 요구가 뒤엉키기 쉽다. 반면 역할을 나누면 각 에이전트는 자기 문제에 집중할 수 있다.

결국 멀티 에이전트는 일을 쪼개기 위해 쓰는 것이 아니라, 복잡성을 통제하기 위해 쓴다. 문제를 작은 단위로 나누고, 각 단위에 맞는 책임을 부여하면 전체 흐름을 더 안정적으로 운영할 수 있기 때문이다.

멀티 에이전트의 대표 구조

멀티 에이전트라고 해도 형태는 하나가 아니다. 하지만 실무에서 자주 보이는 패턴은 몇 가지로 정리할 수 있다.

첫 번째는 관리자-작업자 구조다. 한 에이전트가 전체 계획을 세우고, 다른 에이전트들에게 조사나 작성 같은 하위 작업을 맡긴다. 팀장과 실무자 구조에 가깝다.

두 번째는 파이프라인 구조다. 조사 에이전트가 자료를 넘기면, 작성 에이전트가 초안을 만들고, 검토 에이전트가 문제를 찾아내고, 최종 정리 에이전트가 결과물을 다듬는 식이다. 공정이 순서대로 이어지는 생산 라인에 가깝다.

세 번째는 토론 구조다. 여러 에이전트가 같은 문제를 서로 다른 관점에서 보고, 의견을 주고받으며 더 나은 답을 찾는다. 한 명은 찬성, 한 명은 반대, 한 명은 위험 점검을 맡을 수도 있다.

네 번째는 전문가 분업 구조다. 한 에이전트는 코드, 다른 에이전트는 법무, 또 다른 에이전트는 문서 형식을 잘 다루는 식으로 전문 분야를 나눈다.

중요한 점은, 멀티 에이전트는 "AI를 많이 붙이는 것"이 아니라 역할과 경계가 명확해야 작동한다는 것이다.

멀티 에이전트의 장점

멀티 에이전트가 매력적인 이유는 단순히 화려해 보여서가 아니다. 실제로 잘 설계하면 다음 같은 이점이 있다.

가장 먼저, 역할 분리가 된다. 조사와 작성과 검토를 나누면 각 단계가 더 선명해진다. 누가 무엇을 책임지는지가 보이기 때문이다.

다음으로, 문맥 부담을 줄일 수 있다. 하나의 에이전트가 모든 정보를 들고 있지 않아도 된다. 조사 에이전트는 자료 수집에 집중하고, 검토 에이전트는 결과의 허점을 보는 데 집중할 수 있다.

또한 상호 점검이 가능해진다. 한 에이전트가 만든 결과를 다른 에이전트가 비판하거나 검증하면, 자기 출력에 스스로 속는 문제를 줄일 수 있다.

마지막으로 확장성이 좋다. 작업이 커질수록 하위 업무를 더 세분화하기 쉬워진다. 인간 조직이 커질수록 역할을 나누는 것과 비슷하다.

복잡한 제품 개발, 긴 리서치 작업, 다단계 문서 생성, 코드 수정과 테스트 반복 같은 일에서 멀티 에이전트가 주목받는 이유가 여기에 있다.

멀티 에이전트의 단점

하지만 멀티 에이전트에는 항상 그림자도 있다. 에이전트가 많아지면 똑똑해 보이지만, 실제로는 운영이 더 어려워진다.

첫째, 구조가 복잡해진다. 누가 시작하고, 누가 넘기고, 누가 승인하고, 누가 멈추는지 설계해야 한다. 이 경계가 흐리면 오히려 결과가 더 나빠진다.

둘째, 비용과 시간이 늘어난다. 에이전트가 여럿이면 호출도 늘고, 중간 메시지도 늘고, 전체 지연 시간도 길어진다.

셋째, 책임이 분산된다. 결과가 틀렸을 때 조사 에이전트 문제인지, 작성 에이전트 문제인지, 관리자 에이전트 문제인지 찾기 어려워질 수 있다.

넷째, 오류가 전파된다. 앞 단계에서 잘못 정리된 내용이 뒤 단계로 넘어가면, 뒤의 에이전트들은 그 틀린 전제를 바탕으로 아주 그럴듯한 결과를 만들어 낼 수 있다.

다섯째, 과설계의 위험이 있다. 사실 한 에이전트면 충분한 일을 굳이 여러 개로 쪼개면 복잡성만 늘고 성과는 줄어든다.

즉, 멀티 에이전트는 강력하지만 공짜가 아니다. 작은 배를 타도 될 강을, 괜히 대형 선박으로 건너려는 실수를 하면 안 된다.

싱글 에이전트와 멀티 에이전트의 핵심 차이

두 구조의 차이를 한 문장으로 요약하면 이렇다.

싱글 에이전트는 한 명이 전체를 책임지는 방식이고, 멀티 에이전트는 여러 역할이 나누어 책임지는 방식이다.

좀 더 실무적으로 보면 차이는 다음처럼 드러난다.

• 싱글 에이전트는 빠르고 단순하지만, 복잡한 장기 작업에서 부담이 커진다.

• 멀티 에이전트는 복잡한 작업을 잘게 다룰 수 있지만, 설계와 관리 비용이 크다.

• 싱글 에이전트는 디버깅이 쉽지만, 자기 검토의 한계가 있다.

• 멀티 에이전트는 상호 검토가 가능하지만, 단계 간 전달 오류가 생길 수 있다.

• 싱글 에이전트는 작은 일에 강하고, 멀티 에이전트는 큰 일을 안정적으로 나누는 데 강하다.

결국 어느 쪽이 더 뛰어나다기보다, 어떤 작업을 다루느냐에 따라 유리한 구조가 달라진다.

예시로 보는 차이: 보고서 작성

예를 들어 "신규 AI 도구 도입 검토 보고서"를 만든다고 해 보자.

싱글 에이전트 구조에서는 하나의 에이전트가 요구사항을 읽고, 비교 기준을 정하고, 후보를 조사하고, 장단점을 정리하고, 보고서 초안을 쓴다. 잘 작동하면 빠르고 매끈하다. 하지만 조사 기준이 흔들리거나, 특정 도구의 한계를 놓치거나, 문서 형식 요구를 뒤늦게 반영하는 문제가 생길 수 있다.

멀티 에이전트 구조에서는 먼저 조사 에이전트가 후보 도구를 정리한다. 다음으로 비교 에이전트가 비용, 보안, 기능, 도입 난이도를 기준으로 정리한다. 그다음 작성 에이전트가 초안을 만들고, 검토 에이전트가 빠진 논점과 과장된 표현을 찾는다. 마지막으로 편집 에이전트가 임원용 문서 형식에 맞춘다.

이 구조는 분명 더 무겁다. 하지만 길고 복잡한 보고서에서는 더 안정적일 수 있다. 특히 여러 기준을 놓치면 안 되는 업무에서 강하다.

예시로 보는 차이: 코드 수정

코드 작업에서도 차이는 뚜렷하다.

싱글 에이전트는 오류 로그를 읽고 원인을 추정하고 코드를 수정하고 테스트까지 해 볼 수 있다. 작은 버그 하나를 고칠 때는 이 방식이 매우 효율적이다.

하지만 수정 범위가 넓고, 여러 모듈이 얽히고, 테스트 전략까지 필요하다면 멀티 에이전트 구조가 유리해질 수 있다. 예를 들어 한 에이전트는 원인 분석, 한 에이전트는 패치 작성, 한 에이전트는 테스트 생성, 한 에이전트는 회귀 위험 점검을 맡는 식이다.

이렇게 나누면 각 단계의 품질을 더 세밀하게 통제할 수 있다. 대신 설계를 잘못하면 서로 같은 파일을 건드리거나, 서로 다른 가정을 놓고 따로 놀 수도 있다.

멀티 에이전트라고 해서 더 똑똑한 것은 아니다

여기서 꼭 짚고 넘어가야 할 오해가 있다. 에이전트 수가 많다고 해서 시스템이 자동으로 더 똑똑해지는 것은 아니다.

오히려 애매한 역할을 가진 에이전트를 여러 개 붙이면, 생각은 많고 성과는 적은 회의실이 만들어질 수 있다. 한 에이전트가 한 말을 다른 에이전트가 다시 포장해서 되풀이하는 경우도 생긴다. 사람 팀에서도 회의 참석자가 많다고 일 처리가 빨라지지 않는 것과 같다.

좋은 멀티 에이전트는 숫자가 많아서 좋은 것이 아니다. 역할이 다르고, 입력과 출력이 명확하고, 넘겨주는 형식이 분명하고, 최종 책임 구조가 있는 시스템이어서 좋은 것이다.

즉, 멀티 에이전트는 "AI 회의 참가자 늘리기"가 아니라 "작업 공정 설계"에 가깝다.

언제 싱글 에이전트를 선택해야 하는가

다음과 같은 경우에는 싱글 에이전트가 더 낫다.

• 작업 목표가 명확하고 범위가 작다.

• 중간 단계가 많지 않다.

• 결과를 빠르게 얻는 것이 중요하다.

• 비용과 복잡성을 최소화해야 한다.

• 문맥 전체를 한 에이전트가 들고 있어도 부담이 크지 않다.

예를 들어 초안 작성, 간단한 요약, 단일 문서 분석, 짧은 코드 수정, 회의록 정리 같은 일은 대부분 싱글 에이전트로 충분하다.

처음부터 멀티 에이전트로 시작할 필요는 없다. 실전에서는 "한 명으로 안 되는 이유가 분명할 때" 나누는 것이 좋다.

언제 멀티 에이전트를 선택해야 하는가

반대로 이런 경우에는 멀티 에이전트를 고려할 만하다.

• 작업이 길고 단계가 많다.

• 조사, 작성, 검토, 실행이 분리되어야 한다.

• 서로 다른 관점의 점검이 필요하다.

• 한 번의 문맥 안에 다 넣기 어려울 만큼 정보가 많다.

• 실패 지점을 단계별로 관리해야 한다.

• 각 단계 결과를 기록하고 검증해야 한다.

특히 "잘못되면 비용이 큰 일"에서 멀티 에이전트는 유리할 수 있다. 예를 들어 계약서 검토 보조, 복잡한 코드 변경, 다단계 문서 자동화, 장기 리서치 프로젝트처럼 검토와 추적이 중요한 경우다.

멀티 에이전트를 설계할 때 꼭 필요한 질문

멀티 에이전트를 만들고 싶다면 먼저 이 질문들에 답해야 한다.

첫째, 왜 나누는가? 단순히 멋있어 보여서가 아니라, 어떤 복잡성을 줄이기 위해 나누는지 분명해야 한다.

둘째, 각 에이전트의 역할은 무엇인가? 조사, 작성, 검토, 실행처럼 책임 경계가 있어야 한다.

셋째, 각 에이전트는 무엇을 입력받고 무엇을 출력하는가? 넘겨주는 형식이 모호하면 혼선이 생긴다.

넷째, 누가 최종 결정을 내리는가? 모든 에이전트가 제각각 결론을 내리면 시스템이 흔들린다.

다섯째, 실패했을 때 어디서 멈출 것인가? 잘못된 중간 결과를 자동으로 다음 단계에 넘기지 않도록 브레이크가 필요하다.

멀티 에이전트의 절반은 역할 설계이고, 나머지 절반은 전달 규칙 설계라고 봐도 좋다.

초보자가 실수하기 쉬운 부분

초보 사용자는 종종 역할놀이와 멀티 에이전트를 혼동한다. 하나의 프롬프트 안에서 "너는 조사자, 비평가, 편집자 역할을 모두 해라"라고 쓰는 것은 역할 분리를 흉내 낸 것이지, 진짜 멀티 에이전트 구조와는 다를 수 있다.

물론 이런 방식도 유용하다. 하지만 실제 멀티 에이전트의 강점은 각 역할이 분리된 문맥과 책임을 갖는 데 있다. 조사 에이전트는 조사에만 집중하고, 검토 에이전트는 결과 비판에 집중할 수 있어야 한다.

또 하나의 흔한 실수는, 너무 이른 시점에 에이전트를 많이 쪼개는 것이다. 작은 작업을 다섯 단계로 나누면 보기에는 그럴듯해도 실제로는 전달 비용만 늘어난다.

처음에는 싱글 에이전트로 만들고, 병목이 드러나는 부분만 분리하는 편이 훨씬 현실적이다.

실전 감각: 먼저 하나로 만들고, 필요할 때 나눠라

실무에서 가장 좋은 접근은 대개 이렇다.

처음에는 싱글 에이전트로 시작한다. 어디에서 자주 실패하는지 본다. 조사 품질이 흔들리는지, 초안은 괜찮은데 검토가 약한지, 실행은 잘하는데 우선순위 판단이 불안한지 살핀다.

그다음 그 병목 지점을 분리한다. 예를 들어 검토 품질이 항상 아쉽다면 비평 전용 에이전트를 붙인다. 조사량이 너무 많아 문맥이 넘친다면 조사 에이전트를 따로 둔다. 실행 전에 안전 확인이 필요하다면 승인용 관리자 에이전트를 둔다.

이렇게 하면 멀티 에이전트는 거창한 유행어가 아니라, 실제 문제를 해결하기 위한 구조 개선이 된다.

결국 중요한 것은 구조와 책임이다

싱글 에이전트와 멀티 에이전트의 차이는 단순한 숫자놀이가 아니다. 하나는 한 명이 전체를 맡는 방식이고, 다른 하나는 여러 역할이 책임을 나누는 방식이다.

싱글 에이전트는 빠르고 단순하고 다루기 쉽다. 멀티 에이전트는 복잡한 일을 나누고 점검하고 확장하는 데 유리하다. 하지만 멀티 에이전트는 설계와 관리가 어렵고, 잘못 만들면 오히려 더 혼란스러워진다.

그래서 핵심 질문은 이것이다.

이 작업은 한 명이 끝까지 맡는 편이 나은가, 아니면 역할을 나누는 편이 나은가?

이 질문에 답할 수 있게 되면, 에이전트를 훨씬 현실적으로 설계하고 사용할 수 있다. 무엇을 하나로 묶고, 무엇을 분리해야 하는지 보이기 시작하기 때문이다.

이 장의 정리

싱글 에이전트는 하나의 에이전트가 전체 작업을 맡는 구조다. 단순하고 빠르며 작은 일에 강하다.

멀티 에이전트는 여러 에이전트가 역할을 나누어 협력하는 구조다. 복잡한 작업을 분해하고 점검하며 확장하는 데 유리하다.

복잡한 일을 여러 에이전트로 나누는 이유는 멋있어 보여서가 아니다. 조사, 작성, 검토, 실행처럼 서로 다른 종류의 일을 분리해 복잡성을 통제하기 위해서다.

하지만 에이전트 수를 늘린다고 자동으로 성과가 좋아지지는 않는다. 역할, 입력과 출력, 전달 규칙, 최종 책임이 분명해야 멀티 에이전트가 힘을 발휘한다.

다음 장에서는 한 걸음 더 들어가, 이런 구조를 실제로 잘 쓰기 위해 어떤 태도와 판단 기준이 필요한지 살펴본다. 에이전트를 잘 쓰는 사람은 기술만 아는 사람이 아니라, 어떻게 맡기고 어떻게 통제해야 하는지 아는 사람이기 때문이다.