2부 5장. 단일 에이전트로 충분한 경우

에이전트 시스템을 처음 설계할 때 사람들은 종종 아주 그럴듯한 그림부터 그린다. 조사 담당 에이전트가 있고, 요약 담당 에이전트가 있고, 검토 담당 에이전트가 있고, 마지막으로 관리자 에이전트가 이들을 지휘한다. 다이어그램은 근사하다. 화살표도 많고, 상자도 많고, 왠지 똑똑해 보인다.

그런데 막상 돌려 보면 이상한 일이 벌어진다. 느리고, 비싸고, 어디서 실패했는지 찾기 어렵다. 한 에이전트가 한 말을 다른 에이전트가 오해하고, 같은 정보를 여러 번 읽고, 책임은 여러 조각으로 흩어진다. 결국 사용자는 묻게 된다. "이걸 굳이 이렇게까지 나눌 필요가 있었나요?"

대부분의 경우 답은 놀랍도록 단순하다. 없었다.

이 장의 목적은 멀티에이전트를 깎아내리는 것이 아니다. 오히려 그 반대다. 정말 필요한 순간에만 제대로 쓰기 위해, 먼저 단일 에이전트가 어디까지 할 수 있는지 정확히 이해하려는 것이다. 좋은 설계자는 큰 구조를 먼저 고르지 않는다. 가장 싼 정답, 가장 단순한 정답, 가장 운영하기 쉬운 정답부터 고른다. 그리고 그 정답이 충분할 때는 거기서 멈춘다.

단일 에이전트란 무엇인가

단일 에이전트는 말 그대로 하나의 주된 실행 주체가 목표를 받아 상태를 읽고, 필요한 도구를 쓰고, 결과를 바탕으로 다음 행동을 고르는 구조다. 모델이 하나라는 뜻만은 아니다. 더 중요한 것은 의사결정의 중심이 하나라는 점이다.

이 구조에서는 보통 하나의 실행 루프가 있다. 사용자의 요청을 받고, 현재 상태를 확인하고, 필요한 정보를 찾고, 도구를 호출하고, 다시 판단하고, 끝나면 멈춘다. 책임이 한곳에 모여 있기 때문에 시스템의 흐름을 이해하기 쉽다.

여기서 중요한 감각이 있다. 단일 에이전트는 "작은 시스템"이 아니라 "결정 중심이 하나인 시스템"이다. 검색 도구를 여러 개 붙일 수도 있고, 파일을 읽고 쓸 수도 있고, 브라우저를 사용할 수도 있다. 심지어 내부적으로 단계를 나누어 처리할 수도 있다. 그래도 최종적으로 무엇을 할지 판단하는 중심이 하나라면, 그것은 여전히 단일 에이전트에 가깝다.

많은 팀이 너무 일찍 여러 에이전트로 나누는 이유는, 복잡한 일을 보면 복잡한 구조가 필요하다고 느끼기 때문이다. 하지만 실제로는 복잡한 일을 단일한 판단 중심 아래에서 차근차근 처리하는 편이 더 낫다. 회사에 신입이 들어왔는데, 첫날부터 부서를 다섯 개 만들지는 않는다. 보통은 일을 잘하는 한 사람에게 먼저 맡겨 보고, 어디서 병목이 생기는지 본다. 에이전트도 비슷하다.

왜 기본값은 단일 에이전트여야 하는가

단일 에이전트가 좋은 첫 선택인 이유는 화려함이 아니라 경제성 때문이다. 여기서 경제성은 단순히 API 비용만 뜻하지 않는다. 설계 비용, 디버깅 비용, 운영 비용, 실패 비용까지 포함한다.

첫째, 컨텍스트가 덜 흩어진다. 하나의 에이전트가 일을 처리하면 같은 상태와 같은 목표를 계속 들고 갈 수 있다. 반면 여러 에이전트로 나누면 정보를 전달하는 순간마다 요약이 필요하고, 그 요약이 중요한 맥락을 떨어뜨릴 수 있다. 사람도 회의가 많아질수록 일이 느려지는데, 에이전트도 마찬가지다.

둘째, 실패 원인을 찾기 쉽다. 단일 에이전트는 "왜 이런 판단을 했는가"를 추적할 경로가 비교적 단순하다. 어느 프롬프트에서 흔들렸는지, 어떤 도구 결과를 잘못 해석했는지, 상태가 어떻게 꼬였는지를 보기 쉽다. 반대로 에이전트가 여러 개면 문제는 금방 핑퐁이 된다. 조사 에이전트가 잘못 찾은 건지, 요약 에이전트가 잘못 압축한 건지, 계획 에이전트가 잘못 배분한 건지 헷갈린다.

셋째, 비용과 지연 시간이 줄어든다. 에이전트를 하나 더 추가한다는 것은 보통 모델 호출을 하나 더 추가한다는 뜻이다. 게다가 각자 같은 배경 설명을 다시 읽을 수 있다. 사용자는 "똑같은 문서를 왜 세 번 읽고 있지?"라고 생각하게 된다. 좋은 시스템은 영리하게 보이는 시스템이 아니라, 쓸데없이 바쁘지 않은 시스템이다.

넷째, 권한 관리가 쉽다. 하나의 에이전트에 읽기 도구와 제한된 쓰기 도구를 붙이고, 위험한 작업은 승인 절차 뒤로 미루면 된다. 여러 에이전트가 서로 다른 권한을 들고 움직이기 시작하면, 보안 설계도 함께 어려워진다.

다섯째, 제품을 고치기 쉽다. 프롬프트를 다듬거나 상태 구조를 바꾸거나 도구 설명을 개선했을 때, 단일 에이전트는 효과가 어디에 반영되는지 분명하다. 반면 멀티에이전트는 한쪽을 고치면 다른 쪽의 입력 형식과 기대치도 함께 바꿔야 하는 경우가 많다.

한마디로 정리하면, 단일 에이전트는 덜 화려하지만 더 싸고, 더 빠르고, 더 고치기 쉽다. 제품은 이 세 가지를 유난히 좋아한다.

이런 문제라면 단일 에이전트가 대개 충분하다

어떤 문제는 이름만 복잡할 뿐, 구조는 단순하다. 이런 경우에는 단일 에이전트가 거의 항상 더 낫다.

먼저 목표가 하나로 묶여 있을 때다. 예를 들어 "이 고객 문의를 읽고 관련 정책을 찾아 답변 초안을 작성해 줘" 같은 요청은 여러 하위 단계가 있을 수 있지만, 전체 목표는 하나다. 문의를 이해하고, 정책을 확인하고, 답변을 만든다. 이 정도는 단일 에이전트가 상태를 유지한 채 충분히 처리할 수 있다.

다음으로, 사용하는 도구가 대체로 같은 범주에 있을 때다. 검색, 파일 읽기, CRM 조회, 초안 작성처럼 모두 하나의 작업 흐름 안에 자연스럽게 묶인다면 굳이 도구별로 에이전트를 나눌 이유가 없다. 망치 하나 잘 쓰는 사람이 필요한데, 망치 전담 팀과 못 전담 팀을 따로 만들 필요는 없다.

또한 중간 단계들이 강하게 연결되어 있을 때도 단일 에이전트가 유리하다. 조사 결과를 바탕으로 곧바로 초안을 쓰고, 그 초안을 다시 사용자 맥락에 맞게 다듬어야 한다면, 한 주체가 끝까지 들고 가는 편이 자연스럽다. 단계 사이의 의미가 촘촘하게 연결될수록, 그 경계를 인위적으로 나누는 비용이 커진다.

그리고 실패의 대부분이 구조 부족이 아니라 품질 부족일 때도 그렇다. 에이전트가 필요한 정보를 못 찾는다면 검색 도구를 손봐야 할 수 있고, 결과를 잘못 해석한다면 프롬프트나 상태 표현을 고쳐야 할 수 있다. 이 문제를 멀티에이전트로 해결하려 하면, 사실은 약한 한 명을 여러 명으로 늘리는 셈이 된다.

실무적으로 보면 다음과 같은 일은 단일 에이전트로 시작하는 편이 좋다.

• 사내 문서와 시스템을 참고해 답변 초안 만들기

• 하나의 고객 요청을 분석하고 후속 조치 제안하기

• 미팅 준비 자료 수집과 브리핑 문서 작성하기

• 티켓 내용을 읽고 분류, 요약, 우선순위 판단하기

• 정해진 몇 개의 시스템을 오가며 보고서 초안 만들기

이 일들은 결코 가볍지 않다. 하지만 의사결정 중심이 여러 개일 필요는 없는 경우가 많다.

사람들은 왜 너무 빨리 멀티에이전트로 가는가

이 대목이 중요하다. 많은 팀이 멀티에이전트를 선택하는 이유는 진짜 필요보다 심리적 유혹에 가깝다.

가장 흔한 이유는 역할 이름을 붙이면 설계가 명확해진다고 느끼기 때문이다. "리서처", "플래너", "라이터", "리뷰어"라는 이름을 붙이면 왠지 체계가 잡힌 것처럼 보인다. 하지만 이름표를 붙였다고 경계가 생기는 것은 아니다. 오히려 한 에이전트 안에서 순차적으로 수행해도 될 과정을 공연히 쪼개는 경우가 많다.

둘째는 데모 효과다. 여러 에이전트가 대화하듯 협업하는 장면은 보기 좋다. 투자 발표나 기술 시연에서 박수가 나오기 쉽다. 그러나 운영 환경은 박수보다 재현성을 원한다. 사용자는 "에이전트끼리 토론했어요"보다 "실수 없이 끝났어요"를 더 좋아한다.

셋째는 문제의 원인을 잘못 진단하기 때문이다. 에이전트가 자꾸 이상한 답을 낸다고 해서, 곧바로 "전문가 에이전트를 하나 더 두자"로 가면 안 된다. 진짜 문제는 컨텍스트가 부족하거나, 도구 설명이 모호하거나, 상태 갱신이 부실하거나, 종료 조건이 약한 것일 수 있다. 이런 상태에서 멀티에이전트를 얹으면, 문제를 해결하기보다 문제를 분산시킨다.

넷째는 조직도를 시스템 설계에 그대로 투영하기 때문이다. 회사에는 기획팀, 운영팀, 재무팀이 있으니 시스템에도 비슷한 역할의 에이전트를 넣고 싶어진다. 하지만 조직도는 책임 분배를 위한 것이고, 시스템 구조는 계산과 제어 비용을 줄이기 위한 것이다. 둘은 닮을 수도 있지만, 꼭 같아야 하는 것은 아니다.

단일 에이전트에서 먼저 고쳐야 할 것들

멀티에이전트를 고민하기 전에, 먼저 스스로에게 물어야 한다. "정말 구조의 한계인가, 아니면 아직 기본기를 다듬지 않은 것인가?" 많은 경우 답은 후자다.

단일 에이전트가 기대만큼 성능을 못 낼 때는 보통 네 가지를 먼저 의심해야 한다.

• 목표가 너무 넓거나 अस्पष्ट해서 에이전트가 어디까지 해야 하는지 모른다.

• 상태 표현이 약해서 중간 결과를 제대로 이어받지 못한다.

• 도구 설명과 사용 규칙이 모호해서 엉뚱한 호출을 한다.

• 멈춰야 할 시점을 모르거나, 반대로 필요한 확인을 건너뛴다.

이 문제들은 에이전트 수를 늘린다고 저절로 해결되지 않는다. 오히려 하나의 약한 설계를 여러 복사본으로 늘리는 결과가 되기 쉽다.

예를 들어 문서 조사 후 요약 품질이 들쭉날쭉하다면, 먼저 검색 결과를 어떻게 정리해 상태에 저장할지 생각해야 한다. 중요한 사실, 출처, 불확실한 부분을 분리해 기록하면 같은 에이전트도 훨씬 안정적으로 행동할 수 있다. 또 답변이 장황하다면 "무엇을 답하고 무엇은 보류할지"를 프롬프트에 더 분명히 적어야 한다. 이때 필요한 것은 더 많은 에이전트가 아니라 더 나은 설계다.

좋은 팀은 멀티에이전트로 도망치지 않는다. 먼저 단일 에이전트를 끝까지 단련해 본다.

단일 에이전트가 특히 강한 설계 패턴

단일 에이전트의 장점은 단순함에만 있지 않다. 사실 이 구조는 생각보다 많은 변형을 품을 수 있다.

가장 흔한 형태는 "한 에이전트, 여러 도구"다. 에이전트는 같은 목표 아래 검색도 하고, 파일도 읽고, 데이터베이스도 조회하고, 마지막에 결과를 정리한다. 겉보기에는 일이 많지만, 의사결정의 중심은 여전히 하나다.

그다음 형태는 "한 에이전트, 여러 단계"다. 먼저 초안을 만들고, 그다음 스스로 체크리스트로 검토하고, 부족하면 다시 고치는 식이다. 이 역시 여러 명이 협업하는 것이 아니라, 한 명이 메모를 보며 일하는 것에 가깝다.

또 다른 형태는 "한 에이전트, 제한된 분기"다. 요청 유형에 따라 조금 다른 처리 경로를 타더라도, 최종 판단과 상태 관리는 하나의 루프 안에 있다. 이 정도 분기는 멀티에이전트라기보다 단일 에이전트의 성숙한 형태라고 보는 편이 맞다.

이 감각이 중요하다. 단계를 나눴다고 곧바로 멀티에이전트가 되는 것은 아니다. 분기가 있다고 곧바로 여러 에이전트가 필요한 것도 아니다. 한 명이 차분히 처리할 수 있는 일이라면, 굳이 회의실을 열 필요가 없다.

언제 여기서 멈춰야 하는가

이번 장의 핵심은 단순히 "단일 에이전트도 좋다"가 아니다. 더 중요한 말은 이것이다. 단일 에이전트가 충분할 때는 거기서 멈춰야 한다.

멈춘다는 것은 소극적이라는 뜻이 아니다. 오히려 설계 감각이 있다는 뜻이다. 다음 조건이 맞아떨어지면, 굳이 멀티에이전트로 확장하지 않는 편이 낫다.

첫째, 하나의 공유 컨텍스트로 대부분의 판단이 가능하다면 멈춰도 된다. 같은 배경 정보를 바탕으로 조사, 판단, 작성이 이어진다면, 그 맥락을 쪼개는 순간 손실이 생긴다.

둘째, 처리 시간을 줄이는 핵심이 병렬화가 아니라 품질 개선이라면 멈춰도 된다. 예를 들어 느린 이유가 여러 에이전트가 아니라 외부 검색 API 대기 시간이라면, 구조를 쪼개 봐야 체감 이득이 없다.

셋째, 에러의 대부분이 도구 실패나 데이터 품질 문제라면 멈춰도 된다. 에이전트를 늘리기 전에 도구 자체를 더 안정적으로 만드는 편이 낫다.

넷째, 안전과 감사가 중요할수록 멈추는 편이 좋다. 하나의 에이전트가 어떤 근거로 어떤 행동을 선택했는지 추적하기 쉬운 구조가 운영에 유리하다.

다섯째, 시스템을 아직 충분히 측정하지 못하고 있다면 멈춰야 한다. 단일 에이전트의 성능도 제대로 모르는 상태에서 멀티에이전트로 가면, 무엇이 좋아지고 무엇이 나빠졌는지 판단할 기준이 사라진다.

조금 냉정하게 말하면, 단일 에이전트가 아직 제대로 관측도, 평가도, 통제도 되지 않는 팀은 멀티에이전트를 운영할 준비가 안 된 경우가 많다.

단일 에이전트의 진짜 한계는 언제 드러나는가

그렇다고 단일 에이전트가 언제나 충분한 것은 아니다. 중요한 것은 한계를 정확히 알아보는 것이다. 진짜 한계와 섣부른 조급함은 다르다.

단일 에이전트의 한계는 주로 세 종류로 나타난다.

첫째, 한 요청 안에 서로 다른 하위 과업이 너무 느슨하게 연결되어 있을 때다. 예를 들어 전혀 다른 데이터 소스를 독립적으로 조사한 뒤, 결과를 나중에 합쳐야 한다면 하나의 루프가 모든 것을 순서대로 처리하는 것이 비효율적일 수 있다.

둘째, 병렬 실행의 이점이 아주 클 때다. 여러 문서를 동시에 분석하거나, 여러 후보안을 독립적으로 생성해 비교해야 하는 상황에서는 단일 루프가 시간 면에서 불리할 수 있다.

셋째, 권한과 책임을 강하게 분리해야 할 때다. 어떤 작업은 읽기만 가능해야 하고, 어떤 작업은 승인된 주체만 실행해야 한다면, 구조적 분리가 실제 보안 요구와 맞물릴 수 있다.

하지만 이 한계가 보인다고 곧바로 멀티에이전트로 직행할 필요는 없다. 종종 그 사이에 더 싼 해법이 있다. 단계를 명시적으로 나누는 프롬프트 체이닝, 입력에 따라 경로를 바꾸는 라우팅, 병렬 실행 후 결과를 합치는 오케스트레이션 같은 패턴이 먼저다. 즉, 한 명으로 부족하다고 해서 바로 팀을 꾸릴 필요는 없다. 먼저 일하는 방식을 바꾸면 된다.

단일 에이전트와 멀티에이전트 사이의 함정

실무에서는 이 둘 사이를 헷갈리는 경우가 많다. 단일 에이전트가 조금만 복잡해져도 "이건 사실 멀티에이전트 아닌가요?"라는 말이 나온다. 하지만 중요한 것은 내부 단계 수가 아니라, 독립적인 판단 주체가 정말 여러 개냐는 점이다.

예를 들어 한 에이전트가 먼저 정보를 모으고, 그다음 초안을 쓰고, 마지막에 스스로 검토하는 것은 멀티에이전트라기보다 자기 점검이 있는 단일 에이전트에 가깝다. 반대로 조사 담당과 실행 담당이 서로 다른 상태를 들고 독립적으로 판단하며, 서로에게 결과를 넘기는 구조라면 멀티에이전트에 가까워진다.

이 차이를 구분하지 못하면, 실은 하나의 루프로 충분한 문제를 괜히 거대한 협업 구조로 오해하게 된다. 이름보다 중요한 것은 제어 흐름이다.

설계 회의에서 바로 쓰는 판단 질문

회의실에서 "이건 처음부터 멀티에이전트로 가야 하지 않을까요?"라는 말이 나오면, 다음 질문을 차례로 던져 보면 좋다.

• 목표가 하나인가, 아니면 서로 다른 목표가 병렬로 존재하는가?

• 대부분의 판단이 하나의 공유 상태만으로 가능한가?

• 같은 도구 집합을 써도 충분한가?

• 속도 문제의 본질이 진짜 병렬성 부족인가?

• 권한 분리와 책임 분리가 구조적으로 꼭 필요한가?

이 질문에 대해 앞의 세 항목이 대체로 그렇고, 뒤의 두 항목이 아직 아니라면 단일 에이전트로 시작하는 편이 맞다. 특히 "하나의 공유 상태로 충분한가?"라는 질문은 아주 강력하다. 대부분의 초기 제품은 여기서 이미 답이 나온다.

좋은 설계자는 한 명을 먼저 유능하게 만든다

단일 에이전트는 초보자의 임시 선택이 아니다. 오히려 성숙한 설계의 출발점이다. 처음부터 여러 에이전트를 꾸리는 일은 쉽다. 상자를 더 그리면 되기 때문이다. 어려운 일은 하나의 에이전트를 정말 잘 작동하게 만드는 것이다.

목표를 선명하게 정의하고, 상태를 정돈하고, 도구 사용 규칙을 분명히 하고, 어디서 멈춰야 하는지 가르치는 일은 화려하지 않다. 하지만 이런 기본기가 갖춰진 단일 에이전트는 예상보다 훨씬 넓은 문제를 처리한다. 반대로 기본기가 약한 멀티에이전트는 인원만 많은 프로젝트 팀처럼 굴기 쉽다. 회의는 많은데 결과는 늦게 나온다.

그래서 좋은 설계자는 먼저 이렇게 묻는다. "이 문제를 한 에이전트가 끝까지 책임지게 할 수 없는가?" 이 질문에 아직 충분히 답해 보지 않았다면, 멀티에이전트는 너무 이르다.

이번 장의 결론

단일 에이전트는 대충 만든 첫 버전이 아니다. 많은 경우 가장 좋은 최종 형태이기도 하다. 목표가 비교적 하나로 묶여 있고, 공유 상태가 중요하며, 도구 사용이 하나의 흐름 안에 있고, 운영의 단순함이 중요하다면 단일 에이전트가 가장 효율적이다.

반대로 멀티에이전트는 "더 똑똑한 버전"이 아니라 "더 비싼 구조"다. 그 비용을 정당화하려면 분명한 이유가 있어야 한다. 진짜 병렬성이 필요하거나, 서로 다른 책임을 분리해야 하거나, 하나의 실행 루프로 감당하기 어려운 독립 과업이 존재해야 한다.

그러니 복잡성을 늘리기 전에 먼저 물어보자. 이 문제는 정말 여러 명이 필요한가, 아니면 한 명이 더 잘하면 되는가. 설계 감각은 바로 이 질문에서 시작된다.

다음 장부터는 단일 에이전트를 더 강하게 만드는 방법을 본격적으로 살펴본다. 먼저 팀을 꾸리기 전에, 한 명이 일을 더 잘하게 만드는 법부터 알아야 한다. 의외로 많은 시스템은 거기서 이미 충분해진다.