"AI PM 서비스"라는 한 단어 아래에는 성격이 전혀 다른 시장 몇 개가 뒤섞여 있다. 협업 보드와 문서에서 출발한 워크스페이스, 일정 배치를 자동화하는 실행 도구, 앱과 앱을 잇는 자동화 플랫폼, 그리고 프로젝트마다 담당자를 붙이는 대화형·파견형 접근까지. 몇 년 전이라면 이들을 "AI가 들어있느냐"로 갈랐겠지만, 2026년에는 그 질문이 더 이상 유효하지 않다. Asana도, Notion도, Motion도, Zapier도, Make도 이미 자기 제품 안에 스스로 판단하고 행동하는 에이전트를 얹었다. 요약·초안만 거들던 시절은 지났다.
그래서 이 글은 "누가 에이전트를 가졌나"가 아니라 다른 질문으로 지형도를 다시 그린다. 그 에이전트는 어디에 살고 있으며, 그것을 조립하고 관리하는 부담은 누가 지는가. 이 축 위에 서면 각 서비스의 위치가 선명해지고, 온틀(ONTLE)의 파견형 포지션이 어디에 있는지도 과장 없이 드러난다.
Asana, Monday.com, ClickUp, Jira, Notion, Linear가 이 그룹이다. 원래는 팀이 함께 보는 보드·문서·티켓 시스템이었고, 지금도 그 골격은 같다. 달라진 건 그 위에 얹힌 AI의 성격이다.
Asana는 AI Studio라는 노코드 빌더를 통해, 들어온 요청을 분류하고 담당자에게 배정하고 상태를 갱신하고 필요하면 사람에게 에스컬레이션하는 "AI 팀원"을 설계해 배치할 수 있게 했다. Notion은 2025년 9월 3.0 발표에서 에이전트를 공식화했다. 이 에이전트는 문서를 만들고 데이터베이스를 짓고 여러 단계에 걸친 작업을 수행한다. 즉 이 그룹의 AI는 더 이상 "요약해주는 조수"에 머물지 않는다. 워크스페이스 안에서 실제로 카드를 만들고 옮기고 배정한다.
다만 위치는 분명하다. 그 에이전트는 팀이 채택하고 유지하는 워크스페이스 위에서 동작한다. 여기서 한 가지는 구분해야 한다. 같은 그룹 안에서도 기본 에이전트와 설정형 에이전트는 성격이 다르다. Notion의 기본 에이전트는 사용자의 기존 권한을 그대로 따르며, 대화로 요청받아 문서·데이터베이스·산출물을 만든다. 별도의 트리거나 워크플로를 사용자가 설계해야 하는 것은 아니다. 반대로 Asana AI Studio의 팀원이나 Notion의 설정형 Custom Agents처럼 역할·권한·판단 지점을 사용자가 (노코드라 해도) 설계하는 형태도 있다. 어느 쪽이든 워크스페이스를 채택·운영하고 보드에 쌓이는 데이터를 관리하는 주체는 팀이다. 에이전트는 이 그룹 제품의 강력한 기능이지, 제품 바깥에서 파견 오는 사람이 아니다.
Motion이 대표 주자다. 사람이 할 일과 마감을 넣으면 AI가 캘린더 위에 일을 자동 배치하고 우선순위와 충돌을 조정한다. 이 "시간 배분을 AI가 결정한다"는 각도가 Motion의 정체성이다.
여기서 원문이 틀렸던 부분을 바로잡는다. Motion은 개인 일정만 짜주는 도구가 아니다. List·Kanban·Gantt 뷰를 갖춘 어엿한 프로젝트 관리 도구이고, 팀 프로젝트를 공유하며 태스크마다 담당자를 지정한다. 담당자를 두고 팀이 같은 프로젝트를 보는 협업이 안 된다는 서술은 사실과 다르다. Motion의 차별점은 "팀이 화면을 못 본다"가 아니라, 표준 PM 뷰 위에 일정 자동화라는 결정 레이어를 얹었다는 데 있다. 요청을 대화로 위임하는 접근과는 결이 다를 뿐, 협업 가시성 자체가 약한 것이 아니다.
Zapier와 Make는 원래 프로젝트 관리 도구가 아니라 자동화 플랫폼이다. "이 앱에서 이 일이 생기면 저 앱에서 이걸 실행하라"는 트리거→액션 규칙을 설계해두면 그대로 반복 실행된다. 이 규칙 기반이 여전히 토대인 것은 맞다.
하지만 "정해둔 규칙 밖의 요청은 판단하지 못한다"는 서술은 현재 제품에 더는 맞지 않는다. Make는 2025년 4월 AI Agents를 발표했다. 사용자가 자연어로 목표를 적으면 에이전트가 맥락에 따라 어떤 도구를 쓸지 스스로 고르고 상황 변화에 맞춰 행동을 조정한다. Zapier의 에이전트도 평문 지시를 받아 계획하고 추론하고 수천 개 통합을 넘나들며 자율적으로 실행한다. 초기에 도구를 붙이고 목표를 정의하는 설정이 필요하다는 사실과, 모든 판단 분기를 사람이 미리 짜야 한다는 주장은 전혀 다른 이야기다. 후자는 이제 틀렸다.
정확한 위치는 이렇다. 이 그룹은 여전히 앱과 앱을 잇는 자동화가 중심이고, 에이전트를 쓰더라도 그 에이전트의 목표·도구·가드레일을 조립하고 거버넌스하는 주체는 사용자다. 자동화 플랫폼 안에 설치하는 지능형 부품이라고 보면 이해가 빠르다.
온틀은 앞의 셋과 축이 다르다. 프로젝트마다 전담 AI PM을 배정해서, 대화로 들어오는 요청을 접수하고 작업을 관리하고 산출물까지 발행한다. 사용자는 워크플로를 설계하지 않고, 에이전트에 도구를 붙이지도 않는다. "이거 해줘"라고 말하고, 결과를 확인하고 승인한다. 조립의 부담이 제품 쪽으로 넘어가 있다는 점이 이 그룹의 특징이다.
| 구분 | A. 협업 워크스페이스 (Asana, Monday, ClickUp, Jira, Notion, Linear) | B. AI 실행 도구 (Motion류) | C. 자동화 플랫폼 (Zapier, Make) | D. 파견형·대화형 (온틀) |
|---|---|---|---|---|
| 핵심 축 | 팀 협업 워크스페이스 | 일정·시간배분 자동화 | 앱 연결 자동화 | 요청 접수에서 산출물까지 대행 |
| AI·에이전트의 역할 | 워크스페이스 안에서 분류·배정·상태갱신·다단계 작업 수행 | 일정 자동배치가 중심, 담당자 배정·협업 뷰도 제공 | 자연어 목표로 도구를 고르는 에이전트를 규칙 위에 추가 | 대화로 요청을 이해해 작업 관리와 산출물 생성까지 |
| 사람이 여전히 하는 일 | 워크스페이스 유지, 설정형 에이전트는 워크플로 설계·거버넌스, 승인 | 우선순위 확인, 일정 수용·조정, 프로젝트 뷰 관리 | 에이전트 목표·도구·가드레일 조립, 예외 거버넌스 | 요청 전달, 확인·승인 |
| 잘 푸는 문제 | 팀 전체 가시성, 다인 협업, 이력 관리 | 바쁜 개인·팀의 시간표 자동화 | 반복적·연속적 데이터 연동과 그 위의 자율 실행 | 실행 인력이 부족한 팀의 대화형 위임 |
| 조립·설정 부담 | 팀이 워크스페이스를 운영, 설정형 에이전트만 설계·거버넌스 | 사용자가 뷰·일정 규칙을 설정 | 사용자가 자동화·에이전트를 조립·거버넌스 | 온틀이 조립을 떠맡음 |
에이전트가 있느냐 없느냐 칸을 지웠다는 점에 주목할 필요가 있다. 그 칸은 이제 넷 다 "있다"로 채워지기 때문에 변별력이 없다. 실제로 갈리는 것은 아래 두 줄, "사람이 여전히 하는 일"과 "조립·설정 부담"이다.
협업 워크스페이스는 회의실 화이트보드다. 요즘 화이트보드는 스티커를 붙이면 요약을 정리해줄 뿐 아니라, 시키면 스티커를 대신 옮기고 새 보드를 열어주는 조수까지 딸려 있다. 그래도 그 화이트보드는 내 방에 있고, 조수가 무엇을 할 수 있는지 정하고 관리하는 건 나다.
AI 실행 도구는 다이어리에 할 일을 적어두면 비서가 시간표에 배치해주는 것에 가깝다. 그 비서는 팀 공용 보드를 같이 정리할 줄도 안다. 다만 비서의 주특기는 "언제 할지"를 정하는 쪽이다.
자동화 플랫폼은 예전엔 정해진 규칙대로만 편지를 분류하는 우편실이었다. 지금은 그 우편실에 "이런 목적으로 처리해줘"라고 적어두면 알아서 판단해 서랍을 고르는 담당자를 세워둘 수도 있다. 핵심은 그 우편실과 담당자를 내가 내 사무실에 설치하고 운영한다는 점이다.
온틀 같은 파견형 접근은 가구를 새로 사거나 우편실을 차리는 게 아니다. 프로젝트에 파견 직원을 한 명 들이는 것에 가깝다. "이 일 좀 해줘"라고 말하면 그 담당자가 요청을 접수하고 일을 굴려 결과물을 만들어 온다. 화이트보드를 살지, 담당자를 부를지의 차이다.
A·B·C 그룹의 에이전트는 공통적으로 "사용자가 운영하는 제품 안에 사는 기능"이다. Asana AI Studio의 팀원도, Motion의 스케줄러도, Make·Zapier의 에이전트도 결국 사용자가 그 도구를 채택하고, 데이터와 예외를 관리하는 전제 위에서 동작한다. 역할·권한을 사용자가 얼마나 설계해야 하는지는 제품마다 다르다. Notion의 기본 에이전트처럼 사용자의 권한을 그대로 따르며 대화만으로 산출물을 만드는 경우도 있고, Asana AI Studio나 설정형 Custom Agents처럼 역할·권한·가드레일을 직접 설계해야 하는 경우도 있다. 공통점은 그 에이전트가 사용자가 채택·운영하는 제품 안의 기능이라는 점, 그리고 그 제품을 운영하는 주체가 사람이라는 점이다.
온틀은 그 전제를 옮긴다. 프로젝트마다 전담 AI PM을 배정해서, 대화로 요청을 접수하고 작업을 관리하고 산출물까지 발행하는 일을 대신한다. Palantir의 포워드 배치 모델을 AI로 옮긴 접근으로, 축으로 표현하면 "제품 안의 설정 가능한 기능"이 아니라 "프로젝트에 파견된 역할"에 위치한다. 에이전트를 가졌다는 점은 이제 남들과 같지만, 그 에이전트를 사용자가 조립하느냐 온틀이 조립해 파견하느냐에서 갈린다.
이 포지션이 잘 맞는 곳은 분명하다. 전담 실행 인력을 따로 두기 어려운 소규모 팀·1인 프로젝트, 매번 맥락이 조금씩 달라지는 반복 요청이 많은 조직이라면, 도구를 새로 배우고 워크플로를 세팅하는 대신 "이거 해줘"라고 말하는 편이 빠르다.
한계도 솔직히 짚는다. 온틀은 만능이 아니다. 팀 전체가 실시간으로 같은 보드를 보며 협업해야 하는 대규모 조직이라면 협업 워크스페이스의 가시성을 대체하기 어렵다. 하루 수백 건씩 완전히 정형화된 대량 데이터 연동이라면 자동화 플랫폼이 비용·안정성 면에서 더 적합할 수 있다. 온틀은 대화로 요청하고 판단이 필요한 산출물을 받아 보는 영역에서 강점이 있는 것이지, 팀 협업 보드나 대량 파이프라인을 새로 발명한 것이 아니다.
첫째, 에이전트가 어디에 사는가. 내가 운영하는 워크스페이스나 자동화 안의 기능이 필요하면 A·C 그룹, 시간 배분 자동화가 핵심이면 B, 대화로 요청을 통째로 넘기고 싶으면 D다.
둘째, 조립·거버넌스 부담을 누가 질 것인가. 워크플로를 우리 손으로 세밀하게 설계·통제하고 싶다면 인플랫폼 에이전트(A·C)가 유리하다. 그 설계 부담 자체를 넘기고 결과만 받고 싶다면 파견형(D)이 그 부담을 대신 진다.
셋째, 팀 크기와 협업 필요도. 여러 명이 실시간으로 같은 현황을 봐야 한다면 협업 워크스페이스(A)가 기본 골격으로 필요하다. 소수가 요청 위주로 일한다면 파견형(D)이 가볍다. 중요한 건 이들이 경쟁이 아니라 서로 다른 축을 덮는다는 점이다. 협업 보드는 A에 두고, 매번 다른 비정형 요청은 대화로 D에 맡기는 병행이 자연스럽다.
맞다. 2025년을 지나며 협업 워크스페이스·실행 도구·자동화 플랫폼 모두 에이전트를 얹었다. 그래서 차이는 에이전트 유무가 아니다. 다른 도구의 에이전트는 사용자가 채택·운영하는 제품 안에 사는 기능이다. 설정형 에이전트라면 그 역할과 가드레일도 사람이 설계하고, Notion 기본 에이전트처럼 사용자 권한을 그대로 따라 대화로 쓰는 형태도 있다. 어느 쪽이든 그 제품을 채택·운영하는 주체는 사용자다. 온틀은 프로젝트에 전담 AI PM을 파견해 대화로 요청을 접수하고 산출물까지 만들어 오는 역할 모델이라는 점에서 결이 다르다.
가능하다. 기존 협업 워크스페이스는 팀 내부 기록과 가시성용으로 그대로 두고, 별도 실행 인력이 부족한 반복 요청이나 산출물 작업만 대화로 온틀에 맡기는 병행이 자연스럽다. 두 접근은 경쟁이라기보다 서로 다른 축을 덮는다.
Motion은 일정 자동배치를 중심에 둔 도구이면서 List·Kanban·Gantt 뷰와 담당자 배정을 갖춘 프로젝트 관리 도구이기도 하다. 시간을 어떻게 쓸지 결정하는 데 강점이 있다. 온틀은 시간표를 짜주는 것이 아니라 프로젝트 요청 자체를 접수해 작업을 관리하고 결과물을 만들어 전달하는 데 초점이 있다. 둘은 함께 쓸 수 있다.
있다. 팀 전체가 실시간으로 같은 보드를 보며 협업해야 하는 대규모 조직에는 협업 워크스페이스가, 하루 수백 건 이상 완전히 정형화된 대량 데이터 연동에는 자동화 플랫폼이 더 적합할 수 있다. 온틀은 대화로 요청하고 판단이 필요한 산출물을 받고 싶은 상황에 강점이 있는 것이지 모든 용도의 대체재는 아니다.
프로젝트 관리 도구를 새로 배우고 워크플로를 세팅하는 대신, 전담 AI PM에게 대화로 요청을 맡기고 싶다면 온틀에서 시작해볼 수 있다.
https://ontle.kr