멀티에이전트 하네스

멀티에이전트라는 말을 들으면 대단한 협업 장면이 먼저 떠오른다. 한 에이전트는 조사하고, 다른 에이전트는 실행하고, 또 다른 에이전트는 검토한다. 얼핏 보면 사람 팀을 그대로 복제한 것처럼 보인다. 하지만 여기서 먼저 분명히 해야 할 점이 있다. 여러 에이전트를 쓰는 이유는 시스템을 더 화려하게 만들기 위해서가 아니다. 더 잘 나누고, 더 잘 제한하고, 더 잘 검증하기 위해서다.

에이전트 하나에게 모든 일을 맡기면 설계는 단순해 보인다. 대신 문제가 생겼을 때 원인을 찾기 어렵고, 권한이 한곳에 몰리며, 계획과 실행과 검토가 뒤섞인다. 반대로 역할을 나누면 각 에이전트가 해야 할 일과 하지 말아야 할 일이 분명해진다. 멀티에이전트 하네스의 출발점은 협업이 아니라 격리다. 좋은 멀티에이전트 구조는 마치 한 작업장을 칸막이로 나눈 것과 같다. 서로 방해하지 않으면서도 필요한 결과만 주고받게 만드는 것이다.

여러 에이전트를 쓴다는 것의 진짜 의미

멀티에이전트는 모델 수를 늘리는 기술이 아니다. 책임 경계를 설계하는 기술이다. 한 에이전트가 문제를 정의하고, 다른 에이전트가 도구를 사용해 작업하고, 또 다른 에이전트가 결과를 기준에 맞춰 검사한다면, 우리는 각 단계에서 실패를 더 선명하게 볼 수 있다. 실패가 났을 때 "모델이 이상했다"라고 뭉뚱그리지 않고, 계획이 잘못됐는지, 실행이 틀렸는지, 검토가 허술했는지 구분할 수 있다.

이 차이는 운영에서 크게 드러난다. 단일 에이전트는 빠르게 만들 수 있지만, 권한 통제와 품질 검증이 어려워지기 쉽다. 멀티에이전트는 처음부터 조금 더 복잡하지만, 특정 역할에 특정 도구와 권한만 연결할 수 있다. 예를 들어 계획 에이전트는 읽기만 가능하고, 실행 에이전트만 쓰기 권한을 가지며, 검토 에이전트는 배포 대신 승인 여부만 판단하게 만들 수 있다. 이렇게 하면 사고가 나더라도 사고의 반경이 작아진다.

역할 분담은 능력 분담이 아니라 책임 분담이다

많은 팀이 멀티에이전트를 설계할 때 "누가 더 똑똑한가"를 먼저 고민한다. 하지만 실제로 중요한 것은 "누가 어디까지 책임지는가"다. 역할은 모델의 재능보다 시스템의 통제 구조를 반영해야 한다.

대표적인 역할은 다음과 같다.

• 계획자: 목표를 작업 단위로 나누고 순서를 정한다.

• 실행자: 도구를 호출하고 실제 변경을 만든다.

• 검토자: 결과가 기준을 만족하는지 확인한다.

• 조정자: 여러 에이전트의 상태를 모아 다음 단계를 결정한다.

여기서 핵심은 각 역할이 서로의 일을 몰래 대신하지 않게 하는 것이다. 계획자는 실행하지 않아야 하고, 실행자는 스스로 합격 판정을 내리지 않아야 하며, 검토자는 원칙적으로 결과를 직접 수정하지 않는 편이 낫다. 수정까지 허용하면 검토와 실행이 섞이기 때문이다. 멀티에이전트 하네스는 역할 이름을 붙이는 것으로 끝나지 않는다. 권한, 입력, 출력, 성공 조건까지 분리되어야 비로소 역할이 된다.

토론형 구조와 파이프라인형 구조

멀티에이전트 구조는 크게 두 가지 감각으로 나눌 수 있다. 하나는 서로 의견을 주고받는 토론형이고, 다른 하나는 순서대로 넘겨주는 파이프라인형이다.

토론형 구조는 탐색에 강하다. 문제 정의가 모호하거나, 여러 가설을 비교해야 하거나, 상충하는 관점을 함께 검토해야 할 때 유용하다. 예를 들어 제품 전략 초안, 리서치 해석, 복잡한 설계 대안 비교처럼 정답이 하나로 고정되지 않은 작업에서 힘을 발휘한다. 한 에이전트가 제안을 내고, 다른 에이전트가 반론을 제기하고, 세 번째 에이전트가 쟁점을 정리하면 생각의 폭이 넓어진다. 대신 비용이 늘고, 대화가 길어지며, 잘못 설계하면 끝없는 회의처럼 변한다.

파이프라인형 구조는 운영에 강하다. 입력이 들어오면 분류하고, 필요한 데이터를 모으고, 실행하고, 검증하고, 결과를 내보내는 식이다. 순서가 비교적 명확한 업무 자동화, 문서 처리, 코드 생성 후 테스트, 데이터 분석 리포트 생성 같은 작업에 적합하다. 토론형보다 재현 가능성이 높고, 실패 지점을 찾기 쉽다. 다만 앞단의 판단이 틀리면 그 오류가 뒤까지 흘러갈 수 있다.

쉽게 말해 토론형은 "생각을 넓히는 구조"이고, 파이프라인형은 "작업을 안정시키는 구조"다. 제품 환경에서는 대개 파이프라인형을 기본으로 두고, 꼭 필요한 구간에만 짧은 토론형 단계를 삽입하는 편이 좋다. 매번 전체 회의를 여는 조직보다, 정해진 절차 안에서 필요한 순간에만 검토 회의를 넣는 조직이 더 잘 돌아가는 것과 비슷하다.

조정자는 팀장이 아니라 교통정리 장치다

멀티에이전트 구조에는 종종 오케스트라 지휘자처럼 보이는 조정자가 등장한다. 하지만 조정자를 만능 관리자처럼 만들면 다시 단일 에이전트 문제로 돌아간다. 조정자는 모든 판단을 대신하는 존재가 아니라, 상태를 읽고 다음 경로를 선택하는 라우터에 가까워야 한다.

좋은 조정자는 세 가지를 한다. 첫째, 어떤 에이전트가 언제 호출되어야 하는지 결정한다. 둘째, 이전 단계의 출력이 다음 단계의 입력 조건을 만족하는지 확인한다. 셋째, 실패했을 때 재시도, 인간 승인 요청, 중단 중 어느 쪽으로 보낼지 판단한다. 반대로 조정자가 직접 계획도 하고 실행도 하고 검토도 하면 구조는 그럴듯해 보여도 실제로는 역할이 다시 한곳에 모인다.

따라서 조정자에게는 최소한의 판단 규칙만 주는 것이 안전하다. "검토 실패 시 최대 1회 재실행", "고위험 작업이면 사람 승인 요청", "입력 누락 시 종료"처럼 절차 중심의 결정을 맡기고, 내용 중심의 판단은 각 전문 역할에 남겨두는 편이 낫다.

에이전트 간 컨텍스트 전달은 적을수록 좋다

멀티에이전트가 어려운 이유 중 하나는 서로 많이 공유할수록 더 똑똑해질 것 같다는 착각 때문이다. 실제로는 반대인 경우가 많다. 모든 대화, 모든 로그, 모든 파일 목록을 다음 에이전트에 넘기면 컨텍스트가 풍부해지는 것이 아니라 오염된다. 다음 에이전트는 필요한 사실보다 이전 단계의 추측, 불완전한 가설, 이미 폐기된 시도까지 함께 물려받는다.

좋은 멀티에이전트 하네스는 대화를 전달하지 않고 상태를 전달한다. 즉, "무슨 이야기를 했는가"보다 "무엇이 결정되었는가"를 넘긴다. 이를 위해 각 단계의 출력 형식을 명확히 해야 한다. 예를 들어 계획자의 출력은 작업 목록과 성공 기준이어야 하고, 실행자의 출력은 실제 변경 사항과 실행 로그여야 하며, 검토자의 출력은 통과 여부와 수정 요청 항목이어야 한다. 자연어 대화 전체를 넘기기보다 구조화된 요약, 체크리스트, 상태 객체를 넘기는 편이 훨씬 안정적이다.

컨텍스트 전달에서 특히 중요한 것은 다음 세 가지다.

• 사실과 해석을 구분할 것

• 완료된 결정과 미확정 가설을 구분할 것

• 다음 단계에 필요한 정보만 전달할 것

이 원칙을 지키면 각 에이전트는 앞선 단계의 분위기에 끌려가지 않고, 자신의 역할에 집중할 수 있다. 멀티에이전트에서 컨텍스트는 많이 주는 것이 능사가 아니라, 적절히 다듬어 건네는 것이 실력이다.

충돌은 실패가 아니라 설계 대상이다

에이전트가 둘 이상이면 언젠가 서로 다른 결론이 나온다. 한 에이전트는 실행 가능하다고 하고, 다른 에이전트는 위험하다고 말할 수 있다. 이것은 멀티에이전트의 결함이 아니라 오히려 장점이다. 단일 에이전트에서는 이런 충돌이 내부에서 조용히 섞여 버리지만, 멀티에이전트에서는 드러난다. 문제는 충돌 자체가 아니라, 충돌을 처리하는 규칙이 없다는 데 있다.

충돌 해결 방식은 작업의 성격에 맞게 정해야 한다. 품질이 중요한 경우에는 보수적 규칙이 낫다. 예를 들어 검토자가 반대하면 자동 통과하지 않도록 할 수 있다. 속도가 중요한 경우에는 다수결이나 우선순위 규칙을 둘 수 있다. 예를 들어 분류 에이전트와 검토 에이전트가 다투면 검토 에이전트 판단을 우선한다는 식이다. 더 중요한 것은 충돌 사유를 기록하는 일이다. 누가 맞았는가보다 왜 의견이 갈렸는가를 남겨야 이후 하네스를 개선할 수 있다.

실무적으로는 충돌을 세 종류로 나누면 다루기 쉽다. 사실 충돌, 해석 충돌, 정책 충돌이다. 사실 충돌은 데이터 재조회로 해결할 수 있다. 해석 충돌은 추가 검토나 사람 승인으로 보내야 한다. 정책 충돌은 시스템 규칙을 더 명확히 써야 한다. 이 구분만 있어도 "왜 서로 싸우는지 모르는 상태"에서 벗어날 수 있다.

멀티에이전트의 품질은 개별 지능보다 인터페이스에서 나온다

멀티에이전트는 종종 더 많은 모델을 붙이면 성능이 좋아질 것처럼 이야기된다. 하지만 실제 품질은 에이전트 각각의 지능보다, 그 사이의 인터페이스가 얼마나 명확한지에 더 크게 좌우된다. 입력 스키마가 अस्पष्ट하고, 출력 형식이 제각각이며, 성공 조건이 불분명하면 똑똑한 에이전트 여러 개가 모여도 혼선만 커진다.

따라서 멀티에이전트 하네스를 설계할 때는 각 에이전트의 프롬프트보다 먼저 계약을 정의해야 한다. 무엇을 입력으로 받고, 무엇을 출력으로 내며, 어떤 경우에 실패를 선언하는지, 확신이 없을 때 어떤 상태값을 반환하는지 정해야 한다. 사람 팀에서도 일을 잘하는 팀은 말 잘하는 사람보다 인수인계가 잘 되는 팀이다. 에이전트도 마찬가지다.

멀티에이전트가 오히려 나쁜 선택인 경우

모든 작업이 멀티에이전트를 필요로 하지는 않는다. 오히려 단일 에이전트가 더 나은 경우가 적지 않다. 작업이 짧고, 도구 수가 적고, 실패 비용이 낮고, 검증 기준이 단순하다면 멀티에이전트는 과설계가 된다. 택배 상자를 옮기는데 지휘자, 운반자, 감사자를 모두 두는 셈이다.

특히 다음과 같은 경우에는 주의해야 한다.

• 한 에이전트로도 충분히 결정 가능한 단순 작업

• 에이전트 간 전달 비용이 실제 작업 비용보다 큰 경우

• 역할이 나뉘었지만 책임 경계가 불분명한 경우

• 검토 에이전트가 실질적 검증을 하지 못하는 경우

이런 상황에서는 멀티에이전트가 품질을 높이기보다 지연 시간과 비용, 디버깅 난이도만 늘릴 수 있다. 여러 에이전트를 쓰기로 했다면 먼저 물어야 한다. "이 분리가 실제로 위험을 줄이는가?" 이 질문에 답하지 못하면, 대부분은 하나의 에이전트와 더 좋은 검증 단계로 해결하는 편이 낫다.

실전 설계 원칙

멀티에이전트 하네스를 제품 수준으로 만들려면 몇 가지 원칙이 필요하다.

첫째, 역할은 기능이 아니라 실패 지점을 기준으로 나눈다. 어디서 잘못될 수 있는지 보이면, 어디를 분리해야 할지도 보인다.

둘째, 각 에이전트는 최소 권한만 가진다. 계획자는 읽기 중심, 실행자는 제한된 쓰기, 검토자는 승인 또는 반려 권한만 갖게 하면 사고 범위를 줄일 수 있다.

셋째, 전달되는 컨텍스트는 구조화한다. 자유로운 대화 기록보다 요약된 상태와 명시적 체크리스트가 더 믿을 만하다.

넷째, 충돌 해결 규칙을 미리 정한다. 누가 최종 결정을 내리는지, 언제 사람에게 넘기는지 없으면 협업은 곧 정체가 된다.

다섯째, 멀티에이전트의 목적을 늘 탐색이 아니라 검증에 둔다. 새로운 아이디어를 더 많이 만들기 위해서가 아니라, 잘못된 실행을 더 일찍 걸러내기 위해서다.

좋은 멀티에이전트는 작은 조직처럼 움직인다

결국 멀티에이전트 하네스는 작은 조직을 설계하는 일과 닮아 있다. 모두가 똑같은 정보를 들고, 모두가 모든 도구를 쓰고, 모두가 최종 결정을 내리는 조직은 금방 혼란에 빠진다. 반대로 역할이 분명하고, 인수인계가 깔끔하고, 갈등 처리 규칙이 있으며, 중요한 순간에 멈출 수 있는 조직은 안정적으로 성장한다.

좋은 멀티에이전트는 "여럿이 동시에 일한다"는 화려함보다 "서로를 믿지 않아도 돌아간다"는 견고함에서 나온다. 계획자는 실행자를 검증 가능한 형태로 움직이게 하고, 실행자는 검토자가 판단하기 좋은 결과를 남기며, 검토자는 다시 시스템 전체의 신뢰도를 높인다. 그렇게 역할이 연결될 때, 멀티에이전트는 복잡한 장식이 아니라 통제 가능한 생산 시스템이 된다.

멀티에이전트 하네스의 목표는 협업의 연출이 아니다. 격리, 검증, 추적 가능성이다. 여러 에이전트를 쓰는 이유는 더 복잡해지기 위해서가 아니라, 더 안전하게 실패하고 더 정확하게 책임을 나누기 위해서다. 그 점을 잊지 않는다면, 멀티에이전트는 데모용 묘기가 아니라 실제 제품을 지탱하는 설계 도구가 될 수 있다.