monday.com은 AI 에이전트가 늘리는 API 요청에 대응하기 위해 API 엣지를 재설계했다. 회사에 따르면 새 엣지는 1년 전보다 2.5배 많은 주간 요청을 처리하면서 CPU 사용량은 92%, 메모리 사용량은 80% 줄였고, 요청당 지연 시간도 낮췄다.

사용자가 “기한이 지난 작업을 다음 주로 옮기고 담당자에게 알려줘”라고 요청하면 에이전트는 보드와 항목을 찾고 날짜를 확인한 뒤 작업을 수정하고 담당자에게 알리는 등 API를 수십 차례 호출할 수 있다. monday.com의 모든 API 요청은 비즈니스 로직에 도달하기 전에 API 엣지를 거친다. 엣지는 호출자를 확인하고 권한과 요청 한도를 검사한 뒤 GraphQL 쿼리를 데이터를 담당하는 서브그래프로 전달한다. monday.com 팀이 서브그래프를 만들고 공유하는 방식도 소개한 바 있다.

에이전트 트래픽에 맞춘 엣지 재설계

monday.com의 설명에 따르면 2026년 초 기존 엣지는 한계에 가까워졌다. 고객이 AI 도구를 워크스페이스에 연결하고 monday.com의 자체 에이전트가 실제 작업을 시작하면서 엣지를 통과하는 주간 요청은 1년 사이 약 10억 건에서 약 25억 건으로 2.5배 늘었다. 이에 따라 CPU와 메모리 자원을 거듭 늘려야 했고, 엣지 운영이 온콜 업무에서 차지하는 비중도 커졌다. 회사는 엣지가 요청에 더하는 시간을 p99 기준 100밀리초 이하로 낮추는 것을 목표로 삼았다.

기존 엣지는 Apollo Router에 Node.js 코프로세서를 연결한 구조였다. 라우터는 GraphQL 쿼리의 실행 계획을 세우고 처리했지만, 인증·요청 한도·쿼리 복잡도 예산·API 버전 같은 비즈니스 규칙은 별도의 Node.js 서비스인 코프로세서에 있었다. 요청을 처리하는 여러 단계에서 라우터는 HTTP로 코프로세서에 요청을 보내고 응답을 기다려야 했다.

이 구조에서는 각 단계가 요청을 다시 파싱했다. 라우터가 요청 맥락을 직렬화해 HTTP로 보내면 Node.js가 이를 다시 파싱했다. 회사는 JSON 파싱이 CPU를 많이 쓰고 이벤트 루프를 막으며, 여러 차례 왕복하면서 같은 요청을 반복해서 파싱했다고 설명했다. 요청 한도에 걸릴 요청도 라우터의 처리 과정 깊숙한 곳에서야 거부돼, 성공할 수 없는 요청에 자원이 쓰였다. 또 비즈니스 규칙이 라우터의 코프로세서 훅에 얽혀 있어 작은 규칙을 바꾸려 해도 라우터 전체를 고려해야 했다.

새 구조는 두 계층으로 나뉜다. 게이트웨이는 인증, 권한 확인, 요청 한도, 쿼리 복잡도 예산, 버전 관리, 에이전트 감지, 관측 기능을 작은 단계로 처리하며, 검사를 통과하지 못한 요청은 그 자리에서 거부한다. 라우터는 쿼리 계획을 세우고 각 부분을 담당 서브그래프에서 가져와 결과를 합친다. 쿼리 계획을 알아야 비용을 추정할 수 있기 때문에, 라우터는 게이트웨이가 설정한 복잡도 예산만 추가로 적용한다.

현재 라우터는 Go로 작성된 오픈소스 GraphQL 라우터 WunderGraph Cosmo다. monday.com은 속도만을 이유로 선택한 것이 아니라 수정·프로파일링·적응이 쉽고 제작팀과 긴밀히 협력할 수 있다는 점을 들었다. 회사는 WunderGraph 팀과 실제 운영 프로파일, 버그 보고, 수정 아이디어를 검토해 Cosmo에 반영했으며, 트래픽 상황에서 메모리 사용량을 줄이는 변경을 더한 자체 포크도 운영한다.

두 계층을 모두 Go로 옮긴 뒤에는 같은 도구로 요청 경로 전체를 프로파일링하고 수정할 수 있게 됐다. monday.com은 데이터를 메모리에 배치하는 방식과 스트리밍, 버퍼 재사용 등을 직접 제어할 수 있었다고 설명했다. 파일 업로드는 버퍼에 담지 않고 곧바로 전달하며, 응답은 메모리에 한 번만 보관하도록 바꿨다. 페더레이션 추적 데이터(FTV1)는 전송 형식에서 직접 파싱해 라우터 CPU 사용량에서 차지하는 비중을 절반으로 낮췄다.

트래픽을 복제해 차이를 확인

실제 고객을 옮기기 전에는 읽기 전용 쿼리 일부를 새 라우터 Cosmo에 보내 기존 라우터의 응답과 비교했다. 게이트웨이가 기존 라우터 앞에 있었기 때문에 이 작업을 할 수 있었고, 백그라운드에서 진행해 지연 시간에 영향을 주지 않았다. 쓰기 요청은 복제하지 않았으며, 기능 플래그로 어떤 계정의 요청을 어느 정도 복제할지 제어했다.

두 라우터의 응답을 단순 비교하면 타임스탬프나 순서처럼 비결정적인 차이가 잡음으로 섞일 수 있다. monday.com은 트위터의 오픈소스 도구 Diffy로 알려진 방법을 적용했다. 복제한 쿼리를 기존 라우터에도 한 번 더 보내 기존 라우터의 두 응답 사이에서 발생한 차이는 잡음으로 보고, 남은 차이를 실제 차이로 판단했다.

실제 차이는 검증, null 처리, 오류 응답 형식, 쿼리 비용 계산의 예외 사례에서 드러났다. monday.com은 Apollo와 Cosmo가 명세를 다르게 구현한 부분을 고객 이전 전에 게이트웨이나 자체 포크에서 수정했다. 이후 기능 플래그를 이용해 실제 트래픽을 점진적으로 옮겼으며, 계정을 되돌릴 때는 플래그만 바꾸면 됐다. 현재 monday.com의 API 트래픽은 주 20억 건 이상이며 모두 새 엣지를 통과한다. 회사는 전환이 원활했고 고객이 변경할 사항은 없었다고 밝혔다.

지연 시간과 자원 사용량

monday.com이 공개한 수치에 따르면 엣지가 요청에 더하는 p99 시간은 약 490밀리초에서 현재 44밀리초로 줄었다. 중앙값은 약 80밀리초에서 9밀리초로 낮아졌다. 전환 시점에 라우터가 코프로세서와 왕복 통신을 기다리지 않게 되면서 p99가 약 490밀리초에서 약 200밀리초로 떨어졌다. 9월에는 권한 확인을 다시 손봐 추가로 지연을 줄였다. 캐시에서 찾지 못하는 드문 확인은 중앙값 기준 약 130밀리초에서 약 4밀리초가 됐고, p99가 약 150밀리초 더 낮아져 100밀리초 목표 아래로 내려갔다.

CPU 사용량은 1년 전보다 92%, 메모리 사용량은 80% 줄었다. 회사는 현재 트래픽의 10배에서도 새 엣지의 CPU 사용량이 1년 전 기존 엣지보다 적을 것으로 예상한다. 이는 측정 결과가 아니라 회사의 전망이다.

측정은 모든 운영 리전의 공개·내부 GraphQL 요청을 대상으로 했다. 요청 수는 이전 엣지에서는 이전 전 기존 라우터에서, 이후에는 게이트웨이에서 집계했다. CPU와 메모리는 라우터·코프로세서·게이트웨이 등 운영 엣지 구성 요소 전체의 사용량으로, 2025년 9월 23일과 30일, 2026년 9월 15일과 22일 두 해의 화요일 이틀씩을 평균했다. 지연 시간은 같은 요일의 10:00~17:30 UTC 구간을 비교했다. 이전 엣지는 2026년 4월 8일, 4월 22일, 6월 10일 수요일 세 차례, 새 엣지는 2026년 10월 7일을 측정했다. 차트는 해당 지표 기록을 시작한 2026년 3월부터 주간 p99를 보여준다.

monday.com은 에이전트가 자사 API의 주요 사용자가 될 것으로 보고, 사람을 대신해 소프트웨어가 수행하는 작고 빠른 호출에 맞춰 엣지를 최적화하고 있다고 밝혔다. monday.com API를 기반으로 에이전트를 만드는 데 필요한 정보는 API 문서에서 확인할 수 있다.

이번 글을 쓴 미하우 부지악(Michał Budziak)은 monday.com 플랫폼 API 팀의 소프트웨어 엔지니어 테크 리드로 바르샤바에서 근무한다. 분산 시스템을 8년 넘게 구축해 왔으며, 현재 monday.com API를 뒷받침하는 GraphQL 엣지를 담당한다. AGH 과학기술대학교에서 컴퓨터 과학을 공부했다.