읽기 전용 데이터베이스 접근이 AI 분석을 위한 올바른 기본값입니다. 하지만 그것만으로는 부족합니다. 이는 낯설게 들릴 수 있지만, 프로덕션 환경에서 일어나는 일을 지켜보면 알 수 있습니다. 팀은 AI 에이전트에 SELECT 만 실행할 수 있는 역할 (role) 을 부여합니다. 모든 사람이 안심합니다. 에이전트가 데이터를 변조할 수 없기 때문입니다. 그런데 에이전트는 비용이 많이 드는 쿼리를 실행하거나, 요약만 있으면 충분했을 때 50,000 개의 행을 반환하거나, 민감한 열을 노출시키거나, 스키마가 명확해 보였지만 실제로는 아니었기 때문에 잘못된 테이블에서 답변합니다. 데이터는 변조되지 않았습니다. 하지만 워크플로는 여전히 안전하지 않을 수 있습니다.

SELECT-only 가 실제로 해결하는 것은 무엇입니까? 그것은 쓰기를 방지합니다. 이는 중요합니다. 보통 첫 번째 경계선 (boundary) 이 되어야 합니다. 하지만 그것은 다음을 결정하지 않습니다:

• 어떤 행을 볼 수 있는가
• 어떤 열이 민감한가
• 어떤 테이블이 권위 있는가
• 어떤 쿼리가 너무 비싼가
• 어떤 메트릭 정의가 올바른가
• 어떤 답변에 감사 추적 (audit trail) 이 필요한가

읽기 전용은 데이터 무결성을 보호합니다. 하지만 기밀성, 성능, 또는 답변 품질을 자동으로 보호하지는 않습니다.

통제된 읽기 전용 (Governed read-only) 이야말로 목표입니다. AI 분석을 위한 더 안전한 패턴은 다음과 같이 좁혀져야 합니다:

• 승인된 리포팅 뷰 (approved reporting views)
• 비즈니스 언어로 된 스키마 컨텍스트 (schema context in business language)
• 행 제한 및 타임아웃 (row limits and timeouts)
• 집계 우선 도구 (aggregate-first tools)
• 쓰기 가능 작업에 대한 분리된 경로 (separate paths for write-capable operations)
• 의미 있는 쿼리마다 감사 로그 (audit logs for every meaningful query)

모델은 프롬프트에서 모든 것을 기억할 필요가 없습니다. 접근 계층이 이를 강제해야 합니다.

우리는 여기에 더 많이 썼습니다: Read-only AI analytics: why SELECT-only is necessary but not enough
Conexor 는 이 정확한 MCP 레이어 (MCP layer) 를 기반으로 구축되었습니다: AI 클라이언트와 라이브 데이터베이스 및 API 를 연결하면서 모든 프롬프트를 프로덕션 리스크로 전환하지 않도록 합니다.

실용적인 질문은 "AI 가 SELECT 만 할 수 있는가"가 아니라, 다음과 같습니다:

• 무엇을 선택할 것인가 (SELECT what)
• 누구를 위한 것인가 (for whom)
• 어떤 도구를 통해 하는 것인가 (through which tool)
• 어떤 컨텍스트로 하는 것인가 (with which context)
• 어떤 제한 아래에서 하는 것인가 (under which limits)
• 그리고 감사 추적이 있는가 (and with what audit trail)?