고객이 대화창에 "우리 회사 소개 페이지 하나 만들어줘"라고 말하는 순간, 그 한마디가 실제 작업이 되기까지는 보이지 않는 여러 단계를 거친다. 이 과정을 총괄하는 것이 바로 온틀의 AI PM이다. 온틀이 고객 프로젝트마다 한 명씩 붙여 주는, 담당자 역할을 하는 AI(프로젝트 매니저)다.
이 글에서는 그 "소개 페이지" 요청 한 건이 처음 대화부터 완료까지 어떻게 흘러가는지 — 그리고 애매한 순간마다 AI PM이 무엇을 기준으로 판단하는지 — 를 실제 장면을 따라가며 살펴본다.
온틀의 구조는 식당을 떠올리면 한눈에 들어온다.
손님이 홀 직원에게 말로 주문하면("매운 걸로 하나, 덜 맵게요"), 홀 직원은 그 말을 표준 양식의 주문 티켓으로 바꿔 주방에 넣는다(메뉴명·매운맛 단계·테이블 번호). 주방은 티켓을 순서대로 걸어놓고 조리하고, 요리가 나오면 손님 앞에 서빙한다. 손님이 "이건 너무 매워요"라고 하면 수정 요청이 다시 주방으로 들어간다.
여기서 중요한 건, 손님과 나누는 모든 말이 티켓이 되지는 않는다는 점이다. "오늘 날씨 좋네요" 같은 잡담이나 "매운 거랑 안 매운 거 중 뭐가 나아요?" 같은 질문은 홀에서 답하고 끝난다. 홀 직원은 "이건 진짜 주문이다" 싶은 말, 곧 실행 요청만 골라 티켓을 끊는다.
그리고 솜씨 좋은 주방은 손님을 기억한다. "저번보다 덜 짜게"라는 말이나 단골의 취향을 떠올려 조리에 반영한다. 온틀에서 이 기억 장치에 해당하는 것이 지식 온틀 — 고객이 그동안 온틀에 쌓아 둔 자료를 실행 담당이 다시 꺼내 참고하는 구조다. (실제로 쓰이는 장면은 뒤 4단계에서 보자.)
AI PM은 이 식당 구조를 거의 그대로 소프트웨어로 옮긴 것이다. 대화는 홀에서, 실제 작업은 주방(작업 큐)에서 처리된다. 이제 "소개 페이지 만들어줘" 한마디가 이 주방을 어떻게 통과하는지 여섯 단계로 따라가 보자.
한 고객이 대화창에 "우리 회사 소개 페이지 하나 만들어줘"라고 적었다고 하자. 고객은 명령어가 아니라 평소 쓰는 말(자연어) 그대로 대화하면 된다. AI PM이 가장 먼저 하는 일은 이 말이 그냥 해 보는 얘기인지, 실제로 실행할 요청인지부터 가려내는 것이다. 요청이라고 판단되면, 빠진 정보는 없는지 되묻는다.
예를 들어 "요즘 이런 서비스 많나요?"는 답만 하면 끝나는 질문이라 작업으로 넘어가지 않는다. 반면 "소개 페이지를 만들어서 다음 주까지 보여주세요"에는 무엇을(소개 페이지)과, 어떻게 하라는 동사(만들어 달라)가 함께 들어 있다. 이렇게 '대상 + 실행 동사'가 같이 있으면 요청 후보로 본다.
우리 예시의 "소개 페이지 하나 만들어줘"도 대상과 동사가 있으니 요청 후보다. 다만 어떤 회사인지, 무엇을 담을지가 비어 있다. 그래서 AI PM은 혼자 단정하지 않고 "회사 소개 페이지를 만들어 드릴게요. 어떤 내용을 담을까요?"라고 한 번 더 묻는다. 모든 문장을 덜컥 작업으로 올려 버리면 "안녕하세요"까지 목록에 쌓이고, 반대로 진짜 요청을 잡담으로 흘려보내면 아무 일도 일어나지 않기 때문이다.
고객이 "회사 소개랑 연락처, 간단한 문의 폼이 있으면 좋겠어요"라고 답한다. 그러면 AI PM은 이 대화를 요청서 초안으로 정리한다. 손님의 "매운 걸로 덜 맵게"를 홀 직원이 티켓 양식에 옮겨 적는 것과 같다. 채우는 칸은 보통 네 가지다.
| 항목 | 설명 | 예시 |
|---|---|---|
| 목적 | 이 작업이 왜 필요한가 | 신규 고객에게 서비스를 소개하려고 |
| 기능 | 무엇을 할 수 있어야 하는가 | 회사 소개, 연락처, 문의 폼 |
| 범위 | 어디까지 포함하고 무엇은 빼는가 | 결제 기능 제외, 정적 소개만 |
| 형태 | 결과물의 종류 | '회사이름.ontle.kr' 같은 전용 주소(서브도메인)로 여는 웹페이지 1개 |
여기서 '서브도메인'은 큰 사이트 주소 앞에 이름을 붙여 따로 여는 전용 주소를 말한다. 이 초안은 AI PM이 임의로 확정하지 않는다. 고객에게 다시 보여 주고 확인을 받는 검문소다. 빠진 정보가 있으면 이 자리에서 "문의 폼은 이메일로 받는 형태면 될까요?"처럼 되묻는다. "홈페이지 만들어주세요" 한 줄만 받고 바로 착수하면 나중에 "이게 아닌데요"가 반복되지만, 목적·기능·범위·형태 네 칸을 먼저 맞춰 두면 그 어긋남을 앞에서 걸러낼 수 있다. 고객이 "네, 맞아요"라고 해야 다음으로 넘어간다.
고객이 요청서를 확인하는 순간, 요청에 고유 번호가 붙고 작업 큐에 정식으로 올라간다. 우리 예시에서는 '#123'이 찍혔다고 하자. 이후 모든 소통(진행 문의, 수정 요청)이 이 번호를 기준으로 오간다.
이때 등록 전 요청서 확인과 등록 뒤의 '검토중'은 역할이 다르다. 요청서 확인은 고객이 "이 주문 맞다"고 도장을 찍는 고객과의 합의 단계다. 반면 '검토중'은 이 요청을 실제로 만들 담당(다음 단계에 나올 '워커')이 범위와 기능을 다시 뜯어보며 기술적으로 무리가 없는지 따지는 실무 검토 단계다. 여기서 또 빠진 정보가 발견되면 AI PM이 한 번 더 고객에게 묻는다.
큐에 올라온 요청을 실제로 처리하는 실행 프로그램을 온틀에서는 워커라 부른다. 주방에서 티켓을 보고 요리사가 조리를 시작하는 장면이다. 워커는 글이나 코드를 만들어 내는 생성형 AI의 힘을 빌려, 요청서에 적힌 목적·기능·범위·형태대로 결과물을 만든다. 산출물은 요청 형태에 따라 갈린다.
이 단계에서 #123을 집어 간 워커는 지식 온틀을 참고한다. 그냥 흔한 회사 소개 페이지를 찍어내는 게 아니라, 이 고객이 전에 공유해 둔 브랜드 가이드와 제품 목록을 다시 꺼내, 그 회사의 색과 로고·제품 설명에 맞춘 "우리 회사다운" 소개 페이지로 만든다.
주방이라고 늘 순조로운 건 아니다. 만약 참고할 브랜드 자료가 부족해 워커가 중간에 막히면, 요청은 조용히 사라지거나 억지로 '완료'로 넘어가지 않는다. '진행중'에 멈춘 채 고객 눈에 그대로 남아, 무엇이 더 필요한지 다시 물을 수 있다.
소개 페이지 초안이 나왔다고 자동으로 "완료"가 되지는 않는다. 상태가 '확인대기'로 바뀌고, 결과물이 고객에게 전달된다. 요리가 손님 앞에 서빙되는 순간이다. 고객이 직접 열어 보고 판단할 시간을 주는 이 한 칸이 있어야, 의도와 어긋난 결과물이 멋대로 완료 처리되는 사고를 막을 수 있다.
고객이 결과물을 승인하면 상태가 '완료'로 바뀌고 요청이 마무리된다. 반대로 "로고 색을 좀 더 진하게 해주세요"라면 수정 요청이 되어 다시 워커에게 돌아가고, 4~5단계가 반복된다.
이때 AI PM이 가르는 기준이 하나 있다. 수정인가, 새 요청인가. 잣대는 처음 합의한 요청서의 '범위'다. "로고 색을 진하게"는 범위 안의 손질이라 #123을 그대로 유지한 채 다시 작업한다. 하지만 며칠 뒤 고객이 "결제 기능도 넣어주세요"라고 하면, 이건 "결제 기능 제외"로 합의했던 범위를 벗어난다. 그래서 기존 요청에 억지로 끼워 넣지 않고 별도 요청으로 분리해 새 번호를 준다.
이는 프로젝트 관리에서 가장 흔한 실패 원인으로 꼽히는 '스코프 크립(scope creep — 처음 합의한 작업 범위가 요구가 더해질수록 슬금슬금 불어나는 현상)'을 원천에서 막는 핵심 원칙이다. "소개 페이지 하나"가 이것저것 덧붙으며 정체불명으로 부풀어, 끝이 보이지 않는 작업이 되는 일을 여기서 끊는다.
요청 하나가 큐 안에서 거쳐 가는 상태를 정리하면 이렇다.
| 상태 | 의미 | 이 상태에서 벌어지는 일 |
|---|---|---|
| 신규 | 요청서가 막 등록됨 | 요청 번호 부여, 워커 배정 대기 |
| 검토중 | 워커가 범위·기능을 재확인 | 부족한 정보가 있으면 고객에게 재질문 |
| 진행중 | 워커가 실제 산출물을 만드는 중 | 문서·웹·앱 형태로 결과물 생성 |
| 확인대기 | 산출물이 나와 고객 확인을 기다림 | 고객에게 알림, 결과물 전달 |
| 완료 | 고객이 승인함 | 요청 종료, 산출물 확정 |
| 수정요청 | 고객이 변경을 원함 | 다시 진행중으로 돌아가 반복 |
고객은 자기 요청이 지금 어느 칸에 있는지 화면에서 실시간으로 따라볼 수 있다.
AI PM이 질문으로 판단해 답만 하고 끝났다면, 대상과 실행 동사를 함께 넣어 다시 말씀해 주세요. "이거 되나요?" 대신 "그럼 이걸로 만들어 주세요"처럼요. '무엇을 + 만들어/수정해'가 붙으면 요청서 단계로 넘어갑니다.
처음부터 다 채우지 않아도 됩니다. 아는 만큼만 말씀하시면 AI PM이 빈칸을 보고 "이건 어떻게 할까요?"라고 되물어 함께 채웁니다. 다만 '형태'(웹·앱·문서)만 먼저 정해 두면 요청서가 더 빨리 확정됩니다.
번호가 붙은 뒤에는 대화창이나 요청 목록에서 현재 상태를 언제든 볼 수 있습니다. 작업 큐나 코드를 직접 들여다볼 필요 없이, "지금 어느 단계인지"만 늘 드러납니다.
요청서의 '형태' 칸에 필요한 종류를 함께 적으면 됩니다. 다만 종류가 늘수록 '검토중' 단계에서 확인할 것도 늘어나니, 처음부터 형태를 구체적으로 말씀해 주시는 편이 빠릅니다.
결국 좋은 AI PM은 "네, 알겠습니다"라고 빨리 답하는 AI가 아니라, "이게 정말 원하시는 게 맞나요?"라며 한 번 멈춰 세우는 AI다. "소개 페이지 하나 만들어줘"가 #123이 되고, 브랜드 자료를 입은 결과물이 되고, 수정과 새 요청으로 갈라지기까지 — 그 길목마다 놓인 이 '한 번 더 확인'이, 흘러가는 말을 책임지는 작업으로 바꾸는 신뢰의 핵심이다.
저자: 정유나