에이전트 이야기에서 매력적이지 않은 부분은, 그것이 실제로 출시될지 아니면 정체될지를 결정하는 부분입니다. 프론티어 모델 (Frontier models)은 계획을 세우고, 리팩터링 (refactor)하고, 테스트를 작성하며, 여러분의 코드베이스를 읽을 수 있습니다. 하지만 모델 스스로 할 수 없는 것은 실제 서비스에 도달하는 것입니다. 모델은 여러분의 Postgres 스키마 (schema)를 알지 못하며, 배포 로그 (deploy logs)를 추적할 수도 없고, 인증 제공업체 (auth provider)에 접근할 수도 없습니다. 에디터 외부의 세상과 연결되지 않는다면, 에이전트는 밀폐된 방 안에 있는 뛰어난 작가와 같습니다.

Model Context Protocol (MCP)은 그 문을 여는 부분입니다. 이는 에이전트와 도구 (tool) 사이의 표준화된 핸드셰이크 (handshake)입니다. 즉, 하나의 사양 (spec), 하나의 발견 메커니즘 (discovery mechanism), 하나의 호출 형태 (call shape)를 의미합니다. 생태계는 이를 중심으로 빠르게 채워지고 있습니다: Stripe, Postgres, Sentry, Cloudflare, Linear, Notion 등 모두가 포함됩니다. 한 번 작성된 서버는 Cursor, Claude Code, Continue, Windsurf, 그리고 내년에 출시될 그 어떤 도구에서도 작동합니다. 이 부분은 무시될 것이 아니라 축하받아야 마땅합니다. 어려운 점은 사양이 아닙니다. 어려운 점은 에이전트가 첫날부터 실제로 중요한 5가지 도구에 도달할 수 있도록 여러분의 리포지토리 (repo)에 이를 연결하는 것입니다.

오늘날 에이전트에 MCP를 연결하는 방법

메커니즘은 간단합니다. MCP 서버를 실행하며 — 보통 로컬 프로세스입니다 — 에이전트에게 그것이 어디에 있는지 알려줍니다. 서버는 JSON-Schema 입력을 가진 도구들을 노출합니다. 에이전트는 시작 시점에 도구들을 발견하고, 적절한 것을 선택하여 호출합니다.

Claude Code의 경우, 설정은 리포지토리 루트의 .mcp.json에 위치합니다:

{
  "mcpServers": {
    "stripe": {
...

Cursor의 경우, 동일한 형태가 설정의 "MCP Servers" 아래에 위치합니다. Windsurf의 경우 ~/.codeium/windsurf/mcp_config.json에 위치합니다. 하나의 파일, 하나의 형태입니다. 모델은 단지 도구가 존재한다는 사실을 전달받기만 하면 되며, 프로토콜이 발견을 처리합니다.

이것이 기초입니다. 이 기초보다 더 흥미로운 단계가 바로 에이전트가 데모를 넘어 팀원이 되기 시작하는 지점입니다.

[[DIAGRAM: agent loop — client discovers tools, calls them, reads results, continues; tools are local MCP servers reaching real services behind an env-gated boundary]]

"사전 연결 (pre-wired)"이 실제로 의미하는 것

“MCP 지원”을 포함하여 출시되는 키트는 네 가지 작업을 수행하며, 그중 네 번째만이 흥미로운 부분입니다:

1. 새로운 클론 (clone)이 즉시 작동할 수 있도록 적절한 서버 버전을 고정 (Pinning) 합니다.
2. 복잡한 설정의 미로 대신 단일 .env.local 파일로부터 환경 변수 (env vars)를 연결 (Wiring) 합니다.
3. 에이전트에게 어떤 도구 (tool)를 언제 사용할지 가르치는 프롬프트 (prompts)를 작성합니다.
4. 실제 앱에서 에이전트가 실제로 필요로 할 소수의 도구 세트를 선택하고, 나머지는 제외합니다.

앞의 세 가지는 기본 요건 (table stakes)입니다. 네 번째가 바로 실행 가능하게 만드는 핵심 (the enable)입니다. 200개의 서버가 있는 빈 MCP 카탈로그는 엄선된 5개의 세트보다 더 나쁜 시작점입니다. 에이전트의 컨텍스트 윈도우 (context window)는 유한합니다. 나열된 모든 도구는 모델이 결정해야 하고, 다른 도구들과 비교하여 무게를 달아야 하며, 잘못 작동할 가능성이 있는 도구들입니다. 큐레이션 (Curation)이 바로 핵심 기능 (feature)입니다.

프로덕션 키트가 제공해야 할 5가지 도구

SaaS 키트가 출시 첫날에 우선순위에 따라 노출해야 할 최소한의 세트는 다음과 같습니다:

1. 데이터베이스 (Database) — 스키마 (schema) 읽기, 쿼리 (query) 실행, 실행 계획 (plan) 설명. 이것이 없으면 에이전트는 눈을 감은 채 마이그레이션 (migrations)을 작성하게 됩니다.
2. 결제 (Payments) — 제품 목록화, 가격 생성, 웹훅 (webhook) 연결, 최근 50개 이벤트 읽기. 이것이 없으면 에이전트는 체크아웃 (checkout)을 검증할 수 없습니다.
3. 배포 (Deploy) — 환경 (environments) 목록화, 로그 (logs) 추적, 재배포 트리거, 롤백 (roll back). 이것이 없으면 "배포해(ship it)"라는 명령은 수동 작업이 됩니다.
4. 인증 (Auth) — 사용자 목록화, 사용자 생성, 디버깅을 위한 사용자 사칭 (impersonate), 세션 (session) 취소. 이것이 없으면 에이전트는 로그인 흐름을 엔드 투 엔드 (end-to-end)로 테스트할 수 없습니다.
5. 이메일 (Email) — 템플릿 메시지 전송, 최근 20개 전송 목록화, 바운스 리포트 (bounce report) 읽기. 이것이 없으면 비밀번호 재설정 및 온보딩 (onboarding) 흐름을 검증할 수 없습니다.

다섯 가지입니다. 키트의 역할은 세 개의 환경 변수와 단 한 번의 pnpm dev만으로 새로운 클론에서 이 다섯 가지가 작동하게 만드는 것입니다. 에이전트의 역할은 그것들을 잘 사용하는 것입니다.

왜 연결 (wiring)이 모델보다 강력한가

실제 사례를 들어보겠습니다. 버그 내용: "독일 사용자는 EUR 가격을 보지만 결제는 USD로 진행됩니다." 연결 (wiring)이 없다면, 에이전트는 currency를 검색(grep)하여 Stripe 호출 코드를 찾아내고, 해당 라인을 수정하고, 테스트를 작성한 뒤, 완료되었다고 말할 것입니다. 이것이 실제로 수정되었는지는 동전 던지기만큼이나 불확실합니다. 에이전트에게는 실시간 Stripe 고객 정보를 읽을 방법도, 지역 인식(locale-aware) 가격이 생성되었는지 확인할 방법도, 웹훅(webhook) 페이로드를 확인할 방법도 없기 때문입니다.

결제 MCP (payments MCP)가 연결되어 있다면, 에이전트는 대신 다음과 같이 동작합니다:

> Stripe에서 독일 테스트 고객을 조회하고 해당 지역의 가격 목록을 나열하세요.
> [tools: stripe.list_customers, stripe.list_prices]
> 독일 지역에 대한 EUR 가격이 존재하지 않는다면 생성하세요.
...

동일한 모델, 동일한 프롬프트(prompt)입니다. 하지만 결과는 완전히 다릅니다. 에이전트는 테스트 대상 시스템에 접근할 수 있기 때문에 자신의 작업 내용을 검증할 수 있습니다.

나머지 절반: 연결 구조를 이해하는 프롬프트

도구(tools)는 에이전트가 그 존재를 알고 있을 때만 유용합니다. 이것이 대부분의 "AI-ready" 템플릿들이 생략하는 부분입니다. 그들은 설정 파일 하나를 배포하고 끝내버립니다. 모델이 도구를 발견하기는 하겠지만, 어떤 도구가 어떤 작업에 적합한지, 팀의 컨벤션(convention)은 무엇인지, 혹은 실패 모드(failure mode)가 어떤 모습인지는 알지 못합니다.

이 점을 진지하게 다루는 키트(kit)는 다음과 같은 프롬프트 디렉토리를 함께 제공합니다:

ai/prompts/
  00-overview.md           # 이 코드베이스가 무엇인지, "완료(done)"의 의미는 무엇인지
  10-database.md           # 직접 쿼리할 때와 마이그레이션(migration)을 작성할 때의 구분
...

각 프롬프트는 도구의 이름, 패턴의 이름, 그리고 실패 모드의 이름을 명시합니다. 에이전트는 세션 시작 시 이들을 한 번 읽으며, 이 프롬프트들은 에이전트의 운영 매뉴얼이 됩니다. 지속 가능한 계층(durable layer)은 "AI를 피하는 것"이 아니라, "AI가 제대로 일을 할 수 있도록 올바른 컨텍스트 (context)를 제공하는 것"입니다.

OTF가 오늘날 제공하는 것

모든 풀스택 (full-stack) OTF 키트 — SaaS 대시보드, 피트니스, 예약 시스템 — 는 해당 운영 매뉴얼이 사전 설치된 상태로 제공됩니다. 새로 클론(clone)하면 CLAUDE.md, .cursorrules 파일, 그리고 에이전트에게 코드베이스의 컨벤션 (conventions), 따라야 할 패턴, 주의해야 할 실패 모드 (failure modes)를 알려주는 20개 이상의 테스트된 프롬프트 (prompts)가 담긴 ai/prompts/ 디렉토리가 포함되어 있습니다. 여기에 Stripe, Postgres, 배포 제공업체 (deploy provider), 인증 (auth) 등의 MCP를 연결하면, 이 프롬프트들이 에이전트가 적절한 순간에 적절한 도구를 사용하도록 유도하는 역할을 합니다.

이 키트는 작동하는 서버를 배포한다는 의미에서 특정 SaaS에 미리 연결되어 있는 것은 아닙니다. 그것은 여러분의 통합 (integration) 영역이며, 이는 당연한 일입니다. 키트가 제공하는 것은 에이전트가 여러분의 통합을 처음부터 올바르게 사용할 수 있도록 하는 컨텍스트 (context)이며, 배포 준비가 되었을 때 도메인, DNS, TLS, 그리고 모바일 빌드를 연결해 주는 원스크립트 배포 (one-script deploy) 기능입니다. SaaS 키트는 인증, 결제, DB, Stripe가 키트 자체에 연결된 상태로 제공되며, 피트니스와 예약 키트는 iOS, Android, 웹에서 실행되는 하나의 코드베이스 전체에 동일한 연결 패턴을 확장하여 적용합니다.

[[CONCEPT: 밀폐된 방 안의 뛰어난 작가로서의 에이전트 — 연결과 프롬프트를 결합하는 것은 문을 여는 것과 같다]]

지속 가능한 레이어는 연결 (wiring)이다

2026년에 여러분의 코드베이스를 위해 할 수 있는 가장 유용한 일은 적절한 모델을 선택하는 것이 아닙니다. 적절한 것들을 도달 가능한 상태 (reachable)로 만드는 것입니다. 모델은 스스로 계속해서 발전할 것입니다. 변하지 않는 사실은 Stripe에는 여전히 비밀 키 (secret)가 필요하고, Postgres에는 여전히 URL이 필요하며, 여러분의 배포에는 여전히 명령어가 필요하고, 여러분의 에이전트에는 여전히 여러분의 코드베이스가 어떻게 작동하는지 알려주어야 한다는 점입니다. 이러한 요소들을 설명하는 프롬프트와 함께 미리 연결된 상태로 제공되는 키트들이야말로 에이전트가 첫날부터 실제로 결과물을 만들어낼 수 있는 키트입니다. 스택의 나머지 부분은 끊임없이 변하지만, 이 부분은 변하지 않습니다.