이전 포스트에서 저는 MCP가 단순한 RPC 메커니즘보다는 컨텍스트 분배 계층 (context distribution layer)으로서 더 유용할 수 있다고 썼습니다.

그 이후 이어진 논의는 그 아이디어를 더욱 명확하게 만들었습니다.

진정한 핵심은 "MCP를 어떻게 사용하는가"가 아닙니다.

진정한 핵심은 다음과 같습니다:

어떻게 단계적으로 AI 시스템에 컨텍스트 (context)를 제공해야 하는가?

MCP가 유용한 이유는 단계적인 컨텍스트를 전달할 수 있는 깔끔한 전송 수단 (transport)을 제공하기 때문입니다.

MCP는 문서를 노출할 수 있습니다.
리졸버 (resolvers)를 노출할 수 있습니다.
워크플로우 (workflows)를 노출할 수 있습니다.
기술 (skills)을 노출할 수 있습니다.
운영 계약 (operating contracts)을 노출할 수 있습니다.

이는 MCP가 단순히 도구 호출 (tool-calling) 인터페이스가 아님을 의미합니다.

MCP는 AI 지원 업무를 위한 플러그형 컨텍스트 계층 (pluggable context layer)이 될 수 있습니다.

기존 패턴: 무한히 커지는 로컬 지침 파일

많은 AI 코딩 설정은 로컬 지침 파일 (local instruction files)에 의존합니다.

예시는 다음과 같습니다:

• AGENTS.md
• CLAUDE.md
• 커스텀 지침 (custom instructions)
• 프로젝트 프롬프트 (project prompts)
• 로컬 규칙 파일 (local rule files)
• 압축된 컨텍스트 요약 (compressed context summaries)

처음에는 이것이 잘 작동합니다.

몇 가지 규칙을 작성합니다.

그다음 코딩 컨벤션 (coding conventions)을 추가합니다.
그다음 아키텍처 제약 사항 (architectural constraints)을 추가합니다.
그다음 도메인 지식 (domain knowledge)을 추가합니다.
그다음 워크플로우 노트 (workflow notes)를 추가합니다.
그다음 테스트 규칙 (testing rules)을 추가합니다.
그다음 위험 경고 (risk warnings)를 추가합니다.
그다음 AI가 절대 해서는 안 되는 일들을 추가합니다.
그다음 AI가 항상 확인해야 할 일들을 추가합니다.

결국 지침 파일은 너무 커지게 됩니다.

그러면 새로운 의식이 시작됩니다:

AI가 사용할 수 있도록 컨텍스트를 압축하라.

이것은 AI를 사용하는 데 드는 일상적인 비용의 일부가 됩니다.

사람들은 프롬프트를 유지 관리합니다.
사람들은 문서를 압축합니다.
사람들은 오래된 규칙을 제거합니다.
사람들은 컨텍스트를 다시 작성합니다.
사람들은 각 클라이언트(client)에 맞춰 지침을 조정합니다.

그 결과는 취약합니다.

AI의 출력물은 각 사용자가 로컬 컨텍스트를 얼마나 잘 유지하느냐에 따라 달라집니다.

이것은 확장 가능한 팀 시스템이 아닙니다.

AGENTS.md가 지식 베이스 (knowledge base)가 되어서는 안 됩니다

저는 AGENTS.md가 더 작은 역할을 수행해야 한다고 생각합니다.

AGENTS.md에 모든 도메인 지식을 담아서는 안 됩니다.
모든 워크플로우를 담아서도 안 됩니다.
모든 기술을 담아서도 안 됩니다.
조직의 압축된 버전이 되어서도 안 됩니다.

대신에:

AGENTS.md는 부트로더 (bootloader)여야 합니다.

그 역할은 단순해야 합니다:

• AI 클라이언트에게 프로젝트 컨텍스트 (context)가 어디에 있는지 알려주기
• AI 클라이언트에게 어떤 MCP 서버를 사용할지 알려주기
• AI 클라이언트에게 시작 시 무엇을 로드할지 알려주기
• AI 클라이언트에게 어떤 소스가 권위 있는 (authoritative) 소스인지 알려주기

그게 전부입니다.

상세한 지식은 다른 곳에 존재해야 합니다.

시작 파일 (startup file)은 컨텍스트 시스템 (context system)을 가리켜야 합니다.
그 자체가 컨텍스트 시스템이 되어서는 안 됩니다.

MCP는 컨텍스트를 플러그인 방식으로 교체 가능하게 만듭니다 (pluggable)

MCP를 통해 컨텍스트가 제공되면, 아키텍처가 변화합니다.

MCP 도입 전:

사용자가 로컬에서 컨텍스트를 보유합니다.

MCP 도입 후:

MCP 서버가 컨텍스트를 제공합니다.

이는 큰 차이점입니다.

사용자는 더 이상 거버넌스 (governance) 리포지토리를 로컬에 전체 체크아웃 (checkout)할 필요가 없습니다.
사용자는 더 이상 거대한 프롬프트 (prompt)를 유지 관리할 필요가 없습니다.
사용자는 더 이상 최신 도메인 규칙 (domain rules)을 수동으로 복사할 필요가 없습니다.

클라이언트에게 필요한 것은 오직 다음과 같습니다:

• MCP 서버에 대한 접근 권한
• AI에게 MCP로부터 컨텍스트를 로드하도록 지시하는 시작 규칙 (startup rule)

컨텍스트 자체가 플러그인 방식 (pluggable)으로 교체 가능해집니다.

프로젝트 A는 하나의 MCP 컨텍스트 서버를 사용할 수 있습니다.
프로젝트 B는 다른 서버를 사용할 수 있습니다.
도메인 팀은 자체적인 스킬 카탈로그 (skill catalog)를 제공할 수 있습니다.
거버넌스 팀은 공유된 운영 계약 (operating contracts)을 유지 관리할 수 있습니다.

AI 클라이언트는 더 가벼워집니다.

도메인 컨텍스트는 중앙 집중식으로 관리됩니다.

컨텍스트는 덤프 (dump)가 아니라 패키지 (package) 형태로 전달되어야 합니다

사람들이 AI에게 컨텍스트를 제공하는 것을 생각할 때, 종종 모든 것을 한꺼번에 보내는 것을 상상합니다.

모든 문서.
모든 규칙.
모든 제약 조건 (constraints).
모든 도메인 지식.
모든 예시.
모든 워크플로 (workflows).

이는 새로운 문제를 야기합니다.

컨텍스트가 너무 커집니다.
중요한 규칙들이 희석됩니다.
모델이 현재 작업에 필요하지 않은 정보를 받게 됩니다.
안정적인 규칙과 변동성이 큰 상태 (volatile state)가 뒤섞입니다.
AI가 잘못된 문서, 잘못된 워크플로, 또는 잘못된 수준의 상세도를 따를 수 있습니다.

더 많은 컨텍스트가 항상 더 나은 출력을 의미하지는 않습니다.

때때로, 너무 많은 컨텍스트는 AI의 신뢰성을 떨어뜨립니다.

이것이 바로 컨텍스트를 단일 덤프 (single dump) 형태로 전달해서는 안 되는 이유입니다.

그것은 구조화된 패키지 (structured packages) 형태로 전달되어야 합니다.

예를 들어:

• 스타트업 컨텍스트 (startup context)
• 기술 카탈로그 (skill catalog)
• 워크플로우 정의 (workflow definition)
• 도메인 규칙 세트 (domain rule set)
• 권위 있는 문서 참조 (authoritative document reference)
• 리졸버 정책 (resolver policy)
• 클로저 계약 (closure contract)
• 필요 시 요청되는 런타임 상태 (runtime state fetched on demand)

각 패키지는 명확한 목적을 가져야 합니다.

스타트업 컨텍스트 (Startup context)는 불변량 (invariants)만을 포함해야 합니다.
기술 (Skill)은 한 종류의 작업에 대한 지식과 절차를 포함해야 합니다.
워크플로우 (workflow)는 예상되는 작업 순서를 정의해야 합니다.
리졸버 (resolver)는 필요할 때 권위 있는 문서들을 가져와야 합니다.
런타임 도구 (Runtime tools)는 휘발성 상태 (volatile state)를 필요할 때만 가져와야 합니다.

이렇게 하면 모델이 집중력을 유지할 수 있습니다.

AI는 조직 전체를 컨텍스트 윈도우 (context window)에 담아둘 필요가 없습니다.
AI에게 필요한 것은 작업의 적절한 단계에서 적절한 컨텍스트입니다.

이 지점에서 MCP가 유용해집니다.

MCP는 우리에게 컨텍스트를 위한 명명된 엔트리 포인트 (named entry points)를 제공합니다.

모델에 하나의 거대한 프롬프트를 밀어넣는 대신, 클라이언트는 다음과 같은 것들을 요청할 수 있습니다:

• 스타트업 계약 (startup contract)
• 관련 기술 (relevant Skill)
• 필요한 문서 (required document)
• 클로저 규칙 (closure rule)
• 현재 런타임 상태 (current runtime state)

이를 통해 컨텍스트는 단계별로 구성되고, 명시적이며, 추론하기 쉬워집니다.

목표는 컨텍스트 크기를 최대화하는 것이 아닙니다.

목표는 컨텍스트의 형태 (context shape)를 제어하는 것입니다.

문서는 기술 (Skills)을 함축합니다

MCP가 문서를 전달할 수 있다면, 문서 이상의 것을 전달할 수 있습니다.

문서는 컨텍스트입니다.

기술 (Skill) 또한 컨텍스트이지만, 더 강력한 구조를 가집니다.

좋은 기술은 단순히 다음과 같이 말하지 않습니다:

여기 정보가 있습니다.

좋은 기술은 다음과 같이 말합니다:

이 작업은 이렇게 수행되어야 합니다.

도메인 기술 (domain Skill)은 다음을 포함할 수 있습니다:

• 도메인 지식 (domain knowledge)
• 용어 (terminology)
• 권위 있는 참조 (authoritative references)
• 워크플로우 단계 (workflow steps)
• 결정 기준 (decision criteria)
• 리스크 조건 (risk conditions)
• 미지의 상황 처리 (unknown handling)
• 에스컬레이션 규칙 (escalation rules)
• 클로저 조건 (closure conditions)
• 필요한 증거 (required evidence)

이는 단순히 문서 청크 (document chunks)를 검색하는 것보다 훨씬 더 가치 있는 일입니다.

문서가 지식을 분산시킨다면, 기술 (Skills)은 작업의 품질을 분산시킵니다.

이것이 핵심입니다.

범용 명령 기술 (Generic command Skills)만으로는 부족합니다

오늘날 많은 AI 기술 (Skills)은 명령 중심적입니다.

그것들은 유용하지만, 종종 너무 저수준 (low-level)입니다.

예를 들어:

• 이 명령을 실행하세요
• 이 파일을 검사하세요
• 이 diff를 생성하세요
• 이 테스트를 실행하세요
• 이 출력을 요약하세요
• 이 API를 호출하세요

이것은 자동화처럼 보입니다.

하지만 실제로는 종종 마이크로매니지먼트 (micromanagement)가 됩니다.

인간은 여전히 다음을 결정해야 합니다:

• 어떤 명령을 실행할지
• 언제 실행할지
• 어떤 결과가 중요한지
• 결과가 충분한지
• AI가 계속 진행해야 하는지
• 작업이 완료되었는지

AI는 작은 연산들을 실행합니다.

인간은 워크플로 (workflow)를 관리합니다.

이것은 큰 생산성 향상을 만들어내지 못합니다.

단지 인터페이스를 바꿀 뿐입니다.

사용자는 여전히 모든 단계를 조종하고 있습니다.

문제는 명령 실행이 아닙니다

전문적인 업무에서 어려운 부분은 항상 실행인 것은 아닙니다.

어려운 부분은 판단 (judgment)입니다.

소프트웨어 작업의 경우, 중요한 질문들은 종종 다음과 같습니다:

• 이 변경 사항이 기존 설계와 호환되는가?
• 이 요구사항이 완전히 이해되었는가?
• 어떤 문서가 권위 있는가?
• 아직 알려지지 않은 것은 무엇인가?
• 영향 분석 (impact analysis)이 완료되었는가?
• 이 리스크를 에스컬레이션 (escalate)해야 하는가?
• 종료 전에 어떤 증거가 필요한가?
• 진행해도 안전한가?

범용 명령 번들 (Generic command bundles)은 이러한 질문에 답하지 못합니다.

그것들은 판단이 아닌 연산을 자동화합니다.

그렇기 때문에 명령 수준의 기술 (Skills)은 팀 수준의 출력 품질을 개선하지 못한 채 편의성만 개선할 수 있는 것입니다.

그것들은 키 입력을 줄여줍니다.

하지만 반드시 변동성 (variance)을 줄여주는 것은 아닙니다.

도메인 기술 (Domain Skills)은 비즈니스 수준의 단위여야 합니다

더 나은 기술 (Skill)의 경계는 명령이 아닙니다.

더 나은 기술 (Skill)의 경계는 비즈니스 수준의 작업 단위입니다.

예시:

• 변경 영향 분석
• 알려진 제약 조건에 따른 설계 검증
• 미지의 요소 분류
• 릴리스 준비 상태 검토
• 요구사항 일관성 체크
• 종료 허용 여부 평가
• 도메인 특화된 실패 모드 조사

이것들은 단일 명령이 아닙니다.

이것들은 작업 단위입니다.

하지만 여기서 중요한 점이 있습니다:

도메인 지식 (Domain knowledge)만으로는 충분하지 않습니다.

하나의 저장소 (Repository)에는 수많은 문서가 포함될 수 있습니다.
하나의 팀에는 수많은 규칙이 있을 수 있습니다.
하나의 프로젝트에는 수많은 제약 사항 (Constraints)이 있을 수 있습니다.
하나의 조직에는 방대한 양의 축적된 지식이 있을 수 있습니다.

하지만 그 모든 지식을 모델에게 준다고 해서 작업 품질이 자동으로 향상되지는 않습니다.

모델에게 모든 도메인 지식 (Domain knowledge)이 필요한 것은 아닙니다.

모델에게 필요한 것은 현재 작업에 필요한 지식입니다.

그리고 그 지식은 적절한 순간에 제공되어야 합니다.

이것이 바로 도메인 기술 (Domain Skill)이 단순히 지침 (Instructions)만을 포함해서는 안 되는 이유입니다.

도메인 기술 (Domain Skill)은 다음을 정의해야 합니다:

• 어떤 종류의 작업을 처리하는지
• 어떤 도메인 지식 (Domain knowledge)이 필요한지
• 어떤 참조 (References)가 권위 있는 정보인지
• 어떤 문서를 가장 먼저 로드해야 하는지
• 어떤 문서를 필요할 때만 해결 (Resolved)해야 하는지
• 어떤 가설 (Assumptions)이 금지되는지
• 어떤 미지의 요소 (Unknowns)가 작업을 중단시켜야 하는지
• 종료 (Closure) 전에 어떤 증거 (Evidence)가 필요한지

다시 말해, 기술 (Skill)은 단순한 절차 (Procedure)가 아닙니다.

기술 (Skill)은 도메인 지식 (Domain knowledge)에 대한 접근이 제어되는 작업 단위 (Work unit)입니다.

이 지점에서 MCP가 컨텍스트 분배 계층 (Context distribution layer)으로서 유용해집니다.

기술 (Skill)이 모든 문서를 직접 임베딩 (Embed)할 필요는 없습니다.
시작 컨텍스트 (Startup context)가 도메인 전체를 미리 로드 (Preload)할 필요도 없습니다.
클라이언트 (Client)가 거대한 로컬 프롬프트 (Local prompt)를 유지할 필요도 없습니다.

대신, MCP는 기술 (Skill)과 지식 접근 경로 (Knowledge access path)를 제공할 수 있습니다.

AI는 다음을 로드할 수 있습니다:

• 관련 기술 (Skill)
• 필요한 도메인 규칙 세트 (Domain rule set)
• 권위 있는 문서 (Authoritative document)
• 연결된 참조를 위한 리졸버 (Resolver for linked references)
• 종료 계약 (Closure contract)
• 런타임 상태 (Runtime state), 오직 필요할 때만

이것이 도메인 지식 (Domain knowledge)을 사용 가능하게 만듭니다.

가치는 지식을 저장하는 데 있는 것이 아닙니다.
가치는 적절한 작업 단위 (Work unit)에 적절한 지식을 전달하는 데 있습니다.

시니어 엔지니어가 기술 (Skill)을 정의할 수 있습니다.
기술 (Skill)은 필요한 도메인 지식 (Domain knowledge)을 가리킬 수 있습니다.
팀은 MCP를 통해 기술 (Skill)을 사용할 수 있습니다.
AI는 매번 동일한 규칙을 따를 수 있습니다.

작업 단위 (Work unit), 지식 접근 경로 (Knowledge access path), 그리고 종료 기준 (Closure criteria)이 함께 분배되기 때문에 출력 결과가 더욱 일관되게 됩니다.

그렇기 때문에 도메인 기술 (domain Skills)은 비즈니스 수준의 단위여야 합니다.

그것들은 명령 번들 (command bundles)이 아닙니다.

그것들은 패키징된 작업 컨텍스트 (work contexts)입니다.

시맨틱 라우팅 (semantic routing)이 중요한 이유

기술 (Skills)이 비즈니스 수준의 단위라면, 사용자가 모든 명령을 수동으로 선택할 필요가 없어야 합니다.

사용자는 작업 의도 (work intent)를 설명해야 합니다.

시스템은 그 의도를 적절한 기술 (Skill)로 라우팅 (route)해야 합니다.

이것이 시맨틱 라우팅 (semantic routing)이 중요한 이유입니다.

명령 라우팅 (Command routing)은 다음과 같이 말합니다:

어떤 도구 (tool)를 호출해야 하는가?

시맨틱 라우팅 (Semantic routing)은 다음과 같이 말합니다:

이것은 어떤 종류의 작업인가?

그 차이가 중요합니다.

사용자가 모든 명령을 수동으로 선택해야 한다면, 워크플로 (workflow)는 마이크로매니지먼트 (micromanagement) 수준에 머물게 됩니다.

시스템이 작업 의도를 도메인 기술 (domain Skill)로 라우팅할 수 있다면, 사용자는 더 높은 수준에서 위임 (delegate)할 수 있습니다.

그러면 기술 (Skill)이 도메인 규칙 (domain rules), 참조 (references), 미확인 상황 처리 (unknown handling), 그리고 종료 기준 (closure criteria)을 전달하게 됩니다.

이것이 실제 위임 (delegation)에 더 가깝습니다.

MCP + 시맨틱 라우팅 (semantic routing)이 모델을 변화시키는 방식

MCP와 시맨틱 라우팅 (semantic routing)이 결합되면, 모델은 달라집니다.

사용자는 거대한 로컬 프롬프트 (local prompt)를 유지 관리하지 않습니다.

사용자는 모든 저수준 명령 (low-level command)을 수동으로 선택하지 않습니다.

사용자는 모든 거버넌스 문서 (governance document)의 로컬 사본을 가질 필요가 없습니다.

대신 다음과 같이 작동합니다:

1. AGENTS.md가 AI 클라이언트 (AI client)를 부트스트랩 (bootstraps)합니다.
2. AI가 MCP로부터 시작 컨텍스트 (startup context)를 로드합니다.
3. 시작 컨텍스트 (startup context)가 운영 계약 (operating contract)을 정의합니다.
4. 사용자가 작업 의도 (work intent)를 설명합니다.
5. 시맨틱 라우팅 (Semantic routing)이 관련 도메인 기술 (domain Skill)을 선택합니다.
6. 기술 (Skill)이 필요한 컨텍스트 (context)를 단계별로 로드합니다.
7. 런타임 도구 (Runtime tools)는 필요할 때만 휘발성 상태 (volatile state)를 가져옵니다.
8. 종료 규칙 (Closure rules)이 작업 완료 가능 여부를 결정합니다.

이것은 단순한 도구 호출 (tool calling)이 아닙니다.

이것은 단계별 컨텍스트 전달 (staged context delivery)입니다.

누락된 계층 (The missing layer)

이것이 지금까지 누락되었던 계층입니다.

개별적인 AI 사용은 개인의 프롬프트 기술 (prompt skill)에 의존합니다.

일반적인 기술 (Generic Skills)은 명령을 자동화합니다.

RAG는 관련성이 높은 지식을 검색 (retrieve)합니다.

RPC는 AI가 도구를 호출할 수 있게 합니다.

하지만 팀에는 다른 무언가가 필요합니다.

팀에는 다음과 같은 것들을 분배할 방법이 필요합니다:

• 도메인 판단 (domain judgment)
• 운영 규칙 (operating rules)
• 워크플로우 경계 (workflow boundaries)
• 증거 요구 사항 (evidence requirements)
• 중단 조건 (stop conditions)
• 종료 기준 (closure criteria)

그것이 바로 도메인 기술 (domain Skills)이 제공할 수 있는 것입니다.

그리고 MCP는 이러한 기술 (Skills)을 플러그인 방식으로 교체 가능하게 (pluggable) 만듭니다.

핵심 아이디어

핵심 아이디어는 간단합니다:

AGENTS.md는 지식 베이스 (knowledge base)가 아니라 부트로더 (bootloader)여야 합니다.

그리고:

MCP는 도메인 컨텍스트 (domain context)와 도메인 기술 (domain Skills)을 플러그인 방식으로 교체 가능하게 (pluggable) 만들어야 합니다.

이는 모든 사용자가 점점 커지는 로컬 프롬프트 (local prompt)를 유지해야 했던 기존 패턴을 방지합니다.

또한 기술 (Skills)을 단순히 명령 번들 (command bundles)로 취급하는 함정도 피할 수 있습니다.

팀 단위의 AI 작업에서 목표는 더 많은 명령을 자동화하는 것이 아닙니다.

목표는 품질의 변동성 (quality variance)을 줄이는 것입니다.