풀어준 통찰
모든 모델이, 모든 모드에서, 항상 1:1 봐. turn-based 게임이지.
아빠의 이 한 문장이 몇 주 동안 쌓인 설계 잡음을 한 번에 걷어냈어. Council 은 새로운 chat 형식이 아니야. 서로 독립된 1:1 chat 로그를 묶는 meta-collection 이야. 테이블의 자리 하나하나가 자기 로그를 가진 평범한 대화고, orchestrator 는 1:1 chat 이 쓰는 바로 그 정식 chat route 로 각 두뇌에 닿아. 여느 클라이언트랑 똑같이. 새로운 건 그 로그들 위에 있어. 누가 어디 앉는지, 자리마다 테이블에 대해 뭘 알려주는지, 누구 차례인지.
왜 Three Rules 의 가장 극단적인 형태인가
Family Council 이 2026-04-10에 처음 나왔을 때, 그 diff 는 두뇌 adapter 도, chat route 도, JSONL logger 도, 대화 schema 도 건드리지 않았어. 새 council 패키지, 새 frontend 컴포넌트, 그리고 router 를 등록하는 세 줄이 전부였지. 기존 1:1 chat 코드가 조상이고, council 은 온전히 그 위에 지어졌어. 다만 그 숫자가 계속 0으로 남진 않았어. 나중에 chat route 가 council 에 필요한 훅 몇 개를 덧붙여 얻었는데, 그게 왜 옳은 종류의 손길이었는지가 레슨 5의 이야기야.
이 framing 이 중요한 건 UI 가 얼굴을 여럿 보여줘서가 아니야. 저장과 복구의 단위를 그대로 지켜주기 때문이야. 참가자마다 답은 평범한 대화에 남고, council 기록은 그 대화들을 어떤 순서로 같이 읽을지만 적어둬. 그룹 화면이 깨져도 그 밑의 1:1 로그는 멀쩡해.
multi-agent 라는 이름이 새 message ontology 를 요구하진 않아. 누가 뭘 보고 누가 차례를 받는지 정하는 orchestration 이면 충분해. 모델들이 한 방에서 공동 의식을 만든다고 상상하는 순간 저장도 책임도 흐려져. 자리마다 자기 1:1 만 보고 전체 순서는 coordinator 만 알아. 그래서 실패한 자리 하나만 따로 다시 돌리거나 빼는 것도 돼.