AI 에이전트에 도구 170개를 보여주면 왜 틀릴까: Postman의 4천만 사용자 운영 교훈

반응형

AI 에이전트 데모는 도구 몇 개와 잘 만든 프롬프트만으로도 그럴듯하게 작동합니다. 하지만 수많은 API와 화면 상태, 사용자 데이터가 얽힌 실제 제품에서는 모델이 할 수 있는 일보다 지금 무엇을 알아야 하는지가 더 중요해집니다.

AWS와 Postman은 2026년 10월 9일 Postman Agent Mode를 4천만 개발자 커뮤니티 규모로 운영하며 얻은 설계 교훈을 공개했습니다.

3줄 핵심 요약

• Postman은 4천만 개발자 규모의 Agent Mode를 운영하며 모델 성능보다 도구 선택과 문맥 설계가 더 큰 병목이었다고 밝혔습니다.
• 테스트에서 보이는 도구가 약 40개를 넘자 선택 오류가 늘어, 170개가 넘는 도구 중 작업에 맞는 약 15개만 하위 에이전트에 제공합니다.
• 상태 변경에는 사용자 승인을 요구하고, 민감정보 제거·지역별 처리·보존 설정·프롬프트 캐시를 함께 운영합니다.

도구가 많아지면 선택지가 아니라 오류도 늘어난다

Postman은 처음에 요청 열기, 필드 수정, 메타데이터 조회처럼 작고 정밀한 도구를 많이 제공했습니다. 제어에는 유리했지만 실제 업무는 긴 도구 호출 연쇄가 되어 느려졌습니다.

Postman의 테스트에서는 모델에 보이는 도구가 약 40개를 넘자 존재하지 않는 도구를 호출하거나 인자를 틀리고, 이름은 비슷하지만 맥락에 맞지 않는 도구를 고르는 오류가 증가했습니다.

170개 도구 중 지금 필요한 약 15개만 보여준다

현재 구조는 루트 에이전트가 도구 임베딩을 저장한 벡터 데이터베이스를 검색해 170개가 넘는 후보를 약 15개의 관련 도구로 좁힙니다. 선택된 도구는 문맥이 분리된 하위 에이전트에 전달됩니다.

큰 모델을 쓰면 일부 오류가 줄었지만 사라지지는 않았기 때문에, 모델 교체보다 작업별 도구 범위를 제한하는 구조를 택했습니다.

읽기 작업은 도구 수보다 데이터 구조가 중요하다

서비스 상태, 테스트 결과와 응답 시간처럼 구조화된 데이터에는 질문마다 별도 도구를 만들지 않습니다. 테이블 스키마를 제공하고 에이전트가 필요한 조인과 조건을 포함한 쿼리를 만들게 합니다.

이는 도구 개수를 늘리는 문제를 데이터 모델링 문제로 바꾸며, 잘 정의된 읽기 권한 안에서 더 다양한 분석 질문을 처리할 수 있게 합니다.

실제 병목은 기능 부족보다 잘못된 문맥이었다

Postman은 도구가 없어서 실패하는 경우보다 현재 열린 요청, 선택한 객체와 이미 정해진 상태를 에이전트가 제대로 알지 못해 실패하는 경우가 더 많았다고 설명합니다. 화면을 그리기 위한 기존 데이터 객체를 그대로 넣으면 잡음이 많았습니다.

그래서 객체별 전용 문맥 처리기가 필요한 정보만 추려 모델에 전달하도록 다시 설계했습니다.

긴 문맥은 전부 넣기보다 계층별로 관리한다

OpenAPI 명세, 요청 설명과 페이로드 같은 사용자 데이터는 길이 제한을 빠르게 채울 수 있습니다. Agent Mode는 얕고 넓은 배경 문맥과 사용자가 선택한 깊고 좁은 문맥을 구분합니다.

제품 지식은 정적 프롬프트에 모두 넣지 않고 RAG 지식베이스에서 질문과 선택 객체에 맞는 설명만 가져옵니다. 새 기능을 배포할 때 관련 문서도 함께 갱신해야 정확도를 유지할 수 있습니다.

승인·개인정보·지역·비용 통제를 별도로 둔다

애플리케이션 상태를 바꾸는 행동은 사용자가 승인해야 실행됩니다. 기업 관리자는 Bedrock Guardrails의 개인정보 제거를 켤 수 있고, 작업에 따라 처리 지역을 제한한 추론 프로필과 전 세계 처리 프로필을 구분합니다.

지원 모델에는 보존 없음 설정을 적용하며, 안정적인 시스템 지침과 변동 문맥에 서로 다른 시간의 프롬프트 캐시를 사용해 지연과 비용을 줄입니다.

사용자와 업계에 미치는 영향

AI 에이전트를 만드는 팀은 도구를 추가하는 속도만큼 도구를 감추고 문맥을 줄이는 설계에 투자해야 합니다. 사용자는 에이전트가 화면을 사람처럼 클릭하는지보다 구조화된 데이터에 직접 접근하는지, 상태 변경 전에 승인을 받는지 확인할 필요가 있습니다.

대규모 운영에서는 모델 선택 하나보다 작업별 도구 범위, 목적에 맞춘 문맥, 개인정보 처리와 지역·보존·캐시 정책이 정확도와 비용을 함께 결정합니다.

확인할 점

이 글은 AWS와 Postman이 2026년 10월 9일 공개한 기술 사례를 바탕으로 정리했습니다. 약 40개 이후의 오류 증가와 170개에서 약 15개로 줄이는 수치는 Postman의 제품·테스트 환경에서 관찰된 결과이며 모든 모델과 서비스의 보편적 임계값은 아닙니다.

Postman의 실제 구현은 공개 샘플이 아닌 독점 시스템입니다. 보존 없음, 캐시 시간과 지원 지역은 모델과 시점에 따라 달라질 수 있으므로 도입 전 최신 Bedrock 및 Postman 문서를 확인해야 합니다.

출처

함께 읽을 글

• 메일·문서·코딩을 한 에이전트가 끝까지: Google Cloud ‘Gemini agent’ 발표
• Claude Haiku 5.5, AWS Bedrock 출시: 빠른 AI 서브에이전트에 맞춘 모델
• AWS 비용·보안 점검을 AI가 맡는다: Well-Architected Agent 공개 미리보기

• AWS Artificial Intelligence Blog — How Postman runs Agent Mode for 40 million developers on Amazon Bedrock

728x90