좋은 답을 받는 PM은 도구를 바꾸기 전에 질문을 먼저 바꾼다.
최근 PM들과 AI 활용에 대해 논할 때, "써봤는데, 생각보다 바보 같은 답이 많다."는 이야기를 자주 듣는다. 이 평가는 절반은 진실이며 절반은 오해를 담고 있다. 현업에서 발견하는 문제는 AI의 본질적인 한계보다, 오히려 질문 자체의 한계에서 비롯되는 경우가 더 많다.
특히 팀에서 급하게 기능을 준비할 때 이러한 현상은 더욱 두드러진다. 회의가 끝나고 각자 할 일이 쏟아지는 상황에서, PM은 AI에게 성급히 "PRD 작성해 달라"라고 요청한다. 그러나 이러한 질문에는 핵심적인 정보가 누락되어 있다.
왜 이 기능을 만드는지,
주된 사용자는 누구인지,
이번 분기의 핵심 지표는 무엇인지,
현재 팀 리소스로 가능한 범위는 어디까지인지 등,
맥락과 목표, 제약 조건, 판단 기준이 부재한 상태로 질문하는 것이다. 그리고 부실한 정보를 기반으로 AI가 제시하는 결과물이 평범할 수밖에 없다. 게다가, 팀원들과 공유한 문서들이 AI가 작성한 듯한 틀에 박힌 문구들로 가득할 때, 기획서에 대한 신뢰도는 더욱 하락한다. 이는 마치 제대로 검토되지 않은 문서를 보는 듯한 인상을 주며, 심지어 이 문서를 작성한 사람이 과연 내용을 제대로 이해하고 있는지에 대한 근본적인 의구심마저 들게 한다.
우리가 동료에게 단순히 "이것 좀 해줘"라고만 지시하지 않듯, AI에게도 마찬가지이다.
무엇을 위해, 어떤 기준으로, 어느 범위까지의 결과를 원하는지 명확히 제시해야 비로소 실질적인 가치를 지닌 결과물을 얻을 수 있다. 궁극적으로 AI 활용의 핵심은 단순히 도구 숙련도를 넘어, 얼마나 효과적으로 질문을 설계하는지에 달려 있다.
실무에서 효과적인 AI 활용 방식은 의외로 단순하다. 거대한 업무를 통째로 맡기기보다, 우선 PM 스스로 오류나 업무의 병목 현상이 자주 발생하는 지점을 정확히 파악하고, 해당 문제를 본인이 더 잘 해결할 수 있을지, 아니면 AI의 도움을 받는 것이 효과적일지 판단하는 것이다.
예를 들어, 가설 점검 시 단순하게 "이 기능 괜찮은가?"라고 묻는 것과 "빠르게 검증 가능한지, 측정 가능한지, 임팩트 대비 난이도가 적절한지 기준으로 평가해 달라"라고 구체적인 기준을 제시하는 질문은 그 결과가 확연히 다르다. 전자는 피상적인 의견 수렴에 그치지만, 후자는 즉시 실행 가능한 실험 항목과 우선순위 설정으로 이어진다.
이벤트 로깅에 대한 설계 또한 마찬가지이다. 트래킹 정의를 모호하게 설정하면, 출시 후 데이터가 충분히 쌓여도 유의미한 퍼널 분석이 어려워진다. 뒤늦게 "왜 전환율이 떨어졌을까?"를 분석하려 해도 이미 늦는 경우가 많다. 따라서 사전에 "퍼널 분석 가능성, 네이밍 및 파라미터 일관성을 기준으로 중복, 누락, 애매한 항목만을 식별해 달라"라고 요청하면, 개발 착수 전에 발생할 수 있는 잠재적 문제를 효과적으로 줄일 수 있다.
이러한 관점에서 나는 AI에게 보통 다음과 같은 방식으로 질문을 던진다.
가설 점검: "이 기능의 핵심 가설 3가지를 점검하라. 평가 기준은 빠르게 검증 가능한지, 측정 가능한지, 임팩트 대비 구현 난이도가 적절한지이다. 각 가설별로 발생할 수 있는 문제점과 간단한 검증 방법을 제안하라."
이벤트 로깅 점검: "이 트래킹 설계를 검토하라. 기준은 퍼널 분석이 가능할 정도로 정의가 명확한지, 이벤트명과 파라미터가 일관적인지이다. 중복되거나 누락된 항목, 혹은 애매한 정의만을 간략하게 지적하라."
이 정도의 접근만으로도 팀 전체가 체감하는 업무 효율성은 확연히 달라진다.
개발자와는 "이것은 명확히 정의되었고, 이것은 추가 논의가 필요하다"는 점을 더욱 신속하게 합의할 수 있게 되고, 디자이너와는 플로우 상에서 발생할 수 있는 예외 케이스를 더 이른 단계에서 발견하는 것이 가능해진다. 그리고 궁극적으로 이러한 방식은 커뮤니케이션에 소요되는 비용을 절감하고, 의사결정이 지연되는 구간을 단축시키는 효과를 가져온다.
이러한 이유로 PM은 AI의 활용을 단순히 "자동화"를 넘어 "정밀화"의 관점에서 바라봐야 한다. AI는 PM의 업무를 전적으로 대체하는 도구가 아니다. 오히려 PM이 간과하기 쉬운 판단의 사각지대나 협업 과정에서의 미세한 간극을 더욱 정교하게 메우는 데 기여한다.
결론적으로, 중요한 것은 거창하고 복잡한 프롬프트 작성 기술이나 새로운 기술을 도입하는 것이 중요한 게 아니다. PM이 자신의 업무 중 자주 막히거나 오류가 발생했던 지점을 명확히 발견하고, 해당 문제에 대해 명확한 기준을 가지고 AI에게 재차 점검을 요청하는 것이 기반이 된다면, 그런 문제를 더 잘 해결할 수 있는 여러 도구들이 보이게 되고, 그중에서 가장 좋은 것을 찾아 쓰는 과정에서 본인의 생각이 더 명확해질 것이다. 그리고 그런 PM들의 AI 활용은 실질적인 성과와 차이를 만들어낼 수 있다고 생각한다.