현재 모든 주요 AI 플랫폼은 정확히 동일한 문제, 즉 메모리(Memory)를 해결하려고 노력하고 있습니다.

• OpenAI는 ChatGPT Memory를 도입했습니다.
• Anthropic은 Claude Projects를 제공했습니다.
• Google Gemini는 세션 간 컨텍스트(cross-session context)를 유지합니다.

그들은 모두 올바른 문제를 다루고 있지만, 각자의 독점적인 장벽(proprietary walls) 내부에서 이를 해결하고 있습니다.

여러분의 전체 엔지니어링 워크플로우가 단일 플랫폼 내에서 이루어진다면 이는 괜찮습니다. 하지만 현대의 소프트웨어 개발자들에게 그런 경우는 드뭅니다.

**"컨텍스트 재구성 비용 (Context Reconstruction Tax)"

오늘날의 전형적인 엔지니어링 워크플로우는 단일 모델에 의존하지 않습니다. 대신 여러 모델의 특화된 강점을 활용합니다:

• 빠른 아이디어 구상 및 신속한 유틸리티 스크립트 작성을 위한 ChatGPT.
• 심도 있는 아키텍처 추론 및 긴 컨텍스트 리팩토링(long-context refactoring)을 위한 Claude.
• 교차 검증 및 대안적 접근 방식을 위한 Gemini.

우리는 더 이상 단 하나의 "최고"인 모델을 찾는 것이 아니라, 앙상블(ensemble)을 오케스트레이션하고 있습니다.

문제는 무엇일까요? 제공업체를 바꿀 때마다 막대한 컨텍스트 재구성 비용(Context Reconstruction Tax)을 지불해야 한다는 점입니다.

[ ChatGPT ]  ──(수동 복사/붙여넣기)──>  [ Claude ]  ──(수동 복사/붙여넣기)──>  [ Gemini ]
    │                                     │                                    │
    └── 아키텍처 재설명                   └── 제약 사항 재설명                 └── 컨벤션(Conventions) 재설명

이는 API 토큰의 문제가 아니라, 인간의 운영 피로도(human operational fatigue)의 문제입니다. 여러분은 시스템 아키텍처, 기술적 제약 사항, 코딩 표준, 비즈니스 목표, 그리고 과거의 결정 사항들을 끊임없이 다시 설명해야만 합니다.

아이러니하게도, AI는 복잡한 컨텍스트를 이해하는 데는 놀라울 정도로 뛰어나게 되었지만, 도구 간에 이를 공유하는 데는 형편없게 되었습니다.

잘못된 추상화: "애플리케이션 상태"로서의 컨텍스트

AI 플랫폼이 메모리를 내부 애플리케이션 상태(application state)로 취급할 때, 그들은 지식을 중심으로 한 벤더 종속(vendor lock-in)을 만들어냅니다. 하지만 소프트웨어 엔지니어링은 이러한 패턴을 반복적으로 거부해 왔습니다:

• 소스 코드 (Source code)는 VS Code의 소유가 아닙니다. 버전 관리되는 저장소 (repository)에 존재합니다.
• 인프라 상태 (Infrastructure state)는 클라우드 대시보드의 소유가 아닙니다. 선언적인 Terraform / IaC 파일에 존재합니다.
• 데이터 (Data)는 데이터베이스 관리 도구의 소유가 아닙니다. 스키마 (schema)와 스토리지 계층 (storage layer)에 속합니다.

이 모든 것들은 다양한 도구들이 그 위에서 작동하는 공유 인프라 계층 (shared infrastructure layers)입니다.

만약 AI 컨텍스트 (AI context)가 정확히 동일한 진화 경로를 따른다면 어떻게 될까요?

┌─────────────────────────────────────────────────────────┐
│                 공유 컨텍스트 계층 (Shared Context Layer)                    │
│     (시스템 규칙, 아키텍처, 프로젝트 히스토리)       │
│ ...                                                     │

컨텍스트를 구독 서비스에 종속된 내부 애플리케이션 상태 (internal application state)로 취급하는 대신, 우리는 컨텍스트를 인프라 (Infrastructure)로 취급해야 합니다.

"인프라로서의 컨텍스트 (Context as Infrastructure)"는 어떤 모습일까요?

컨텍스트가 제공자 (provider)가 아닌 개발자나 프로젝트가 소유하는, 분리된 선언적 계층 (decoupled, declarative layer)이 되면 다음과 같은 강력한 기능들이 나타납니다:

1. 제공자 독립적 컨텍스트 (Provider-Independent Context)
   당신의 시스템 설계, 데이터베이스 스키마, 포맷팅 규칙은 특정 LLM 래퍼 (wrapper)나 채팅 UI와 무관하게 독립적으로 존재합니다.

2. 거대 프롬프트 (Monolithic Prompts) 대신 조합 가능한 프로필 (Composable Profiles)
   2,000단어에 달하는 거대한 프롬프트 템플릿을 붙여넣는 대신, 컨텍스트를 모듈식으로 조합할 수 있습니다:

활성 컨텍스트 (Active Context) = 기본 스택 규칙 (Base Stack Rules) + 보안 가드레일 (Security Guardrails) + 기능 명세 (Feature Spec)

3. 이동 가능한 페르소나 (Traveling Personas)
   팀의 아키텍처 페르소나나 코드 리뷰어 지침은 OpenAI 또는 Anthropic 계정이 아니라, 저장소 (repository)나 로컬 워크스페이스 (local workspace)와 함께 이동합니다.

4. 컨텍스트를 위한 Git 방식의 버전 관리 (Git-like Versioning for Context)
   컨텍스트는 소프트웨어가 진화함에 따라 함께 진화합니다. 컨텍스트를 인프라로 취급하면, 생성된 코드를 형성하는 바로 그 지침들에 대해 브랜칭 (branching), 차이점 비교 (diffs), 롤백 (rollbacks) 및 히스토리 추적 (history tracking)이 가능해집니다.

철학에서 클라이언트로: ContxtAI 구축하기

이 패러다임(paradigm)을 탐구하기 시작했을 때, 저는 프롬프트 관리(prompt management)를 위한 도구를 만드는 것이 목표가 아니라는 것을 깨달았습니다. 그것은 더 넓은 아키텍처 가설(architectural hypothesis)을 테스트하는 것이었습니다. 즉, 컨텍스트 관리(context management)를 AI 제공업체(AI providers)로부터 분리할 수 있는가 하는 점이었습니다.

이를 테스트하기 위해, 저는 ContxtAI를 구축하기 시작했습니다. 이는 컨텍스트를 제공업체의 상태(provider state)가 아닌 인프라(infrastructure)로 취급하도록 설계된 실험적인 브라우저 및 개발자 레이어(developer layer)입니다.

이 도구는 벤더 종속(vendor lock-in) 없이 기존 워크플로(workflow)에 직접 통합되는 로컬 우선(local-first) 방식의 공유 컨텍스트 평면(shared context plane) 역할을 합니다.

GitHub (⭐) :
https://github.com/vinaykolupula/ContxtAI
이 프로젝트가 유용하다고 느끼신다면, GitHub에서 별(star)을 눌러주시면 큰 힘이 됩니다! ⭐

커뮤니티를 위한 공개 기술 질문

다른 개발자들이 오늘날 멀티 모델 워크플로(multi-model workflows)와 로컬 컨텍스트(local context)를 어떻게 관리하고 있는지 궁금합니다.

• 소유권 (Ownership): AI 컨텍스트는 사용자가 소유해야 할까요, 아니면 제공업체 플랫폼 내에 잠겨 있어야 할까요?
• 아키텍처 (Architecture): 특정 벤더에 종속된 메모리(vendor-specific memory)가 장기적으로 지속 가능할까요, 아니면 우리는 공유 컨텍스트 레이어(shared context layer)를 향해 가고 있을까요?
• 기능 (Capabilities): 만약 컨텍스트가 독립적인 인프라가 된다면, 프롬프트 동기화(prompt syncing) 외에 어떤 기능들을 기대하시나요?

링크 및 탐색
이 패러다임을 테스트하거나 실험에 기여하는 데 관심이 있다면:

📦 Chrome 확장 프로그램: Chrome 웹 스토어에서 ContxtAI를 설치하세요.

💻 오픈 소스 저장소: **GitHub**에서 ContxtAI를 Star/Fork 하세요.

🚀 출시 지원하기: **Product Hunt**에서 저희를 확인해 보세요.

여러분의 의견이나 워크플로 해킹 (workflow hacks)을 아래 댓글로 들려주시면 감사하겠습니다!