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

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

개발용 AI 도구가 실제 운영 환경에서 실패하는 핵심 이유는 빌드타임의 자유로운 권한과 입력을 런타임에 그대로 허용하기 때문이며, 사전 정의된 SQL과 인증된 사용자 신원으로 실행 범위를 제한해야 한다.

📌 핵심 요점

1. 빌드타임과 런타임은 목적이 다르다. 개발 보조용 관리 도구와 자연어 SQL은 탐색의 유연성이 중요하지만, 최종 사용자용 서비스는 실행 범위와 권한을 예측 가능하게 통제해야 한다.
2. 운영용 도구는 사전에 정의한 SQL과 타입이 지정된 파라미터를 사용한다. 발표자는 이를 통해 임의 쿼리 실행을 제한하고 SQL 인젝션 위험, 지연, 환각을 줄일 수 있다고 설명한다.
3. 연결 정보만 숨겨서는 충분하지 않다. 읽기 전용 설정, 허용 데이터셋, 출력량 제한, 고정된 SQL을 함께 적용해 에이전트가 접근하고 반환할 수 있는 범위를 줄여야 한다.
4. 사용자·애플리케이션·에이전트의 신원을 구분해야 한다. 애플리케이션의 넓은 권한이 에이전트에 그대로 전달되면, 악성 입력이 이를 악용해 사용자가 볼 수 없는 데이터를 가져올 수 있다.
5. 사용자 ID는 모델이 선택하는 입력에서 제외한다. 애플리케이션이 인증 후 값을 바인딩하거나 도구가 서명된 토큰을 검증하고 사용자 정보를 추출하도록 설계한다.

🧩 배경과 문제 정의

Google 엔지니어 Avery Kitch와 Prerna는 데이터베이스용 MCP 도구를 개발한 경험을 바탕으로, 개발 단계에서 유용한 도구가 운영 환경에서는 왜 위험해질 수 있는지 설명한다. Avery는 MCP Toolbox for Databases와 Google Cloud MCP 서버 관련 업무를, Prerna는 Eval Bench와 MCP Toolbox 관련 업무를 소개한다.

발표에서 빌드타임은 개발자를 돕는 관리·탐색 작업을, 런타임은 챗봇처럼 최종 사용자가 이용하는 애플리케이션의 실행을 뜻한다. 핵심 문제는 모델이 SQL과 사용자 ID를 자유롭게 정하면서 애플리케이션의 넓은 권한까지 사용하면, 사용자에게 허용되지 않은 데이터나 작업에 접근할 수 있다는 것이다.

해결 과정은 연결 정보를 분리하는 단계에서 시작해 데이터 접근 범위, 실행 SQL, 사용자 신원을 차례로 통제하는 방향으로 전개된다. 예정된 챗봇 데모는 기술 문제로 진행하지 못했고, 후반부는 슬라이드 설명으로 이어진다.

🕒 시간순 섹션별 상세정리

1. 발표자 소개와 빌드타임·런타임 문제

• Avery와 Prerna는 Google의 데이터베이스 MCP 도구 및 에이전트 평가 업무를 소개하고, 개발용 도구가 운영 환경에서 실패하는 문제를 주제로 제시한다. [00:52]
• 발표는 Google의 MCP 배경, 데이터베이스 도구 패턴, 신원을 인식하는 보안 가드레일 순서로 진행될 예정이라고 안내한다. [01:24]

2. 자체 운영 Toolbox와 관리형 MCP

• MCP Toolbox는 오픈소스 자체 운영 서버로 묶인다. 발표자는 약 1만 5,700개 스타, 132명 이상 기여자, 40종 이상 데이터베이스 지원과 연결 풀링·통합 인증·관측 기능을 보여준다. [01:57]
• Google 관리형 MCP는 호스팅과 확장을 맡는 대안으로 묶인다. 발표자는 Model Armor와 접근 관리 기능을 언급하고, 관리형 MCP와 Toolbox를 합쳐 전월 2,000만 건의 도구 호출이 있었다고 드러낸다. [02:41]

3. 관리 도구와 자연어 SQL의 쓰임

• 제어 영역 도구는 인스턴스와 데이터베이스를 생성·관리하는 개발 보조 도구이며, 위험한 작업을 막기 위해 사람이 개입해야 한다고 강조한다. [03:29]
• 자연어 SQL은 에이전트가 원시 SQL을 생성해 실행하는 방식이다. 질의를 미리 알기 어려운 분석과 유연한 탐색에 적합하며, 구매·반품·마케팅 정보를 결합한 질문을 예로 든다. [04:20]

4. 운영 환경에는 구조화된 실행 범위가 필요하다

• 구조화 SQL 도구는 사전 정의된 로직과 파라미터로 접근을 제한한다. 발표자는 운영 환경에서 SQL 인젝션 위험과 지연, 환각을 줄이는 데 도움이 된다고 보여준다. [04:55]
• 개발 단계의 관리·탐색 도구와 최종 사용자용 런타임 도구를 구분하고, 주문 취소처럼 정해진 SQL을 실행하는 도구를 운영 사례로 제시한다. [05:48]
• 가드레일이 없는 개발용 도구 사례에서는 에이전트가 테이블을 삭제하고 새로 시작하도록 요청해 데이터가 모두 삭제됐다고 보여준다. [06:08]

5. 여행 챗봇의 신원 통제와 시연 중단

• 발표자는 항공편 예약·변경 등을 돕는 챗봇을 보여준다. Prerna가 Avery라고 주장해도 인증된 신원을 기준으로 본인을 위한 예약만 처리하도록 설계했다고 드러낸다. [07:36]
• 영상 재생과 연결 문제로 데모를 보여주지 못했으며, 슬라이드로 데이터베이스 접근 보안과 가드레일 설명을 이어간다. [08:31]

6. 에이전트 권한을 악용하는 공격

• 혼동된 대리인 공격은 사용자가 에이전트를 속여 에이전트의 권한을 부적절하게 사용하게 만드는 패턴이다. 비공개 데이터, 신뢰할 수 없는 콘텐츠, 외부로 데이터를 내보낼 능력의 결합을 위험 조건으로 보여준다. [09:21]
• 가상의 장애 대응 사례에서 악성 내부자가 티켓에 급여 조회 지시를 넣는다. 에이전트가 자신의 권한으로 급여를 조회해 티켓에 게시하면, 원래 접근 권한이 없던 사용자에게 정보가 유출된다. [10:25]

7. 세 가지 신원과 두 종류의 입력

• 기존 애플리케이션의 고정된 입력·쿼리와 달리 에이전트는 행동 경계가 불명확해질 수 있다. 사용자·애플리케이션·에이전트 신원을 구분하고, 에이전트의 데이터 접근은 최종 사용자에게 필요한 범위로 제한해야 한다. [11:50]
• 에이전트가 동적으로 생성하는 파라미터는 신뢰하지 않는 입력으로 취급한다. 사실에 기반한 제약을 담는 애플리케이션 파라미터는 에이전트의 통제 밖에 둬야 한다. [12:17]

8. 연결 정보와 데이터 접근 범위 축소

• 자격 증명·호스트·포트·SQL을 모두 모델이 다루는 도구는 광범위한 접근 위험을 만든다. Toolbox는 연결 정보를 YAML에 미리 설정하고 서버가 주입하는 source 구성으로 이를 분리한다. [13:16]
• 읽기 전용 제한은 쓰기 도구 제거뿐 아니라 데이터베이스 드라이버 수준에서도 적용한다. 일부 데이터베이스의 허용 데이터셋 설정으로 접근 범위를 더 좁힐 수 있다. [14:02]
• 출력량 제한은 한 번에 가져올 수 있는 데이터를 줄여 유출 피해 범위와 에이전트·데이터베이스의 부담을 낮추는 장치로 드러난다. [14:20]

9. 임의 SQL에서 사전 정의된 도구로

• 연결 정보를 분리해도 모델이 임의 SQL을 생성할 수 있다는 문제가 남는다. Toolbox의 사용자 정의 도구는 YAML에 실행할 SQL을 정하고 도구 이름과 설명도 지정한다. [15:18]
• 준비된 문장과 타입이 지정된 파라미터를 사용하고 입력 타입을 검증해 SQL 인젝션 공격 위험을 줄인다고 보여준다. [15:36]

10. 정확하게 사용하기 쉬운 도구 설계

• 도구는 개별 REST API보다 업무 결과를 중심으로 설계해 호출 왕복을 줄인다. 설명에는 이미 제공되는 파라미터 정보를 반복하기보다 정확한 사용을 돕는 지침을 담는다. [16:12]
• 읽기와 쓰기 도구를 분리하면 읽기 자동 승인과 쓰기 사용자 확인을 구분하기 쉽다. 오류에는 재시도 등 후속 행동을 판단할 수 있는 정보를 제공한다. [16:55]
• 복잡한 맵과 입력 조합 대신 평평한 구조와 단순한 입력을 사용하면 신뢰성을 높일 수 있다고 권고한다. [17:16]

11. 사용자 ID를 모델의 통제에서 제거

• 항공편 조회 SQL을 고정해도 사용자 ID를 모델이 입력한다면 민감한 신원을 조작할 여지가 남는다. 애플리케이션이 사용자를 인증하고 해당 값을 도구에 바인딩하는 방식을 보여준다. [18:09]
• 다른 방식은 도구가 OpenID 서명 JWT를 검증한 뒤 사용자 ID·이메일·발급자 등의 클레임을 추출하는 것이다. 이렇게 신원을 도구에 연결해 모델의 통제에서 분리한다. [18:50]

12. 최소 입력 도구와 평가의 중요성

• 최종 항공편 조회 도구에서 모델은 날짜처럼 단순한 값만 입력한다. 발표자는 민감한 신원과 실행 제약을 시스템이 통제하는 구성을 제로 트러스트 아키텍처로 보여준다. [19:20]
• 발표자는 데모 문제에 사과하고 문서와 GitHub 저장소를 안내한다. 특히 도구가 잘 작동하는지 확인하는 Eval Bench와 평가의 중요성을 강조한 뒤 발표를 마친다. [19:54]

🧾 결론

• 빌드타임 도구를 운영 서비스에 연결하는 것만으로는 안전한 런타임 도구가 되지 않는다. 운영 목적에 맞게 권한과 입력을 다시 설계해야 한다.
• 보안의 핵심은 모델이 올바르게 판단하기를 기대하는 데 그치지 않고, 연결 정보·쿼리·사용자 신원을 모델의 통제 밖에 두는 것이다.
• 좋은 도구는 업무 결과를 중심으로 설계하고, 단순한 입력과 명확한 설명, 복구 가능한 오류 정보를 제공한다. 읽기와 쓰기를 분리하면 승인 정책도 명확해진다.
• 발표는 문서와 GitHub 저장소, Eval Bench를 통한 평가의 중요성을 강조하며 마무리한다.

📈 투자·시사 포인트

• 기업용 AI 도입을 평가할 때 모델 성능뿐 아니라 데이터 접근 통제, 인증 연계, 도구 평가 체계를 함께 살펴볼 필요가 있다.
• MCP Toolbox의 자체 운영 방식과 Google 관리형 MCP의 대비는 조직이 맞춤 구성과 운영 부담 사이에서 선택해야 할 지점을 보여준다.
• 발표자가 제시한 도구 호출량과 오픈소스 참여 수치는 활용 규모의 참고 자료다. 매출, 수익성, 투자수익률을 입증하는 자료는 제시되지 않았다.
• 읽기 전용 제한이 주요 고객 요청이라는 설명은 실제 도입에서 에이전트의 기능 확대만큼 권한 축소와 통제 가능성도 중요하다는 점을 시사한다.

⚠️ 불확실하거나 확인이 필요한 부분

• 런타임 챗봇 데모는 기술 문제로 재생되지 않았다. 타인 사칭을 차단한다는 동작은 발표자의 설명이며, 이 영상에서 정상 작동하는 시연으로 확인되지는 않았다.
• GitHub 스타 약 1만 5,700개, 기여자 132명 이상, 데이터베이스 40종 이상, 전월 도구 호출 2,000만 건은 발표 당시 제시한 수치다. 집계 기준과 현재 수치는 확인되지 않는다.
• 구조화 SQL의 지연·환각 감소 효과와 보안 개선에 대한 정량 비교는 제공되지 않았다. 파라미터화와 인증을 적용했다는 사실만으로 모든 공격을 차단한다고 해석해서는 안 된다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 도구를 개발 보조용 관리·탐색 도구와 최종 사용자용 운영 도구로 분류하고, 각 도구의 권한과 사람의 확인 필요 여부를 기록한다.
• 운영 도구의 임의 SQL 입력을 점검하고, 정해진 업무에는 사전 정의 SQL·준비된 문장·입력 타입 검증을 적용한다.
• 데이터베이스 연결 정보와 사용자 ID를 모델 입력에서 분리하고, 인증 후 바인딩 또는 토큰 검증으로 전달하도록 설계한다.
• 읽기 전용 설정, 허용 데이터셋, 출력량 제한을 점검하고 읽기·쓰기 도구의 승인 정책을 구분한다.

❓ 열린 질문

• 사전 정의하기 어려운 분석 질의에는 어느 범위까지 자연어 SQL을 허용하고, 어떤 권한 제한과 사람의 검토를 적용할 것인가?
• 사용자·애플리케이션·에이전트의 신원을 실제 서비스에서 어떻게 연결해 최종 사용자의 접근 범위를 강제할 것인가?
• 사용자 사칭 차단과 데이터 유출 방지를 어떤 평가 사례 및 통과 기준으로 지속 검증할 것인가?