Amazon Bedrock, Programmatic Tool Calling(PTC)의 세 가지 구현 경로를 공개했다

"Which engineering team members exceeded their Q3 travel budget?" 이 문장은 단순한 질의처럼 보이지만, LLM이 외부 도구를 사용하는 방식의 근본적인 한계를 드러내는 사례다. 원문에서는 비용 감사 시나리오를 통해 기존의 툴 콜링(Tool Calling) 방식이 가진 비효율성을 지적한다. 기존 방식에서는 모델이 도구를 호출하고, 결과를 받고, 다시 추론하여 다음 도구를 호출하는 과정이 반복된다. 이 과정에서 모든 중간 결과물이 모델의 컨텍스트 윈도우를 거쳐야 하며, 이는 곧 토큰 소모의 증가와 응답 지연으로 이어진다.

반면, Programmatic Tool Calling(PTC)은 모델이 도구를 하나씩 호출하는 대신, 여러 도구를 프로그램적으로 호출하는 파이썬 코드를 직접 작성하게 한다. 모델은 코드를 생성하기 위해 단 한 번만 샘플링되며, 실제 도구 호출과 데이터 필터링, 집계 작업은 격리된 샌드박스 환경에서 수행된다. 결과적으로 모델의 컨텍스트에는 최종 처리 결과만 전달된다. 주목할 점은 이러한 구조적 변화가 단순한 속도 개선을 넘어, 대규모 데이터 처리와 프라이버시 민감 작업에서 LLM의 활용 가능성을 확장한다는 사실이다.

Amazon Bedrock의 PTC 구현 방식과 3가지 배포 경로

기존의 도구 호출 방식은 모델이 도구를 호출하고 그 결과를 수신한 뒤 다시 추론하는 과정을 매번 반복하는 구조다. 이러한 라운드 트립(Round Trip) 방식은 도구 호출 횟수가 늘어날수록 지연 시간이 누적되고 컨텍스트 윈도우 내의 토큰 소비량이 급증하는 한계가 있다. 반면 PTC(Programmatic Tool Calling, 프로그래밍 방식의 도구 호출) 패러다임은 모델이 직접 파이썬(Python) 코드를 작성해 샌드박스 환경에서 실행하는 방식을 취한다. 모델은 루프, 조건문, 필터링, 집계 로직을 포함한 코드를 한 번에 생성하며, 실행 환경이 도구 호출과 데이터 처리를 전담한다. 주목할 점은 모델의 샘플링 횟수가 획기적으로 줄어든다는 사실이다. 모델은 코드를 생성할 때와 최종 결과를 해석할 때 단 두 번만 샘플링되며, 그 사이의 모든 도구 호출과 데이터 가공은 컨테이너 내부에서 독립적으로 수행된다.

데이터 처리 효율 측면에서 PTC는 특히 대규모 데이터셋이나 정밀한 수치 계산이 필요한 시나리오에서 강점을 가진다. 수천 개의 비용 레코드를 분석하는 작업의 경우, 기존 방식은 모든 중간 데이터를 모델의 컨텍스트에 입력해야 했으나 PTC는 샌드박스 내부에서 필터링과 집계를 끝내고 최종 결과값만 모델에 전달한다. 그러나 구현 환경에 따라 제어권과 운영 부담은 상이하게 나타난다. 가장 높은 제어권을 제공하는 방식은 Amazon ECS(Elastic Container Service, 아마존 엘라스틱 컨테이너 서비스) 기반의 셀프 호스팅 도커(Docker) 샌드박스다. 이 방식은 네트워크 접근 차단, 읽기 전용 파일 시스템, 비루트 사용자 설정 등 엄격한 보안 계층을 강제할 수 있으며, 개발자가 필요한 커스텀 파이썬 패키지를 직접 구성할 수 있다. 오케스트레이터는 IPC(Inter-Process Communication, 프로세스 간 통신)를 통해 도구 호출을 중계하며 샌드박스의 생명주기를 관리한다.

인프라 관리 부담을 최소화하려는 팀을 위해서는 관리형 솔루션인 Amazon Bedrock AgentCore Code Interpreter가 제공된다. 이는 도커 컨테이너의 직접적인 운영 없이도 동일한 PTC 패턴을 구현할 수 있게 하며, 도구 정의를 샌드박스 세션에 미리 로드하여 모델이 이를 직접 호출하게 만드는 구조다. 반면 개발자 경험을 위해 Anthropic SDK(소프트웨어 개발 키트) 인터페이스를 그대로 유지하고 싶은 경우에는 프록시(Proxy) 경로를 활용한다. Amazon ECS에 배포된 경량 API 변환 프록시가 Anthropic SDK의 호출을 Amazon Bedrock의 InvokeModel 호출로 변환하고 샌드박스 관리와 PTC 프로토콜을 투명하게 처리한다. 사용자는 인프라 제어권, 운영 편의성, 그리고 기존 SDK와의 호환성이라는 세 가지 기준에 따라 적합한 배포 경로를 선택한다.

Docker 샌드박스와 IPC 기반의 실행 메커니즘

실제 실행 단계에서 가장 먼저 적용되는 것은 엄격한 격리 환경이다. 샌드박스는 모델이 생성한 코드가 호스트 시스템에 영향을 주지 않도록 다음과 같은 설정으로 구동된다.

bash

docker run --network none --read-only --user 1000:1000 --cap-drop ALL --memory 512m --cpus 1

네트워크 접근을 완전히 차단하고 파일 시스템을 읽기 전용으로 설정하여 데이터 유출과 변조 가능성을 제거했다. 반면 임시 작업 공간을 위한 최소한의 tmpfs(Temporary File System, 임시 파일 시스템)만 허용한다. 루트 권한을 제거하고 CPU와 메모리 자원을 제한함으로써 자원 고갈 공격이나 권한 상승 시도를 원천적으로 차단하는 구조다.

코드 실행과 도구 호출의 제어는 IPC(Inter-Process Communication, 프로세스 간 통신) 프로토콜을 통해 이루어진다. 오케스트레이터는 샌드박스 내의 러너 스크립트와 표준 입출력(I/O) 스트림으로 통신한다. 주목할 점은 텍스트 스트림 내에서 서로 다른 메시지 유형을 정확히 구분하기 위해 정의된 경계 마커(Boundary Markers)다. 러너 스크립트가 실행 중 도구 호출이 필요하면 호출 내용을 JSON으로 직렬화하여 stderr(표준 에러) 스트림에 경계 마커와 함께 기록한다. 이후 stdin(표준 입력)을 통해 결과가 돌아올 때까지 프로세스 실행을 블로킹(Blocking, 대기) 상태로 유지한다. 반면 오케스트레이터는 stderr를 실시간으로 모니터링하다가 마커 사이의 요청을 파싱하여 실제 도구를 실행하고 그 결과값을 다시 stdin으로 주입한다. 이 과정을 통해 샌드박스는 외부 환경과 격리된 상태를 유지하면서도 필요한 도구의 기능만 선택적으로 이용할 수 있다.

오케스트레이터는 전체 워크플로우의 제어 평면 역할을 수행하며 Bedrock과 샌드박스 사이의 피드백 루프를 관리한다. 구현의 핵심은 다음과 같은 라이브러리를 활용한 제어 루프에 있다.

python

import boto3
import json

오케스트레이터는 사용자 쿼리를 Bedrock에 전달하고 응답 데이터에서 모델이 생성한 파이썬 코드를 추출한다. 추출된 코드는 즉시 샌드박스로 전달되어 실행되며 그 최종 결과값만 다시 모델의 컨텍스트로 피드백된다. 그러나 기존의 도구 호출 방식이 매 단계마다 모델의 추론을 거쳐야 했던 것과 달리 이 구조에서는 코드 생성 시점과 최종 결과 해석 시점에만 모델을 호출한다. 결과적으로 수천 건의 로우 데이터 처리나 복잡한 필터링 작업은 샌드박스 내부에서 완결되며 모델의 컨텍스트 윈도우에 불필요한 데이터가 유입되는 것을 방지한다. 이는 모델의 토큰 소비와 추론 지연 시간을 물리적으로 줄이는 핵심 기제로 작용한다.

전통적 Tool Calling 대비 PTC의 토큰 및 지연 시간 효율성

전통적인 도구 호출 방식은 도구를 한 번 호출할 때마다 모델과 클라이언트 사이에 매번 라운드 트립(Round Trip, 왕복 통신)이 발생한다. 모델이 특정 도구를 호출하고 그 결과값을 수신한 뒤 다시 이를 분석하여 다음 도구를 호출하는 과정이 순차적으로 반복되는 구조다. 이러한 워크플로우는 도구 호출 횟수가 증가함에 따라 지연 시간이 누적되는 복리 효과를 낳는다. 특히 모든 중간 결과 데이터가 모델의 컨텍스트 윈도우(Context Window, 모델이 한 번에 처리할 수 있는 텍스트 범위)를 거쳐야 하므로 토큰 소비량이 급격히 증가한다. 이는 단순히 비용의 문제를 넘어 모델이 처리 가능한 최대 토큰 한도에 빠르게 도달하게 만들어 복잡한 작업의 수행 능력을 저하시키는 요인이 된다.

반면 PTC(Programmatic Tool Calling, 프로그래밍 방식 도구 호출)는 모델이 도구를 하나씩 제어하는 대신 샌드박스 실행 환경에서 구동될 파이썬 코드를 직접 작성하는 방식을 취한다. 이 아키텍처의 핵심은 모델 샘플링 횟수를 단 2회로 엄격하게 제한했다는 점이다. 첫 번째 샘플링은 도구 호출 로직과 데이터 처리 과정을 포함한 코드를 생성할 때 이루어지며, 두 번째 샘플링은 코드 실행이 완료된 후 최종 결과물을 해석하여 사용자에게 답변을 제공할 때 수행된다. 코드 생성과 결과 해석 사이의 모든 과정, 즉 도구의 실제 호출과 데이터의 가공은 모델의 추론 없이 독립적인 실행 환경에서 처리된다. 이는 반복적인 모델 호출로 인한 지연 시간을 제거하고 토큰 사용량을 획기적으로 낮추는 결정적인 근거가 된다.

대량의 데이터를 처리하는 상황에서 PTC의 효율성은 더욱 극명하게 드러난다. PTC는 `asyncio.gather()` 함수를 통해 20개 이상의 도구 호출을 병렬로 처리함으로써 데이터 수집 시간을 단축한다. 기존의 순차적 호출 방식이 가졌던 물리적 병목 현상을 해결한 것이다. 주목할 점은 2,000개가 넘는 원시 레코드가 모델의 컨텍스트에 전혀 진입하지 않고 파이썬 내부 로직만으로 처리된다는 사실이다. 모델이 자연어 추론을 통해 수천 개의 데이터를 일일이 필터링하거나 예산 수치를 비교하는 대신 파이썬의 조건문과 집계 함수를 사용한다. 이는 모델의 컨텍스트 부하를 완전히 제거함과 동시에 수치 계산의 정확도를 보장하며 대규모 데이터셋 처리 시 발생하는 토큰 낭비를 원천적으로 차단하는 결과를 낳는다.

데이터 프라이버시 강화와 대규모 수치 계산의 정확도 향상

기존 툴 콜링 방식에서는 2,000건의 지출 내역을 조회할 때 모든 원시 데이터가 모델의 컨텍스트 윈도우(모델이 한 번에 처리할 수 있는 텍스트 범위)를 거쳐야 했다. 이는 토큰 소모를 가속화할 뿐 아니라 데이터 노이즈를 증가시켜 모델의 추론 정확도를 떨어뜨리는 원인이 된다. 반면 PTC(Programmatic Tool Calling, 프로그램 방식의 도구 호출)는 모델이 데이터를 직접 읽는 대신 이를 처리할 파이썬 코드를 작성하고, 실제 연산은 샌드박스(외부와 격리된 실행 환경) 내부에서 수행하는 구조를 취한다. 결과적으로 모델에게는 최종 가공된 결과값만 전달된다. 원시 데이터가 모델 컨텍스트에 진입하지 않으므로 개인정보나 기업 기밀이 포함된 프라이버시 민감 시나리오에서 보안성이 비약적으로 높아진다.

수치 계산의 정확도 역시 파이썬 엔진의 도입으로 해결된다. LLM은 자연어 추론 과정에서 복잡한 산술 연산이나 대규모 데이터 집계 시 확률적 생성 특성으로 인해 계산 오류를 범하는 경향이 있다. 그러나 PTC 환경에서는 필터링, 집계, 예산 비교 등의 로직이 결정론적인 파이썬 코드 내에서 정밀하게 실행된다. 주목할 점은 asyncio.gather() 같은 비동기 처리 방식을 통해 수십 개의 도구 호출을 병렬로 수행할 수 있다는 점이다. 이는 다단계 프로세스 오케스트레이션(여러 작업을 순서대로 혹은 병렬로 조정하는 과정)의 효율성을 극대화한다. 모델의 샘플링 횟수를 코드 생성 시점과 결과 해석 시점, 단 2회로 제한함으로써 대규모 데이터 처리 시 발생하는 지연 시간을 획기적으로 단축한다.

운영 관점에서는 관리형 서비스인 AgentCore(에이전트코어, Bedrock의 관리형 코드 인터프리터)와 셀프 호스팅 방식의 Docker(도커, 컨테이너 기반 가상화 플랫폼) 환경 간의 선택지가 주어진다. AgentCore는 인프라 관리 부담이 전혀 없는 대신 실행 환경에 대한 제어권이 제한적이다. 반면 ECS(Elastic Container Service, AWS의 컨테이너 관리 서비스) 기반의 셀프 호스팅 방식은 커스텀 파이썬 패키지 설치나 읽기 전용 파일시스템 설정, 비루트(non-root) 사용자 지정 같은 세밀한 보안 구성이 가능하다. 다만 이 경우 컨테이너 생명주기 관리와 IPC(Inter-Process Communication, 프로세스 간 통신) 프로토콜 구현이라는 운영 오버헤드를 직접 감수해야 한다. 결국 기업이 요구하는 보안 수준과 커스터마이징 필요성에 따라 제어권과 편의성 사이의 명확한 트레이드오프(Trade-off, 어느 하나를 얻기 위해 다른 하나를 포기하는 관계)가 발생한다.

한국 기업의 LLM 도입 시 인프라 제어권과 비용 최적화 전략

국내 금융사와 공공기관의 보안 가이드라인은 데이터의 외부 유출을 엄격히 제한한다. 관리형 서비스는 운영 편의성을 제공하지만 세부적인 제어권 확보에는 한계가 있다. 반면 셀프 호스팅 방식의 PTC(Programmatic Tool Calling, 프로그램 방식 도구 호출)는 인프라 제어권을 완전히 확보할 수 있는 실질적인 대안이 된다. 특히 기업 내부의 레거시 시스템과 연동하기 위해 특정 버전의 커스텀 파이썬 패키지를 설치해야 하거나, 엄격한 망 분리 정책에 따른 특정 보안 설정이 필요한 환경에서는 셀프 호스팅 방식이 권장된다. 이는 외부 관리형 샌드박스가 제공하는 표준 환경만으로는 해결할 수 없는 국내 기업 특유의 폐쇄적 인프라 요구사항을 충족하기 위함이다.

주목할 점은 데이터 거버넌스의 구현 방식이다. 관리형 샌드박스는 서비스 제공자가 관리하는 환경에서 실행되지만, 셀프 호스팅은 기업의 AWS 계정 내에서 Docker 컨테이너를 통해 직접 실행된다. 이는 데이터의 흐름이 기업의 보안 경계 내부에서만 이루어지도록 강제할 수 있음을 의미한다. 그러나 이러한 제어권 확보는 ECS(Elastic Container Service, 아마존 엘라스틱 컨테이너 서비스) 클러스터 관리와 컨테이너 이미지 업데이트라는 운영 비용을 수반한다. 그럼에도 불구하고 규제 준수가 최우선인 국내 산업 특성상, 실행 환경에 대한 완전한 가시성과 제어권을 갖는 것은 단순한 운영 편의보다 높은 우선순위를 가진다.

개발 생산성 측면에서는 도구의 인터페이스 선택지가 갈린다. 일부 개발 팀은 Anthropic SDK의 인터페이스를 선호하지만, 실제 추론과 실행은 Amazon Bedrock의 인프라를 활용하고자 한다. 이 경우 Amazon ECS에 경량 API 번역 프록시 계층을 배치하는 전략이 유효하다. 프록시는 Anthropic API 호출을 Amazon Bedrock의 InvokeModel 호출로 변환하며, 동시에 Docker 샌드박스의 생명주기와 PTC 프로토콜을 투명하게 관리한다. 개발자는 다음과 같이 base_url만 변경하여 기존 SDK 환경을 유지하며 Bedrock의 인프라 이점을 누릴 수 있다.