대부분의 "업무에 AI를 활용하세요"라는 조언은 _하나의 모델에게 묻고, 그 답변을 받아들이는 것_에서 멈춥니다. 그것은 확신에 찬 목소리로 전달되는 단일한 관점입니다. 그리고 확신이야말로 중요한 결정에서 당신이 신뢰해서는 안 될 바로 그것입니다. 그래서 저는 중요한 것에 대해 단 하나의 모델에게만 묻는 것을 그만두었습니다. 대신 작은 자문 위원회(advisory board)를 구축했습니다. 세 개의 모델, 세 개의 역할, 병렬로 실행하며, 마지막에 결정하는 것은 바로 저입니다.

설정 방법과 이를 통해 실제로 얻을 수 있는 이점은 다음과 같습니다.

하네스 (The harness)

저는 Claude Code를 오케스트레이터(orchestrator)로 사용하여 모든 것을 제어합니다. 제가 triad라고 부르는 단일 기술은 브리프(brief)를 받아 세 명의 작업자에게 전달하며, 각 작업자는 고정된 역할을 가집니다:

• 비즈니스 분석가 (The business analyst) (gemini-cli 브릿지를 통한 Gemini) — 시장, 수요, 포지셔닝, "누가 관심을 가질 것인가."
• 아키텍트 (The architect) (Opus) — 구조, 트레이드오프 (trade-offs), 실패 모드 (failure modes), "규모가 커질 때 무엇이 깨지는가."
• 빌더 (The builder) (백그라운드의 Codex) — 구체적인 구현 단계, "이것을 출시하는 데 실제로 비용이 얼마나 들 것인가."

그들은 서로의 출력을 보지 못합니다. 그것이 핵심입니다. 저는 한 모델이 다른 모델들을 앵커링(anchoring)하여 형성된 합의가 아니라, 세 개의 독립적인 해석을 원합니다. 오케스트레이터는 세 가지를 모두 수집한 다음, 그들의 추론을 나란히 배치하고 그들이 의견이 일치하지 않는 부분을 표시하는 합성(synthesis) 단계를 수행합니다.

병렬 및 블라인드 방식이 중요한 이유

가치는 합의에 있는 것이 아닙니다. 세 모델 모두가 같은 결론에 도달한다면, 좋습니다. 하지만 그것은 정보량이 적은 상태입니다. 신호(signal)는 _의견 불일치_에 있습니다. 아키텍트는 "이것은 나중에 후회하게 될 두 시스템을 결합합니다"라고 말하고, 분석가는 "아무도 이것을 요청하지 않았습니다"라고 말하며, 빌더는 "3시간이 아니라 3일이 걸립니다"라고 말합니다. 이는 단일 스레드에서 하나의 모델과 반복하며 얻을 수 없었을 세 가지 서로 다른 실패 모드입니다. 단일 모델과의 반복 작업에서는 각 후속 질문이 첫 번째 프레임을 강화할 뿐이기 때문입니다.

나를 6개월이나 아껴준 이사회 회의

실제 사례를 약간 추상화하자면 이렇습니다. 제가 진심으로 기대했던, 이미 실행되는 모습이 눈에 선한 자동 에너지 차익 거래 (energy-arbitrage) 봇 프로젝트가 있었습니다. 저는 패널들에게 브리핑을 하며 반쯤은 승인이 나기를 기대했습니다. 하지만 그들은 세 가지 관점에서 이 프로젝트를 해체해 버렸습니다. 분석가 (Analyst)는 수요가 실제로 존재하지 않는다는 점을 찾아냈고, 설계자 (Architect)는 가변적인 요소들의 비용을 산정하자 이익 (edge)이 증발해 버린다는 점을 보여주었으며, 구축자 (Builder)는 1년 동안 제 주말을 조용히 갉아먹었을 유지보수 비용을 수치로 제시했습니다. 그들 중 누구도 무언가를 _금지_하지는 않았습니다. 그저 결정을 내릴 수 있도록 상황을 너무나 명확하게 펼쳐 놓았을 뿐입니다. 저는 프로젝트를 보류했고, 그렇지 않았다면 고통스러운 방식으로 배우기 위해 허비했을 6개월의 개발 시간을 아낄 수 있었습니다.

내 책상 위에 놓이는 것

이 종합 (synthesis) 결과는 판결이 아닙니다. 그것은 세 가지 관점이 솔기(seams)를 드러낸 채 쌓여 있는 모습입니다.

프로젝트 X — 종합 (synthesis)

• 분석가 (Analyst): 시장이 내가 가정했던 것보다 얇다 — 수천 명이 아니라 아마 수백 명 정도일 것이다.
• 설계자 (Architect): 상태 비저장 (stateless) 도구를 서비스로 바꾼다; 이제 당신은 가동 시간 (uptime)을 책임져야 한다.
• 구축자 (Builder): 내가 상상했던 주말 정도가 아니라, 약 10일이 걸린다.
• 의견이 갈리는 지점: 분석가는 낮은 가치를 보고, 구축자는 시도해 볼 만한 저렴한 비용이라고 말한다 — 따라서 이것은 도박이 아니라 작은 실험이다.

저는 그것을 읽고 결정합니다. 의견이 엇갈리는 지점이 바로 제가 실제로 비용을 지불하고 얻는 부분입니다.

내가 맞닥뜨린 주의사항 (Gotchas)

• 거짓 합의 (False consensus). 중복된 데이터로 학습된 모델들은 잘못된 이유로 의견이 일치할 수 있습니다. 단순히 투표 결과만 세고 있다면, 상관관계(correlation)를 확증(confirmation)으로 오해하게 될 것입니다. 판결(verdict)이 아니라 그
  _추론(reasoning)_을 읽으세요.
• 지시문(brief)을 통해 아첨 (Sycophancy)이 스며듭니다. 만약 당신의 프롬프트가 당신이 원하는 답을 몰래 전달하고 있다면, 세 모델 모두 그 답을 그대로 돌려줄 것입니다. 지시문은 중립적으로 유지하세요. 그들이 싸우게 두어야 합니다.
• 비용이 많이 들고 느립니다. 1초 만에 나오는 답변이 아니라, 몇 분의 시간과 세 번의 모델 호출이 필요합니다. 이것은 단순 정보 조회(lookups)가 아닌 의사결정을 위한 것입니다. 변수 이름을 바꾸려고 삼중 구조(triad)를 돌리지는 않습니다.
• 합성(Synthesis) 단계에서 스스로를 속일 수 있습니다. 병합(merge) 단계는 대충 훑어보고 싶은 유혹을 느끼게 합니다. 의견의 불일치가 바로 결과물입니다. 너무 일찍 의견을 하나로 뭉뚱그린다면, 당신은 단 하나의 의견을 얻기 위해 세 배의 비용을 지불한 것에 불과합니다.

안전을 보장하는 단 하나의 규칙

이 위원회는 조언합니다. 위원회는 여러 각도에서 조사하고, 스트레스 테스트(stress-tests)를 수행하며, 기반을 마련합니다. 결정은 하지 않습니다. 결정 — 그리고 그에 대한 책임 — 은 언제나 인간인 나의 몫입니다. 이것은 면책 조항이 아니라 운영 원칙입니다. LLM 앙상블(ensemble)은
혼자서는 볼 수 없는 문제의 더 많은 측면을 볼 수 있는 환상적인 방법입니다. 하지만 판단을 외주 주기에 적합한 도구는 아닙니다. 인간을 합성자(synthesizer)이자 결정권자로 유지한다면, 이 패턴 전체는 약해지는 것이 아니라 더 강력해집니다.

저는 이 방식을 약 6개월 동안 실행해 왔으며, 틀렸을 때 실제 시간이 많이 소요될 만한 모든 일에 대해 종종 — 이것이 저의 기본 설정(default)이 되었습니다.

한 가지만 기억하세요. 모델 하나에게 묻고 그 자신만만한 목소리를 믿지 마세요. 몇 개의 모델이 서로 논쟁하게 만들고, 그들이 의견이 갈리는 지점을 읽은 다음,
당신이 결정하세요.