여러분은 일을 할 때 ToDo 리스트 등을 만드는 경우가 많을 것입니다.
제 작업 목록(ToDo 리스트)에는 미완료된 항목이 24가지 있습니다.
어떤 것을 먼저 해야 하는지 AI에게 한 번 물어보면, 그럴듯한 답변이 하나 돌아옵니다. 하지만 다시 물어보면 다른 답변이 돌아올 때가 있습니다. 둘 다 이유가 통하기 때문에 어느 쪽을 믿어야 할지 결정할 수 없었습니다.
ToDo 항목이 늘어나면 AI가 읽는 텍스트 양도 많아지고, 오류도 더욱 커집니다.
어떻게 해야 할지 고민하다가 (물론 AI와 벽치기하며ㅋ) 조금 생각해 보았습니다.
그래서 세 명의 AI에게 반대 입장에서 싸우게 하고, 이것을 여러 번 반복하여 어떤 안이 더 많이 이기는지 세어보기로 했습니다. 결정하는 것은 저이고, AI가 만드는 것은 재료입니다.
이 글에서는 디베이트 구조를 만든 순서대로 작성하겠습니다. 심판으로 사용한 Jev와 Claude의 판정 일치는 이전 글에서 작성했습니다. 50회 돌린 결과와 비용은 다음 글에 작성하겠습니다.
그림 아래쪽의 '50회'는 마지막으로 진행한 실제 횟수입니다. 결과는 다음 글에 작성하겠습니다.
진행 방식의 원료가 된 것은 해외 Y파파님의 영상(2026년 7월 16일 공개)입니다.
그 영상은 협상이나 프레젠테이션처럼, 실제 한 번에 승부가 나는 상황에 대한 이야기였습니다. AI로 평행 세계를 만들고 뒤에서 수백 번 되돌려 가장 논리적인 한 수를 가져오는 것입니다. 이 글에서는 1회의 토론을 '세계'라고 부릅니다. 핵심은 다음 네 가지였습니다.
- 세 명에게 입장을 할당한다 (지지/반박/중립). 토론에 참여하지 않는 심판이 가장 설득력 있는 논리를 선택한다.
- 100~200회 반복하여, 몇 번을 해도 강한 승리 방식을 찾아낸다. 마지막으로, 어떤 회차의 강력한 논리와 다른 회차의 효과적인 반박을 조합한다.
- '흔들림'이 엔진이 된다. 흔들림이 없으면 100번 모두 같은 결과가 나온다.
- 토큰을 대량으로 사용하는 힘겨루기라 비용이 발생한다. 패배할 수 없는 설득의 장면에만 사용한다.
제가 가져온 것은 '반복하여 분포를 보기'와 '마지막에 조합하기' 두 가지입니다. 그 영상은 설득 전략 짜는 이야기여서, 제 용도(어떤 안을 선택할지)와는 방향이 조금 다릅니다.
2026년 10월 3일에 다음 여섯 가지를 결정했습니다.
- 후보 중 하나를 선택하는 형태로 만든다.
- 세 명의 역할은 지지/반박/중립으로 한다 (영상과 동일).
- 토론은 2회로 진행한다. 첫 번째는 자신의 논리를 제시하고, 두 번째는 상대방의 논리를 읽고 반박 및 마지막 주장을 내놓는다.
- 심판은 토론에 참여하지 않는다. 논리를 보여주는 순서는 회차마다 바꾼다.
- 심판이 보는 것은 근거, 반박에 대한 강도, 실행 가능성 3가지로 한다.
- 결정하는 것은 나로 한다.
영상에서 추가한 것은 여러 번 반복하여 이긴 횟수를 세는 것과, 마지막으로 이긴 논리를 조합해서 정리하는 것입니다. 처음에는 논자를 Claude Haiku로 하고, 횟수는 20회로 했습니다.
디베이트는 1회의 토론에서 논자를 6번 호출합니다 (3명이 2라운드). Orca(여러 AI 에이전트에게 긴 작업을 맡기는 환경. 사용법은 다음 글에 작성하겠습니다)의 하위 요소로 구동하기에는 왕복 과정이 너무 많아 무거워집니다. 그래서 논자도 심판도 claude -p
으로 호출하기로 했습니다.
claude -p
을 그대로 사용하면, 1회마다 약 10만 토큰의 서론(설정, 후크, 도구 설명 등이 매번 로드되기 때문입니다)이 붙습니다. 이것을 다음과 같이 잘랐습니다.
cmd = [
규칙
심사위원에게 제출할 기준이며, 설계에서 정한 3가지 포인트를 그대로 한 줄로 만든 것입니다.
2026년 10월 3일 16시 7분에 첫 번째 안건으로 단 한 번 시도했습니다.
안건은,
**Qiita와 Note 다음에 제가 힘을 쏟을 발신처를 무엇으로 할 것인가?** 입니다.
16시 13분에 같은 안건을 20번 돌리자 3.1분 만에 끝났습니다. 심사위원들의 표는 LinkedIn이 12표, 블로그가 8표였습니다.
LinkedIn에는 이미 작성하고 있으므로, 이 조사 답변은 일단 건너뛰었습니다ㅋㅋ
계속해서 16시 46분부터 56분에 걸쳐 순서대로 시작하며 나머지 4가지 안건을 각각 20번 돌렸습니다.
안건은,
**이미 구축하고 있는 개인 지식 wiki를 어떻게 운영할 것인가? 학습 계획을 어떻게 세울 것인가? 독서 내용을 회상시켜 기억에 정착시키는 시스템을 어떻게 만들 것인가? 구상 메모 폴더를 어떻게 구성할 것인가, 등** 입니다.
이 5가지 안건으로 심사위원들의 비교 방식을 테스트했습니다. 그 결과는 이전 기사에 적은 대로, 99회분의 기록이 남았습니다.
99회를 검토해 보니, 세 사람의 마지막 주장이 같은 안에 모여 있는 경우가 눈에 띄었습니다. 마지막 주장에서 세 사람 모두 같은 안을 추천했던 횟수는 다음과 같습니다.
- 구상 메모 폴더: 20회 중 20회
- 학습 계획: 20회 중 19회
- 회상 카드: 20회 중 15회
- 개인 지식 wiki: 19회 중 12회
- 발신처: 20회 중 4회
합치면, 99회 중 70회입니다. 영상의 '흐트러지는 엔진'이 효과를 보지 못했습니다. 세 사람이 처음부터 같은 안을 추천하는 것은 반대 입장의 논리가 나오지 않기 때문이라고 생각합니다.
이 때는 추천하는 안을 세 사람이 자유롭게 선택하고 있었습니다.
수정한 부분은, 추천할 안, 역할, 모델을 세계별로 제비뽑기로 할당하는 방식입니다. 모델은 Haiku 2석과 Sonnet 1석으로 했습니다.
안의 할당은 후보의 수로 나누고 있습니다. 후보가 3~6개일 때는 세 가지 조합을 모두 만들어서 섞은 후 순서대로 돌립니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
if len(opts) >= 3:
combos = list(itertools.combinations(opts, 3))
rng.shuffle(combos)
...
발췌는 3~6개일 때의 분기입니다. 5안이라면 조합은 10가지이고, 20회라면 각 그룹이 2번씩 당첨됩니다. 7개 이상인 경우는 다른 분기로, 매번 전부를 섞어서 3개씩 가져옵니다. 난수 시드는 안건 이름과 출력 폴더 이름입니다. 같은 조건으로 돌리면 같은 할당을 재현할 수 있습니다.
추천하는 안은 끝까지 바꾸지 못하게 했습니다. 프롬프트에 '바꿀 수 없습니다'라고 적습니다. 2라운드에서는 자신의 1차 논리와 다른 두 사람의 논리를 전달하여 반론하게 합니다.
j = claude_json(f"{base}\n\n당신이 추천하는 안은 「{d['option']}」입니다 (바꿀 수 없습니다).{inst}\n당신의 1차 논리:\n{r1[d['id']]}\n\n"
f"다른 두 사람의 논리:\n{others}\n\n다른 논리에 반론하여 마지막 주장을 써주세요."
'형식:{"final": "<반론을 포함한 마지막 주장. 300자 이내>"}", d["model"], False, a.budget_usd, calls, "debater",
...
심사위원에게 보여주는 것은 마지막 주장뿐입니다. 논자들의 순서는 세계별로 섞어 P, Q, R이라는 이름을 붙입니다. 역할과 모델은 숨깁니다. 1회 토론의 흐름은 다음 그림과 같습니다.
수정한 후, 개인 지식 wiki의 입구를 정하는 안건을 돌렸습니다.
19회 동안, 5가지 안이 각각 11~12회씩 경쟁했습니다.
입구(진입점)를 하나로 통합하는 안이 11회 중 9회(82%) 승리했고, 다른 안은 12회 중 4회(33%) 이하였습니다.
그림의 왼쪽은 구상 메모 폴더 안건(자유롭게 선택하게 한 회)의 숫자이고, 오른쪽은 개인 지식 wiki 안건(제비뽑기로 할당한 회)의 숫자입니다. 다른 안건이므로 같은 안건의 전후 비교는 아닙니다.
19회 동안 승률이 어떻게 움직였는지도 확인했습니다.
입구 통합 안은 처음 4회는 100%였으나, 6회차에 80%까지 떨어졌고, 그 후에는 흔들리면서 19회차에 82%로 안정되었습니다.
다른 안들은 마지막에 33% 이하였습니다.
횟수가 적을 때는 승률이 크게 요동치지만, 횟수를 거듭할수록 차이가 드러납니다.
시스템이 갖춰진 후, 읽기 전용의 Codex에게 스크립트와 절차서를 검토하게 했습니다. 승인 화면은 0회였고, 56초 만에 끝났으며, 중대한 지적이 7건, 경미한 지적이 4건 있었습니다. 수정한 부분은 다음 4가지입니다.
- 비용 상한선이 느슨해졌습니다. 호출 전에 누적 비용을 확인하고, 실패한 호출의 비용도 합산하도록 했습니다.
- 임시 파일 충돌 문제. 생성 로직을 락(lock) 안에 넣었습니다.
- 필요한 항목 확인 누락. JSON에 기대하는 항목이 없을 때도 다시 호출하도록 했습니다.
- 결과 폴더 충돌. 같은 이름의 폴더가 있으면 중단되도록 했습니다.
이로써 실제 환경에서 50회를 돌릴 수 있는 상태가 되었습니다.
10월 3일은 이 순서대로 진행되었습니다. 16시 7분부터 1회 테스트를 시작했고, 17시 14분~35분에 작은 버전의 뽑기판 테스트를 시작했으며, 외부 리뷰에서의 수정 과정을 거쳐 17시 52분에 실제 환경에서 50회를 진행했습니다.
50회를 돌린 결과로 모델별 차이점, 비용, 그리고 막혔던 부분은 다음 글에 작성하겠습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32