‘여럿이 협력한다’는 말을 실제 인계 규칙으로 바꾼다
보고서 작성 시스템에 조사 에이전트, 계산 에이전트, 편집 에이전트를 붙였다고 해 봅시다. 이름만 나누면 같은 내용을 세 번 만들거나, 서로의 결과를 끝없이 고쳐 달라고 보내는 순환이 생길 수 있습니다. 협업 그래프는 노드에 역할과 책임, 연결선에 과제·결과·오류·승인 같은 전달물을 적습니다. 시작 노드와 최종 결과의 소유자, 반복 횟수와 사람에게 넘기는 조건도 표시합니다. 여러 역할을 쓰는 목적은 등장인물을 늘리는 데 있지 않고, 서로 다른 도구와 검토 기준을 분리해 추적 가능하게 만드는 데 있습니다.[1]
누가 시작하고 무엇을 돌려주는지 알 수 없습니다.
조사자 → 조정자: 근거·출처
조정자 → 사람: 검토본·미확인 항목
에이전트·도구·저장소·사람을 같은 존재로 그리지 않는다
둥근 상자는 과제를 받아 다음 행동을 선택하는 에이전트 역할, 사각형은 검색·계산기 같은 도구, 열린 저장소는 공유 작업 기록, 사람 모양은 승인자처럼 구분할 수 있습니다. 선의 방향은 메시지나 과제의 이동이며 ‘호출’보다 “검색어”, “근거 묶음”, “수정 요청”처럼 내용을 적습니다. 한 역할이 LLM을 사용해도 그 역할 자체가 모델과 같지는 않습니다. 에이전트는 모델 호출, 도구 사용, 규칙과 상태 관리를 묶은 시스템 구성입니다. 여러 에이전트가 같은 기반 모델을 공유할 수도 있습니다.
관리자형·순차형·공유판형의 장단점을 비교한다
관리자형에서는 조정자가 과제를 나누고 결과를 모으므로 책임과 종료 조건을 한곳에 둘 수 있지만 조정자가 병목이 될 수 있습니다. 순차형은 조사 결과를 계산자와 편집자에게 차례로 넘겨 단순하지만 앞 단계의 오류가 뒤로 전달되기 쉽습니다. 공유판형은 여러 역할이 공통 작업 상태를 읽고 갱신하여 유연하지만 누가 어떤 값을 바꿨는지 충돌 규칙이 필요합니다. 서로 직접 대화하는 완전 연결형은 작은 실험에는 편해도 역할 수가 늘면 선과 가능한 경로가 급격히 많아집니다.
| 구조 | 장점 | 확인할 위험 |
|---|---|---|
| 관리자형 | 책임·종료 판단이 분명함 | 조정자 병목·오판 |
| 순차형 | 단계와 입력이 단순함 | 앞 오류의 연쇄 전파 |
| 공유판형 | 병렬 작업과 재사용 | 갱신 충돌·오래된 상태 |
조사·수치 확인·편집을 분리하되 출처는 끝까지 유지한다
지역 독서율 보고서를 만드는 교육용 시스템을 생각해 봅시다. 조정자는 질문을 ‘공식 통계 찾기’, ‘증감률 계산’, ‘설명문 작성’으로 나눕니다. 조사 역할은 원자료 URL, 발표 기관, 기준 연도와 표의 행 번호를 돌려줍니다. 계산 역할은 조사 결과에서 지정된 수치만 사용해 식과 결과를 남깁니다. 편집 역할은 근거 식별자를 문장에 붙이되 새로운 수치를 만들지 않습니다. 조정자는 미확인 항목이 있으면 발행 대신 사람 검토로 보냅니다. 이 구조는 각 역할이 잘하는 일을 나누면서 출처 연결을 잃지 않게 합니다.
URL·기관·연도·행 번호
식·입력값·결과
코드 검토와 고객 지원은 종료 조건이 다르다
코드 수정 시스템에서는 구현 역할이 패치를 만들고 시험 역할이 정해진 테스트를 실행하며, 실패하면 오류 로그와 실패한 시험 이름을 구현 역할로 돌려보냅니다. 반복은 최대 두 번처럼 제한하고 보안 관련 실패는 사람에게 넘깁니다. 고객 지원 시스템에서는 분류 역할이 문의 유형을 정하고 지식 검색 역할이 승인 문서를 찾으며 답변 역할이 초안을 만듭니다. 환불·계정 잠금처럼 권한이 필요한 행동은 사람이 승인합니다. 두 사례의 그래프 모양은 비슷해도 성공 기준과 사람 개입 조건은 다릅니다.
| 사례 | 자동 완료 | 사람에게 넘김 | 반복 제한 |
|---|---|---|---|
| 코드 수정 | 필수 시험 모두 통과 | 보안 실패·설계 변경 | 수정 2회 |
| 고객 지원 | 승인 문서로 안내 답변 | 환불·계정 변경·낮은 확신 | 재검색 1회 |
역할마다 입력·도구·출력·금지 행동을 적는다
협업 그래프를 요청할 때 역할 이름만 주면 LLM은 일반적인 대화선을 만들기 쉽습니다. 각 역할의 입력, 사용할 수 있는 도구, 내놓을 결과 형식, 금지 행동과 완료 조건을 표로 줍니다. 누구든 다른 역할을 무제한 호출하지 못하게 허용된 연결과 최대 반복 횟수를 정합니다. 공유 상태를 쓰면 읽기·쓰기 권한과 충돌 규칙을 적습니다. 실제 내부 추론이나 숨은 사고 과정을 그리라고 요구하지 않고, 관찰 가능한 요청·도구 호출·결과·승인 기록만 도표에 넣습니다.
다음 보고서 작성 시스템을 에이전트 협업 그래프로 정리해 주세요. 조정자: 질문을 나누고 완료 기준을 확인한다. 도구 사용 없음. 조사자: 공식 자료 검색만 사용. 출력은 URL·기관·연도·인용 위치·요약. 계산자: 전달받은 수치만 계산기에 넣는다. 출력은 식·입력값·결과. 편집자: 조사·계산 결과를 문장으로 묶는다. 새 사실과 수치를 만들지 않는다. 사람 검토자: 미확인 출처, 민감 내용, 발행 여부를 판단한다. 연결: 조정자만 과제를 배분하고 결과를 모은다. 수정 반복은 최대 2회다. 금지: 모델의 숨은 사고 과정을 노드로 그리지 않는다. 사람 승인 없이 발행하지 않는다. 출력: ① 역할 계약표 ② 협업 그래프 ③ 실패·종료 조건 ④ 빠진 권한 질문.
끝없는 대화와 책임 없는 다수결을 막는다
잘못된 그래프는 모든 역할이 서로 수정 요청을 보낼 수 있고 종료 조건이 없습니다. 조사자는 편집자에게 더 찾아보라고 하고, 편집자는 조사자에게 다시 쓰라고 하며, 검토자는 새 기준을 추가해 순환합니다. 또는 세 에이전트가 다수결로 사실을 확정하도록 만들기도 합니다. 같은 오류를 공유하는 모델 세 개의 일치는 사실 검증이 아닙니다. 수정할 때는 허용된 연결, 반복 횟수, 검증 자료와 최종 책임자를 고정합니다. 충돌은 원자료와 규칙으로 해결하고 판단 권한이 필요한 사안은 사람에게 넘깁니다.
누구나 다시 요청하고 멈출 기준이 없습니다.
실패 시 최대 2회 수정
계속 실패하면 사람 검토
협업 그래프는 구조, 시퀀스는 한 실행의 시간 순서를 보여 준다
협업 그래프는 가능한 역할과 허용된 전달 관계를 나타냅니다. 어느 조사자가 언제 먼저 답했는지는 알 수 없습니다. 제7회의 시퀀스 다이어그램은 한 사례에서 실제 메시지가 오간 순서를 보여 줍니다. 제10회의 시스템 구성도는 에이전트가 어느 애플리케이션에서 실행되고 어떤 저장소와 모델을 쓰는지 보여 줍니다. 12회의 실행 추적 트리는 실제 한 번의 실행에서 생성된 호출과 자식 작업을 기록합니다. 설계 가능한 연결과 실제로 지나간 경로를 분리해야 “그럴 수 있음”을 “그렇게 실행됨”으로 오해하지 않습니다.
| 도표 | 보여 주는 것 | 확정할 수 없는 것 |
|---|---|---|
| 협업 그래프 | 역할·허용 연결·책임 | 특정 실행의 실제 순서 |
| 시퀀스 | 한 시나리오의 메시지 순서 | 모든 가능한 경로 |
| 실행 추적 트리 | 관찰된 호출·시간·오류 | 기록되지 않은 내부 과정 |
역할 수와 연결 방식에 따라 검토할 선의 수를 계산하자
역할 네 개가 모두 서로 직접 요청을 보낼 수 있으면 방향 있는 연결은 최대 12개입니다. 관리자형으로 조정자 한 명이 세 전문 역할과 왕복하면 6개입니다. 연결 수가 줄면 항상 성능이 좋아지는 것은 아니지만, 허용 관계와 책임을 검토하는 부담은 줄어듭니다. 아래에서 역할 수와 구조를 바꾸어 가능한 연결 수를 비교하고, 실패가 생겼을 때 어디에서 차단하기 쉬운지 살펴보세요.