멀티에이전트 시스템이란? 여러 AI가 역할을 나눠 일하는 원리

1. 여러 번 질문하는 것과 여러 에이전트는 다르다

멀티에이전트 시스템은 여러 AI 에이전트에 서로 다른 책임을 맡기고, 결과와 제어권, 즉 다음 작업·응답 담당을 정하는 흐름을 주고받게 연결한 구조입니다. 여기서 에이전트는 지시와 도구 등을 바탕으로 작업하는 실행 단위, 즉 한 담당으로 묶어 실행하는 작업 주체입니다. 반드시 서로 다른 회사의 AI나 다른 모델이어야 하는 것은 아닙니다.

다만 “수집해 줘, 비교해 줘, 검토해 줘”라는 프롬프트(AI에게 주는 요청문)를 정해진 순서로 입력한다고 자동으로 멀티에이전트가 되지는 않습니다. Anthropic은 미리 정한 경로를 따르는 워크플로(정해 둔 작업 흐름)와 모델이 다음 행동을 결정하는 에이전트를 구분하며, 앞선 응답을 다음 입력으로 넘기는 방식을 프롬프트 체이닝(응답을 다음 요청에 이어 붙이기)으로 설명합니다. (Anthropic 공식 설명)

반대로 고정된 순서라도 별도로 구성한 여러 에이전트를 코드로 연결할 수는 있습니다. 핵심은 순서가 고정됐는지가 아니라 실제로 어떤 실행 단위를 연결했는지입니다. OpenAI도 모델이 흐름을 결정하는 방식과 코드로 조정하는 방식을 모두 안내합니다. (OpenAI의 작업 조정(오케스트레이션) 문서)

2. 단일 에이전트부터 시작할까, 역할을 나눌까?

이 글에서는 ‘가상의 제품 공지 3개 비교 보고서’를 만든다고 가정합니다. 아래 공지와 완성 보고서는 직접 작성한 설명용 가상 사례이며, 실제 제품 정보나 에이전트 실행 결과가 아닙니다. 작업 계약을 거쳐 어떤 결과를 남기는지 함께 살펴봅니다.

• 단일 구조 우선: 공지 3개가 짧고, 같은 비교 항목을 쓰며, 한 에이전트가 원문과 보고서를 함께 확인할 수 있다면 한곳에서 추출·비교·검토하게 합니다.
• 다중 구조 검토: 공지마다 다른 도구나 접근 권한이 필요하거나, 추출 담당과 검토 담당의 지시를 분리할 이유가 분명하다면 역할 분리를 검토합니다.
• 나누지 않을 이유: 담당끼리 전체 원문을 반복해서 전달해야 하거나, 결과를 합치는 일이 본 작업보다 복잡해지면 분리 이점이 작을 수 있습니다.

이는 성능 보장이 아니라 이 글의 설계 판단입니다. Anthropic도 가능한 한 단순한 해결책부터 시작하고 필요할 때 복잡성을 늘리며, 지연과 비용의 절충을 고려하라고 권합니다. (공식 설계 원칙) 같은 입력으로 누락·근거 오류·처리 부담을 비교하기 전에는 다중 구조가 더 낫다고 결론내리지 않습니다.

3. 시작 전에 공통 작업 계약을 적는다

Planning이 ‘어떤 단계를 어떤 순서로 할까’에 초점을 둔다면, 여기서는 ‘담당자가 무엇을 받아 무엇을 넘겨야 끝나는가’에 집중합니다. 아래 양식의 자동화에는 실행·전달·검사 기능을 별도로 연결해야 합니다. 수동으로 주고받는다면 협업 연습에 해당합니다. 실제 도구 호출과 실행의 구분은 도구 사용 글에서 확인할 수 있습니다.

다음 공통 계약의 대괄호를 실제 자료로 바꿔 사용하세요. 입력 버전은 담당자들이 같은 자료를 읽었는지 확인하는 판본 표시입니다. 원문이 없으면 빈칸을 사실처럼 채우지 않습니다.

과제: 가상의 제품 공지 3개 비교 보고서 작성.
입력: [공지 A/B/C 원문], [각 출처 URL 또는 문서명], [확인 기준일].
비교 항목: 변경 내용, 적용 대상, 시행일, 독자가 해야 할 일.
범위: 제공된 공지만 사용. 외부 검색·게시·파일 변경 금지.
공통 출력: 담당명 / 입력 버전 / 근거 목록 / 결과 / 미확인 항목 / 상태.
상태: 완료, 보완 필요, 입력 부족 중 하나. 미기재는 ‘원문에 없음’으로 기록.
종료: 세 공지와 네 비교 항목을 모두 확인하고, 미해결 충돌을 별도 표시한 초안을 사람이 승인하면 종료.

4. 역할별 입력·출력·완료 조건 템플릿

역할 이름만 붙이지 말고 아래 계약을 함께 전달합니다. 이 예시의 역할 수는 권장 정답이 아니라 책임을 설명하기 위한 구성입니다. 공지 ID는 A·B·C처럼 공지를 구별하는 이름이고, 근거 ID는 ‘A-1’처럼 뒷받침 문장을 다시 찾는 표식입니다.

추출 담당

맡은 범위: 배정받은 공지 [A/B/C] 한 개만 읽는다.
입력: 해당 공지 원문과 출처 식별자, 공통 계약.
출력: 공지 ID / 비교 항목 / 원문에서 확인한 사실 / 짧은 근거 인용 / 위치 / 미기재 여부.
완료 조건: 네 항목에 사실 또는 ‘원문에 없음’을 표시하고 모든 사실에 근거를 붙인다.
제한: 다른 공지를 추정하거나 제품 간 우열을 판단하지 않는다. 입력이 없으면 ‘입력 부족’으로 반환한다.

비교 담당

입력: A/B/C 추출 결과와 공통 계약.
출력: 항목별 공통점·차이점 / 연결된 근거 ID / 비교 불가 항목.
완료 조건: 세 공지를 같은 네 항목으로 다루고, 사실과 해석을 구분한다.
제한: 빠진 값을 추측해 채우지 않는다. 시행일과 발표일처럼 뜻이 다른 날짜는 같은 값으로 비교하지 않는다. 근거가 부족하면 추출 담당에게 항목을 지정해 돌려보낸다.

검토 담당

입력: 원문 세 개, 추출 결과, 비교 초안.
출력: 주장별 통과·수정·보류 / 원문 위치 / 수정 이유 / 필요한 추가 입력.
완료 조건: 비교 초안의 사실 주장을 모두 원문과 대조하고 미확인 목록을 남긴다.
제한: 말이 자연스럽다는 이유로 통과시키지 않는다. 다른 담당의 결론을 그대로 승인하지 말고 근거를 직접 확인한다.

조정 담당

입력: 공통 계약, 각 담당의 결과와 상태.
출력: 근거가 연결된 비교 보고서 초안 / 누락·충돌 목록 / 완료 또는 보류 사유.
완료 조건: 필수 항목 확인과 검토 결과 반영이 끝나고 남은 불확실성을 독자가 알 수 있다.
제한: 반려는 항목별 한 번만 재요청한다. 미해결이면 보류하고 사람에게 묻는다. 최종 게시 권한은 없다.

조정자가 최종 답변을 책임지고 전문가를 하위 작업에 호출하는 구조와, 전문가에게 대화의 제어권을 넘기는 핸드오프(다음 응답 담당까지 넘기기)는 다릅니다. 이 계약은 전자에 가까운 설계입니다. (OpenAI의 agents as tools와 handoffs 구분)

완성 예시: 공지 3개 비교 보고서

가상 공지 A/B/C의 핵심문장

• A-1: “제품 A는 관리자에게 CSV(표의 값을 쉼표로 구분해 저장하는 파일 형식) 내보내기를 추가합니다. 시행일은 2026년 12월 1일입니다. 사용하려면 설정에서 내보내기를 켜세요.”
• B-1: “제품 B는 검색 필터를 추가합니다. 기존 이용자는 별도 조치 없이 사용할 수 있습니다.”
• C-1: “제품 C는 팀 관리자에게 알림 묶음 기능을 추가합니다. 시행일은 2026년 12월 5일입니다.”

완성 비교 보고서 | 입력 버전: 설명용 1판

표를 좌우로 밀어 전체 열을 확인하세요.

공지	변경 내용	적용 대상	시행일	독자가 해야 할 일	근거
A	CSV 내보내기 추가	관리자	2026-12-01	설정에서 내보내기 켜기	A-1
B	검색 필터 추가	미기재(원문에 없음)	미기재(원문에 없음)	기존 이용자는 별도 조치 없음	B-1
C	알림 묶음 추가	팀 관리자	2026-12-05	미기재(원문에 없음)	C-1

비교 결론: 세 공지는 모두 기능 추가를 알리지만 기능의 종류가 다릅니다. A·C는 적용 대상과 시행일을 명시하고, B는 기존 이용자의 조치 여부만 명시합니다. B의 ‘기존 이용자’라는 문장만으로 전체 적용 대상을 확정하지 않습니다. A는 설정 변경이 필요하고 B는 기존 이용자의 조치가 불필요하며, C는 조치 여부를 알 수 없습니다. 기능의 목적과 빠진 조건이 달라 우열 점수는 매기지 않습니다.

검토 결과와 남은 질문: 표의 기재 내용은 A-1~C-1과 대조했습니다. B의 적용 대상·시행일과 C의 조치 여부는 추가 확인 항목이며 추정하지 않았습니다. 설명용 보고서는 작성 완료, 실제 사용·게시 판단은 사람 검토 대기입니다.

직접 따라 하는 수동 협업 실습

아래는 새 대화와 텍스트 붙여넣기를 지원하는 AI 도구에서 따라 할 수 있도록 작성한 실행 제안입니다. 이 프롬프트를 실제 도구에 입력해 시험한 결과는 아닙니다. 앞의 완성 보고서는 정답 비교용으로 남겨 두고 AI 입력에는 넣지 않습니다. 우선 위 가상 공지 A-1·B-1·C-1만 사용하세요. 실제 고객·회사 자료를 넣거나 새 유료 기능을 결제할 필요는 없습니다.

준비: 대화 6개를 만들고 메모에 ‘A 추출, B 추출, C 추출, 비교, 검토, 통합’으로 구분합니다. 도구가 대화 이름 변경을 지원하지 않으면 번호로 기록하면 됩니다. 같은 모델을 사용해도 되며, 역할을 나눈 대화가 자동으로 서로의 내용을 읽는다고 가정하지 않습니다.

1단계: 추출 담당을 세 번 실행합니다. 아래 프롬프트를 A 추출 대화에 넣고, [원문] 자리에 위 A-1의 문장을 붙입니다. B·C도 별도 대화에서 공지 ID와 원문만 바꿔 실행합니다.

당신의 작업은 현재 제공한 공지 한 개에서 사실을 추출하는 것입니다.
공지 ID: A
입력 버전: 설명용 1판
원문: [여기에 위 A-1 문장 전체를 붙여넣기]

외부 검색이나 다른 공지의 내용을 사용하지 마세요.
변경 내용, 적용 대상, 시행일, 독자가 해야 할 일을 각각 한 행으로 정리하세요.
출력 열: 공지 ID | 비교 항목 | 확인한 사실 | 짧은 근거 인용 | 근거 ID.
원문에 없는 값은 '미기재(원문에 없음)'으로 쓰세요.
근거 ID는 A-1로 표시하세요. 원문이 비어 있으면 결과를 만들지 말고 입력을 요청하세요.

B 대화에서는 공지 ID: B, 근거 ID: B-1로, C 대화에서는 C와 C-1로 바꿉니다. 각각 네 항목이 있는지 확인하고 응답을 메모장에 복사합니다. 빠진 값이 채워져 있으면 추출 담당에게 해당 항목만 원문과 다시 대조하도록 요청하세요.

2단계: 비교 대화에 추출표 세 개를 전달합니다. 대괄호 위치에는 직접 복사한 내용을 넣습니다. 다른 대화의 결과를 모델이 알아서 가져오지는 않습니다.

아래 추출표를 같은 기준으로 비교해 보고서 초안을 작성하세요.
입력 버전: 설명용 1판
원문 A-1/B-1/C-1: [위 가상 공지 세 문장]
추출표 A/B/C: [1단계의 응답 세 개]

출력은 다음 세 부분으로 제한하세요.
1) 공지 | 변경 내용 | 적용 대상 | 시행일 | 독자 조치 | 근거 ID의 비교표
2) 공통점과 차이점 3문장 이내
3) 추가 확인이 필요한 항목 목록

'미기재'는 추측으로 채우지 마세요. 발표일과 시행일을 섞지 마세요.
같은 종류의 기능이 아니면 성능·품질·우열 점수를 만들지 마세요.
원문과 추출표가 다르면 충돌 항목을 표시하고 보류하세요.

3단계: 검토 대화에서는 원문을 다시 제공합니다. 비교표만 넘기면 앞 단계의 잘못된 값이 그대로 승인될 수 있습니다.

아래 보고서의 사실 주장을 원문과 하나씩 대조하세요.
원문 A-1/B-1/C-1: [위 가상 공지 세 문장]
비교 보고서 초안: [2단계 응답]

출력 열: 주장 또는 표 항목 | 원문 근거 ID·인용 | 일치/수정/보류 | 이유 | 수정 제안.
공지가 말하지 않은 적용 대상·시행일·조치가 추가됐는지 확인하세요.
확인되지 않은 값은 '보류'로 남기고, 다른 담당의 결론만 근거로 쓰지 마세요.

사람도 세 원문과 검토표를 대조합니다. 의견이 다르면 “어느 원문 구절 때문인가?”를 확인하고, 같은 항목은 한 번만 재요청한 뒤 남은 문제를 보류합니다. 검토 역할의 응답 자체가 정답이라는 뜻은 아닙니다.

4단계: 통합 대화에서 최종 초안을 만듭니다.

원문 A-1/B-1/C-1: [가상 공지 세 문장]
비교 초안: [2단계 응답]
검토표와 사람이 확인한 수정 항목: [3단계 결과 및 확인 메모]

일치가 확인된 항목과 원문으로 확인된 수정만 반영하세요.
최종 출력: 비교표 / 차이점 요약 / 미기재·보류 목록 / 사람 검토 대기 상태.
원문과 검토 의견이 충돌하면 임의로 확정하지 말고 보류하세요.
외부 검색·게시·파일 수정은 하지 마세요.

최종 산출물을 앞의 가상 완성 보고서와 비교해 보세요. B의 적용 대상·시행일과 C의 조치 여부를 추정하지 않았는지, A의 설정 변경 조건이 남았는지를 확인합니다. 실제 응답이 예시와 다르면 차이를 기록하되, 문장 표현이 다르다는 이유만으로 실패로 판정하지는 않습니다.

이 실습은 수동 협업입니다. 사람이 다음 역할을 선택하고, 입력을 복사하고, 응답을 대조합니다. 실제 멀티에이전트 자동화라면 프로그램이 별도의 에이전트 실행 단위에 역할을 배정하고 필요한 상태·결과를 전달하며, 실패·상한·승인 조건에 따라 다음 호출이나 중단을 처리해야 합니다. 단순히 대화를 여섯 개 만들거나 같은 프롬프트를 순서대로 넣은 것만으로 이 연결이 구현되지는 않습니다. 코드에 의한 연결과 모델에 의한 조정의 차이는 OpenAI 작업 조정 문서에서 확인할 수 있습니다. 이 글은 그 자동화 시스템을 구축하거나 시험했다는 뜻이 아닙니다.

5. 중복·충돌·실패는 이렇게 처리한다

중복: 결과마다 ‘공지 ID+비교 항목+원문 위치’를 붙입니다. 같은 조합이 반복되면 조정 담당이 하나로 합치고 원래 근거를 보존합니다. 문장이 비슷해도 공지가 다르면 임의로 삭제하지 않습니다.

충돌: 같은 항목에 다른 값이 나오면 다수결로 확정하지 않습니다. 검토 담당이 적용 대상·문서 버전·날짜 의미를 다시 확인합니다. 명시적인 정정 근거가 없다면 최신 날짜라는 이유만으로 하나를 선택하지 않고 두 값과 차이를 남겨 보류합니다.

실패: 원문 누락, 읽기 실패, 출력 형식 누락은 ‘입력 부족’ 또는 ‘보완 필요’로 반환합니다. 실패를 빈 결과로 숨기거나 무한 재시도하지 않습니다. 조정 담당은 빠진 입력과 다음 요청을 한 문장으로 적습니다.

검토 역할이 있다는 사실만으로 정확성이 보장되지는 않습니다. 이 글의 핵심은 AI 숫자를 늘리는 것이 아니라 책임 경계, 근거 연결, 멈출 조건을 먼저 정하는 데 있습니다. 실제 도입 여부는 이 계약으로 만든 초안이 단일 구조보다 검증하기 쉬운지를 확인한 뒤 결정하세요.