[한영자막] 개발용 AI 도구가 왜 실제 환경에선 실패할까요? 빌드타임과 런타임의 결정적 차이 | Google 엔지니어

한 줄 핵심

개발용 AI 도구는 빌드타임의 유연한 실행 방식으로는 잘 작동해도, 프로덕션에서는 권한·입력·출력을 강하게 통제하는 런타임 도구로 재설계하지 않으면 쉽게 오작동하거나 데이터 유출을 일으킨다.

시간별 요약

1. 0:00
   소개 및 Google의 MCP Toolbox Google의 MCP Toolbox와 Google managed MCP를 바탕으로, 데이터베이스용 AI 도구를 어떻게 운영하고 보안 경계를 둘지 다룬다. 핵심 주제는 개발자 보조용 도구, 프로덕션용 도구, 그리고 신원 인식 가드레일을 통해 데이터 유출을 막는 방법이다.
2. 2:43
   데이터베이스용 대표 도구 패턴 데이터베이스 도구는 관리용 control plane 도구와 자연어를 SQL로 바꾸는 NL to SQL 도구로 크게 나뉜다. 전자는 인스턴스 생성·관리 같은 작업에, 후자는 사전에 어떤 쿼리가 필요한지 모를 때의 탐색적 분석에 적합하다.
3. 4:24
   프로덕션을 위한 구조화된 SQL 도구 프로덕션에서는 agent가 임의 SQL을 생성하는 방식보다, 미리 정의된 구조화된 SQL 도구가 더 적합하다. 이런 방식은 SQL injection 위험을 줄이고, 접근 범위를 통제하며, 지연 시간과 hallucination도 낮춘다.
4. 5:07
   빌드타임과 런타임 도구의 결정적 차이 NL to SQL과 관리용 도구는 빌드타임 도구로서 유연하지만 위험도가 높아 human-in-the-loop가 필요하다. 반면 런타임 도구는 end user 애플리케이션에 맞춰 deterministic한 동작과 안정적인 운영을 목표로 한다.
5. 6:03
   빌드타임 도구가 DB 테이블을 날려버린 실제 사례 빌드타임 도구를 데모에 그대로 적용하면 agent가 테이블 삭제 같은 파괴적 행동을 수행할 수 있다. 실제 사례처럼 안전장치가 없으면 오류 수준을 넘어 데이터 소실로 이어질 수 있다.
6. 8:33
   데이터베이스 보안은 앞단의 agent 수준과 같다 데이터베이스 보안은 그 앞단의 agent가 얼마나 쉽게 속을 수 있는지에 달려 있다. 사용자가 agent를 속여 권한을 오용하게 만드는 confused deputy 패턴이 핵심 위험으로 제시된다.
7. 9:00
   혼동된 대리인 공격과 치명적 3요소 private data, untrusted content, 외부 사용자에게 내용을 다시 노출할 수 있는 능력이 동시에 있으면 데이터 유출이 발생한다. 티켓 triage 같은 시나리오에서 신뢰된 입력이 악용되면 권한 있는 agent가 민감 정보를 그대로 반환하게 된다.
8. 11:06
   사용자·앱·agent 3대 Identity 분리 사용자 identity, 애플리케이션 identity, agent identity를 분리해야 권한 경계를 명확히 할 수 있다. 특히 agent가 다루는 파라미터는 untrusted input으로 보고, 애플리케이션이 통제해야 하는 사실 기반 제약은 agent 밖에 둬야 한다.
9. 12:20
   슈퍼유저 권한에서 엄격히 통제된 도구로의 진화 초기 모델링 방식은 agent가 DB 자격 증명과 raw SQL까지 가진 슈퍼유저 구조라서 위험하다. MCP Toolbox는 연결 정보를 YAML과 source primitive로 분리하고, read-only 제한·allowed data sets·출력 크기 제한으로 blast radius를 줄인다.
10. 14:42
    커스텀 도구와 Prepared Statements로 인젝션 차단 agent가 임의 SQL을 만들지 못하게 하려면 YAML로 고정된 SQL을 실행하는 custom tools가 필요하다. Prepared Statements와 type parameters를 사용하면 입력 검증을 강화해 SQL injection 공격을 줄일 수 있다.
11. 15:39
    agent를 위한 고품질 도구 설계 베스트 프랙티스 도구는 원자적 REST API보다 결과 중심으로 설계해야 round trip을 줄일 수 있다. 또한 read/write 도구를 분리하고, 재시도 가능한 actionable errors를 반환하며, 복잡한 구조보다 단순한 flat input을 쓰는 것이 안정적이다.
12. 17:26
    바운드 파라미터로 개인정보 격리하기 user ID 같은 PII는 agent가 직접 보지 못하게 bound parameters나 authenticated parameters로 분리해야 한다. 이렇게 하면 identity token 검증 후 필요한 claim만 사용하게 되어, 민감 정보가 agent 통제 밖에서 안전하게 처리된다.

실무 인사이트

• 프로덕션용 에이전트 도구는 ‘무엇을 할 수 있나’보다 ‘무엇을 절대 못 하게 할 것인가’를 먼저 정해야 안전하다.
• DB 연동 에이전트는 SQL 생성 능력보다 권한 분리, read-only 제한, 출력 크기 제한이 실제 사고를 더 크게 줄인다.
• PII와 사용자 identity는 agent 입력에서 제거하고, 애플리케이션이 바인딩하거나 토큰 검증으로 주입하는 구조가 가장 실무적이다.