AWS, Bedrock 프로그래밍 방식 툴 콜링(PTC) 구현 3종 가이드 공개

AWS가 Amazon Bedrock에서 프로그래밍 방식 툴 콜링(PTC, Programmatic Tool Calling)을 구현하는 세 가지 경로를 ML 블로그에 정리해 공개했다. 전통적인 툴 콜링이 도구 하나를 부를 때마다 모델을 다시 호출하는 라운드트립 구조라면, PTC는 모델이 여러 도구를 한 번에 묶어 호출하는 파이썬 코드를 작성하고 샌드박스가 그 코드를 실행하는 방식이다.

글이 든 예시는 'Q3 출장비 한도를 초과한 엔지니어링 팀원 찾기'다. 전통 방식이라면 모델은 팀원 20명 명단을 부르고, 각 사람의 비용 기록(50~100건씩)을 차례대로 받아 2,000건 이상의 원자료를 컨텍스트에 끌어들이고, 그 위에서 자연어로 필터·집계·비교를 해야 한다. 라운드트립이 누적되며 토큰 사용량, 지연시간, 자연어 집계의 정확도가 모두 악화된다.

PTC를 켜면 모델은 단 한 번 호출되어 파이썬 코드 한 블록을 생성한다. 그 코드는 asyncio.gather()로 20건의 비용 조회를 병렬로 던지고, 필터·집계·예산 비교를 파이썬 안에서 처리한 뒤 최종 결과만 print로 내보낸다. 모델 컨텍스트에는 2,000건 넘는 원자료 대신 마지막 print 출력만 들어가며, 모델은 결과 해석을 위해 한 번 더 호출되어 총 두 번만 추론한다.

AWS는 같은 패턴을 모델 종류와 무관하게 쓸 수 있도록 자가 호스팅 옵션을 가장 먼저 제시한다. Amazon ECS 위에서 Docker 샌드박스를 직접 운영하는 구조로, Bedrock에 올라온 Claude, Qwen, MiniMax, Llama, Nova 등 다양한 모델을 그대로 쓸 수 있고, 파이썬 패키지와 보안 정책을 도메인에 맞춰 커스터마이즈하면서 실행과 중간 데이터를 자체 AWS 계정 안에 묶어 둘 수 있다.

아키텍처는 두 컴포넌트로 나뉜다. ECS 태스크·Lambda 등 컴퓨트에서 도는 오케스트레이터가 Boto3로 InvokeModel API를 호출하고, 별도의 Docker 샌드박스 컨테이너가 모델이 생성한 파이썬 코드를 실행한다. 둘은 stdin·stderr 표준 입출력을 통한 IPC로 통신하며, 평소 tool_config에 넘기던 도구 정의를 시스템 프롬프트에 직접 박아 모델이 그 도구를 호출하는 파이썬 코드를 작성하도록 유도한다.

핵심 모듈인 SandboxExecutor는 코드 실행 요청마다 격리 컨테이너를 띄우고 종료까지 책임진다. 컨테이너 안의 러너 스크립트는 모델 코드를 async 컨텍스트로 감싸 실행하면서 __PTC_TOOL_CALL__, __PTC_END_CALL__, __PTC_OUTPUT__ 같은 마커로 도구 호출 요청과 결과, 최종 출력을 텍스트 스트림 안에서 구분한다. 모델 코드가 await get_team_members 같은 함수를 호출하면 러너가 인자를 JSON으로 직렬화해 stderr로 내보내고, 오케스트레이터가 외부에서 도구를 실행한 뒤 결과를 stdin으로 다시 주입한다.

러너 스크립트는 싱글 모드와 루프 모드 두 가지를 지원한다. 싱글 모드는 코드를 한 번 실행하고 컨테이너를 종료하는 일회성 작업용이고, 루프 모드는 컨테이너를 살려 두고 여러 차례의 코드 실행을 받아 세션 상태와 변수를 재사용하는 데 쓴다.

샌드박스를 직접 운영할 필요가 없는 팀을 위해 AWS는 두 가지 관리형 경로도 함께 안내한다. 하나는 Amazon Bedrock AgentCore Code Interpreter를 그대로 PTC 실행 환경으로 쓰는 방식이고, 다른 하나는 Anthropic SDK 호환 프록시를 거치는 경로로 이미 Anthropic 개발자 경험을 쓰던 팀이 코드 변경을 최소화하면서 Bedrock 위에서 PTC를 도입할 수 있게 한다.