모든 에이전트 시스템은 동일하고 불편한 트레이드오프(trade-off)에 직면합니다. 코드 리뷰와 git 히스토리를 견뎌낼 수 있는 깊고 잘 조직된 지식 베이스를 원하면서도, 동시에 런타임은 빠르게 움직이고 집중력을 유지해야 합니다. 이 두 가지 요구사항은 서로 충돌합니다. 더 많은 지침을 보존할수록, 그 모든 것을 프롬프트에 쏟아붓고 결과가 좋기를 바라는 유혹에 빠지기 쉽습니다. 하지만 그런 요행은 비용이 많이 듭니다.
Agent Project Context 생태계에서 이러한 긴장은 두 개의 레이어로 명확하게 나뉩니다. APC는 내구성(durability)을 담당하고, APX는 속도(speed)를 담당합니다. 이들이 어떻게 상호작용하는지, 그리고 왜 APX가 모든 스킬 정의를 미리 로드(preload)하기를 거부하는지를 이해하면, 대부분의 최적화 가이드보다 더 많은 프롬프트 엔지니어링의 원리를 깨닫게 될 것입니다.
아카이브와 엔진
APC의 역할은 영속성입니다. 재사용 가능한 스킬 파일을 .apc/skills/ 아래에 일반 Markdown 문서로 저장합니다. 이 파일들은 저장소(repository) 내부에 존재하므로 버전 관리 시스템과 함께 움직입니다. 배포 절차를 변경하는 풀 리퀘스트(pull request)를 생성할 수 있고, 6주 전의 보안 정책 롤백 내용을 diff로 확인할 수 있습니다. 에이전트가 정확히 무엇을 언제 알았어야 했는지 감사(audit)할 수도 있습니다. 잘못된 배포가 실행되거나 컴플라이언스 감사관이 질문을 던지기 시작할 때, 이러한 검토 가능성(reviewability)은 매우 중요합니다.
반면, APX는 현재의 순간에 집중합니다. 사용자와 모델 사이의 실제 대화를 관리합니다. APX의 목표는 지식을 아카이브하는 것이 아니라, 지식을 정밀하게 사용하는 것입니다. APX가 스킬을 영구적인 짐(baggage)처럼 취급하면 시스템 전체가 느려집니다. 컨텍스트 윈도우(context window)가 가득 차고, 토큰 비용이 상승합니다. 더 나쁜 것은, 모델의 주의력(attention)이 현재 요청과 아무런 관련이 없는 지침들로 분산된다는 점입니다.
이것이 바로 스킬 본문(skill bodies)을 온디맨드(on-demand) 방식으로 로드하는 이유입니다.
비대해진 프롬프트의 진정한 비용
대부분의 팀은 토큰에 비용이 든다는 사실을 알고 있습니다. 하지만 무관한 토큰이 정확도를 떨어뜨린다는 사실을 깨닫는 팀은 드뭅니다.
APX가 매 턴마다 사용 가능한 모든 스킬을 주입하면 프롬프트에 노이즈가 발생합니다. 모델은 배포 런북(runbook), 보안 가이드, API 스타일 참조, 테스트 체크리스트, 온보딩 FAQ를 한꺼번에 받게 됩니다. 컨텍스트 윈도우가 크더라도, 모델이 신호(signal)를 찾기 위해 먼저 노이즈를 걸러내야 한다면 추론 품질은 저하됩니다. 로컬 테스트 설정에 관한 질문에 답하면서 운영 환경 배포를 위한 보안 요구 사항에 집착할 수도 있고, 단순한 버그 수정 과정에서 릴리스 체크리스트의 단계를 환각(hallucinate)할 수도 있습니다. 관련 없는 텍스트가 한 단락씩 추가될 때마다 주의를 분산시키는 요소가 됩니다.
원리는 간단합니다. 대부분의 턴에서 대부분의 스킬이 필요하지는 않습니다. 에러 로그에 대한 빠른 수정을 요청하는 경우, 배포 런북이나 보안 강화 가이드의 전체 텍스트가 필요하지 않습니다. 모델이 에러를 확인하고, 프로젝트 컨벤션을 이해하며, 올바른 파일을 수정하기만 하면 됩니다. 무관한 스킬 본문을 로드하는 것은 모델의 작업을 돕지 않습니다. 오히려 모델이 실제 문제를 해결하기 시작하기도 전에 쓸모없는 데이터를 걸러내도록 강요할 뿐입니다.
온디맨드 로딩 방식
메커니즘은 단순하지만 의도적입니다. APC는 계속해서 그라운드 트루스(ground truth)를 보유합니다. 스킬 정의는 원래 있어야 할 곳인 .apc/skills/<name>.md에 그대로 남아 있습니다.
APX는 해당 파일들을 활성 메모리에 미러링(mirror)하지 않습니다. 대신, 스킬 이름들로 구성된 컴팩트한 레지스트리를 컴파일합니다. 모델은 이 목록을 보고 카탈로그가 존재한다는 것을 이해합니다. 사용 가능한 기능이 무엇인지 찾아보거나 확인해야 할 경우, list_skills 호출을 실행할 수 있습니다. 이를 통해 데이터 양을 늘리지 않고도 가시성을 확보할 수 있습니다.
작업에 스킬 파일에 인코딩된 정확한 구문, 상세 단계 또는 특정 제약 조건이 실제로 필요할 때, 모델은 load_skill을 호출합니다. 바로 그 시점에, 그리고 오직 그 시점에만 APX가 APC에서 전체 Markdown 본문을 가져와 컨텍스트에 주입합니다. 지침은 필요한 시점에 즉시 전달되어 의도된 목적에 한 번 사용되며, 시스템은 이를 불필요한 짐으로 계속 들고 다니지 않아도 됩니다.
라이브러리를 임포트(import)하는 것과 모든 함수 정의를 메인 파일에 직접 붙여넣는 것의 차이를 생각해보세요. 한 가지 방식은 코드베이스를 탐색 가능하게 유지하지만, 다른 방식은 우연히 컴파일될 뿐인 엉망진창인 상태를 만듭니다.
스킬이 충돌할 때 승자는 누구인가
APX는 스킬을 로드할 때 명확한 우선순위도 적용합니다. 모든 환경이 동일하지 않으며, 일반적인 조언이 로컬 지식을 결코 압도해서는 안 됩니다.
프로젝트 스킬(Project skills)이 최우선 순위를 갖습니다. 이 파일들은 현재 저장소의 .apc/skills/ 경로에 위치합니다. 여기에는 팀의 특정 컨벤션, 커스텀 래퍼, 레거시 명명 표준, 그리고 고유한 툴체인이 담깁니다. 만약 프로젝트가 데이터베이스 마이그레이션 처리 방식을 자체적으로 정의했다면, 그 정의가 우선 적용됩니다.
다음은 글로벌 스킬(Global skills)입니다. 이는 프로젝트 자체에 정의가 없을 때 적용되는 조직 전체의 패턴을 다룹니다. 표준 라이브러리 역할을 합니다.
빌트인 런타임 스킬(Built-in runtime skills)은 최하위 계층에서 폴백(fallback) 역할을 합니다. 모든 에이전트가 이해해야 하지만, 특정 프로젝트에서 별도로 재정의할 필요가 없는 일반적인 기능들을 처리합니다.
이러한 계층적 접근 방식 덕분에 저장소는 자체 동작에 대한 제어권을 유지할 수 있습니다. 글로벌 스킬이나 빌트인 스킬이 팀에서 의도적으로 커스텀한 워크플로우를 실수로 가로채는 일은 발생하지 않습니다.
실제 적용 사례
전형적인 유지보수 작업을 상상해 보십시오. 팀원이 채팅창에 에러 로그를 붙여넣습니다. 트레이스백(traceback)은 유틸리티 모듈의 단일 null 참조를 가리킵니다. 해결책은 아마도 두 줄 정도의 방어적 코딩이면 충분할 것입니다.
온디맨드 로딩(on-demand loading)이 없는 시스템이라면, APX는 알고 있는 모든 스킬을 컨텍스트에 쑤셔 넣었을 것입니다. 모델은 그 두 줄의 코드를 건드리기 전에 고려해야 할 40페이지 분량의 텍스트를 마주하게 됩니다. 릴리스 체크리스트를 보고 버전을 올려야 하는지 고민합니다. 보안 가이드를 보고, 단순히 null 체크만 하면 되는 함수에 입력값 검증을 추가해야 할지 검토합니다. 배포 런북을 보고 스테이징 환경을 생각하기 시작합니다. 모델의 집중력이 흐트러집니다. 응답은 느려집니다. 토큰 소모량이 급증합니다.
APX의 온디맨드 설계 덕분에 모델은 이름만 확인합니다. [release-checklist], [security-guide], [deployment-runbook], 그리고 [error-handling]이 존재한다는 사실만 압니다. 처음 세 개는 무시합니다. 만약 프로젝트의 null 안정성 컨벤션이 구체적이라면 [error-handling]을 로드할 수도 있습니다. 그리고 버그를 수정합니다. 관련 없는 스킬들은 컨텍스트 윈도우에 들어오지 않았습니다. 프롬프트가 깔끔하게 유지되었기에 모델은 집중력을 유지할 수 있었습니다.
작업이 실제로 복잡할 때도 동일한 논리가 적용됩니다. 나중에 에이전트에게 운영 환경 배포를 준비하라고 요청하면, 배포 런북을 로드하고, 보안 가이드를 참고하며, 해당 단계가 필요할 때 정확히 릴리스 체크리스트를 따릅니다. 지식은 항상 그곳에 있었습니다. 단지 적절한 순간을 기다리고 있었을 뿐입니다.
아키텍처로서의 프롬프트 규율(Prompt Discipline)
APC와 APX의 분리는 단순한 구현 세부 사항이 아닙니다. 이는 프롬프트 규율에 관한 철학입니다. APC는 지식을 영구적으로 보존하여 검토 가능하고, 버전 관리가 되며, 안전하게 만듭니다. APX는 그 지식 중 얼마만큼이 현재 활성 컨텍스트에 들어갈 자격이 있는지를 결정합니다.
풍부한 스킬 카탈로그는 자산입니다. 비대해진 프롬프트는 부채입니다. 목표는 컨텍스트를 항상 활성화하지 않으면서도 이식성을 유지하는 것입니다. 저장소에는 팀이 작성한 모든 지침이 포함되어 있어야 하지만, 에이전트는 즉각적인 작업에 도움이 되는 지침만을 읽어야 합니다.
만약 시스템이 모델로 하여금 매 턴마다 모든 스킬의 본문을 들고 다니게 강제한다면, 당신은 지능형 어시스턴트를 만드는 것이 아닙니다. 모든 아카이브를 모든 참고 데스크 질문마다 끌고 오는 사서(librarian)를 만들고 있는 것입니다. 모든 것을 저장하십시오. 중요한 것만 로드하십시오. 그것이 에이전트를 빠르게 유지하고, 컨텍스트를 깔끔하게 하며, 추론 능력을 날카롭게 유지하는 방법입니다.