“Super-Agent”는 페르소나가 아닌 모드(Mode)로 유지되어야 합니다

기본 런타임 루프(runtime loop)에는 기술적인 이름이 필요합니다.

그것이 사용자에게 해당 이름의 캐릭터를 만나야 한다는 의미는 아닙니다.

이것은 작은 디자인 선택이지만 중요합니다. APX에서 “super-agent”는 페르소나(persona)가 아닌 모드(mode)로 유지되어야 합니다.

APC는 휴대 가능한 컨텍스트 레이어(portable context layer)입니다. 이는 AGENTS.md 및 .apc/agents/에서 프로젝트 에이전트(project agents)를 정의합니다. 이 파일들은 리포지토리(repository)가 도구와 머신을 가로질러 운반할 수 있는 내구성이 있는 계약(durable contract)입니다. APX는 일상적으로 사용하는 런타임(runtime) 및 툴링(tooling) 레이어입니다. 세션을 실행하고, CLI 및 웹 관리자(web admin)를 노출하며, 메시지를 관리하고, 명시적인 프로젝트 에이전트 슬러그(project agent slug)가 선택되지 않았을 때 기본 런타임이 어떻게 동작할지를 결정합니다.

바로 이 지점에서 혼란이 시작됩니다.

만약 런타임이 코드, 프롬프트(prompts), 라우트(routes), 파일 및 메타데이터에서 폴백 루프(fallback loop)의 이름을 “super-agent”라고 명명한다면, 사용자에게도 그 이름을 보여주고 싶은 유혹에 빠지게 됩니다. 하지만 일단 그렇게 되면, 모델들은 해당 라벨을 하나의 캐릭터처럼 취급하기 시작합니다. 런타임의 기본 실행 모드(execution mode)로 동작하는 대신, “super-agent”라는 이름의 특별한 페르소나가 존재하는 것처럼 말하기 시작합니다.

APX의 디자인 결정은 그보다 더 날카롭습니다.

내부적으로 “super-agent”는 기술 용어로 남습니다. 이는 설정 키(config keys), 프롬프트 파일, 채널 메타데이터 및 구현 경로(implementation paths)에 그대로 유지될 수 있습니다. 하지만 사용자에게 노출되는 인터페이스(user-facing surfaces)는 기술적인 모드 이름이 아니라 ~/.apx/identity.json에서 가져온 디스플레이 정체성(display identity)을 보여주어야 합니다. 즉, 엔지니어를 위해서는 런타임 용어를 유지하고, 사용자를 위해서는 인간 중심의 정체성을 유지하라는 것입니다.

이러한 분리는 APC와 APX에 깔끔하게 들어맞습니다.

APC는 프로젝트 에이전트의 이름을 reviewer, architect 또는 writer와 같이 명명합니다. 이러한 이름들은 안정적인 프로젝트 역할(project roles)을 설명하기 때문에 리포지토리에 속합니다. 반면, APX는 리포지토리에 소유된 에이전트 슬러그가 선택되지 않았을 때 기본 루프가 필요할 수 있습니다. 그 루프는 런타임 동작(runtime behavior)이지, 휴대 가능한 프로젝트 컨텍스트(portable project context)가 아닙니다. 이를 모드(mode)로 취급함으로써 가짜 리포지토리 역할을 만들어내는 대신 APC의 경계를 보존할 수 있습니다.

실질적인 예시를 통해 그 차이가 명확해집니다.

프로젝트 에이전트를 대상으로 하지 않은 요청에 대한 Telegram 답장, CLI 상태 표시줄(status line), 또는 사이드바 레이블을 상상해 보십시오. 만약 UI에 “super-agent”라고 표시된다면, 사용자는 AGENTS.md에 정의되어 있지 않고 프로젝트 계약(project contract)에 실제로 속하지도 않는 정체불명의 추가 액터(actor)를 보게 됩니다. 만약 UI에 “APX” 또는 로컬 ID 파일(local identity file)이 정의한 다른 표시 이름이 나타난다면, 시스템은 정직해집니다. 즉, 이것이 기본 모드(default mode)로 응답하고 있는 런타임(runtime)임을 보여주는 것입니다.

이러한 정직함은 이식성(portability) 측면에서도 중요합니다.

만약 어떤 리포지토리가 APC 내에 세 개의 에이전트를 정의한다면, 다른 APC 호환 도구는 APX 특유의 명명 관습(naming folklore)을 상속받지 않고도 해당 역할들을 읽을 수 있어야 합니다. “Super-agent”는 유용한 APX 구현 어휘(implementation vocabulary)이지만, 마치 네 번째 리포지토리 에이전트인 것처럼 이식 가능한 계약(portable contract)으로 유출되어서는 안 됩니다.

이는 또한 미묘한 프롬프트 버그(prompt bug)를 방지합니다.

사용자에게 보이는 텍스트와 내부 레이블이 동일한 페르소나(persona) 같은 용어를 사용할 때, 언어 모델(language models)은 종종 이를 그대로 모방합니다. 모델은 해당 이름으로 자신을 소개하거나, 그 이름을 중심으로 배경 이야기를 만들거나, 마치 그 모드 자체가 지속적인 캐릭터인 것처럼 말합니다. 일단 이런 현상이 시작되면 런타임 경계가 모호해집니다. 모델은 더 이상 단순히 폴백 경로(fallback path)를 실행하는 것이 아니라, 구현 세부 사항(implementation detail)을 역할극(roleplaying) 하게 됩니다.

“super-agent”를 모드(mode)로 유지하면 이 문제가 해결됩니다.

• APC는 실제 프로젝트 에이전트 이름을 이식 가능하게 유지합니다.
• APX는 폴백 실행(fallback execution)을 로컬로 유지합니다.
• 사용자 대상 문구(User-facing copy)는 내부 구현 전문 용어(implementation jargon)가 아닌 런타임 정체성을 반영합니다.

이것이 인간과 도구 모두에게 더 나은 시스템입니다.

인간은 Telegram, CLI, 오버레이(overlays), 상태 뷰(status views) 전반에 걸쳐 일관된 하나의 액터 이름을 보게 됩니다. 도구는 에이전트 슬러그(agent slug)가 존재하지 않을 때 실행되는 코드 경로에 대해 정확한 내부 용어를 유지합니다. 리포지토리 역할이 리포지토리 역할로 남기 때문에 APC는 깔끔하게 유지됩니다. 런타임 동작이 런타임 동작으로 남기 때문에 APX는 정직하게 유지됩니다.

이 논지는 작지만 견고합니다:

런타임이 폴백 루프(fallback loop)를 구현하는 것을 돕기 위해 이름이 존재하는 경우, 그 이름은 APX 내부(internals)에 두십시오.

실제 프로젝트 에이전트를 설명하기 위해 이름이 존재하는 경우, 그것을 APC에 두십시오.

“Super-agent”는 두 번째 범주가 아닌 첫 번째 범주에 속합니다.