데모는 쉽다.

모델을 데이터베이스에 연결하고, 자연어 질문을 던지면 답변을 얻는다.

하지만 실제 운영 환경(production)에서의 결정은 더 어렵다.

이 모델은 누구를 대신하여 행동하는가? 어떤 테이블에 접근할 수 있는가? 잘못된 조인(join)을 추측했을 때 무슨 일이 발생하는가? 나중에 무엇이 일어났는지 재구성할 수 있는가?

AI 에이전트가 운영 데이터에 쿼리하기 전에, 그 접근 경로에 대한 검토가 필요하다. 6개월짜리 거버넌스 프로그램이 아니라, 실용적인 체크리스트가 필요하다.

내가 계속 돌아가는 체크리스트는 다음과 같다:

• 모든 요청은 실제 사용자 또는 서비스 ID에 매핑되어야 한다.
• 읽기 전용(Read-only) 자격 증명(credentials)이 기본값이어야 한다.
• 도구 카탈로그는 역할과 워크플로우별로 범위가 지정되어야 한다.
• 반복적인 질문에는 승인된 데이터베이스 뷰(view)를 사용해야 한다.
• 민감한 컬럼은 제외되거나, 마스킹되거나, 차단되어야 한다.
• 행 제한(Row limits), 구문 시간 초과(statement timeouts), 속도 제한(rate limits)이 적용되어야 한다.
• 프롬프트, 도구 호출, 생성된 쿼리, 사용자 및 결과 메타데이터가 로깅되어야 한다.
• 카탈로그 확장은 검토를 거쳐야 한다.
• 쓰기 접근은 별도의 승인 경로로 처리되어야 한다.

마지막 부분이 중요하다.

에이전트에게 추천을 준비하게 하는 것과, 에이전트가 운영 환경에 놀라게(surprise) 만드는 것 사이에는 큰 차이가 있다.

MCP는 클라이언트 측에서 데이터베이스 접근을 간단하게 느끼도록 만든다. 이는 좋다. 하지만 동시에 보안 모델은 프롬프트와 데이터베이스 사이의 계층으로 이동해야 함을 의미한다: 즉, ID(identity), 권한(permissions), 도구 범위(tool scope), 쿼리 제어(query controls), 그리고 감사 가능성(auditability)이다.

이 내용을 더 자세한 Conexor 체크리스트로 확장하여 여기에 게시했다: https://conexor.io/blog/ai-database-access-review-checklist?utm_source=devto&utm_medium=article&utm_campaign=content

목표는 'AI를 프로덕션에 연결하는 것'이 아니다.

목표는 특정하고 검사 가능한 AI 데이터 접근 경로를 승인하는 것이다.