제가 점점 불편하게 느꼈던 점은 AI 아키텍트가 자신의 제안이 어떻게 도전받아야 할지 결정하도록 내버려 두는 것이었습니다.

그것이 아키텍트가 약하다고 생각해서는 아니었습니다. 대부분의 경우, 아키텍트는 유능하고 신중하며 출처에 근거했습니다. 하지만 일단 그것이 작업에 대한 첫 번째 일관된 해석을 형성하면, 나중 검토에서도 여전히 그 해석 안에 머무를 수 있었습니다.

여러 에이전트가 참여하여 과정은 독립적으로 보일 수 있지만, 원래의 틀 지어 놓은 방식(framing)이 모두에게 관련 있다고 간주하는 것을 계속해서 형성하고 있었습니다. 저는 결국 비평가를 선택하는 것 또한 추론이 어디로 가도록 허용될지 결정한다는 것을 깨달았습니다.

직관의 출처

저는 이것을 견제와 균형(checks and balances)에 연결했습니다. 요점은 정치적인 것이 아니었고, AI 시스템이 권위에 의해 도덕적으로 부패할 수도 있다는 것도 아니었습니다. 저에게 흥미로웠던 것은 구조였습니다: 시스템의 한 부분이 규칙을 정의하고, 적용하고, 그 자체의 적용을 반대 없이 판단해서는 안 된다는 것입니다. 역량(Competence)이 사각지대(blind spots)를 제거하지는 못합니다.

저에게 더 가까운 비유는 숙련된 개발자와 강력한 QA 간의 관계였습니다.

숙련된 개발자는 경험이 풍부하고, 생각이 깊으며, 세심할 수 있습니다. 그럼에도 불구하고, 개발자는 자연스럽게 그것을 구축하는 논리(intended behaviour, implementation constraints, 그리고 디자인이 제대로 작동하는지 여부)를 통해 시스템을 바라봅니다.

강력한 QA는 실패를 통해 같은 시스템에 접근합니다. 가정이 틀렸을 때는 어떻게 될까요? 사용자가 실제로 경험하는 것은 무엇일까요? 기능은 실제 요구 사항을 놓치면서도 작동하는 것처럼 보일 수 있을까요?

두 역할 모두 동일한 결과를 원합니다. 유용한 긴장감(useful tension)은 그들의 다른 책임과 기대되는 실패의 종류에서 나옵니다.

이것이 대략적으로 위원회가 저에게 이해되기 시작한 방식이었습니다. 저는 에이전트들로 가득 찬 방에서 서로 논쟁하는 것을 만들려고 한 것이 아니었습니다. 저는 하나의 관점이 제안과 그것에 대해 제기되는 모든 질문을 소유하는 것을 피하고 싶었습니다.

자체 검토의 한계

단일 모델은 과제를 해석하고, 해결책을 제안하며, 그 해결책을 비판하고, 수정하고, 구현하고, 결과를 검증할 수 있습니다. 이러한 순서는 실제로 유용할 수 있습니다. 자체 검토는 종종 취약한 검증(validation), 누락된 엣지 케이스(edge cases), 그리고 일반적인 구현 실수를 잡아냅니다.

하지만 제가 계속 알아차린 것은, 그 검토가 항상 원래의 틀(framing)에 의문을 제기하지는 않는다는 것이었습니다. 문제가 올바르게 구성되었는지, 소유권이 잘못된 곳에 있는지, 아니면 가정된 행동 자체가 존재하는지 재검토하는 경우가 없을 수도 있다는 것입니다.

저는 이것을 모든 상황의 모든 모델에 대한 주장은 아닙니다. 단지 제가 너무 자주 본 패턴이라서, 저는 그 패턴을 중심으로 설계하기 시작했다는 것일 뿐입니다: 자체 검토는 답변을 개선할 수는 있지만, 그것을 만들어낸 틀(frame)에서 벗어나도록 돕지는 못합니다.

한 예시가 이 문제를 특히 명확하게 했습니다. 과제는 처음에 불완전한 메커니즘을 개선하려는 시도로 보였습니다. 그 가정은 자연스럽게 수리(repair) 쪽으로 이어졌습니다: 구현을 검사하고, 신뢰할 수 없는 부분을 찾아내고, 그것을 강화하는 것이었습니다.

소스 코드 검사를 통해 예상되는 필드나 배선이 한 번도 채워진 적이 없다는 것을 알게 되었습니다. 그 메커니즘은 단순히 불완전한 것이 아니라, 실제로 연결된 적조차 없었던 것입니다. 주변의 워크플로우(workflow)가 그것이 존재한다고 가정한 것입니다.

그것은 작업을 무언가를 수리하는 것에서, 그것을 구축하거나 복원하는 것으로 바꾸어 놓았습니다. 원래 제안에 대한 기술적으로 강력한 구현이라 할지라도 여전히 잘못된 문제를 겨냥할 수 있었습니다.

이때쯤에는 아키텍트(Architect)가 이미 과제의 첫 번째 일관된 모델을 구축했습니다. 이 모델에게 첫 번째 검토를 통해 모양을 갖추게 하는 것은 그 모델에 또 다른 장점을 주었습니다: 가장 중요한 가정이 직접적으로 도전받지 않을 수 있다는 것입니다.

이론적 틀을 만들면서 반대 의견 만들기

그렇기 때문에 저의 첫 번째 위원회 라운드는 항상 네 가지 다른 렌즈를 사용합니다. 시스템 사고가(System Thinker)는 어떤 결정이 시간이 지남에 따라 더 넓은 시스템에 어떤 영향을 미치는지 질문합니다. 비판적 검토자(Critical Reviewer)는 제안이 실제 문제를 해결하지 못하면서도 성공적으로 보일 수 있는 방식까지 포함하여 실패를 찾습니다. 단순화가(Simplifier)는 그 솔루션이 문제가 필요로 하지 않는 기계를 추가하는지 의문을 제기합니다. 대안 탐색자(Alternatives Explorer)는 선호되는 방향이 틀렸을 경우 물질적으로 다른 방향을 계산해 냅니다.

이들은 네 가지 성격이 아닙니다. 이들은 네 가지 다른 의무입니다.

그럼에도 불구하고, 유용한 불일치는 종합 과정에서 사라질 수 있습니다. 일반적인 종합가는 모든 것을 맞추려고 합니다: 날카로운 반대는 주의사항(caveats)이 되고, 소수의 우려는 희미해지며, 양립할 수 없는 권고 사항들은 상호 보완적이라고 묘사됩니다. 건축가(Architect)의 방향이 이미 가장 완전한 서사를 가지고 있기 때문에, 답변은 조용히 그쪽으로 되돌아가기 쉽습니다.

따라서 저는 종합 과정이 반대가 실제로 해결되었는지 아니면 단지 흡수하기 쉽게 만들어졌는지를 질문하도록 만들고 싶습니다. 소수의 우려가 우리가 시작했던 것 아래에 있는 다른 문제를 드러냈을까요? 두 가지 권고 사항이 정말로 함께 맞는 걸까요, 아니면 여전히 결정해야 할 선택을 매끄럽게 덮어버리고 있는 걸까요?

위원회는 투표 시스템이 아닙니다. 세 명의 에이전트가 동의한다고 해서 자동으로 한 명의 잘 뒷받침된 반대 의견보다 더 큰 가치를 갖지는 못합니다. 동시에, 불일치가 존재한다는 이유만으로 가치 있는 것은 아닙니다. AI 에이전트는 불필요한 우려를 만들어내거나, 잘못된 대안을 강제하거나, 간단한 결정을 필요 이상으로 복잡하게 만들 수 있습니다.

반대는 압력을 만듭니다. 증거가 무엇이 살아남을지 결정합니다.

출처 증거(Source evidence), 영향(impact), 심각성(severity), 가역성(reversibility), 그리고 인간의 판단이 여전히 결과를 결정합니다. 위원회는 불일치를 진실로 바꾸기 위해서가 아니라, 가정과 대안을 보이게 만들기 위해 존재합니다.

워크플로우 전반에 걸쳐 동일한 원칙 적용

이 아이디어가 자리 잡으면서 나머지 워크플로우에도 영향을 미치기 시작했습니다. 아키텍트(Architect)가 자신의 제안을 자유롭게 실행해서는 안 되며, 실행자(executor) 역시 자신이 수행한 작업을 승인해서는 안 됩니다. 심지어 수정하려는 의도조차 더 많은 작업이 시작되기 전에 이의를 제기해야 할 수도 있습니다. 올바른 감사(audit)가 여전히 잘못된 개선 계획(remediation plan)으로 이어질 수 있기 때문입니다.

이러한 AI 역할들은 독립적인 기관이 아닙니다. 이들은 훈련 패턴, 맥락적 앵커(contextual anchors), 그리고 유사한 사각지대를 공유할 수 있습니다. 에이전트들에게 다른 이름을 붙여준다고 해서 의미 있는 분리가 만들어지는 것은 아닙니다. 진정한 분리는 반드시 서로 다른 맥락, 서로 다른 책임, 출처의 증거, 그리고 중요한 결정에 대한 인간의 통제를 통해 의도적으로 창출되어야 합니다.

인간 역시 오류를 범할 수 있습니다. 저는 첫 번째 설명에 근거하거나, 편리한 결론을 선호하거나, 증거를 잘못 해석할 수 있습니다. 저의 역할은 제가 완벽하게 중립적인 심판관으로서 시스템 밖에 서 있는 척하는 것이 아니라, 트레이드오프(trade-offs)를 의식적으로 수행하고 실행이 실제로 승인되었는지 결정하는 것입니다.

제가 AI 위원회(AI council)를 구축한 것은 더 많은 답변을 원했기 때문이 아닙니다. 저는 하나의 추론 맥락(reasoning context)이 문제를 구성하고, 그 틀이 어떻게 도전받아야 할지 결정하며, 작업을 승인하고, 결과를 판단하는 상황에 불편함을 느꼈기 때문에 이를 만든 것입니다.

견제와 균형(Checks and balances)은 정확성을 보장하지 않습니다. 그것들은 단지 아무것도 반대하도록 설계되지 않았다는 이유만으로 하나의 그럴듯한 해석이 권위적이 되도록 만드는 것을 어렵게 만들 뿐입니다.