Underpass Choreographer는 Underpass 플랫폼의 심의 엔진(deliberation engine)입니다. 이는 멀티 에이전트(multi-agent) 회의를 Kubernetes 상에서 선언적(declarative)이고 관찰 가능하며(observable) 운영 가능한(operable) 의식(ceremony)으로 변환합니다. 이는 오픈 소스(open source)입니다.

에이전트들은 작업을 해결합니다: 컨텍스트(context)를 받고, 도구(tools)를 사용하며, 단계를 조정하고, 결과를 전달합니다.

많은 경우, 그것이 정확히 우리가 필요로 하는 것입니다.

하지만 그 결과가 나중에 방어해야 할 무언가를 결정하는 데 사용될 때 요구 사항은 달라집니다.

시스템이 아키텍처를 추천하거나, 작업의 우선순위를 정하거나, 운영을 제안하거나, 기술 계획을 설계한다면, 최종 결과만으로는 충분하지 않습니다. 우리는 그 결과에 어떻게 도달했는지 알아야 합니다.

어떤 대안들이 고려되었는지. 누가 그것을 비판했는지. 비판 후에 무엇이 바뀌었는지. 검증자(validator)가 무엇을 확인했는지. 각 제안이 어떤 점수를 받았는지. 왜 한 가지 옵션이 승리했고 다른 것들은 그렇지 않았는지.

거기서부터 결정(decision)이 시작됩니다. 에이전트의 마지막 문장이 아니라, 한 옵션이 다른 옵션들에 대해 승리하게 되는 그 과정 말입니다.

Choreographer는 바로 그 아이디어에서 탄생했습니다: 멀티 에이전트의 결정은 블랙박스(black box)나 일시적인 대화여서는 안 됩니다. 그것은 의식(ceremony)의 형태를 갖추어야 합니다.

의식은 역할, 단계, 규칙, 그리고 흔적(trace)을 가집니다. 선언될 수 있고, 실행될 수 있으며, 관찰될 수 있고, 나중에 검토될 수 있습니다.

산출물로서의 결정

에이전트 생태계의 상당 부분은 매우 실용적인 질문을 중심으로 구축되었습니다:

모델이 어떻게 무언가를 하게 만들 것인가?

그로부터 도구 호출(tool-calling) 루프, 프롬프트 체인(prompt chains), 실행 그래프(execution graphs), 메모리(memories) 및 커넥터(connectors)가 나옵니다. 이 모든 것은 유용합니다. 하지만 시스템이 중요한 결정을 내리기 시작할 때, 또 다른 질문이 나타납니다:

방금 내린 결정을 어떻게 방어할 것인가?

최종 결과만을 저장하는 것은 가장 가치 있는 것, 즉 선택의 역사를 배제하게 됩니다. 우리는 그 결정을 열어보고 그것이 어떻게 형성되었는지 이해할 수 있어야 합니다.

어떤 경로가 배제되었는지. 어떤 반론이 제기되었는지. 어떤 제안이 동료 검토 (peer review)를 통과했는지. 심사위원이 어떤 기준을 사용했는지. 어디서 동점이 발생했는지. 어디서 특정 옵션이 도착 순서가 아닌 품질에 의해 승리했는지 말입니다.

Choreographer에서는 그 역사가 시스템 밖에 남겨지지 않습니다. 그것은 모델의 일부가 됩니다.

답변 (response)은 텍스트입니다.

결정 (decision)은 대안, 기준, 검토 및 흔적을 가집니다.

채팅이 아닌 의식 (Ceremonies, not chats)

Choreographer에서 복잡한 결정은 하나의 의식 (ceremony)으로 모델링됩니다.

이는 여러 에이전트가 즉흥적으로 대화하는 채팅이 아닙니다. 의식은 명시적인 형태를 가집니다: 참여자, 단계, 역할, 진행 조건 및 기대 결과.

Choreographer의 의식 엔진 (ceremony engine)은 이러한 작업 방식을 가능하게 합니다. 이는 폐쇄적인 회의나 고정된 프롬프트 (prompt) 시퀀스가 아닙니다. 상태 (states), 단계 (steps), 역할 (roles), 전문가 (specialists), 참여자 수, 라운드 (rounds) 및 종료 조건을 YAML로 정의할 수 있는 유연한 시스템입니다.

동일한 엔진으로 아키텍처 검토, 제품 계획, 사고 조사 또는 여러 전문가와의 기술적 심의를 실행할 수 있습니다. YAML을 바꾸면 의식이 바뀝니다. 실행 환경은 동일하게 유지됩니다.

YAML은 장식이 아닙니다. 그것은 어떻게 결정할 것인지에 대한 계약 (contract)입니다.

팀은 이를 실행하기 전에 해당 계약을 검토할 수 있습니다. 단계를 변경할 수 있습니다. 전문가를 조정할 수 있습니다. 아키텍처 결정이 먼저 보안 역할 (security role)을 거치고, 그다음 비용 역할 (cost role)을 거쳐, 최종적으로 프로그램 책임자 (program lead)에게 전달되도록 설정할 수 있습니다.

결정하는 방식은 더 이상 함수나 스크립트 내부에 파묻혀 있지 않습니다. 읽고, 토론하고, 버전 관리(versioning)를 하고, 진화시킬 수 있는 하나의 구성 요소가 됩니다.

나중에 살펴보게 될 실제 의식의 일부 발췌본입니다 (엔진이 실행하는 것과 동일한 스키마이며, 프롬프트는 축약되었습니다):

states:
  - id: BRIEFING
    initial: true
...

저 see_prior: true 설정이 바로 매 단계마다 회의가 재시작되지 않게 만드는 디테일입니다. 즉, 아키텍트(architect)가 미션 프레임워크(mission framing)가 남긴 내용을 읽을 수 있게 합니다. 그리고 가드(guard)를 통한 전이(transition)는 진행 조건이 됩니다. 프레임워크가 완료될 때까지는 DESIGN 단계로 넘어가지 않습니다.

예시는 작지만 핵심 아이디어를 가르쳐 줍니다. 결정 모드(mode of deciding)를 읽을 수 있다면, 그것을 논의하고, 버전 관리(versioning)하며, 거버넌스(governance)를 수행할 수도 있다는 점입니다.

최소 단위: deliberate

하나의 의식(ceremony) 아래에는 더 작은 원시 요소(primitive)인 deliberate가 있습니다.

deliberate는 무언가가 결정되는 최소 단위입니다. 작업(task), 에이전트 그룹, 제약 조건(constraints), 그리고 검증 정책(validation policy)을 전달받습니다. 이 에이전트 그룹은 해당 심의(deliberation)의 의회(council) 역할을 합니다. 즉, 서로 다른 관점에서 동일한 문제를 다루는 여러 전문가들입니다.

그 지점부터 Choreographer는 명시적인 프로세스를 실행합니다:

1. 에이전트들이 제안합니다.
2. 동일한 의회(council) 내의 다른 에이전트들이 해당 제안들을 비판(criticize)합니다.
3. 제안들이 검토(review)됩니다.
4. 검증기(validators)가 정의된 기준을 충족하는지 확인합니다.
5. 심판(judge)이 각 제안의 상대적 품질에 점수를 매길 수 있습니다.
6. 승자가 선택됩니다.

검증기(validator)는 제안이 특정 기준을 통과할지 결정하는 모든 확인 절차를 의미합니다. 예를 들어, 내용이 비어 있지 않은지, JSON 계약(contract)을 준수하는지, 스키마(schema)를 따르는지, 또는 LLM 심판의 평가를 통과하는지 등을 확인합니다.

심판(judge)은 특별한 검증기입니다. 단순히

긴 의식(ceremony) 과정에서 각 단계는 하나의 완전한 심의(deliberation)가 될 수 있습니다. 한 단계의 승리한 결과가 다음 단계의 입력값이 됩니다. 이처럼 회의는 매 단계마다 새로 시작되는 것이 아니라, 문맥(context)을 축적합니다.

개방형 기술 결정

우리는 설계 회의를 테스트했습니다: 4,500달러 미만, 최대 이륙 중량(MTOW) 25kg 미만이며, 혼합 수관(mixed canopy)에서 병든 나무를 탐지하기 위해 약 45분간 임무를 수행할 수 있는 드론을 계획하는 것입니다.

이 구체적인 테스트에서 모든 모델 호출은 vLLM을 통해 서빙되는 Gemma 4를 사용하여 로컬에서 실행되었습니다. 에이전트(agent), 심판(judge), 그리고 심의(deliberation) 과정은 어떤 클라우드 제공업체에도 의존하지 않았습니다.

이러한 유형의 결정은 협상을 강제합니다. 자율성이 높아지면 전기적 안전성이 악화될 수 있습니다. 센서가 많아지면 예산이나 무게를 초과할 수 있습니다. 온보드(on-board) 프로세싱이 늘어나면 정확도는 향상될 수 있지만, 에너지, 비용, 그리고 열 마진(thermal margin)을 소모하게 됩니다.

의식은 네 단계로 나뉘었습니다:

• frame_mission: 임무와 제약 조건을 설정합니다.
• design_approach: 기술적 아키텍처를 제안합니다.
• review_risks: 안전 및 신뢰성 리스크를 공격적으로 검토합니다.
• build_plan: 최종 계획을 합성합니다.

각 단계는 세 가지 제안을 바탕으로 한 심의 과정이었습니다. 결과적으로, 이 회의는 심판에 의해 평가된 총 12개의 제안을 생성했습니다.

결과는 즉각적이지 않았습니다. 약 25분이 소요되었습니다. 이 데이터 또한 중요합니다. 실제 멀티 에이전트(multi-agent) 결정은 시간, 토큰, 제공업체 호출 및 검증 사이클을 소비합니다. 이러한 비용을 관찰할 수 없다면, 이를 운영할 수 없습니다.

핵심은 드론에 관한 멋진 텍스트를 얻는 것이 아니었습니다. 핵심은 시스템이 결정 구조를 유지할 수 있는지 확인하는 것이었습니다.

첫 번째 단계는 미션 계약(mission contract)을 확정했습니다. 두 번째 단계는 아키텍처(architecture)를 탐색했습니다. 세 번째 단계는 대화의 무게 중심을 바꾸었습니다. 핵심적인 리스크는 단순히 센서의 정확도나 비용이 아니라, 바람과 비 속에서의 전기적 안정성이었습니다. 보안 검토자(security reviewer)는 전압 강하(voltage sag), 브라운아웃(brown-out) 및 드론 분실 위험으로 인해 순수 리튬 이온(Li-ion) 기반의 아키텍처에 의문을 제기했습니다.

최종 합성(synthesis) 단계에서 승리한 계획은 해당 비판을 수용했습니다. 즉, 이론적인 자율성(autonomy)보다 운영 안정성을 우선시했으며, Li-ion + LiPo 버퍼(buffer)의 하이브리드 토폴로지(hybrid topology)를 통합했습니다.

이 결정이 흥미로운 이유는 그것이 완벽해서가 아니라, 열어볼 수 있기 때문입니다.

결정을 열어보면 초기 제안들, 수정 사항들, 심사위원의 판결, 점수, 그리고 각 단계의 승자가 나타납니다. 또한 합성 단계가 누적된 제약 조건들을 조정하느라 더 느리게 진행되었다는 점도 확인할 수 있습니다. 심사위원은 12개의 제안을 평가했으며, 세션은 정상적으로 종료되었습니다.

결정은 최종 응답 속에 사라지지 않았습니다. 관찰 가능한 아티팩트(artifact)로 남았습니다.

결정을 탐색하는 방법

여기서 관찰 가능성(observability)은 매우 구체적인 기능을 수행합니다. 바로 결정 사항을 사후에 읽을 수 있도록 하는 것입니다.

전체 세리머니(ceremony)는 분산 트레이스(distributed trace)로 볼 수 있습니다. 각 심의 단계는 스팬(span)으로 나타납니다. 그리고 토론은 구조 없는 로그(logs) 속에 길을 잃지 않고, 스팬의 이벤트(events)로 기록됩니다.

실제 심의 과정에서는 다음과 같은 이벤트들을 볼 수 있습니다:

• proposal drafted (제안 초안 작성)
• peer critique and revision (동료 비판 및 수정)
• validator verdict (검증자 판결)
• proposal scored (제안 점수 산정)
• deliberation completed (심의 완료)

이러한 구조를 갖추면, Grafana를 여는 의미가 달라집니다.

당신은 단순히 지연 시간(latency), 에러(errors), 또는 처리량(throughput)을 보고 있는 것이 아닙니다. 시스템이 어떻게 결정했는지를 읽고 있는 것입니다.

회의는 탐색 가능한 흔적(trace)을 남깁니다. 최근의 세션(ceremony)을 열고 deliberate 스팬(span)으로 들어갈 수 있습니다.

그곳에서 제안들을 읽고, 어떤 비판을 받았는지 확인하며, 판사(judge)의 평결을 검토하고, 어떤 제안이 승리했는지 확인할 수 있습니다.

이 흔적(trace)은 결정의 기술적 회의록(acta técnica)이 됩니다.

이는 실행의 결정론적 리플레이(deterministic replay)가 아닙니다. 외부 세계를 다시 실행하여 정확히 동일한 추론을 얻을 수 있다는 의미가 아닙니다. 그보다 더 구체적이고 방어 가능한 것을 의미합니다. 즉, 트레이스 ID(trace ID)를 통해 과거의 결정을 다시 열고 단계별로 따라갈 수 있다는 뜻입니다.

플랫폼 팀에게 이것은 중요합니다. 프로덕션 환경의 멀티 에이전트(multi-agent) 시스템은 단순히 "모델이 이렇게 응답했습니다"라고 말하는 것에 그쳐서는 안 됩니다. 운영 및 거버넌스(governance) 질문에 답할 수 있어야 합니다:

• 이 결정에서 무슨 일이 일어났는가.
• 어떤 에이전트가 승리한 옵션을 제안했는가.
• 어떤 비판이 제안을 변경했는가.
• 어떤 점수를 받았는가.
• 각 심의(deliberation)에 시간이 얼마나 걸렸는가.
• 신뢰도가 낮은 판사가 있었는가.

이러한 종류의 질문은 평면적인 로그(flat log)로는 제대로 답변할 수 없습니다. 흔적(trace)을 통해서 더 잘 답변할 수 있습니다.

결정이 제대로 작동하는지 측정하기

과거의 회의를 읽는 것은 문제의 일부일 뿐입니다. 다른 하나는 의사 결정 프로세스가 시간이 지남에 따라 제대로 작동하고 있는지 아는 것입니다.

여기에서 메트릭(metrics)이 등장합니다.

Choreographer는 토론이 담긴 흔적(trace)을 발행할 뿐만 아니라, 프로세스의 품질과 비용에 대한 운영 신호(operational signals)도 노출합니다:

• 숙고(deliberations) 시간
• 승리 제안 점수
• 심판 지연 시간(latency)
• 심판 점수 분포
• 유형별 분류된 심판 오류
• 심판 및 공급업체당 소비 토큰 수
• 공급업체당 지연 시간 및 활성 호출 수
• Postgres 풀 사용량
• 의식(ceremonies) 결과 및 지속 시간
• 각 의식 단계의 지속 시간 및 상태
• NATS에 이벤트를 게시할 때의 지연 시간 및 오류

드론 테스트에서는 측정 항목들이 전체 프로세스를 반영했습니다: 네 번의 숙고, 열두 번의 생성(generations), 열두 번의 비평(critiques), 열두 번의 수정(revisions), 열두 번의 심판 점수 부여, 그리고 하나의 완료된 의식.

또한, 문제가 발생하는 순간 병목 현상을 보여줍니다. 의식이 아직 진행 중일 때, 공급업체별 활성 호출 게이지는 그렇지 않으면 순수한 추측에 불과할 질문—시스템이 고장 났는지, 트레이스가 손실되었는지, 심판이 실패했는지?—에 훨씬 더 구체적인 답변을 제공합니다: 현재 실행 중인 모델의 긴 호출이 남아 있다는 것입니다.

여기에 운영상의 가치가 있습니다. 관측 가능성(observability)은 단순히 나중에 이야기를 재구성하는 데만 사용되는 것이 아닙니다. 시스템이 결정하는 동안 작동하는 데에도 사용됩니다.

가장 흥미로운 측정 항목은 단지 '심판이 어떤 점수를 주었는지'가 아닙니다. 심판이 무언가를 변경했는지 여부입니다.