monday.com의 실전 AI 에이전트

요약

• monday.com은 에이전트를 가상 동료로 등록해 자동 머지 파이프라인을 구축했습니다.
• 병목은 코드 작성에서 리뷰로 옮겨갔고 파일 기반 기억과 기준 검사가 주효했습니다.
• 성공적인 인공지능 도입은 모델 성능보다 엄격한 평가와 업무 도구 연동에 달렸습니다.

동료 목록에 이름을 올린 인공지능 엔지니어

사내 협업 도구의 조직도 페이지를 열었을 때 사람 팀원들 사이에 인공지능 소프트웨어 엔지니어가 나란히 등록되어 있다면 어떤 느낌일까요. 그 인공지능은 별도의 실험용 화면이 아니라 일반 개발자와 똑같은 백로그에서 티켓을 가져가고, 스스로 코드를 작성해 풀 리퀘스트(PR)를 올리며, 기능 출시까지 도맡습니다.

단순히 편집기 안에서 코드를 자동 완성해 주는 조수 수준을 넘어섰습니다. 글로벌 협업 소프트웨어 기업 monday.com이 AWS 머신러닝 블로그를 통해 공개한 사내 에이전트 플랫폼 ‘Sphera’와 ‘AI 동료(AI Teammates)‘의 이야기입니다. monday.com은 수백만 명의 유료 사용자를 보유하고 있으며, 10년 동안 쌓인 거대한 코드베이스와 수백 개의 마이크로서비스, 그리고 화면을 작은 단위로 나눈 구조인 수백 개의 마이크로프런트엔드를 함께 운영하는 대규모 기업입니다. 여기에 수백 명의 빌더가 협업하고, 실제 당번(온콜) 근무가 돌아가며, 엄격한 규정 준수(컴플라이언스) 요건까지 충족해야 합니다. 이런 실제 프로덕션 환경에서 인공지능 엔지니어는 어떻게 동료로 인정받을 수 있었을까요.

이 회사의 엔지니어링 에이전트 ‘Atlas’와 완전 자율 에이전트 ‘Morphex’가 만든 성과는 분명합니다. Morphex가 올린 코드 변경 요청은 20건 중 19건이 모든 품질 검증 관문을 통과해 사람의 개입 없이 머지됩니다. 한 달 동안 웬만한 사람 엔지니어보다 더 많은 PR을 생성하고 처리합니다. 엔지니어와 기획자, 디자이너를 아우르는 빌더(Builder) 10명 중 약 9명이 매달 인공지능 도구를 사용하고 있으며, 엔지니어 1인당 PR 처리량은 50% 이상 늘어났습니다.

하지만 이 결과를 얻기까지의 과정은 순탄하지 않았습니다. 인공지능이 코드를 그럴듯하게 짜내는 것과, 수백만 명이 쓰는 대형 소프트웨어에 문제없이 배포하는 것은 완전히 다른 차원의 문제였기 때문입니다.

코드를 많이 만들어낼수록 깊어지는 병목

초기 버전의 Atlas는 독립된 환경에서 보기 좋은 코드를 생성하는 데 집중했습니다. 그러나 다루는 작업량이 늘어나자마자 거대한 장벽에 부딪혔습니다. 개발자의 로컬 환경에서는 통과하던 코드가 정작 지속적 통합(CI) 파이프라인에 들어가면 줄줄이 깨졌습니다. 특정 팀의 소유권이나 복잡한 맥락을 파악하지 못한 채 만들어진 PR이 사내에 쏟아지기 시작했습니다.

가장 치명적인 문제는 세션이 종료되면 이전 작업 내용을 완전히 잊어버리는 망각 현상이었습니다. 직전 작업에서 겪은 오류나 사내 규칙을 다음 세션에서 기억하지 못하니 같은 실수를 반복했습니다. 널리 쓰이는 벡터 데이터베이스 검색이나 프롬프트에 맥락을 무작정 욱여넣는 방식으로는 이 망각 문제를 해결할 수 없었습니다.

결국 2026년 1분기 말이 되자 시스템의 병목이 코드 생성에서 사람의 코드 리뷰로 이동했습니다. 인공지능이 코드를 순식간에 작성해 올려도, 수백 명의 엔지니어가 그 코드를 일일이 들여다보고 승인하느라 대기열이 끝없이 밀렸습니다. 문제를 해결하려면 모델을 더 똑똑한 것으로 바꾸는 것이 아니라, 코드가 배포되기까지 거치는 엔지니어링 파이프라인 전체를 다시 설계해야 했습니다.

세 개의 받은편지함과 하나의 세션

monday.com은 먼저 인공지능을 시스템 도구가 아닌 정식 팀원으로 다루는 규칙을 세웠습니다. 사내 플랫폼인 Sphera의 팀 페이지에는 사람 직원과 에이전트가 함께 표시됩니다. Atlas는 ‘소프트웨어 엔지니어’라는 직무 프로필을 부여받았고, 담당 매니저와 업무 책임 범위, 정량화된 성과 점수까지 관리됩니다.

Atlas는 별도의 독립된 통합개발환경(IDE)을 쓰지 않습니다. 사람 동료들과 완전히 동일한 작업 백로그에서 일감을 가져옵니다. Slack과 GitHub, monday.com 전반에 걸쳐 영구적인 단일 계정을 발급받았기 때문에, 사람 엔지니어는 새로운 거버넌스 도구를 배울 필요 없이 기존 방식대로 에이전트를 멘션하고 작업을 할당할 수 있습니다. 사람 엔지니어는 다른 팀원에게 하듯 에이전트에게 코드 리뷰를 요청하거나, 필요하면 에이전트를 비활성화할 수도 있습니다. 별도의 거버넌스 구조를 위에 얹는 대신 monday.com의 기존 인증 체계와 역할 기반 접근 제어(RBAC) 권한 모델, 그리고 배포 파이프라인을 그대로 적용받습니다.

업무 접점은 세 가지 창구로 통일되었습니다. Slack 멘션, monday.com 작업 할당, GitHub PR 리뷰 요청입니다. 이 세 가지 경로로 들어온 모든 요청은 서로 다른 파편화된 시스템으로 흩어지지 않고 단 하나의 에이전트 세션으로 모입니다. 동일한 작업 메모리와 디스크 공간을 공유하도록 설계했기 때문에, 메신저에서 나눈 대화 맥락이 코드 리뷰나 작업 티켓 처리로 자연스럽게 이어집니다.

튼튼한 하네스 위에 올린 클라우드 인프라

안정적인 에이전트 구동을 위해 monday.com은 강력한 이벤트 기반 아키텍처를 구축했습니다. 외부에서 발생한 작업 이벤트는 먼저 Amazon SNS로 유입된 뒤, 팀별 Amazon SQS 큐로 분산됩니다. Amazon EKS 클러스터에서 실행되는 사내 워커인 ‘monday Builders CoWORK’가 메시지를 읽어와 담당 에이전트 실행 파드로 안전하게 전달합니다.

메시지 큐 구조는 핵심적인 안전판 역할을 합니다. 실패한 작업에 대한 자동 재시도와 데드 레터 큐(DLQ)를 통한 장애 격리를 제공합니다. 대규모 작업이 몰려 인공지능 API 호출에 제한이 걸릴 때도 메시지 대기열이 완충 작용을 해 시스템 다운을 막아줍니다.

이 메시지 큐 구조는 하나의 이벤트를 여러 곳에 동시에 나눠 보내는 병렬 분배(fan-out)도 가능하게 해 줍니다. 또한 앞으로 Claude Agent SDK 같은 바탕 런타임이 바뀌더라도, monday.com이 만든 얇은 감싸개(래퍼)만 교체하면 기존 하네스 환경은 그대로 유지할 수 있습니다.

파드 내부에서는 자체 라이브러리인 monday-agent-sdk가 동작합니다. 이 SDK는 Claude Agent SDK를 얇게 감싼 형태로, 모델 호출을 Amazon Bedrock으로 전달하고 캐시를 최적화해 첫 모델 호출까지 걸리는 시간을 대개 1초 미만으로 단축시킵니다. monday.com은 이 라이브러리를 외부에 공개하지 않기로 결정했습니다. 진정한 엔지니어링 가치는 얇은 SDK 래퍼가 아니라, 사내 보드와 평가 프레임워크, 권한 모델이 단단하게 얽힌 하네스 환경에 있기 때문입니다.

첫 모델 호출이 이처럼 빠른 이유는 node_modules와 플러그인 캐시를 미리 데워 둔(pre-warmed) 덕분입니다. 여기에 에이전트를 감싸는 작업 틀인 하네스가 평가 프레임워크와 플러그인 인터페이스, Slack·monday.com·GitHub 연동, 그리고 사내 코드 리뷰 기준을 하나로 묶어 monday.com 고유의 엔지니어링 기준을 에이전트에게 일관되게 주입합니다.

함께 쓰이는 Amazon Bedrock은 단순히 인공지능 토큰을 공급하는 창구가 아니라 기업 운영의 기반으로 작동합니다. Application Inference Profiles를 적용해 팀과 프로젝트별로 비용과 사용 용량을 정밀하게 추적하고, 모든 모델 호출을 하나의 감사 기록(audit trail)으로 남깁니다. 만약 특정 AWS 리전에서 호출 제한(스로틀링)이 발생하면 다른 리전으로 작업을 자동으로 넘겨주는 기능(cross-Region failover)도 수행합니다. 아울러 외부 공용 인터넷에 트래픽이 노출되지 않도록 AWS PrivateLink를 통해 회사 전용 가상 네트워크인 VPC 내부에서 안전하게 격리합니다.

상태 관리는 지속성에 따라 3개 층으로 명확히 나눴습니다. 먼저 실시간 상태를 맡는 ElastiCache에는 현재 진행 중인 작업과 실행 위치를 가리키는 커서, 충돌을 막는 분산 잠금, 시스템이 살아 있음을 알리는 하트비트, 그리고 에이전트와 사람이 주고받은 실시간 메시지 기록이 보관됩니다. 세션과 기억을 담당하는 Amazon EFS에는 세션별 작업 디렉터리인 /sessions/<id>/repos, /sessions/<id>/secrets, /sessions/<id>/messages와 에이전트의 영구 기억 파일인 /agents/<id>/MEMORY.md, 날짜별 일지인 diary/YYYY-MM-DD.md가 저장됩니다. 마지막으로 영구 보관용 S3에는 최종 대화 기록과 전체 스냅숏, 생성된 산출물, 평가 보고서가 안전하게 적재됩니다.

여기서 핵심은 세션 파일 시스템으로 Amazon EFS를 채택했다는 점입니다. 에이전트가 git이나 npm 같은 표준 명령어를 쓰려면 표준 POSIX 파일 시스템 인터페이스가 필수적입니다. 작업 도중 특정 파드에 문제가 생겨 다른 파드로 실행이 넘어가더라도, 새 파드가 동일한 EFS 경로를 즉시 마운트하면 작업 흐름이 끊기지 않고 이어집니다.

Amazon EKS 컴퓨팅 환경 역시 매우 단순하고 명확하게 짜여 있습니다. 활성 세션 하나마다 격리된 파드 하나를 배정하고 해당 에이전트의 Amazon EFS 볼륨을 연결하는 구조입니다. 복잡한 서비스 메시나 계층화된 오케스트레이터를 덧붙이지 않고, 이벤트에 따라 파드 수를 자동으로 조절하는 KEDA(Kubernetes Event-driven Autoscaling)가 Datadog에서 집계한 활성 세션 지표를 참조해 파드 수를 늘리거나 줄입니다. 전체 부하 분산과 내구성은 검증된 Amazon EKS, Amazon SQS, 캐시 계층이 직접 지탱하며, 데이터베이스인 Amazon RDS와 민감 정보를 다루는 AWS Secrets Manager도 이 AWS 스택에 함께 포함되어 있습니다.

monday.com은 새 빌드를 프로덕션으로 승격하기 전에 지난 하루 동안 발생한 실제 이벤트를 다시 실행하여 검증합니다. 실제 배포 과정에서는 새 빌드를 격리된 스테이징 풀에 먼저 올린 뒤, PR 머지율이나 가드레일 반려율 등을 기준치와 비교하여 미달 시 배포를 되돌렸을 것입니다.

실운영을 가능하게 만든 다섯 가지 개조

초기 실패를 극복하고 시스템을 안착시키기 위해 monday.com은 아키텍처 전반에 걸쳐 다섯 가지 개조를 단행했습니다.

첫째, 모델 업그레이드보다 평가 체계를 먼저 만들었습니다. PR 머지율, 되돌림(revert) 비율, 무수정 머지율 같은 결정론적 지표와 함께, 대규모 언어 모델이 PR마다 다섯 가지 차원(의도와 결정, 실행과 산출물, 완전성과 유용성, 지시와 경계, 효율성)을 채점하는 평가 시스템을 구축했습니다. 놀랍게도 하부 인공지능 모델이나 프롬프트를 전혀 바꾸지 않고 단지 하네스 안의 평가 기준을 엄격하게 다듬는 것만으로도 다섯 가지 차원의 점수가 모두 향상되었습니다.

둘째, 복잡한 벡터 데이터베이스를 버리고 파일 기반 메모리로 전환했습니다. 초기에는 벡터 검색 기술에 과도하게 투자했지만, 세션 간 연속성을 유지하는 데는 기대에 미치지 못했습니다. monday.com은 벡터 인덱스를 걷어내고, 에이전트마다 사람이 읽을 수 있는 마크다운 형식의 MEMORY.md 파일과 일일 업무 일기를 EFS에 기록하도록 바꿨습니다. 그 결과 세션 간 기억은 훨씬 명확해졌고 유지보수도 쉬워졌습니다.

셋째, 사람에게 리뷰를 요청하기 전에 원격 샌드박스에서 먼저 실행 검증을 거치도록 했습니다. 에이전트가 PR을 올리면 세션 전용 원격 샌드박스가 자동으로 생성되어 코드가 배포됩니다. 실제 프로덕션 기능 플래그와 서드파티 연동 환경에서 실제 트래픽 조건을 가상으로 재현해 통과한 코드만 다음 단계로 넘어가게 만들었습니다. 로컬에서는 돌지만 배포하면 터지는 현상을 근본적으로 차단한 장치입니다.

넷째, 사내 개발 표준을 자동으로 검토하는 ‘PR 가드레일(PR Guardrails)‘을 도입했습니다. 사내 엔지니어링 기준을 자동화된 코드 리뷰어로 변환하고, 모델 컨텍스트 프로토콜(MCP)을 통해 플랫폼 팀들과 동일한 내부 맥락을 참조하게 했습니다. 가드레일은 매달 수만 건의 PR을 검토하고 수십만 건의 기준 점검을 수행합니다. 현재 전체 PR 5건 중 약 1건은 사내 기준을 최소 하나 이상 통과하지 못해 즉시 반려됩니다. 사람이 이 반려 판정을 뒤집는 비율은 한 자릿수 초반에 불과할 정도로 가드레일은 엄격하고 정확합니다.

다섯째, 에이전트의 실시간 작업 상태를 엔지니어들이 매일 확인하는 monday.com 보드에 직접 연동했습니다. 에이전트의 작업 진행 상황, 병목 지점, 담당자 핸드오프 정보가 별도의 관리 화면이 아니라 팀원들의 일상 업무 보드에 그대로 표시됩니다. 팀 소유자 없이 방치되는 고아 PR 문제를 완전히 해결한 결정적인 전환점이었습니다. 팀은 돌아보며 “CoWORK를 monday 보드로 옮기는 일은 나중에 바로잡을 일이 아니라 첫 결정이었어야 했다”고 적었습니다.

실제 업무 환경에서는 각 보드의 상태 열이 세부적인 실행 단계와 맞물려 돌아갔을 것입니다. 대기 중, 샌드박스 검증, 가드레일 심사, 사람 검토 대기, 머지 완료 같은 상태가 API를 통해 실시간으로 갱신되었을 것입니다. 문제가 발생하면 보드의 댓글 창에 즉시 경고가 등록되어 담당 엔지니어가 IDE를 열지 않고도 웹 브라우저에서 바로 병목을 파악할 수 있는 구조였을 것입니다.

수치로 입증된 생산성과 Morphex의 자동 머지

다섯 가지 개조를 거치며 monday.com의 개발 생산성은 가파르게 상승했습니다.

현재 빌더 10명 중 약 9명이 매달 인공지능 코딩 도구를 사용합니다. 1년 전 약 절반에 불과했던 비율이 두 배 가까이 뛴 것입니다. 엔지니어 1인당 PR 처리량은 50% 이상 증가했습니다. 이 비약적인 생산성 향상은 단순 질문에 답하는 보조(L1) 단계를 넘어, 재사용 가능한 스킬과 서브에이전트를 활용하는 L2 단계로 확장되면서 본격화되었습니다. 현재 monday.com 업무의 대부분이 이 L2 환경에서 처리되고 있습니다.

초기 L1 보조 단계에서는 Cursor나 Claude Code 같은 도구를 활용해 개별 작업을 보조받는 형태였습니다. 그보다 더 나아간 L3는 여러 에이전트가 협업해 처음부터 끝까지 전체 프로세스를 완수하는 멀티 에이전트 단계이며, monday.com은 현재 L2에서 L3로 넘어가는 전환기를 지나고 있습니다. 이 흐름 속에서 등장한 Morphex는 monday.com이 선보인 첫 완전 자율 엔지니어링 에이전트입니다.

상위 PR 생성 에이전트들의 성과를 전수 조사한 결과도 인상적입니다. 에이전트가 올린 PR 10건 중 약 3건이 최종 머지됩니다. 그리고 머지된 PR 4건 중 약 3건은 사람이 코드를 단 한 줄도 손대지 않은 완전 무수정 머지였습니다. 머지된 코드의 되돌림 비율은 한 자릿수 초반에 머물러 프로덕션의 안정성을 확고하게 증명했습니다. 사람 리뷰어에게 전달되기 전에 PR 4건 중 약 1건을 가드레일이 미리 걸러내 준 덕분에 엔지니어들의 불필요한 피로도 크게 줄었습니다.

그리고 이 시스템의 최정점에서 완전히 자율적으로 동작하는 엔지니어링 에이전트 Morphex가 탄생했습니다. Morphex가 올린 PR은 20건 중 19건이 엄격한 다단계 관문을 모두 통과해 사람의 개입 없이 자동으로 머지됩니다.

monday.com 에이전트 PR 지표

Morphex의 자동 머지는 검토를 생략해서 얻은 결과가 아닙니다. PR이 열리는 순간 네 가지 신호를 종합해 정밀한 ‘신뢰도 점수’를 계산합니다.

첫째, PR 가드레일의 모든 차단 기준을 100% 무결하게 통과했는가. 둘째, 해당 에이전트 빌드 버전의 최근 평가 점수 추이가 안정적인가. 셋째, ‘에이전트 × 코드 저장소 × 변경 유형’ 조합의 과거 되돌림 비율이 충분히 낮은가. 넷째, 세션별 원격 샌드박스 실행 결과가 완벽한 정상 상태인가.

네 가지 신호가 합산된 점수가 사전에 정한 기준을 넘을 때만 코드가 자동으로 머지됩니다. 합산 점수가 기준에 미치지 못하면 실패한 신호가 표시된 상태로 사람 엔지니어의 리뷰 대기열로 넘어갑니다. 리스크가 높은 코어 시스템 변경은 사람의 승인을 거치게 하고, 정형화된 작업은 즉시 배포하는 차등 제어 구조로 운영되었을 것입니다. monday.com은 되돌림 비율을 한 자릿수 초반으로 엄격하게 통제하면서, 사람 없이 머지되는 PR의 비율을 꾸준히 늘려가는 것을 핵심 목표로 두고 있습니다.

monday.com 자동 머지 판정 흐름

모델 중심에서 하네스 중심으로

monday.com의 사례는 인공지능을 실무에 적용하려는 모든 기업에 분명한 교훈을 줍니다.

많은 조직이 더 최신의 고성능 모델을 도입하면 업무 자동화가 저절로 이루어질 것이라 기대합니다. 하지만 실제 운영 환경에서 드러난 진실은 정반대였습니다. 초기 Atlas의 병목을 뚫어낸 것은 차세대 파운데이션 모델이 아니라, 엄격한 가드레일과 마크다운 기반의 투명한 메모리, 실제 배포 전 상태를 검증하는 원격 샌드박스였습니다.

인공지능 코딩 도구를 개발자 개인의 편집기에 머물게 하면 생산성 향상은 제한적일 수밖에 없습니다. 인공지능에게 명확한 업무 권한과 계정을 부여하고, 사람과 똑같은 협업 창구에서 일감을 받아 기존의 배포 파이프라인 안에서 검증받도록 만들어야 합니다.

“평가는 첫날부터 시스템에 들어가 있었어야 했다”는 monday.com 팀의 반성은 의미심장합니다. 모델을 바꾸기 전에 우리가 원하는 품질 기준이 무엇인지 명확한 수치로 정의하고 통제할 수 있을 때, 비로소 인공지능은 그럴듯한 답변을 내놓는 말상대를 넘어 믿고 일을 맡길 수 있는 진정한 동료로 거듭날 수 있습니다.

---

출처

AWS ML Blog — AI Teammates: how monday.com runs production AI agents on Amazon Bedrock — https://aws.amazon.com/blogs/machine-learning/ai-teammates-how-monday-com-runs-production-ai-agents-on-amazon-bedrock/ — 2026-07-22