APC가 모든 접점에 도달할 수 있도록 APX는 하나의 코어를 유지합니다

많은 에이전트 도구들이 조용히 별개의 제품들로 분리되곤 합니다.

CLI는 하나의 동작 방식을 가집니다. 웹 패널은 또 다른 방식을 키워나갑니다. Telegram은 단순화된 봇 루프를 가집니다. 음성(Voice)은 자체적인 프롬프트 스택을 가집니다. 데스크톱 헬퍼는 동일한 결정 사항들을 다시 구현하기 시작합니다.

그러한 아키텍처는 처음에는 빨라 보이지만, 대개 드리프트(drift, 괴리)를 발생시킵니다.

APC와 APX는 의도적으로 그러한 분리를 피합니다.

APC는 휴대 가능한 컨텍스트 계층(portable context layer)입니다. 이는 저장소(repository)에 내구성이 있는 프로젝트 계약(durable project contract)인 AGENTS.md, .apc/, 에이전트 파일, 스킬(skills), 명령어(commands), 그리고 MCP 힌트(hints)를 유지합니다. APX는 일상적으로 사용하는 런타임(runtime) 및 툴링(tooling) 계층입니다. 이는 해당 컨텍스트를 읽고, 에이전트 루프(agent loop)를 실행하며, CLI, 웹, 데스크톱, 루틴(routines), Telegram과 같은 접점(surfaces)을 통해 이를 노출합니다.

핵심적인 세부 사항은 이것입니다: APX는 모든 접점마다 서로 다른 두뇌를 구축하는 대신, **하나의 핵심 에이전트 루프(one core agent loop)**를 유지하려고 노력합니다.

이것이 중요한 이유

APX 아키텍처 결정 기록(architecture decision record)은 분리에 대해 명확하게 명시하고 있습니다: src/core/는 공유 로직을 보유하고, src/host/는 장기 실행되는 데몬 프로세스(daemon processes)를 보유하며, src/interfaces/는 사용자 대면 접점(user-facing surfaces)을 보유합니다.

이것은 단순한 폴더 정리 작업이 아닙니다.

이는 중요한 동작이 단 한 번만 존재함을 의미합니다.

프롬프트 빌더(prompt builder), 모델 라우팅(model routing), 툴 루프(tool loop), 메모리 브로커(memory broker), 지연 툴 활성화(lazy tool activation), 그리고 저지 루프(judge loop)는 core/에 속합니다. 데몬(daemon)은 해당 로직을 HTTP, 플러그인(plugins), 그리고 런타임 프로세스(runtime processes)에 맞게 조정합니다. CLI, 웹, 데스크톱 및 기타 인터페이스는 가볍게(thin) 유지됩니다.

이러한 설계는 APC 또한 보호합니다.

만약 모든 접점이 각자의 프롬프트 규칙과 프로젝트 컨텍스트에 대한 독자적인 해석을 만들기 시작한다면, APC는 더 이상 휴대 가능한 계약이 아니라 각 진입점(entry point)마다 다르게 해석되는 모호한 제안이 되어버릴 것입니다. 휴대 가능한 컨텍스트 계층은 런타임이 해석의 일관성을 유지할 때에만 작동합니다.

APX의 구체적인 예시

APX에서 runSuperAgent()는 src/core/agent/super-agent.js에 존재합니다.

그 단일 함수는 공유 에이전트 러너 (shared agent runner)를 호출하기 전에 관련 메모리 (memory), 활성 스레드 컨텍스트 (active thread context), 지연 도구 상태 (lazy tool state), 모델 라우팅 (model routing), 확인 처리 (confirmation handling), 그리고 선택적인 심판 루프 (judge loop)를 조립합니다.

그 후 여러 서피스 (surfaces)가 동일한 로직을 호출합니다.

코드 그래프를 보면 데몬 API (daemon API), 데스크톱 플러그인 흐름 (desktop plugin flow), Telegram 답장 경로 (Telegram reply path), 루틴 (routines), 코드 모드 (code mode), 그리고 서브에이전트 실행 (subagent execution)으로부터의 인바운드 호출이 나타납니다. 이것이 바로 핵심입니다: 서로 다른 서피스들이 동일한 코어 동작을 공유한다는 것입니다.

시스템 프롬프트 (system prompt) 조립도 동일한 규칙을 따릅니다. src/core/agent/prompt-builder.js에 있는 buildSuperAgentSystem()은 정체성 (identity), 메모리 (memory), 채널 컨텍스트 (channel context), 프로젝트 인덱스 (project index), 프로젝트 에이전트 컨텍스트 (project agent context), 기술 (skills), 그리고 음성 모드 규칙 (voice-mode rules)을 하나의 구성된 시스템 프롬프트로 계층화합니다. 서피스는 채널 메타데이터 (channel metadata)를 전달할 수 있지만, 전체 프롬프트 모델을 분기(fork)하지는 않습니다.

따라서 APC 프로젝트 컨텍스트가 변경될 때, APX는 이를 따라잡기 위해 다섯 개의 별도 구현체를 가질 필요가 없습니다.

얇은 서피스 (thin surfaces)가 제공하는 이점

이 접근 방식은 세 가지 실질적인 이점을 제공합니다.

첫째, 동작이 일관되게 유지됩니다. 코어 에이전트 루프 (core agent loop)가 새로운 안전 규칙이나 메모리 규칙을 학습하면, 웹(web)과 Telegram은 CLI에 뒤처지지 않습니다.

둘째, 새로운 서피스를 추가하는 비용이 저렴해집니다. 코어가 이미 APC 컨텍스트를 읽고, 모델을 라우팅하며, 도구를 실행하는 방법을 알고 있다면, 데스크톱 음성 셸 (desktop voice shell)이나 브라우저 관리자 (browser admin)를 추가하는 것은 대부분 어댑터 (adapter) 작업에 불과합니다.

셋째, 버그의 원인을 파악하기가 더 쉬워집니다. 하나의 서피스가 이상하게 동작할 때, 문제가 공유 코어에 있는지 아니면 어댑터에만 있는지 질문할 수 있습니다. 이는 거의 동일한 런타임 (runtime) 다섯 개를 디버깅하는 것보다 훨씬 명확합니다.

APC가 이러한 규율에 의존하는 이유

APC는 작고, 휴대 가능하며, 리포지토리 소유 (repo-owned) 상태를 유지해야 합니다. APC는 프로젝트가 무엇을 의미하는지를 정의해야 하며, 모든 전송 계층 (transport)이 각자의 실행 의미론 (execution semantics)을 발명하도록 해서는 안 됩니다.

실행 의미론이 위치해야 할 곳은 바로 APX입니다.

하지만 만약 APX가 각 인터페이스(surface)마다 별도의 런타임 브레인(runtime brain)을 갖도록 허용한다면, 그 결과는 여전히 이식성 (portability)을 해칠 것입니다. 동일한 AGENTS.md 및 .apc/ 파일이라 할지라도 CLI, 데스크톱, 웹, 또는 Telegram 중 어떤 경로로 접속하느냐에 따라 서로 다른 에이전트 동작을 유발할 것이기 때문입니다.

이는 설령 APC 자체가 디스크 상에서 깔끔하게 유지된다 하더라도, APC를 더 취약하게 만들 것입니다.

따라서 진정한 승리는 단순히 APX가 많은 인터페이스를 가진다는 것에 있지 않습니다. 진정한 승리는 그 인터페이스들이 하나의 해석 계층 (interpretation layer)을 공유할 수 있을 만큼 충분히 얇게(thin) 유지된다는 점에 있습니다.

APC는 프로젝트 계약 (project contract)을 운반합니다.
APX는 실행 메커니즘 (execution machinery)을 운반합니다.
APX 내부에 하나의 코어를 유지하는 것이 바로 그 계약이 일상적인 사용 환경과 접촉하면서도 살아남을 수 있게 하는 핵심입니다.