학습 데이터의 설계

어떤 팀은 더 큰 모델을 찾느라 바쁘고, 어떤 팀은 더 좋은 프롬프트를 찾느라 분주하다. 그런데 실무에서 성능을 가장 크게 바꾸는 것이 의외로 훨씬 덜 화려한 곳에 숨어 있는 경우가 많다. 바로 데이터다. 모델은 결국 데이터로부터 세상을 배운다. 아무리 구조가 훌륭해도, 무엇을 보여 주었는지와 어떻게 보여 주었는지가 엉성하면 모델은 그 엉성함까지 정직하게 배운다.

이 점이 중요하다. 좋은 모델은 종종 좋은 아키텍처에서만 나오지 않는다. 좋은 데이터 설계에서 나온다. 데이터는 연료가 아니라 교과서에 가깝다. 어떤 내용을, 어떤 순서로, 어떤 기준으로 담았는지가 모델의 사고방식을 만든다.

데이터 수집은 세계를 고르는 일이다

데이터를 모은다는 말은 흔히 단순한 수집 작업처럼 들린다. 하지만 실제로는 모델에게 어떤 세계를 보여 줄지 결정하는 일이다. 고객 상담 모델을 만든다면, 모델은 회사의 실제 고객이 쓰는 말투를 알아야 한다. 검색 보조 모델을 만든다면, 정제된 백서만이 아니라 어수선한 사내 문서, 오래된 문서, 표현이 제각각인 문서까지 접하게 될 가능성을 고려해야 한다.

문제는 현실의 데이터가 늘 지저분하다는 데 있다. 같은 의미의 문서가 여러 버전으로 흩어져 있고, 파일 형식은 제각각이며, 날짜 표기나 단위 표기도 통일되어 있지 않다. 이 상태로 학습에 넣으면 모델은 중요한 패턴보다 불필요한 잡음을 더 많이 본다. 그러면 학습은 느려지고, 예측은 흔들리고, 배포 후에는 "왜 이렇게 기본적인 것도 불안정하지?"라는 질문이 돌아온다.

그래서 수집 단계에서는 양만 보지 말고 대표성을 봐야 한다. 많이 모으는 것보다, 실제 사용 환경을 얼마나 닮았는가가 더 중요할 때가 많다. 한쪽 유형의 데이터만 지나치게 많으면 모델은 그 세계가 전부라고 착각한다. 결국 데이터 수집은 파일을 모으는 일이 아니라, 현실을 샘플링하는 일이다.

정제, 중복 제거, 포맷 통일이 학습 품질을 만든다

데이터 엔지니어링은 자주 뒷정리처럼 취급되지만, 사실은 성능 설계의 핵심이다. 특히 정제와 중복 제거는 모델이 무엇을 더 자주, 더 강하게 배우게 될지를 바꾼다.

예를 들어 같은 문장이 수천 번 반복된 데이터셋을 생각해 보자. 모델은 그 패턴을 지나치게 자주 보게 되고, 실제보다 더 중요한 신호라고 오해할 수 있다. 중복은 데이터 양을 부풀려 보이게 하지만, 정보량을 늘려 주지는 않는다. 오히려 특정 표현, 특정 문체, 특정 라벨을 과장해 학습 편향을 키우기도 한다.

포맷 통일도 마찬가지다. 날짜는 어떤 문서에서는 2026-04-30, 다른 문서에서는 26년 4월 30일, 또 다른 곳에서는 April 30, 2026으로 적혀 있다고 해보자. 사람은 대충 같은 뜻으로 읽지만, 모델 입장에서는 서로 다른 패턴이 늘어난 셈이다. 이것이 꼭 나쁜 것은 아니지만, 불필요한 변동이 너무 많으면 모델은 핵심 개념보다 표면 형식에 끌려다니기 쉽다.

실무에서 이 단계는 대체로 네 가지 질문으로 압축된다.

• 이 데이터는 정말 학습에 필요한 정보인가

• 같은 내용이 반복되어 특정 패턴을 과대대표하지 않는가

• 필드 이름, 단위, 날짜, 인코딩, 문서 구조가 일관적인가

• 깨진 텍스트, 누락 값, 잘못 연결된 레코드가 섞여 있지 않은가

이 질문들은 단순해 보이지만, 실제 성능 차이는 여기서 크게 벌어진다. 모델이 똑똑하지 않아서 틀리는 경우도 있지만, 그보다 먼저 데이터가 흐릿해서 헷갈리는 경우가 훨씬 많다.

라벨링은 정답 붙이기가 아니라 기준을 설계하는 일이다

지도학습에서는 라벨이 모델의 선생님 역할을 한다. 그런데 많은 팀이 라벨링을 "정답을 붙이는 단순 노동"으로 생각하다가 큰 대가를 치른다. 진짜 중요한 것은 라벨 자체보다 라벨링 지침이다. 어떤 경우를 긍정으로 볼지, 애매한 사례는 어떻게 처리할지, 사람마다 해석이 갈리는 표현은 무엇으로 통일할지를 먼저 정해야 한다.

예를 들어 고객 문의를 "환불", "배송", "제품 문의"로 분류한다고 해보자. 얼핏 쉬워 보이지만 실제 문의는 그렇게 깔끔하지 않다. "배송이 늦었는데 그냥 환불하고 싶어요" 같은 문장은 어디에 넣어야 할까. 어떤 작업자는 배송으로, 다른 작업자는 환불로 붙일 수 있다. 이때 문제는 작업자가 틀렸다는 데 있지 않다. 기준이 모호했다는 데 있다.

라벨 품질이 낮으면 모델은 세상을 잘못 배우는 것이 아니라, 세상을 모순되게 배운다. 같은 입력에 다른 정답이 붙어 있으면 모델은 일관된 경계를 만들기 어렵다. 학습 손실은 줄지 않고, 배포 후 예측도 오락가락한다.

그래서 좋은 라벨링 설계에는 예시가 필요하다. 정답 예시뿐 아니라 경계 사례, 예외 사례, 자주 헷갈리는 사례가 함께 있어야 한다. 그리고 라벨러 사이의 일치도를 확인해야 한다. 두 사람이 자주 다르게 판단한다면, 모델을 탓하기 전에 지침부터 다시 써야 한다. 데이터셋의 품질은 종종 라벨 수가 아니라 판단 기준의 선명도에서 결정된다.

편향, 데이터 누수, 분포 불일치는 배포 후에 폭발한다

데이터 문제는 학습 단계에서는 조용히 숨어 있다가, 서비스에 붙는 순간 크게 드러난다. 그중 가장 위험한 세 가지가 편향, 데이터 누수, 분포 불일치다.

편향은 특정 집단, 표현, 상황이 과소대표되거나 과대대표되는 문제다. 채용 데이터를 학습했더니 특정 배경의 지원자에게 불리한 판단을 내리거나, 고객 응대 모델이 특정 말투를 유독 공격적으로 해석하는 식이다. 모델은 사회를 이해하지 않는다. 단지 데이터의 반복 패턴을 배운다. 그래서 데이터 안에 왜곡이 있으면 모델은 그 왜곡을 성실하게 재현한다.

데이터 누수는 더 교묘하다. 훈련 과정에서 원래는 알 수 없어야 할 정보가 새어 들어오는 것이다. 예를 들어 테스트셋과 거의 같은 문서가 훈련셋에 섞여 있거나, 미래 예측 문제인데 미래 정보가 입력에 포함되어 있으면 모델은 실력보다 훨씬 좋아 보인다. 이때 팀은 "성능이 아주 잘 나온다"고 기뻐하지만, 실제 배포 순간 성능이 무너진다. 시험지를 미리 본 학생이 모의고사에서 잘 본 셈이기 때문이다.

분포 불일치는 학습할 때 본 데이터와 실제 운영 데이터의 성격이 달라지는 현상이다. 학습 데이터는 깔끔한 문장인데, 실제 사용자는 오타투성이 문장으로 질문한다. 학습 데이터는 낮 시간대 거래만 많았는데, 실제 서비스는 야간 패턴이 다르다. 이런 차이가 크면 모델은 훈련 때 잘하던 일을 실전에서 갑자기 못한다. 모델이 망가진 것이 아니라, 세계가 달라진 것이다.

그래서 데이터 설계는 언제나 묻는다. "이 데이터로 배운 모델이, 배포될 그 세계에서도 여전히 통할까?" 이 질문을 빼먹으면 테스트 점수는 높아도 제품은 흔들린다.

합성 데이터와 데이터 증강은 부족한 세계를 메우는 도구다

현실 데이터는 비싸고, 느리고, 민감하고, 불균형하다. 그래서 실무에서는 합성 데이터와 데이터 증강이 점점 중요해진다. 둘은 비슷해 보이지만 역할이 조금 다르다.

데이터 증강은 기존 데이터를 살짝 변형해 더 다양한 사례를 만드는 방식이다. 이미지에서는 회전, 자르기, 밝기 조절 같은 방법이 대표적이고, 텍스트에서는 표현을 바꾸거나 질문 형태를 다양화하는 방법을 쓸 수 있다. 목적은 단순하다. 모델이 표면적 모양이 조금 달라져도 같은 본질을 알아보게 만드는 것이다.

합성 데이터는 아예 새로운 데이터를 만들어 내는 접근이다. 희귀한 오류 사례를 시뮬레이션하거나, 특정 도메인 대화를 인공적으로 생성하거나, 개인정보 때문에 실제 데이터를 충분히 모으기 어려운 상황에서 초안을 만드는 식이다. 잘만 쓰면 비용을 줄이고, 드문 경우의 수를 넓히고, 데이터 공백을 메울 수 있다.

하지만 여기에도 함정은 있다. 합성 데이터는 진짜처럼 보여도 진짜가 아닐 수 있다. 문장은 그럴듯하지만 실제 사용자의 거친 말투가 빠져 있을 수 있고, 이미지가 깨끗하지만 현실의 노이즈를 반영하지 못할 수 있다. 그래서 합성 데이터는 현실을 대체하는 재료가 아니라, 현실 데이터를 보완하는 재료로 보는 편이 안전하다.

핵심은 균형이다. 현실 데이터로 바닥을 만들고, 증강과 합성으로 사각지대를 메운다. 이 순서가 뒤집히면 모델은 현실보다 실험실에 더 잘 적응하는 이상한 학생이 되기 쉽다.

데이터셋은 제품 전략이다

좋은 데이터 설계는 모델 성능만 높이는 일이 아니다. 무엇을 자동화할 수 있는지, 어디까지 신뢰할 수 있는지, 어떤 사용자에게 강한지를 결정한다. 그래서 데이터셋은 기술 자산이면서 동시에 제품 자산이다.

같은 모델을 써도 어떤 팀은 강하고 어떤 팀은 약한 이유가 여기에 있다. 차이는 종종 모델 이름이 아니라, 어떤 데이터를 모았는지, 무엇을 버렸는지, 라벨 기준을 얼마나 단단히 세웠는지, 배포 세계와 얼마나 비슷하게 설계했는지에서 나온다.

결국 딥러닝에서 데이터는 재료가 아니다. 모델이 세상을 이해하는 방식 그 자체다. 아키텍처는 모델의 몸을 만들고, 데이터는 모델의 경험을 만든다. 그리고 실제 서비스에서 더 오래 남는 것은 대개 더 멋진 몸보다, 더 좋은 경험을 가진 모델이다.

다음 장에서는 이 데이터가 실제로 어떻게 학습되고 서비스에서 어떻게 돌아가는지 살펴본다. 좋은 데이터를 준비했다면, 이제 그 데이터를 제대로 소화할 학습 인프라와 추론 인프라를 이해할 차례다.