monday.com이 기존 제품에 AI 기능을 얹는 방식의 한계를 인정하고 플랫폼을 다시 지은 과정과 다섯 가지 교훈을 정리하고, 국내 기업이 사내 시스템에 같은 질문을 던질 때의 순서를 짚습니다.
Anthropic이 2026년 8월 20일 공개한 「How monday.com transformed its platform into an agent-first product where humans and agents collaborate」를 정리하고, 국내 기업이 사내 시스템에 같은 질문을 던질 때 확인해야 할 것을 덧붙입니다. 작성자는 Aleksandra Todorova입니다.
monday.com은 25만 개 이상의 기업이 업무 관리에 쓰는 협업 플랫폼입니다. 출발점은 팀이 워크플로를 자동화하고 프로젝트를 관리하도록 돕는 시각적 인터페이스였습니다. 기사는 이 회사가 제품을 밑바닥부터 다시 설계해 사람과 에이전트가 협업하는 모델로 옮긴 과정을 다룹니다.
AI 먼지라는 천장
기사에 따르면 재구축은 세 단계로 진행됐습니다. 첫 단계는 기존 플랫폼에 AI 기능을 붙이는 작업이었고, 2025년 5월 사내 AI 월로 정점을 찍었습니다. 4주 동안 전사가 AI 기능이나 제품을 출시하는 데 집중했습니다.
도입률은 좋았고 반응도 뜨거웠지만 곧 천장에 부딪혔습니다. AI Works Platform 제품 부문 VP인 Orly Stern Izhaki는 그 상태를 이렇게 표현합니다. "우리는 AI 먼지를 만들고 있었습니다. 기존 워크플로에 자동화를 흩뿌리기만 하고 그 안에 심어 넣지는 못했습니다." 기능들이 텍스트를 요약하고 정보를 분류하는 데는 도움이 됐지만 지속적인 사용 패턴을 만들지 못했다는 것입니다.
기사에서 가장 자주 인용될 문장도 Izhaki의 것입니다. "AI 기능을 도입하는 것과 AI 회사가 되는 것은 같지 않습니다. 그걸 이해하고 나서 모든 게 달라졌습니다."
최고제품기술책임자 Daniel Lereya는 이 전환을 회사가 내린 가장 중대한 결정 중 하나로 부릅니다. "기존 워크플로에 AI를 더하는 수준이 아니라 플랫폼이 무엇을 해야 하는지를 근본적으로 다시 상상하는 일이었습니다."
2026년 5월 출시 이후 monday 고객이 플랫폼 위 에이전트와 주고받은 상호작용은 500만 건을 넘었다고 기사는 밝힙니다.
동료로 취급되는 에이전트
monday의 각 에이전트는 접근 권한과 제약을 부여받고, 여기에 이름과 아바타가 붙습니다. 동료는 트리거와 멘션으로 에이전트에게 일을 맡깁니다.
이 설계는 의도적이었습니다. monday이 고객사에서 반복적으로 관찰한 실패 패턴이 있었습니다. AI를 쓰고 싶어 하는 기업이 실제 업무가 벌어지는 곳과 나란히 돌아가는 별도의 AI 채팅에서 멈추는 것입니다. 에이전트를 워크플로 안에 직접 넣고 동료를 대하듯 상호작용하게 만들자 추상적 개념이 구체적 대상이 됐다고 기사는 설명합니다.
| 영역 | 에이전트와 담당 업무 |
|---|---|
| IT | Intake & Triage Agent (티켓 분류, 일반 요청 자동 해결, 맥락과 함께 에스컬레이션), Knowledge Agent (지식 공백 탐지, KB 문서 초안), Incident Agent (장애 감지, 워룸 개설, 사후 분석 촉발) |
| HR | Resume Screener (지원서 점수화, 상위 후보 노출, 불합격 통보), Interview Scheduler (일정과 확정 처리), Hiring Coordinator (이해관계자 상태 공유), Feedback Manager (면접 피드백 구조화 수집) |
| 마케팅 | Competitive Intelligence Agent (경쟁사 모니터링, 신호 분류, 주간 브리핑), Battlecard Agent (승인된 신호로 배틀카드 갱신, 영업 통지) |
| 임원실 | Operator Agent (회의 예약, 브리핑 준비, 결정을 추적 과제로 전환), Org Health Agent (매출 리스크와 비용 누수 점검), Strategy Consultant Agent (성장 기회 식별, 실행 계획 생성) |
Claude를 돌리는 네 가지 경로
| 방식 | 설명 |
|---|---|
| monday Agents | 프롬프트로 커스텀 에이전트를 만들고 모델로 Claude를 선택 |
| Bring Your Own Agent | Claude Managed Agents를 플랫폼에 합류시켜 팀 전체가 호출 |
| Pre-built Agents | Agents Store에서 Claude 플러그인을 전문 에이전트로 사용 |
| Claude Coding 연동 | 고객 자체 환경에서 실행되고 결과가 티켓으로 돌아옴 |
기사가 든 종단 예시는 마케팅 캠페인입니다. 담당자와 콘텐츠 리드가 보드 항목 위에서 목표, 대상, 핵심 메시지, 채널을 정리하면 Strategist Agent가 구조화된 브리프로 바꿉니다. Landing Page Builder가 승인된 브리프를 받아 기존 랜딩 페이지의 새 변형을 생성해 항목에 자동으로 붙입니다. Brand Reviewer가 브랜드 가이드라인과 법무 기준에 맞는지 검사하고 사람이 봐야 할 것을 표시합니다. 마케팅 매니저가 내리는 결정은 게시할지 다시 다듬을지 하나입니다.
고객사 사례
Cooke은 1985년 캐나다 뉴브런즈윅에서 시작한 가족 수산업체로, 연어 5,000마리 규모의 양식장 한 곳에서 시작해 16개국에서 운영하는 세계 최대 가족 소유 수산 기업이 됐습니다. 기사에 따르면 Cooke은 프로젝트 수행, 자원 관리, 계약 관리를 Claude와 monday에서 함께 돌립니다. 프로젝트 매니저는 승인된 차터와 요구사항을 초기 프로젝트 계획으로 바꾸고 상태 보고서를 생성하며, 리스크와 이슈를 monday RAID 로그로 흘려보냅니다. 대상 범위는 진행 및 제안 프로젝트 약 200건과 계약 130건입니다.
전략 담당 이사 Patti Stevens의 말이 이 사례를 요약합니다. "monday은 우리가 업데이트해야 하는 플랫폼이었습니다. 지금은 거기서 운영합니다."
monday이 정리한 다섯 가지 교훈
| 교훈 | 내용 |
|---|---|
| 사고 모델이 기술보다 바꾸기 어려움 | 현재 제품을 개선할까라는 질문에서 다시 지을까로 옮기는 데 기술 작업보다 오래 걸림 |
| 전면 전환에서는 소규모 팀이 빠름 | 방향, UX, 기술, 가격, 신뢰 모델이 동시에 움직일 때 결정권 있는 작은 팀이 세부를 놓치지 않음 |
| 도입은 역량만큼 신뢰에 좌우 | 거버넌스, 권한, 투명성, 안정성이 파일럿 이후를 결정 |
| 역량에는 인프라가 따라와야 함 | 라이브 데이터와 구조화된 워크플로가 있을 때 성능이 달라져 monday DB에 투자 |
| 기존 강점 위에 쌓기 | 사람이 팀을 이루는 곳이라는 약속을 새로운 팀원까지 확장 |
국내 기업이 던져야 할 같은 질문
이 사례는 SaaS 벤더의 제품 재설계 이야기입니다. 그래도 사내 시스템을 운영하는 기업에 그대로 옮겨지는 질문이 있습니다. 그룹웨어나 ERP 화면에 AI 버튼을 붙이는 작업이 monday이 말한 AI 먼지와 얼마나 다른지입니다.
| 확인 항목 | 통과 기준 | 실패 신호 |
|---|---|---|
| 사용 지속성 | 도입 3개월 후에도 주간 활성 사용자가 유지됨 | 첫 달 이후 급감 |
| 업무 위치 | 에이전트가 실제 업무 화면 안에 있음 | 별도 챗봇 탭으로 분리 |
| 권한 모델 | 에이전트가 사용자 권한을 그대로 상속 | 관리자 계정 하나로 전부 접근 |
| 데이터 인프라 | 에이전트 호출량을 감당할 조회 성능 확보 | 야간 배치로만 갱신되는 데이터 참조 |
| 실행 경계 | 자동 실행과 사람 승인 대상이 문서로 구분됨 | 승인 없이 쓰기 작업 수행 |
세 번째와 다섯 번째 줄이 국내에서 가장 자주 비어 있습니다. 레거시 그룹웨어와 ERP는 사용자 단위 권한을 API로 노출하지 않는 경우가 많아, 에이전트를 붙이는 순간 관리자 권한 계정 하나로 모든 데이터에 접근하는 구조가 만들어집니다. monday이 세 번째 교훈에서 거버넌스와 권한을 도입의 조건으로 꼽은 이유가 여기 있습니다.
네 번째 줄도 국내 조건에서 가볍지 않습니다. monday은 에이전트 계층과 함께 데이터 인프라에 별도 투자했습니다. 사내 시스템 다수는 사람의 화면 조회 빈도를 기준으로 설계돼 있어, 에이전트가 초 단위로 조회를 반복하면 기존 부하 가정이 무너집니다. 파일럿 단계에서 호출량을 계측하지 않으면 확산 시점에 성능 문제로 되돌아옵니다.
코텍시스는 에이전트를 기존 시스템의 API 위에 얹어 새 인프라 부담을 줄이는 방식을 기본으로 검토하고, 실패나 불확실한 판단에서 사람이 개입하는 승인 지점을 설계 단계에 배치합니다. 위 표의 세 번째와 다섯 번째 항목은 구축 이전 실사 단계에서 확인해야 하는 항목입니다.
출처
코텍시스 AI 인사이트 최신 논문 리뷰
활성값을 보고 가중치를 지키는 AWQ 양자화
MIT 연구진의 AWQ는 활성값 분포를 기준으로 중요한 가중치 1%만 보호해도 저비트 양자화 오류가 크게 줄어든다는 관찰에서 출발해 재학습 없는 4비트 양자화를 구현했고 전용 커널 TinyChat으로 FP16 대비 3배 이상의 추론 속도를 달성했습니다. 온프레미스 sLLM을 소수의 GPU로 서빙해야 하는 기업에게 정확도 손실 없이 메모리와 비용을 동시에 줄이는 사실상의 표준 기법입니다.
Mixtral 8x7B로 읽는 MoE 아키텍처: 13B의 연산으로 70B급 성능 내기
총 47B 파라미터 중 토큰당 13B만 활성화하는 희소 MoE 모델 Mixtral 8x7B는 Llama 2 70B와 GPT-3.5를 대부분의 벤치마크에서 따라잡거나 능가했습니다. 추론 연산량은 소형 모델 수준으로 유지하면서 품질을 끌어올리는 MoE의 실용성을 입증한 사례로, 기업의 자체 호스팅 모델 선정 기준에 직접 영향을 줍니다.
DPO가 바꾼 선호 정렬 학습: 보상 모델 없이 RLHF를 대체하는 방법
DPO는 보상 모델의 재매개변수화를 통해 최적 정책을 닫힌 형태로 유도하고, 선호 데이터에 대한 단순 분류 손실만으로 RLHF와 같은 목적을 달성하는 기법입니다. 강화학습 파이프라인을 운영할 여력이 없는 기업 프로젝트에서 선호 정렬을 현실적인 작업 범위로 만들어 준 논문입니다.
AI 솔루션이 필요하신가요?
cortexys.ai에서 맞춤 AI 개발 서비스를 확인하세요.


![[교육] AI 기업교육 업체를 고를 때 확인해야 할 7가지](https://cortexys-blog-images.s3.ap-northeast-2.amazonaws.com/blog/20260901-vendor-check-structure.png)
![[교육] AI Agent 기업교육은 ChatGPT 활용 교육과 무엇이 다른가](https://cortexys-blog-images.s3.ap-northeast-2.amazonaws.com/blog/20260901-qa-vs-delegation.png)