monday.com이 AI와 일하는 법

1. 왜 이 사례인가

많은 조직이 코딩 에이전트를 IDE 안에서 질문에 답해 주는 페어 프로그래머 정도로만 씁니다. 하지만 monday.com이 AWS ML Blog를 통해 공개한 내부 에이전트 시스템 Sphera AI Teammates는 작업 범위를 그 바깥으로 과감히 넓혔습니다. 에이전트를 조직도에 실재하는 팀원(teammate) 으로 등록하고, Slack·monday·GitHub 인박스에서 티켓을 직접 할당받아 PR을 열게 한 뒤, 자동화된 가드레일(Guardrails)과 원격 샌드박스를 거쳐 머지까지 완결 짓는 구조를 갖췄습니다.

AWS 블로그에 공개된 내부 프로덕션 데이터는 인상적입니다. 엔지니어·PM·애널리스트·프로덕트 디자이너를 아우르는 빌더(Builder) 10명 중 9명이 매달 AI 코딩 도구를 활용하고 있으며(1년 전 약 절반 수준에서 상승), 엔지니어 1인당 PR 처리량은 50% 이상 증가했습니다. 10년 넘게 다듬어진 레거시 코드베이스, 수백 개의 마이크로프론트엔드와 마이크로서비스, 수백 명의 빌더가 일하는 대규모 환경에서 실제로 거둔 성과입니다.

이 사례의 중심축에는 티켓을 직접 가져와 PR을 열고 기능을 배포하는 소프트웨어 엔지니어 에이전트 Atlas, 그리고 그 위에서 20건 중 19건을 자동으로 머지하는 Morphex가 있습니다. L1(개인 어시스턴트)에서 L2(스킬·서브에이전트)를 거쳐 L3(엔드투엔드 멀티에이전트)로 이어지는 성숙도 프레임, SNS→SQS→EKS로 흐르는 이벤트 파이프라인, 벡터 데이터베이스 대신 EFS 파일시스템에 보관하는 MEMORY.md와 업무 일기, Amazon Bedrock 기반의 런타임, 다섯 가지 아키텍처 개편(retrofit), 그리고 신뢰도 점수 기반 자동 머지(confidence-scored automatic merging)가 하나의 유기적인 파이프라인으로 연결되어 있습니다.

2. Problem

monday.com의 환경은 가볍게 실험해보는 신규 그린필드 프로젝트가 아닙니다. AWS 기술 블로그에서 밝히듯, 10년 된 코드베이스, 수백만 명의 유료 사용자, 수백 개의 마이크로프론트엔드와 마이크로서비스, 24시간 온콜과 엄격한 컴플라이언스가 전제된 라이브 서비스입니다. 에이전트가 발행한 PR 하나라도 프로덕션의 안정성을 해쳐서는 안 되는 환경이었습니다.

초기 Atlas는 겉보기에 그럴듯한 수준으로 PR을 생성하는 데 집중했습니다. 하지만 처리하는 작업량이 늘어나자 한계가 곧바로 드러났습니다. 로컬 테스트는 통과했지만 CI 파이프라인에서 실패하는 PR, 담당 팀의 승인이나 맥락이 누락된 PR, 사람이 일일이 검토해야 하는 리뷰 병목, 세션이 끝나면 직전 작업 맥락을 잊어버리는 세션 간 기억 상실 문제가 잇따랐습니다. 벡터 데이터베이스 검색이나 컨텍스트 스터핑(context stuffing) 같은 기법도 이 문제를 해결하지 못했습니다. 결국 2026년 1분기 말에 이르러 시스템의 병목은 코드 작성이 아니라 사람의 코드 리뷰로 옮겨갔습니다. PR Guardrails가 문제 소지가 있는 코드를 사전에 자동으로 걸러냈지만, 최종 머지 단계에서는 여전히 모든 PR이 사람의 승인 큐에 머물러 있었습니다.

확인된 사실: 대규모 레거시 SaaS 환경, 현재 대다수 워크로드가 L2 단계에서 운영되며 엔지니어당 PR 처리량 50% 이상 증가, Atlas 초기 버전의 품질·기억·CI 안정성 격차, 사람 리뷰 단계의 병목, 사람 리뷰에 도달하기 전 PR의 약 1/4을 차단하는 Guardrails 필터.

3. Solution

3.1 Sphera와 팀원 스키마

Sphera는 monday.com의 사내 에이전트 플랫폼입니다. 사내 Teams 페이지를 열면 동료 직원들과 에이전트가 나란히 등록되어 있으며, 에이전트 역시 직무 프로필, 직속 매니저, 담당 업무 스코프, 성과 점수를 부여받습니다. 그중 Atlas는 직무가 Software Engineer로 정의되어 있으며, 백로그에서 티켓을 가져와 PR을 작성하고 기능을 배포하는 역할을 맡습니다. 별도의 IDE 환경 없이 동작하며 사람 동료들과 같은 백로그를 공유합니다.

에이전트마다 Slack, GitHub, monday.com 전반을 관통하는 안정적인 계정 식별자(identity)가 부여되어 있습니다. 따라서 동료 엔지니어는 일반 팀원을 대하듯 에이전트를 멘션하고, 작업을 할당하고, 코드 리뷰를 요청하거나 필요 시 계정을 비활성화할 수 있습니다. 별도의 거버넌스 층을 새로 얹지 않고, monday.com이 이미 구축해 둔 기존 인증, RBAC 권한 체계, 배포 파이프라인을 그대로 활용합니다.

3.2 세 개의 인박스, 하나의 세션

에이전트는 세 가지 1급(first-class) 인박스를 모니터링합니다. Slack @mention, monday.com 업무 아이템 할당, GitHub PR 리뷰 요청입니다. 세 경로로 들어오는 모든 요청은 채널별로 파편화되지 않고 동일한 에이전트 세션, 즉 같은 메모리와 디스크 작업 공간으로 합류합니다. 목적에 따라 에이전트 시스템을 분리하는 대신 하나의 통합 큐와 단일 처리 경로로 묶어낸 구조입니다.

3.3 SNS → SQS → EKS (Builders CoWORK)

외부 인박스에서 발생하는 트리거 이벤트는 Amazon SNS로 먼저 수신되며, 토픽과 라우팅 키를 거쳐 팀별 전용 큐인 per-team SQS로 분기(fan-out)됩니다. EKS 클러스터 위에서 동작하는 SQS 컨슈머인 monday Builders CoWORK가 메시지를 폴링하여 담당 에이전트를 지정하고, 해당 agent runner pod에 작업을 전달합니다.

이러한 메시징 큐 기반 아키텍처는 자동 재시도와 데드 레터 큐(DLQ)를 통한 장애 격리, Amazon Bedrock API 호출 스로틀링 발생 시의 배압(back-pressure) 제어, 신규 버전 배포 전 과거 하루치 이벤트 재실행(replay) 검증, 대규모 동시 분기 처리를 안정적으로 지원합니다. 향후 Claude Agent SDK 등 하부 런타임이 변경되더라도 monday.com 측의 실행 래퍼만 교체하면 기존 하네스(harness) 환경은 그대로 유지할 수 있습니다.

3.4 monday-agent-sdk와 상태 계층

monday-agent-sdk는 Claude Agent SDK를 얇게 감싼 내부 라이브러리입니다. 모델 호출부를 Amazon Bedrock으로 라우팅하고, 미리 준비된 node_modules와 플러그인 캐시를 활용해 콜드 스타트를 단축함으로써 첫 모델 호출 시간을 통상 1초 미만으로 낮춥니다. 아울러 평가(eval) 체계, 플러그인 인터페이스, Slack·monday·GitHub 연동, 사내 리뷰 표준을 통합한 하네스(harness)를 통해 monday.com 고유의 엔지니어링 규칙을 일관되게 주입합니다.

시스템 상태는 영속성과 용도에 따라 세 계층으로 관리됩니다.

POSIX 파일시스템 호환이 필요한 Amazon EFS를 채택한 이유는 분명합니다. Claude Agent SDK와 각종 CLI 도구가 git, npm, 로컬 파일 편집 등 표준 POSIX 파일시스템 인터페이스를 전제로 동작하기 때문입니다. 아울러 실행 포드가 교체되더라도 새로 뜬 EKS 포드가 동일한 EFS 볼륨 경로를 즉시 마운트하여 직전 세션 작업을 중단 없이 이어받을 수 있습니다. Atlas의 작업 메모리는 벡터 DB 대신 읽고 쓰기 쉬운 마크다운 파일 형태로 유지됩니다.

3.5 Amazon Bedrock과 인프라 확장

Amazon Bedrock은 단순한 언어 모델 API 제공처 이상의 엔터프라이즈 운영 기반으로 작동합니다. Application Inference Profiles를 적용해 팀 및 프로젝트 단위로 비용과 사용량을 정밀하게 추적하고, 모델 호출 내역을 단일 감사 추적(audit trail) 로그로 남기며, 특정 리전에서 처리량 제한(throttling)이 발생하면 자동으로 우회하는 크로스 리전 장애 조치(cross-Region failover)를 수행합니다. 외부망 노출 없는 보안 통신을 위해 VPC 내부 트래픽은 AWS PrivateLink로 격리했습니다.

EKS 런타임 계층은 활성 세션당 1개의 독립 포드를 할당하고 EFS 볼륨을 마운트하는 단순한 구조를 유지합니다. 복잡한 서비스 메시나 오케스트레이터를 덧붙이지 않고, Datadog의 활성 세션 메트릭을 기반으로 KEDA(Kubernetes Event-driven Autoscaling)가 포드 수를 오토스케일링합니다. 부하 분산과 내구성은 검증된 EKS, SQS, 캐시 계층이 직접 지탱합니다.

3.6 프로덕션 전환을 이끈 다섯 가지 아키텍처 개편

* 모델 교체 전 평가 체계 선행(Evals before model upgrades): PR 머지율, 리버트율, 무수정 머지율(zero-touch merge) 같은 결정론적 소프트웨어 메트릭에 더해, PR마다 LLM이 채점하는 5대 차원 평가(Intent & Decision, Execution & Artifact, Completeness & Usefulness, Instruction & Boundary, Efficiency)를 하네스에 도입했습니다. 기반 모델이나 프롬프트를 바꾸지 않고 평가 기준(eval)을 정교화하는 것만으로도 에이전트의 산출물 품질 점수가 눈에 띄게 개선되었습니다.

* 벡터 검색 대신 파일 기반 메모리(Memory is a file, not a vector store): 복잡한 임베딩 파이프라인이나 에이전틱 RAG 대신 MEMORY.md와 업무 일기 마크다운 파일을 선택했습니다. 세션 간 기억 유지가 훨씬 명확하고 유지보수하기 쉬워졌습니다.

* 인간 리뷰 전 원격 샌드박스 검증(Remote sandbox before human review): 세션마다 전용 원격 샌드박스를 띄워 에이전트가 만든 PR을 자동 배포하고, 실제 프로덕션 환경의 피처 플래그, 연동 서드파티 서비스, 트래픽 조건을 재현해 기능이 정상 동작함을 확인한 뒤에만 동료 엔지니어에게 리뷰를 요청합니다.

* 엔지니어링 표준을 코드로 검증하는 PR Guardrails: 사내 엔지니어링 표준을 자동 코드 리뷰어로 구현했습니다. MCP(Model Context Protocol)를 통해 각 표준을 관리하는 플랫폼 팀과 동일한 최신 맥락을 참조합니다. 현재 월 수만 건의 PR과 수십만 건의 표준