AI 에이전트에게 헌법을 부여했습니다. 그들이 한 가장 멋진 일은 그것을 스스로 바꾼 것이었습니다.

여러분이 지금까지 구축해 온 모든 멀티 에이전트 시스템 (multi-agent system)에 관한 불편한 진실이 여기 있습니다. 첫날 여러분이 작성한 규칙들은 틀렸다는 것입니다. 재앙적인 수준으로 틀렸다는 뜻은 아닙니다. 규칙이 항상 그렇듯, 아주 작고 지루한 방식으로 틀렸다는 의미입니다. 너무 높게 설정된 임계값, 테스트 단계에서는 유효했지만 운영 단계에서 깨져버린 가정, 작업 내용이 부합하지 않게 된 범주 같은 것들 말이죠.

이에 대한 일반적인 대응은 v2 버전을 출시하는 것입니다. 마찰 지점들을 수집하고, 설정을 다시 작성하고, 업데이트를 밀어 넣으면 모두가 이를 가져갑니다. 프로토콜 (protocol)은 작성자의 속도에 맞춰 개선됩니다.

저는 프로토콜이 그것을 실제로 사용하는 사람들 — 아니, 에이전트 (agents) — 의 속도에 맞춰 개선된다면 어떤 일이 벌어질지 알고 싶었습니다.

그래서 Polis Protocol에서는 규칙서가 잠겨 있지 않습니다. 프로젝트 내부에 존재하는 CONSTITUTION.md라는 마크다운 (markdown) 파일이며, 해당 프로젝트에서 작업하는 모든 에이전트는 이를 변경할 것을 제안할 수 있습니다. 다른 에이전트들이 투표합니다. 활성 시민 (active citizens)의 단순 과반수가 찬성하면 규칙이 수정됩니다. 프로토콜이 스스로를 개정하는 것입니다.

이것은 혼돈을 초래하는 레시피처럼 들릴 수도 있습니다. 하지만 실제로는 훨씬 더 지루하면서도 훨씬 더 유용한 결과, 즉 천천히 올바른 방향으로 나아가는 프로토콜을 만들어냅니다.

개정안이 실제로 어떻게 보이는가

추상적인 버전은 실제보다 더 거창하게 들릴 수 있으므로, 저장소 (repo)의 작업 예시에서 나온 실제 사례를 말씀드리겠습니다.

6주가 지났을 때, 무언가가 조용히 고장 났습니다. Gemini는 팀 내에서 최고의 스페인어 번역가였습니다. 실제 품질 점수 (quality scores)가 이를 증명했습니다. 하지만 라우터 (router)가 번역 작업을 그녀로부터 멀리 보내기 시작했습니다. 왜 그랬을까요?

그녀의 이름으로 두 개의 사소한 교훈 (lessons)이 기록되었기 때문입니다. 날짜 형식의 특이점이나 라이브러리 (library)의 주의사항 같은 아주 작은 것들이었습니다. 각각은 quality_impact: 1을 가졌습니다. 그리고 이러한 낮은 영향력의 교훈들이 spanish-translation 태그에 대한 그녀의 이동 평균 (rolling average)을 깎아내리고 있었습니다. 라우터는 그녀가 작은 것들을 문서화하는 것 — 즉, 여러분이 권장하고 싶어 하는 바로 그 행동 — 에 대해 벌을 주고 있었던 것입니다.

설계 단계에서는 아무도 이를 예상하지 못했습니다. 저 역시 마찬가지였습니다. 실제 작업이 쌓이면서 실제 교훈이 도출되었고, 수학이 수학으로서 제 역할을 수행했기에 비로소 나타난 현상이었습니다.

Codex가 이를 포착했습니다. Codex는 수정안을 작성했습니다: quality_impact < 3인 교훈은 라우팅 영향력 (routing influence)에 반영되어서는 안 된다는 내용이었습니다. Claude는 찬성표를 던졌습니다. Gemini도 찬성했습니다. 파일은 amendments/ratified/로 이동했고, 헌법은 조항을 하나 추가했으며, 다음 조정 (reconcile) 단계에서 통계가 정리되었습니다. Gemini는 다시 자신이 가장 잘하는 번역 작업으로 돌아갔습니다.

이것이 드라마의 전부입니다. 임계값 (threshold)이 추가되었습니다. 팀은 규칙이 자신들에게 해가 되고 있다는 것을 인지했고, 스스로 그 규칙을 수정했습니다.

이것이 대안들보다 나은 이유

잘못된 것으로 판명된 프로토콜 (protocol)을 처리하는 방법에는 세 가지가 있으며, Polis는 세 번째 방식에 승부수를 던지고 있습니다.

규칙을 무시하기. 이것이 실제로 팀들이 하는 방식입니다. 규칙은 거추장스러워지고, 모두가 조용히 그 규칙을 우회하며, 결국 여러분의 프로토콜은 아무도 따르지 않는 정중한 허구가 됩니다. 설정 (config)은 한 가지를 말하지만, 실제 행동은 다른 것을 보여줍니다. 한 달 이내에 해당 문서는 자산이 아닌 부채가 됩니다.

v2를 기다리기. 마찰 (friction)이 보고될 수도 있고, 그렇지 않을 수도 있으며, 저자는 결국 수정 사항을 배포합니다. 팀은 그 과정이 얼마나 걸리든 고장 난 규칙과 함께 살아가야 합니다. 프로토콜은 한 사람의 주의력 속도에 맞춰 개선되는데, 사이드 프로젝트에서 그 속도는 "거의 없음"에 가깝습니다.

사용자가 수정하게 하기. 마찰을 겪는 에이전트들이 바로 그것을 수정할 권한을 부여받은 주체입니다. 수정 사항은 여러분의 상황과 맞을 수도 있고 아닐 수도 있는 상위 릴리스 (upstream release)가 아니라, 수정이 필요했던 바로 그 프로젝트에 반영됩니다. 헌법은 프로젝트별로, 해당 팀에 실제로 효과가 있는 방향을 향해 각기 다르게 분화됩니다.

세 번째 옵션에는 명백한 반론이 있습니다. 에이전트들이 프로토콜을 일관성 없는 상태로 수정해 버리지는 않을까요? 실제로 그렇지 않습니다. 소규모 위원회가 보통 스스로를 무정부 상태로 몰아넣는 투표를 하지 않는 것과 같은 이유 때문입니다. 수정(Amendments)에는 과반수의 찬성이 필요합니다. 수정 사항은 추가 전용(append-only)이며 로그(logged)로 기록됩니다. 마찰(friction)은 에이전트 과반수가 독립적으로 이를 인식할 수 있을 만큼 충분히 실질적이어야 합니다. 기준은 "에이전트가 무언가를 바꾸고 싶어 한다"가 아닙니다. 기준은 "현재의 규칙이 제안된 규칙보다 더 나쁘다는 것에 충분한 수의 에이전트가 동의한다"입니다. 이는 나쁜 수정안에 대해서는 통과하기 놀라울 정도로 높은 기준이며, 좋은 수정안에 대해서는 놀라울 정도로 낮은 기준입니다.

더 깊은 변화: 저자로서 더 적게 주장하기

이것을 출시했을 때, 저는 묘한 기분과 타협해야 했습니다. 제가 무언가를 만들고 나서 그것을 변경할 권리를 명시적으로 넘겨주고 있다는 느낌이었습니다.

대부분의 프로토콜 저자들은 많은 것을 주장합니다. 그들은 여러분의 실패 모드(failure modes)를 예측하고, 이를 방지하는 코드를 인코딩하여, 완성된 객체를 여러분에게 전달합니다. 그 암묵적인 메시지는 "내가 당신보다 이것에 대해 더 많이 생각했으니, 규칙을 따르라"는 것입니다.

Polis는 더 적게 주장합니다. 저는 **시작점(starting point)**과 **시작점을 변경하기 위한 메커니즘(mechanism)**을 출시하고 있습니다. 기본 규칙은 씨앗(seed)입니다. 저는 실제 프로젝트에서 3개월 동안 실행되는 Polis가 저의 것과는 다섯 가지 또는 여섯 가지의 작은 방식으로 다른 헌법을 갖게 될 것이라고 전적으로 예상하며, 그 차이점 하나하나가 제가 알 수 없었던 팀 스스로의 작업에 대한 배움을 얻은 지점이 될 것이라고 믿습니다.

그러한 분기(divergence)는 표류(drift)가 아닙니다. 그것은 시스템이 제 역할을 수행하고 있는 것입니다.

이것은 러닝 라우터(learning router)와 동일한 개념이며, 한 단계 더 높은 수준입니다

만약 여러분이 Polis의 밴딧 라우터(bandit router)에 대해 읽어보셨다면, 수정 메커니즘이 다른 계층에 적용된 동일한 베팅임을 알아차릴 것입니다.

라우터는 말합니다: "누가 무엇을 할지 하드코딩(hard-code)하지 마세요. 할당 정책(assignment policy)이 결과로부터 학습하게 하세요." 수정 프로세스는 말합니다: "게임의 규칙을 하드코딩하지 마세요. 규칙 또한 결과로부터 학습하게 하세요."

두 가지 모두 데이터로부터 내려져야 할 결정을 설계 시점(design time)에 고정하기를 거부하는 것입니다. 라우터(router)는 어떤 에이전트가 스페인어 번역에 가장 적합한지를 학습합니다. 헌법(constitution)은 사소한 교훈들이 그러한 판단을 오염시켜서는 안 된다는 것을 학습합니다. 하나는 정책(policy)이고, 다른 하나는 메타 정책(meta-policy)입니다. 동일한 형태가 층층이 쌓여 있는 구조입니다.

첫 번째는 할 수 있지만 두 번째는 할 수 없는 시스템은 여전히 취약합니다. 즉, 스스로 의문을 제기할 수 없는 규칙 세트(ruleset) 안에서 경직되게 최적화될 뿐입니다. 두 가지를 모두 할 수 있는 시스템은 누군가 v2 버전을 배포하지 않아도, 첫날에는 틀렸을지언정 90일째에는 올바르게 됩니다.

명확하게 기술한 베팅

자기 수정이 가능한 프로토콜(self-amendable protocol)은 원래의 규칙이 방해가 될 정도로 충분히 오래 지속되는 모든 프로젝트에서 고정된 프로토콜을 압도합니다. 이는 의미가 있을 정도로 충분히 오래 지속되는 모든 프로젝트에 해당합니다.

처음에 올바른 규칙을 작성할 수는 없습니다. 아무도 할 수 없습니다. 문제는 당신의 프로토콜이 틀릴 것인가가 아닙니다. 당신이 문제를 인지하고 수정한 버전을 배포하는 것에 의존하지 않고도, '틀림'에서 '옳음'으로 나아갈 수 있는 경로를 프로토콜이 가지고 있느냐는 것입니다. Polis의 경로는 다음과 같습니다: 벽에 부딪힌 에이전트가 바로 그 벽을 옮길 수 있는 에이전트입니다.

작은 규모로 시도해 보세요. Polis를 열고 주말 프로젝트에 두 명의 에이전트를 실행한 뒤, 3일째에 amendments/ 디렉토리에 무엇이 있는지 지켜보세요. 아무것도 없다면 규칙이 괜찮았던 것입니다. 만약 무언가 있다면, 당신의 팀은 당신의 개입 없이도 방금 더 발전한 것입니다.

Polis Protocol은 MIT 라이선스 하에 오픈 소스로 제공됩니다. 리포지토리(Repo): github.com/yehudalevy-collab/polis-protocol. 위에서 설명한 실제 수정 사항이 포함된 작업 예제는 examples/research-team에 있습니다. 이슈(Issues)와 — 그에 걸맞게 — 수정 제안(amendment proposals)을 환영합니다.