매일 아침 AI 코딩 도구를 열 때마다 어제의 결정을 다시 설명하는 개발자가 팀에 몇 명이나 있는가. "Redis로 결정했잖아요, 지난주에"라는 말이 AI에게도, 동료에게도 반복되고 있다면, 그건 도구의 문제가 아니라 컨텍스트를 자산으로 다루지 않는 팀의 문제다.
최근 세 가지 흐름이 이 문제를 서로 다른 각도에서 조명하고 있다. dev.to에 올라온 EGC(Extended Global Context) 프로젝트는 Claude Code, Cursor, Codex 등 9개 이상의 AI 코딩 도구에 MCP 서버를 설치해 세션 간 영구 메모리를 공유하는 오픈소스 솔루션이다. Anthropic의 $965억 달러 밸류에이션을 분석한 같은 플랫폼의 개발자 에세이는 플랫폼 의존성 리스크와 '이식 가능한 워크플로우'의 중요성을 짚는다. 그리고 velog의 프롬프트 인터페이스 설계 아티클은 프롬프트를 문자열이 아닌 입력 계약(input contract)으로 다루는 설계 관점을 제시한다. 세 개를 따로 읽으면 각각 흥미로운 팁이지만, 함께 읽으면 하나의 질문으로 수렴된다. 컨텍스트를 어떻게 팀 자산으로 구조화할 것인가.
컨텍스트 소실은 개인 문제가 아니다
EGC가 해결하려는 문제는 단순하다. 세션을 닫으면 AI는 모든 걸 잊는다. 다음 세션에서 스택 설명, 아키텍처 결정, 지난번에 실패한 접근법을 다시 설명하는 데 약 1,500 토큰이 소비된다. EGC는 이걸 200 토큰으로 줄인다. 절약되는 비용 자체($0.08/월)는 작다. 하지만 이 숫자를 팀 규모로 환산하면 달라진다. 5명 팀, 하루 3세션, 한 달이면 컨텍스트 재설명에만 수백만 토큰이 증발하고 있을 수 있다. 더 중요한 건 토큰이 아니라 흐름의 단절이다.
EGC의 구조는 주목할 만하다. 상태 파일이 ~/.egc/state/에 저장되고, IDE가 아닌 프로젝트를 따라다닌다. egc-memory 서버가 세션 시작 시 컨텍스트를 로드하고 종료 시 저장하며, egc-guardian 서버가 백그라운드에서 셸 인젝션 차단과 민감 경로 보호를 담당한다. 개인이 설치하면 개인의 워크플로우를 보호하는 도구지만, 팀이 같은 상태 파일 포맷과 저장 위칙을 합의하면 팀 지식 베이스가 된다. 이 차이가 핵심이다.
플랫폼 의존성이 강제하는 이식성 설계
Anthropicが $965억 달러 밸류에이션을 받은 직후 나온 개발자 에세이가 흥미로운 이유는 숫자보다 태도다. 필자는 "나는 내 프롬프트와 워크플로우를 특정 벤더의 API 형태가 아닌, 내가 일하는 방식에 가치가 머물도록 이식 가능하게 유지한다"고 쓴다. 마이크로소프트가 내부 Claude Code 라이선스를 철회하고 자사 툴링으로 전환한 사례가 그 이유를 설명한다. 한 대형 고객의 조달 결정이 같은 스택 위에 있는 모든 소규모 개발자에게 파급됐다.
이건 개인 개발자만의 리스크가 아니다. 팀이 특정 AI 도구의 컨텍스트 관리 방식에 완전히 종속되면, 그 도구가 바뀌거나 사라질 때 팀의 축적된 컨텍스트도 함께 증발한다. CLAUDE.md나 .cursor/rules 같은 도구별 설정 파일에 팀의 모든 규칙을 분산 저장하는 방식이 바로 이 함정이다. 형식은 다르지만 EGC가 제안하는 도구-독립적 상태 파일, 그리고 프롬프트 인터페이스 설계 아티클이 강조하는 버전 관리 가능한 프롬프트 스펙이 같은 방향을 가리키는 이유다.
프롬프트는 메모가 아니라 계약이다
velog의 프롬프트 인터페이스 설계 아티클은 이 구조화의 언어를 제공한다. 프롬프트를 "좋은 문장"이 아닌 입력 계약으로 보면 팀 표준화가 가능해진다. role, task, context, input_data, constraints, output_schema, failure_policy—이 7개 필드로 프롬프트를 분해하면 버전 관리, 리뷰, 테스트가 모두 코드와 동일한 방식으로 작동한다. AI가 "이상하게" 답하는 것처럼 보이는 문제의 상당수는 모델 품질이 아니라 입력 스펙이 비어 있기 때문이라는 진단은 팀 단위에서 더 자주 발생한다.
팀에서 이 설계 관점이 특히 중요한 이유는 온보딩이다. 새 팀원이 합류했을 때 "우리 팀은 이렇게 AI를 씁니다"를 전달하는 가장 확실한 방법은 잘 작성된 프롬프트 스펙과 few-shot 예시 라이브러리다. "강의를 거의 못 들었는데 결제 취소 가능한가요?"가 왜 needs_review: true로 분류되어야 하는지를 예시로 보여주는 것이 말로 설명하는 것보다 훨씬 빠르게, 훨씬 정확하게 팀의 판단 기준을 전달한다.
팀 표준화를 위한 실행 순서
세 흐름을 종합하면 실행 순서가 나온다. 첫째, 컨텍스트 저장 포맷을 도구 밖에서 정의한다. EGC의 상태 파일 구조처럼, 어떤 도구를 쓰더라도 읽을 수 있는 포맷으로 팀의 아키텍처 결정, 실패한 접근법, 진행 중인 작업을 기록한다. Git으로 관리하면 더 좋다. 둘째, 프롬프트를 코드 리포지토리에 넣는다. 자연어 덩어리가 아니라 role/constraints/output_schema로 분해된 형태로 저장하고, 변경 시 테스트 케이스를 함께 업데이트한다. 셋째, 도구 전환을 가정하고 설계한다. Claude Code에서만 동작하는 설정, Cursor에서만 읽히는 규칙 파일은 플랫폼 전환 비용을 팀이 고스란히 지불하게 만든다.
도구의 밸류에이션이 오르내리고, 라이선스 정책이 바뀌고, 더 좋은 모델이 3개월마다 나오는 환경에서 팀의 경쟁력은 어떤 도구를 쓰는가가 아니다. 컨텍스트를 얼마나 잘 구조화했느냐, 그리고 그 구조가 다음 도구에서도 그대로 작동하느냐다. EGC가 해결하는 것은 세션 메모리 문제지만, 그것이 가리키는 것은 팀 지식의 이식성이다. 프롬프트를 입력 계약으로 다루는 설계가 해결하는 것은 답변 품질 문제지만, 그것이 가리키는 것은 팀 표준의 버전 관리다. 두 방향이 만나는 지점에서 AI-First 팀의 진짜 인프라가 시작된다.