프로덕트에서 방향을 잃지 않으려면, 착수 전 임팩트 계산이 먼저다
저는 처음으로 AI 프로덕트를 맡아 착수했다가 방향을 잃은 경험이 있어요. 우선순위는 계속 흔들렸고, scope은 커졌고, 일정은 밀렸고, 결국 처음에 세웠던 목표 자체가 흐릿해졌습니다. 그때는 실행력 문제라고 생각했어요. 그런데 뒤를 돌아보니, 시작 전에 임팩트 계산을 건너뛴 게 시작이었습니다.
데이터 포인트가 많지 않고, 성숙도가 높지 않은 제품에서 능동적으로 일하는 PM일수록 이 단계를 건너뛰기 쉬워요. 이 글은 저의 실패 경험을 풀어 쓴 글입니다.
작성자: 멘토 파니(Fannie)
15초 요약
"하면 된다"와 "하면 왜 된다"는 다르다. 그 차이는 착수 전에 임팩트를 계산했느냐, 아니냐에서 시작된다.
자동화를 지원하지 않던 많은 제품들이 자동화를 준비해갈 때는 기획 단계에서 불확실성이 높아, 많은 PM들이 "일단 해보자"로 착수합니다. 그런데 임팩트 계산 없이 시작한 프로젝트는 진행할수록 scope이 붙고, 우선순위가 흔들리고, 어느 순간 왜 이걸 하고 있는지 모르게 됩니다. 이미 방향을 잃은 프로젝트를 다시 중심 잡는 건 처음부터 제대로 시작하는 것보다 몇 배 더 어렵습니다.
알아두면 좋은 용어
- 임팩트 계산 (Impact Estimation): 특정 문제를 해결했을 때 비즈니스나 사용자에게 미치는 효과를 수치 또는 규모로 추정하는 것. 정확한 예측이 아니라, 방향과 우선순위를 잡기 위한 추정입니다.
- Scope Creep: 프로젝트 진행 중 기능이나 요구사항이 계획 외로 계속 늘어나는 현상. 초기에 임팩트 범위가 불명확할수록 심해집니다.
- 엣지 케이스 (Edge Case): 일반적인 처리 흐름에서 벗어난 예외 상황. AI 자동화에서는 표준화되지 않은 업무 유형이 여기에 해당됩니다.
- 표준 업무 (Standard Work): 반복 가능하고 정형화된 작업의 집합. 자동화의 전제 조건입니다. 표준이 정의되지 않으면 자동화 대상 자체가 없습니다.
- 워크플로우 분해 (Workflow Decomposition): 복합적인 업무를 단위 행위로 쪼개고, 각 행위의 시간·비중·빈도를 측정하는 작업. 임팩트 계산의 출발점입니다.
Y's Insight
오늘의 Y's Insight는 커머스 운영, 물류 PM을 거쳐 AI 도메인까지 PM 경력만 5년차인 멘토 파니(Fannie)님이 작성했습니다.
우리는 아는 게 없는 채로 시작했다
회사의 운영 조직에 반복 수기 업무가 많았습니다. 인력이 늘수록 비용도 선형으로 증가하는 구조였고, 이걸 자동화로 해결하자는 방향은 팀 모두가 공감했어요.
문제는 "무엇을 자동화할 것인가"였습니다.
회사에는 팀별 인건비 데이터가 있었지만, 어떤 행위에 얼마나 시간이 쓰이는지는 아무도 몰랐어요. 더 복잡한 건, 동일한 업무처럼 보이는 일들이 실제로는 고객사마다 다르게 커스터마이즈된 서비스를 소화하는 형태였다는 것입니다. "표준"이 뭔지에 대한 정의 자체가 없었어요.
PM과 개발팀이 아는 건 딱 두 가지였습니다. 대략적인 인건비, 그리고 작업 종류별 대략적인 금액. 어떤 행위 하나를 자동화했을 때 실제로 비용이 얼마나 줄어드는지는 아무도 계산하지 못한 상태였어요.
그 상태로 시작했습니다. 뭐라도 해보자는 마인드로, 운영 관리자들의 경험에 귀 기울여서 문제를 하나씩 풀어보기로 했어요.
한 달이 지났는데 아무것도 시작되지 않았다
시간은 흘렀고, 결과는 흐릿해졌고, 매번 미팅에서 나오는 말은 "그 다음은 뭐예요?"였습니다.
프로젝트가 시작된 지 한 달이 지났을 때, 팀은 그제서야 인정했습니다. 영향도를 파악하지 못한 채 일을 시작한 게 문제였다는 것을.
우리 회사에서 처리하는 업무는 크게 네 가지 유형으로 나뉩니다. 우리는 그중 가장 큰 비용을 차지하는 유형을 해결하려 하고 있었어요. 그런데 막상 임팩트를 계산하려고 보니, 그 업무 자체가 꽤 복합적인 워크플로우를 가지고 있었고, 고객사마다 서비스 방식이 달라서 계산이 더 어려웠습니다. 결국 임팩트를 계산하기 어려웠기 때문에 계산을 안 했던 게 아니라, 계산하기 어려웠기 때문에 계산할 수 없다고 포기했던 거였어요.
200개의 작업, 손으로 다 뜯어봤다
우리는 그 업무를 외주로 맡기고 있는 6개월·1년·3년 차 직원 세 명을 불러서 면밀히 조사했습니다.
여전히 일은 정형화되지 않았어요. 그래서 먼저 이 프로세스에서 "표준" 작업만 남기고, 나머지는 엣지 케이스로 분류하는 판단을 내렸습니다. 엣지 케이스는 재계약되는 고객사를 대상으로 "추가 과금 서비스"로 계약서를 변경해 해결하기로 했어요.
표준 업무를 정의하고 나니 비로소 자동화 대상이 생겼습니다. 세 명의 작업자가 하는 일은 크게 네 단계로 그룹핑됐어요.
- 스크랩된 온라인 페이지에서 전반적인 정보를 정리한다
- 고객사 정보의 오남용 여부를 권리 사용과 연관지어 증빙 문서를 첨부한다
- 각 온라인 페이지의 양식에 맞는 서술을 작성한다
- 기타 선택적 부가 정보를 메모하여 제출한다
이 네 단계가 작업 완료 시간에서 차지하는 비중도 정확하지는 않아도 정량화 할 수 있었습니다. 이걸 알아내기 위해 총 200개의 작업에 대해, 작업 시작 시각·종료 시각·특이사항을 직접 기록하는 데이터 작업을 진행했어요. 데이터를 정리하면서 나오는 엣지 케이스는 손수 보정하고, 왜 엣지 케이스로 판단했는지도 함께 남겼습니다.
우리가 해결하려 했던 건 전체의 0.38%였다
그리고 우리는 발견했습니다.
"뭐라도 해보자"고 시작했던 그 일이 실은 — 전체 작업 유형 중 20%, 그 중 15%의 행위, 그 중 여러 조건을 제외하면 겨우 0.38%에 불과한 해결방안을 모색하고 있었다는 것을.
유쾌한 발견은 아니었습니다.
지금도 부끄러운 일이에요. PM 경력이 짧지 않은데, 너무 초보적인 실수를 했다고 생각합니다.
변명을 해보자면, 이 프로젝트의 총괄이 PM이 아니었다는 점, 그리고 데이터 포인트가 부족해 경험 기반 서술에 의존해 일을 시작할 수밖에 없었다는 점이 치명적으로 작용했어요. 하지만 그게 이유가 되지는 않는다는 걸 압니다.
이미 방향을 잃은 프로젝트를 다시 중심 잡는 건 정말 쉽지 않았어요. 처음부터 제대로 시작하는 것보다 몇 배 더 많은 에너지가 필요했습니다.
이 일을 왜 해야 하는지, 해결했을 때 무엇을 기대할 수 있는지, 언제 이 프로젝트를 끝냈다고 말할 수 있는지. 이건 도메인이 바뀌어도, 일하는 방법이 바뀌어도 변하지 않는 것인데, 제가 큰 실수를 했습니다.
그래서 지금은 이렇게 일합니다
지금은 모든 작업물의 유형별·행위별 영향도를 미리 정리해두는 것은 물론, AI 기술이 개발됐을 때의 정확도(Accuracy)와 기술 적용에서 보장하지 않는 Scope out 영역까지 계산할 수 있는 매트릭을 미리 만들어두고 우선순위를 결정합니다.
공식으로 표현하면 이렇습니다.
일의 비중 × 그 일의 단위 행위 소요시간 × 정확도 × 필터 아웃 비중
위에서 언급한 0.38%의 영향도, 실제 숫자를 대입하면 이렇습니다.
21.79% × 18.2% × 64% × 15% = 약 0.38%
처음에 "뭐라도 해보자"고 시작했던 그 일의 실제 임팩트였습니다. 이 매트릭이 있으면 "이 기능을 먼저 할 것인가, 저 기능을 먼저 할 것인가"라는 질문에 근거를 갖고 답할 수 있습니다. 그리고 0.38%라는 숫자가 나왔을 때, "이게 지금 가장 중요한 일인가"라는 질문도 비로소 할 수 있게 됩니다.
그리고 현재는 새로운 과제가 생겼어요. 지금까지 개발한 많은 솔루션들이 특정 고성능 LLM 서비스에 의존하고 있는데, 토큰 비용이 인건비 못지않게 소모되고 있습니다. 그래서 다른 LLM 모델을 사용해도 유사한 성능을 보장하는 실험을 병렬로 진행 중이에요. 임팩트 계산이 자동화 착수 단계에서만 필요한 게 아니라, 운영 단계에서도 계속 필요하다는 것을 새삼 느끼고 있습니다.
이런 액션을 취해보세요
다음 프로젝트를 착수하기 전에, 이 세 가지 질문을 먼저 적어보세요.
- 이 문제를 풀면 누가, 얼마나 달라지는가?
- 지금 이걸 안 풀면 어떤 일이 생기는가?
- 지금 팀이 풀 수 있는 다른 문제들과 비교했을 때, 이게 가장 중요한가?
세 줄이면 됩니다. 근사한 문서가 아니어도 됩니다. 이 질문에 대답할 수 있는 상태가 된 다음에 착수해도 늦지 않아요.
근데 말이죠
그렇게 샘플링 데이터로 계산한 임팩트가 실환경과 동일한가요?
계산의 목적이 정확성이 아니라 방향성 설정과 프로젝트의 끝을 정하는 것이라면 이야기가 달라집니다. 정밀함이 부족한 추정이라도, 없는 것보다는 낫습니다. 방향을 잃지 않기 위한 최소한의 기준점이 필요한 거니까요.
또 한 가지. 임팩트 계산이 통하지 않는 상황도 있어요. "이 기능은 무조건 해야 해"가 위에서 내려오는 경우입니다. 그럴 때 임팩트 계산은 설득 도구가 됩니다. "이걸 왜 지금 하면 안 되는지", "저게 왜 더 중요한지"를 숫자로 보여주는 것. 계산이 없으면 그 대화 자체를 시작할 수가 없습니다.
"하면 된다"와 "하면 왜 된다"는 다릅니다. 전자는 방향이 없고, 후자는 방향이 있어요. 저는 그 차이를 몸으로 배웠고, 이 글을 읽는 PM들이 저와 같은 방식으로 배우지 않았으면 합니다.