콘텐츠로 이동

P1-4.4 문제 정의가 모델을 결정하는 방식

Section ID: P1-4.4 Version: v2026.07.20

4.1에서는 모델을 목적에 맞게 줄인 계산용 모형으로 봤습니다. 4.2에서는 입력, 출력, 데이터를 정리했고, 4.3에서는 입력이 특징과 표현으로 바뀌고 모델 내부의 파라미터와 함께 계산된다는 점을 봤습니다.

이번 절에서는 이 흐름을 하나의 질문으로 묶습니다. 현실의 목표를 어떤 AI 문제로 정의할 것인지가 그 질문입니다.

문제 정의는 모델을 만들기 전의 문서 작업처럼 보일 수 있습니다. 하지만 실제로는 모델의 종류, 필요한 데이터, 평가 기준, 업무 연결 방식을 함께 결정합니다. 문제 정의가 흔들리면 좋은 알고리즘을 써도 결과가 빗나갈 수 있습니다.

Part 1에서 문제 정의(task definition)와 현실 목표를 모델링 과제로 바꾸는 방식의 기본 기준은 이 절에서 잡습니다. 모델, 입력/출력/데이터, 특징/표현/파라미터의 기본 뜻은 4.1~4.3에서 먼저 잡았고, 여기서는 그 요소들을 어떤 과제로 묶을지와 무엇을 잘했다고 볼지를 정하는 단계에 집중합니다.

4.4는 모델 평가 지표를 계산하는 절이 아닙니다. 정확도, 정밀도, 재현율, 손실 함수 같은 지표의 세부 계산은 Part 4에서 다룹니다.

또한 4.4는 AI 서비스 아키텍처를 설계하는 절도 아닙니다. 라우팅, 권한 확인, 사람 검토, 도구 호출, 배포 후 모니터링은 P1-14와 Part 7에서 다룹니다.

여기서는 그 앞 단계만 다룹니다. 어떤 현실 목표를 어떤 입력과 출력의 문제로 정의하고, 무엇을 잘했다고 평가할지 정하는 단계입니다.

현실 목표를 모델링 과제로 바꾸는 기준

  • 현실 목표와 모델링 과제(task)를 구분합니다.
  • 같은 현실 목표도 여러 AI 문제로 나뉠 수 있음을 이해합니다.
  • 출력 정의가 데이터, 모델, 평가 지표를 함께 바꾼다는 점을 봅니다.
  • 모델 성능과 실제 업무 성과가 다를 수 있음을 이해합니다.
  • 4장을 마무리하면서 “문제를 모델로 바꾼다”는 말을 정리합니다.

세 가지 기준

좋은 알고리즘을 고르기 전에 아래 세 가지를 먼저 가릅니다.

기준 왜 중요한가 이 절에서 이해할 수준
현실 목표와 모델링 과제는 같지 않다는 점 AI가 해결하는 범위를 과장하지 않게 해 줍니다. 고객 만족 향상과 문의 분류를 서로 다른 층위로 구분합니다.
같은 목표도 여러 출력 정의로 바뀔 수 있다는 점 분류, 점수 예측, 생성이 어떻게 갈라지는지 보여 줍니다. 무엇을 출력하게 할지 정해야 한다는 점을 잡습니다.
출력 정의가 데이터와 평가 기준까지 함께 바꾼다는 점 모델 선택 이전에 문제 설계가 중요하다는 사실을 보여 줍니다. 출력이 바뀌면 필요한 사례와 잘했다는 기준도 함께 바뀐다는 점을 이해합니다.

현실 목표, 모델링 과제, 출력 정의, 평가, 업무 성과는 서로 연결되어 있지만 같은 말이 아닙니다.

용어 아주 짧은 뜻 이 절에서의 역할
현실 목표 실제로 개선하고 싶은 바깥 문제 모델이 왜 필요한지 정하는 출발점
모델링 과제 모델이 풀도록 좁힌 계산 문제 분류, 점수 예측, 생성 같은 형태
출력 정의 모델이 내야 하는 결과의 형식 어떤 데이터를 모으고 어떤 지표를 볼지 정하는 기준
평가 모델 출력이 얼마나 맞는지 보는 기준 정확도, 재현율, 점수 오차 같은 판단 틀
업무 성과 모델을 넣은 뒤 실제 일이 나아졌는지 보는 결과 처리 속도, 비용, 안전성, 고객 경험 같은 바깥 영향

여기서는 현실 목표는 바깥 문제, 모델링 과제는 좁힌 계산 문제, 출력 정의는 모델에게 시키는 일, 평가는 모델 점검, 업무 성과는 실제 결과라는 자리 구분이 중요합니다.

현실 목표는 아직 모델링 과제가 아니다

“고객 문의를 더 잘 처리하고 싶다”는 현실 목표입니다. 하지만 이 문장만으로는 모델에게 시킬 일을 알 수 없습니다.

모델링 과제가 되려면 더 구체적인 형태가 필요합니다.

현실 목표 모델링 과제로 바꾼 표현
고객 문의를 더 잘 처리하고 싶다 문의 문장을 보고 문의 유형을 분류한다
배송 문제를 줄이고 싶다 주문 정보를 보고 배송 지연 가능성을 예측한다
상담원의 반복 업무를 줄이고 싶다 문의 문장과 정책을 보고 답변 초안을 생성한다
위험한 거래를 줄이고 싶다 거래 정보를 보고 이상 거래 가능성을 점수로 낸다

Google의 머신러닝 용어집은 task를 머신러닝 기법으로 풀 수 있는 문제로 설명하고, 예로 분류(classification), 회귀(regression), 군집화(clustering), 이상 탐지(anomaly detection)를 듭니다.

따라서 문제 정의는 현실 목표를 이런 과제 형태로 바꾸는 일입니다.

현실 목표 -> 모델이 풀 수 있는 과제 -> 입력/출력/데이터/평가라는 순서로 정리할 수 있습니다.

이 순서는 단순한 기획 문장이 아니라, 뒤에서 모델 후보와 데이터 수집 범위를 흔들리지 않게 잡아 주는 기준입니다. 여기서는 현실 문제를 바로 모델에 넣는 것이 아니라 중간에 과제 정의가 한 번 필요하다는 점을 분명히 이해하는 것이 핵심입니다.

같은 목표도 여러 과제가 될 수 있다

같은 “고객 문의를 도와준다”는 목표도 모델에게 무엇을 시키느냐에 따라 다른 문제가 됩니다.

모델에게 시키는 일 출력 과제 성격
문의 유형을 고른다 환불, 배송, 교환, 기타 분류(classification)
긴급도를 예측한다 1~5 점수 회귀(regression) 또는 점수 예측
담당 부서를 추천한다 물류팀, 결제팀, CS팀 분류 또는 추천
답변 초안을 작성한다 자연어 문장 생성(generation)
사람 검토가 필요한지 판단한다 예/아니오 이진 분류(binary classification)

Google의 머신러닝 용어집은 분류 모델을 클래스(class)를 예측하는 모델로, 회귀 모델을 숫자 값을 예측하는 모델로 설명합니다. 이 구분은 입문 단계에서 매우 중요합니다. 출력이 범주인지 숫자인지, 문장인지에 따라 모델이 배워야 할 관계가 달라지기 때문입니다.

예를 들어 같은 문의 문장이라도 출력 정의가 달라지면 완전히 다른 문제가 됩니다.

“어제 주문했는데 아직 배송 조회가 안 됩니다.”

출력 정의 가능한 출력 필요한 데이터
문의 유형 분류 배송 문의 문장과 문의 유형 라벨
긴급도 예측 2 문의 문장과 긴급도 점수
답변 초안 생성 “배송 조회 반영까지 시간이 걸릴 수 있습니다...” 문의, 주문 상태, 정책, 좋은 답변 예시
사람 검토 필요 여부 아니오 문의와 자동 처리 가능 여부 라벨

입력 문장이 같아도 출력이 바뀌면 필요한 데이터와 평가 방식이 함께 바뀝니다. 그래서 “어떤 모델을 쓸까?”보다 먼저 “무엇을 출력하게 할까?”를 물어야 합니다.

실무에서는 같은 목표를 놓고도 팀마다 다른 출력을 먼저 상상하는 경우가 많습니다. 상담 운영팀은 문의 유형을 자동으로 붙이자고 생각할 수 있고, 관리자는 긴급한 문의를 먼저 올리자고 생각할 수 있으며, 작성 지원을 원하는 팀은 답변 초안을 만들자고 생각할 수 있습니다. 세 방향은 모두 문의 처리를 더 잘하자는 같은 목표에서 출발하지만, 실제 모델링 과제는 분류, 점수 예측, 생성으로 달라집니다. 이런 갈라짐은 혼란이 아니라 정상이며, 문제 정의의 역할은 바로 그 차이를 문서로 고정하는 데 있습니다.

출력 정의는 평가 지표를 바꾼다

모델이 무엇을 출력하는지 정하면, 그 다음에는 무엇을 잘했다고 볼지 정해야 합니다.

Google의 머신러닝 용어집은 평가(evaluation)를 모델의 품질을 측정하거나 서로 다른 모델을 비교하는 과정으로 설명합니다. 또한 지표(metric)를 관심을 두는 통계량으로 설명합니다.

scikit-learn의 모델 평가 문서는 평가 함수를 고를 때 최종 목표와 예측이 적용되는 맥락에서 출발하라고 설명합니다. 또한 예측(prediction)과 그 예측을 사용한 의사결정(decision making)을 구분합니다. 4.4에서는 이 관점을 받아들여, 지표를 모델 출력만의 문제가 아니라 그 출력이 어디에 쓰이는지와 연결해 봅니다.

고객 문의 예시로 보면 평가 기준은 출력 정의에 따라 달라집니다.

출력 정의 볼 수 있는 평가 기준
문의 유형 분류 정확도, 정밀도, 재현율, 혼동 행렬
긴급도 점수 실제 긴급도와 예측 점수의 차이
답변 초안 생성 사실성, 정책 준수, 문체, 안전성, 사람 검토 결과
사람 검토 필요 여부 놓치면 안 되는 문의를 얼마나 잘 잡는가

여기서 중요한 점은 평가 지표가 단순 숫자 이상의 의미를 가진다는 점입니다. 어떤 지표를 고르느냐는 “어떤 실수를 더 위험하게 볼 것인가?”를 정하는 일이기도 합니다.

예를 들어 사람 검토가 필요한 문의를 자동 처리로 넘기는 실수는 위험할 수 있습니다. 반대로 자동 처리해도 되는 문의를 사람에게 보내는 실수는 비용을 늘릴 수 있습니다. 둘 다 틀린 예측이지만 업무 영향은 다릅니다.

실수 업무 영향
위험한 문의를 자동 처리함 고객 피해, 정책 위반, 보안 문제 가능성
안전한 문의를 사람에게 보냄 처리 비용 증가, 응답 지연

따라서 문제 정의에는 출력뿐 아니라 실수의 비용도 포함되어야 합니다.

데이터 수집 범위도 문제 정의가 결정한다

문제 정의는 어떤 데이터를 모아야 하는지도 결정합니다. 데이터가 많아도 모델이 풀려는 과제와 맞지 않으면 유용하지 않을 수 있습니다.

예를 들어 “배송 문제를 줄이고 싶다”는 목표를 세 가지 과제로 바꾸어 보겠습니다.

과제 필요한 입력 데이터 필요한 출력 데이터
배송 지연 예측 주문 시간, 출고 시간, 지역, 상품, 택배 상태 지연 여부 또는 예상 도착 시간
배송 문의 분류 고객 문의 문장 문의 유형 라벨
배송 답변 생성 문의 문장, 주문 상태, 배송 정책 좋은 답변 예시 또는 답변 기준

같은 배송 문제라도 데이터의 모양이 완전히 다릅니다. 문의 분류 데이터만 많이 모아서는 배송 지연 예측 모델을 만들기 어렵습니다. 반대로 주문 로그만 많아도 고객 문의 답변 품질을 직접 학습하기는 어렵습니다.

그래서 데이터 수집 전에 다음 질문이 필요합니다.

우리가 예측하거나 생성하려는 출력은 무엇인가? 그 출력을 만들기 위해 모델이 실제로 볼 수 있는 입력은 무엇인가? 그 입력과 출력이 함께 있는 과거 사례가 있는가? 라벨 기준은 사람마다 일관적인가?

모델 선택은 문제 정의 뒤에 온다

이 절에서는 모델 이름이 먼저 눈에 들어오기 쉽습니다. 선형 모델, 트리 모델, 신경망, LLM 같은 말이 익숙하게 들릴 수 있습니다. 하지만 모델 이름이 먼저 오면 문제를 모델에 억지로 맞추기 쉽습니다.

더 안전한 순서는 다음과 같습니다.

  1. 현실 목표를 정합니다.
  2. 모델링 과제를 정합니다.
  3. 입력과 출력을 정합니다.
  4. 데이터와 라벨 기준을 정합니다.
  5. 평가 지표를 정합니다.
  6. 모델 후보를 정합니다.
  7. 출력 사용 위치를 확인합니다.

예를 들어 고객 문의 분류 문제라면, 처음부터 LLM을 써야 한다고 정할 필요는 없습니다. 문의 유형이 명확하고 데이터가 잘 정리되어 있다면 단순한 분류 모델이나 규칙과 모델을 섞은 방식이 충분할 수 있습니다. 반대로 답변 초안 생성처럼 자연어 문장을 만들어야 한다면 생성형 모델이나 LLM을 검토할 수 있습니다.

모델 선택은 중요하지만, 문제 정의를 대신하지 못합니다. 문제 정의가 불명확하면 큰 모델을 써도 무엇을 잘해야 하는지 평가하기 어렵습니다.

모델 성능과 업무 성과는 다를 수 있다

모델 평가 지표가 좋아도 실제 업무 성과가 좋아진다고 단정할 수는 없습니다. 모델은 시스템 안의 한 부분이기 때문입니다.

예를 들어 문의 유형 분류 정확도가 높아졌다고 하겠습니다. 그래도 다음 문제가 남을 수 있습니다.

모델은 잘했지만 업무에서 생길 수 있는 문제
문의 유형을 잘 맞힘 라우팅 규칙이 잘못되어 담당 부서가 틀림
자동 처리 가능 여부를 잘 예측함 정책 변경이 반영되지 않아 잘못된 안내를 함
답변 초안을 자연스럽게 생성함 근거 없는 내용을 포함해 사람 검토에서 반려됨
지연 가능성을 잘 예측함 알림을 보내는 시점이 늦어 고객 경험이 나아지지 않음

Google의 머신러닝 용어집은 LLM 평가가 성능 비교뿐 아니라 안전하고 윤리적인 사용을 확인하는 데도 도움이 된다고 설명합니다. 이 내용은 생성형 AI 장에서 더 자세히 다룹니다. 4.4에서는 “출력이 달라지면 평가 기준도 달라진다”는 점만 기억하면 됩니다.

따라서 모델 평가와 업무 평가는 구분해야 합니다.

구분 질문
모델 평가 모델의 출력이 정답 또는 기준에 얼마나 맞는가?
업무 평가 모델을 넣은 뒤 실제 업무 결과가 좋아졌는가?
안전 평가 잘못된 출력이 사용자나 조직에 위험을 만들지 않는가?

같은 모델이라도 두 평가는 다르게 나올 수 있습니다. 예를 들어 문의 유형 분류 정확도는 높지만, 분류 결과를 넘겨받는 라우팅 규칙이 낡았거나 담당 부서 연결이 늦으면 업무 성과는 충분히 좋아지지 않을 수 있습니다. 반대로 모델 정확도는 아주 높지 않아도, 위험 문의만 잘 걸러 사람 검토로 보내는 구조가 있으면 실제 업무 안전성은 좋아질 수 있습니다.

문제 정의 문서에 적어야 할 것

작은 모델링 과제라도 다음 항목을 문서로 남기면 혼란을 줄일 수 있습니다.

항목 질문 고객 문의 예시
현실 목표 왜 이 모델이 필요한가? 문의 처리 시간을 줄인다
모델링 과제 모델이 풀 문제는 무엇인가? 문의 유형 분류
입력 모델이 실제로 보는 것은 무엇인가? 문의 문장
출력 모델이 내야 하는 결과는 무엇인가? 환불, 배송, 교환, 기타
데이터 과거 사례는 무엇인가? 문의 문장과 사람이 붙인 라벨
라벨 기준 사람이 같은 기준으로 라벨을 붙일 수 있는가? 환불/배송/교환/기타의 기준 정의
평가 지표 무엇을 잘했다고 볼 것인가? 정확도, 재현율, 사람 검토 결과
실수 비용 어떤 실수가 더 위험한가? 위험 문의를 자동 처리하는 실수
사용 위치 출력은 어디에 쓰이는가? 라우팅, 자동 답변, 사람 검토의 입력
제외 범위 모델이 하지 않는 일은 무엇인가? 실제 환불 승인, 정책 판단 최종 책임

이런 문서는 거창한 기획서가 아니라, 모델이 다룰 세계를 정하는 최소한의 지도입니다. 이 지도가 없으면 모델이 좋아졌는지, 데이터가 충분한지 판단하기 어렵습니다. 실제 배포 가능 여부는 보안, 권한, 검토 흐름, 운영 책임까지 함께 보아야 하므로 후속 장에서 다룹니다.

체크리스트

  • 현실 목표와 모델링 과제를 구분할 수 있다.
  • 같은 목표가 분류, 회귀, 추천, 생성 같은 다른 과제로 바뀔 수 있음을 설명할 수 있다.
  • 출력 정의가 데이터, 모델 후보, 평가 지표를 함께 바꾼다는 점을 설명할 수 있다.
  • 모델 성능과 실제 업무 성과가 다를 수 있음을 설명할 수 있다.
  • 문제 정의 문서에 입력, 출력, 데이터, 라벨 기준, 평가 지표, 실수 비용, 제외 범위를 적을 수 있다.
  • 문제 정의는 모델 앞에 놓이는 준비 작업이 아니라, 모델이 무엇을 볼지, 무엇을 낼지, 무엇을 잘했다고 평가할지 결정하는 핵심 단계라는 점을 설명할 수 있다.
  • 우리는 어떤 입력을 사용해 어떤 출력을 만들고, 그 출력이 어떤 업무 목표에 도움이 되는지 어떤 지표와 검토 기준으로 확인하려고 한다는 문장을 스스로 채울 수 있는가

출처와 참고 자료