에이전트가 기대만큼 일을 못 하면, 보통은 모델 탓부터 합니다. 프롬프트를 다듬고, 도구를 하나둘 더 붙이고, 그래도 안 되면 더 큰 모델로 바꿔보죠.

Postman이 10월 9일 AWS 기술 블로그에 공개한 Agent Mode 운영 기록은 이 순서를 뒤집습니다. 4천만 개발자, 50만 조직, 포춘 500의 98%가 쓰는 11년차 제품 위에서 에이전트를 돌려보니, 가장 아픈 병목은 모델이 아니라 도구 개수와 문맥이었다는 겁니다. 내부 실험에서는 모델에 노출하는 도구가 40개를 넘어가자 도구 선택 오류가 눈에 띄게 늘었고, 지금은 170개가 넘는 도구 중 작업에 필요한 15개 정도만 골라서 쓰는 구조로 바꿨습니다.

40개의 벼랑: 도구가 많아지면 생기는 일

처음 Postman 팀이 한 선택은 상식적이었습니다. 요청 열기, 필드 하나 바꾸기, 메타데이터 가져오기처럼 작고 원자적인 도구를 많이 노출하면 에이전트가 정교하게 움직일 거라고 본 거죠. 결과는 정교함이 아니라 느림이었습니다. 매 단계마다 모델을 왕복하니, 실제 속도가 느려서가 아니라 체감 속도가 느려졌습니다.

그래서 도구를 늘렸더니 이번에는 다른 병이 났습니다. 40개를 넘어가자 이런 실패가 늘었습니다.

① 존재하지 않는 도구 호출
   → 스키마에 없는 이름을 지어내서 부름

② 인자가 틀린 호출
   → 스키마는 맞는데 값이 어긋남

③ 의미는 맞고 맥락은 틀린 호출
   → 그럴듯한 도구를 골랐지만 지금 작업과 무관

모델이 크거나 최신이면 빈도가 줄지만, 사라지지는 않았습니다. 여기서 나온 결론이 이 글의 첫 문장과 이어집니다. 도구는 토큰처럼 예산을 정해서 써야 한다는 것. 무한히 늘리는 자원이 아니라, 개수 자체가 성능을 갉아먹는 자원이라는 겁니다.

170개 중 15개만: 좁혀서 보여주는 구조

지금 Postman이 쓰는 방식은 단순합니다. 전부 보여주지 않고, 필요한 것만 골라서 보여줍니다.

전체 카탈로그: 170개 이상의 도구
   → 루트 에이전트가 벡터 DB(도구 임베딩)에서 작업 관련 후보를 조회
   → 문맥이 격리된 서브 에이전트에게 약 15개만 전달
   → 서브 에이전트는 그 15개만 보고 행동

AWS 글의 Fig3에 나오는 흐름 그대로입니다. 루트가 고르고, 일하는 애는 좁은 시야에서 일합니다. 하네스 엔지니어링 글에서 말한 "모델 주변의 통제 구조"가 바로 이런 겁니다. 똑똑한 모델을 구하는 게 아니라, 멍청한 실수를 못 하게 방을 좁혀주는 쪽입니다.

이 패턴은 성숙한 제품에서 특히 중요합니다. Postman처럼 화면 상태와 도구가 얽힌 제품은, 도구가 인터페이스 상태를 전제로 돌아가기 때문입니다. 탭을 열어놔야 읽을 수 있고, 실행하면 부작용으로 탭이 열리는 식이죠. Postman은 이 결합을 끊는 쪽을 택했습니다. 대표 예가 백그라운드 요청 실행입니다. 탭을 열지 않고 보내고, 상태를 바꾸는 작업 전에는 사람 승인을 받습니다. 네이티브 Git 연동도 이 분리 위에서 돌아갑니다.

문맥은 두 종류다: 넓고 얕게, 좁고 깊게

두 번째 병목은 문맥이었습니다. Postman은 문맥을 두 갈래로 나눠서 다룹니다.

① Background context (넓고 얕게)
   → 자동으로 모으고, 작게 다듬어서 깔아둠

② User-selected context (좁고 깊게)
   → 사용자가 고른 개체마다 전용 핸들러가
     에이전트에게 필요한 형태로 증류

여기서 뼈아픈 실패담이 하나 나옵니다. 화면 렌더링용 객체를 그대로 직렬화해서 넘겼더니, 렌더링에는 좋은 구조가 추론에는 나쁜 구조였다는 겁니다. 화면용과 사유용은 모양이 다릅니다. 그래서 개체마다 "증류기"를 붙였고, 요청 설명·OpenAPI 명세·페이로드처럼 끝없이 긴 필드는 핸들러마다 자르고 펼치는 로직을 따로 두지 않기 위해 파일시스템 기반 방식을 검토하고 있습니다. 잘라내기는 꼼수가 아니라 설계라는 말, 이 대목에서 실감 납니다. 에이전트 메모리 3층 구조 글에서 다룬 층위 나누기와 같은 방향입니다.

읽기 도구 50개보다 스키마 하나

세 번째 패턴은 데이터 조회입니다. 좁은 화면 N개를 각각 보여주는 도구 N개를 두는 대신, 카탈로그 하나로 합치고 에이전트에게 스키마를 줘서 직접 질의하게 했습니다. AWS 글에 나온 ClickHouse 예시가 대표적입니다.

테이블: http_events_summary_1d
컬럼: service_id, total_requests(countMerge),
      total_errors, error_rate_pct,
      avg_latency_ms(avgMerge), p95_latency_ms(quantileMerge 0.95)

에이전트가 직접 작성:
  WHERE bucket_1d >= today() - 7
  GROUP BY service_id
  HAVING p95_latency_ms < 100
  ORDER BY error_rate_pct DESC

질문마다 도구를 추가하는 대신, 데이터 모델링을 한 번 잘해두는 쪽이 이깁니다. 도구 개수를 줄이면서 표현력은 오히려 늘어난 셈입니다. Uber MCP 게이트웨이 글에서 다룬 발견·문맥 문제와 겹쳐 읽으면 이해가 빠릅니다. 도구를 찾는 비용도 문맥 예산의 일부니까요.

Bedrock 위에서 돌리는 법: 라우팅·지리·캐싱

이 사례가 AWS 블로그에 실린 이유도 있습니다. Agent Mode는 Amazon Bedrock 위에서 돌아가는데, "Claude를 쓴다"가 아니라 운영 방식이 포인트입니다.

모델 유연성: converse / InvokeModel API로 고정 모델에 묶이지 않음
  → 빠른 작업은 가벼운 모델, 복잡한 추론은 큰 모델
  → Opus 4.6을 기본값으로 고른 뒤 교체는 설정 변경 수준

Cross-Region 추론:
  → modelId에 지리적 추론 프로파일 지정
  → Geographic: 처리량 + 지역 경계 유지 / Global: 전 세계 라우팅, 약 10% 저렴
  → 단, IAM·SCP가 모든 목적지를 허용해야 함

데이터 보호:
  → 전송·저장 구간 암호화, 프롬프트로 학습하지 않음
  → 지원 모델에 data_retention_mode=none (모델별 확인 필요)

신뢰 장치:
  → 상태 변경 전 사람 승인, Bedrock Guardrails PII 마스킹(기업용)
  → Secret Scanner가 키·토큰을 기기 밖으로 내보내지 않음

Prompt Caching:
  → 안정된 앞부분(시스템·지침·핵심 도구·지식·대화)을 매 턴 재전송
  → 1시간 체크포인트(거의 불변) + 5분 체크포인트(가변층), 1시간이 먼저 와야 함
  → cacheReadInputTokens / cacheWriteInputTokens와 첫 토큰 시간으로 검증

캐싱 대목은 프롬프트 캐싱 비용 글과 바로 이어집니다. 캐시는 붙이는 순간 끝이 아니라, 읽기·쓰기 토큰과 체감 지연으로 검증해야 하는 운영 항목입니다.

AWS 글이 정리한 7가지 교훈도 그대로 옮겨둘 만합니다. 도구에 예산을 두라, 스키마 기반 읽기를 선호하라, 동작을 UI 상태에서 떼어내라, 문맥을 의도적으로 설계하라, 윈도우를 희소 자원으로 다뤄라, 문서와 기능을 함께 배송하라, Bedrock에서 라우팅과 캐싱을 운영하라. 하나같이 "모델을 바꾸기 전에 구조를 보라"는 말입니다.

CodeBridge Mini Lab: 15개·40개·전체 실험

브리핑의 실무 액션을 그대로 실험 명세로 바꿔보세요. Postman을 못 써도, 자기 에이전트에서 오늘 돌릴 수 있습니다.

① 조건 3개 고정:
   - A: 작업 관련 15개만 노출
   - B: 40개 노출
   - C: 전체 노출

② 같은 작업 5개를 각 조건에서 3회씩:
   - 존재하지 않는 도구 호출 횟수
   - 인자 오류율
   - 맥락 오류(그럴듯하지만 무관한 선택) 횟수

③ 함께 재기:
   - 선택 정확도 + 응답 지연(p50·p99) + 토큰 사용량
   - "정확도는 올랐는데 지연이 얼마나 늘었나"까지 한 표에

이 표가 나오면 "도구를 더 붙이자"는 회의가 "어느 15개를 남길까"는 회의로 바뀝니다. 그게 Postman 사례의 진짜 수확입니다.

결론: 에이전트 개선은 뺄셈부터다

한 줄로 정리합니다.

에이전트가 헤맬 때 먼저 볼 건 모델이 아니라 노출 면적이다.

170개 중 15개, 40개의 벼랑, 화면용 객체와 사유용 문맥의 분리, 도구 50개 대신 스키마 하나. 전부 "더 주기"가 아니라 "덜 보여주기"의 기술입니다. 모델 업그레이드는 나중 문제고, 당장 효과를 내는 건 카탈로그 다이어트와 문맥 증류기입니다. 오늘 자기 에이전트의 도구 목록을 세어보세요. 40개를 넘겼다면, Postman이 먼저 밟은 지뢰밭에 들어선 겁니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

도구 고르기, 문맥 격리, 루프와 그래프로 역할을 나누는 구조가 이 글의 170→15 패턴과 바로 이어집니다. 프롬프트를 넘어 실행하고 검증하는 에이전트 구조를 처음부터 설계해보고 싶다면 이 과정부터 보세요.