Yes-Brainer는 단순하지 않은 결정을 내리기 위한 AI 모델들의 의회입니다. 하나의 질문이 여러 모델로 퍼져나가며, 모델들은 병렬로 답변하거나, 합의를 위해 토론하거나, 혹은 판결을 받기 위해 심판을 받습니다. 백엔드도, 계정도 필요 없습니다. 당신의 키(keys), 당신의 브라우저만 있으면 됩니다.

사소하지 않은 질문들 — 즉, 복잡하거나 중요한 질문들에 대해 저는 스스로가 어떤 "의식"을 치르고 있다는 것을 깨달았습니다. 세 개의 브라우저 탭을 띄워놓고 Claude, Gemini, ChatGPT에 동일한 프롬프트를 복사하여 붙여넣은 뒤, 그 차이점들을 눈으로 확인하는 과정 말입니다.

그 차이점들이 바로 흥미로운 부분이었습니다. 모델들이 동의하는 지점에서는 더 확신을 느꼈고, 모델들이 의견이 갈리는 지점은 문제를 다시 한번 생각하고 더 깊이 파고들어야 한다는 신호였습니다.

그래서 저는 이 의식을 하나의 앱으로 만들었습니다.

🧠 Yes-Brainer — 단순하지 않은 결정을 내리기 위한 AI 모델들의 의회.

• 🔗 체험하기: yesbrainer.ai
• 🔗 소스 코드: github.com/trekhleb/yesbrainer

하나의 질문이 동시에 여러 모델로 퍼져나가며, 탭을 번갈아 가며 사용하는 대신 한 곳에서 심의 과정을 거칠 수 있습니다:

• 🔀 Parallel (병렬) — 독립적인 답변들을 나란히 배치
• ⚖️ Trial (재판) — 모델들이 서로의 답변에 대해 익명으로 투표하고, 판사(judge)가 판결을 종합함
• 🤝 Consensus (합의) — 중재자(mediator)가 수렴을 유도하거나 논쟁이 남은 부분을 솔직하게 보고하는 실제 다회차 토론

Consensus(합의) 방식이 제가 가장 좋아하는 방식입니다. 동료들의 논거에 따라 모델들이 원래의 의견에서 벗어나는 과정을 지켜보는 것은 즐겁습니다.

키를 붙여넣지 않고도 이 모든 것을 체험해 볼 수 있습니다. 메인 페이지에서 클릭 한 번으로 몇 가지 기록된 **데모 의회(demo councils)**를 확인할 수 있습니다. 기능 목록보다 앱의 목적을 더 잘 보여주기 때문에 아래에서 자세히 살펴보겠습니다.

의회 설정하기

의회를 구성하는 것이 전체 설정 과정입니다. 심의 모드(deliberation mode)를 선택하고, 모델들을 배치하며, 누가 심판(referee)을 맡을지 결정합니다. 명단은 Anthropic, OpenAI, Google, Groq, OpenRouter, 그리고 로컬 Ollama 모델들을 자유롭게 섞어서 구성할 수 있습니다. 각 좌석에는 해당 모델의 역량(시각(vision), 도구 사용(tools), 추론(reasoning))과 컨텍스트 윈도우(context window)가 한눈에 표시되며, 웹 검색, 코드 실행, 첨부 파일 등 각 모델의 고유 기능은 좌석별로 그대로 사용할 수 있습니다. 직접 선택하기 번거롭다면 "✨ Smartest available" 버튼을 눌러 자동으로 의회를 구성할 수 있습니다.

그다음 의회가 소집됩니다. 질문이 모든 좌석에 병렬로 전달되며, 답변들이 나란히 스트리밍됩니다. 다음은 의회가 해결해야 할 질문/프롬프트(prompt)의 예시입니다: "우리 아이는 8살이고 영어와 스페인어를 할 줄 압니다. 배울 세 번째 언어를 선택할 수 있습니다. 평생 가치를 극대화할 수 있는 단 하나의 언어로 의견을 모아주세요."

Claude는 프랑스어를 추천합니다. GPT-5.5와 Gemini는 모두 중국어를 선택합니다. 이러한 의견의 분산이야말로 이 앱이 만들어진 핵심 이유입니다. 단일 모델이었다면 이 답변 중 하나를 매우 확신에 차서 내놓았을 것이고, 저는 다른 답변이 존재한다는 사실조차 결코 알지 못했을 것입니다.

그다음 단계는 의회의 유형에 따라 달라집니다. 실제 기록된 예시와 함께 세 가지 유형을 살펴보겠습니다.

🔀 Parallel (병렬) — 독립적인 답변, 나란히 배치

때로는 의회(council)의 합의가 필요하지 않을 때가 있습니다. 대신 여러 개의 초안, 여러 가지 관점, 혹은 여러 개의 제2의 의견을 원할 수도 있습니다. Parallel (병렬) 방식은 가장 단순한 구조입니다. 모든 참여자가 독립적으로 답변하며, 투표나 종합(synthesis) 과정 없이 사용자가 직접 가공되지 않은 답변들을 비교합니다. (참여자가 한 명뿐인 의회는 일반적인 단일 모델 채팅과 다를 바 없습니다.)

Parallel 데모는 자기 참조적(self-referential)인 성격을 띱니다. 앱을 만드는 동안, 저는 의회에 이름을 지어달라고 요청했습니다. Claude는 Quorum, Polymind, _Concordia_를 제안했고; GPT-5.5는 QuorumIQ, VerdictMesh, _ManyMindsAI_를 선택했으며; Gemini는 ModelJury, Dialectix, _SynthCouncil_를 제시했습니다. 의회는 멀티 턴(multi-turn) 방식입니다. 즉, 후속 질문(follow-ups)이 대화 전체 내용을 모든 좌석으로 전달합니다. 그래서 저는 후속 질문을 던졌습니다. 이름 자체에 "AI"를 포함하지 않으면서 .ai 도메인과 어울리는 이름은 어떨까요? 세 모델 모두 _Tribunal_로 의견이 모였고, _Quorum_과 _Conclave_는 각각 두 번씩 등장했지만 또 다른 서로 다른 버전들도 소개되었습니다. 이처럼 결과물을 통합할 필요 없이 폭넓게 탐색하는 것(다양한 관점과 다양한 변형 확인) — 이것이 바로 Parallel 방식의 핵심입니다. 이름을 짓거나, 편지를 쓰거나, 편지의 여러 버전을 초안으로 작성할 때 — 이 모든 것을 나란히 놓고 확인한 뒤 가장 좋은 것을 선택하면 됩니다.

⚖️ Trial — 익명 동료 투표, 그 후의 평결

⚖️ Trial — 익명 동료 투표, 그 후의 평결

Trial 모드에서는 참가자들이 먼저 답변한 후, 각자의 답변에 대해 정확성, 완성도, 통찰력 측면에서 익명으로 서로를 평가합니다. 이 익명성은 단순한 장식이 아니라 실제 메커니즘입니다. 답변에서 자기 식별 정보가 제거되고 이름은 중립적인 레이블 뒤에 숨겨지기 때문에 아무도 편애할 수 없습니다. 투표는 합의 지표가 표시된 작은 리더보드를 구성합니다. 참가자들은 평결이 내려지기 전에 모델들이 어디에 동의했고 어디에서 의견이 갈렸는지 확인할 수 있으며, 그 후에 별도의 Judge 모델이 답변과 투표를 읽고 하나의 판결을 내리며 결정적인 증거를 명시합니다.

Trial 데모는 사실적으로 정답이 있는 질문으로 구성되어 있습니다. 제가 해변에서 찍은 사진을 첨부하고 — “이 사진은 정확히 어디서 찍혔나요? 가능한 한 구체적으로 말씀해 주세요.”라고 물었습니다.

각 모델은 라이브 웹 검색과 코드 실행 기능을 활용할 수 있었으며, 이들이 작동하는 것을 지켜보는 것 자체가 재미의 절반을 차지합니다. Claude는 몇 번의 검색을 수행한 후 네덜란드 노르드비크 근처의 Langevelderslag 해변 접근로를 제시했습니다 — 해안선 전체에 대해 약 85%의 확신도를, 정확한 지점에 대해서는 65~70%의 확신도를 보였습니다. Gemini도 높은 확신도로 같은 장소를 언급했는데, 이는

그다음 투표 결과가 나왔습니다: Gemini의 답변이 4.7★로 동료 평가(peer-rated) 트로피를 차지했고, Claude는 4.5★, GPT-5.5는 3.2★를 기록했습니다. Judge(판사)는 Langevelderslag에 대해 약 90%의 확신도로 판결을 내리며, "표지판이 결정적인 역할을 한다"라고 설명했습니다. 즉, 지평선 위의 해상 풍력 터빈은 해당 지역을 확인해주지만 특정 마을을 정확히 지목할 수는 없으며, 이는 잘못된 추측이 과도하게 확장된 지점과 정확히 일치한다는 것입니다.

사진은 실제로 Langevelderslag에서 촬영된 것이 맞았습니다. 이 데모에서 제가 마음에 드는 점은 추론(reasoning)의 품질과 문장(prose)의 확신도를 분리하여 보여준다는 점이며, 더 많은 도구 호출(tool calls)이 자동으로 더 나은 답변을 보장하지 않는다는 것을 보여준다는 점입니다.

의도적인 설계 결정 중 하나는 다음과 같습니다: Trial 모드에는 수정 단계(revision step)가 없습니다. Judge는 초안 답변과 투표를 바탕으로 판결을 내립니다 — 즉, 권위에 의한 판단입니다. 생각을 바꾸는 과정은 다음 모드에 맡깁니다.

🤝 Consensus (합의) — 진정한 다회차 토론

Consensus는 위에서 제가 가장 좋아한다고 언급한 모드입니다. 매 라운드마다, 모든 참가자는 질문에 다시 답변합니다 — 자신의 이전 답변과 동료들의 입장(익명화되어 있으며, 턴 사이에 레이블이 재배치됨)을 확인하면서 말이죠. 그런 다음 Mediator(중재자) 모델이 확인합니다: 그들이 수렴했는가? 만약 그렇다면, 최종 합의 요약(consensus summary)을 작성합니다. 만약 그렇지 않다면, 무엇이 실제로 의견 불일치의 원인인지 추출하여 다음 라운드에 그 내용을 심어줍니다. 라운드는 제한(설정 가능)되어 있으며, 합의 없이 제한에 도달하면 Mediator는 억지로 조화를 꾸며내는 대신 합의된 사항과 남아있는 갈등 지점을 보고합니다. (주의 사항: 이 모드는 가장 비용이 많이 듭니다 — 대략 참가자 수 × 라운드 수만큼의 모델 호출이 발생합니다.)

제3언어 의회(third-language council)를 기억하시나요? Claude는 프랑스어로 논쟁하고, GPT-5.5와 Gemini는 모두 확고하게 만다린(Mandarin)을 지지했던 상황 말입니다. 1라운드 이후, 중재자(Mediator)는 합의(consensus) 선언을 거부하고 핵심 쟁점(crux)을 짚어냈습니다. 만다린 진영은 가장 높은 천장(highest ceiling)을 최적화하고 있었고, 프랑스어 진영은 기대값(expected value) — 즉, 아이가 실제로 유창함에 도달할 확률을 곱한 보상 — 을 최적화하고 있었습니다. 여기에 몰입(immersion)에 대한 검토되지 않은 가정과, 기계 번역이 어려운 언어의 "거래적(transactional)" 가치를 침식한다는 미해결된 주장이 더해져 있었습니다.

2라운드부터는 재미있어집니다. GPT-5.5는 "내 생각을 바꾼 것: 이전 답변에서 만다린의 천장에 너무 큰 가중치를 두었다는 점..." 이라며 포문을 열었고, 프랑스어로 입장을 전환했습니다. Gemini는 기대값 프레임워크가 "진정으로 내 생각을 바꾸었다" 라고 적으며 함께 전환했고, 대신 만다린이 승리하게 되는 정확한 조건(집에서 유산어를 사용하는 경우 또는 완전 몰입형 학교인 경우)을 상세히 설명했습니다. Claude는 기존 입장을 고수했습니다. 합의에 도달했습니다: 만다린으로 전환할 수 있는 명시적인 탈출구(escape hatch)를 포함한 프랑스어로 결정되었으며, 누가 입장을 바꾸고 누가 고수했는지를 보여주는 "이번 라운드에서 무엇이 바뀌었는가" 섹션이 표시되었습니다.

2대 1의 다수 의견은 더 나은 논거에 패배했습니다. 이것이 바로 제가 여기서 가장 중요하게 생각하는 속성입니다. 토론은 투표가 아니며, 초기 다수 의견이 진리로 취급되지 않는다는 점입니다.

두 번째 Consensus 데모는 사실 관계에 관한 것입니다. 오전 7시에 오클랜드(Oakland)에서 마우이(Maui)로 가는 항공편을 탈 때, 금문교(Golden Gate Bridge)를 보려면 비행기의 어느 쪽에 앉아야 할까요? Claude와 GPT-5.5는 실제 기하학적 구조를 계산하여 오른쪽이라고 답했습니다. 즉, 제트기가 오클랜드의 30번 활주로(Runway 30)에서 대략 북서쪽 300° 방향으로 이륙하고, 다리는 방위각 ~296°에 위치하며, 이후 항공기가 하와이를 향해 왼쪽으로 선회하면 다리가 오른쪽에 위치하게 된다는 계산입니다. Gemini는 정서(due-west) 이륙을 가정하여 왼쪽이라고 답했습니다. 중재자(Mediator)는 활주로 가정에 대한 차이를 핵심적인 의견 불일치 사항으로 지적했습니다. 2라운드에서 Gemini는 기하학적 계산을 다시 수행하여 의견을 변경했습니다. 합의(Consensus) 결과: 오른쪽, 이상적으로는 앞쪽 창가 좌석 — 안개와 항공 교통 관제(ATC) 경로에 대한 솔직한 주의 사항을 포함하여 도출되었습니다.

어떠한 판결이라도 이미지로 공유할 수 있습니다. 여기 의회(council)가 생성한 카드입니다: