brunch

문제정의 없이 AI 도입하지 마세요

<AI 제품을 처음 만들게 된 PM에게> 브런치북 시리즈 - 후속편 #1

by Alicia in Beta
본 글은 <AI제품을 처음 만들게 된 PM에게 시리즈>
제2화. AI 제품은 왜 다르게 만들어야 하는가?(클릭 시 이동)의 후속입니다.


"GPT를 붙여볼까?"

"챗봇으로 자동화하면 사용자 만족도가 높아질까?"


요즘 많은 팀에서 AI 도입을 논의할 때 가장 먼저 나오는 질문들이다.


AI는 분명 새로운 기회이고, 누구나 이전보다 쉽게 강력한 도구를 쓸 수 있는 시대가 되었다.

또한 반드시 문제 해결적 접근이 아니더라도, 좋은 기술이 인간의 삶에 긍정적인 영향을 줄 수 있다는 점에서 AI는 단지 문제 해결 도구를 넘어선 가능성을 품고 있다.


하지만 그렇다고 해서 "일단 붙여보자"는 접근이 정답이 되는 건 아니다. 도입 그 자체가 목표가 되면 실패해도 원인을 알 수 없고, 무엇이 잘못됐는지도 알 수 없으며, 심지어 제품 자체의 방향이 흔들릴 수 있다. 무엇보다 사용자가 써야 하는 이유가 무엇이 될 것인가?


그래서 나는 이 글을 통해 AI를 도입하더라도, 구조적으로 검토하고 설계하자는 이야기를 하고 싶다.

(도입하지 말자는 건 아니다. 조금 더 구조적으로 접근하자는 것이다.)


그 첫걸음은 우리가 정확히 풀고자 하는 문제가 무엇인지 정의하는 일이다.




문제를 정의하지 않고 시작하면 생기는 일


아무리 AI가 세상을 뒤집고 있다 해도, AI를 썼다는 이유만으로 제품이 좋아지지 않는다. (그것은 마술...)

생성형 AI든 전통적 모델이든, 지금은 수단일 뿐이다.

게다가 다루기도 어렵고, 돈은 돈대로 들고, 정형화된 공식도 레퍼런스도 거의 없다.


그런데 많은 팀이 (제대로 된) 문제 정의 없이 '일단 붙여보자'는 식으로 AI 도입을 시도한다.

그 결과 모델 성능, UX 흐름, 실험 설계, 운영 구조 등 모든 지점에서 의사결정이 흐릿해지고,

그 모든 물음표는 PM/PO의 고통으로 되돌아온다.


심지어 최근엔 *AI Bubble(AI버블) 이야기까지 만연하다. 하지만 정말 AI가 문제일까?

그냥 유행이라서, FOMO(Fear-Of-Missing-Out)로, 일단 만들면 뭐라도 되겠지 싶어서 — 그저 '도입이 목표'가 되는 현상이 지금의 '거품'을 더 풍성하게 키우고 있다는 생각도 든다.

*AI버블: 실질적 수익 없이 거품만 잔뜩 낀 상황이며, 경제적/기술적으로 매우 불안정한 구조라 보는 관점


"저희 대표님이 우리도 당장 AI 붙이라는데 뭐부터 해야 하죠?ㅠㅠ"

<AI 제품을 처음 만들게 된 PM에게> 시리즈 작성의 계기를 준 후배 PM이 실제 나에게 했던 말이다.


그래서 나는 PO/PM분들께 이 글을 통해 전하고 싶다.

도입할 때 하더라도, 적어도 우리는 구조적으로 검토하고, 준비하고, 실험하며, 제대로 만들어보자고.


그 첫 단추로써 일단 제대로 된 문제정의부터 해보고, 그 문제를 해결할 방법이 정말 AI밖에 없는 것인지, 기존에 시도해 본 솔루션으로는 도무지 해결이 되지 않는지, 그 이유가 뭔지 등을 따져본 후 -- 솔루션의 '도구'로서 생성형 AI를 검토하고 도입하는 방향을 다시 한번 강조하고 싶다.




현상과 문제는 다르다


그렇다면 AI 제품 설계 시 '좋은 문제정의'란 무엇일까?

이건 사실 만국 공통어(?)인데, 현상과 문제부터 구분할 수 있어야 한다.


예를 들어 “고객 문의가 너무 많다”는 건 현상이다. 하지만 문제는 아니다.

그 현상이 왜 반복되고 있는지, 어떤 영향을 미치는지까지 파고들어야 비로소 문제가 드러난다.

반복적인 질문이 전체 문의의 60% 이상을 차지해서,
CS 인력이 중요한 케이스에 집중하지 못하고, 응대 품질과 팀 피로도가 동시에 하락하고 있다.

↑ 이게 문제다.


문제는 언제나 맥락 속에 있다. 정량/정성 데이터를 통해 원인과 영향을 연결해봐야 한다.




Output이 아닌 Outcome에 집중해야 한다


'챗봇 도입'은 Output이다.

“사용자가 빠르게 원하는 정보를 얻고, 팀은 더 중요한 일에 집중하게 되는 것”은 Outcome이다.


우리가 만들려는 건 단순 기능이 아니라 변화다.

결국 제품이 풀어야 하는 건 기술적 과제보다는 사람의 문제다. 기술은 그다음이다.


아래 표처럼 좋은 문제 정의는 현상에서 출발해 원인을 짚고, Outcome을 정의하고, 그 후에야 도구(예: AI)를 선택한다.


참고. 문제정의 나쁜 예와 좋은 예


AI 제품 역시 마찬가지다. 위의 표에서 보듯이 후자 형태가 되어야 도구로서의 AI가 등장할 이유가 보이기 시작한다. 그리고 이 구조로 생각하지 않으면, 우리가 겪게 될 실패는 전부 원인 불명이 되어 버린다. (지옥의 문..)




문제 정의 후, 그다음 단계는?


문제를 잘 정의했더라도, 그다음 단계는 바로 AI 도입이 아닐 수 있다.

정말 이 문제에 생성형 AI가 최적의 해결책인지—그건 또 다른 검토가 필요하다.


그래서 준비했다:

다음 편에서는 실제 현업에서 활용 가능한 [GenAI Fit Sheet] 템플릿을 공개한다.

'이 문제, 정말 AI여야만 하는가?'를 스스로 묻고,

팀과 함께 구조적으로 검토할 수 있도록 돕는다.




다음 편 예고:

[G-Fit Sheet] – AI 도입이 진짜 필요한 문제인지 구조적으로 검토하는 1-pager 템플릿 공개

(브런치 유료 멤버십 대상)




keyword
작가의 이전글나의 삶과 리더십 사이에서