학습, 검증, 테스트

모델을 만드는 일은 종종 이렇게 오해됩니다. 데이터를 모으고, 모델을 학습시키고, 마지막에 점수를 확인하는 순서라고 말입니다. 하지만 실제로는 반대에 가깝습니다. 어떻게 평가할지를 먼저 정해야, 무엇을 만들지 제대로 정할 수 있습니다.

같은 데이터로 학습도 하고 평가도 하면, 모델은 마치 시험 범위를 미리 본 학생처럼 너무 좋아 보입니다. 숫자는 높게 나오는데, 실제 서비스에 넣는 순간 성능이 미끄러집니다. 많은 머신러닝 실패가 알고리즘 선택이 아니라 잘못된 검증 절차에서 시작되는 이유가 여기에 있습니다.

이번 장에서는 모델의 진짜 실력을 보기 위해 데이터를 어떻게 나누고, 어떻게 검증하고, 어디서 속기 쉬운지 살펴보겠습니다. 핵심은 단순합니다. 평가는 모델을 만든 뒤의 체크리스트가 아니라, 모델 설계의 일부라는 점입니다.

왜 데이터를 나눠야 할까

머신러닝 모델이 잘하고 싶은 일은 과거를 설명하는 것이 아니라, 처음 보는 데이터에 대해 그럴듯한 판단을 내리는 것입니다. 그렇다면 평가도 당연히 처음 보는 데이터로 해야 합니다.

예를 들어 고객 이탈 예측 모델을 만든다고 해 봅시다. 이미 모델이 학습에 사용한 고객 기록을 다시 보여 주면, 모델은 꽤 높은 점수를 받을 수 있습니다. 하지만 우리가 알고 싶은 것은 그 점수가 아닙니다. 다음 달 새롭게 관찰될 고객에게도 이 모델이 쓸 만한가가 진짜 질문입니다.

그래서 데이터를 나눕니다. 가장 기본이 되는 세 조각은 다음과 같습니다.

• 학습 데이터: 모델이 실제로 배우는 데이터

• 검증 데이터: 모델을 고르고 조정할 때 참고하는 데이터

• 테스트 데이터: 마지막에 단 한 번, 최종 실력을 확인하는 데이터

이 셋은 비슷해 보여도 역할이 완전히 다릅니다. 학습 데이터는 연습장이고, 검증 데이터는 모의고사이며, 테스트 데이터는 진짜 시험이라고 생각하면 이해가 쉽습니다.

학습 데이터는 모델이 패턴을 배우는 곳이다

학습 데이터는 모델이 내부 규칙을 조정하는 재료입니다. 선형 회귀든 랜덤 포레스트든 부스팅이든, 모델은 이 데이터를 바탕으로 "어떤 입력이 어떤 결과와 자주 연결되는가"를 익힙니다.

이때 중요한 사실이 하나 있습니다. 학습 데이터에서 성능이 높다는 말은, 아직 절반만 좋은 소식이라는 점입니다. 연습장에서 완벽했다고 해서 실전에서도 잘한다는 보장은 없습니다. 오히려 지나치게 복잡한 모델은 학습 데이터의 우연한 잡음까지 외워 버릴 수 있습니다.

그래서 학습 데이터의 점수는 출발점일 뿐입니다. 학습 점수만 보고 만족하면, 모델은 대개 너무 낙관적으로 보입니다.

검증 데이터는 모델 선택을 위한 현실 점검표다

검증 데이터는 초보자가 가장 자주 놓치는 조각입니다. 많은 입문자가 데이터를 학습용과 테스트용 둘로만 나누고 바로 실험을 반복합니다. 문제는 그 순간부터 테스트 데이터가 더 이상 진짜 테스트 데이터가 아니라는 점입니다.

모델을 여러 개 바꿔 보고, 전처리 방법을 바꿔 보고, 하이퍼파라미터를 조절하면서 매번 테스트 점수를 확인하면 어떻게 될까요? 겉보기에는 테스트 데이터를 한 번도 학습에 넣지 않았습니다. 하지만 실제로는 테스트 점수에 맞춰 모델을 고르고 있는 셈입니다. 즉, 테스트 데이터가 모델 선택 과정에 참여하게 됩니다.

검증 데이터는 이 문제를 막기 위해 존재합니다. 모델을 바꾸고, 특성을 추가하고, 임계값을 조정하고, 하이퍼파라미터를 고를 때는 검증 데이터를 봅니다. 그리고 마지막에 정말 한 번만 테스트 데이터를 꺼냅니다.

이 흐름을 지키면 각 데이터의 역할이 분명해집니다.

• 학습 데이터는 배우는 용도

• 검증 데이터는 고르는 용도

• 테스트 데이터는 확인하는 용도

이 셋이 섞이는 순간, 평가는 설득력을 잃습니다.

테스트 데이터는 마지막까지 아껴 둬야 한다

테스트 데이터는 프로젝트의 마지막 문장에 가깝습니다. "이 모델은 지금까지 안 본 데이터에서도 이 정도 성능을 낸다"라고 말할 수 있게 해 주는 근거입니다.

그래서 테스트 데이터는 자주 보면 안 됩니다. 자주 볼수록 사람은 무의식적으로 그 점수에 맞춰 결정을 바꾸게 됩니다. 모델 구조를 바꾸고, 전처리를 바꾸고, 임계값을 바꾸는 동안 테스트 점수가 나침반이 되어 버리기 때문입니다.

테스트 데이터는 냉정해야 합니다. 나에게 친절한 피드백을 주는 데이터가 아니라, 마지막에 현실을 알려 주는 데이터여야 합니다. 모델이 검증 데이터에서는 좋아 보였는데 테스트 데이터에서 갑자기 무너진다면, 그것은 불행한 일이면서 동시에 아주 유용한 신호입니다. 지금까지의 설계가 충분히 일반화되지 않았다는 뜻이기 때문입니다.

데이터를 어떻게 나누는 것이 좋을까

실무에서 항상 정답 비율이 있는 것은 아니지만, 사고방식은 분명합니다. 데이터가 충분하다면 학습, 검증, 테스트를 별도로 나누고, 데이터가 부족하다면 검증 전략을 더 신중하게 가져가야 합니다.

예를 들어 데이터가 아주 많다면 검증과 테스트를 따로 떼어 내도 학습에 쓸 양이 충분합니다. 반대로 데이터가 작다면 검증용 데이터를 조금만 떼어 내도 결과가 불안정해질 수 있습니다. 이때 등장하는 방법이 바로 교차 검증입니다.

중요한 것은 숫자 비율보다 역할의 분리입니다. 데이터가 8:1:1이냐 7:2:1이냐보다 더 중요한 질문은 이것입니다.

"모델을 고르는 데 쓴 데이터와, 최종 성능을 말하는 데 쓴 데이터가 정말 분리되어 있는가?"

이 질문에 자신 있게 답할 수 있어야 합니다.

교차 검증은 작은 데이터에서 운의 영향을 줄여 준다

데이터가 적을 때는 한 번 나눈 검증 점수가 지나치게 흔들릴 수 있습니다. 우연히 쉬운 샘플이 검증 세트에 많이 들어가면 점수가 높아지고, 까다로운 샘플이 몰리면 점수가 낮아질 수 있습니다. 이런 상황에서 한 번의 분할만 믿고 모델을 선택하면, 모델보다 분할 운을 선택하는 셈이 되기 쉽습니다.

교차 검증은 이 흔들림을 줄이기 위한 방법입니다. 가장 대표적인 방식은 데이터를 여러 조각으로 나눈 뒤, 한 조각씩 돌아가며 검증용으로 쓰는 것입니다. 예를 들어 5개로 나누면, 4개로 학습하고 1개로 검증하는 과정을 5번 반복합니다. 그러면 각 샘플이 한 번씩은 검증에 참여하게 됩니다.

이 방식의 장점은 분명합니다. 한 번의 우연한 분할에 덜 휘둘리고, 모델 성능을 조금 더 안정적으로 추정할 수 있습니다. 특히 데이터가 많지 않은 분류 문제나 표 데이터 실험에서는 꽤 유용합니다.

교차 검증을 이해할 때 중요한 감각은 이것입니다. 교차 검증은 성능을 마법처럼 높여 주는 기술이 아닙니다. 대신 성능 추정치를 덜 불안하게 만들어 주는 기술입니다. 즉, 더 좋은 모델을 만든다기보다, 지금 모델이 얼마나 믿을 만한지 더 차분하게 보게 해 줍니다.

교차 검증은 언제 특히 유용할까

교차 검증이 빛나는 장면은 대개 비슷합니다. 데이터가 아주 크지 않고, 한 번의 분할 결과가 쉽게 흔들리며, 모델 비교를 신중하게 해야 할 때입니다.

예를 들어 고객 이탈 데이터가 몇 천 건 수준이라면, 검증 세트를 한 번 나누는 방식만으로는 특정 분할에 결과가 크게 좌우될 수 있습니다. 이럴 때 교차 검증을 하면 로지스틱 회귀, 랜덤 포레스트, 부스팅 모델 중 어느 쪽이 더 안정적인지 조금 더 신뢰 있게 비교할 수 있습니다.

다만 교차 검증도 만능은 아닙니다. 데이터가 매우 크다면 계산 비용이 커질 수 있고, 시계열처럼 시간 순서가 중요한 문제에서는 일반적인 섞기 방식의 교차 검증을 그대로 쓰면 안 됩니다. 방법을 쓰는 것보다, 문제의 구조에 맞게 쓰는 것이 중요합니다.

검증 점수가 좋아도 안심할 수 없는 이유

검증 데이터까지 분리했는데도 결과가 과장될 때가 있습니다. 바로 실험을 너무 오래 하면서 검증 데이터에까지 익숙해지는 경우입니다.

모델을 수십 번, 수백 번 바꾸다 보면 사람은 검증 세트의 성향을 무의식적으로 배우게 됩니다. 특정 특성을 넣었을 때 왜 좋아지는지 모르더라도, 검증 점수가 오른다는 이유만으로 선택을 반복하게 됩니다. 그러면 모델이 일반적 패턴을 배운 것인지, 검증 데이터의 우연한 구조를 따라간 것인지 헷갈려집니다.

그래서 실무에서는 검증 절차뿐 아니라 실험 기록도 중요합니다. 어떤 분할로 실험했는지, 어떤 전처리를 적용했는지, 어떤 하이퍼파라미터를 시도했는지 남겨야 합니다. 그래야 점수의 상승이 진짜 개선인지, 우연한 최적화인지 구분할 수 있습니다.

평가는 숫자를 보는 일이지만, 동시에 태도의 문제이기도 합니다. 너무 자주 들여다본 데이터는 더 이상 중립적이지 않습니다.

데이터 누수는 점수를 예쁘게 만드는 가장 위험한 지름길이다

머신러닝에서 가장 교묘한 실패 중 하나가 데이터 누수입니다. 데이터 누수는 말 그대로 원래 평가 단계에서 알 수 없어야 할 정보가 학습 단계로 새어 들어가는 현상입니다.

이 문제는 무섭습니다. 모델 구조가 훌륭해 보여도, 실제로는 미래 정보를 몰래 본 덕분에 점수가 잘 나왔을 수 있기 때문입니다. 서비스에 배포하는 순간 그 정보는 더 이상 존재하지 않으므로 성능이 무너집니다.

데이터 누수는 대놓고 일어나지 않는 경우가 많습니다. 그래서 입문자도, 숙련자도 둘 다 걸릴 수 있습니다. 겉보기에는 그럴듯한 전처리나 특성 생성이 사실은 답안지를 슬쩍 훔쳐본 것일 수 있습니다.

전처리에서 자주 생기는 누수

가장 흔한 누수는 전처리를 데이터 전체에 먼저 해 버리는 경우입니다. 예를 들어 평균과 표준편차를 계산해 정규화하거나, 결측치를 평균값으로 채우거나, 범주형 인코딩 기준을 만들 때 전체 데이터를 한꺼번에 쓰는 실수입니다.

겉으로 보면 별문제가 없어 보입니다. 어차피 숫자를 바꿔 주는 작업일 뿐이라고 생각하기 쉽기 때문입니다. 하지만 여기에는 테스트 데이터의 통계가 이미 들어 있습니다. 즉, 모델은 학습 과정에서 원래 몰라야 할 미래의 분포 정보를 일부 공유받은 셈이 됩니다.

올바른 순서는 항상 같습니다. 학습 데이터에서만 전처리 기준을 만들고, 검증 데이터와 테스트 데이터에는 그 기준을 그대로 적용해야 합니다. 평균도, 표준편차도, 인코딩 사전도, 특성 선택 기준도 마찬가지입니다.

이 원칙을 한 문장으로 기억하면 좋습니다. 무엇을 배우든 기준은 학습 데이터에서만 만든다.

특성 생성에서 생기는 더 위험한 누수

전처리보다 더 위험한 것은 특성 생성 단계의 누수입니다. 특히 실무 데이터에서는 시간과 집계가 얽혀 있어 무심코 미래 정보가 섞이기 쉽습니다.

예를 들어 고객 이탈 예측에서 "향후 30일간 접속 수"를 특성으로 넣었다면, 이미 정답 이후의 정보를 본 것입니다. 이탈을 예측하려는 시점에 미래 30일의 접속 수를 알 수는 없기 때문입니다. 이렇게 만든 모델은 놀라울 정도로 높은 점수를 낼 수 있지만, 현실에서는 작동하지 않습니다.

비슷한 예는 얼마든지 있습니다.

• 대출 연체 예측에서 연체 발생 후 생성된 상담 기록을 특성에 넣는 경우

• 환자 위험 예측에서 진단 확정 뒤에만 측정되는 검사를 입력에 포함하는 경우

• 주문 취소 예측에서 취소 직전에만 나타나는 운영 상태값을 사용하는 경우

이런 문제는 기술적 실수라기보다 예측 시점 정의의 실패에서 시작됩니다. 모델이 실제로 예측을 수행하는 순간을 먼저 정하지 않으면, 나중에 생긴 정보가 아주 자연스럽게 데이터에 끼어들게 됩니다.

데이터 누수를 막는 가장 좋은 질문

누수를 막는 데 가장 강력한 질문은 의외로 단순합니다.

"이 정보는 예측 시점에 정말 알 수 있었는가?"

모든 특성과 전처리 단계에 이 질문을 붙여 보면, 많은 문제가 바로 드러납니다. 예측 시점에 존재하지 않았던 정보라면 넣으면 안 됩니다. 예측 시점에는 알 수 없지만 사후 집계로 계산된 값이라면 역시 위험합니다. 테스트 데이터를 포함해 계산한 기준이라면 그 또한 누수입니다.

머신러닝 실험에서는 화려한 모델보다 이 질문 하나가 더 큰 차이를 만들 때가 많습니다.

파이프라인 사고가 누수를 막아 준다

데이터 누수를 줄이려면 코드를 잘 쓰는 것보다 흐름을 잘 쪼개는 사고방식이 중요합니다. 즉, 데이터를 먼저 나누고, 학습 데이터에서만 전처리와 특성 생성 규칙을 만들고, 그 규칙을 검증과 테스트에 적용하는 순서를 습관처럼 유지해야 합니다.

이때 파이프라인이라는 개념이 도움이 됩니다. 파이프라인은 전처리와 모델 학습을 하나의 절차로 묶어, 학습 단계에서 만들어진 기준이 평가 단계에 일관되게 적용되도록 해 줍니다. 입문자에게 파이프라인은 단지 코드를 예쁘게 만드는 구조가 아닙니다. 실험을 정직하게 만드는 안전장치에 가깝습니다.

실무에서는 성능을 조금 더 높이는 트릭보다, 이런 구조적 안전장치가 훨씬 큰 가치를 가집니다. 잘못된 점수로 좋은 결정을 내리기는 어렵기 때문입니다.

시계열 데이터는 왜 섞으면 안 될까

시계열 데이터에서는 시간 자체가 정보입니다. 오늘의 판매량, 어제의 접속 수, 지난주 센서 로그처럼 순서가 중요한 데이터에서는 과거가 미래보다 앞서야 합니다. 너무 당연한 말 같지만, 이 원칙이 실제 실험에서 자주 무너집니다.

일반적인 분류 문제처럼 데이터를 무작위로 섞어 학습과 검증으로 나누면 어떤 일이 생길까요? 모델은 미래 구간의 패턴을 일부 본 상태에서 과거를 예측하는 이상한 상황에 놓입니다. 현실에서는 절대 불가능한 조건입니다.

예를 들어 12월 매출을 예측하는 모델을 만들면서 1월부터 12월까지 데이터를 무작위로 섞어 버리면, 모델은 사실상 미래의 계절성이나 이벤트 패턴을 엿본 셈이 됩니다. 검증 점수는 그럴듯해 보일 수 있습니다. 하지만 실제 운영에서는 오늘 시점에서 내일 이후를 예측해야 하므로, 그런 정보는 존재하지 않습니다.

시계열에서는 반드시 과거로 학습하고, 미래로 검증해야 합니다. 이것이 기본 원칙입니다.

시계열 분리의 올바른 감각

시계열 검증에서는 시간 순서를 보존한 채 데이터를 나눠야 합니다. 예를 들어 1월부터 9월까지로 학습하고 10월로 검증한 뒤, 필요하다면 1월부터 10월까지로 다시 학습하고 11월로 검증하는 식의 방식이 더 현실적입니다. 이렇게 하면 실제 운영 환경처럼 "지금까지의 데이터로 다음 구간을 예측하는" 조건을 흉내 낼 수 있습니다.

여기서 핵심은 단순히 날짜 칼럼을 기준으로 자르는 데 그치지 않습니다. 특성을 만드는 방식도 시간 순서를 지켜야 합니다. 이동 평균, 최근 7일 합계, 누적 사용자 수 같은 집계 특성은 반드시 해당 시점 이전 데이터로만 계산해야 합니다. 미래 구간까지 포함해 계산한 이동 평균은 아주 전형적인 누수입니다.

시계열 모델링에서는 모델보다 분리 방식이 더 중요하게 작용하는 경우도 많습니다. 평가가 현실을 닮아 있지 않으면, 모델 성능은 언제든 착시가 됩니다.

분류 문제와 시계열 문제는 검증 철학이 다르다

표 데이터 분류 문제에서는 데이터가 서로 독립적이라고 가정할 수 있는 경우가 많아서 무작위 분할이나 교차 검증이 잘 작동합니다. 하지만 시계열에서는 각 샘플이 시간으로 연결되어 있기 때문에, 같은 방법을 그대로 쓰면 현실성이 깨집니다.

이 차이를 이해하면 검증이 단순한 기술이 아니라 문제 구조를 반영하는 설계라는 점이 선명해집니다. 검증은 정답이 하나인 메뉴얼이 아닙니다. 내 데이터가 어떤 세계를 담고 있는지에 따라, 검증 방식도 달라져야 합니다.

그래서 모델링을 시작할 때는 알고리즘보다 먼저 이런 질문을 던지는 편이 좋습니다.

• 이 데이터는 시간 순서가 중요한가?

• 같은 사용자, 같은 기기, 같은 그룹이 학습과 검증에 동시에 섞이면 안 되는가?

• 실제 예측 시점에 사용할 수 없는 정보가 숨어 있지는 않은가?

이 질문들이 평가 설계의 뼈대를 만듭니다.

좋은 평가는 좋은 모델보다 먼저 온다

입문 단계에서는 성능 향상 기법에 눈이 먼저 갑니다. 더 강한 알고리즘, 더 많은 특성, 더 복잡한 앙상블이 매력적으로 보입니다. 하지만 평가 절차가 흔들리면, 그 모든 개선은 모래 위에 쌓은 탑이 됩니다.

좋은 평가는 모델을 냉정하게 보게 해 줍니다. 어떤 모델이 진짜 강한지, 어떤 전처리가 실제로 도움이 되는지, 어디서 누수가 생겼는지, 서비스에 배포했을 때 얼마나 버틸지를 더 정확히 알려 줍니다.

반대로 나쁜 평가는 자신감을 줍니다. 문제는 그 자신감이 대개 가짜라는 점입니다. 머신러닝 프로젝트에서 가장 위험한 순간은 성능이 낮을 때가 아니라, 이상하게 너무 잘 나올 때인 경우가 많습니다.

그러니 점수가 높게 나왔을수록 먼저 의심해 보아야 합니다. 분리는 올바른가, 누수는 없는가, 검증 방식은 현실을 닮았는가. 좋은 실무자는 성능을 자랑하기 전에 평가를 검토합니다.

이 장에서 가져가야 할 감각

이번 장의 핵심은 분명합니다. 모델 평가는 학습이 끝난 뒤의 행사 절차가 아니라, 모델 설계의 일부입니다.

학습 데이터는 모델이 배우는 곳이고, 검증 데이터는 선택과 조정의 기준이며, 테스트 데이터는 마지막 현실 점검입니다. 데이터가 적다면 교차 검증으로 성능 추정의 흔들림을 줄일 수 있습니다. 전처리와 특성 생성에서는 예측 시점에 알 수 없는 정보가 섞이지 않도록 늘 경계해야 합니다. 그리고 시계열에서는 무엇보다 시간 순서를 보존해야 합니다.

이 감각을 갖추면 점수에 덜 속게 됩니다. 그리고 점수에 덜 속는 사람일수록, 결국 더 좋은 모델을 만듭니다.

다음 장에서는 이제 한 걸음 더 나아가, 이렇게 분리하고 검증한 결과를 어떤 숫자로 읽어야 하는지 살펴보겠습니다. 정확도만 보면 왜 위험한지, 정밀도와 재현율은 언제 중요해지는지, ROC-AUC와 PR-AUC는 어떤 상황에서 의미가 달라지는지를 본격적으로 다룰 차례입니다.