Postman, 4천만 개발자용 에이전트 운영법 공개
AWS와 함께 공개한 Bedrock 실전 설계다. 도구 170개를 15개로 좁히고, 병목을 모델 성능이 아닌 컨텍스트로 봤다.
핵심 3줄
- 도구 40개 넘으면 선택 오류 증가, 작업별 동적 축소
- 좁은 뷰 여러 개를 단일 스키마 조회 도구로 통합
- Bedrock 가드레일로 개인정보를 모델 전달 전에 삭제
왜 중요한가
데모용 에이전트와 대규모 운영의 차이를 보여주는 실전 기록이다. 국내 B2B SaaS도 도구 수 늘리기보다 컨텍스트 예산 설계부터 손대야 하며, 상태 변경 전 사용자 승인이 기본값이 될 것으로 보인다.
나는 뭘 하면 될까 · AI 제안
편집 AI(Muse)가 위 사실을 읽고 떠올린 제안입니다. 원문에 없는 해석이며 사실 보도가 아닙니다.
- 개발자
- 에이전트에 노출하는 도구를 작업별로 좁히고 40개 기준을 넘지 않게 한다
- 기획·PM
- 상태 변경 동작에는 사용자 승인 단계를 기본으로 넣어 설계한다
특정 제품 구매·투자 권유가 아닙니다. 결정 전 아래 원문을 확인해 주세요.
배경
Postman이 4천만 개발자 대상 에이전트 모드를 Amazon Bedrock 위에서 돌리는 법을 AWS와 함께 공개했다. 제품 테스트에서 눈에 보이는 도구가 40개를 넘으면 없는 도구 호출·잘못된 인자 같은 선택 오류가 늘었고, 큰 모델도 없애지 못했다. 그래서 루트 에이전트가 도구 임베딩 벡터 데이터베이스에서 170여 개를 15개 안팎으로 좁혀 맥락 격리된 하위 에이전트에 넘긴다. 잘 짜인 데이터는 도구를 늘리지 않고 스키마 인식 조회로 붙였고, Bedrock 가드레일로 개인정보를 지운 뒤 모델에 넘긴다. 앱 상태를 바꾸는 행동은 사용자 승인이 필수다.
원문 보기
새 탭에서 열립니다. 숫자·날짜·고유명사는 원문을 기준으로 확인해 주세요.