.jpg&blockId=37a5bbc0-e5c2-80d6-b7ce-e48340aaae4a&width=3600)
안녕하세요. 데이블 PD팀에서 PM으로 일하고 있는 문경복입니다 
이번 글에서는 제가 사이드 프로젝트로 만들어 사내에서 운영 중인 PM Triage Bot 이야기를 해보려고 합니다.
1. PM의 태스크 판단
데이블에서 PM으로 일하다보면 여기저기 흩어진 채널에 요청이 쌓여 있고, Jira에는 누가 어떤 의도로 만들었는지 불분명한 티켓들이 서로 다른 보드에 흩어져 있는 상황에 불편함을 느꼈습니다.
기존에는 사내 요청이 크게 두 갈래로 들어오고 있었습니다. 하나는 Support 보드(버그·장애 대응·서비스 개선 등), 또 하나는 PRD 문서(기획성 작업). 그런데 실제로는 대부분의 요청이 일단 Support로 흘러들어왔습니다.
"광고주 계정 활성화 좀 부탁드려요"
"위젯 식별 기준을 분석해주세요"
"미디어팀 리포트 양식 좀 업데이트해주실 수 있나요?"
이런 요청들은 긴급한 장애도 아니고, 기획이 필요한 신규 기능도 아닙니다. 그런데 어딘가에는 들어가야 하니까 일단 Support로 모이게 된 거죠. 문제는 그렇게 모인 티켓들 사이에 우선순위가 명확하지 않다는 것이었습니다. 진짜 장애 대응과 단순 설정 변경 요청, 데이터 추출 요청이 같은 보드에 같은 모양으로 쌓이다 보니, 무엇을 먼저 봐야 하는지가 흐릿했습니다.
그래서 올해 초, 데이블 사내에서 큰 결심을 했습니다. 흩어져 있던 요청을 모두 DT(DNA Task) 보드 하나로 모으기로 한 것입니다. Support는 진짜 긴급한 버그·장애 대응만, 나머지는 모두 DT로 통합하는 방식이었습니다. 이 전환을 통해 다음과 같은 장점을 얻고자 했습니다.
•
모든 요청이 하나의 보드에서 우선순위가 한눈에 들어오는 점
•
요청의 진행 상태(Backlog → PM REVIEW → Ready → In Progress → Done)가 상태값으로 명확히 보이는 점
•
누가 무엇을 요청했고 지금 어디까지 와있는지 추적 가능한 점
좋은 시도였지만 통합이 끝나고 나니, 새로운 문제가 따라왔습니다.
모든 요청이 PM에게 모이는 구조
DT 보드 하나로 통합하다 보니, 모든 요청이 일단 PM REVIEW 라는 큐로 흘러들어옵니다. 그리고 PM은 매 티켓마다 판단을 해야 했습니다.
이거 진짜 기획이 필요한 건가, 단순 요청(Service Request)인가?Business Value 점수는 몇 점이지?다음 상태를 Ready로 보낼까, Spec in Progress로 보낼까?
그런데 막상 들여다보면 판단이 늘 명확한 건 아니었습니다. 어떤 요청은 단순한 설정 변경처럼 보이지만 실제로는 정책 검토가 필요했고, 어떤 요청은 신규 기능처럼 보였지만 사실상 기존 기능의 작은 확장이었습니다. "이건 기획을 거쳐야 하나, 바로 개발로 넘겨도 되나" 같은 경계선상의 판단이 매번 따라붙었습니다. 비즈니스 점수도 마찬가지였습니다. 광고주 한 곳에서 온 요청이 전체 매출에 영향을 줄 수도 있고, 전사 차원의 요청처럼 보이지만 실제 임팩트는 한정적인 경우도 있었습니다. 결국 매주 비슷한 결을 따라가면서도 케이스마다 미묘하게 다른 판단을 반복해야 했고, 그 판단의 일관성을 사람의 컨디션에만 맡기기에는 어려운 점이 있었습니다.
이걸 봇이 먼저 해보고, PM은 확인하고 수정만 하면 되게 만들 수는 없을까? 그렇게 시작한 게 PM Triage Bot입니다.
2. 봇의 목표와 요구사항
처음 설계할 때 잡은 요구사항은 단순했습니다.
기능적 요구사항
•
티켓이 PM REVIEW 상태로 진입하면 봇이 자동으로 1차 분석을 수행할 것
•
단순 요청(Service Request)과 기획 필요 작업을 구분할 것
•
Business Value 점수(6개 항목, 100점 만점)를 자동 채점할 것
•
PM은 자연어로 답장만 하면 결과가 Jira에 반영될 것
비기능적 요구사항
•
PM이 코드를 건드리지 않고도 판단 기준을 바꿀 수 있을 것
•
봇이 사람의 판단을 강제하지 않고 "1차 의견"으로 동작할 것
•
봇이 운영될수록 점점 PM의 판단 패턴에 맞춰 학습될 것
특히 마지막 두 가지가 중요했습니다. 자동화의 함정 중 하나가 "봇이 결정자가 되는 것"인데, 이번 도구는 PM이 여전히 의사결정자고 봇은 그 출발점만 만들어주는 역할이어야 했습니다.
3. 티켓의 플로우
전체 흐름을 먼저 그려보면 이렇습니다.
(그림 1) PM Triage Bot — 티켓 플로우
요청자 → Jira 티켓 등록 → DoR 체크(지라 티켓의 작성 요건 확인) → PM REVIEW 진입 → Slack 알림 → 봇 감지 → Jira 상세 조회 → Google Sheet 룰 로드 → AI 판단(Service Request 여부 + BV 점수) → Slack 스레드 리포트 → PM 자연어 답장 → 봇이 Jira 반영 + Sheet에 학습 데이터 누적
티켓 한 건이 등록되고 PM의 손에 떨어지기까지의 흐름을 단계별로 풀어보면 다음과 같습니다.
① 티켓 등장 & DoR 체크
요청자가 Jira DT 보드에 티켓을 등록하면, 먼저 DoR(Definition of Ready) 체크를 거칩니다. 요건이 충분히 채워지지 않은 티켓은 이 단계에서 걸러져 요청자에게 다시 돌아갑니다. DoR을 통과한 티켓만 PM REVIEW 상태로 전환되고, Jira가 #dt-pm-triage 슬랙 채널에 알림을 자동으로 띄웁니다.
② 봇이 발견
봇이 채널을 보고 있다가 DT-숫자 패턴이 감지되면 곧장 스레드에 답장을 답니다.
DT-225 확인했습니다. 분석 중입니다…③ Jira에서 상세 정보 수집
봇이 Jira에 접근해 제목, 설명, 이슈 타입, 보고자, 라벨을 읽어옵니다.
④ Google Sheet에서 "규칙집" 로드
여기가 이 봇의 핵심 설계 중 하나입니다. 봇은 분석 직전 매번 Google Sheet를 읽어 최신 기준을 반영합니다. 시트는 4개 탭으로 구성되어 있습니다.
탭 | 내용 | 필요한 이유 |
보정규칙 | "광고 관련이면 전략 점수 최소 3점" 같은 룰 | AI가 편향되지 않도록 사람이 정한 룰로 교정 |
캘리브레이션 | "DT-213은 39점이 정답" 같은 과거 정답지 | AI에게 "이전엔 이렇게 채점했어"라고 예시 제공 |
배점설정 | ⓐ~ⓕ 6개 항목 배점 (25/25/20/10/5/15) | 코드 수정 없이 배점 변경 가능 |
봇설정 | Service Request 라벨명, Ready 상태명 등 | 운영 설정 조정 |
⑤ AI가 두 가지를 판단
봇이 AI에게 티켓 정보 + 규칙집 + 과거 정답 예시를 통째로 넘기면, AI는 두 단계로 판단합니다.
•
(a) 먼저, Service Request인가?
코드 개발이 필요 없는 단순 요청 — 계정 활성화, DB 값 변경, 데이터 추출, 리포트 양식 변경 같은 건은 Service Request로 분류하고 점수 매기기를 스킵합니다. 그리고 라우팅 대상(BE팀 / BI팀 등)까지 함께 알려줍니다.
•
(b) Service Request가 아니라면, 기획 필요 여부 + BV 점수 매기기
◦
기획 필요: 신규 기능, 법규 판단, UI 신규 설계 등◦
기획 불필요: 버그 수정, 기존 기능 확장, 솔루션이 이미 명시된 요청 등◦
Business Value Score (100점 만점)
ⓐ 매출영향 (25) / ⓑ UX·경쟁력 (25) / ⓒ 안정성·법규 (20)
ⓓ 내부효율 (10) / ⓔ 전략정렬 (5) / ⓕ 시간긴급성 (15)
⑥ 봇이 슬랙 스레드에 리포트 업로드
판단 결과, 총점, 항목별 점수의 근거, 권고사항, 그리고 PM이 취할 수 있는 액션 안내까지 한 번에 정리되어 올라옵니다.
⑦ PM이 자연어로 답장
여기가 의외로 중요한 부분입니다. 정해진 명령어가 아니라 편하게 말로 답하면 됩니다.
이렇게 답하면 | 봇이 이렇게 합니다 |
"진행해", "ㅇㅇ", "LGTM" | 점수 반영 + 상태 전환 |
"ⓐ를 15로 올리고 진행" | 점수 수정 후 반영 |
"이건 Service Request야" | Service Request로 재분류 |
"기획 필요 없어, Ready로" | PM 판단 뒤집고 Ready로 전환 |
"다시 분석해봐" | 재분석 |
"보류" | 아무것도 하지 않음 |
봇은 PM의 답장을 해석한 뒤 "이런 액션을 실행할게요, 진행할까요?" 하고 한 번 더 확인합니다. Jira에 쓰기 작업이 들어가기 전 마지막 안전장치입니다.
⑧ 봇이 Jira에 반영
PM이 "진행"이라고 하면, 봇은 BV 점수 6개 필드를 업데이트하고, 상태를 Spec in Progress(기획 필요) 또는 Ready(개발 준비)로 전환합니다. Service Request라면 라벨과 코멘트를 함께 추가하고, 슬랙 스레드에는 이모지와 완료 보고가 달립니다.
이모지와 완료 보고가 달립니다.
4. 핵심 설계 결정들 — 왜 이렇게 만들었나
흐름만 보면 단순한 슬랙 봇처럼 보이지만, 실제로 이 봇을 운영 가능한 도구로 만든 건 몇 가지 작은 설계 결정들이었습니다.
4-1. 왜 Google Sheet를 룰 엔진으로 썼나
가장 처음 부딪힌 고민이었습니다. 판단 기준을 어디에 둘 것이냐. 코드 안에 하드코딩하면 빠르게 만들 수 있지만, 기준을 바꿀 때마다 PM이 개발자에게 부탁하거나 직접 코드를 건드려야 합니다.
그래서 Google Sheet를 봇의 "리모컨"으로 만들기로 했습니다. PM이 시트를 한 줄 수정하면, 다음 분석부터 바로 새 기준이 적용됩니다. 코드 재배포가 전혀 필요 없습니다.
이게 단순히 편의성의 문제만은 아니었습니다. 기준이라는 건 운영해보기 전에는 알 수 없는 것들이 너무 많았습니다. "광고 관련 요청은 전략 점수가 최소 몇 점은 되어야 한다"같은 룰은 처음부터 알 수 있는 게 아니라, 봇과 한 달쯤 같이 일하다 보니 보이는 패턴이었거든요. 시트를 룰 엔진으로 두면 이런 발견을 즉시 시스템에 반영할 수 있습니다.
4-2. 왜 자연어 응답 인터페이스인가
처음에는 슬랙 버튼 인터페이스도 고민했습니다. "승인 / 수정 / 거절" 같은 버튼을 박아두면 깔끔하니까요. 그런데 실제로 써보니 버튼만으로는 부족했습니다.
PM의 응답에는 "ⓐ만 살짝 올려서 진행" 같이 미세조정이 필요한 경우가 꽤 많았는데, 버튼으로 모든 경우를 커버하려면 UI가 금방 복잡해졌습니다. 그래서 차라리 PM이 평소에 슬랙에서 답하듯 말로 답하게 하고, 그걸 AI가 해석하게 하자고 결정했습니다.
다만 자연어 해석의 가장 큰 위험은 봇이 PM의 의도를 잘못 읽는 것입니다. 그래서 봇은 모든 쓰기 작업 전에 "이렇게 이해했는데 진행할까요?" 하고 한 번 더 확인합니다. 자연어의 유연함과 안전장치를 함께 가져가기 위한 절충이었습니다.
4-3. 왜 점수를 자동 누적하나 — "PM이 판단할수록 똑똑해지는 봇"
봇은 Google Sheet를 읽기만 하지 않고 쓰기도 합니다. 그게 핵심이었습니다.
•
PM이 봇의 점수를 수정하거나 판단을 뒤집으면 → 그 사례가 캘리브레이션 탭에 자동으로 누적됩니다 → 다음 분석부터 AI는 그 사례를 참고합니다.
•
같은 유형의 Service Request 오버라이드가 3번 쌓이면 → 봇이 "이 유형을 Service Request 규칙으로 추가할까요?" 하고 제안합니다 → 승인하면 보정규칙 탭에 자동 반영됩니다.
즉, PM이 판단할수록 봇이 PM의 취향에 점점 맞춰지는 구조입니다. 모델 파인튜닝이 아니라, 룰과 예시의 누적으로 학습이 일어나는 방식이라 PM이 직접 시트를 들여다보면서 "왜 봇이 그렇게 판단하는지" 를 언제든 확인할 수 있습니다. 블랙박스가 아니라는 게 중요했습니다.
4-4. 기술 스택은 절제해서
기술 스택은 의도적으로 가볍게 가져갔습니다. Mac에서 도는 launchd 스케줄러와 Claude Code 헤드리스 모드, 그리고 Jira API + Slack API + Google Sheets API의 조합입니다. 별도의 서버나 EKS 같은 인프라 없이, PM 한 명이 충분히 운영할 수 있는 수준에서 시작했습니다.
이 정도 스택으로도 위에서 설명한 8단계 워크플로우가 안정적으로 돈다는 게, 어떤 의미에서는 이 글에서 가장 말하고 싶었던 부분이기도 합니다. 거창한 인프라 없이도 자동화가 가능한 시대가 됐다는 것이지요.
5. 운영하면서 발견한 것들
봇을 며칠 돌려보면서 가장 흥미로웠던 건, 봇 자체보다 봇이 비춰준 판단 패턴이었습니다.
대표적인 발견 하나만 공유하자면, Internal Efficiency(내부효율) 항목이 일관되게 저평가되는 패턴이 있었습니다. 봇이 운영 효율 개선 요청에 7점쯤 매기면, 저는 거의 매번 4~5점으로 깎아 내리고 있었습니다. 처음엔 "봇이 점수를 너무 후하게 주네" 라고 생각했는데, 캘리브레이션 데이터가 쌓이고 나서 다시 보니 저 자신이 운영 개선 요청을 무의식 중에 낮게 평가하는 경향이 있었던 거였습니다.
이게 옳은 판단인지 아닌지는 별개의 문제입니다. 다만 봇이 없었다면 이런 편향을 인지조차 하지 못했을 거라는 게 흥미로웠습니다. 자동화가 단순히 시간을 줄여주는 것을 넘어서, 사람의 판단을 거울처럼 비추는 도구가 될 수 있다는 걸 봇을 운영하면서 처음 체감했습니다.
또 하나 배운 건, 봇의 첫 판단보다 PM의 수정 패턴이 훨씬 더 많은 정보를 담고 있다는 것이었습니다. 봇의 1차 점수는 그냥 평균에 가까운 값일 때가 많지만, PM이 그 점수를 어디로 어떻게 옮기는지를 보면 그 안에 우리 조직의 우선순위가 녹아 있었습니다. 캘리브레이션 데이터가 결국 일종의 암묵지의 명문화였던 셈입니다.
6. 정리하며
PM의 일이라는 건 결국 수많은 작은 판단의 연속이라고 생각합니다. 그 판단 하나하나는 어렵지 않아도, 그게 매일 쌓이면 적지 않은 인지부하가 됩니다. 그리고 인지부하가 쌓이는 만큼, 정작 PM이 더 깊이 고민해야 할 큰 의사결정에 쓸 에너지가 줄어들죠.
PM Triage Bot은 거창한 시스템이 아닙니다. 그저 "PM이 매번 처음부터 판단하지 않아도 되게" 만들어준 작은 도구에 가깝습니다. 봇이 1차 의견을 내고, PM은 거기서 출발해서 동의하거나 수정하거나 뒤집습니다. 결정의 책임은 여전히 PM에게 있지만, 출발점이 비어 있는 백지가 아니라 한 번 채워진 초안이라는 점에서 일의 결이 완전히 달라졌습니다.
요즘 자동화에 대한 이야기를 하다 보면 "AI가 사람의 일을 대체할 것이냐" 같은 프레임이 자주 등장합니다. 하지만 적어도 이번 경험에서 제가 느낀 건 조금 달랐습니다. PM의 일은 판단을 자동화하는 게 아니라, 판단의 출발점을 자동화하는 것에 더 가깝다는 것이었습니다. 최종 의사결정과 그 책임은 여전히 사람에게 남아 있고, 봇은 그 결정에 도달하기까지의 경로를 짧게 만들어주는 역할에 머무릅니다.
앞으로는 이 봇을 PM Triage뿐 아니라, 다른 영역의 1차 검토 자동화로도 확장해볼 계획입니다. 그리고 캘리브레이션 데이터가 더 쌓이면, 그걸 사내 LLM Wiki와 연결해서 조직의 판단 기준이 자연스럽게 문서화되는 구조도 실험해보려고 합니다.
이번 글이 비슷한 고민을 하고 계신 분들께 작은 출발점이 되었으면 좋겠습니다.
읽어주셔서 감사합니다