How Postman runs Agent Mode for 40 million developers on Amazon Bedrock

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Postman은 4,000만 개발자 커뮤니티를 지원하는 Agent Mode를 Amazon Bedrock에서 운영하며, 도구의 수보다 작업별 도구 선택과 목적에 맞는 컨텍스트 설계가 에이전트의 효과를 좌우한다고 설명한다.

📌 핵심 요약

• Agent Mode는 API 테스트·문서화·탐색·구현을 지원하며, 11년간 발전한 Postman의 인터페이스 중심 구조를 에이전트가 데이터로 이해하고 조작할 수 있도록 재설계하는 과정에서 통합 문제가 드러났다.
• Postman 테스트에서는 노출된 도구가 약 40개를 넘으면 선택 오류가 증가했다. 현재는 루트 에이전트가 벡터 데이터베이스를 검색해 170개가 넘는 도구에서 약 15개를 선택하고, 컨텍스트가 격리된 하위 에이전트에 전달한다.
• API Catalog에서는 ClickHouse 테이블 스키마를 제공하는 단일 쿼리 도구로 여러 조회 기능을 통합했다. 실제 실패는 기능 부족보다 컨텍스트 부족에서 더 많이 발생했으며, 전용 컨텍스트 핸들러와 컨텍스트 예산 관리가 중요해졌다.
• Agent Mode는 클라이언트 측 도구, 일반 에이전트 지침, RAG 지식 기반을 결합한다. 애플리케이션 상태를 변경하는 작업에는 사용자 승인이 필요하며, 기업 관리자는 Amazon Bedrock Guardrails를 켜서 개인 식별 정보를 기반 모델에 전달하기 전에 가릴 수 있다.
• Amazon Bedrock은 자체 모델 서빙 인프라 없이 변동성과 급증이 큰 수요를 처리하고, 지원되는 Anthropic Claude 모델을 작업 특성에 맞게 선택하도록 돕는다. 원문은 지리적 범위가 지정된 교차 리전 추론, 모델에 따라 달라지는 데이터 무보존, 다층 프롬프트 캐싱도 소개하지만, 제공된 본문은 모델 유연성 설명 도중 끝나 세부 내용은 확인할 수 없다.

🧩 주요 포인트

1. 도구 선택 오류와 호출 지연 → 도구 목록도 컨텍스트 예산으로 취급하고, 작업별 노출 범위와 인터페이스 상태 의존성을 줄이는 설계가 중요하다.
2. ClickHouse 스키마 기반 조회와 전용 컨텍스트 핸들러 → 질문마다 기능을 추가하기보다 데이터 모델링과 추론에 필요한 정보 선별에 투자하는 방향으로 개발 부담이 이동한다.
3. Amazon Bedrock의 모델 선택 유연성과 사용자 승인·정보 가림 → 처리 속도·추론 품질·비용을 조정하면서 작업 통제를 유지할 수 있지만, 운영 테스트와 모니터링은 계속 필요하다.

🧠 상세 정리

1. 데모와 대규모 제품 운영 사이의 차이

Postman은 데모용 AI 에이전트를 만드는 일과 4,000만 개발자를 위한 에이전트를 운영하는 일을 서로 다른 엔지니어링 문제로 설명한다. Agent Mode는 API 테스트, 문서화, 탐색, 구현을 AI 중심 방식으로 수행하는 진입점이며, 사용자가 화면을 직접 탐색하지 않아도 애플리케이션에 접근해 작업하도록 설계됐다. 팀은 처음에 모델 품질과 프롬프트 설계가 가장 어려울 것으로 예상했지만, 실제로는 오랜 인터페이스 중심 가정과 넓은 기능 범위, 전문적인 제품 개념을 가진 기존 제품에 에이전트를 통합하는 문제가 더 깊었다. Postman은 11년 동안 사용자가 사이드바를 펼치고 탭을 확인하며 요청을 여는 방식으로 정보를 찾도록 발전해 왔다. 데이터를 바탕으로 추론하는 에이전트를 지원하려면 이러한 사용자의 제품 이해를 API와 컨텍스트 구조 안에서 다시 구현해야 했다.

2. 운영 기반과 사람의 통제

Agent Mode는 Amazon Bedrock을 통해 기반 모델에 접근하며, 전 세계 개발자 커뮤니티에서 발생하는 지연에 민감하고 급격히 증가할 수 있는 수요를 처리한다. Postman은 자체 모델 서빙 인프라를 운영하지 않으면서 모델 선택의 유연성을 확보하고, 처리량과 지리적 처리 범위, 비용을 제어할 수 있다고 설명한다. 운영 아키텍처는 클라이언트 측 도구, 에이전트 오케스트레이션, 목적에 맞게 구성한 컨텍스트, 모델 추론을 결합하며, 애플리케이션 상태를 변경하는 작업에는 사용자 승인을 요구한다. 작업별 도구 제한과 필요한 컨텍스트 선택, 모델에 따라 달라지는 데이터 보존 설정은 의도하지 않은 행동과 불필요한 데이터 노출을 줄이지만, 운영 테스트와 모니터링의 필요성을 없애지는 않는다. 기업 관리자는 Agent Mode의 가드레일 설정에서 Amazon Bedrock Guardrails를 활성화해 개인 식별 정보를 기반 대규모 언어 모델에 도달하기 전에 가릴 수 있다.

3. 도구 증가와 인터페이스 의존성의 한계

초기에는 요청 열기, 단일 필드 수정, 특정 메타데이터 조회처럼 작고 정밀한 도구를 선호했으며, 이는 정확성과 통제에 도움이 됐다. 그러나 실제 작업은 긴 도구 호출 연쇄를 요구했고, 각 단계가 다음 단계 전에 모델로 돌아가야 해서 개별 실행이 빨라도 전체 경험은 느려졌다. Postman 테스트에서는 노출된 도구가 약 40개를 넘자 존재하지 않는 도구 호출, 잘못된 인수 전달, 문맥에 맞지 않는 도구 선택이 증가했으며, 더 크거나 새로운 모델도 이를 완전히 제거하지 못했다. 현재 루트 에이전트는 도구 임베딩의 벡터 데이터베이스를 검색해 170개가 넘는 도구를 약 15개로 좁힌 뒤 컨텍스트가 격리된 하위 에이전트에 전달한다. 또한 요청 수정에 열린 화면 요소가 필요하거나 도구 실행이 새 탭을 여는 등 클라이언트 API의 인터페이스 상태 의존성이 드러나, Postman은 도구와 탭을 분리하는 작업을 진행하고 있다. Native Git은 이 접근을 폭넓게 활용하며, Agent Mode는 이제 열린 탭 없이도 백그라운드에서 요청을 보낼 수 있지만 사용자 승인은 여전히 필요하다.

4. 스키마 기반 조회로 읽기 도구 통합

Postman은 API Catalog처럼 여러 서비스의 가동 시간, 테스트 결과, 엔드포인트 응답 시간을 다루는 제품에서 좁은 조회 기능들을 단일 쿼리 도구로 통합했다. 에이전트는 기반 ClickHouse 테이블의 스키마를 받아 조인과 WHERE 조건을 포함하는 복잡한 쿼리를 생성할 수 있으므로, 분석 질문마다 별도의 도구를 제공할 필요가 줄어든다. 원문의 SQL 예시는 최근 7일의 서비스별 요청 수, 오류 수와 오류율, 평균 지연 및 95번째 백분위 지연을 집계하고, 해당 지연이 100 미만이며 요청 수가 0보다 큰 서비스를 오류율 내림차순으로 정렬한다. 이 방식에서는 개발 과제가 질문별 도구 구현에서 데이터를 한 번 잘 모델링하는 일로 이동한다. 원문은 구조화된 데이터가 있는 경우 스키마를 이해하는 읽기 접근을 제공하면, 팀이 개별 도구로 미리 열거하기 어려운 다양한 질문까지 처리할 수 있다고 주장한다.

5. 기능보다 더 자주 실패를 일으킨 컨텍스트

Postman은 처음에 필요한 도구의 부재가 가장 큰 장애물일 것으로 생각했지만, 실제로는 누락되거나 불완전한 컨텍스트가 기능 부족보다 더 많은 실패를 일으켰다고 설명한다. 여기서 컨텍스트는 사용자가 Postman의 어디에 있는지, 어떤 개체가 활성화돼 있는지, 어떤 상태가 이미 설정됐는지를 에이전트가 이해하는 데 필요한 정보다. 이 정보가 틀리거나 없으면 올바른 도구가 있어도 효과적으로 사용할 수 없었다. Agent Mode는 넓고 얕은 배경 컨텍스트를 자동 수집해 프롬프트용으로 축약하고, 사용자가 선택한 깊고 집중된 컨텍스트는 개체 유형별 전용 핸들러로 처리한다. 기존 인터페이스 데이터 모델은 화면 렌더링과 데이터 전달을 위해 만들어졌으므로 그대로 직렬화해도 유용한 추론 자료가 되지 않았으며, 팀은 반복적인 개선을 통해 각 개체에서 에이전트가 알아야 할 정보를 추려내는 핸들러를 구축했다.

6. 컨텍스트 예산과 정보 잘림 문제

더 많은 개체에 전용 컨텍스트 핸들러가 적용되자, 다음 문제는 정보를 컨텍스트 창에 넣는 과정에서 발생하는 잘림이었다. 요청 설명, OpenAPI 명세, 요청 페이로드처럼 사용자가 생성하는 필드는 길이가 정해져 있지 않아 컨텍스트 공간을 크게 차지할 수 있다. 원문은 모델의 한계에 도달하기 훨씬 전부터 불필요한 정보가 중요한 신호를 밀어낼 수 있으므로, 컨텍스트 창을 희소한 예산으로 취급하고 적극적으로 관리해야 한다고 강조한다. 따라서 개체의 모든 정보를 전달하는 것보다 각 작업에 필요한 내용을 목적에 맞게 정리하는 일이 중요해진다. 팀은 핸들러마다 별도의 잘림과 확장 로직을 구현할 필요를 줄이는 파일시스템 기반 접근을 탐색하고 있으며, 본문은 이를 이미 완성된 운영 방식으로 제시하지 않는다.

7. 도구·공통 지침·RAG 지식 기반의 결합

Agent Mode가 발전하면서 Postman은 서로 다른 문제를 해결하는 클라이언트 측 도구, 일반 에이전트 지침, 지식 기반을 함께 구성해야 한다고 판단했다. 대부분의 도구는 Postman 애플리케이션에서 요청 열기, 설정 수정, 컬렉션 실행, 인증 확인 같은 최종 행동을 수행하며, 웹 검색과 에이전트 루프 관리에는 서버 측 도구도 사용한다. 일반 지침은 에이전트가 얼마나 선제적으로 행동할지, 불확실성을 어떻게 전달할지, 어떤 기본 제품 지식을 가질지 규정한다. 여러 요청 프로토콜과 모의 서버, 모니터, 문서, API Network, 워크스페이스 거버넌스 등 넓은 제품 지식을 모두 정적 프롬프트에 넣기는 어려워 RAG 방식의 지식 기반을 활용한다. 팀은 초기 자료로 Postman Learning Center에서 기능별 간결한 문서를 생성했고, 실행 중에는 질문과 컨텍스트에 맞는 문서를 선택하며 사용자가 모의 서버를 선택하면 관련 문서를 자동으로 주입한다. 이 구조는 기본 상태의 에이전트를 가볍게 유지하면서 필요할 때 상세 지식을 제공하고, 새 기능과 함께 Agent Mode용 문서를 제공할 수 있게 한다.

8. Amazon Bedrock과 Claude 모델 선택

도구, 일반 지침, 지식 기반은 실행 시 기반 모델에 대한 추론 호출로 모이며, Postman 규모에서는 개발자 활동에 따라 급증하는 트래픽을 처리하면서 비용과 지리적 처리 요구를 관리해야 한다. 원문은 Amazon Bedrock의 라우팅, 캐싱, 지리적 처리 제어가 이러한 요구를 지원한다고 설명하고, 모델 유연성, 지리적 범위가 지정된 교차 리전 추론, 모델에 따른 데이터 무보존, 다층 프롬프트 캐싱을 소개한다. 제공된 상세 설명에서는 Amazon Bedrock 모델 추론 API를 통해 지원되는 Anthropic Claude 모델에 접근하고, 작업별로 적합한 모델을 선택할 수 있다는 점을 다룬다. 빠른 모델은 대량의 지연 민감 상호작용에, 큰 모델은 비용보다 품질이 중요한 복잡한 추론에 배정할 수 있으며, 지원 모델 사이의 전환은 주로 새로운 통합 대신 설정 변경으로 처리된다. 다만 제공된 본문은 이 설명 도중 끝나므로, 나머지 기능의 구체적인 설정이나 적용 조건, 성능·비용 효과는 확인할 수 없다.

🧾 핵심 주장 / 시사점

• 도구를 더 많이 제공하는 것이 항상 에이전트의 효과를 높이지는 않는다. Postman 사례에서는 도구 선택 범위와 호출 연쇄가 정확성과 체감 속도를 함께 제한했다.
• 성숙한 제품을 에이전트에 연결하려면 기존 화면용 데이터를 전달하는 수준을 넘어, 사용자가 인터페이스를 통해 얻던 이해를 추론에 적합한 컨텍스트로 재구성해야 한다.
• 스키마 기반 조회와 필요한 지식의 선택적 주입은 질문별 도구와 거대한 정적 프롬프트를 늘리는 부담을 줄이지만, 데이터 모델링과 컨텍스트 예산 관리의 중요성을 높인다.

✅ 액션 아이템

• Postman의 약 40개 도구 노출 시 오류 증가를 참고해, 작업별 도구 선택과 인터페이스 상태 의존성 축소를 검토한다.
• ClickHouse 스키마 기반 조회와 전용 컨텍스트 핸들러의 적용 가능성을 검토하고, 컨텍스트 부족과 예산 관리 문제를 우선 살핀다.
• Amazon Bedrock에서 지원되는 Anthropic Claude 모델의 작업별 적합성을 검토하고, 사용자 승인·정보 가림을 유지하는 운영 테스트와 모니터링을 수행한다.

❓ 열린 질문

• Postman 테스트에서 나타난 약 40개 도구 노출 시 선택 오류 증가는 작업 유형에 따라 어떻게 달라지는가?
• ClickHouse 스키마 기반 조회와 전용 컨텍스트 핸들러를 함께 적용할 때 컨텍스트 부족과 예산 관리 문제는 얼마나 줄어드는가?
• Amazon Bedrock의 지원되는 Anthropic Claude 모델을 작업별로 선택할 때 처리 속도·추론 품질·비용의 균형을 어떤 기준으로 판단하는가?