머신러닝 문제 정의하기

머신러닝 프로젝트는 대개 모델 선택에서 시작되지 않습니다. 실제로는 그보다 훨씬 앞, '우리가 무엇을 풀려는가'를 정확히 적는 순간부터 시작됩니다. 많은 팀이 이 단계를 가볍게 넘깁니다. 그래서 회의실에서는 모두가 고개를 끄덕였는데, 막상 몇 주 뒤에는 서로 전혀 다른 목표를 상상하고 있었다는 사실이 드러납니다. 데이터 팀은 예측 모델을 만들고 있고, 서비스 팀은 개인화를 기대하고 있으며, 경영진은 비용 절감을 원합니다. 결국 모델이 실패한 것이 아니라, 문제 정의가 흐릿했던 것입니다.

좋은 모델보다 먼저 필요한 것은 좋은 문제 정의입니다. 문제를 제대로 정의하면 어떤 데이터를 모아야 하는지 보이고, 어떤 모델이 적절한지도 자연스럽게 좁혀집니다. 반대로 문제 정의가 모호하면, 성능이 높은 모델을 만들어도 실제 업무에서는 쓸 수 없는 결과가 나옵니다. 이번 장에서는 바로 그 출발점, 비즈니스 문제를 학습 가능한 머신러닝 문제로 바꾸는 법을 다룹니다.

왜 문제 정의가 먼저인가

머신러닝은 마법이 아닙니다. 데이터에서 패턴을 배워 미래를 예측하거나, 보이지 않던 구조를 드러내는 도구일 뿐입니다. 그러니 먼저 결정해야 할 것은 "어떤 문제를 어떤 방식으로 풀 것인가"입니다.

예를 들어 회사가 "고객 이탈을 줄이고 싶다"고 말한다고 해봅시다. 이 문장은 비즈니스 목표로는 훌륭합니다. 하지만 아직 머신러닝 문제는 아닙니다. 고객 이탈을 줄인다는 말만으로는 모델이 무엇을 입력받아 무엇을 출력해야 하는지, 언제 예측해야 하는지, 예측 결과로 누가 무엇을 할지 알 수 없기 때문입니다.

이 목표를 머신러닝 문제로 번역하면 훨씬 구체적이 됩니다. "지난 30일간의 사용 기록, 결제 이력, 문의 이력을 바탕으로 각 고객이 앞으로 14일 안에 이탈할 확률을 예측한다." 이제야 모델의 입력과 출력이 보입니다. 더 나아가 "이탈 확률이 높은 고객에게 할인 쿠폰을 보낸다"까지 연결되면, 예측이 실제 행동으로 이어지는 구조도 생깁니다.

문제 정의는 결국 세 가지를 맞추는 일입니다. 비즈니스 목표, 데이터로 관측 가능한 신호, 그리고 실제 의사결정의 타이밍입니다. 이 셋이 맞아떨어져야 머신러닝이 힘을 발휘합니다.

좋은 ML 문제와 나쁜 ML 문제

좋은 머신러닝 문제는 그럴듯해 보이는 문제가 아니라, 학습과 운영이 가능한 문제입니다. 겉보기에는 비슷해 보여도, 실제로는 출발선이 크게 다릅니다.

좋은 ML 문제는 다음 질문에 또렷하게 답할 수 있습니다.

• 입력은 무엇인가?

• 출력은 무엇인가?

• 언제 예측할 것인가?

• 예측 결과로 누가 어떤 결정을 내릴 것인가?

• 나중에 정답을 확인할 수 있는가?

반대로 나쁜 ML 문제는 목표가 멋있지만 정의가 흐립니다. "고객 만족도를 AI로 높이자", "사용자 경험을 머신러닝으로 개선하자", "더 똑똑한 추천을 만들자" 같은 문장은 방향성은 있어도, 바로 모델링으로 들어가기에는 정보가 부족합니다.

좋은 문제와 나쁜 문제의 차이는 대개 한 끗입니다. 아래 두 문장을 비교해봅시다.

첫째, "매출을 늘리자." 이 문장은 너무 넓습니다. 어떤 고객의 어떤 행동을 바꾸려는지 알 수 없습니다.

둘째, "방문 후 7일 이내 구매할 가능성이 높은 고객을 예측해 쿠폰 발송 대상을 정하자." 이 문장은 입력, 출력, 의사결정 대상, 행동 방식이 모두 드러납니다.

좋은 ML 문제는 기술적으로도 풀 수 있어야 하지만, 운영적으로도 닫혀 있어야 합니다. 다시 말해 모델이 낸 예측이 실제 행동으로 연결되고, 그 결과를 다시 확인할 수 있어야 합니다. 예측만 있고 후속 행동이 없다면, 그 모델은 멋진 대시보드 장식품이 되기 쉽습니다.

"AI로 해결하자"가 실패하는 이유

현업에서 자주 듣는 말이 있습니다. "이건 AI 붙이면 되지 않나요?" 이 말이 틀린 것은 아닙니다. 다만 너무 빨리 나왔을 때가 문제입니다. 기술보다 먼저 확인해야 할 조건들이 빠져 있기 때문입니다.

머신러닝 프로젝트가 전형적으로 실패하는 패턴은 몇 가지가 있습니다.

• 해결하고 싶은 문제가 너무 추상적이다.

• 필요한 데이터가 없거나, 있어도 쓸 수 없는 상태다.

• 예측 결과를 실제 업무에 반영할 운영 방식이 없다.

• 성공 기준이 없어 프로젝트 종료 시점에도 잘됐는지 판단할 수 없다.

예를 들어 "고객 문의를 자동으로 처리하자"는 목표를 세웠다고 해봅시다. 얼핏 보면 자연어 처리 모델을 적용하면 될 것 같습니다. 하지만 실제로는 먼저 확인할 것이 많습니다. 어떤 유형의 문의를 자동화할 것인지, 과거 상담 기록이 정리되어 있는지, 상담사의 답변 품질이 일관적인지, 잘못 답했을 때 책임은 누가 지는지, 자동 응답이 실패하면 사람에게 어떻게 넘길 것인지가 정리되어야 합니다.

즉, AI 프로젝트는 모델이 없어서 실패하는 경우보다 문제 구조가 없어서 실패하는 경우가 더 많습니다. 모델은 마지막 퍼즐 조각에 가깝습니다. 퍼즐 판이 없는데 조각부터 사 모으면, 당연히 완성되지 않습니다.

비즈니스 문제를 예측 문제로 번역하는 법

문제 정의의 핵심은 비즈니스 언어를 예측 언어로 바꾸는 것입니다. "매출", "이탈", "재고", "사기", "추천" 같은 말은 비즈니스에서 쓰는 표현입니다. 머신러닝은 이 표현을 입력과 출력의 관계로 다시 써야 이해할 수 있습니다.

이때 가장 유용한 질문은 아주 단순합니다.

"우리는 무엇을, 언제, 누구에 대해, 어떤 데이터를 바탕으로 예측하려는가?"

이 질문을 기준으로 몇 가지 대표 사례를 번역해보겠습니다.

고객 이탈 문제를 번역해보기

비즈니스 문제는 이렇게 시작됩니다. "고객이 자꾸 떠난다."

이 문장을 머신러닝 문제로 바꾸려면 먼저 '이탈'을 정의해야 합니다. 구독 서비스라면 해지 버튼을 누른 시점이 이탈일 수 있습니다. 쇼핑몰이라면 90일 이상 구매가 없는 상태를 이탈로 볼 수 있습니다. 앱 서비스라면 30일 이상 접속이 없을 때를 이탈로 정할 수도 있습니다.

그다음에는 예측 시점을 정합니다. 이탈한 뒤 알아내면 소용이 없으니, 떠나기 전에 알아야 합니다. 그래서 보통 "앞으로 14일 안에 이탈할 가능성"처럼 미래 구간을 정합니다. 입력 데이터는 현재 시점까지 관측 가능한 정보만 사용해야 합니다. 최근 접속 빈도, 결제 이력, 고객센터 문의 수, 기능 사용 패턴 등이 여기에 들어갑니다.

이렇게 정리하면 문제는 다음처럼 바뀝니다.

"오늘 시점까지의 사용자 행동 데이터를 바탕으로, 각 고객이 앞으로 14일 안에 이탈할 확률을 예측한다."

이제야 분류 문제의 형태가 나타납니다. 출력은 이탈 여부 또는 이탈 확률이고, 이후 행동은 리텐션 메시지 발송, 혜택 제공, 상담 연결 같은 방식으로 설계할 수 있습니다.

가격 예측 문제를 번역해보기

비즈니스에서는 "적정 가격을 알고 싶다"고 말할 수 있습니다. 이 말 역시 아직은 너무 넓습니다. 어떤 상품의 가격인지, 언제의 가격인지, 시장 변화는 어떻게 반영할지 정해지지 않았기 때문입니다.

예를 들어 중고차 거래 서비스라면 문제를 이렇게 바꿀 수 있습니다.

"차종, 연식, 주행 거리, 사고 이력, 옵션 정보를 바탕으로 차량의 예상 판매 가격을 예측한다."

이 문제는 연속된 숫자를 예측하므로 회귀 문제입니다. 다만 여기서도 중요한 것은 예측 결과의 사용 목적입니다. 판매자에게 가격 가이드를 줄 것인지, 내부 매입 기준으로 쓸 것인지에 따라 허용 오차와 평가 지표가 달라집니다. 단순히 숫자를 맞히는 것과 실제 거래를 돕는 것은 다른 문제이기 때문입니다.

수요 예측 문제를 번역해보기

비즈니스 현장에서는 "재고를 잘 맞추고 싶다"는 표현을 자주 씁니다. 이것도 머신러닝 문제로 바꾸면 더 구체적이 됩니다.

"상품별 과거 판매량, 시즌 정보, 요일, 프로모션 여부, 날씨 정보를 바탕으로 다음 주 판매 수량을 예측한다."

이 경우 출력은 미래의 판매량입니다. 하지만 여기서 특히 중요한 것은 시간입니다. 내일의 수요를 예측할 때 내일 이후 데이터를 실수로 입력에 넣으면 안 됩니다. 수요 예측은 모델보다 데이터 시점 관리가 더 어려운 경우가 많습니다.

비즈니스 문제를 예측 문제로 번역할 때는 늘 다음 구조를 떠올리면 좋습니다.

• 대상은 누구인가 또는 무엇인가?

• 예측하려는 결과는 무엇인가?

• 예측 시점은 언제인가?

• 그 시점에 사용할 수 있는 데이터는 무엇인가?

• 예측 뒤에 이어질 실제 행동은 무엇인가?

이 다섯 줄만 분명해져도 프로젝트의 절반은 이미 정리된 셈입니다.

정답 데이터를 만들 수 있는가

머신러닝 프로젝트를 시작할 때 가장 먼저 던져야 하는 질문 중 하나는 이것입니다. "우리는 정답을 만들 수 있는가?"

지도학습은 정답이 있는 데이터를 바탕으로 학습합니다. 스팸 메일 분류라면 스팸인지 아닌지 표시된 메일이 필요합니다. 고객 이탈 예측이라면 이탈한 고객과 이탈하지 않은 고객이 구분되어 있어야 합니다. 가격 예측이라면 실제 거래 가격이 있어야 합니다.

문제는 많은 조직이 이 질문을 너무 늦게 한다는 데 있습니다. 아이디어 단계에서는 멋져 보였지만, 막상 데이터 창고를 열어보니 정답이 없거나 정의가 제각각인 경우가 많습니다.

예를 들어 "고객 만족도를 예측하자"는 목표를 세웠다고 합시다. 그런데 만족도에 대한 측정값이 없다면 어떻게 될까요? 리뷰 점수, 재구매율, 문의 건수, 환불률 중 무엇을 만족의 대리 지표로 삼을지부터 정해야 합니다. 이 과정 없이 모델을 만들면, 팀마다 서로 다른 만족을 상상한 채 프로젝트를 진행하게 됩니다.

정답 데이터를 만들 수 있는지는 크게 세 단계로 확인할 수 있습니다.

첫째, 정답의 정의가 분명한가. 예를 들어 이탈은 30일 미접속인지, 해지 여부인지, 구매 중단인지 먼저 정해야 합니다.

둘째, 그 정답을 데이터로 기록하고 있는가. 정의가 있어도 시스템에 저장되지 않으면 학습에 쓸 수 없습니다.

셋째, 충분한 양과 품질을 확보할 수 있는가. 정답 데이터가 너무 적거나 오류가 많으면 모델이 엉뚱한 패턴을 학습합니다.

여기서 중요한 사실이 하나 있습니다. 정답 데이터는 발견하는 것이 아니라 설계하는 경우도 많다는 점입니다. 서비스 로그를 다시 정리하고, 업무 시스템의 상태 값을 표준화하고, 사람이 일부 데이터를 라벨링해야 비로소 학습 가능한 데이터셋이 만들어지는 경우가 흔합니다. 문제 정의는 모델링 이전의 일처럼 보이지만, 실제로는 데이터 설계와 바로 연결되어 있습니다.

성공 지표를 먼저 정해야 하는 이유

문제를 정의할 때 많은 팀이 빠지는 함정은 "일단 만들어보고 나중에 성능을 보자"는 태도입니다. 하지만 성공 지표를 뒤로 미루면 프로젝트는 쉽게 흔들립니다. 왜냐하면 같은 모델도 어떤 지표를 보느냐에 따라 전혀 다른 평가를 받기 때문입니다.

예를 들어 고객 이탈 예측 모델이 있다고 해봅시다. 정확도만 보면 95퍼센트가 나올 수 있습니다. 그런데 실제로 이탈 고객이 매우 적은 서비스라면, 모든 고객을 "안 떠난다"고 예측해도 높은 정확도가 나올 수 있습니다. 이런 모델은 숫자는 좋아 보이지만 아무 쓸모가 없습니다.

그래서 성공 지표는 반드시 문제 정의 단계에서 정해야 합니다. 그리고 이 지표는 두 층으로 나누어 생각하는 것이 좋습니다.

첫 번째는 머신러닝 지표입니다. 예를 들면 정밀도, 재현율, F1 점수, 평균 절대 오차 같은 값입니다. 모델이 예측 자체를 얼마나 잘하는지 보여줍니다.

두 번째는 비즈니스 지표입니다. 예를 들면 이탈률 감소, 재고 비용 절감, 클릭률 증가, 상담 처리 시간 감소 같은 값입니다. 모델이 실제로 사업에 어떤 변화를 만들었는지 보여줍니다.

중요한 것은 이 둘이 자동으로 이어지지 않는다는 점입니다. 모델 성능이 좋아도 운영 방식이 나쁘면 비즈니스 성과는 나오지 않을 수 있습니다. 반대로 모델 성능이 아주 최고는 아니어도, 적절한 임계값과 실행 전략 덕분에 큰 효과를 낼 수도 있습니다.

성공 지표를 먼저 정하면 좋은 점이 많습니다.

• 프로젝트의 목적이 분명해진다.

• 팀 간 기대치가 맞춰진다.

• 어떤 데이터를 더 모아야 할지 결정하기 쉬워진다.

• 실험이 많아져도 무엇이 개선인지 판단할 기준이 생긴다.

쉽게 말해 성공 지표는 프로젝트의 나침반입니다. 나침반 없이 열심히 걷는 것은 성실함이지, 설계는 아닙니다.

의사결정 시점이 빠지면 문제가 된다

초보 팀이 자주 놓치는 요소가 하나 더 있습니다. 바로 의사결정 시점입니다. 어떤 예측을 하든, 그 예측이 실제로 쓰이는 순간이 있어야 합니다.

예를 들어 카드 사기 탐지 모델을 만든다고 해봅시다. 거래가 끝난 뒤 사기 여부를 정확히 맞히는 것은 분석적으로는 흥미롭지만, 운영적으로는 늦을 수 있습니다. 실전에서는 결제 승인 전에 위험도를 판단하거나, 직후에 추가 인증을 요청해야 합니다. 즉, 모델의 성능만큼이나 "언제 점수를 낼 수 있는가"가 중요합니다.

고객 이탈 예측도 마찬가지입니다. 이미 해지한 고객을 높은 확률로 이탈 예측하는 것은 별 도움이 되지 않습니다. 떠나기 직전, 하지만 아직 붙잡을 수 있는 시점에 예측해야 가치가 생깁니다.

머신러닝 문제를 정의할 때는 이렇게 물어보면 좋습니다. "이 예측은 너무 늦지 않은가?" 이 질문 하나가 실제로 제품에서 쓰일 수 있는 모델과, 발표 자료에서만 빛나는 모델을 가릅니다.

현장에서 자주 나오는 나쁜 문제 정의의 예

문제 정의는 틀리기 쉬운 만큼, 흔한 실패 문장을 알아두는 것이 도움이 됩니다.

"고객을 더 잘 이해하는 AI를 만들자." 듣기에는 멋지지만, '더 잘 이해한다'는 상태를 측정할 수 없습니다. 어떤 행동을 예측할지, 어떤 결과가 나오면 성공인지 정의해야 합니다.

"추천 시스템을 만들자." 추천 시스템 자체는 목표가 아닙니다. 클릭을 늘리고 싶은지, 구매 전환을 높이고 싶은지, 탐색 시간을 줄이고 싶은지에 따라 완전히 다른 문제입니다.

"재고 문제를 AI로 해결하자." 재고 부족을 줄이려는지, 과잉 재고를 줄이려는지, 발주 시점을 최적화하려는지 먼저 정해야 합니다. 같은 재고 문제라도 출력값이 달라집니다.

"불량을 잡아내자." 불량 판별인지, 불량 확률 예측인지, 공정 이상 조기 감지인지에 따라 데이터와 운영 구조가 달라집니다.

이런 문장들은 보통 비전 문장으로는 괜찮습니다. 하지만 머신러닝 문제 정의 문장으로는 부족합니다. 비전은 넓어도 되지만, 학습 문제는 좁고 정확해야 합니다.

문제 정의를 위한 간단한 설계 틀

실무에서는 문제 정의를 아주 짧은 문서로라도 남기는 편이 좋습니다. 길고 화려할 필요는 없습니다. 오히려 한 페이지 안에 핵심이 정리되는 것이 이상적입니다.

다음 항목이 있으면 대부분의 프로젝트 출발이 훨씬 안정적입니다.

• 해결하려는 비즈니스 문제

• 예측 대상과 예측 시점

• 입력 데이터 후보와 사용 가능 여부

• 출력값의 정의와 정답 데이터 생성 방식

• 성공 지표와 운영 후속 액션

예를 들어 이렇게 적을 수 있습니다.

"목표는 구독 해지율 감소다. 예측 대상은 현재 활성 고객이며, 매주 월요일 기준으로 향후 14일 내 해지 가능성을 예측한다. 입력 데이터는 최근 사용 빈도, 결제 이력, 고객센터 문의, 기능 사용 로그다. 정답은 예측 시점 이후 14일 안에 실제 해지했는지 여부로 정의한다. 성공 지표는 상위 위험 고객군에서의 재현율과, 캠페인 적용 후 해지율 감소다."

이 정도만 정리되어도 데이터 팀, 서비스 팀, 마케팅 팀이 같은 그림을 보게 됩니다.

좋은 문제 정의는 좋은 데이터 설계로 이어진다

문제를 잘 정의하면 다음 단계인 데이터 작업이 쉬워집니다. 무엇을 모아야 하는지, 어떤 기간을 잘라야 하는지, 어떤 열이 필요하고 어떤 열은 아직 쓰면 안 되는지가 드러나기 때문입니다.

반대로 문제 정의가 흐리면 데이터 전처리도 끝없이 흔들립니다. 처음에는 이탈 예측이라더니, 중간에는 VIP 고객 관리로 목표가 바뀌고, 나중에는 마케팅 반응 예측처럼 바뀌는 일이 벌어집니다. 그러면 데이터셋 구조도 계속 바뀌고, 실험 결과를 비교하기도 어려워집니다.

좋은 문제 정의는 모델링을 위한 준비일 뿐 아니라, 데이터셋을 만드는 기준점입니다. 결국 데이터와 모델은 따로 움직이지 않습니다. 문제 정의가 둘의 설계도 역할을 합니다.

이 장의 핵심

머신러닝 프로젝트의 성패는 종종 알고리즘보다 문제 정의에서 갈립니다. 좋은 ML 문제는 입력, 출력, 예측 시점, 후속 행동이 분명합니다. 나쁜 문제는 목표가 넓고 멋있지만, 학습 가능한 형태로 닫혀 있지 않습니다.

또한 "AI로 해결하자"는 말은 출발점이 될 수 있어도 설계 문장은 아닙니다. 데이터를 구할 수 있는지, 정답을 만들 수 있는지, 예측이 실제 의사결정에 연결되는지 확인해야 합니다. 고객 이탈, 가격 예측, 수요 예측처럼 익숙한 비즈니스 문제도 결국은 "무엇을 언제 예측할 것인가"로 번역되어야 비로소 모델이 다룰 수 있는 문제가 됩니다.

무엇보다 중요한 것은 성공 지표를 먼저 정하는 일입니다. 그래야 프로젝트가 흔들리지 않고, 성능 개선이 실제 개선인지 판단할 수 있습니다. 문제를 정확히 정의하는 일은 답답한 준비 작업이 아니라, 가장 먼저 해야 할 설계입니다.

다음 장에서는 이렇게 정의된 문제를 실제 데이터셋으로 옮기기 위해, 데이터가 어떤 구조를 가지는지부터 살펴보겠습니다. 모델은 데이터에서 배우지만, 그 전에 우리는 데이터가 어떤 모습으로 세상과 연결되어 있는지 읽을 수 있어야 합니다.