김영욱
19시간 전
AI 프로덕트 매니지먼트 특별 연재 ④
모호한 내용을 평가 가능한 언어로 바꾸는 법
김영욱
Product Expert, SAP
1999년 9월, NASA의 우주선 하나가 화성 궤도에 진입하려다 그대로 사라졌습니다. 화성 기후 궤도선(Mars Climate Orbiter)이 9개월의 비행을 거쳐 목적지에 막 도착하려던 참이었습니다. 원인은 로켓 폭발도, 부품 결함도 아니었습니다. 놀랍게도 '계산 단위'의 차이였습니다.
우주선을 만든 콜로라도 팀은 추력 값을 미국식 단위(파운드힘·초)로 넘겼는데, 항법을 계산한 캘리포니아 팀은 그걸 미터법(뉴턴·초)으로 읽었습니다. 같은 숫자, 다른 단위. 받는 쪽은 매 분사를 실제의 4분의 1 크기로만 계산한 셈입니다. 그 미세한 오차가 9개월간 쌓여, 궤도선은 계획보다 한참 낮은 57km 고도로 대기에 처박혀 타버린 것이었습니다.
여기서 진짜 중요한 대목이 나옵니다. NASA의 결론은 "단위를 깜빡했다"가 아니었습니다. 단위는 두 팀이 공유하던 규격 문서에 이미 명시돼 있었습니다. 만든 쪽이 그 규격을 안 지켰고, 받는 쪽이 확인하지 않았을 뿐입니다. NASA의 공식 결론은 "문제는 오류 자체가 아니라, 그 오류를 잡아낼 검증 장치가 없었다."는 것으로 발표합니다.
두 팀 다 유능했습니다. 각자 자기 일은 훌륭히 해냈죠. 그런데 그 경계에서 사용하는 단위가 어긋났음을 아무도 확인하지 않았습니다. 이게 바로 프로덕트 팀에서 PM과 엔지니어 사이에 매일 벌어지는 일입니다. 그리고 그 어긋남은 대개, 이런 종류의 한마디에서 시작됩니다. "요즘 모델 답변 품질이 좀 떨어지는 것 같아요."
"정확도를 좀 높여주세요." PM이 엔지니어에게 흔히 하는 말입니다. 다른 뜻 없이 선의로 한 요청이죠. 그런데 이건 단위 없이 건네는 추력 값과 똑같습니다. 받는 사람이 제멋대로 해석할 수밖에 없거든요. 이 문장엔 중요한 네 가지가 빠져 있습니다.
무엇을 높이라는 건지(어떤 능력?), 얼마나 높이라는 건지(목표 수치?), 어떤 기준으로 측정하는지(무엇을 정확도라 부르나?), 그리고 왜 그게 중요한지(제품에 어떤 영향?). 이 넷이 없으면 엔지니어는 어디를 얼마나 손봐야 할지 알 수 없습니다. 한 사람은 프롬프트를 만지고, 다른 사람은 모델 교체를 검토하고, 또 다른 사람은 "지금도 충분히 정확한데?"라고 생각합니다. 화성 궤도선이 비행을 계속 이어가고 있는 모습이죠.
좋은 소식은, 이 모호함을 걷어내는 공식이 의외로 단순하다는 겁니다.
같은 상황을 두 가지로 말해보겠습니다.
두 문장의 차이가 보이시나요? 아래 문장에는 세 가지가 다 들어 있습니다.
이 관측 + 영향 + 기준 세 요소가 갖춰지면, 모호한 불평이 곧바로 실행 가능한 명세가 됩니다. 엔지니어는 무엇을 고쳐야 하는지, 어디까지 고치면 되는지, 왜 급한지를 한 번에 이해합니다.
연습 삼아 두 개만 더 바꿔볼까요.
"요약이 이상해요"
→ “회의록 요약 50건 중 8건에서 액션 아이템이 누락됐습니다. 후속 실행 누락으로 이어지므로, 액션 아이템 재현율 90%를 목표로 하겠습니다.”
"좀 느린 것 같아요"
→ "P95 응답 시간이 8초입니다. 3초를 넘으면 이탈률이 오르는 걸 확인했으니, P95 4초를 기준으로 잡겠습니다."
패턴이 보이시나요? 막연한 형용사(이상하다, 느리다, 떨어진다)를 숫자와 기준으로 바꾸는 것. 이것이 AI 프로덕트를 다루는 PM과 엔지니어가 해야 할 품질있는 대화의 첫 번째 기술입니다.
화성 궤도선의 교훈을 다시 떠올려 볼까요? 문제의 핵심은, 받는 쪽이 넘어온 값을 검증할 수 없었다는 것이었습니다. AI 품질 대화도 마찬가지입니다. 엔지니어가 검증할 수 있는 형태로 넘겨야 합니다.
"AI가 자꾸 이상한 답을 해요"라는 리포트는 고칠 수 없습니다. 재현이 안 되니까요. 반면 좋은 AI 버그 리포트는 딱 세 줄입니다.
이 세 줄이 있으면 엔지니어는 그 상황을 즉시 재현하고 원인을 좁혀갈 수 있습니다. 그리고 여기에서 부가가치가 나옵니다. 이 세 줄은 그대로 이밸(Eval)의 한 행이 됩니다. 앞선 글에서 이밸을 '제품의 라이벌'이라고 불렀죠. 잘 쓴 버그 리포트 하나가, 그 라이벌을 더 단단하게 만듭니다.
이전 글 살펴보기 >> PM은 AI를 어디까지 알아야 하는가
자, 이제 한 걸음 더 들어가 봅시다. "답이 틀렸다"는 같은 증상이라도, 원인은 완전히 다른 곳에 있을 수 있기 때문입니다. 담당을 나누기 전에 어느 레이어에서 난 문제인지부터 진단해야 합니다. 크게 네 곳입니다.
지시가 모호하거나 서로 충돌합니다. 실무에서 가장 흔하고, 가장 싸게 고쳐지는 유형입니다. 그래서 대개 여기부터 확인하는 게 경제적입니다.
모델은 맞게 답했는데, 사용자가 이해하기 어렵게 제시된 경우입니다. 모델을 아무리 손봐도 안 풀립니다. 이건 신뢰와 기대치를 설계하는 문제는 답에 출처를 함께 보여주거나, 불확실성을 솔직히 표시하는 식으로 풀 수 있습니다.
RAG가 가져 온 자료가 오래되었거나, 아예 없거나, 틀렸습니다. "그 정보가 애초에 우리 문서에 없거나 오래됐다"면 데이터 파이프라인을 봐야 합니다. 근거충실도 지표가 여기서 신호를 줍니다.
모델의 능력 한계나 환각 경향 때문입니다. "출처 문서에는 정답이 있었는데도 엉뚱하게 답했다"면 이쪽을 의심합니다. 해결책은 모델 교체나 파인튜닝을 해 보는 것인데 이건 가장 무겁고 비쌉니다.
핵심은 이겁니다. 같은 "틀린 답"이라도 이 넷 중 어디서 왔느냐에 따라 해결책도, 담당자도, 비용도 완전히 달라집니다. PM이 이 네 레이어를 구분할 수 있는 예를 들어 "출처 문서엔 정답이 있었나요?"(데이터냐 모델이냐)나 "프롬프트를 바꾸면 사라지나요?"와 같은 질문을 할 수 있으면 팀은 엉뚱한 곳을 파는 시간을 아낄 수 있습니다.
화성 궤도선의 두 팀에겐 인터페이스 규격이라는 공통 사양서가 있었습니다. 문제는 그 사양서를 함께 들여다보고 검증하지 않았다는 것이었죠. AI 프로덕트 팀에서 그것에 해당하는 게 바로 합의된 지표를 보여주는 대시보드입니다.
PM과 엔지니어가 각자 다른 지표 화면을 보면, 각자 다른 현실을 삽니다. 같은 숫자를 같은 화면에서 같은 의도로 해석된 내용을 봐야 이해가 시작됩니다. 그 내용엔 무엇이 있을 수 있을까요? 환각률, 근거충실도, 세션당 토큰 비용, P95 응답 지연, 인간 개입률, 부정 피드백률 정도면 출발점으로 충분합니다.
중요한 건 역할 분담입니다. 엔지니어는 이 숫자가 '기술적으로 왜' 그런지를 봅니다. PM은 이 숫자가 '사용자와 비즈니스에 무슨 의미'인지를 보고 설명합니다. 환각률이 3%에서 5%로 올랐을 때, 엔지니어는 원인을 찾고 PM은 "이 도메인에서 5%가 배포 가능한 수준인가"를 판단합니다. 두 관점이 같은 화면 위에 있을 때, 비로소 대화가 됩니다. 주간에 15분, '프로덕트 스크럼 미팅'으로 이 화면을 함께 보는 습관을 들이면, 대부분의 어긋남은 커지기 전에 잡힙니다.
마지막으로, AI 프로덕트 품질 대화에서 가장 자주 빠뜨리는 게 있습니다. AI는 코드가 바뀌지 않아도 동작이 바뀝니다. 모델 프로바이더가 어느 날 조용히 가중치를 업데이트하거나, 사용자 입력 패턴이 달라지거나, 외부 데이터가 변하면 어제까지 멀쩡하던 기능이 오늘 다르게 동작합니다. 이걸 드리프트(drift)라고 부르는데, 무서운 건 신호 없이 온다는 겁니다. 주 1~2%씩 조용히 쌓이다가, 3개월 뒤 15~20%의 품질 손실로 터집니다. 그리고 대개 다른 반응을 접한 사용자 불만이 폭발한 뒤에야 알아챕니다.
그래서 PM과 엔지니어가 미리 맺어둬야 할 약속이 두 가지입니다.
하나, 업데이트나 변경은 무조건 공지한다.
모델을 교체하거나 프롬프트를 수정하면 서로 알리고, 그 이력을 남깁니다. PRD가 배포 후에도 살아 있어야 하는 이유입니다. 지금의 이 기능이 어떤 변경을 거쳐 여기까지 왔는지가 곧 그 기능의 역사이고, 문제가 터졌을 때 가장 먼저 펼쳐볼 지도입니다.
둘, 배포엔 게이트키퍼를 둔다.
기능 변경·프롬프트 수정·모델 교체가 있을 때마다 이밸을 통과해야만 배포한다는 원칙입니다. 소프트웨어의 CI/CD 파이프라인에 테스트를 내장하는 것과 같습니다.
항공 관제에는 '복창(readback)'이라는 규칙이 있습니다. 관제탑의 지시를 조종사가 그대로 되읽어 확인하는 것이죠. 수많은 사고 끝에 만들어진 이 습관 하나가 치명적인 오해를 막습니다. AI 팀의 배포 관문이 정확히 그 복창입니다. 넘어온 변경은, 반드시 되읽고 확인하십시오.
최근 엔지니어에게 준 품질 피드백 하나를 떠올려, '관측 + 영향 + 기준' 세 요소로 다시 써보세요. 빠진 요소가 있다면, 그게 그동안 대화가 겉돌던 이유입니다.
다음 버그 리포트는 "입력 / 기대 출력 / 실제 출력" 세 줄로 정리해보세요. 재현되는 리포트 하나가, 열 번의 "이상해요"보다 낫습니다.
"답이 틀렸다"는 말 앞에서 한 번 멈추세요. 그리고 물으세요. "이거, 프롬프트 / UX/ 데이터/ 모델 중 어디서 난 문제지?" 이 질문 하나가 엉뚱한 곳을 파는 노력을 아낍니다.
화성 궤도선의 두 팀은 무능하지 않았습니다. 세계 최고 수준이었죠. 그들이 놓친 건 실력이 아니라, 경계에서 주고받는 인터페이스의 빈도와 정밀함이었습니다.
AI 프로덕트팀도 다르지 않습니다. PM과 엔지니어가 아무리 유능해도, 품질을 이야기하는 공통 언어가 없으면 제품은 조용히 57km 아래로 떨어집니다. 그리고 그 언어를 만들고 해석하고 번역하는 일은 다른 누구도 아닌 PM의 역할입니다.
위 콘텐츠는 『AI 프로덕트 매니지먼트』김영욱 저자가 작성한 특별 기고문입니다.
『프로덕트 매니지먼트』로 PM의 성장 가이드를 제시한 김영욱 저자가 이번에는 AI 시대에 맞춰 PM의 역할과 책임을 다시 정의합니다. 책은 소프트웨어와 AI 시스템이 근본적으로 어떻게 다르게 작동하는지에서 출발해 AI 프로덕트에서 발생하는 새로운 실패를 설계 단계부터 어떻게 다뤄야 하는지, 그 판단이 PRD와 지표, 팀의 협업 방식을 어떻게 바꾸는지 짚습니다.
더 나아가 AI PRD와 평가 플랜 작성, 하네스 설계, AI 지표와 모니터링, 머신러닝 엔지니어와의 협업까지. 아이디어를 실제 프로덕트로 만들고 운영하는 전 과정을 한 권에 담았습니다. 과거의 PM이 '어떤 기능을 만들 것인가'를 결정했다면, AI 시대의 PM은 '시스템이 어떻게 동작하고, 틀리며, 오류를 어떻게 설계할 것인가'까지 책임져야 합니다. AI를 ‘프로덕트’로 만드는 방법이 필요한 모든 분께 추천합니다.
0
0 
댓글