김영욱
2시간 전
AI 프로덕트 매니지먼트 특별 연재 ➂
김영욱
Product Expert, SAP
지난 5월, SAP의 사용자 콘퍼런스에 세계적인 테니스 선수 로저 페더러가 올랐습니다. 그랜드 슬램을 스무 번 들어 올린 그 전설의 선수입니다. 인터뷰를 시작합니다. "당신은 코트에서 늘 여유로워 보였어요. 힘든 티가 안 났죠." 페더러가 웃으며 답합니다. “그건 오해입니다. 평온한 것처럼 보이려 애썼지만, 속에서는 늘 화산이 터지고 있었죠."
그리고는 그는 커리어에서 결정적 전환점을 하나 이야기합니다. 20대 초반, 그는 태도에 대해서, 준비에 대해서, 뜻대로 안 된 결과에 대해서 늘 핑계를 대던 선수였습니다. 그러다 핑계를 그만두자 뜻밖의 일이 벌어졌습니다. "승리가 찾아오기 시작하고, 그때부터 왜 졌는지가 곧바로 선명하게 보였습니다. 이 포핸드 때문이었구나, 아니면 경기를 이렇게 풀었어야 했구나. 아주 빠르게 명확해졌고, 그때부터 그 부분에만 집중하고 나아갈 수 있었죠."
핑계를 버리자, 진단이 선명해진 겁니다.
AI 프로덕트를 맡은 PM에게도 똑같은 순간이 옵니다. 여러분의 AI 기능이 어느 날 이상한 답을 내놓습니다. 사용자가 항의합니다. 여러분은 이때 왜 그런 일이 벌어졌는지 말할 수 있습니까? 왜 검색이 엉뚱한 문서를 물어왔는지, 왜 프롬프트가 부실했는지, 아니면 모델이 환각을 일으킨 건지 말입니다. 아니면 "AI는 원래 다 그렇죠"라는 핑계에서 멈춥니까?
이 둘의 차이는 바로, AI를 얼마나 아느냐입니다. 그리고 오늘의 질문은 “AI PM은 AI를 도대체 어디까지 알아야 할까요?” 입니다. 모델을 직접 만들 정도로? 그건 아니지요. 하지만 "AI가 원래 그렇다"에서 라는 대답은 안되겠죠.
먼저 분명히 말씀드립니다. PM은 모델을 훈련시키지 않습니다. 벡터 데이터베이스를 고르지도, 파이썬으로 평가 스크립트를 짜지도 않습니다. 그건 엔지니어의 일입니다.
하지만 여기 오래된 진실이 하나 있습니다. 관리할 수 없는 것은, 결국 이해하지 못한 것입니다. 토큰이 뭔지 감이 없는 PM은 다음 달 비용 청구서 앞에서 속수무책입니다. 환각이 뭔지 모르는 PM은 고객에게 "이 기능은 100% 정확합니다"라고 약속했다가 릴리즈 후에 크게 데입니다.
페더러는 라켓 줄을 직접 감지 않습니다. 하지만 어떤 장력이 자기 플레이에 맞는지는 정확히 압니다. AI PM도 마찬가지입니다. 엔지니어가 될 필요는 없습니다. 하지만 게임의 규칙은 알아야 합니다. 그럼 그 '규칙'의 최소 집합에 대해서 이야기 해 볼까요?
여섯 개면 충분합니다. 다만 전부 똑같은 비중으로 알 필요는 없습니다. 실무에서 매일 부딪히는 두 쌍은 조금 깊게, 나머지 한 쌍은 개념 정도 잘 이해하면 됩니다.
AI는 글자를 '토큰'이라는 조각 단위로 처리합니다. 여기서 중요한 건 이겁니다. AI 비용은 사용자 수가 아니라 토큰 수로 매겨집니다. 사용자가 긴 대화를 나눌수록, 문서를 많이 붙일수록, 시스템 프롬프트가 길수록 토큰이 쌓이고 그대로 돈이 됩니다. PM이 "이 기능, 사용자당 토큰을 얼마나 쓰지?"를 묻지 못하면 비용은 통제 밖으로 나갑니다.
컨텍스트 윈도는 모델이 한 번에 볼 수 있는 토큰의 최대치, 즉 작업 기억의 크기입니다. 이 범위를 벗어난 내용은 모델에게 존재하지 않는 것과 같습니다. 사용자가 한참 전에 한 말을 모델이 "까먹은 것처럼" 구는 건 버그가 아니라 이 구조적 한계 때문입니다. 긴 문서를 다루는 기능을 설계한다면, PM은 이 한계를 반드시 계산에 넣어야 합니다.
여기가 PM 사고의 핵심 전환입니다. 기존 소프트웨어는 같은 입력에 같은 출력을 냈습니다. AI는 같은 질문에도 매번 조금씩 다른, '가장 그럴듯한' 답을 확률적으로 만듭니다. 그리고 때로는 그럴듯하게 틀립니다. 존재하지 않는 사실을 확신에 차서 말하는 것, 이게 환각입니다.
여기서 페더러의 유명한 숫자 하나가 정확히 들어맞습니다. 그는 커리어 통산 경기의 약 80%를 이겼습니다. 그런데 그가 딴 개별 포인트는 전체의 54%에 불과했습니다. 거의 절반은 내주면서도 경기를 이긴 겁니다. 그가 다트머스 졸업 연설에서 이 숫자를 꺼내며 한 유명한 말이 있습니다.
"우리는 늘 이길 수 없습니다. 우리는 때때로 완벽을 추구하죠.
너무 완벽하려다 그 때문에 부서집니다. 이기는 게 전부가 아닙니다. 과정입니다."
AI 출력도 포인트와 같습니다. 모든 출력이 완벽할 필요는 없습니다. 환각률을 0으로 만들어달라는 요구는 현재 기술로 불가능하고, 그걸 좇다간 제품이 부서집니다. PM이 할 일은 완벽을 좇는 게 아니라, 도메인에 맞는 허용 임계값을 정하는 것입니다. 의료 정보 AI라면 환각률 1%도 위험하지만, 창작 보조 AI라면 5~10%도 괜찮을 수 있습니다. 이 선을 어디에 그을지는 엔지니어가 아니라 PM의 판단입니다.
마지막 한 쌍은 개념만 잡아봅시다. 임베딩은 텍스트를 숫자 벡터로 바꾼 것으로, 의미가 비슷한 문장끼리 가까운 좌표에 놓이게 만드는 기술입니다. 이걸 이용해 방대한 문서 더미에서 질문과 관련된 내용만 찾아 모델에게 함께 건네주는 방식이 RAG입니다. 왜 중요할까요? 범용 모델은 우리 회사 내부 문서를 모릅니다. RAG는 그 간극을 메워, 모델이 '우리 데이터'에 근거해 답하게 만드는 가장 흔한 방법입니다. PM이 여기서 챙길 지표는 꽤 많은데, 그중 하나가 답변이 실제 출처 문서에 얼마나 충실한가를 판단하는 근거충실도(groundedness) 입니다.
이 세 개념을 알면 자연스럽게 실무의 갈림길이 보입니다. AI 기능을 개선하는 길은 크게 셋입니다.
가장 먼저는 프롬프트 개선입니다. 빠르고 싸고 위험이 적습니다. 대부분의 문제는 사실 여기서 풀립니다. 프롬프트로 충분하면 굳이 더 나갈 필요가 없습니다.
프롬프트로 안 되면 RAG입니다. 모델이 모르는 우리 데이터나 최신 정보가 필요할 때죠. 사내 문서, 최신 정책, 제품 매뉴얼 같은 걸 답변 근거로 대야 할 때 선택합니다.
마지막이 파인튜닝입니다. 책에서 정리한 선택 기준은 셋입니다. 의료·법률처럼 도메인 특화 언어가 필요할 때, 특정 출력 형식이나 톤을 일관되게 강제해야 할 때, 그리고 긴 지침을 모델에 내재화해 추론 비용을 줄이고 싶을 때입니다. 단, 파인튜닝은 비싸고 느리며, 데이터가 부족하거나 품질이 낮으면 오히려 독이 됩니다. 최후의 수단으로 두는 게 맞습니다.
여기서 한 가지 주의할 점. 이 셋 중 무엇을 쓸지 기술적으로 최종 결정하는 건 엔지니어입니다. PM이 "그럼 파인튜닝합시다"라고 결론 내리면 월권입니다. PM의 몫은 세 길의 트레이드오프를 이해하고, "우리 문제엔 왜 이 길이 맞는가"를 제품 목표로 함께 따져보는 것입니다. 그래야 회의에서 헛다리를 짚지 않습니다.
이쯤에서 선을 그어볼까요? 페더러에겐 팀이 있었습니다. 스트링 장력은 스트링어가, 훈련 프로그램은 코치가, 몸 관리는 물리치료사가 맡았죠. 하지만 코트 위에서 지금 이 공을 어디로 칠지, 이 상대를 어떻게 공략할지는 오직 페더러 본인이 결정했습니다. AI 팀에서 PM의 자리도 정확히 그렇습니다.
모델 아키텍처, 벡터DB 선택, 온도(temperature)나 에포크 같은 하이퍼파라미터, 임베딩 모델 튜닝. 이런 기술적 세부에 PM이 끼어들면 전문성 침해이고, 엔지니어의 신뢰만 잃습니다.
어떤 문제를 풀 것인가, 얼마나 정확해야 '충분한가', 틀렸을 때 사용자 피해는 어느 정도인가, 비용과 품질 중 무엇을 우선할 것인가, 어떤 데이터를 넣을 것인가.
한 줄로 요약하면 이렇습니다. 엔지니어는 '어떻게(How)'를, PM은 '왜·무엇(Why·What)'을 책임집니다. 회의에서 PM이 던져야 할 질문도 여기서 나옵니다. "이 기술 지표가 우리 제품 지표와 어떻게 연결되나요?" "실패하면 사용자는 어떤 경험을 하게 되나요?" How를 묻지 않고 Why와 What을 묻는 것 바로 그게 PM의 언어입니다.
자, 여기까지 왔으면 마지막 질문이 남습니다. 그럼 이 모든 개념을 다 공부한 다음에야 AI 제품을 만들 수 있을까요? 아닙니다. 그전에 길러야 할, 더 중요한 능력이 하나 있습니다.
페더러에게는 커리어 초반에 진짜 라이벌이 없었습니다. 항상 이기는 경기가 많아서 좋았습니다. 그러다 라파엘 나달, 노박 조코비치, 앤디 머리가 연이어 나타납니다. 훗날 그는 이렇게 말합니다.
"저에겐 나달이 필요했고, 조코비치와 앤디가 필요했습니다. 그들이 제 결함을, 제 정신적 약점을, 제 신체적 한계를 드러내 줬으니까요." 혼자 뒀다면 그는 편안한 자리에 안주했을 겁니다. 라이벌이 있었기에 그는 자기 게임을 끊임없이 뜯어 고쳤습니다. 중요한 건, 라이벌이 준 게 막연한 압박이 아니라 구체적이고 명료한, 풀어야 할 문제였다는 점입니다.
AI 프로덕트에서는 그 라이벌의 이름이 바로 이밸(Eval)입니다.
이밸은 AI의 출력이 얼마나 좋은지를 체계적으로 측정하는 장치입니다. "AI가 좀 별로다" 같은 막연한 불평이 아니라, "다단계 질문에서 환각률이 12%다", "배송 문의의 30%에 엉뚱한 답을 한다"처럼 약점을 구체적으로, 반박 불가능하게 드러내주죠. 이밸 없이 배포된 AI 제품은 라이벌 없는 선수와 같습니다. 데모에선 그럴듯해 보이다가, 실전에서 조용히 무너집니다. 책에서는 이걸 계기판 없이 고속도로를 달리는 것에 비유합니다.
그래서 저는 이렇게 말하고 싶습니다. AI 개념을 달달 외우기 전에, 이밸을 설계할 줄 아는 능력을 먼저 기르십시오. 개념은 일하다 보면 붙습니다. 하지만 제품을 평가할 줄 모르면, 그 지식이 실제 제품에서 쓸모가 있는지조차 알 수 없습니다.
이밸의 실제 구현은 엔지니어가 합니다. PM이 파이썬 코드를 짤 필요는 없습니다. PM이 할 일은 무엇을, 어떤 기준으로 평가할지를 정하는 것 입니다. 즉 어떤 케이스가 실제 사용을 대표하는지, 합격선을 몇 %로 그을지, 정확성·속도·비용 중 무엇을 우선할지입니다. 이건 기술 판단이 아니라 제품 판단이고, 그래서 PM의 일입니다.
지금 맡은 AI 기능 하나를 골라, "이게 잘 작동한다는 걸 나는 어떻게 알 수 있지?"를 다섯 개의 구체적 케이스로 적어보세요. 브라보! 방금 여러분의 첫 이밸을 만든 겁니다.
위 여섯 개념을 한 번에 다 공부하려 들지 마세요. 지금 내 프로덕트에 직접 걸리는 것 하나부터. 비용이 걱정이면 토큰부터, 신뢰가 걱정이면 환각부터입니다.
다음번 AI가 헛소리를 하면, "AI가 원래 그렇지"에서 멈추지 마세요. 페더러처럼 한 단계 파고드세요. "왜? 검색이 문제였나, 프롬프트였나, 모델이었나?" 이 한 번의 질문이, 핑계와 진단을 가릅니다.
페더러는 은퇴 후에도 그 54%의 이야기를 자주 꺼냅니다. 절반 가까이 지고도 챔피언이 될 수 있었던 건, 매 순간의 완벽이 아니라 과정을 붙들었기 때문이라고요.
PM도 다르지 않습니다. AI의 모든 것을 완벽하게 알 필요는 없습니다. 정말 필요한 건, 내 제품의 약점을 끊임없이 드러내 주는 좋은 라이벌 하나 이밸과, 그 앞에서 게임을 읽어낼 줄 아는 PM의 직관입니다. 페더러에게 나달이 그랬듯이. 여러분의 AI 프로덕트에도, 이밸이 필요합니다.
위 콘텐츠는 『AI 프로덕트 매니지먼트』김영욱 저자가 작성한 특별 기고문입니다.
『프로덕트 매니지먼트』로 PM의 성장 가이드를 제시한 김영욱 저자가 이번에는 AI 시대에 맞춰 PM의 역할과 책임을 다시 정의합니다. 책은 소프트웨어와 AI 시스템이 근본적으로 어떻게 다르게 작동하는지에서 출발해 AI 프로덕트에서 발생하는 새로운 실패를 설계 단계부터 어떻게 다뤄야 하는지, 그 판단이 PRD와 지표, 팀의 협업 방식을 어떻게 바꾸는지 짚습니다.
더 나아가 AI PRD와 평가 플랜 작성, 하네스 설계, AI 지표와 모니터링, 머신러닝 엔지니어와의 협업까지. 아이디어를 실제 프로덕트로 만들고 운영하는 전 과정을 한 권에 담았습니다. 과거의 PM이 '어떤 기능을 만들 것인가'를 결정했다면, AI 시대의 PM은 '시스템이 어떻게 동작하고, 틀리며, 오류를 어떻게 설계할 것인가'까지 책임져야 합니다. AI를 ‘프로덕트’로 만드는 방법이 필요한 모든 분께 추천합니다.
0
2 
댓글