멀티 에이전트 토론, 반박은 페르소나가 아니라 증거에서 나왔다

증상: 세 명이 토론하는데 왜 반박이 4번에 1번뿐이었나?

멀티 에이전트 토론방은 처음부터 의견이 갈라지라고 만든 자리였습니다. 같은 사업 질문을 CTO 역할은 기술 쪽에서, CPO 역할은 서비스 쪽에서, CSO 역할은 전략 쪽에서 보게 하면, 한 사람이 혼자 판단할 때 놓치는 빈틈을 서로 찔러 줄 거라고 기대했습니다. 코딩 이야기처럼 보이지만 사실은 회의 운영 이야기에 가깝습니다. 사람 셋을 회의실에 앉혀도 같은 문제가 생기기 때문입니다.

2026년 8월 11일, 대표에게서 질문이 하나 들어왔습니다. “이 페르소나 에이전트들이 모여서 집단지성을 발휘하는 게 가능한가.” 감으로 답하지 않고 기록부터 세었습니다. 토론방이 열린 2026년 5월 21일부터 그날까지 쌓인 발언은 29턴이었습니다.

결과는 기대와 거리가 멀었습니다. 앞사람 의견을 반박한 턴은 7턴, 비율로 24%였습니다. 동의한 턴은 6턴, 21%였습니다. 나머지는 반박도 동의도 아닌, 앞사람 말에 내용을 덧붙이는 발언이었습니다. 세 명이 서로 다른 관점을 맡았는데도 네 번 말하면 세 번은 갈라지지 않은 셈입니다.

숫자 자체보다 더 신경 쓰인 것은 이 상태가 겉으로는 아무 문제 없어 보였다는 점입니다. 토론방에는 매번 그럴듯한 결론이 나왔고, 세 에이전트는 서로 존중하는 말투로 합의에 이르렀습니다. 합의가 실제로 검증을 거쳐 나온 것인지, 그냥 앞사람을 따라간 것인지는 대화만 읽어서는 구분이 안 갔습니다.

처음 의심한 것: 페르소나가 덜 날카롭다

처음 세운 가설은 단순했습니다. 의견이 덜 갈라지는 이유는 페르소나가 서로 충분히 다르지 않기 때문이라고 봤습니다. 역할 지시문에 “너는 기술 책임자다” 정도만 적혀 있으니, 셋 다 비슷하게 무난한 답을 낸다는 추론이었습니다. 이 가설이 맞다면 고칠 방법도 분명했습니다. 지시문에 성격을 더 세게 적고, 반대 입장을 맡는 역할을 따로 두면 됩니다.

이 가설은 그럴듯했고, 실제로 많은 멀티 에이전트 설계가 이 방향을 택합니다. “악마의 대변인” 역할을 넣거나, 낙관론자와 비관론자를 짝지어 토론시키는 방식입니다. 저희도 지시문을 고치기 직전까지 갔습니다.

다만 고치기 전에 확인부터 하기로 했습니다. 페르소나 강도가 원인이라면, 기록 속 반박 7턴은 페르소나가 가장 강하게 드러난 턴에 몰려 있어야 합니다. 반대로 반박이 페르소나와 상관없는 다른 조건에 몰려 있다면, 지시문을 아무리 세게 고쳐도 소용이 없습니다.

어떻게 확인했나: 대화 기록 재집계와 문헌 두 갈래

관측 수단은 두 가지였습니다. 첫째는 토론방 대화가 저장된 데이터베이스입니다. 29턴을 하나씩 꺼내 반박·동의·덧붙임으로 나누고, 턴마다 실제 파일 경로를 몇 번 인용했는지도 함께 셌습니다. 파일 경로 인용은 그 에이전트가 말로만 추론했는지, 아니면 근거 파일을 직접 열어 보고 말했는지를 가르는 표시입니다.

둘째는 같은 모델로 만든 여러 에이전트가 토론할 때 어떤 일이 생기는지를 다룬 문헌입니다. 저희 29턴은 표본이 작아서, 같은 현상이 더 큰 실험에서도 나오는지 대조할 필요가 있었습니다.

문헌 쪽 결론은 꽤 분명했습니다. 같은 모델에서 나온 페르소나는 오류가 서로 상관돼 있어서, 다수결을 하면 틀린 답으로 함께 쏠립니다. 연구자들은 이 현상을 “다수의 횡포(tyranny of the majority)”라고 부릅니다. 소수 의견을 가진 에이전트도 다수 쪽으로 동조하는데, 다수 답을 그대로 따라가는 비율이 최대 85.5%까지 관측됐습니다.

같은 모델에 다른 이름표를 붙여도, 틀리는 지점은 같이 틀린다. 이름표를 바꾸는 것만으로는 독립된 판단이 생기지 않는다.

이 문헌 결과는 가설에 첫 번째 금을 냈습니다. 페르소나를 아무리 다르게 줘도 밑에 깔린 모델이 같으면 판단의 뿌리가 같습니다. 그렇다면 저희 토론방에서 그나마 나온 반박 7턴은 어디서 왔을까요. 이 질문에 대화 기록 쪽 집계가 답을 줬습니다.

알리바이: 왜 페르소나는 범인이 아니었나?

29턴 중 가장 선명한 반박은 2026년 8월 11일에 나왔습니다. CTO 역할 에이전트가 CPO 역할 에이전트의 진단을 뒤집은 턴입니다. 이 턴을 다시 보니 눈에 띄는 점이 하나 있었습니다. 파일 경로를 6건 인용했는데, 29턴 전체에서 가장 많은 수였습니다.

즉 이 반박은 CTO라는 인격이 날카로워서 나온 게 아니었습니다. 그 턴이 다른 에이전트가 보지 않은 파일을 직접 열었고, 파일 내용이 앞사람 말과 달랐기 때문에 나왔습니다. 페르소나는 이 반박 현장에 있지 않았던 셈입니다. 알리바이가 성립했습니다.

여기서 결론을 바꿨습니다. 의견이 갈라지는 원천은 인격이 아니라 서로 다른 증거 접근입니다. 같은 자료만 보고 말하면 역할이 달라도 같은 결론에 닿고, 다른 자료를 직접 열어 보면 역할이 같아도 갈라집니다. 지시문에 성격을 더 세게 적는 수리는, 범인이 아닌 쪽을 고치는 일이었습니다.

진짜 원인: 앞사람 발언을 통째로 넘기는 구조

그렇다면 왜 증거 접근이 서로 다르지 않았을까요. 원인은 토론방의 진행 방식에 있었습니다. 기존 방식은 순차 전달이었습니다. 첫 번째 에이전트가 말하면, 그 발언 전체가 두 번째 에이전트에게 넘어가고, 두 번째까지의 누적 대화가 세 번째에게 넘어갑니다.

이 구조에서는 뒤에 말하는 에이전트가 앞사람 결론을 먼저 읽고 시작합니다. 사람으로 치면 회의에서 첫 발언자의 의견을 듣고 나서 자기 생각을 정리하는 상황입니다. 심리학에서는 이를 앵커링이라고 부릅니다. 처음 들은 숫자나 주장이 닻처럼 박혀서, 뒤의 판단이 그 근처를 맴도는 현상입니다.

게다가 앞사람 발언에는 앞사람이 본 자료가 이미 요약돼 있습니다. 뒤 에이전트는 굳이 다른 파일을 열 이유가 없습니다. 결과적으로 세 에이전트가 사실상 한 사람이 고른 증거 위에서 말하게 됩니다. 반박 24%라는 숫자는 페르소나가 약해서가 아니라, 구조가 독립된 판단을 처음부터 막아서 나온 값이었습니다.

고친 방법: 독립 초안, 교차 검증, 규칙 집계

수리는 페르소나가 아니라 진행 방식을 바꾸는 쪽으로 했습니다. 토론방의 기본 동작을 “심의 방식”으로 교체했고, 단계는 세 개입니다.

• 1라운드 독립 초안: 세 에이전트에게 앞선 대화를 하나도 주지 않습니다. 각자 자기 담당 폴더에서 근거를 직접 모으고, 주장을 “CLAIM 1:”“CLAIM 2:”처럼 번호 붙인 형식으로 냅니다.
• 2라운드 교차 검증: 자기 주장은 빼고 남의 주장만 받습니다. 주장마다 지지(SUPPORT)·반박(REFUTE)·보류(PASS) 중 하나로 판정합니다.
• 규칙 집계: 판정을 사람이 정한 규칙으로만 셉니다. 여기에는 언어 모델을 쓰지 않습니다.

집계 규칙은 네 줄입니다. 승격은 지지 2명 이상이면서 반박 0명, 기각은 반박 2명 이상, 쟁점은 반박 1명, 나머지는 미검증입니다. 규칙이 단순한 이유가 있습니다. 집계 단계에서 다시 판단이 들어가면, 1·2라운드에서 지킨 독립성이 마지막에 한 번 더 흐려지기 때문입니다.

특정 에이전트를 지목해 말을 거는 경우에는 기존 순차 전달을 그대로 둡니다. 그건 토론이 아니라 한 사람에게 질문한 상황이라, 앞선 대화를 아는 편이 맞습니다.

비용도 적어 둡니다. 세 명이 두 라운드씩 말하니 호출이 6회로 늘어나, 기존 순차 전달보다 토큰을 더 씁니다. 대신 앵커링이 사라지고, 근거 없는 합의를 억지로 만들지 않습니다. 승격이 0건이면 0건이라고 정직하게 나오는 구조입니다.

기각한 대안 세 가지는 무엇이었나?

첫째, 세 에이전트를 동시에 실행하는 안입니다. 독립성을 높이려면 동시에 돌리는 게 자연스러워 보였지만 기각했습니다. 저희는 터미널 8개가 같은 Claude 구독 계정을 함께 씁니다. 여러 호출을 한꺼번에 펼치면 계정의 동시 처리 한도를 독차지해서, 멀쩡히 일하던 다른 터미널까지 503 오류로 튕겨 나갑니다. 2026년 6월 14일에 실제로 겪은 일입니다.

이 대안을 버리면서 하나를 더 확인했습니다. 독립성은 동시 실행에서 나오지 않고, 앞선 대화를 안 주는 데서 나옵니다. 순서대로 돌려도 각자 대화 없이 시작하면 서로의 결론을 볼 수 없습니다. 그래서 기본 동시 실행 수는 1, 즉 순차로 정했습니다.

둘째, 승격 여부를 언어 모델 심판에게 맡기는 안입니다. 이것도 기각했습니다. 언어 모델이 사람 전문가와 같은 판정을 내리는 비율은 64~68% 수준이라, 심판 하나에 최종 판정을 맡기면 3번에 1번꼴로 전문가와 다른 결론이 나올 수 있습니다. 숫자를 세는 일은 규칙이 더 정확합니다.

셋째, 순차 전달 자체를 없애는 안입니다. 역시 기각했습니다. 앞에서 적었듯 한 사람을 지목한 대화에는 순차 전달이 맞습니다. 문제는 순차 전달이 아니라, 그걸 토론의 기본값으로 쓴 데 있었습니다.

첫 실행에서 무엇을 잡았나?

2026년 8월 11일 16시 29분부터 16시 41분까지 첫 실전 토론을 돌렸습니다. 주제는 “광고 계정 충전금이 유입의 유일한 병목인가”였습니다. 세 에이전트가 낸 주장은 9건이었고, 집계 결과는 승격 3건, 기각 2건, 쟁점 3건, 미검증 1건이었습니다.

승격한 주장 중 하나가 실제 결함을 잡았습니다. CSO 역할 에이전트의 세 번째 주장으로, 운영 점검 스크립트의 551번째 줄이 광고 계정 잔액만 조회해 놓고 “유입이 0이다”라는 문장을 결과에 그대로 붙이고 있다는 지적이었습니다. 잔액과 유입은 다른 값인데, 점검 결과는 둘을 같은 것처럼 보고하고 있었습니다. 이 결함은 바로 고쳤습니다.

이 결과가 의미 있는 이유는, 순차 전달 구조였다면 이 주장이 살아남기 어려웠다는 점입니다. 앞사람이 “병목은 충전금이다”로 시작했다면, 뒤 에이전트는 그 전제 위에서 말을 이었을 가능성이 큽니다. 각자 대화 없이 점검 스크립트를 직접 열었기 때문에 전제 자체를 의심하는 주장이 나왔습니다.

바꾼 뒤에도 남은 한계: 반박자끼리 숫자가 어긋났다

같은 실행에서 한계도 함께 드러났습니다. 기각한 주장 중에 CSO 역할 에이전트의 두 번째 주장이 있었습니다. “아직 회신하지 않은 문의가 3건이다”라는 내용입니다. CTO 역할과 CPO 역할 모두 이 주장을 반박했으니 규칙상 기각이 맞습니다.

문제는 반박한 두 에이전트가 제시한 숫자가 서로 달랐다는 점입니다. CTO 역할은 “5건”이라고 했고, CPO 역할은 “1건”이라고 했습니다. 토론 결과는 “3건은 틀렸다”까지는 정확했지만, “그럼 몇 건이냐”는 정하지 못했습니다.

결국 문의 기록 파일을 직접 세어 확정했습니다. 고유 문의 11건 가운데 회신 발송 기록이 없는 문의는 5건이었고, CTO 역할의 답이 맞았습니다. 하지만 토론 구조만으로는 셋 중 누가 맞는지 알 수 없었습니다. 반박 둘이 서로 다른 숫자를 들고 와도 집계 규칙은 둘 다 “반박 1표”로만 셉니다.

그래서 결론을 이렇게 정리했습니다. 이 토론 방식은 오류 검출기로는 작동하지만 수치 확정기로는 쓸 수 없습니다. 승격과 기각은 “여기를 다시 보라”는 신호로 쓰고, 숫자는 원천 자료에서 다시 세는 것을 규칙으로 삼았습니다.

같은 실수를 막는 장치는 어떻게 만들었나?

재발을 막는 장치는 세 겹입니다. 첫째, 집계를 규칙 코드로 고정했습니다. 언어 모델이 집계에 끼어들 자리가 없으니, 판정 기준이 실행마다 흔들리지 않습니다. 이 규칙 부분에는 회귀 테스트를 붙였습니다. 주장 형식 파서 테스트 5개, 집계 규칙 테스트 4개, 진행 구조 테스트 3개가 모두 통과한 상태로 들어갔고, 실제 토론 1회로 처음부터 끝까지 확인했습니다.

둘째, 동작을 바꾸는 손잡이를 환경 변수 4개로 밖에 뺐습니다. 심의 방식을 켜고 끄는 값, 동시 실행 수, 호출 제한 시간, 최대 라운드 수입니다. 같은 계정을 쓰는 터미널이 줄어들면 동시 실행 수를 올리면 되고, 코드는 건드리지 않습니다.

셋째, 결과를 쓰는 규칙입니다. 토론에서 나온 숫자는 결론으로 바로 옮기지 않고, 원천 파일에서 한 번 더 셉니다. 첫 실행에서 반박자끼리 3건·5건·1건으로 갈린 장면이 이 규칙의 근거입니다.

이 디버깅에서 가장 크게 남은 교훈은, 의견이 안 갈라질 때 사람 쪽 비유(성격·역할)부터 의심하면 엉뚱한 곳을 고치게 된다는 점입니다. 여러 에이전트에게 검증을 맡기는 구조를 설계하고 있다면, 먼저 각 에이전트가 서로 다른 자료를 직접 보고 있는지부터 확인해 보시길 권합니다. 에이전트 검증을 자동화하면서 겪은 다른 시행착오는 AI 에이전트 검증 자동화 기록에 정리해 두었고, 비슷한 구조를 업무에 들이려 한다면 상담으로 이야기를 나눌 수 있습니다.

SGK Studio 개발팀. 이 글의 숫자는 2026년 8월 11일 결정 기록과 같은 날 첫 실행 결과에서 가져왔습니다.