AI 시대의 프로덕트 매니저: 새로 필요한 역량

AI 기능을 맡게 된 프로덕트 매니저가 가장 먼저 부딪히는 것은 기술 용어가 아닙니다. 회의실에서 나오는 낯선 질문들입니다. “몇 번 중에 몇 번 맞으면 내보내도 되나요?”, “틀린 답을 믿고 일한 직원이 생기면 누가 책임지나요?”, “다음 달 청구서는 얼마나 나오나요?” 이 시리즈의 마지막 글에서는 한 회사의 장면을 따라가며, AI 기능을 맡은 프로덕트 매니저가 새로 답해야 하는 질문이 무엇인지 정리하겠습니다.

장면: 사내 문서 요약 기능을 내놓기까지

직원 수백 명 규모의 한 국내 회사가 사내 문서 요약 기능을 만들기로 했습니다. 회의록, 보고서, 규정집을 열면 위쪽에 몇 줄 요약이 뜨는 기능입니다. 담당 프로덕트 매니저 김 과장은 처음에 평소처럼 요구사항 문서를 쓰려고 했습니다. “문서를 열면 요약을 보여 준다. 요약은 다섯 줄 이내.” 그런데 개발자가 시험판을 돌려 보니 같은 회의록을 두 번 넣었는데 요약이 조금씩 달랐습니다. 대부분은 쓸 만했지만, 가끔 회의에서 정하지 않은 결정을 정한 것처럼 적기도 했습니다.

여기서 김 과장은 일반 기능을 만들 때는 정할 필요가 없던 세 가지를 정해야 했습니다.

첫째, 무엇을 ’맞았다’고 볼지 미리 정한다

버튼이나 결제 화면은 동작하는지 안 하는지로 확인할 수 있습니다. 요약은 다릅니다. AI 모델은 같은 입력에도 매번 다른 결과를 낼 수 있어서, 한 번 해 보고 “잘 된다”고 말할 수 없습니다.

김 과장은 먼저 “좋은 요약”의 뜻을 팀과 함께 글로 적었습니다. 원문에 없는 내용을 지어내지 않을 것, 결정 사항과 담당자를 빠뜨리지 않을 것, 다섯 줄을 넘지 않을 것. 그다음 실제 업무 문서 가운데 대표적인 것 수십 건을 골라 시험용 묶음을 만들고, 사람이 직접 모범 요약을 써 두었습니다. 모델이나 지시문을 바꿀 때마다 이 묶음으로 다시 돌려 보고, 기준을 몇 건이나 지키는지 셉니다.

중요한 것은 출시 기준을 숫자로 미리 합의했다는 점입니다. “지어낸 내용은 한 건도 없어야 하고, 결정 사항 누락은 이 정도까지 받아들인다”처럼 정해 두면, 출시 회의가 “좋아 보인다”, “아직 불안하다”는 느낌 싸움이 되지 않습니다. 기준은 문서 종류마다 다를 수 있습니다. 회의록은 조금 거칠어도 괜찮지만 규정집 요약은 훨씬 엄격해야 할 수 있습니다.

둘째, 틀렸을 때 어떻게 되는지 설계한다

시험 묶음을 아무리 잘 만들어도 틀린 요약은 나옵니다. 그래서 김 과장은 “틀리지 않게 하는 법”과 함께 “틀렸을 때 피해가 작게 끝나는 법”을 화면에 넣었습니다.

요약 바로 아래에 “AI가 만든 요약입니다. 중요한 판단은 원문으로 확인하세요” 문구와 원문 해당 위치로 가는 링크를 둔다.
요약이 틀렸을 때 누르는 버튼을 두고, 눌린 사례는 매주 모아 시험 묶음에 더한다.
인사 기록이나 계약서처럼 틀리면 피해가 큰 문서는 처음에는 요약 대상에서 뺀다.

일반 기능에서 오류는 고쳐야 할 결함입니다. AI 기능에서는 일정한 비율의 오류가 처음부터 생긴다고 보고, 그 오류를 사용자가 알아차리고 되돌릴 수 있게 만드는 것까지가 제품 설계입니다.

셋째, 한 달에 얼마가 드는지 계산한다

김 과장이 가장 늦게 깨달은 것은 비용이었습니다. 보통 소프트웨어는 한 번 만들면 사용자가 늘어도 운영비가 크게 늘지 않습니다. 반면 외부 AI 모델을 쓰는 기능은 요약을 한 번 만들 때마다 사용료가 붙습니다. 문서가 길수록, 사용자가 많을수록 청구서가 커집니다.

그래서 출시 전에 간단한 계산을 했습니다. “요약 한 번에 드는 값 × 하루 요약 횟수 × 한 달 근무일”. 그리고 이 숫자를 줄일 수 있는 선택지를 함께 검토했습니다. 같은 문서는 한 번 만든 요약을 저장해 다시 쓰기, 사용자가 요약 버튼을 눌렀을 때만 만들기, 짧은 문서에는 값이 싼 모델 쓰기. 기능의 가치를 따질 때 “직원들이 좋아하는가”만이 아니라 “그 편의가 매달 드는 돈만큼의 값을 하는가”를 같이 묻게 된 것입니다. 이 계산을 미리 해 두지 않으면, 사용자가 늘어 기능이 성공할수록 비용 때문에 기능을 줄여야 하는 일이 생길 수 있습니다.

그대로 남는 것: 왜 만드는가

세 가지가 새로 생겼지만, 김 과장이 가장 오래 고민한 질문은 따로 있었습니다. “직원들이 정말 요약이 없어서 불편한가?” 인터뷰를 해 보니 불편의 중심은 문서가 길다는 것보다, 지난 회의에서 무엇을 정했는지 찾기 어렵다는 데 있었습니다. 그래서 첫 출시 범위를 모든 문서의 요약에서 “회의록의 결정 사항과 담당자 뽑기”로 좁혔습니다.

AI가 결과물을 빨리 만들어 줄수록, 무엇을 만들 가치가 있는지 고르는 일은 사람에게 남습니다. 문제를 찾고, 범위를 좁히고, 하지 않을 일을 정하는 것은 이 시리즈에서 다룬 디스커버리, 전략, 우선순위 그대로입니다. 앞의 세 질문도 이 답이 서야 정할 수 있습니다. 문제가 좁혀지자 시험 묶음에 넣을 문서도, 틀리면 안 되는 부분도, 하루 요약 횟수도 함께 분명해졌기 때문입니다.

내 일에 바로 써 보는 점검표

지금 맡고 있거나 검토 중인 AI 기능 하나를 떠올리고 아래 질문에 답해 보세요. 답을 쓸 수 없는 칸이 다음에 할 일입니다.

이 기능이 푸는 문제를 사용자의 말로 한 문장으로 쓸 수 있는가?
“좋은 결과”의 뜻을 팀이 같은 문장으로 적어 두었는가?
실제 업무 자료로 만든 시험 묶음과 사람이 쓴 모범 답이 있는가?
출시해도 되는 기준(지켜야 할 비율, 절대 허용하지 않는 오류)을 출시 전에 합의했는가?
결과가 틀렸을 때 사용자가 그것을 알아차리고 원문이나 사람에게 돌아갈 길이 있는가?
틀리면 피해가 큰 경우를 따로 골라 처음 범위에서 뺐는가?
한 번 쓸 때의 값, 예상 사용 횟수, 한 달 비용을 계산해 보았는가?
사용자가 지금의 열 배로 늘어도 그 비용을 감당할 수 있는가, 아니라면 줄일 방법이 있는가?

마무리

AI 기능을 맡은 프로덕트 매니저는 세 가지를 새로 정해야 합니다. 무엇을 맞았다고 볼지, 틀렸을 때 어떻게 되는지, 한 달에 얼마가 드는지. 이 세 가지는 모두 “이 기능을 왜, 누구를 위해 만드는가”라는 오래된 질문에 답한 뒤에야 제대로 정할 수 있습니다. 위 점검표는 그 순서를 지키기 위한 도구입니다.

이로써 프로덕트 매니지먼트의 기초부터 전략, 디스커버리, 솔루션, 빌드, 런치, 그로스, 그리고 AI 기능을 다루는 법까지 긴 길을 함께 걸었습니다. 이 시리즈에서 읽은 것을 여러분이 지금 맡은 제품 하나에 먼저 적용해 보시기 바랍니다.

참고: AI 기능을 맡은 프로덕트 매니저에게 품질 기준, 오류 대응, 사용 비용을 함께 묻는다는 생각은 여러 글에서 다뤄 왔습니다. 그 가운데 Product Map, “The 6 core skills every AI product manager needs in 2026”(productmap.io/blog/ai-product-manager-skills, 2026-07-23)을 참고했습니다. 본문의 장면과 점검표는 JSCampus가 새로 쓴 것입니다.