Postman이 Amazon Bedrock에서 에이전트 모드를 구현하는 방식

Postman의 Agent Mode는 Amazon Bedrock 위에서 작동하지만, 흥미로운 엔지니어링은 모델 자체가 아니라 그 주변 모든 것입니다. Postman과 AWS는 에이전트를 작동하게 만드는 세 가지 연결된 결정 사항을 설명합니다: 각 작업에 표시되는 도구를 좁히기, 전용 경로를 통해 컨텍스트를 준비하기, 그리고 실행 흐름에 인간의 승인을 유지하는 것입니다.

170개 이상의 도구에서 작업당 약 15개로 축소

Postman은 테스트 과정에서 표시되는 도구 세트가 대략 40개를 초과했을 때 도구 선택 오류가 증가한다고 보고했습니다. 해결책은 작업 기반 검색(task-based retrieval)입니다. 전체 170개 이상의 도구 카탈로그를 노출하는 대신, Agent Mode는 관련 기능을 검색하여 주어진 작업에 대해 약 15개로 세트를 좁힌 다음, 이를 컨텍스트가 격리된 서브 에이전트에게 전달합니다. 이 검색 단계는 중요해집니다: 실행하는 에이전트가 어떤 기능들을 받게 할지 결정하기 때문입니다.

구조화된 데이터의 경우, Postman은 모든 질문에 대해 좁은 도구를 만드는 대신 ClickHouse 테이블에 대한 스키마 인식 읽기 액세스(schema-aware read access)도 설명합니다. 이를 통해 구조화된 정보를 조회할 수 있습니다.

컨텍스트를 위한 두 가지 경로

Postman은 누락되거나 불완전한 컨텍스트를 주요 병목 현상으로 식별했습니다. 배경 컨텍스트는 워크스페이스에서 자동으로 수집되어 프롬프트에 들어가기 전에 축소됩니다. 집중된 컨텍스트(focused context)는 사용자 선택이나 언급으로부터 오며, 관련 Postman 객체에 맞게 조정된 핸들러를 통해 전달됩니다. 이 트레이드오프는 명확합니다: 컨텍스트를 줄이는 것은 모델에 도달하는 것을 제한하므로, 워크스페이스 접근이 모든 관련 세부 정보가 프롬프트 준비 과정을 거쳐 살아남는다는 것을 보장하지 않습니다.

추론 라우팅(Inference routing), 캐싱(caching), 그리고 마스킹(redaction)

에이전트 모드는 Bedrock의 추론 API를 통해 Claude 모델에 접근하며, 워크로드를 라우팅하기 위해 크로스 리전(cross-Region) 추론 프로필을 사용합니다. 프롬프트 캐싱은 안정적인 콘텐츠를 위해 1시간 체크포인트를, 가변 컨텍스트를 위해 5분 체크포인트를 사용하는데, 이는 모델에 따라 지원 제한이 있으며 전반적인 보장은 아닙니다. 개인 정보 보호 측면에서는 Postman이 Bedrock Guardrails를 사용하여 PII(개인 식별 정보)가 모델에 도달하기 전에 마스킹하며, 이는 엔터프라이즈 관리자가 설정할 수 있습니다.

승인은 루프 내에서 유지됨

에이전트 모드는 애플리케이션 상태를 수정하는 작업 전에는 사용자 승인을 필요로 하며, 백그라운드 요청 전송도 이를 면제하지 않습니다. 마스킹(Redaction)과 승인(Approval)은 서로 다른 것을 다룹니다: 모델에 전달되는 정보 대 애플리케이션을 통해 이루어지는 변경 사항입니다.

유용한 워크스루, 열린 질문들

이 사례 연구는 Postman이 도구를 범위 지정하고, 컨텍스트를 준비하며, 추론을 라우팅하고, 인간의 제어를 유지하는 방식에 대한 아키텍처 워크스루로 읽는 것이 가장 좋습니다. 이는 측정된 작업 성공률이나 독립적인 안전 평가를 제공하지 않고 메커니즘을 문서화합니다. 커버리지에서 한 가지 명확히 할 점은 '4천만 개발자'라는 헤드라인이 Agent Mode 사용자가 아닌 Postman의 개발자 커뮤니티를 지칭한다는 것입니다.

더 깊이 들어가기

이는 요약된 개요입니다. 출처 인용, 증거 주의사항, 설명된 아키텍처 다이어그램을 포함한 전체 분석은 Agentic Affairs에 있습니다:

👉 Postman이 Amazon Bedrock에서 에이전트 모드를 구조화하는 방법

Agentic Affairs(https://agentic-affairs.com)에 원래 게시됨