monday.com — Sphera AI Teammates와 Amazon Bedrock 위의 프로덕션 에이전트

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 고유의 엔지니어링 규칙을 일관되게 주입합니다.

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

계층	저장소	관리 데이터
Live state	ElastiCache	현재 실행 중인 태스크, 실행 커서(run cursor), 분산 락, 하트비트, 메시지 스트림 로그
Session + memory	EFS	세션별 작업 디렉터리(`/sessions/<id>/repos,secrets,messages`), 에이전트 영구 기억(`/agents/<id>/MEMORY.md`), 일별 업무 일기(`diary/YYYY-MM-DD.md`)
Durable records	S3	최종 실행 기록(transcript), 스냅샷, 생성된 아티팩트, 평가(eval) 결과 보고서

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과 수십만 건의 표준 검사를 처리하고 있으며, 전체 PR의 약 1/5이 최소 1개 이상의 기준을 통과하지 못해 반려됩니다. 이 과정에서 사람이 개입해 결과를 뒤집는 오버라이드(override) 비율은 낮은 한 자릿수(low single digits) 퍼센트에 불과합니다.
monday 보드를 공유 상태로 활용하는 Builders CoWORK: 에이전트의 세부 작업 현황, 블로커, 핸드오프 상태를 엔지니어링 팀이 일상적으로 사용하는 동일한 monday 보드에 기록합니다. 이를 통해 “어느 팀 담당인지 불명확한 미아 PR”이 발생하는 구조적 실패 모드를 업무 협업 도구 자체의 기능으로 해결했습니다.

확인된 사실: 상기 명시된 아키텍처 구성, 다섯 가지 개편 내역, Atlas의 업무 일기 스니펫, SDK 비공개 유지 방침(런타임 래퍼 자체보다 내부 하네스, monday 보드 연동, MCP, 인증 및 배포 통합의 가치가 핵심).

4. Impact

지표	수치	비고
AI 코딩 도구 월간 활용 Builder 비율	약 10명 중 9명(~9/10) (1년 전 약 1/2)	monday.com 내부 프로덕션 측정 데이터
엔지니어 1인당 PR 처리량	50% 이상 증가(+50% 이상)	L2(스킬·서브에이전트) 확산 구간에서 비약적 상승
Guardrails 기준 미달 PR 비율	전체 PR의 약 1/5(~1/5)이 1개 이상 기준 실패	사람의 개입 오버라이드 비율은 낮은 한 자릿수 퍼센트(low single digits)
상위 PR 생성 에이전트 머지율	생성된 PR의 약 3/10(~3/10) 머지	임의 선별(cherry-pick) 없는 전수 집계
무수정 머지 비율 (머지된 PR 중)	약 3/4(~3/4)	사람의 추가 코드 수정 없이 머지
리버트율 (머지된 PR 대상)	낮은 한 자릿수 퍼센트(low single digits)	프로덕션 안정성 유지
Guardrails 사전 필터링 비율	전체 PR의 약 1/4(~1/4)이 사람 리뷰 전 반려	사람의 불필요한 리뷰 공수 절감
Morphex 완전 자동 머지율	20건 중 19건(19/20) PR	모든 검증 게이트 통과 후 사람 개입 없는 머지
Morphex 월간 PR 생성량	대다수 엔지니어보다 많은 수준	고빈도 자율 기여

Morphex가 달성한 20건 중 19건의 자동 머지는 결코 코드 리뷰를 무단 생략한 결과가 아닙니다. Guardrails 검증, 원격 샌드박스 동작 테스트, 정량적 평가 점수, 변경 영역별 과거 리버트 이력 분석을 모두 무결하게 통과한 작업에 한해 사람의 손을 거치지 않고 최종 배포까지 이어지도록 설계한 결실입니다.

신뢰도 점수 기반 자동 머지 (Confidence-scored automatic merging)

에이전트가 PR을 제출하는 즉시 시스템은 네 가지 핵심 품질 신호를 종합해 신뢰도 점수를 산출합니다.

Guardrails 차단(blocking) 필수 표준의 100% 통과 여부
해당 에이전트 빌드 버전의 평가 점수 추이(eval trajectory)
세분화된 (agent × repo × change-class) 단위의 과거 리버트 이력
원격 샌드박스 테스트 통과(Remote sandbox green, 필수조건이나 단독으로는 불충분)

합산된 점수가 사전에 정의된 안전 임계값을 넘어서면 PR은 즉시 자동으로 머지되며, 기준에 미달하면 감점 사유와 함께 사람 엔지니어의 리뷰 큐로 라우팅됩니다. monday.com이 추구하는 핵심 운영 지표는 리버트율을 기존처럼 낮은 한 자릿수 이하로 유지하거나 개선하면서, 사람의 개입 없이 머지되는 에이전트 PR의 비중을 꾸준히 늘려가는 것입니다.

확인된 사실: 표에 정리된 핵심 지표, 4대 평가 신호 체계, L2에서 L3로의 운영 전이. SDK는 오픈소스로 공개하지 않음(기본 런타임 래퍼는 단순하며, 실제 엔지니어링 가치는 하네스, 사내 보드 통합, MCP 인터페이스, 권한 체계 및 배포 파이프라인의 결합에 있음).

5. Insight

L1→L2→L3는 단순한 기술 도입 순서가 아니라 조직 운영 모델의 전환입니다. 실제 엔지니어당 PR 처리량 50% 향상이라는 가시적인 생산성 혁신은 L2(재사용 가능한 엔지니어링 스킬과 서브에이전트) 단계에서 본격화되었습니다. L3 단계의 자율 에이전트 Morphex 역시 사람을 무조건 배제하는 것이 아니라, 엄격한 신뢰도 점수 기준을 통과한 조건부 케이스에 한해 점진적으로 사람의 개입을 줄여가는 방식으로 안착했습니다.

복잡한 벡터 검색보다 단순하고 투명한 파일 시스템이 효과적이었습니다. 다음 세션으로 넘어가면 이전 맥락을 유실하던 문제는 무거운 벡터 DB 검색이나 RAG보다 EFS 위의 MEMORY.md와 업무 일기 마크다운 파일로 명료하게 해결되었습니다. monday.com 팀 스스로도 초기에 벡터 기반 솔루션에 과도하게 투자했다가 이를 다시 걷어냈다고 솔직하게 회고합니다.

가드레일의 역할은 인간 리뷰의 전면 대체가 아닌 선행 여과입니다. 전체 PR의 약 1/4을 사람에게 전달되기 전에 기계적으로 걸러내어 최종 머지된 코드의 리버트율을 한 자릿수 초반으로 낮춰 두었기에, 비로소 다음 단계인 신뢰도 기반 자동 머지를 도입할 여력이 생겼습니다.

협업 도구의 업무 보드가 곧 시스템의 상태 저장소(state store)가 됩니다. CoWORK 시스템의 작업 상태를 별도의 독립 관리용 대시보드가 아니라 사내 엔지니어들이 상시 확인하는 monday 보드 위에 직접 구성한 점이 주효했습니다. 엔지니어링 팀은 이를 뒤늦게 고친 땜질 처방이 아니라 처음부터 선택했어야 할 가장 중요한 아키텍처적 결정이었다고 평가합니다.

평가 체계(Eval) 구축은 프로젝트 성숙기가 아닌 첫날(Day 1)부터 시작해야 합니다. Atlas의 5대 품질 지표 점수는 모델 자체를 업그레이드하기 전, 하네스 내부의 정량적 평가 기준을 정립하는 것만으로도 즉각적인 개선을 보였습니다.

요약하자면, 엔터프라이즈 환경에서 코딩 에이전트를 성공적으로 스케일링하는 열쇠는 더 뛰어난 파운데이션 모델의 선택에만 머물지 않습니다. 안정적인 이벤트 큐, 파일 기반 메모리, 자동화된 표준 검사 가드레일, 공유 보드 상태 머신, 그리고 정량적 신뢰도 기반 머지 파이프라인이 단일 하네스 체계 안에서 빈틈없이 맞물려 돌아갈 때 비로소 지속 가능한 운영이 가능해집니다.

6. 원문에 없는 추정 (구현 가설)

6.1 평가 게이트를 프로모션 파이프라인과 결합한 배포 자동화

근거: AWS 공식 블로그에서는 머지율, 리버트율, 무수정 머지율 등 결정론적 지표와 LLM 기반 5대 차원 평가를 하네스에 통합했으며, 모델이나 프롬프트 수정 없이 평가 기준을 보정하는 것만으로도 Atlas의 점수가 개선되었다고 설명합니다. 아울러 신규 빌드 프로모션 직전 “과거 하루치 이벤트의 재실행(replay)” 절차를 거친다고 명시하고 있습니다.

신규 하네스 빌드는 전체 운영 환경에 곧바로 적용되지 않고 스테이징 에이전트 풀(staging agent pool)에 먼저 격리 배포될 가능성이 높습니다. 그다음 재생 전용 큐를 통해 전날 실제 프로덕션에서 발생했던 Amazon SNS 이벤트를 동일하게 재실행하며, 이때 기록되는 PR 머지율, Guardrails 반려율, 5차원 품질 점수 분포를 기준선(baseline)과 자동으로 비교 분석할 것입니다. 결정론적 안정성 지표 중 하나라도 허용 오차를 벗어나면 배포는 즉시 롤백되며, LLM 평가의 경우 시스템 제약 준수를 감시하는 “Instruction & Boundary” 같은 필수 차원에 더 엄격한 가중치와 차단 임계값을 부여할 것으로 추정됩니다. 새로운 파운데이션 모델로의 업그레이드 역시 이러한 다면 평가 게이트를 완전히 통과한 뒤에만 Application Inference Profile 설정을 교체하도록 강제함으로써, 초기 단계에서 발생했던 “단편적으로는 멀쩡해 보이지만 대량 작업 시 결함이 드러나는 현상”을 원천 차단하도록 구현되었을 것입니다.

6.2 일관된 에이전트 식별자와 RBAC 권한 모델의 다중 채널 적용

근거: 원문에서는 각 에이전트가 Slack, GitHub, monday.com 전반에 걸쳐 일반 팀원과 동일한 실제 사용자(real user) 계정 식별자와 RBAC 권한을 부여받는다고 설명합니다. 아울러 세 개의 인박스에서 수신된 작업과 Guardrails 검증, CoWORK 오케스트레이션이 모두 단일 세션으로 합류한다고 밝힙니다.

구현 측면에서 볼 때 각 에이전트 ID는 독립된 단순 깃허브 봇 계정이 아니라 monday.com SSO 체계와 연동된 사내 서비스 계정(service principal)으로 프로비저닝되었을 공산이 큽니다. 그래야만 리포지토리 쓰기 권한, 브랜치 보호 규칙 우회 예외 처리, monday 보드의 컬럼 상태 수정 등이 사람 엔지니어와 동일한 중앙 보안 정책 엔진의 통제를 받기 때문입니다. Slack의 @Atlas 호출과 monday 보드의 업무 할당이 동일한 내부 session-id로 매핑되도록 이벤트 라우팅 키를 (agent-id, inbox-type) 형태로 표준화하고, 만약 특정 에이전트의 오동작이 감지되면 사내 Teams 관리 화면의 스위치 하나로 연관된 SNS 구독, SQS 컨슈머, 런너 포드를 일괄 격리 및 정지시키는 킬스위치를 마련했을 것입니다. “특정 시점에 에이전트가 Bedrock으로 어떤 프롬프트와 페이로드를 전달했는가”라는 보안 감사 질의에는 Bedrock의 감사 로그, EFS 내 /sessions/<id>/messages 파일, 그리고 S3에 영구 저장된 트랜스크립트 로그를 상호 교차 검증하는 삼각 감사 파이프라인으로 대응하도록 설계되었을 것으로 보입니다.

6.3 세분화된 변경 단위별(agent × repo × change-class) 차등 자동 머지 임계값

근거: 신뢰도 점수 산출의 핵심 축 중 하나로 (agent × repo × change-class) 단위의 과거 리버트 이력이 언급되며, 단순 패키지 의존성 버전 업데이트와 대규모 모놀리스 코드 마이그레이션은 완전히 다른 위험도를 갖는다고 원문에 명시되어 있습니다. 또한 Morphex의 19/20 자동 머지율은 특정 안정 작업군에 적용되는 기준선으로 제시됩니다.

작업의 성격(change-class)은 PR 라벨, Guardrails가 적용한 룰셋 카테고리, 변경된 코드 라인 수와 수정 파일 경로(diff stat)를 조합해 파이프라인에서 자동으로 분류될 것입니다. 그리고 해당 카테고리별로 최근 N개 PR 윈도우 내의 롤링 리버트율이 허용 임계값 미만을 유지하고 있을 때에만 자동 머지 대상군으로 승격시키는 로직이 작동할 것으로 추정됩니다. 예컨대 위험도가 높은 모놀리스 마이그레이션은 샌드박스 테스트가 통과하고 Guardrails를 통과했더라도 에이전트의 최근 평가 점수 추이가 완벽하지 않다면 사람 엔지니어의 수동 검토 큐로 즉시 넘기고, 반대로 과거 장애 이력이 거의 없는 단순 의존성 업데이트는 안전 임계값을 낮춰 신속하게 머지할 것입니다. 아울러 자동 머지 판단의 근거가 된 4대 품질 신호 스냅샷 데이터를 S3 평가 보고서에 버전과 함께 영구 박제하고 PR 코멘트로 기록해 둠으로써, 전체 리버트율을 낮은 한 자릿수 이하로 통제하면서 자동 머지 비율을 지속적으로 높여가는 피드백 루프를 운용할 것으로 추론됩니다.

6.4 monday 보드를 런타임 상태 머신으로 동기화하는 관제 구조

근거: Builders CoWORK 플랫폼은 에이전트의 세부 작업 항목, 진행 상태, 의존성 블로커, 작업 핸드오프 이력을 개발팀과 동일한 monday 보드에서 직접 관리한다고 설명합니다. 또한 세 인박스로부터 유입된 작업 요청이 단일 세션으로 합류합니다.

보드의 상태 컬럼은 queued → sandbox → guardrails → awaiting-human → merged와 같이 명확한 상태 머신 단계로 정의되어 있으며, 에이전트 런너 포드는 작업 단계가 전이될 때마다 사내 monday API를 호출해 해당 컬럼 값을 실시간으로 갱신할 것입니다. Slack 대화 스레드 링크, GitHub PR 주소, 원격 샌드박스 프리뷰 URL을 보드 아이템의 하위 항목(subitem)으로 자동 첨부하면, 관리자나 엔지니어는 IDE를 열지 않고도 웹 브라우저에서 작업의 병목 지점을 즉시 파악할 수 있습니다. 특히 Atlas의 업무 일기에서 나타났듯이 “PR 발행 전 패키지 레지스트리 업데이트 선행 필요”와 같은 작업 블로커가 발견되면, 이를 업무 일기(diary) → MEMORY.md → monday 보드 블로커 코멘트 순으로 단계적 에스컬레이션하여 다음 실행 세션의 콜드 스타트 시점에 반영하도록 구현했을 것입니다. 최초 인입된 SNS 이벤트 ID를 monday 보드 아이템 식별자와 1:1로 바인딩해 두면, 시스템 장애 발생 시 이벤트 재실행 및 감사 추적이 한층 수월해집니다.

6.5 프로덕션 안전성 보장을 위한 SNS/SQS 이벤트 재실행 릴리스 게이트

근거: 원문에서는 패치된 새 빌드를 상용 배포하기 전에 마지막 24시간 동안 수집된 실제 프로덕션 이벤트를 재실행하여 검증한다고 밝힙니다. 또한 팀별 SQS 큐, DLQ, 배압 제어 메커니즘이 인프라의 핵심 축으로 설명됩니다.

이벤트 재실행 절차는 라이브 운영 트래픽을 무작정 복제해 흘려보내는 방식이 아니라, S3에 영구 저장된 트랜스크립트와 이벤트 로그에서 중복 제거 키(dedupe key)를 기반으로 과거 24시간 치 메시지를 추출하여 스테이징 환경으로 인입시키는 배치 파이프라인으로 구성되었을 것입니다. 재실행 결과로 측정된 PR 머지 성공률, 리버트 발생률, Guardrails 실패율의 분포가 실제 프로덕션의 통계적 오차 범위(ε) 내에 머무를 때에만 신규 하네스 빌드의 시맨틱 버전을 상용 프로모션할 것으로 추정됩니다. Bedrock API의 호출량 한도를 시험하는 모의 스로틀링 재실행 단계에서는 SQS의 가시성 타임아웃(visibility timeout)을 동적으로 연장하고 KEDA를 통한 포드 스케일아웃을 사전에 예약하여 인프라의 배압 저항력을 검증할 것입니다. 재실행 중 최종 처리 실패로 분류되어 DLQ로 빠진 메시지는 monday 보드에 즉시 장애 인시던트 티켓으로 발행되어 온콜 엔지니어가 런너 포드의 컨테이너 이미지 롤백을 신속히 수행하도록 유도할 것입니다. 이러한 검증 체계는 “평가 시스템의 첫날 구축(Eval day one)” 철학을 단순한 애플리케이션 비즈니스 로직뿐만 아니라 클라우드 인프라 및 환경 설정(config) 변경 작업 전반으로 일관되게 확장하는 안전장치로 작동합니다.

7. 출처

AWS ML Blog — AI Teammates: how monday.com runs production AI agents on Amazon Bedrock (Claudio Mazzoni, Erez Drutin, Moran Zilberstein, Netanel Abergel, Ofek Dayan)
https://aws.amazon.com/blogs/machine-learning/ai-teammates-how-monday-com-runs-production-ai-agents-on-amazon-bedrock/
게시: 2026-07-22 · 확인일(본 초안): 2026-09-22