monday.com은 소프트웨어 딜리버리를 위한 프로덕션 AI 에이전트를 Amazon Bedrock에서 어떻게 운영하는지 자세히 공개하며, 시장에 “에이전틱 AI”가 데모 환경이 아닌 대규모 엔터프라이즈 SaaS 환경 안에서 실제로 어떤 모습인지에 대한 구체적인 사례를 제시했다.

이 공개 내용은 AWS Machine Learning Blog 게시물과 AWS 뉴스 항목을 통해 나왔기 때문에, 정보의 상당 부분은 벤더가 통제하는 것이다. 그럼에도 주목할 만한 이유는 monday.com이 단순히 모델 사용만이 아니라, 내부 AI 에이전트가 Slack, GitHub, monday 워크플로우와 프로덕션에서 상호작용할 수 있도록 하는 시스템, 큐, 저장 계층, 검토 흐름, 운영 안전장치를 설명하고 있기 때문이다. AI 빌더와 엔터프라이즈 구매자에게 중요한 것은 단일 벤치마크보다 신뢰성, 재실행 가능성, 감사 가능성, 그리고 인간의 감독을 뒷받침하는 아키텍처 선택이다.

AWS가 설명한 monday.com의 구성에 따르면, 회사는 내부 “AI Teammates”를 세 단계로 구성한다. 첫 번째 계층에서는 인간이 AI 코딩 도구를 보조 도구로 사용한다. 두 번째 계층에서는 팀이 반복 작업을 위한 재사용 가능한 스킬과 서브 에이전트를 만든다. 세 번째 계층에서는 에이전트가 엔드투엔드 딜리버리 작업을 맡고 인간이 이를 조율하고 검토한다. AWS는 Sphera라고 불리는 monday.com의 내부 시스템이 에이전트에 시스템 전반에서 안정적인 정체성을 부여해, 인간 팀원처럼 작업을 배정받거나 검토받거나 비활성화될 수 있게 한다고 말한다.

코딩 보조 도구에서 관리형 에이전트 워크플로우로

monday.com 설명에서 가장 흥미로운 부분은 AI 도입을 단일 제품 출시가 아니라 운영상의 진화로 프레임한다는 점이다. AWS에 따르면 monday.com은 빠른 페어 프로그래밍 작업에는 Cursor를, 더 무거운 엔지니어링 작업에는 Claude Code를 사용하며, 이를 회사는 L1 보조 계층으로 분류한다. 그다음에는 재사용 가능한 내부 에이전트인 L2로, 이어서 다중 에이전트 딜리버리인 L3로 이동한다.

이 점이 중요한 이유는 많은 엔터프라이즈 AI 배포가 “코파일럿” 실험과 프로덕션 자동화 사이에서 멈추기 때문이다. monday.com의 사례는 그 간극이 더 나은 모델만으로 해결되지 않음을 시사한다. 작업 배정, 세션 메모리, 도구 사용, 코드 리뷰, 재실행, 실패 처리까지 이해하는 오케스트레이션 계층으로 모델 접근을 감싸야만 해결된다는 것이다.

monday.com의 시스템에서 에이전트는 세 채널 중 하나로 트리거될 수 있다: Slack 멘션, monday 항목 배정, 또는 GitHub 풀 리퀘스트 리뷰 요청이다. AWS는 이 세 경로가 모두 같은 에이전트 세션으로 들어가며, 동일한 메모리와 디스크 작업공간을 공유한다고 말한다. 이 설계는 서로 다른 협업 도구들 사이에서 맥락이 분절되는 것을 피하려는 의도로 보인다.

게시물에서 강조된 핵심 에이전트 Atlas는 티켓을 가져와 풀 리퀘스트를 작성하고 기능을 배포할 수 있는 소프트웨어 엔지니어 에이전트로 설명된다. AWS는 Atlas를 Sphera 내부의 더 넓은 팀 구조의 한 구성원으로 제시하며, 에이전트에는 정의된 역할, 범위, 관리자, 성과 점수가 있다고 말한다. 이 프레이밍은 다소 형식적으로 들릴 수 있지만, monday.com은 이것이 실제로 에이전트가 주소 지정되고 통제되는 운영 스키마의 일부라고 설명한다.

왜 여기서 AWS 스택이 중요한가

monday.com이 공개한 아키텍처가 주목받는 이유 중 하나는 단일 모놀리식 에이전트 플랫폼이 아니기 때문이다. 대신 AWS는 monday.com이 Amazon Bedrock을 통해 모델 접근을 처리하고, 더 넓은 이벤트 및 저장 스택이 운영 작업의 대부분을 맡는 계층형 시스템을 표준 클라우드 서비스 위에 구축했다고 말한다.

게시물에 따르면 외부 트리거는 먼저 Amazon SNS로 들어가고, 이후 Amazon SQS 큐로 팬아웃된다. Amazon EKS에서 실행되는 컨슈머가 메시지를 가져와 어떤 에이전트가 이를 맡아야 하는지 결정한 뒤, 작업을 에이전트 러너 파드에 넘긴다. monday.com은 이 pub/sub와 큐 조합이 재시도, Amazon Bedrock이 속도를 제한할 때의 백프레셔, 패치된 빌드 테스트를 위한 내구성 있는 재실행, 동시 팬아웃을 제공한다고 말한다.

이는 프로덕션에서 AI 에이전트를 계획하는 팀에게 중요한 포인트다. 어려운 부분은 종종 코드나 텍스트를 생성하는 것이 아니다. 버스트성 워크로드를 관리하고, 실패 후 작업을 다시 실행하며, 무슨 일이 일어났는지 추적하고, 의존성이나 모델 엔드포인트가 사용할 수 없게 되었을 때 안전하게 복구하는 일이다. monday.com의 아키텍처는 검증된 지루한 인프라 패턴을 선호하는 쪽에 가깝다.

회사 측은 Claude Agent SDK를 직접 의존하는 대신 이를 래핑한다고도 설명한다. AWS는 monday.com이 그렇게 하는 이유로 세 가지를 제시한다: Amazon Bedrock을 통해 호출 지점에서 공급자 중립성을 유지하는 것, 사전 웜업된 캐시로 콜드 스타트 지연을 줄이는 것, 그리고 평가, 플러그인 조합, 통신, 검토 로직이 위치한 “하니스(harness)” 계층을 통제하는 것이다. 이는 빌더들에게 유용한 신호다. 모델 런타임은 교체 가능할 수 있지만, 컨트롤 플레인과 워크플로우 로직이 지속적인 내부 우위가 된다는 뜻이다.

저장소, 메모리, 그리고 덜 화려한 엔지니어링 선택

이번 공개의 두 번째 교훈은 에이전트 시스템이 여러 종류의 상태를 필요로 하며, 그 상태들이 하나의 데이터베이스에 들어가서는 안 된다는 점이다.

AWS는 monday.com이 현재 작업, 하트비트, 락, 메시지 로그 같은 라이브 상태를 낮은 지연 시간 접근을 위해 Amazon ElastiCache에 저장한다고 말한다. 세션 메모리와 작업 파일은 Amazon EFS에 저장되며, 대화 기록, 아티팩트, 스냅샷, 평가 같은 내구성 있는 기록은 Amazon S3로 간다. Amazon RDS도 사용되는 서비스 목록에 포함되어 있지만, 게시물 발췌본은 그 구체적 역할을 설명하지 않는다. AWS Secrets Manager는 세션별 비밀 정보 처리를 위해 사용된다.

이 구분은 많은 에이전트 프로토타입이 메모리를 단일 추상화로 취급하기 때문에 중요하다. 실제로 코딩 에이전트는 전통적인 분산 시스템에 더 가까운 것이 필요하다: 빠른 휘발성 상태, POSIX 의미론을 기대하는 도구들을 위한 공유 파일 시스템, 그리고 감사와 증거를 위한 장기 저장소다.

AWS는 Claude Agent SDK와 git, npm 같은 일반적인 개발자 도구가 진짜 파일 시스템을 기대하기 때문에, 활성 세션에 객체 스토리지 대신 Amazon EFS를 선택했다고 말한다. 또한 동일한 경로를 마운트하면 세션이 다른 Amazon EKS 파드에서 재개될 수 있다. 이는 실용적인 선택이며, 소프트웨어 에이전트가 종종 인간 개발자와 같은 파일 및 프로세스 가정에 의존한다는 현실을 반영한다.

엔터프라이즈 AI 팀에게 이것은 이 이야기의 더 신빙성 있는 부분 중 하나다. “메모리”라는 마케팅식 표현을 넘어, 지속적인 작업공간, 재개 가능성, 결정론적 도구 환경이 에이전트 신뢰성의 핵심임을 보여준다.

증거, 주장, 그리고 아직 검증되지 않은 것들

출처가 AWS와 AWS Machine Learning Blog이므로, 가장 강한 성과 및 채택 주장은 벤더 보고로 간주해야 한다. AWS는 게시물의 모든 수치가 monday.com의 내부 프로덕션 데이터에서 왔다고 말한다.

이 주장에는 monday.com의 빌더 10명 중 9명이 매달 AI 코딩 도구를 사용하며, 이는 약 6개월 전 절반 수준에서 증가한 것이라는 내용과, 엔지니어 1인당 풀 리퀘스트 처리량이 절반 이상 증가했다는 내용이 포함된다. AWS는 또한 이 L2 계층의 스킬과 서브 에이전트가 현재 monday.com의 주된 운영 영역이라고 말한다.

만약 사실이라면 의미 있는 주장이다. 다만 독자는 उपलब्ध한 증거에 없는 점도 주의해야 한다. 독립적인 방법론도 없고, “빌더”에 대한 원시 분모도 없으며, 대략적인 상대 표현을 넘어선 기준 시점도 없고, 증가한 풀 리퀘스트 처리량이 실제로 사이클 타임 개선, 인시던트 감소, 또는 다른 리뷰 부담으로 이어졌는지에 대한 구분도 없다. 또한 자료는 비용, 결함률, 혹은 인간 리뷰어가 에이전트 출력을 얼마나 자주 거절하거나 다시 작성하는지 수치화하지 않는다.

마찬가지로 AWS는 Amazon Bedrock이 Application Inference Profiles 같은 메커니즘을 통해 monday.com이 비용 추적, 용량 계획, 모델 호출 감사 추적을 한 곳에서 유지하도록 돕는다고 말한다. 이는 플랫폼상의 장점으로 충분히 가능성이 있지만, 여기서의 증거는 비교가 아니라 설명적이다. 대체 배포 경로와의 직접 벤치마크는 없다.

그럼에도 이 글은 많은 AI 사례 연구보다 강하다. 추상적인 변혁 주장보다 시스템 설계에 더 많은 지면을 할애하기 때문이다. 독립 검증의 부재가 아키텍처 신호를 지우지는 않는다. 다만 구매자가 생산성 수치에 얼마나 큰 비중을 둘지 제한할 뿐이다.

이것이 빌더와 엔터프라이즈 구매자에게 의미하는 것

소프트웨어 팀에게 monday.com 사례는 AI 스택에서 실용적인 분리를 시사한다. Cursor와 Claude Code 같은 제품은 개인 개발자의 산출물을 빠르게 개선할 수 있지만, 개인 보조를 넘어 확장하려면 프롬프트 엔지니어링보다 플랫폼 엔지니어링에 훨씬 더 가까운 인프라가 필요하다.

엔터프라이즈 AI 구매자에게 이 사례는 고객 대응 소프트웨어 조직에 AI 에이전트를 배포하는 일이 챗봇 배포보다 더 어려운 요구사항을 수반한다는 점을 상기시킨다. 풀 리퀘스트를 열거나 티켓을 처리하는 에이전트는 지속적인 정체성, 범위가 제한된 권한, 관측 가능성, 롤백 경로, 검토 체크포인트, 그리고 보안 및 컴플라이언스 팀을 만족시킬 수 있을 만큼의 감사 세부 정보를 필요로 한다.

이 이야기는 Amazon Bedrock을 둘러싼 경쟁 구도도 더 분명하게 만든다. AWS는 이 서비스를 단순한 모델 접근이 아니라, 많은 에이전트 전반의 용량, 거버넌스, 비용 회계를 위한 통제 지점으로 포지셔닝하고 있다. 이 메시지는 이미 AWS에 표준화된 기업, 특히 자체 게이트웨이 계층을 처음부터 구축하지 않으면서 모델 선택의 유연성을 원하는 기업에 공감할 가능성이 높다.

동시에 monday.com 자체 설계는 클라우드 서비스만으로 핵심 워크플로우 문제가 해결되지 않음을 보여준다. 차별화 계층은 내부 하니스다: 라우팅, 평가, 플러그인 로직, 검토 정책, 그리고 Slack, GitHub, monday 자체와의 팀별 통합이다. 에이전트 플랫폼을 구매하는 기업은 이 하니스의 어느 부분을 직접 소유할지 결정해야 한다.

다음에 주목할 점

다음으로 볼 신호는 monday.com이나 AWS가 단순한 활동 지표가 아니라 소프트웨어 품질과 운영 비용에 대한 더 강한 증거를 제공하는지 여부다. 풀 리퀘스트 수는 유용하지만, 엔터프라이즈 구매자들은 인시던트 비율, 롤백 빈도, 리뷰 시간, 보안 예외에 대한 데이터를 보고 싶어 할 것이다.

두 번째 신호는 monday.com이 에이전트 자율성을 내부 엔지니어링 워크플로우를 넘어 확장하는지 여부다. 에이전트가 코딩 지원에서 더 넓은 제품 및 운영 작업으로 안전하게 이동할 수 있다면, 구조화된 다중 에이전트 시스템이 일반적인 엔터프라이즈 패턴이 될 수 있다는 주장에 힘이 실릴 것이다.

세 번째로는 AWS가 이 아키텍처를 Amazon Bedrock, Amazon EKS, 그리고 오케스트레이션 도구를 둘러싼 더 제품화된 가이드나 기능으로 전환하는지 살펴볼 가치가 있다. 현재 설명은 여전히 monday.com의 상당한 맞춤형 엔지니어링을 암시한다.

마지막으로, 경쟁사들이 이와 비슷하게 상세한 프로덕션 사례를 공개하는지도 추적할 만하다. 시장에는 AI 에이전트에 대한 수많은 주장이 있지만, 실제로 에이전트가 어떻게 맥락을 유지하고, 실패에서 복구하며, 살아 있는 엔터프라이즈 스택에서 인간 리뷰를 통과하는지 설명하는 사례는 상대적으로 적다.

Creati.ai 관점

여기서의 진짜 뉴스는 monday.com이 코딩에 AI를 사용한다는 사실이 아니다. 많은 회사가 그렇게 한다. 더 중요한 발전은 monday.com이 AI 에이전트를 기존 소프트웨어 딜리버리 시스템 안의 관리형 작업자로 취급하는 프로덕션 운영 모델을 설명하고 있다는 점이다. 즉, 큐, 파일 시스템, 감사 로그, 명시적인 검토 경계를 갖춘 형태다.

이것이 바로 엔터프라이즈 AI 시장이 향하고 있는 방향이다. 승자는 가장 화려한 데모를 가진 팀이 아니라, AI 에이전트를 엔지니어링 매니저, 보안 팀, 재무 팀, 온콜 운영자가 이해할 수 있게 만드는 팀이 될 것이다. AWS가 제시한 monday.com의 아키텍처는, 에이전트 도입이 인프라를 먼저, 지능을 나중에 구축할 때 비로소 신뢰 가능해진다는 점을 시사한다.