음성은 채널이 아니라 모드입니다

많은 에이전트 시스템(agent systems)이 음성을 별도의 제품 카테고리로 전환합니다.

그것은 UI 상에서는 깔끔해 보일 수 있지만, 잘못된 추상화(abstraction)를 만들어냅니다.

APC와 APX에서는 더 깔끔한 모델이 더 단순합니다. APC는 지속 가능한 프로젝트 컨텍스트(project context)를 전달하고, APX는 런타임(runtime)에서 해당 컨텍스트가 어떻게 사용될지를 결정합니다. 해당 런타임 내부에서 음성은 별도의 정체성을 가진 독립적인 채널이 아니라, 표면(surface) 위에 레이어링된 하나의 모드(mode)로서 작동할 때 더 효과적입니다.

이러한 구분은 미세하지만, 놀라울 정도로 많은 드리프트(drift)를 방지합니다.

APC는 휴대 가능한 컨텍스트 레이어(portable context layer)입니다. 이는 프로젝트 에이전트, 프로젝트 규칙, 기술(skills), 그리고 기타 리포지토리 소유의 사실들을 정의합니다. APX는 일상적으로 사용하는 런타임 및 툴링 레이어(runtime and tooling layer)입니다. 이는 CLI, 웹 관리(web admin), 데스크톱 앱, 루틴(routines) 및 기타 실행 경로를 지원합니다. 따라서 APX가 답변을 어떻게 말하고, 형식을 지정하거나, 분할할지 결정할 때, 그 결정은 휴대 가능한 프로젝트 구조가 아닌 런타임 동작(runtime behavior)에 속합니다.

코드는 이를 직접적으로 반영합니다.

src/core/constants/channels.js에서 APX는 채널 이름을 telegram, cli, web, desktop, code와 같은 표면(surfaces)으로 유지하며, 파일 주석에는 규칙이 명확하게 명시되어 있습니다: 음성은 채널이 아니라 channelMeta.voice를 통해 레이어링된 모드라는 점입니다. src/core/agent/prompt-builder.js에서 CHANNEL_PROMPT_FILES는 표면을 channels/<surface>.md로 매핑하는 반면, 음성 지침은 나중에 별도의 음성 모드(voice-mode) 블록을 통해 전달됩니다. 프롬프트 빌더(prompt builder)는 channelMeta.voice로부터 voice를 계산한 다음, 조건부로 modes/voice.md 동작을 추가합니다.

이러한 분리는 세 가지 실질적인 이유로 중요합니다.

첫째, 중복된 프롬프트 트리(prompt trees)를 방지합니다.

만약 음성이 별도의 채널이 된다면, 모든 인터페이스(surface)는 갑자기 두 번째 버전을 필요로 하게 됩니다: cli와 voice-cli, deck와 voice-deck, desktop와 voice-desktop, 그리고 아마 나중에는 telegram과 voice-telegram까지 말이죠. 이는 유지보수 비용의 폭발적인 증가를 초래합니다. 작은 지침(instruction) 변경 사항이 더 이상 전역적으로 적용되지 않고, 거의 중복되는 채널 프롬프트들 사이로 파편화되기 시작합니다. 하나의 인터페이스 블록과 하나의 선택적인 음성 레이어(voice layer)를 유지함으로써, APX는 인터페이스당 하나의 프롬프트 트리(prompt tree)와 하나의 공유된 음성 동작 레이어를 보존합니다.

둘째, 로깅(logging)과 런타임 상태(runtime state)의 정직함을 유지합니다.

채널은 "이 상호작용이 어디에서 발생했는가?"라는 질문에 답합니다. 모드(Modes)는 다른 질문에 답합니다: "이 응답이 어떻게 동작해야 하는가?" 이 둘은 동일한 차원이 아닙니다. 데스크톱(desktop) 상호작용은 응답이 소리 내어 읽히든 아니든 여전히 데스크톱 상호작용입니다. 덱(deck) 상호작용은 TTS가 읽어주든 사용자가 조용히 훑어보든 여전히 덱 상호작용입니다. 만약 음성이 채널이 된다면, 로그는 작업이 실제로 발생한 인터페이스를 숨기기 시작할 것입니다.

셋째, APC를 깔끔하게 유지합니다.

APC는 응답이 소리 내어 읽히는지, 속삭여지는지, TTS를 위해 분할되는지, 혹은 감정적 전달을 위해 태그가 붙는지 신경 쓸 필요가 없어야 합니다. 이것들은 런타임(runtime)의 관심사입니다. APC는 다른 호환 가능한 런타임도 읽을 수 있는 프로젝트 계약(project contract)을 정의합니다. APX는 오늘 하나의 로컬 인터페이스에 음성 포맷팅이 필요한지 여부를 결정합니다. 이 경계야말로 APC가 이식성(portable)을 유지하는 동시에 APX가 유용함을 유지할 수 있는 정확한 이유입니다.

데스크톱 경로가 좋은 예시입니다. src/core/constants/channels.js에서 desktop은 여전히 인터페이스입니다. APX 개발 가이드에서 데스크톱은 항상 음성 모드(voice mode)로 실행되는 것으로 설명됩니다. 이는 시스템이 데스크톱 전용 컨텍스트(context)를 보존하면서도, 필요할 때만 음성 전용 포맷팅 및 전달 규칙을 레이어로 쌓을 수 있음을 의미합니다. 동일한 인터페이스, 추가된 모드입니다.

이 아이디어에 대한 테스트도 존재합니다. tests/channel-coherence.test.js는 모든 서피스 (surface)가 동일한 슈퍼 에이전트 역할 (super-agent role)을 유지하고, 자체적인 컨텍스트 블록 (context block)을 유지하며, 음성 모드 (voice mode)가 활성화되었을 때만 추가적인 프롬프트 콘텐츠를 받는지를 확인합니다. 이는 오디오가 포함되었다는 이유만으로 가짜 채널을 만들어내는 것보다 더 나은 불변량 (invariant)입니다.

더 깊은 논지는 단순합니다.

APC는 안정적인 프로젝트의 의미를 기술해야 합니다.

APX는 런타임 실행 (runtime execution)을 기술해야 합니다.

그리고 APX 내부에서, 음성은 실제 서피스 (surface)를 대체하는 것이 아니라 그 위에 얹혀지는 수정자 (modifier)로 남아 있어야 합니다.

이 모델은 프롬프트를 더 작게 유지하고, 로그를 더 명확하게 하며, 서피스를 진화시키기 더 쉽게 만들고, 프로젝트 컨텍스트를 런타임 특유의 노이즈로부터 자유롭게 유지합니다.