4000만 사용자 규모에서 에이전트를 운영한다는 것의 의미
포스트맨(Postman)은 11년간 축적된 인터페이스 중심의 제품 구조를 AI 네이티브 방식인 '에이전트 모드(Agent Mode)'로 재해석하는 과정에서, 데모 수준의 프로토타입과 프로덕션 운영 사이의 거대한 간극을 경험했습니다. 팀은 처음에 모델 품질과 프롬프트 설계가 최대 난제일 것으로 예상했으나, 실제로는 성숙한 제품에 에이전트를 통합하며 드러난 구조적 가정들이 더 깊은 문제였습니다. 에이전트는 화면을 탐색하는 것이 아니라 데이터를 추론하며 작동하므로, 사이드바 확장·탭 전환·요청 열기 등 인간이 UI를 통해 습득해 온 '상황 인지' 방식을 에이전트가 이해할 수 있는 형태로 재구성해야 했습니다.
이 글에서는 포스트맨과 AWS가 공동으로 정리한 △툴 스프롤 통제 △스키마 기반 읽기 노출 △컨텍스트를 병목으로 인식하고 해결한 아키텍처 패턴 △아마존 베드록의 지리적 추론·제로 데이터 보존·다중 티어 프롬프트 캐싱 활용법 △책임 있는 AI 가드레일 적용까지, 프로덕션 에이전트를 구축하려는 팀이 참고할 구체적 교훈을 다룹니다.
아마존 베드록 위에서 구현한 프로덕션 아키텍처
포스트맨의 전 세계 개발자 커뮤니티는 변동성이 크고 지연 시간에 민감한 트래픽을 생성하며, 급격한 트래픽 버스트가 발생합니다. 자체 모델 서빙 인프라를 운영하지 않으면서도 모델 선택의 유연성, 처리량 제어, 지리적 처리 위치 지정, 비용 관리를 모두 충족하기 위해 아마존 베드록(Amazon Bedrock)을 추론 계층으로 채택했습니다.
| 베드록 기능 | 포스트맨 적용 효과 |
|---|---|
| 관리형 파운데이션 모델 접근 | 자체 서빙 인프라 없이 모델 유연성 확보 |
| 지리적 범위 교차 리전 추론(Geographically scoped cross-Region inference) | 전 세계 사용자 대상 지연 시간 최적화 및 데이터 상주 요건 충족 |
| 모델 의존적 제로 데이터 보존(Model-dependent zero data retention) | 기업 고객의 데이터 거버넌스 정책 준수 |
| 다중 티어 프롬프트 캐싱(Multi-tier prompt caching) | 반복 컨텍스트에 대한 추론 비용 및 지연 시간 대폭 절감 |
전체 아키텍처는 클라이언트 사이드 툴, 에이전트 오케스트레이션, 목적별 컨텍스트, 베드록 모델 추론 네 계층으로 구성됩니다. 작업별로 툴을 범위 지정(scoping)하고, 애플리케이션 상태를 변경하는 액션에는 반드시 사용자 승인을 요구하는 인간 감독(Human-in-the-loop) 설계가 기본에 깔려 있습니다.
원문 발언: “Human oversight is part of the production design. Agent Mode requires user approval before actions that modify application state.”
또한 아마존 베드록 가드레일(Amazon Bedrock Guardrails)을 통해 개인식별정보(PII)가 하위 LLM에 도달하기 전에 마스킹하며, 엔터프라이즈 관리자는 에이전트 모드의 가드레일 설정에서 이를 활성화할 수 있습니다.
툴 스프롤: 170개 툴을 15개로 좁히는 동적 선택 전략
초기에는 '작고 정밀한' 원자적 툴(요청 열기, 필드 하나 갱신, 메타데이터 조회 등)을 선호했습니다. 이는 초기 반복에서 정확성과 제어에는 유리했으나, 세 가지 치명적 부작용을 낳았습니다.
- 긴 호출 시퀀스: 실제 워크플로는 다단계 툴 호출이 필수적인데, 매 단계마다 모델로 제어가 돌아가며 체감 속도 저하 발생
- 툴 선택 오류 급증: 가시 툴셋이 약 40개를 넘으면 존재하지 않는 툴 호출, 스키마는 유효하나 인자 오류, 문맥상 부적절한 툴 선택 빈도 증가
- 모델 크기로도 미해결: 더 크거나 최신 모델이 오류를 줄이긴 했으나 근본 제거 불가
현재 아키텍처는 루트 에이전트 → 툴 임베딩 벡터 DB 질의 → 상위 15개 툴 선별 → 컨텍스트 격리된 서브 에이전트 위임 흐름으로 동작합니다. 루트 에이전트는 170개 이상 전체 툴 임베딩을 벡터 DB에 저장해 두고, 사용자 요청 임베딩과 유도 검색으로 현재 작업에 관련된 약 15개 툴만 추려 서브 에이전트에 전달합니다. 서브 에이전트는 자신이 받은 툴만 보며 추론하므로 선택 오류가 획기적으로 줄었습니다.
| 전체 툴 | 170 |
| 작업당 노출 툴 | 15 |
| 오류 임계치 | 40 |
더 미묘한 문제는 클라이언트 API가 암묵적으로 UI 상태와 결합돼 있었다는 점입니다. 요청을 수정하는 툴은 특정 요소가 열려 있어야 작동했고, 다른 툴은 새 탭을 여는 부작용을 냈습니다. 에이전트는 데이터를 추론하는 대신 '탭 열기 → 읽기 → 수정' 같은 UI 모방 행동을 강요받았습니다. 포스트맨은 현재 툴을 탭에서 분리(decoupling) 중이며, 네이티브 깃(Native Git) 기능이 이 접근을 광범위하게 활용합니다. 이제 에이전트는 열린 탭 없이 백그라운드에서 요청을 보낼 수 있습니다(사용자 승인은 여전히 필수).
빌더 교훈: “Treat your tool catalog as part of the context budget. Dynamically scope the tools exposed to the model per task, and decouple ‘what the agent can do’ from ‘what the UI happens to have open.’”
스키마 기반 읽기: 툴 개수를 데이터 모델링으로 치환
API 카탈로그(API Catalog) 같은 제품군에서는 서비스 가동 시간, 테스트 결과, 엔드포인트 응답 시간 등 구조화된 데이터가 다수 서비스에 걸쳐 존재합니다. 과거라면 '가동 시간 조회 툴', '테스트 결과 조회 툴', '응답 시간 조회 툴' 식으로 단일 목적 읽기 툴을 양산했겠지만, 포스트맨은 언더라이잉 클릭하우스(ClickHouse) 테이블 스키마를 에이전트에 노출하는 단일 쿼리 툴로 통합했습니다.
에이전트는 스키마를 보고 조인(JOIN)과 WHERE 절을 포함한 복잡한 쿼리를 직접 생성합니다. 그 결과 '질문당 툴 하나' 패턴에서 '데이터 모델링 한 번으로 무한 쿼리 커버리지' 패턴으로 전환됐습니다. 엔지니어링 업무가 툴 제작에서 스키마 설계로 이동하며, 팀이 열거할 수 있는 툴 개수 한계를 넘어 에이전트가 훨씬 다양한 분석 질문에 답할 수 있게 됐습니다.
- 단일 쿼리 툴로 다중 좁은 뷰 대체
- 에이전트가 스키마 인식 하에 임의 쿼리 생성
- 툴 카운트 증가 곡선을 데이터 모델링 품질 곡선으로 치환
빌더 교훈: “Where you have well-structured data, give the agent schema-aware read access to a query engine instead of a proliferation of single-purpose read tools. You trade tool count for data modeling, which produces a better scaling curve.”
컨텍스트가 진짜 병목이었다
포스트맨은 초기에 '빠진 툴'이 최대 걸림돌일 것으로 봤습니다. 그러나 실전에서는 부재하거나 불완전한 컨텍스트가 '빠진 기능'보다 훨씬 많은 실패를 유발했습니다. 여기서 컨텍스트란 △사용자가 포스트맨 내 어디에 있는지 △어떤 엔티티가 활성 상태인지 △이미 확립된 상태가 무엇인지에 대한 에이전트의 이해를 뜻합니다.
컨텍스트가 틀리거나 없으면, 올바른 툴조차 비효율적이거나 위험한 동작을 유발했습니다. 이에 포스트맨은 목적별 컨텍스트(purpose-built context)를 선별 주입하고, 작업 단위로 컨텍스트를 격리하는 아키텍처를 채택했습니다. 이는 앞서 본 서브 에이전트 격리 설계와 맞물려, '모델이 보는 세상'을 작업에 꼭 필요한 최소·정확 집합으로 유지하는 방향으로 작동합니다.
프로덕션 교훈: 책임 있는 AI와 운영 가드레일
기술적 아키텍처 이상으로 중요한 것은 운영 단계의 안전장치입니다. 포스트맨은 세