MCP 데이터 계층
MCP를 사용해 사내 시스템과 AI를 연결할 때 tools, resources, prompts의 경계를 어떻게 나눌지 정리합니다.
핵심 요약
- MCP는 읽기 전용 문맥을 resources, 반복 절차를 prompts, side effect가 있는 기능을 tools로 분리해 권한 경계를 명확히 합니다.
- resources는 애플리케이션 주도·최소 권한, tools는 모델 선택 가능·OAuth/audit log/approval 필수로 보안 모델이 다릅니다.
- 모든 내부 API를 tool로 노출하지 말고 읽기 중심 지식은 resources로 넣어 공격면을 줄입니다.
- transport는 사내 서비스·다중 언어 환경에 HTTP를 기본으로 두어 인증·운영을 표준화합니다.
- 고객 테넌트 경계는 tenant-bound scope를 token이나 server에 반영해 데이터 혼입을 막습니다.
엔터프라이즈 AI에서 중요한 건 "모델이 더 많은 데이터를 아는가"가 아니라 어떤 데이터와 권한을 어떤 인터페이스로 넘기는가입니다.
MCP는 이 연결을 표준화하기 좋은 도구지만, tools/resources/prompts를 나눠 쓰지 않으면 오히려 경계가 흐려집니다.
역할 분리
| 구성 | 주도권 | 적합한 데이터 | 기본 보안 모델 |
|---|---|---|---|
| resources | 애플리케이션 | 읽기 전용 문맥, 문서, 설정 | 최소 권한, deterministic |
| prompts | 사용자/애플리케이션 | 반복 가능한 작업 템플릿 | 리뷰 가능한 텍스트 자산 |
| tools | 모델 선택 가능 | 실제 액션, 조회, 쓰기 | OAuth, audit log, approval |
권장 연결 구조
next-devtools-mcp — 개발 환경 MCP 통합
Next.js 16.2.0에서 next-devtools-mcp가 도입되면서 DevTools 자체를 MCP 서버로 노출합니다. MCP 데이터 계층 관점에서 새로운 패턴이 하나 생긴 셈입니다.
| MCP 인터페이스 | 노출 대상 | 활용 시나리오 |
|---|---|---|
| resources | 라우트 구조, 컴포넌트 트리, 빌드 상태 | 에이전트가 앱 구조를 읽기 전용으로 파악 |
| tools | 빌드 실행, 오류 조회 | 코딩 에이전트가 빌드/타입체크 결과를 직접 조회하고 수정 루프 실행 |
경계 주의
next-devtools-mcp는 개발 환경 전용입니다. 프로덕션에서는 비활성화해야 하며, 개발 서버가 외부 네트워크에 노출되지 않도록 주의하세요(CVE-2026-27977 참고).
HTTP transport 우선 원칙
| transport | 적합한 상황 | 이유 |
|---|---|---|
| HTTP | 사내 서비스, 다중 언어 환경 | 운영과 인증 표준화가 쉬움 |
| stdio | 로컬 개발, 단일 프로세스 | 빠른 검증 |
| custom bridge | 특수 런타임 | 디버깅 비용 상승 |
OAuth와 권한 경계
| 시나리오 | 권장 방식 | 이유 |
|---|---|---|
| 개인 사용자 데이터 조회 | user-bound OAuth token | 사용자 책임 추적 |
| 백오피스 시스템 액션 | service token + approval | 오남용 방지 |
| 문서/위키 검색 | app-managed read token | 단순 운영 |
| 고객 테넌트 분리 | tenant-bound scope | 데이터 혼입 방지 |
예시: resources와 tools를 분리한 연결
const agent = new ToolLoopAgent({
model: 'anthropic/claude-sonnet-4.6',
tools: {
updateCrmRecord,
},
mcp: {
servers: {
docs: docsServer,
crm: crmServer,
},
},
})- docs server: resources 중심, 사내 정책/문서/가격표 제공
- crm server: mutating tool 중심, 승인 필요 액션만 노출데이터 계층 설계 체크리스트
| 질문 | Yes면 취할 액션 |
|---|---|
| 이 정보가 읽기 전용인가 | resources로 공급 |
| 사용자나 운영자가 반복 쓰는 절차인가 | prompts로 관리 |
| 실제 side effect가 있는가 | tools + approval + audit log |
| 고객 테넌트 경계가 필요한가 | tenant scope를 토큰/서버에 반영 |
추론
모든 내부 API를 tools로 노출할 필요는 없습니다. 읽기 중심 지식은 resources로 넣고 쓰기는 최소한의 tool surface로 줄이면 더 안전하고 평가하기도 쉽습니다.
ADR 스타일 결론
Decision
읽기 전용 문맥은 resources, 반복 절차는 prompts, side effect가 있는 기능은 tools로 분리합니다. 모든 내부 시스템을 tool로 노출하지 않고 권한 경계에 따라 surface를 최소화합니다.
실무 체크리스트
- 읽기 전용 데이터가 tools로 과도하게 노출되지 않았는가
- mutating tool에 OAuth, audit log, approval 기준이 있는가
- tenant scope가 token 또는 server 경계에 반영되는가
- HTTP transport를 기본으로 운영 표준화했는가