PM을 위한 머신러닝 기초. AI 기능 기획할 때 알아야 할 것들

{ "title": "AI 기획, PM이라면 머신러닝 기초는 알아야지", "slug": "ai-planning-ml-basics-for-pm", "excerpt": "AI 기능 기획, 막막하신가요? 디자이너 출신 PM이 머신러닝 기초를 톺아봅니다. 개발자 없이도 AI 제품 성공하는 노하우, 지금 공개합니다.", "content": "# AI 기능 기획, PM이라면 머신러닝 기초는 알아야지\n\n솔직히 말해볼까? AI 스타트업에서 PM으로 일하다 보면, '머신러닝'이라는 단어만 들어도 머리가 지끈거릴 때가 있다. 코드 한 줄 모르는 디자이너 출신 PM으로서, 특히 그랬다. 개발자 친구들이 쏟아내는 용어들 속에서 길을 잃기 일쑤였고, '과연 내가 이걸 제대로 이해하고 있는 걸까?'라는 불안감에 시달리기도 했다. 밤새워가며 관련 논문을 뒤져봐도, 결국엔 '그래서 우리 제품에 어떻게 적용해야 하는데?'라는 질문으로 돌아왔다.\n\n이 글은 바로 그런 나와 같은 PM들을 위해 썼다. 머신러닝 전문가가 되자는 게 아니다. 하지만 AI 기능 기획을 앞두고 있다면, 최소한 '이 정도'는 알아야 한다는 것들을 짚어보고자 한다. 개발자와의 소통을 원활하게 하고, 정말 '되는' AI 제품을 만들기 위한 실질적인 이야기다. 내 개인적인 고군분투와 시행착오를 바탕으로, AI 기능 기획의 본질에 다가가 보자.\n\n## 1. 머신러닝, '마법'이 아닌 '수학'이라는 냉정한 사실\n\n많은 PM들이 AI, 특히 머신러닝을 마치 마법처럼 생각한다. 데이터를 넣으면 알아서 척척 결과가 튀어나오는 신비로운 기술이라고. 물론 그런 면도 있지만, 그 이면에는 철저한 수학적 원리와 알고리즘이 숨어있다. 이걸 이해하는 게 왜 중요하냐고? 우리가 기획하는 AI 기능이 '왜' 작동하는지, '어떻게' 개선될 수 있는지, **'어떤 한계'*가 있는지 알아야 하기 때문이다.\n\n### 1.1. 지도 학습 vs. 비지도 학습: 문제 정의의 출발점\n\n가장 기본적인 구분은 지도 학습(Supervised Learning)과 비지도 학습(Unsupervised Learning)이다. 마치 어린아이가 정답지를 보며 공부하는 것과, 스스로 규칙을 찾아내는 것의 차이라고 할까?\n\n 지도 학습: '이 사진은 고양이', '이 문자는 스팸'처럼 **정답(레이블)*이 있는 데이터를 가지고 학습한다. 분류(Classification)나 회귀(Regression) 문제에 주로 쓰인다. 예를 들어, 우리 서비스에서 사용자 리뷰의 긍정/부정 톤을 분석하는 기능이라면 지도 학습이 유용하다. 이미 잘 분류된 리뷰 데이터를 가지고 모델을 학습시키는 거지.\n 비지도 학습: 정답 없이 데이터 자체의 패턴이나 구조를 찾아낸다. 군집화(Clustering)나 차원 축소(Dimensionality Reduction) 등에 활용된다. 예를 들어, 우리 서비스의 신규 사용자들을 '어떤 그룹으로 묶을 수 있는지' 발견하고 싶을 때 비지도 학습을 고려해볼 수 있다. 명확한 목표 변수가 없을 때 유용하다.\n\nPM으로서, 내가 만들고 싶은 AI 기능이 *'어떤 종류의 문제'를 해결하는 것인지 명확히 하는 것만으로도 개발팀과의 소통이 훨씬 수월해진다. "이건 분류 문제인데, 지도 학습으로 접근하는 게 좋겠어요." 같은 짧은 코멘트 하나가 시간을 절약해 준다.\n\n### 1.2. 평가 지표: '좋은 모델'의 기준은 무엇인가\n\n개발팀이 '모델 성능이 좋다'고 말할 때, 그 기준이 무엇인지 알아야 한다. 단순히 정확도(Accuracy)만 보는 게 아니다. 문제의 특성에 따라 다양한 평가 지표가 사용된다.\n\n 정확도 (Accuracy): 전체 예측 중에 올바르게 예측한 비율. 직관적이지만, 데이터 불균형이 심할 때는 함정이 될 수 있다.\n 정밀도 (Precision) & 재현율 (Recall): 스팸 메일 분류 같은 경우를 생각해보자. 스팸이 아닌 메일을 스팸으로 잘못 분류하면(False Positive), 사용자는 중요한 메일을 놓친다. 반대로 스팸 메일을 스팸이 아니라고 잘못 분류하면(False Negative), 받은 편지함이 지저분해진다. 정밀도는 '스팸이라고 예측한 것들 중에 진짜 스팸인 비율'이고, 재현율은 '진짜 스팸인 것들 중에 스팸이라고 예측한 비율'이다. 어떤 실수를 더 용납하기 어려운지에 따라 두 지표의 중요도가 달라진다.\n F1-Score: 정밀도와 재현율의 조화 평균. 두 지표가 모두 중요할 때 사용한다.\n\nPM으로서, **'우리가 해결하려는 문제에서 어떤 오류가 더 치명적인가?'**를 명확히 하고, 이에 맞는 평가 지표를 개발팀과 합의하는 것이 중요하다. '성능 개선'이라는 막연한 목표 대신, '재현율 10%p 향상'과 같이 구체적인 목표를 설정할 수 있게 된다.\n\n## 2. PM의 역할: 개발자가 아닌, 'AI 기능 설계자'로서\n\n나는 코드를 직접 짜지 않는다. 하지만 AI 스타트업에서 PM으로 일하며 수많은 AI 기능들을 세상에 내놓았다. 그 과정에서 배운 것은, PM의 역할은 단순히 '아이디어만 내는 사람'이 아니라는 것이다. 오히려 **'AI 기능의 성공을 위한 설계자'*가 되어야 한다. 개발팀이 가장 효율적으로, 가장 올바른 방향으로 나아갈 수 있도록 돕는 역할이다.\n\n### 2.1. 'AI 도구'를 활용한 프로토타이핑의 힘\n\n디자이너 출신으로서 나는 시각적인 프로토타이핑에 익숙하다. AI 기능도 마찬가지다. 복잡한 알고리즘을 이해하지 못하더라도, No-code/Low-code AI 플랫폼이나 API를 활용하여 빠르게 프로토타입을 만들어볼 수 있다. 예를 들어, 이미지 인식 기능을 기획한다면, 미리 학습된 모델을 제공하는 클라우드 AI 서비스(Google Cloud Vision AI, AWS Rekognition 등)를 활용해볼 수 있다. 직접 모델을 학습시키지 않아도, 어떤 종류의 결과물을 얻을 수 있는지, 사용자 경험은 어떨지 시뮬레이션해볼 수 있다.\n\n이런 경험은 개발팀과의 논의에서 엄청난 무기가 된다. "이런 결과를 원해요. 이 API를 써보면 가능할까요?" 혹은 "이 프로토타입을 보면, 이 부분이 사용자에게는 이렇게 보일 거예요." 와 같이 구체적으로 소통할 수 있다. 막연히 'AI로 뭔가 해주세요'가 아니라, '이 AI 도구로 이런 결과를 만들어보고 싶은데, 기술적으로 가능할까요?'라고 접근하는 것이다.\n\n### 2.2. 데이터, AI 기능의 '숨겨진 연료'를 관리하라\n\n머신러닝 모델은 데이터로 학습한다. 데이터가 없으면 아무것도 할 수 없다. 그리고 어떤 데이터를 사용하느냐에 따라 AI 기능의 성능이 천차만별로 달라진다. PM은 이 '데이터'의 중요성을 누구보다 잘 알아야 한다.\n\n 데이터 수집 전략: 어떤 데이터를, 어떻게 수집할 것인가? 개인정보 보호 문제는 어떻게 해결할 것인가?\n 데이터 전처리: 수집된 데이터는 바로 사용하기 어렵다. 노이즈 제거, 형식 통일 등 전처리 과정이 필수적이다. 이 과정에서 어떤 기준으로 데이터를 가공할지 PM이 방향을 제시해야 한다.\n 데이터 편향 (Bias): 학습 데이터에 특정 편향이 있다면, AI 모델도 그 편향을 학습하게 된다. 성별, 인종, 지역 등에 대한 편향은 예상치 못한 문제를 야기할 수 있다. 우리 서비스의 사용자를 대표할 수 있는 다양하고 편향되지 않은 데이터를 확보하기 위해 노력해야 한다.\n\nAI 기능 기획 단계부터 '어떤 데이터를 가지고, 어떻게 관리할 것인가'에 대한 고민이 시작되어야 한다. 데이터 확보 및 관리 계획이 부실하면, 아무리 뛰어난 알고리즘도 무용지물이 될 수 있다.\n\n## 3. '현실적인 AI'를 위한 질문들\n\nAI 기능을 기획할 때, 나는 스스로에게 다음과 같은 질문들을 던진다. 이러한 질문들은 종종 개발팀과의 논의를 더욱 깊게 만들고, 불필요한 삽질을 줄여준다.\n\n 이 AI 기능이 해결하려는 핵심 문제는 무엇인가? (가장 중요한 질문이다. AI 그 자체가 목적이 되어서는 안 된다.)\n 이 문제를 해결하기 위해 '반드시' 머신러닝이 필요한가? (더 간단한 규칙 기반 시스템이나 기존 솔루션으로 해결할 수는 없는가? 'AI'라는 키워드에 매몰되지 말자.)\n 어떤 종류의 데이터를 가지고 있는가? 혹은 확보할 수 있는가? (데이터의 양과 질은 충분한가? 편향성은 없는가?)\n '성공'의 기준은 무엇인가? 어떤 지표로 측정할 것인가? (개발팀과 합의된 명확한 목표가 있는가?)\n AI 모델의 예상되는 한계는 무엇인가? (모든 AI는 완벽하지 않다. 어떤 상황에서 오작동할 가능성이 있으며, 이에 대한 대비책은 있는가?)\n 모델의 복잡성과 성능 사이의 트레이드오프는 고려했는가? (최신, 가장 복잡한 모델이 항상 최선은 아니다. 리소스, 개발 속도 등을 고려한 현실적인 선택이 필요하다.)\n\n이 질문들에 답하는 과정은 PM으로서 AI 기능에 대한 **'이해력'**을 높일 뿐만 아니라, **'통제력'**을 갖게 해준다. 결국 AI는 도구일 뿐, 그 도구를 어떻게 활용해 비즈니스 가치를 창출할 것인가는 PM의 역량에 달려있다.\n\n## 결론: AI, 두려워 말고 '이해'하라\n\nAI와 머신러닝은 더 이상 먼 미래의 기술이 아니다. 우리 손안의 스마트폰부터 복잡한 기업 시스템까지, 이미 깊숙이 자리 잡고 있다. PM으로서 이 변화의 흐름에 올라타지 못한다면, 도태될 수밖에 없다. 하지만 그렇다고 해서 머신러닝 전문가가 될 필요는 없다. 핵심 원리를 이해하고, 데이터의 중요성을 인지하며, 개발팀과 효과적으로 소통할 수 있는 **'AI 기능 설계자'**가 되는 것. 그것이 지금 우리에게 필요한 자세다.\n\nAI 기능 기획, 막연한 두려움 대신 명확한 이해를 바탕으로 도전해보자. 당신의 'AI 제품'은 어떤 모습인가? 그리고 그 제품을 만들기 위해, 지금 당장 무엇을 준비해야 할까?", "tags": [ "머신러닝", "AI", "PM", "기획", "스타트업" ], "seoTitle": "AI 기획, PM이라면 머신러닝 기초는 알아야지", "seoDescription": "AI 기능 기획, 막막하신가요? 디자이너 출신 PM이 머신러닝 기초를 톺아봅니다. 개발자 없이도 AI 제품 성공하는 노하우, 지금 공개합니다." }