Build-Time vs. Run-Time: Why Dev Tools Fail in Production — Averi Kitsch & Prerna Kakkar, Google

한 줄 핵심

데이터베이스용 에이전트 도구는 빌드타임의 유연한 개발 보조에는 유용하지만, 프로덕션에서는 권한·입력·출력을 엄격히 제한하는 런타임 도구와 신원 분리가 없으면 보안 사고와 오작동이 쉽게 발생한다.

시간별 요약

1. 0:00
   소개, MCP Toolbox와 관리형 MCP 발표는 Google의 MCP Toolbox for databases와 Google managed MCP를 중심으로, 데이터베이스용 에이전트 도구를 어떻게 안전하게 제공하는지 설명한다. 자체 운영형은 연결 풀링과 관측성을 기본 제공하고, 관리형은 Gemini CLI, Cloud Code 같은 하네스에 연결해 대규모 도구 호출을 처리한다.
2. 2:56
   데이터베이스용 일반적인 도구 패턴 데이터베이스 도구는 관리 작업용 control plane 도구와 자연어를 SQL로 바꾸는 NL2SQL 도구로 크게 나뉜다. 전자는 인스턴스와 DB 생성·관리처럼 위험한 작업을 다루므로 human in the loop이 필요하고, 후자는 탐색적 분석과 복잡한 질의 작성에 적합하다.
3. 4:37
   프로덕션을 위한 구조화된 SQL 도구 프로덕션에서는 사용자가 어떤 SQL을 쓸지 이미 알고 있고, 파라미터가 미리 정해진 구조화된 SQL 도구가 더 적합하다. 이 방식은 SQL injection 위험을 줄이고, 에이전트의 환각을 낮추며, 지연시간과 접근 제어를 더 엄격하게 관리할 수 있다.
4. 5:20
   빌드타임과 런타임의 차이 NL2SQL 도구와 control plane 도구는 개발 보조용 빌드타임 도구로는 유용하지만, 프로덕션 사용자 흐름에는 그대로 쓰면 안 된다. 런타임에는 Patching AI나 LangChain 같은 방식으로 사용자용 앱에 맞는 결정적 도구를 구성해야 한다.
5. 6:16
   빌드타임 도구가 테이블을 삭제할 때 데모에서는 빌드타임 도구가 에이전트의 잘못된 지시를 받아 테이블 전체를 삭제하는 사고가 발생한다. 안전장치와 guardrail이 없으면 에이전트가 자신 있게 위험한 작업을 실행할 수 있고, 그 결과는 즉시 파괴적일 수 있다.
6. 8:46
   데이터베이스의 보안은 에이전트만큼만 강하다 에이전트와 LLM은 쉽게 속을 수 있으므로, 데이터베이스 보안은 결국 에이전트의 권한 설계에 달려 있다. 사용자가 에이전트를 속여 권한을 오남용하게 만드는 confused deputy 공격이 대표적인 위험이다.
7. 9:13
   치명적 삼중조합과 confused deputy 유출은 비공개 데이터, 신뢰되지 않은 입력, 그리고 외부 사용자에게 그 내용을 다시 노출할 능력이 동시에 있을 때 발생한다. 티켓 기반 트리아지 에이전트처럼 신뢰된 시스템이 악성 입력을 받아 권한을 그대로 행사하면, 원래 접근 권한이 없던 데이터가 외부로 흘러나간다.
8. 11:19
   사용자, 애플리케이션, 에이전트 신원 분리 사용자 신원, 애플리케이션 신원, 에이전트 신원을 분리해야 권한 범위를 정확히 통제할 수 있다. 사용자에게는 앱 접근만 주고, 애플리케이션은 필요한 서비스에만 넓게 접근하되, 에이전트는 최종 사용자에게 필요한 데이터 범위까지만 접근하게 해야 한다.
9. 12:33
   슈퍼유저 도구를 제한형 도구로 진화시키기 초기에는 에이전트가 데이터베이스 자격 증명, 호스트, 포트, raw SQL까지 쥔 슈퍼유저 형태지만, MCP Toolbox는 source primitive로 연결 정보를 에이전트 바깥에 둔다. read only 제한, allowed data sets, 출력 크기 제한까지 더해 blast radius를 줄이고, 도구 입력도 SQL string 수준으로 단순화한다.
10. 14:55
    커스텀 도구와 prepared statements 에이전트가 임의의 SQL을 생성하지 못하게 하려면 YAML로 정확한 SQL 문을 정의한 custom tools가 필요하다. prepared statements와 type parameters를 사용하면 입력 검증이 강해지고, 도구 이름과 설명도 에이전트가 올바르게 사용할 수 있도록 명확히 설계할 수 있다.
11. 15:52
    도구 품질을 위한 모범 사례 도구는 원자적 REST API가 아니라 실제 결과 중심으로 설계해야 하며, 읽기와 쓰기를 분리해 승인 흐름을 다르게 가져가야 한다. 또한 재시도 가능한 구체적 오류, 단순한 평면 입력 구조, 그리고 중복되지 않는 명확한 설명이 도구 품질을 크게 높인다.
12. 17:39
    바인딩된 파라미터와 에이전트에서 PII 숨기기 user ID 같은 PII는 에이전트가 직접 다루게 두면 안 되며, 애플리케이션이 먼저 인증한 뒤 bound parameters로 도구에 묶어야 한다. 또는 authenticated parameters로 identity token을 검증해 user claims를 추출하면, 민감한 신원 정보가 에이전트 제어 밖에서 처리된다.

실무 인사이트

• 프로덕션용 에이전트 도구는 '무엇을 할 수 있나'보다 '무엇을 절대 못 하게 할 것인가'를 먼저 설계해야 한다.
• SQL 생성권, 연결 정보, 사용자 신원처럼 위험도가 큰 요소는 에이전트 입력에서 분리하고, 도구 시그니처를 가능한 한 좁게 유지하는 것이 핵심이다.
• 읽기/쓰기 분리, 명시적 오류, bound parameters, authenticated parameters를 함께 적용하면 보안과 운영 안정성을 동시에 높일 수 있다.