글로벌 컨텍스트는 APC 외부에 있어야 합니다
APC는 휴대 가능한 컨텍스트 레이어입니다. APX는 로컬 런타임 레이어입니다.
이 두 레이어를 건강하게 유지하려면 한 가지 규칙만 따르면 됩니다. 새로 클론(clone)한 후에도 유지되어야 하는 것이라면 APC에 넣으세요. 특정 사용자, 머신 또는 프로세스에 의존하는 것이라면 APC 외부에 두어야 합니다.
프로젝트가 커지면 유혹도 따릅니다. 설정 하나를 더 추가하거나 로컬 경로 하나를 더 넣고 싶어질 수 있습니다. 엄격하게 관리하지 않으면 저장소(repo)는 머신 데이터의 쓰레기통이 됩니다. 이는 저장소를 취약하게 만듭니다.
APC는 프로젝트 소유의 의미를 담고 있습니다. 이는 저장소가 지니는 공유 계약과 같습니다.
좋은 APC 콘텐츠에는 다음이 포함됩니다:
- 프로젝트 정체성
- 에이전트 역할
- 재사용 가능한 기술(skills)
- 큐레이션된 프로젝트 메모리
- 프로젝트 수준의 MCP 힌트
- AGENTS.md의 저장소 전역 지침
팀원이나 새로운 머신은 체크아웃(checkout) 직후에 이러한 사실들을 바로 읽을 수 있어야 합니다.
글로벌 컨텍스트는 다릅니다. 이는 사용자 또는 워크스테이션에 속합니다.
글로벌 컨텍스트의 예:
- API 키
- 에디터 설정(preferences)
- 로컬 별칭(aliases)
- 머신별 도구 경로
- 개인 런타임 메모리
- 캐시
- 세션 기록(transcripts)
- 메시지 로그
APX는 이러한 상태를 로컬로 유지합니다. 런타임 상태를 ~/.apx/ 아래에 저장함으로써 프로젝트를 공유 가능한 상태로 유지합니다.
이 레이어들을 혼합하면 세 가지 문제가 발생합니다:
- 휴대성(Portability)이 깨집니다. 로컬 설정에 의존하는 저장소는 신뢰하기 어렵습니다.
- 리뷰가 지저분해집니다. 풀 리퀘스트(Pull requests)는 워크스테이션의 부수적인 데이터가 아니라 프로젝트의 결정 사항을 보여주어야 합니다.
- 보안 정보(Secrets)가 유출됩니다. 로컬 세부 정보를 저장하면 실수로 잘못된 파일을 커밋하기 쉽습니다.
설정을 추가하기 전에 스스로에게 물어보세요: 다른 기여자가 클론 직후에 이것을 즉시 필요로 할까요?
만약 그렇다면, APC를 사용하세요.
- 모든 클론을 위한 리뷰어 에이전트? APC.
- 개인 API 키? APC 아님.
- 권한에 대한 프로젝트 결정 사항? APC.
- 로컬 브라우저 경로? APC 아님.
- 공유 MCP 힌트? APC.
- 실행 캐시? APC 아님.
이 규칙은 자동화를 견고하게 만듭니다. APC는 휴대 가능한 의미를 제공하고, APX는 로컬 상태를 제공합니다.
경계를 명확히 유지하세요. 그래야 스택을 디버깅하고, 공유하고, 도구 간에 이동하기가 쉬워집니다.
저장소와 함께 이동하는 컨텍스트에는 APC를 사용하세요. 개인적이거나 일시적인 것이라면 로컬에 유지하세요.
Source: https://dev.to/agentprojectcontext/global-context-belongs-outside-apc-4fg8
Optional learning community: https://t.me/GyaanSetuAi