P1-4.2 입력(input), 출력(output), 데이터(data)¶

Section ID: P1-4.2 Version: v2026.07.20

4.1에서는 모델을 현실 문제 전체가 아니라 목적에 맞게 줄여 만든 계산 가능한 모형으로 정리했습니다. 이제 그 모델을 설명할 때 가장 먼저 나누어 볼 세 요소, 곧 무엇을 넣고 무엇을 얻고 어떤 사례를 모을 것인지 살펴봅니다.

여기서는 입력(input), 출력(output), 데이터(data)를 정리합니다. 특징(feature), 표현(representation), 파라미터(parameter)는 4.3에서 다룹니다.

예시 상황은 고객 문의를 AI로 도와주고 싶다는 문제입니다. 이 상황을 계속 바꿔 가며 입력, 출력, 데이터가 어떻게 갈라지는지 봅니다.

Part 1에서 입력(input), 출력(output), 데이터(data), 사례(example), 라벨(label)의 기본 구분은 이 절에서 잡습니다. 모델과 시스템의 기본 구분은 4.1에서 먼저 잡았고, 특징, 표현, 파라미터의 차이는 4.3에서 더 자세히 다룹니다. 여기서는 먼저 무엇을 넣고 무엇을 얻을 것인가와 어떤 사례를 모아야 하는가를 분리하는 데 집중합니다.

아직은 모델링 과제가 아닙니다. “도와준다”는 말이 너무 넓기 때문입니다. 이 넓은 말을 입력, 출력, 데이터로 나누어야 모델이 맡을 수 있는 작은 과제가 됩니다.

여기서는 다음 질문을 정리합니다.

• 입력(input), 출력(output), 데이터(data)는 각각 어떤 역할을 하는가?
• 같은 현실 문제도 입력과 출력 정의에 따라 왜 다른 과제가 되는가?
• 데이터는 왜 단순 파일 모음이 아니라 사례(example) 묶음으로 읽어야 하는가?

특징과 표현, 파라미터의 관계는 바로 다음 4.3에서 다시 회수하고, 문제 정의가 모델 선택을 어떻게 바꾸는지는 4.4에서 이어집니다. 입력과 출력을 실제 특징·표현 계산으로 바꾸는 구조는 Part 4의 머신러닝 장과 Part 5의 신경망 장에서 다시 연결합니다. 여기서는 먼저 무엇을 넣고 무엇을 얻을 것인가를 분리하는 데 집중합니다.

입력, 출력, 데이터를 나누는 기준¶

• 입력(input), 출력(output), 데이터(data)의 역할을 구분합니다.
• 현실 문제를 입력과 출력의 관계로 보는 관점을 이해합니다.
• 같은 현실 문제도 입력과 출력 정의에 따라 다른 데이터가 필요해짐을 봅니다.
• 데이터가 단순 파일 모음이 아니라 모델이 배울 기준을 제공하는 사례(example)의 모음이라는 점을 이해합니다.
• 4.3에서 다룰 특징과 표현으로 넘어갈 준비를 합니다.

세 가지 기준¶

현실 문제를 계산 가능한 문제로 줄일 때는 아래 세 가지를 먼저 가릅니다.

입력, 출력, 데이터, 사례, 라벨은 이 절 전체를 끌고 가는 핵심 용어입니다. 지금 단계에서는 입력은 넣는 정보, 출력은 얻고 싶은 결과, 데이터는 사례 묶음, 사례는 한 건, 라벨은 정답 이름이라는 큰 구분만 먼저 잡고 넘어가면 됩니다. 각 용어는 아래 본문에서 한 번 더 묶어 정리합니다.

여기서 특히 헷갈리기 쉬운 부분은 입력과 데이터입니다. 입력은 모델이 지금 한 번 받아 보는 정보 한 건에 가깝고, 데이터는 그런 입력과 출력 사례가 여러 건 모여 있는 학습용 묶음에 가깝습니다. 예를 들어 배송이 언제 오나요?라는 문의 문장 한 줄은 입력이 될 수 있고, 이런 문의 문장과 정답 분류가 수천 건 모인 표는 데이터가 됩니다.

또한 입력 한 건이 꼭 값 하나만 뜻하는 것은 아닙니다. 문의 문장 하나만 넣을 수도 있지만, 필요하다면 문의 문장 + 주문 상태 + 고객 등급 + 최근 배송 이벤트처럼 여러 필드를 묶어 한 건의 입력으로 볼 수도 있습니다. 이 구간에서는 입력 = 모델이 한 번 판단할 때 받아 보는 정보 묶음, 데이터 = 그런 입력 묶음과 출력 사례가 많이 모인 것으로 구분해 두면 흐름이 선명해집니다.

문제를 계산 가능한 형태로 바꾸기¶

AI 모델은 현실 문제 전체를 그대로 다루지 않습니다. 사람이 현실의 상황 중 일부를 골라 입력으로 만들고, 모델이 만들어야 할 출력을 정해야 합니다.

예를 들어 “고객 문의를 처리하고 싶다”는 말은 아직 모델링 과제가 아닙니다. 너무 넓고 모호합니다.

이 말을 조금씩 좁혀 보겠습니다.

세 번째 문장이 되면 모델링 과제에 가까워집니다. 무엇을 넣을지, 무엇을 얻을지, 어떤 과거 사례가 필요한지 보이기 시작하기 때문입니다.

AI 모델링 과제가 되려면 다음처럼 좁혀야 합니다.

이렇게 바꾸면 현실 업무가 다음 구조로 정리됩니다.

입력 -> 모델 -> 출력

flowchart TD
  R["현실 문제"]

  R --> I["입력"]
  R --> T["목표 출력"]
  R --> D["과거 사례"]

  D --> L["학습"]
  L --> M["학습된 모델"]
  I --> M
  M --> P["새 사례 예측"]

이 도식은 현실 문제를 바로 모델에 넣는 것이 아니라, 먼저 입력, 목표 출력, 과거 사례로 나눈 뒤 학습과 예측으로 이어지는 구조를 보여 줍니다. 맨 위의 현실 문제는 아직 넓은 현실 문제이고, 그 아래로 내려가며 무엇을 모델이 실제로 보게 할지와 무엇을 맞히게 할지가 좁혀집니다. 여기서는 이 그림을 현실 문제를 바로 푸는 기계가 아니라 현실 문제를 계산 가능한 작은 과제로 잘라 내는 과정으로 읽으면 됩니다.

Stanford Encyclopedia of Philosophy의 AI 항목은 지능형 에이전트를 환경에서 지각(percepts)을 받고 행동(actions)을 수행하는 함수로 설명하는 Russell과 Norvig의 관점을 소개합니다. 이 관점은 AI 문제를 입력과 출력, 또는 지각과 행동의 관계로 보는 데 도움이 됩니다.

다만 이 구조는 학습을 위한 단순화입니다. 실제 서비스에서는 입력 전에 전처리, 권한 확인, 개인정보 제거가 있을 수 있고, 출력 뒤에는 사람 검토, 정책 규칙, 업무 시스템 연동이 붙을 수 있습니다.

입력은 모델이 받는 관찰이다¶

입력(input)은 모델이 판단을 위해 받는 정보입니다. 입력은 문장일 수도 있고, 이미지일 수도 있고, 센서 값이나 표 형식 데이터일 수도 있습니다.

입력을 정할 때 중요한 점은 “현실에서 중요한 것”과 “모델에 실제로 들어가는 것”이 다를 수 있다는 점입니다. 고객의 진짜 의도는 중요하지만, 모델이 받는 입력이 문의 문장뿐이라면 모델은 그 문장 안에 드러난 단서만 사용할 수 있습니다.

고객 문의 예시를 더 자세히 보겠습니다.

이 경우 모델은 문의 문장만 보고 판단합니다. 사람이 보기에는 배송 상태가 중요하더라도, 그 정보가 입력에 없으면 모델은 사용할 수 없습니다.

예를 들어 다음 두 문의는 문장만 보면 비슷하지만, 실제 처리는 다를 수 있습니다.

따라서 입력을 정한다는 것은 “모델에게 무엇을 보여 줄 것인가”를 정하는 일입니다. 동시에 “모델에게 무엇을 보여 주지 않을 것인가”를 정하는 일이기도 합니다.

따라서 입력을 정할 때는 다음 질문이 필요합니다.

모델이 실제로 볼 수 있는 정보는 무엇인가? 그 정보는 판단에 충분한가? 중요하지만 빠진 정보는 없는가? 개인정보나 민감 정보가 포함되는가?

입력, 출력, 데이터, 사례, 라벨은 비슷하게 들릴 수 있습니다. 여기서 한 번만 대표 기준으로 묶어 두고, 뒤 문단에서는 이 구분을 전제로 입력과 출력 정의를 읽습니다.

이 단계에서는 입력은 넣는 정보, 출력은 얻고 싶은 결과, 데이터는 그런 사례 묶음, 라벨은 정답 이름이라는 구분이 먼저 남아 있으면 됩니다.

출력은 모델에게 시키는 일이다¶

출력(output)은 모델이 내야 하는 결과입니다. 같은 입력을 사용하더라도 출력을 어떻게 정하느냐에 따라 완전히 다른 문제가 됩니다.

예를 들어 같은 고객 문의 문장을 가지고도 다음처럼 여러 출력을 만들 수 있습니다.

따라서 “AI로 고객 문의를 처리한다”는 말만으로는 충분하지 않습니다. 모델이 내야 하는 출력이 범주인지, 숫자인지, 문장인지, 검토 여부인지 정해야 합니다. 이 출력 형태가 어떤 모델링 과제로 이어지는지는 4.4에서 따로 정리합니다.

같은 입력 문장을 놓고 출력 정의가 어떻게 달라지는지 보겠습니다.

입력이 다음과 같다고 하겠습니다.

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

이 문장 하나도 출력 정의에 따라 다른 과제가 됩니다.

여기서 중요한 점은 입력이 같아도 출력이 바뀌면 필요한 데이터가 바뀐다는 점입니다. 문의 유형을 고르는 모델을 만들려면 과거 문의에 배송, 환불, 교환 같은 라벨이 붙어 있어야 합니다. 답변 초안을 만드는 모델을 만들려면 좋은 답변 예시나 답변 작성 기준이 필요합니다.

출력을 정할 때는 다음 질문이 필요합니다.

모델이 하나의 범주를 고르면 되는가? 숫자 점수를 내야 하는가? 문장을 생성해야 하는가? 사람이 최종 확인할 중간 결과를 내면 되는가? 이 출력이 실제 업무 목표와 연결되는가?

데이터는 입력과 출력 사례의 모음이다¶

데이터(data)는 모델이 참고하거나 학습할 사례의 모음입니다. 지도학습(supervised learning)에서는 보통 입력과 정답 출력이 함께 있는 사례를 사용합니다.

Google의 머신러닝 입문 자료는 지도학습에서 예시(example)가 특징(features)과 라벨(label)을 포함한다고 설명합니다. 이 절에서는 이를 더 단순하게, 하나의 사례가 “입력과 원하는 출력의 묶음”이라고 읽습니다.

이 표는 단순하지만 중요한 구조를 보여 줍니다.

사례 1 = 입력 1 + 출력 1 사례 2 = 입력 2 + 출력 2 사례 3 = 입력 3 + 출력 3 ...

조금 더 천천히 말하면, 데이터는 모델에게 보여 주는 과거 사례입니다.

이런 입력이 들어왔을 때, 사람은 이런 출력을 기대했다.

모델은 이 반복된 사례를 통해 입력과 출력 사이의 관계를 조정합니다. 여기서는 아직 특징을 자세히 다루지 않으므로, 데이터를 “모델이 참고할 입력과 원하는 출력이 함께 있는 사례”로 이해하면 됩니다.

데이터를 만들 때도 속도를 늦춰 생각해야 합니다. 같은 고객 문의라도 라벨 기준이 흔들리면 모델이 배우기 어렵습니다.

이런 데이터는 파일로는 존재하지만, 좋은 학습 사례라고 보기 어렵습니다. 모델이 배울 기준이 흔들리기 때문입니다.

더 나은 데이터는 라벨 기준이 먼저 정리되어 있어야 합니다.

학습 기반 모델은 이런 사례를 사용해 입력과 출력 사이의 관계를 조정합니다. 다만 데이터가 있다고 해서 자동으로 좋은 모델이 되는 것은 아닙니다. 모델은 데이터에 없는 관계를 안정적으로 배울 수 없고, 잘못된 데이터의 관계도 그대로 배울 수 있습니다. 데이터가 실제 사용 환경을 충분히 대표하는지, 출력 라벨이 일관적인지, 잘못된 사례가 섞이지 않았는지 확인해야 합니다.

입력과 출력이 달라지면 데이터도 달라진다¶

현실 문제 하나가 항상 하나의 데이터셋으로 정해지는 것은 아닙니다. 어떤 입력과 출력을 고르느냐에 따라 데이터셋의 모양이 달라집니다. 이 절에서는 데이터의 모양만 확인하고, 과제 정의와 평가 기준은 4.4로 넘깁니다.

예를 들어 “배송 문제를 줄이고 싶다”는 목표를 생각해 보겠습니다.

이 예시는 입력과 출력 정의가 데이터의 모양을 결정한다는 점을 보여 줍니다. 같은 업무 목표라도 입력과 출력이 다르면 필요한 데이터가 달라집니다.

반대로 말하면, “데이터를 많이 모으자”만으로는 부족합니다. 어떤 입력과 출력을 학습할 데이터인지 먼저 정해야 합니다.

같은 “배송 문제”라도 모델에게 시키는 일이 다르면 데이터의 모양도 달라집니다. 어떤 과제로 정의할지, 어떤 모델 후보와 평가 기준을 둘지는 4.4에서 다룹니다.

입력과 출력 정의는 먼저 점검해야 한다¶

모델이 틀리는 이유가 항상 알고리즘에 있는 것은 아닙니다. 입력과 출력 정의가 애초에 문제를 잘못 잡았을 수도 있습니다. 4.2에서는 이 점을 경고 수준에서만 확인합니다.

예를 들어 고객 불만을 줄이고 싶으면서 입력으로 문의 문장만 사용하고, 출력으로 문의 유형만 예측한다고 해 봅니다. 이 모델은 문의를 분류할 수는 있지만, 고객 불만의 원인이 배송 지연인지, 상품 품질인지, 환불 정책인지 직접 해결하지는 못합니다.

다음과 같은 실수가 자주 생깁니다.

데이터가 실제 환경과 맞는지, 배포 후 성능이 유지되는지, 민감 정보를 어떻게 다룰지는 뒤의 문제 정의, 평가, 서비스 아키텍처에서 더 자세히 다룹니다.

이 입력으로 정말 이 출력을 판단할 수 있는가? 이 출력은 우리가 해결하려는 문제와 연결되는가? 이 데이터는 실제 사용할 상황을 대표하는가?

간단한 역할 구분 연습¶

아래 사례를 보고 먼저 입력 정의 문제인지, 출력 정의 문제인지, 데이터 정의 문제인지를 가려 보겠습니다.

이 연습의 핵심은 모델 성능 문제를 곧바로 알고리즘 문제로만 보지 않는 데 있습니다. 실제로는 무엇을 넣었는가, 무엇을 맞히게 했는가, 어떤 사례를 모았는가에서 문제가 먼저 생기는 경우가 많습니다.

체크리스트¶

• 입력(input), 출력(output), 데이터(data)의 역할을 구분할 수 있다.
• 현실 문제를 입력 -> 모델 -> 출력 구조로 바꾸어 설명할 수 있다.
• 같은 입력이라도 출력 정의에 따라 필요한 데이터가 달라질 수 있음을 설명할 수 있다.
• 데이터가 입력과 출력 사례의 모음임을 설명할 수 있다.
• 데이터가 모델의 내부 기준을 조정하는 근거가 됨을 설명할 수 있다.
• 입력과 출력 정의가 잘못되면 데이터 준비 이전에 문제가 생길 수 있음을 설명할 수 있다.
• 현실 문제는 바로 모델 문제가 되지 않고, 모델 문제가 되려면 입력, 출력, 데이터가 정해져야 한다는 점을 설명할 수 있다.
• 같은 현실 문제도 입력과 출력을 어떻게 정하느냐에 따라 필요한 데이터가 달라질 수 있다는 점을 설명할 수 있다.

출처와 참고 자료¶

• Stanford Encyclopedia of Philosophy, Selmer Bringsjord and Naveen Sundar Govindarajulu, Artificial Intelligence, 2018-07-12, 확인 날짜: 2026-06-22.
• Google for Developers, Supervised Learning, 확인 날짜: 2026-06-22.