AI로 DynamoDB를 쿼리하는 법 (자연어)

"지난주의 실패한 주문 보여 줘"는 머릿속에서는 한 줄이지만, 와이어에서는 플레이스홀더 맵이 붙은 KeyConditionExpression입니다. 그 간극을 메우는 것이 "AI로 DynamoDB 쿼리하기"의 실제 의미입니다 — DynamoDB API 자체에는 자연어 엔드포인트가 없기 때문입니다. 모든 요청은 여전히 표현식 아니면 이고, AI는 도구 계층에 앉아 여러분의 의도를 그것들로 번역합니다.

그 번역은 진짜로 훌륭할 수도, 조용히 위험할 수도 있는데, 한 가지에 달려 있습니다: 모델이 여러분의 실제 스키마를 볼 수 있는가입니다. 이 가이드는 동작하는 세 가지 구성과 각각이 어디서 깨지는지를 다룹니다.

자연어로 DynamoDB를 어떻게 쿼리하나요?

실질적인 선택지는 셋입니다: 범용 LLM에게 PartiQL 초안을 부탁하고 직접 실행하기(빠르지만, 모델은 여러분의 속성 이름을 짐작하고 있습니다), AI 에이전트를 MCP 서버를 통해 DynamoDB에 연결해 실제로 살펴보고 쿼리하게 하기, 아니면 스키마 인지 어시스턴트가 내장된 DynamoDB 클라이언트 쓰기 — DynoTable의 AI 채팅은 일상 언어를 여러분의 실제 인덱싱된 스키마에 대한 PartiQL이나 SQL로 바꾸고, 정확한 전체 테이블 집계를 계산하며, 모든 쓰기를 검토를 위해 스테이징합니다.

옵션 1: LLM이 초안을 쓴 PartiQL, 실행은 직접

제로 설정 버전: 아무 유능한 모델에게 쿼리를 설명하고, PartiQL을 받아, 콘솔의 PartiQL 편집기나 CLI로 실행합니다:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

동작은 합니다 — 그리고 예측 가능한 세 가지 방식으로 실패합니다:

모델은 여러분의 테이블을 볼 수 없습니다. 속성 이름과 키 형태를 자신 있게 지어냅니다(여러분의 것은 PK = ORDER#<id>인데 orderId라고요). 결국 쿼리를 쓰는 대신 환각된 스키마를 디버깅하게 됩니다.
PartiQL의 제한은 여전히 적용됩니다. SELECT는 정확히 한 테이블을 읽고, 키를 고정하지 않는 WHERE는 전체 테이블 스캔이 됩니다 — 여러분이 직접 쓴 것과 똑같이, 조용히 비쌉니다. 모델은 좀처럼 경고해 주지 않습니다; PartiQL 대 SQL이 SQL 표면이 무엇을 사 주고 무엇을 사 주지 않는지 설명합니다.
스키마나 데이터를 챗봇에 붙여 넣는 것은 데이터 거버넌스 결정입니다. 프롬프트 안의 샘플 항목은 여러분의 경계를 떠나는 프로덕션 데이터입니다.

기억으로 붙여 넣을 수 있는 스키마에 대한 일회성 쿼리에는 좋지만, 워크플로로는 불안합니다.

옵션 2: MCP로 연결된 AI 에이전트

"모델이 테이블을 볼 수 없다"의 구조적 해법은 에이전트에게 프롬프트에 붙여 넣은 스키마 대신 도구를 주는 것입니다. Model Context Protocol(MCP)이 정확히 그 일을 합니다: MCP 서버가 DynamoDB 연산을 타입이 있는 도구로 노출하면, MCP를 지원하는 어떤 에이전트든(Claude, IDE 어시스턴트, 커스텀 에이전트) 테이블을 나열하고, 키를 살펴보고, 실제 결과가 대화로 돌아오는 쿼리를 실행할 수 있습니다.

전체 설정은 — 그리고 에이전트가 데이터베이스를 만지게 할 때 따라오는 동의, 범위 지정, 쓰기 안전성 문제까지 — MCP 서버로 DynamoDB 사용하기에서 다룹니다. DynoTable 자체도 하나를 내장하고 있습니다: 연결별 동의와 범위와 함께, 게이트가 걸린 루프백 전용 도구를 외부 에이전트에 노출할 수 있습니다.

이것은 에이전트 가 곧 제품일 때 — 지원 봇, 사내 Slack 어시스턴트 — 올바른 아키텍처입니다. 일상적인 대화형 작업에서는 여전히 에이전트, 서버, 자격 증명을 직접 조립해야 합니다.

옵션 3: DynamoDB 클라이언트에 내장된 스키마 인지 어시스턴트

DynoTable의 내장 어시스턴트는 통합된 버전입니다: 테이블 옆에 살면서(⌘;), 여러분의 인덱싱된 스키마를 읽습니다 — 활성 프로필 아래의 테이블들, 그 키와 인덱스, 테이블 인덱싱으로 발견된 속성 경로와 타입, 심지어 샘플 값까지 — 그래서 "이걸 지난주로 필터해 줘"는 짐작이 아니라 여러분의 실제 속성 이름으로 해석됩니다. @를 입력하면 @table, @column, @gsi를 명시적으로 참조할 수 있습니다.

테이블 탭 옆에 도킹된 DynoTable AI 채팅: 일상 언어 질문, 생성된 쿼리, 그리고 뷰로 열리는 결과.

질문 하나로 무엇을 하는지, 기능 카탈로그에 따르면:

쿼리를 대신 써 줍니다 — 읽기 전용 PartiQL, 또는 질문에 JOIN / GROUP BY / 집계(DynamoDB의 API에는 없는 분석)가 필요하면 Workbench SQL — 그리고 결과를 클릭하면 진짜 탭으로 열리는 칩으로 제안합니다.
정확한 전체 테이블 답을 계산합니다. 수, 합계, 평균, 그룹별 분해를 요청하면 샘플링된 페이지가 아니라 일치하는 모든 항목을 읽습니다 — "지난달 주문이 몇 건이지?"는 실제 테이블을 반영합니다. 같은 순회를 변환된 내보내기 파일로 재구성할 수도 있습니다.
모든 쓰기를 스테이징합니다. 행을 고쳐 달라고 하면 변경이 검토 가능한 diff로 스테이징 영역에 들어옵니다 — 어시스턴트는 어떤 권한 모드에서도 DynamoDB에 직접 쓰거나, 테이블을 배치 삭제하거나, 테이블 구조를 바꿀 수 없습니다. 검토도, 커밋도 여러분이 합니다.
여러분의 돈을 쓰기 전에 물어봅니다. AWS에 닿아 용량 비용이 드는 읽기는 권한 게이트가 걸려 있고(프로필별 Manual / Auto / Full Auto), 게이트를 거친 모든 결정은 로컬의 항상 켜져 있는 감사 로그에 남습니다.

신뢰 모델은 기능만큼이나 중요합니다: 어시스턴트는 사용자 본인의 AWS Bedrock 자격 증명으로 실행되며, 여러분 계정의 Bedrock과 직접 통신합니다 — 프롬프트, 스키마, 테이블 데이터는 결코 DynoTable의 서버를 경유하지 않고, 추론은 마크업 없이 Bedrock 자체 요금으로 여러분에게 청구됩니다. 도구 결과는 신뢰할 수 없는 데이터로 취급되므로, "이전 지시를 무시하라"가 담긴 행이 에이전트를 탈취할 수 없습니다.

AI가 DynamoDB에서 바꾸지 못하는 것

정직한 AI 계층이라면 데이터베이스의 물리 법칙을 그대로 물려받습니다:

여전히 액세스 패턴이 지배합니다. 키가 아닌 속성에 대한 "where status = X"는 누가 쓰든 필터링된 스캔입니다 — 모델은 그 비싼 쿼리를 더 빨리 타이핑해 줄 뿐입니다. 어떤 질문이 계속 스캔을 강요한다면, 해법은 더 나은 프롬프트가 아니라 모델링(GSI, 더 나은 정렬 키)입니다.
읽기에는 실제 용량 비용이 듭니다. 정확한 전체 테이블 집계는 전체 테이블 읽기입니다. 좋은 도구는 게이트를 걸고 그렇게 말해 줍니다; 요금 계산기가 승인 전에 전체 순회의 비용을 알려 줍니다.
결정론에는 결정론의 자리가 있습니다. 프로덕션에서 영원히 실행할 쿼리라면, Expression Builder에서 표현식을 한 번 직접 만들어 정확한 이름/값 맵을 배포하세요 — AI는 탐색을 위한 것이고, 빌더는 커밋하는 코드를 위한 것입니다.

FAQ

DynamoDB를 그냥 한국어나 영어로 쿼리할 수 있나요? API 자체에 대고는 안 됩니다 — DynamoDB는 표현식과 PartiQL만 말합니다. 하지만 AI 계층이 번역할 수 있습니다: PartiQL 초안을 쓰는 LLM, MCP로 연결된 에이전트, 또는 여러분의 실제 스키마에 대해 쿼리를 생성하고 실행하는 DynoTable 같은 스키마 인지 어시스턴트로요.

DynamoDB에 내장 AI 쿼리 기능이 있나요? DynamoDB API에는 자연어 엔드포인트가 없습니다. 어떤 AI 쿼리든 그 위의 도구 계층에서 옵니다 — 그래서 그 도구의 안전 모델(읽기 게이트, 스테이징된 쓰기, 사용자가 통제하는 자격 증명)이 평가해야 할 핵심입니다.

AI를 프로덕션 데이터 근처에 두어도 안전한가요? 권한의 문제입니다. 이런 것을 확인하세요: 명시적 승인 뒤에 게이트가 걸린 읽기, 직접 실행되는 대신 검토 가능한 스테이징 영역에 들어오는 쓰기, 감사 로그, 그리고 사용자가 통제하는 자격 증명으로 하는 추론. DynoTable의 어시스턴트는 넷 다 충족합니다; 데이터를 붙여 넣은 챗봇은 하나도 충족하지 않습니다.

AI가 테이블을 조인하거나 GROUP BY를 할 수 있나요? DynamoDB API로는 안 됩니다 — 그걸 해 줄 엔진이 없습니다. DynoTable의 어시스턴트는 그런 질문에 읽기 전용 Workbench SQL(DynamoDB의 액세스 패턴 규칙 안에서의 진짜 JOIN, GROUP BY, 집계)로 답하며, count/sum/average 질문도 그리로 갑니다.

비용은 얼마나 드나요? 계량기는 둘입니다: 쿼리가 건드리는 것에 대한 DynamoDB 읽기 용량(어시스턴트는 게이트가 걸린 읽기 전에 물어봅니다), 그리고 여러분 자신의 AWS 계정에 청구되는 Bedrock 추론 — DynoTable은 마크업을 더하지 않고 아무것도 프록시하지 않습니다.

다음 질문은 일상 언어로 해 보세요 — DynoTable을 다운로드하고, AI를 여러분 자신의 Bedrock에 겨누고, 모든 쓰기를 검토 뒤에 두세요.