시작한 이유
AI를 사용하다 보면 가끔 매우 그럴듯하지만 사실은 틀린 답변을 만날 때가 있습니다.
문제는 이런 답변이 단순한 오타나 계산 실수가 아니라는 점입니다. 논리적으로도 자연스럽고 자신 있게 설명하기 때문에 사용자가 오류를 알아차리기 어렵습니다.
그러다 문득 이런 생각이 들었습니다.
하나의 AI를 믿는 대신, 서로 다른 AI들이 같은 주제를 놓고 토론하게 하면 어떨까?
사람 사회에서도 중요한 의 사결정을 할 때 한 사람의 의견만 듣지 않습니다. 서로 다른 관점을 가진 사람들이 토론하고 검증하는 과정을 거칩니다.
그렇다면 AI도 마찬가지로 운영할 수 있지 않을까?
특히 서로 다른 회사의 AI라면 학습 데이터와 모델 구조, 성향이 다르기 때문에 같은 실수를 동시에 저지를 가능성이 조금 더 낮아질 수 있습니다.
그래서 저는 다음과 같은 구조를 만들고 싶었습니다.
Claude Sonnet
Codex(GPT)
Claude Opus(심판)
두 AI가 토론하고, 제3의 AI가 토론 내용을 검토하여 최종 결론을 내리는 구조입니다.
마침 Claude와 Codex를 모두 구독 중이었기 때문에 추가 API 비용 없이 구독만으로 구현하는 것을 목표로 잡았습니다.
이 글은 그 과정을 정리한 기록입니다.
무엇을 조사했고, 어떤 판단을 했고, 어디에서 막혔으며, 실제로 무엇이 가능했는지를 솔직하게 남겨보려고 합니다.
첫 번째 구상
wmux를 발견하다
처음에는 wmux라는 도구를 발견했습니다.
처음 봤을 때는 "이거면 되겠다" 싶었습니다. 제가 윈도우 환경에서 개발을 하기 때문에 적절해 보였습니다. 그리고 Claude와 Codex를 동시에 띄워 놓고 서로 대화하게 만들 수 있을 것처럼 보였기 때문입니다.
그래서 wmux를 중심으로 조사하기 시작했습니다.
하지만 조사 범위는 자연스럽게 더 넓어졌습니다.
MCP 기반 접근 방식
tmux
cmux
NTM(Named Tmux Manager)
멀티 에이전트 운영 사례
이런 도구들을 하나씩 살펴보면서 실제 구조와 구현 방식을 비교했습니다.
조사하면서 생각이 바뀌기 시작했다
조사를 진행할수록 처음 생각했던 구조는 여러 번 수정되었습니다.
1. API 자동화 대신 실제 대화 세션 활용
처음에는 CLI 옵션으로 AI를 자동 호출하는 방식도 고려했습니다.
하지만 여러 정보를 찾아보니 구독 플랜에서는 이런 방식이 장기적으로 제한될 가능성이 있다는 이야기가 있었습니다. 특히 Claude에서 -p 옵션의 사용에 제한이 생긴다는 이야기가 있었습니다.
그래서 방향을 바꿨습니다.
API처럼 호출하는 것이 아니라,
사람이 직접 사용하는 것과 동일한 대화 세션을 자동으로 운영하는 방식
으로 접근하기로 했습니다.
이렇게 하면 이미 구독 중인 서비스를 그대로 활용할 수 있습니다.
2. wmux에서 NTM으로
또 다른 문제는 운영 환경이었습니다.
wmux는 GUI 중심 도구였습니다.
반면 제가 원했던 것은 24시간 켜 두는 서버 환경이었습니다.
모니터 없이도 돌아가야 했습니다.
조사 과정에서 NTM(Named Tmux Manager)을 발견했고,
리눅스 서버 친화적
tmux 기반
외부 제어 가능
이라는 장점이 있어서 결국 NTM을 기반으로 방향을 변경했습니다.
3. 윈도우에서 우분투 미니PC로
자연스럽게 운영 환경도 바뀌었습니다.
원래는 윈도우 PC에서 돌릴 생각이었지만,
결국 항상 켜 둘 수 있는 우분투 미니PC가 더 적합하다고 판단했습니다.
가장 중요한 전환점
AI를 믿지 말고 시스템을 믿자
프로젝트를 진행하면서 가장 크게 생각이 바뀐 부분이 있습니다.
처음에는 AI에게 이런 지시를 주려고 했습니다.
발언이 끝나면 내용을 정리해서 파일에 저장해라.
하지만 경험상 AI는 이런 규칙을 자주 잊어버립니다.
어떤 때는 잘 지키고,
어떤 때는 빠뜨리고,
어떤 때는 전혀 다른 형식으로 출력합니다.
즉, 시스템이 AI의 협조에 의존하게 됩니다.
그래서 생각을 완전히 바꿨습니다.
AI에게 부탁하지 말고 시스템이 직접 가져오자.
발언이 끝나는 순간을 감지해서 자동으로 저장하는 구조로 설계했습니다.
기술적으로는 훅(Hook)을 활용한 방식입니다.
비유하자면 직원에게 보고서를 제출하라고 부탁하는 대신,
업무가 끝나는 순간 자동으로 문서함에 저장되도록 만든 것입니다.
최종 설계
최종적으로는 다음 구조가 되었습니다.
토론자
Claude Sonnet
Codex(GPT)
서로 다른 회사의 AI를 사용했습니다.
한 모델의 편향이나 오류가 그대로 반복되는 상황을 줄이기 위해서입니다.
심판
Claude Opus
심판은 토론 내용만 보고 판단합니다.
중요한 점은 AI 이름을 숨긴다는 것입니다.
누가 Claude인지,
누가 GPT인지,
심판은 알지 못합니다.
오직 주장과 근거만 보고 판정합니다.
실제 구현 과정
설계가 끝난 뒤에는 "정말 돌아가는지"를 검증하기 시작했습니다.
생각보다 시행착오가 많았습니다.
환경 준비
먼저 우분투 미니PC 환경을 구성했습니다.
tmux 설치
Codex 설치
로그인 설정
NTM 설치
여기서부터 작은 실수들이 나오기 시작했습니다.
Claude는 이미 설치되어 있었지만,
Codex도 설치되어 있다고 착각하고 있었습니다.
실제로는 다른 PC에 설치된 것이었습니다.
결국 처음부터 다시 설치해야 했습니다.
문서 검증 과정에서 발견한 오류
구현 전에 문서를 다시 검토하던 중 문제가 하나 발견되었습니다.
저는 훅이 항상 실행된다고 가정하고 있었습니다.
하지만 확인해 보니 특정 상황에서는 훅이 실행되지 않는 예외가 존재했습니다.
실제로 구현하기 전에 발견한 덕분에 설계를 수정할 수 있었습니다.
이 과정에서 얻은 교훈은 단순했습니다.
"당연히 될 것"이라고 생각하는 부분일수록 반드시 검증해야 한다.
세 개의 AI를 띄우다
이후 하나의 화면을 세 개 영역으로 나누었습니다.
Sonnet
Codex
Opus
첫 실행에서 의도한 모델이 모두 정상적으로 실행되었습니다.
생각보다 이 단계는 순조로웠습니다.
자동 회수 기능 첫 실패
가장 중요한 검증은 발언 자동 회수였습니다.
훅을 설정한 뒤 테스트했는데 아무것도 저장되지 않았습니다.
원인을 찾고 보니 단순했습니다.
훅은 AI가 시작될 때 읽어 오는데,
저는 이미 실행 중인 상태에서 설정만 변경했던 것입니다.
AI를 재시작하자 즉시 정 상 동작했습니다.
"안녕"
"안녕하세요"
같은 단순한 테스트 메시지조차 자동으로 파일에 기록되었습니다.
이 순간이 프로젝트에서 가장 중요한 성공 지점 중 하나였습니다.
AI가 협조하지 않아도 시스템이 발언을 가져올 수 있다는 것이 확인되었기 때문입니다.
Codex는 예상보다 까다로웠다
Claude는 비교적 쉽게 해결됐지만 Codex는 달랐습니다.
중간에 설정 파일을 잘못 덮어써서 복구 작업을 해야 했고,
신뢰된 폴더 설정 문제도 만났습니다.
하지만 가장 큰 문제는 다른 곳에 있었습니다.
Codex가 승인 대기 상태로 멈춰 있었던 것입니다.
저는 훅이 고장 났다고 생각했지만,
실제로는 Codex가 답변을 끝내지 못해서 훅이 실행될 기회 자체가 없었습니다.
자동 승인과 읽기 전용 설정을 적용한 뒤 정상적으로 동작했습니다.
설정 오류라고 생각했지만 내 착각이었다
중간에는 Sonnet과 Opus가 동일 모델로 실행되고 있다고 착각하기도 했습니다.
확인 결과 문제는 모델이 아니라 제가 사용한 창 번호였습니다.
명령어마다 창 번호 기준이 달랐던 것입니다.
올바른 번호로 확인하니 처음부터 정상 실행 중이었습니다.
첫 번째 완전 자동 토론
이후 실제 토론을 진행했습니다.
먼저 사람이 직접 중간에서 발언을 전달하는 방식으로 검증했습니다.
흥미로웠던 점은 두 AI가 단순히 같은 이야기를 반복하지 않았다는 것입니다.
상대방 근거의 약점을 지적하고 반박하는 모습이 실제로 나타났습니다.
그 다음 단계에서는 사 람이 개입하지 않는 완전 자동 토론을 시도했습니다.
결과는 성공이었습니다.
2라운드 토론
심판 판정
자동 종료
까지 모두 자동으로 수행되었습니다.
이번 실험에서 확인한 것
이번 실험을 통해 다음 사항을 확인했습니다.
Claude와 Codex 모두 발언 자동 회수가 가능하다.
서로 다른 회사 AI끼리 실제 토론이 가능하다.
익명 심판 구조가 동작한다.
사람 개입 없이 자동 진행이 가능하다.
토론 결과에 따라 판정까지 수행할 수 있다.
즉,
"서로 다른 AI를 토론시키고, 제3의 AI가 검증하는 구조"
가 실제 환경에서 동작한다는 것을 확인했습니다.
앞으로의 계획
이번에는 개념 검증(PoC) 단계까지만 진행했습니다.
다음 단계에서는 다음 기능들을 추가할 예정입니다.
심판 판단에 따른 자동 라운드 조절
토론 비용 최적화
요약 기반 컨텍스트 압축
전체 토론 기록 관리
재검증 및 재실행 기능
그리고 장기적으로는 단순한 토론 시스템을 넘어,
전문 분야별 AI 팀들이 협업하는 작은 AI 조직 형태까지 확장해 보고 싶습니다.
한 AI의 답변을 그대로 믿기보다,
서로 다른 AI들이 검증하고 반박하도록 만들면 더 신뢰할 수 있는 결과를 얻을 수 있지 않을까.
이번 실험은 그 가설을 검증하기 위한 첫 번째 시도였습니다.
아직 갈 길은 멀지만, 적어도 "이 구조가 실제로 작동한다"는 것은 확인했습니다.
다음 단 계도 진행되면 다시 공유해 보겠습니다.
읽어주셔서 감사합니다.
