[AI 전사발표] 멀티 에이전트 시스템

샌드위치데이 8회차

멀티 에이전트 시스템(MAS)

2026-05-13(수)

 

최근에 회사에서 AI 관련 전사발표를 진행하게되어 해당 내용을 기록하려고 한다.

방향성이 단순 AI 활용이었기에 너무 범용적이라 주제를 선정하는 부분에서 고민이 되었다.

 

발표 준비를 할 때는 어떤 내용을 해야하나 머리가 아팠지만

막상 발표를 할 때 편안했고 잘 마무리할 수 있어서 대학생 때 느꼇던 성취감을 오랜만에 느껴봐서 좋은 경험이었다.

 

 

샌드위치데이_멀티에이전트시스템.pdf

5.68MB

 

---

 

 

주제 및 목차

주제 선정에 있어서 초반에 단순히 1.두 개의 모델을 사용한 개발 성능 향상과 요즘 핫한 2.하네스 엔지니어링과 주제를 두고 고민했었다.

 

1번의 경우에는 cluade + codex로 개발자 + 평가자 역할로 구분해서 이론 설명과 시연을 구상했고,

2번의 경우에는 시연까지는 준비하기 애매한 감이 있어서 이론+트렌드+회사적용방안과 같은 구조를 구상했다.

 

1번은 너무 내용이 가벼운 듯 하고 요즘 트렌드보다 뒤쳐진다는 생각이 들어서 아쉬웠고,

 

2번은 발표 주제로 하기에 내가 잘 이해하고 설명을 할 수 있을지 자신이 없었다. 

또한 발표의 주제가 명확하지 않고 방황할 것 같다는 예상이 들었다. 청중이 "그래서 말하고 싶은게 먼데?" 라고 할 것만 같았달까..

 

 

그렇기에 두 개의 주제 가운데 있는 멀티 에이전트 시스템을 다뤄보자고 생각했고, 

멀티 에이전트 시스템에 대한 기본적인 설명과 실제 사례를 들어서 멀티 에이전트 구조의 중요성을 체감해보고

이후 사내 솔루션에 적용할 수 있는 가치에 대해서 발표하면 좋겠다는 생각으로 발표 준비를 시작했다.

---

목차는 아래와 같다.

 

ppt는 젠스파크를 사용했다.

무료로 써보다가 나름 잘 만들어주는 것 같아서 처음으로 한달 결제를 진행했다.(비싸다)

 

근데 얘도 프롬프트 입력을 너무 장황하게 하거나 성의없이 적으면 자료가 잘 나오지 않아서 직접 구조를 구성해서 알려주고 4~5번 정도 시도 및 수정 끝에 원하는 모양대로 생성하게 됬다.

그러다보니 8000 크레딧이나 사용했다;

 

ai 써서 발표자료 만들어보니.. 이제 직접 ppt 만드는건 못하겠다.

 

 

발표 상세내용

 

최근에 2026년도 상반기에 Claude Code의 성능이 급격하게 하락하는 이슈가 있었다.

Anthropic 측은 공식적으로 세 가지 원인을 발표했는데, 그 내용은 다음과 같다.

 

[이슈 사후 보고서]

1. 기본 사고 수준 설정 변경
2. 캐시 최적화 과정의 버그
3. 응답 길이를 줄이기 위한 시스템 프롬프트 수정 

앤트로픽은 이 조치들이 기저 모델 자체를 변경한 것은 아니라고는 했지만 사용자들이 체감하기에 성능 이슈가 크게 다가왔다.

해당 사건을 기반으로 개발자들은 하나의 모델에만 의존하면 위험하겠다는 생각을 하게 되었고 여러 개의 모델을 조합해서 사용하는 워크플로우의 필요성을 느끼게 되었다.

 

그의 대표적인 방식이 여러 모델을 융합하는
Claude + Codex, Cursor + Claude 같은 구조인 것이다.

---

 

단일 에이전트, 즉 모델 하나만 쓰는 구조에는 두 가지 본질적인 한계가 있다.

 

첫 번째는 컨텍스트 불안(Context Anxiety)이다.

대화가 길어질수록 모델이 초반 지시를 잊거나, 이미 수정한 파일을 또 수정하거나,
후반부에서 품질이 급격히 떨어지는 현상이다.

 

실제로 많이 보이는 부분이 AI가  “이미 수정했습니다”라고 말했는데 실제로는 안 된 경우이다.

 

두 번째는 자기 평가 편향(Self-Evaluation Bias)이다.

AI가 자기 결과물을 스스로 검토하면 대부분 “잘 됐다”고 판단하는데,

사람도 자기 글 오탈자를 잘 못 보듯이, 모델도 자기 코드의 결함을 잘 못 찾는 것이다.

 

특히 코드 리뷰 실험들을 보면 다른 모델이 검토할 때보다 자기 검토 시 버그 검출률이 낮게 나오게 된다.

 

이와같이 단일 에이전트 구조는 “기억 문제”와 “자가 검토 문제”를 동시에 가지고 있다.

 

---

 

그래서 등장한 게 멀티 에이전트이다.

핵심 아이디어는 단순하다.— "AI에게 역할을 분리해서 부여하자" 

 

하나의 모델이 설계, 구현, 검토를 다 하는 게 아니라,

• 계획하는 역할, 실제 만드는 역할 , 검토하는 역할

로 역할을 분리하는 거다.

• Planner : 작업을 분해하고 방향을 정함
• Generator : 실제 코드나 문서를 생성
• Evaluator : 결과가 제대로 되었는지 검토.

이렇게 역할을 나누면
각 에이전트는 자기 작업 범위만 집중하면 되기 때문에 컨텍스트 부담이 줄어들고,

그리고 검토를 다른 모델이 하니까 자기 평가 편향도 구조적으로 줄어들게 된다.

---

 

멀티 에이전트의 기본 아키텍처는 역할의 순환 구조이다.

해당 구조는 내가 임의로 설계자, 생성자, 평가자의 세 가지 구조로 구성했다. 

 

1. 먼저 사용자 요청이 들어오면, 먼저 설계자(Planner) 가 작업을 작게 쪼개고 검증 기준까지 정의한다.

2. 그 다음 생성자(Generator) 가 좁은 컨텍스트에 집중해서 실제 코드나 문서를 생성한다.

3. 마지막으로 검토자(Reviewer) 가 결함, 환각, 정합성을 확인한다.

4. 검토자가 문제를 발견하면 다시 설계자로 돌아가서 반복한다.

통과하면 최종 결과로 확정된다.

 

이 ①→②→③→다시 ① 루프가 합의에 이를 때까지 돌면서 품질을 끌어올리게 되는 것이다.

 

물론 이러한 아키텍처는 사용자에 따라 다양한 조합법이 나올 수 있고 AI 에이전트에게 어떠한 역할을 분할하냐에 따라서 달라질 수 있다.

그래서 회사에 맞는, 서비스에 맞는 구조를 설계하는 것이 중요하다.

---

 

멀티 에이전트 시스템의 장점은 크게 네가지로 구분 할 수 있다.

• 첫째, 컨텍스트 분산 - 각 에이전트가 자기 일에만 집중하니까 망각이 안 일어남
• 둘째, 자기 평가 편향 차단 - 만든 사람과 검토하는 사람이 다른 모델이니까 결함이 잘 보임
• 셋째, 병렬 처리 - 독립 작업은 동시에 진행할 수 있어서 전체 작업 속도가 빨라짐
• 넷째, 하네스 교체 가능성 - 코드 생성은 Claude, 리뷰는 GPT, 검색은 다른 모델과 같이 역할별 최적 모델을 붙일 수 있음

---

 

첫 번째 사례는 Claude + Codex의 결합이다.

가장 단순한 멀티 에이전트 사례라고 볼 수 있다.

 

실제 사례 두 가지를 준비했는데

첫 실제 사례는 Claude가 MCP 브리지 코드를 작성했고, Codex가 리뷰를 진행했을 때, Claude가 못 본 버그 세 개를 잡아낸 것이다.

 

여기서 MCP 브리지 코드는 AI와 외부 도구를 연결하는 중간 레이어 코드라고 이해하면 되는데,
예를 들어 AI가 터미널 실행이나 파일 접근을 할 때 그 연결을 담당하는 부분이다.

 

버그 세 가지는 아래와 같다.

1. 종료 코드 처리 구멍 - 자식 프로세스가 비정상으로 끝나도 exit code를 안 봐서 실패가 성공처럼 위로 전달되던 경로
2. ANSI escape 인젝션 위험 - 외부 입력의 이스케이프 시퀀스를 검증 없이 출력해서 터미널 화면이나 로그를 위조할 수 있는 보안 결함
3. 경로 두 번 적용 버그 - 베이스 경로가 두 군데서 결합돼서 prefix가 중복되는, 특정 환경에서만 터지는 간헐 장애

---

두번째 실제 사례는 사이드바 리팩터링 작업이다.

변경 범위가 위저드 흐름, 상태 관리, 여러 화면에 걸쳐 있는 큰 작업이었는데, Codex가 점검을 시작해서 6분 35초 만에 엣지 케이스 네 개를 보고했다.

 

케이스 네 가지는 아래와 같다.

1. 필수 설정이 안 된 상태에서 제출 버튼이 조용히 실패하는 케이스.
2. 앞 단계 검증을 건너뛰고 리뷰 단계로 그냥 점프 가능한 흐름.
3. 실행 도중에 뒤로 가기로 끊으면 복구 불가
4. 동시 요청이 상태를 덮어써서 결과가 비결정적이 되는 문제

 

위 실제 사례들로 볼 수 있는 중요한 핵심은 이 버그들이 “코드를 모르는 사람이 봐서 발견된 문제”라는 점이다.

자기가 만든 코드는 자기 관점으로 보게 되는데, 다른 모델은 처음 보는 코드이기 때문에 다른 시각으로 문제를 발견한 것이다.

---

 

두 번째 사례는 Anthropic의 실험이다.

Anthropic 측은 똑같이 "레트로 게임 만들어줘" 라는 한 줄 프롬프트를 두 가지 구성에 던졌는데, 같은 클로드 모델을 사용했지만 역할의 유무에 따라서 결과는 배우 상반되게 나왔습니다.

 

왼쪽은 단일 에이전트 구조로 Claude 한 개가 설계/구현/검토를 다 진행했다.

 

과연 결과는 어땟을까?

 

API 비용 9달러를 쓰고 멈춰버렸다.

자기 검토에 막혀 설계가 진척이 안 되고, 같은 파일을 반복 수정하다 컨텍스트가 다 차버렸던 것이다.

최종적으로 완성된 기능은 0개 였으며 캐릭터가 움직이지도 않았고 실행 가능한 빌드조차 없었다.

---

오른쪽은 같은 Claude 모델을 세 개 인스턴스로 나눈 멀티 에이전트 구조이다.

설계자, 생성자, 검토자로 역할만 분리해서 진행했다.

 

이쪽의 결과는 어땟을까?

 

200달러, 약 22배의 비용이 들었지만 플레이어 이동, 충돌 판정, 점수와 HP, 적 AI, 스테이지 두 종, 사운드, 메인 메뉴까지 실제로 플레이 가능한 게임이 나왔다.

 

핵심은 설계·생성·검증 3단 구조다.

▲설계자가 작업을 잘게 쪼개고 ▲생성자가 코드를 짜고 ▲검증자가 실제 화면을 돌아다니며 결과물을 채점하는 것인데,

AI 이미지 생성 기술인 생성적 적대 신경망(GAN)에서 착안한 방식이다.

 

 

핵심은 이거다. 모델을 바꾼 게 아니라는 것. 같은 모델을 어떻게 조합하느냐만 바꿨는데,

"기능 0개"와 "완성된 게임"으로 결과가 갈렸다. 비용이 22배가 아니라, 가능한 결과의 차원 자체가 달라진 것입니다.

 

---

 

최신 동향을 한 장에 담아 보았다.

시간 축과 복잡도 축으로 보면 네 단계로 진화해 왔음이 보인다.

 

• L1 단일 프롬프트 시대(2022~2023): 한 채팅창에 모든 컨텍스트를 넣고 모델 자체가 결과의 천장
• L2 멀티 에이전트 시대(2023~2024): 작성자와 검토자가 분리되면서 자기 평가 편향을 깨기 시작
• L3 3 에이전트 시대(2024~2025): 설계자까지 추가되고 서브 에이전트 위임이 일반화
• L4 하네스 엔지니어링시대(지금): 도구, 메모리, 라우팅까지 하나의 골격으로 묶이는 단계

 

한 단계 올라갈 때마다 결과 품질의 한계 자체가 한 단계씩 옮겨졌다는 게 핵심이다.

---

 

이제 사내 적용 방안에 대한 이야기이다.

 

현재(As-Is) 는 Cursor 단독 구조이며, Cursor가 작성한 코드를 같은 Cursor가 검토하니까 자기 평가 편향이 그대로 있고,단일 에이전트의 단점이 그대로 존재한다.

 

가장 빠른 적용은 역할 분리(To-Be) 이다.

Cursor를 메인 개발자로, 즉 코드를 직접 쓰는 생성자로, Claude를 검토자·리뷰어로 두는 것이다.

 

Cursor 같은 경우 통합 IDE를 제공하고 Claude는 터미널에서 사용 가능하기에 유연하게 사용할 수 있을 것 같아서 가장 쉽고 빠르게 적용 할 방안에 대해서 이야기를 했다.

---

 

이후는 확장에 대한 추후 방향성에 대해서 이야기했는데,

역할 분리로 시작했다면 그 다음 단계는 전용 에이전트를 한 단계씩 추가해서 키워가는 구조를 설계하는 방안이다.

 

위에 설계자가 작업을 라우팅하고, 아래로 Cursor 개발자와 Claude 리뷰어가 이미 있는 상태이다.(듀얼 적용 상태)

 

여기에 Phase 1으로 QA 모델을 붙인다. (테스트 생성과 실행을 자동화하는 전용 에이전트)

그 다음 Phase 2로 보안 모델, 더 나아가 문서 에이전트까지 점진적으로 추가하며, 모두 공유 컨텍스트 레이어 위에서 결과를 주고받는 것이다.

 

오른쪽에 전략적 가치 세 가지를 정리했는데 다음과 같다.

1. 병목 해소 - QA가 자동으로 테스트를 생성·실행하면 사람 리뷰어 한 명에게 걸리던 부담이 분산됨
2. 품질의 다층 방어 - 코드·테스트·보안 검증이 서로 다른 모델로 이루어져 단일 모델의 사각지대가 사라짐
3. 사내 자산으로 누적 - 도구 정의, 역할 분리, 평가 기준은 모델이 바뀌어도 회사에 남음. 한 팀이 만들면 모든 팀이 같이 쓰는 자산이 되는 것

---

 

그래서 해당 발표를 간단히 정리하면 이 한 문장이다.

 

"모델이 좋아져도, 하네스 조합의 가능성은 줄어들지 않는다. 이동할 뿐이다.“

 내가 한 말은 아니고 엔트로픽 연구진이 한 말이다.

 

 더 좋은 모델이 나와도, 우리가 만들 수 있는 조합의 가능성은 그대로 남거나 오히려 더 넓어진 다는 것이다.

 

앞으로의 질문은 단순히 “gpt가 좋나? 클로드가 좋나? 어느 모델이 성능이 최고인가?”가 아니라.

“다양한 모델들을 어떻게 조합해서 운영하는 것이 효율적일까?”로 바꿔야 할 때인 것 같다.

 

해당 발표에서 가져갈 세 가지를 정리하면 — 첫째, 역할을 나누자. 둘째, 다른 모델로 검증하자. 셋째, 그렇게 만든 구조를 사내 자산으로 쌓자. 이다.

 

 

발표 후기

 

발표날 이전 1~2주 전쯤에 발표 대상자가 되어 준비했었다.

 

이미 이전까지 할만한 주제들이 다 나온듯 하여 천천히 주제를 서칭하다가 팀 회의때 "커서vs클로드"해보는 것이 어떠냐고 의견이 나오게 되었고 거의 픽스가 되었던 상황이었다.

 

그런데 발표를 하기에 주제가 조금 애매한 것 같고.. 내 성에 차지 않아서 전날에 주제를 바꾸고(MAS) 발표준비를 하루동안 진행했다.

하고 싶은 주제를 해도 된다고 팀장님이 말씀하셨고, 이전에 멀티에이전트 시스템은 나온적이 없다고 하셔서 바꾸었다.

 

이후 유튜브 & 지인찬스 등등 활용하며 목차 구성부터 어떻게 내용을 구상할지 짜고, PPT 생성 및 발표 흐름을 구성했다.

 

 

발표는 나름? 성공적이었던 것 같다.

전사 발표였는데 대표님께서 발표를 여러번 해본 사람 같다고 하셨고, 평소잘 하지 않으시는 발표를 잘한다는 칭찬을 하셨다.ㅎㅎ

부끄럽지만 팀장님은 강사가 발표하는 줄 아셨다고 장난삼아 말씀하셨다~

 

우리 팀원분들(사수님, 담당PM님)이 나보다 긴장하셨던 같다ㅎㅎ 참 감사한 분들이다.

다들 발표를 잘 한다고 집중이 확 된다고 말해주셨다.

 

그래서 재밌는 것 같다.

개발이라는 것이 성취감이 있는 분야이고, 그것을 잘 해냈을 때의 기분좋은 느낌이 좋다.

 

고생했다!

 

 

---

 

 

 

// 그동안 회사 업무때문에 포스팅을 하기가 참 애매해서 올리지 못했다.(보안도 있고)

아마 앞으로도 잘 올라오지는 못할 것 같다.

강의를 듣고 작성하는 부분은 단순 강의 요약본같아져서...더이상 그런 방식은 안하려고 한다.

앞으로는 이렇게 IT관련된 나의 경험이나 실제 개인 프로젝트의 내용들을 담을 예정이다.