4천만 개발자를 위한 포스트맨의 AI 에이전트 설계법

한국 독자에게 왜 중요할까?
대규모 개발자를 위한 AI 에이전트 운영 아키텍처 사례는 국내 기업들이 대규모 서비스를 안정적으로 구축하는 데 중요한 시사점을 제공합니다.

단순한 시연용 인공지능(AI)을 만드는 것과 수천만 명이 매일 쓰는 대규모 서비스에 AI 에이전트를 안정적으로 도입하는 것은 완전히 다른 차원의 공학적 문제입니다. 세계적인 API(애플리케이션 프로그래밍 인터페이스, 서로 다른 소프트웨어가 소통할 수 있게 돕는 도구) 개발 플랫폼인 포스트맨은 전 세계 4천만 명의 개발자를 위해 API 테스트, 문서화, 개발을 아우르는 '에이전트 모드'를 선보였습니다. 포스트맨은 아마존웹서비스의 완전관리형 AI 서비스인 아마존 베드록을 기반으로 대규모 환경에서도 안정적인 지능형 에이전트 운영 아키텍처를 구축했습니다.

포스트맨 개발팀은 당초 모델 자체의 성능이나 프롬프트(명령어) 설계가 가장 까다로울 것이라 예상했습니다. 하지만 실제로 맞닥뜨린 가장 큰 장벽은 11년 동안 쌓여온 복잡한 화면 중심의 제품 구조에 AI를 자연스럽게 녹여내는 작업이었습니다. 사람은 사이드바를 펼치고 여러 탭을 오가며 직관적으로 정보를 찾지만, AI 에이전트는 화면을 직접 조작하기보다는 배경에 깔린 데이터 자체를 이해하고 추론해야 하기 때문입니다. 이에 따라 사용자가 화면에서 탭을 열지 않더라도 AI가 백그라운드에서 직접 요청을 처리하도록 화면과 내부 기능 사이의 결합을 끊어내는 구조 개선이 이루어졌습니다.

특히 AI가 직접 실행하는 '도구'의 수가 지나치게 늘어나는 문제가 주요 과제로 떠올랐습니다. 포스트맨의 테스트 결과, AI가 한 번에 인지할 수 있는 도구의 수가 약 40개를 넘어서면 도구 선택 오류가 급증했습니다. 존재하지 않는 기능을 호출하거나 맥락에 맞지 않는 엉뚱한 도구를 고르는 현상이 나타난 것입니다. 이를 해결하기 위해 포스트맨은 170개가 넘는 도구를 모델에 무작정 전부 보여주지 않고, 요청이 들어올 때마다 벡터 데이터베이스를 활용해 필요한 약 15개의 핵심 도구만 동적으로 추려 하위 에이전트에 넘기는 아키텍처를 도입했습니다.

데이터 조회 방식에서도 커다란 구조적 전환을 이뤘습니다. 서비스 가동률이나 테스트 결과처럼 정형화된 데이터를 다룰 때 질문마다 좁은 범위의 도구를 일일이 만들어주는 대신, 데이터베이스 구조를 에이전트에게 인식시키고 단일 쿼리(데이터 조회 명령어) 도구를 부여했습니다. 이를 통해 AI가 스스로 복잡한 분석 쿼리를 직접 작성하게 함으로써 도구의 무분별한 확장을 효과적으로 억제하고 데이터 분석 효율을 끌어올렸습니다. 한편 시스템의 상태를 바꾸는 중요한 동작은 사용자의 명시적인 승인을 거치도록 설계해 안전성도 놓치지 않았습니다.

이러한 포스트맨의 실제 운영 사례는 생성형 AI를 자사 핵심 서비스에 접목하려는 국내 기업들에게 매우 중요한 시사점을 던집니다. AI의 자체 성능에만 의존하기보다는, 화면 조작과 데이터 처리의 분리, 동적인 도구 선별, 데이터베이스 중심의 통합 조회처럼 체계적인 아키텍처를 설계하는 것이 대규모 사용자를 감당하는 안정적인 서비스 구현의 핵심 열쇠임을 보여줍니다.

원문: AWS — How Postman runs Agent Mode for 40 million developers on Amazon Bedrock