중급5분 분량

DynamoDB MCP 서버: Claude Code, Cursor & Codex를 안전하게 연결하기

Model Context Protocol (MCP)는 터미널이나 편집기에서 실행되는 AI 에이전트 — Claude Code, Cursor, Codex, VS Code Copilot — 가 추측하는 대신 외부 도구를 호출하게 해줍니다. 하나를 DynamoDB로 향하게 하면 에이전트는 사용자의 스키마를 읽고, 실제 쿼리를 실행하며, 편집을 제안할 수 있습니다 — 테이블 덤프를 채팅에 붙여넣지 않고도 말이죠.

문제는 무엇을 넘기느냐입니다. 에이전트를 DynamoDB에 연결하는 대부분의 방식은 에이전트의 MCP 서버 프로세스에 원시 AWS 자격 증명과 테이블에 대한 직접 쓰기 권한을 줍니다. 그것은 바로 보안 연구자들이 경고하는 패턴입니다: 오염된 도구 결과나 프롬프트 인젝션이 담긴 문서에 의해 조종될 수 있는 에이전트가, 프로덕션에서 DeleteItem을 할 수 있는 키를 쥐고 있는 것이죠. 이 가이드는 둘 다 — 안전한 경로와 원시 경로 — 를 다루므로, 사용자가 신중하게 선택할 수 있습니다.

DynamoDB MCP 서버가 있나요?

네 — 여러 개 있습니다. AWS는 데이터 모델링에 초점을 맞춘 공식 서버를 게시하며, 커뮤니티 npm·PyPI 서버들은 실시간 읽기 또는 읽기/쓰기 액세스를 제공합니다. DynoTable도 로컬 MCP 서버로 동작합니다. 진짜 선택은 서버가 존재하느냐가 아니라, 에이전트에게 얼마나 많은 권한을 줄 것이냐입니다. 읽기 전용 서버는 비교적 안전하지만, AWS 키를 보유한 쓰기 가능 서버는 위험합니다.

  • 에이전트가 DynamoDB를 읽고 추론하게 하고 싶나요? 여러 MCP 서버가 이를 수행합니다. 읽기 전용 서버는 비교적 안전합니다.
  • 에이전트가 데이터를 변경하게 하고 싶나요? 키와 직접 쓰기 경로를 주지 마세요. 쓰기를 검토 단계로 라우팅하여 사람이 커밋하도록 하세요. 그것이 아래에서 DynoTable이 사용하는 모델입니다.

안전한 방법: MCP 서버로서의 DynoTable

DynoTable로컬 MCP 서버 역할을 할 수 있는 데스크톱 DynamoDB 클라이언트입니다. 외부 에이전트가 여기에 연결하면 DynoTable의 내장 어시스턴트가 사용하는 것과 동일한 게이팅된 도구 모음을 얻습니다 — 다만 독립형 서버들이 제공하지 않는 두 가지 보장과 함께입니다:

  • 사용자의 AWS 자격 증명은 결코 에이전트에 도달하지 않습니다. DynoTable이 사용자의 AWS 프로필을 보유하고, 에이전트는 AWS가 아니라 DynoTable과 통신합니다. 에이전트의 프로세스 안의 어떤 것도 사용자의 키를 읽을 수 없습니다.
  • 에이전트는 DynamoDB에 직접 쓸 수 없습니다. 에이전트가 제안하는 모든 변경은 사용자가 검토하고 커밋할 수 있도록 DynoTable의 스테이징된 커밋 창에 들어갑니다. 에이전트는 제안하고, 사용자가 커밋합니다.

게다가: 기본적으로 꺼져 있고, 모든 연결은 사용자가 선택한 스코프로 클라이언트별로 승인되며, 엔드포인트는 루프백 전용(127.0.0.1, 사용자의 컴퓨터 밖에서는 절대 접근 불가)이고, 어떤 클라이언트든 해지 가능합니다.

켜고 클라이언트 연결하기

Settings → MCP Server에서 서버를 켭니다. DynoTable은 루프백 포트를 바인딩하고 정확한 연결 명령을 보여줍니다. 엔드포인트는 http://127.0.0.1:<port>/mcp입니다(실제 포트는 창에서 복사하세요).

프로젝트에서 MCP 창에 표시된 명령을 실행하세요:

claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp

클라이언트가 처음 연결할 때, DynoTable은 앱 안에서 연결하는 클라이언트의 이름을 알려주고 어떤 스코프를 부여할지 — 아니면 거부할지 — 묻는 동의 프롬프트를 보여줍니다:

  • Read only — 스키마, 쿼리, 항목 읽기. 변경 없음.
  • Read & stage — 위의 모든 것에 더해, 사용자가 검토할 변경을 스테이징합니다(직접 쓰기는 절대 아님).
  • Full access — 위의 모든 것에 더해, 뷰 열기, 필터, 내보내기. 쓰기는 여기서도 여전히 스테이징을 거칩니다.

전체 설정, 스코프, 보안 모델은 MCP 서버 문서에 있습니다.

다른 선택지들 (그리고 그 절충점)

이것들도 작동하지만, 프로덕션 테이블로 향하게 하기 전에 절충점을 읽어보세요.

AWS의 공식 DynamoDB MCP 서버 — 모델링용, 실시간 작업용 아님

AWS는 awslabs/mcp에 공식 dynamodb-mcp-server를 게시합니다. 2026-06-12 기준으로 이것은 프로덕션 테이블에 대한 실시간 읽기/쓰기보다는 데이터 모델링과 설계 지침 — 스키마 설계, DynamoDB Local에 대한 검증, 비용 추정 — 에 초점이 맞춰져 있습니다. 실시간 데이터 플레인 액세스를 위해 AWS는 사용자에게 일반 AWS API MCP Server를 안내하는데, 이것은 사용자가 구성한 AWS 자격 증명으로 AWS API/CLI 호출을 실행합니다. 즉 에이전트의 서버 프로세스가 광범위한 영향 범위를 가진 강력한 키를 보유하며, DynamoDB 전용 검토 단계가 없습니다. (이것에 의존하기 전에 awslabs 리포지토리에서 현재 도구 모음을 확인하세요 — 이 서버들은 변합니다.)

커뮤니티 npm/PyPI 서버 — 잘해야 읽기 전용, 최악의 경우 원시 키

npm과 PyPI에는 여러 커뮤니티 DynamoDB MCP 서버가 있습니다. 일부는 전체 테이블/항목 작업을 노출하고, 다른 것들은 의도적으로 읽기 전용입니다. 공통점은:

  • 사용자의 AWS 액세스 키와 시크릿이 서버의 환경(.env 또는 클라이언트 구성)에 존재하며, 그 키의 전체 IAM 권한을 가집니다.
  • 연결별 동의도, 스코프도, 쓰기 스테이징도 없습니다 — 읽기 전용 서버는 설계가 아니라 쓰기 도구를 생략함으로써만 사용자를 보호합니다.

읽기 전용 커뮤니티 서버는 에이전트가 테이블을 탐색하게 하는 합리적이고 위험이 낮은 방법입니다. 쓰기가 가능한 서버에 프로덕션 키를 주는 것이 위험한 패턴입니다.

AI 에이전트에게 DynamoDB 액세스를 주는 것이 안전한가요?

그것은 전적으로 경로에 달려 있습니다. 민감하지 않은 테이블에 대한 읽기 액세스는 위험이 낮습니다. 문제는 쓰기 액세스입니다 — 그리고 안전한 답은 자율 에이전트에게 자격 증명과 직접 쓰기 경로를 결코 둘 다 주지 않는 것입니다. 읽기 전용으로 유지하거나, 모든 변경을 사람이 승인하는 검토 단계로 라우팅하세요. DynoTable은 후자를 합니다: 에이전트는 결코 사용자의 키를 보유하지 않고 DynamoDB에 쓰지도 않습니다. 사용자가 스테이징 창에서 커밋합니다.

MCP 에이전트가 내 DynamoDB 테이블에 쓸 수 있나요?

원시 쓰기 가능 서버로는: 예, 직접 — 그것이 위험입니다. DynoTable로는: 아니요, 직접은 아닙니다. Read & stage 또는 Full access에서 에이전트는 변경을 스테이징할 수 있지만, 그것은 앱 안에 검토 가능한 diff로 나타나며 사용자가 커밋할 때에만 기록됩니다.

DynamoDB와 함께 Claude Code를 어떻게 사용하나요?

DynoTable의 MCP 서버를 실행하고(Settings → MCP Server), 프로젝트에서 claude mcp add --transport http dynotable http://127.0.0.1:<port>/mcp를 실행한 뒤, 원하는 스코프로 연결을 승인하고 Claude Code를 다시 로드하세요. 그러면 에이전트는 AWS 자격 증명을 결코 보유하지 않은 채로 사용자의 스키마를 읽고, 쿼리를 실행하며, 편집을 스테이징할 수 있습니다. 동일한 패턴이 Cursor, VS Code Copilot, Codex, OpenCode에서도 작동합니다(위의 구성 참조).

관련 문서

제품명은 각 소유자의 상표이며, 식별 목적으로만 참조됩니다. 경쟁사 및 AWS 서버 세부 정보는 2026-06-12에 검증되었습니다 — 의존하기 전에 업스트림 리포지토리를 다시 확인하세요.

업데이트됨