monday.com, AI 에이전트 트래픽 대응해 API 엣지 재설계

업무 관리 플랫폼 monday.com이 AI 에이전트의 호출 증가에 맞춰 API 입구 역할을 하는 엣지 계층을 재설계했다. 회사가 19일 공개한 공식 기술 블로그에 따르면, 요청 허용 여부를 판단하는 게이트웨이와 실제 데이터를 찾아 응답을 조합하는 GraphQL 라우터를 분리한 것이 핵심이다.

에이전트는 사람의 짧은 지시를 여러 API 요청으로 나눠 수행한다. 가령 기한이 지난 업무를 다음 주로 옮기고 담당자에게 알리려면 목록 조회와 날짜 확인, 항목 수정, 알림 전송이 이어진다. monday.com은 고객의 AI 도구 연동과 자체 에이전트 활용이 늘면서 엣지를 통과하는 주간 요청이 약 10억 건에서 25억 건으로 증가했다고 설명했다. 이 수치는 공개·내부 API를 합친 전체 요청량이며, 모두 AI 에이전트가 만든 트래픽이라는 의미는 아니다.

기존 구성은 Apollo Router와 별도 Node.js 보조 서비스인 코프로세서를 연결하는 방식이었다. 인증과 호출 제한, API 버전 같은 규칙을 확인할 때마다 HTTP로 요청 정보를 주고받으면서 같은 데이터를 반복해 직렬화하고 해석했다는 것이 회사의 진단이다. Apollo 공식 문서도 외부 코프로세서를 호출한 단계에서는 응답을 받을 때까지 라우터가 기다린다고 설명한다.

새 구조에서는 게이트웨이가 인증·권한, 호출 제한, 버전 등을 먼저 검사한다. 통과할 수 없는 요청은 라우터에 도달하기 전에 거절한다. 라우터는 하위 서비스에 질의를 보내고 결과를 합치는 역할에 집중하되, 실행 계획이 있어야 계산할 수 있는 질의 복잡도 한도는 직접 적용한다.

라우터는 Go로 작성된 오픈소스 WunderGraph Cosmo로 교체했고, 게이트웨이도 Go로 구성했다. 회사는 언어 교체만으로 절감 효과를 설명하지 않았다. 파일 업로드를 메모리에 통째로 보관하지 않고 흘려보내는 처리, 응답 버퍼 재사용, 추적 데이터 해석 방식 개선 등을 함께 적용했다고 밝혔다. 운영 환경에 맞춘 자체 Cosmo 포크도 사용한다.

전환에 앞서 실제 읽기 전용 요청 일부를 새 라우터에도 보내 기존 응답과 비교했다. 데이터를 바꾸는 쓰기 요청은 복제하지 않았다. 기존 라우터에도 같은 질의를 두 번 보내 시간값이나 순서처럼 본래 달라질 수 있는 결과를 가려낸 뒤, 검증·오류 형식·빈 값 처리 등의 차이를 수정했다. 이후 계정별 기능 플래그로 트래픽을 단계적으로 옮겼다.

회사 자체 측정에서 엣지가 요청에 추가하는 지연의 99백분위수(p99)는 약 490밀리초에서 44밀리초로, 중앙값은 약 80밀리초에서 9밀리초로 줄었다. 이는 데이터 처리와 네트워크를 포함한 API 전체 응답시간이 아니라 엣지 계층의 추가 지연이다. CPU와 메모리 사용량은 전년보다 각각 92%, 80% 감소했다고 보고했다.

측정 기간은 지표별로 다르다. CPU·메모리는 2025년과 2026년 9월 각각 두 차례 화요일의 운영 구성요소 전체 사용량을 비교했고, 지연은 올해 4~6월 세 차례 수요일과 10월 7일의 같은 시간대를 비교했다. 따라서 수치는 이 회사의 운영 환경과 측정 조건에 한정된다. 이번 사례는 AI 에이전트의 잦은 호출에 대응할 때 모델뿐 아니라 인증과 라우팅 같은 공통 경로의 비용도 함께 살펴야 함을 보여준다.

출처: monday.com 공식 기술 블로그 https://engineering.monday.com/rebuilding-monday-api-edge-for-agents/
Apollo GraphQL 공식 외부 코프로세싱 문서 https://www.apollographql.com/docs/graphos/routing/customization/coprocessor
WunderGraph Cosmo 공식 문서 https://cosmo-docs.wundergraph.com/overview