💻 테크 | AWS Machine Learning
💡 핵심 요약
포스트맨(Postman)은 4천만 개발자를 위한 ‘Agent Mode’를 아마존 베드락(Amazon Bedrock) 기반으로 구축하며, 단순한 프로토타입을 넘어 실제 운영 환경에 AI 에이전트를 성공적으로 안착시킨 사례를 공유합니다. 이 과정에서 포스트맨은 모델 품질이나 프롬프트 설계보다, 기존의 복잡하고 성숙한 제품에 에이전트를 통합하고 ‘Tool Sprawl’을 제어하며 ‘Context’를 핵심 병목으로 관리하는 데 주력했습니다. 이는 AI 에이전트가 현실의 복잡한 비즈니스 문제를 해결하기 위해 모델 자체를 넘어 시스템 아키텍처, 데이터 관리, UX 통합에 대한 깊은 고민이 필요함을 시사합니다.
🔍 심층 분석
20년차 시니어 개발자 관점에서 이 글은 “AI를 실제 프로덕션에 적용할 때 어떤 난관에 부딪히고 어떻게 극복했는가”에 대한 매우 현실적인 가이드라인을 제시합니다. 특히 주목할 부분은 다음과 같습니다.
성숙한 제품에 AI 통합하기의 어려움: 많은 AI 사례가 POC나 신규 서비스 위주로 소개되지만, 포스트맨은 11년 된 복잡한 제품에 에이전트를 통합했습니다. 이는 기존의 UI 중심 사고방식, 방대한 API, 그리고 ‘암묵지’처럼 퍼져있는 제품 지식을 AI 에이전트가 ‘이해’하고 ‘행동’할 수 있도록 재설계하는 고통스러운 과정을 의미합니다. “An agent reasons over data rather than navigating a screen.” 이 한 문장이 기존 시스템 통합의 핵심 난이도를 대변합니다. 단순히 LLM을 호출하는 것을 넘어, 기존 시스템의 데이터와 액션을 LLM이 이해할 수 있는 형태로 ‘번역’하고 ‘표준화’하는 작업이 엄청났을 것입니다. ‘스키마 기반 읽기(schema-based reads)’를 노출했다는 것은 그 기반 작업으로 기존 시스템의 데이터 모델과 API를 명확히 정의하고, 이를 에이전트가 활용할 수 있는 형태로 메타데이터화하는 작업이 수반되었음을 암시합니다.
Tool Sprawl 문제와 높은 추상화 수준의 도구 설계: 에이전트 개발 초기에 흔히 저지르는 실수가 바로 ‘극도로 원자적인(highly atomic) 도구’를 만드는 것입니다. 포스트맨도 이를 경험했고, 각 단계마다 모델과 통신해야 하므로 사용자 경험이 느려지고, 에이전트의 도구 선택 오류도 증가했다는 것은 중요한 교훈입니다. 실제 사용자들은 여러 원자적 작업을 묶어 하나의 큰 작업으로 인식합니다. 따라서 에이전트를 위한 도구는 현실 세계의 복합적인 업무 흐름을 반영하는 높은 추상화 수준의 ‘복합 도구(composite tools)’ 형태로 설계하는 것이 중요합니다. 이는 백엔드 개발에서 마이크로서비스를 너무 잘게 쪼개면 오케스트레이션 비용이 폭증하는 것과 유사한 맥락으로 해석됩니다. 에이전트 아키텍처 설계 시 이 ‘도구 추상화 레벨’에 대한 깊은 고민이 필요함을 일깨웁니다.
“Context is the primary bottleneck” – 패러다임 전환: 이 문장은 이 글의 핵심 인사이트입니다. 많은 개발자가 LLM의 성능이나 프롬프트 엔지니어링에 집중하지만, 포스트맨은 에이전트가 유의미한 행동을 하기 위한 ‘적절한 컨텍스트’를 제공하는 것이 가장 어렵고 중요한 문제임을 깨달았습니다. 이는 단순하게 데이터베이스를 모두 던져주는 것이 아니라, 특정 작업에 필요한 ‘목적에 맞는 컨텍스트(purpose-built context)’를 선별하고, 이를 효율적으로 캐싱하며, 지리적 범위에 맞게 처리하는(cross-Region inference) 전략까지 포함합니다. 결국 에이전트의 지능은 모델의 역량뿐 아니라, 에이전트가 주어진 태스크에 대해 얼마나 정확하고 풍부한 컨텍스트를 이해하고 활용할 수 있는지에 달려있다는 것을 명확히 보여줍니다.
Amazon Bedrock의 전략적 활용: 모델 서빙 인프라 운영 부담을 덜고 모델 선택의 유연성을 확보한 것은 물론, ‘모델 의존적 제로 데이터 보존(model-dependent zero data retention)’, ‘PII 마스킹(Bedrock Guardrails)’ 등 기업 환경에서 필수적인 보안 및 개인정보 보호 기능을 적극 활용했다는 점은 매우 중요합니다. 이는 AI를 프로덕션에 적용할 때 기술적 성능 외에 컴플라이언스, 보안, 거버넌스가 핵심 고려사항임을 강조합니다.
🇰🇷 한국 독자 관점
한국의 많은 기업들도 레거시 시스템 위에 새로운 AI 기능을 얹으려는 시도를 하고 있습니다. 포스트맨의 사례는 이러한 환경에서 매우 실질적인 가이드라인이 될 수 있습니다.
- 기존 시스템 통합의 현실적 접근: 한국 기업들은 거대한 모놀리식 시스템이나 수많은 레거시 API를 가진 경우가 많습니다. ‘성숙한 제품’에 에이전트를 통합하며 겪은 포스트맨의 어려움은 그대로 한국 기업들의 고민과 연결됩니다. AI 에이전트를 위한 ‘스키마 기반 노출’ 작업은 단순히 API 문서화를 넘어, 기존 시스템의 ‘인지 부하’를 줄여주는 ‘AI 친화적 API 디자인’으로 해석하고 적용할 필요가 있습니다.
- 도구 추상화와 사용자 경험: 국내 개발자들이 주로 사용하는 사내 시스템이나 서비스에서 AI 에이전트를 도입한다면, 포스트맨처럼 원자적인 도구 대신 실제 업무 흐름에 맞는 복합적인 ‘미션 지향적’ 도구 설계에 집중해야 합니다. 사용자들은 에이전트가 똑똑하게 ‘한 번에’ 일을 처리해주기를 기대합니다.
- 보안 및 개인정보 보호: 아마존 베드락의 PII 마스킹(Guardrails), 제로 데이터 보존 정책은 한국의 강화된 개인정보보호법(PIPA) 및 정보통신망법(ICNA) 준수에 필수적인 기능입니다. 자체 LLM을 구축하거나 오픈소스 모델을 활용하는 경우에도 이러한 보안 및 컴플라이언스 요구사항을 어떻게 충족시킬지 반드시 고려해야 합니다.
💬 트램의 한마디
AI 에이전트가 거친 프로덕션 환경에서 살아남으려면, ‘컨텍스트’는 연료이고 ‘도구’는 팔다리, ‘인간’은 최종 결정자여야 한다.
🚀 실행 포인트
- [x] 지금 당장 할 수 있는 것: 현재 내가 맡은 서비스 또는 제품에서 AI 에이전트가 가장 먼저 자동화할 수 있는 ‘반복적이고 단순한’ 작업 흐름을 3가지 정도 정의해보고, 이를 수행하기 위해 어떤 정보(컨텍스트)와 기능(도구)이 필요한지 아이디어를 정리해 본다.
- [ ] 이번 주 안에 할 수 있는 것: 기존 API 중 에이전트가 활용할 만한 API 몇 개를 선정하여, 이를 LLM이 이해하기 쉬운 형태로 ‘함수 호출(function calling)’ 스키마나 ‘도구 정의’ 형식으로 바꿔보는 실습을 진행한다. (예: LangChain tools, OpenAI function calling)
- [ ] 한 달 안에 적용할 수 있는 것: 사내 또는 팀 내에서 AI 에이전트 PoC를 진행할 대상 업무를 선정하고, 포스트맨의 사례를 참고하여 ‘Tool Sprawl’을 피하는 복합 도구 설계 및 ‘컨텍스트’ 관리 방안에 대해 아키텍처 토의를 시작한다. 가능하다면 Bedrock과 같은 관리형 서비스의 보안/컴플라이언스 기능을 포함한 POC 계획을 수립한다.
🔗 원문 보기
트램 AI 분석 | gemini-2.5-flash | 2026-10-10 12:24