모델 선택과 실험 관리

모델을 고른다는 것은 무엇을 고른다는 뜻일까

머신러닝을 처음 배울 때는 이런 생각을 하기 쉽습니다.

"그래서 어떤 모델이 제일 좋아요?"

선형회귀, 로지스틱 회귀, 결정트리, 랜덤포레스트, 그래디언트 부스팅까지 배우고 나면 더 헷갈립니다. 어떤 책에서는 랜덤포레스트가 좋다고 하고, 어떤 대회에서는 그래디언트 부스팅이 강하다고 합니다. 딥러닝이 유행하니 신경망을 써야 할 것 같기도 합니다.

하지만 실전에서 더 중요한 질문은 따로 있습니다.

"이 문제, 이 데이터, 이 제약 조건에서 어떤 모델이 가장 적절한가?"

좋은 모델은 이름값으로 결정되지 않습니다. 같은 모델이라도 데이터가 달라지면 결과가 달라지고, 같은 데이터라도 특징을 어떻게 만들었는지에 따라 성능이 달라집니다. 하이퍼파라미터를 조금 바꾸었을 뿐인데 결과가 크게 출렁일 때도 있습니다.

그래서 모델 선택은 감으로 찍는 일이 아닙니다. 여러 후보를 공정하게 비교하고, 그 과정을 기록하며, 다시 실행해도 비슷한 결론에 도달할 수 있도록 관리하는 일입니다.

앞 장에서 우리는 데이터 누수를 배웠습니다. 예측 시점에 알 수 없는 정보가 몰래 들어오면 성능이 좋아 보이지만, 실제 서비스에서는 무너질 수 있었습니다. 이제 한 걸음 더 나아가 봅시다. 깨끗한 평가 절차를 만들었다면, 그 위에서 어떤 모델을 선택해야 할까요?

이 장의 핵심은 단순합니다.

좋은 모델은 한 번의 번뜩이는 선택이 아니라, 체계적인 비교와 기록을 통해 만들어집니다.

기준 모델부터 만든다

실험을 시작할 때 가장 먼저 해야 할 일은 멋진 모델을 고르는 것이 아닙니다. 기준 모델을 만드는 것입니다. 기준 모델은 앞으로의 모든 개선이 의미 있는지 판단하게 해 주는 출발선입니다.

집값을 예측한다고 해 봅시다. 처음부터 랜덤포레스트나 그래디언트 부스팅을 돌리고 싶을 수 있습니다. 하지만 그 전에 아주 단순한 모델을 하나 만들어야 합니다. 예를 들어 모든 집값을 학습 데이터의 평균값으로 예측하는 모델을 만들 수 있습니다.

"그게 무슨 모델이야?"라고 느껴질 수 있습니다. 맞습니다. 아주 단순합니다. 하지만 바로 그 점이 중요합니다.

평균값만 예측하는 모델보다 훨씬 나아지지 못한다면, 우리가 만든 복잡한 모델은 별 가치가 없습니다. 반대로 단순한 기준 모델보다 확실히 좋아졌다면, 이제 개선의 방향이 보이기 시작합니다.

분류 문제에서도 마찬가지입니다. 스팸 메일 분류기를 만든다면 모든 메일을 '정상'으로 예측하는 모델을 먼저 생각해 볼 수 있습니다. 고객 이탈 예측에서는 모든 고객을 '이탈하지 않음'으로 예측하는 모델이 기준이 될 수 있습니다. 물론 이런 모델은 똑똑하지 않습니다. 그러나 데이터가 한쪽으로 치우쳐 있을 때는 의외로 높은 정확도를 보일 수 있습니다.

예를 들어 고객 100명 중 95명이 이탈하지 않는다면, 모든 고객을 '이탈하지 않음'으로 찍어도 정확도는 95%입니다. 이때 새 모델의 정확도가 96%라고 해서 무조건 좋은 모델이라고 말할 수 있을까요? 아닙니다. 실제로 중요한 이탈 고객 5명을 여전히 거의 못 찾고 있을지도 모릅니다.

기준 모델은 우리에게 냉정한 질문을 던집니다.

"지금 만든 모델은 정말로 문제를 더 잘 풀고 있는가, 아니면 그럴듯해 보일 뿐인가?"

좋은 실험은 이 질문에서 시작합니다.

한 번에 하나씩 바꾸기

모델을 개선하려고 할 때 흔히 저지르는 실수가 있습니다. 한 번에 너무 많은 것을 바꾸는 것입니다.

처음에는 로지스틱 회귀를 썼습니다. 다음 실험에서는 랜덤포레스트로 바꾸고, 결측치 처리 방식도 바꾸고, 새로운 특징도 추가하고, 학습 데이터 기간도 늘렸습니다. 점수가 올랐습니다. 기분은 좋습니다. 그런데 문제가 생깁니다.

무엇 때문에 좋아졌는지 알 수 없습니다.

모델이 좋아서일까요? 새 특징이 효과적이었을까요? 결측치 처리 방식이 나아진 걸까요? 아니면 우연히 검증 데이터에 잘 맞은 걸까요?

실험은 요리와 비슷합니다. 라면을 더 맛있게 끓이고 싶어서 물의 양, 스프 양, 면 삶는 시간, 계란 넣는 시점, 불 세기를 한 번에 다 바꾸면 어떤 변화가 맛을 좋게 만들었는지 알기 어렵습니다. 다음에 다시 맛있게 만들기도 어렵습니다.

머신러닝 실험도 마찬가지입니다. 가능하면 한 번에 하나의 요소만 바꿔야 합니다. 물론 실전에서는 시간이 부족해서 완벽하게 통제하기 어렵습니다. 그래도 기본 원칙은 분명합니다. 바꾼 것이 무엇인지 알아야 결과를 해석할 수 있습니다.

기준 모델을 만든 다음에는 점진적으로 개선합니다. 먼저 간단한 모델을 학습합니다. 그다음 특징을 조금 추가해 봅니다. 이후 모델을 바꿔 봅니다. 마지막으로 하이퍼파라미터를 조정합니다. 이렇게 해야 어떤 선택이 성능에 영향을 주었는지 추적할 수 있습니다.

머신러닝의 기본 흐름을 다시 떠올려 봅시다.

데이터를 준비합니다. 특징을 만듭니다. 모델이 예측합니다. 실제값과 비교합니다. 오차를 줄입니다. 새로운 데이터에 적용합니다.

실험 관리는 이 흐름을 여러 번 반복하되, 매번 무엇이 달라졌는지 남기는 일입니다.

실험 기록에는 무엇이 들어가야 할까

실험을 몇 번만 해도 처음에는 기억할 수 있을 것 같습니다. "아까 그 모델이 좋았지", "이번에는 특징을 조금 바꿨지" 정도로 머릿속에 남아 있습니다.

하지만 실험이 열 번, 스무 번, 서른 번을 넘어가면 이야기가 달라집니다. 어떤 데이터로 학습했는지, 어떤 전처리를 했는지, 하이퍼파라미터를 어떻게 설정했는지, 평가 지표가 무엇이었는지 헷갈리기 시작합니다. 점수가 가장 좋았던 실험을 다시 실행했는데 결과가 다르게 나오기도 합니다.

그래서 실험은 반드시 기록해야 합니다. 기록하지 않은 실험은, 조금 과장하면, 하지 않은 실험과 비슷합니다. 결과를 믿기도 어렵고, 다른 사람에게 설명하기도 어렵고, 나중에 다시 재현하기도 어렵기 때문입니다.

실험 기록에는 적어도 다음 정보가 함께 남아야 합니다.

여기서 하이퍼파라미터라는 말이 다시 나왔습니다. 하이퍼파라미터는 모델이 데이터에서 직접 배우는 값이 아니라, 사람이 학습 전에 정해 주는 설정값입니다. 결정트리의 최대 깊이, 랜덤포레스트의 트리 개수, 그래디언트 부스팅의 학습률 같은 것이 여기에 해당합니다.

모델은 데이터에서 규칙을 배웁니다. 하지만 어떤 방식으로, 얼마나 복잡하게, 얼마나 오래 배울지는 우리가 정한 설정에 영향을 받습니다. 그래서 모델 종류만 기록해서는 부족합니다. 같은 랜덤포레스트라도 트리 50개를 쓴 모델과 트리 500개를 쓴 모델은 서로 다른 실험입니다.

점수표를 만드는 습관

실험을 기록할 때는 점수표를 만드는 습관이 좋습니다. 처음에는 간단한 표면 충분합니다.

이 표는 단순하지만 강력합니다. 실험의 흐름이 보이기 때문입니다. 기준 모델에서 시작해, 선형 모델을 거치고, 트리 기반 모델로 넘어가고, 특징을 추가하고, 하이퍼파라미터를 조정한 과정이 한눈에 들어옵니다.

중요한 것은 최고 점수만 남기는 것이 아닙니다. 실패한 실험도 남겨야 합니다. 어떤 특징을 추가했더니 성능이 떨어졌다면 그것도 중요한 정보입니다. 어떤 모델이 학습은 오래 걸렸지만 성능 개선이 작았다면 그 역시 다음 의사결정에 도움이 됩니다.

실패한 실험을 지우면 우리는 같은 실수를 반복합니다. 반대로 실패한 실험을 기록하면 데이터에 대한 이해가 쌓입니다. 머신러닝 프로젝트에서 실험 기록은 단순한 행정 작업이 아니라, 지식이 축적되는 장소입니다.

성능이 가장 높은 모델이 항상 좋은 모델은 아니다

검증 점수가 가장 높은 모델을 고르면 끝일까요? 꼭 그렇지는 않습니다.

머신러닝 모델은 실제 문제를 풀기 위해 존재합니다. 실제 문제에는 숫자 성능 외에도 여러 조건이 붙습니다. 모델이 너무 느리면 서비스에 넣기 어렵습니다. 운영 비용이 지나치게 크면 유지하기 어렵습니다. 성능은 좋지만 왜 그런 예측을 했는지 전혀 설명할 수 없다면, 금융이나 의료처럼 설명이 중요한 분야에서는 쓰기 어렵습니다.

예를 들어 대출 심사 모델을 생각해 봅시다. 어떤 모델이 승인 여부를 꽤 잘 예측합니다. 하지만 고객에게 "왜 대출이 거절되었나요?"라는 질문을 받았을 때 아무 설명도 할 수 없다면 문제가 됩니다. 반대로 조금 단순한 모델이라도 주요 판단 근거를 설명할 수 있다면 더 적절한 선택일 수 있습니다.

스팸 메일 분류기에서는 속도가 중요할 수 있습니다. 메일이 들어올 때마다 즉시 분류해야 하기 때문입니다. 추천 시스템에서는 예측 성능뿐 아니라 매번 새 추천을 계산하는 비용도 중요합니다. 고객 이탈 예측에서는 모델이 너무 복잡해서 매주 재학습하기 어렵다면 운영 부담이 커집니다.

따라서 모델을 선택할 때는 여러 기준을 함께 봐야 합니다.

• 예측 성능: 검증 데이터와 테스트 데이터에서 문제에 맞는 지표가 충분히 좋은가?

• 해석 가능성: 사람이 예측 근거를 이해하거나 설명할 수 있는가?

• 학습 속도: 모델을 학습시키는 데 걸리는 시간이 감당 가능한가?

• 예측 속도: 실제 서비스에서 빠르게 응답할 수 있는가?

• 운영 비용: 서버, 메모리, 저장 공간, 재학습 비용이 지나치게 크지 않은가?

• 유지보수성: 데이터가 바뀌었을 때 다시 학습하고 점검하기 쉬운가?

이 기준들은 서로 충돌할 때가 많습니다. 성능이 가장 좋은 모델은 복잡하고 느릴 수 있습니다. 가장 해석하기 쉬운 모델은 성능이 조금 낮을 수 있습니다. 학습이 빠른 모델은 복잡한 패턴을 충분히 잡지 못할 수 있습니다.

그래서 모델 선택은 "무조건 최고 점수"가 아니라 "목적에 맞는 균형"을 찾는 일입니다.

해석 가능한 모델과 강력한 모델 사이에서

이 책에서 배운 모델들을 떠올려 봅시다. 선형회귀와 로지스틱 회귀는 비교적 단순합니다. 각 특징이 예측에 어떤 방향으로 영향을 주는지 해석하기 쉽습니다. 결정트리도 질문의 흐름을 따라가면 어느 정도 이해할 수 있습니다.

반면 랜덤포레스트와 그래디언트 부스팅은 여러 개의 트리를 함께 사용합니다. 대체로 성능은 강력하지만, 하나의 예측이 어떤 경로로 나왔는지 완전히 직관적으로 설명하기는 더 어렵습니다.

그렇다고 단순한 모델이 항상 좋고, 복잡한 모델이 항상 나쁘다는 뜻은 아닙니다. 문제에 따라 선택이 달라집니다.

집값 예측처럼 정확도가 중요한 문제에서는 복잡한 모델이 더 나은 선택일 수 있습니다. 고객에게 추천할 상품을 고르는 문제에서도 예측 성능이 큰 영향을 줄 수 있습니다. 반대로 내부 보고서에서 "어떤 요인이 매출에 영향을 주는가"를 설명해야 한다면 단순한 모델이 더 적절할 수 있습니다.

모델을 고를 때는 먼저 질문해야 합니다.

"우리는 예측을 잘하고 싶은가, 이해를 잘하고 싶은가, 아니면 둘 다 적당히 필요한가?"

이 질문에 따라 실험의 방향이 달라집니다. 예측이 목적이라면 강력한 모델을 더 적극적으로 비교할 수 있습니다. 설명이 목적이라면 해석 가능한 모델을 기준으로 삼고, 성능이 크게 부족할 때만 더 복잡한 모델을 검토할 수 있습니다.

하이퍼파라미터 조정은 마지막 양념에 가깝다

모델 선택을 하다 보면 하이퍼파라미터 조정에 빠져들기 쉽습니다. 랜덤포레스트의 트리 개수를 100개로 할지 300개로 할지, 결정트리의 깊이를 5로 할지 10으로 할지, 그래디언트 부스팅의 학습률을 0.1로 할지 0.03으로 할지 고민하게 됩니다.

하이퍼파라미터 조정은 중요합니다. 하지만 처음부터 여기에 모든 시간을 쓰는 것은 좋지 않습니다.

좋은 재료 없이 양념만 바꾼다고 훌륭한 요리가 되지는 않습니다. 머신러닝에서도 데이터 품질, 문제 정의, 특징 설계, 평가 방식이 먼저입니다. 하이퍼파라미터는 그 위에서 모델을 더 잘 맞추는 과정입니다.

특히 초반에는 넓게 비교하는 편이 좋습니다. 단순한 기준 모델, 선형 모델, 트리 모델, 앙상블 모델을 차례로 실험해 보며 어떤 계열이 이 데이터에 잘 맞는지 확인합니다. 그다음 가능성이 높은 모델을 골라 하이퍼파라미터를 조정합니다.

하이퍼파라미터를 조정할 때도 검증 데이터를 사용해야 합니다. 테스트 데이터는 마지막까지 아껴 두어야 합니다. 테스트 데이터로 계속 설정을 고르면, 앞에서 배운 것처럼 테스트 데이터에 맞춰져 버립니다. 그러면 테스트 성능은 더 이상 진짜 새 데이터 성능을 대표하지 못합니다.

실험의 기본 흐름은 이렇게 정리할 수 있습니다.

• 기준 모델을 만들어 출발선을 정합니다.

• 여러 모델 계열을 검증 데이터로 공정하게 비교합니다.

• 가능성이 높은 모델의 하이퍼파라미터를 조정합니다.

• 최종 후보를 정한 뒤 테스트 데이터로 마지막 평가를 합니다.

• 성능, 해석 가능성, 속도, 비용을 함께 고려해 실제 사용할 모델을 고릅니다.

이 흐름을 지키면 실험이 훨씬 차분해집니다. 점수가 조금 오르내릴 때마다 흔들리는 대신, 지금 무엇을 비교하고 있는지 분명히 알 수 있습니다.

데이터 버전은 실험의 땅이다

모델은 허공에서 학습하지 않습니다. 모델은 데이터 위에서 학습합니다. 그래서 데이터가 바뀌면 실험의 의미도 바뀝니다.

어제 학습한 모델과 오늘 학습한 모델의 성능을 비교한다고 해 봅시다. 그런데 오늘 데이터에는 새로운 고객 1만 명이 추가되었고, 결측치 처리 방식도 바뀌었고, 일부 컬럼 이름도 수정되었습니다. 이때 성능이 좋아졌다면 모델이 좋아진 걸까요? 데이터가 쉬워진 걸까요? 전처리가 달라진 걸까요?

알 수 없습니다.

그래서 실험을 재현하려면 데이터 버전을 관리해야 합니다. 여기서 데이터 버전이란 "그 실험에 사용한 데이터가 정확히 어떤 상태였는지"를 가리킵니다. 파일 이름에 날짜를 붙이는 단순한 방식도 시작점이 될 수 있습니다. 더 체계적으로는 원본 데이터, 전처리 코드, 생성된 학습 데이터의 버전을 함께 관리할 수 있습니다.

중요한 습관은 원본 데이터를 함부로 덮어쓰지 않는 것입니다. 오늘 결측치를 채운 파일을 어제 원본 파일 이름으로 저장해 버리면, 나중에 어떤 데이터로 실험했는지 추적하기 어렵습니다. 원본은 원본대로 보관하고, 전처리 결과는 별도 파일이나 별도 버전으로 남기는 편이 안전합니다.

데이터 버전 관리에서 특히 확인해야 할 것은 세 가지입니다.

• 원본 데이터의 시점: 언제까지 수집된 데이터를 사용했는가?

• 전처리 규칙: 결측치, 이상치, 범주형 변수, 스케일링을 어떻게 처리했는가?

• 데이터 분할 결과: 어떤 행이 학습, 검증, 테스트에 들어갔는가?

마지막 항목은 생각보다 중요합니다. 같은 데이터라도 학습 데이터와 검증 데이터가 다르게 나뉘면 성능이 달라질 수 있습니다. 특히 데이터가 많지 않을 때는 분할 결과의 영향이 큽니다.

결국 데이터 버전은 실험의 땅입니다. 땅이 바뀌었는데 집의 높이만 비교하면 안 됩니다. 어떤 땅 위에 어떤 모델을 세웠는지 함께 기록해야 합니다.

랜덤 시드는 작은 우연을 붙잡는 장치다

머신러닝 실험에는 무작위성이 자주 들어갑니다. 학습 데이터와 검증 데이터를 무작위로 나눌 수 있습니다. 랜덤포레스트는 여러 트리를 만들 때 무작위로 샘플과 특징을 고릅니다. 일부 알고리즘은 학습을 시작할 때 초기값을 무작위로 정합니다.

이런 무작위성 때문에 같은 코드를 실행해도 결과가 조금씩 달라질 수 있습니다. 어제는 정확도 0.86이 나왔는데, 오늘은 0.84가 나오는 식입니다. 차이가 작다면 괜찮을 수 있지만, 여러 모델의 성능이 비슷할 때는 선택이 흔들릴 수 있습니다.

랜덤 시드는 이 무작위성을 통제하기 위한 숫자입니다. 컴퓨터에게 "무작위로 하되, 이번에는 이 출발점에서 시작해 줘"라고 알려 주는 역할을 합니다. 같은 랜덤 시드를 사용하면 데이터 분할이나 모델 내부의 무작위 선택이 비슷하게 재현됩니다.

랜덤 시드를 설정한다고 해서 세상의 모든 차이가 완전히 사라지는 것은 아닙니다. 사용하는 라이브러리, 실행 환경, 병렬 처리 방식에 따라 미세한 차이가 생길 수 있습니다. 그래도 랜덤 시드를 기록하는 것은 재현 가능한 실험의 기본 습관입니다.

더 좋은 습관은 중요한 비교를 한 번의 시드에만 의존하지 않는 것입니다. 성능이 비슷한 두 모델이 있다면 여러 랜덤 시드로 반복해 보고 평균 성능과 변동 폭을 함께 볼 수 있습니다. 어떤 모델은 한 번은 운 좋게 높게 나오지만, 반복하면 들쭉날쭉할 수 있습니다. 반대로 평균 성능은 조금 낮아도 안정적인 모델이 실제 운영에는 더 적합할 수 있습니다.

모델 선택에서 안정성은 생각보다 큰 장점입니다. 새 데이터가 들어올 때마다 성능이 크게 흔들리는 모델은 관리하기 어렵습니다. 예측이 조금 덜 화려해도 꾸준히 믿을 수 있는 모델이 더 좋은 선택일 때가 많습니다.

실험 이름을 붙이면 프로젝트가 보인다

실험이 많아지면 이름을 붙이는 것도 중요합니다. "최종", "진짜최종", "진짜최종2", "최종_수정_마지막" 같은 이름은 처음에는 웃기지만, 실제 프로젝트에서는 자주 벌어지는 비극입니다.

좋은 실험 이름은 나중에 봐도 무엇을 했는지 짐작할 수 있어야 합니다. 예를 들어 rf_basic_features, gb_added_price_per_area, logistic_balanced_weight처럼 모델과 핵심 변경 사항이 드러나면 좋습니다.

실험 이름은 짧아도 됩니다. 대신 실험 기록표와 연결되어야 합니다. 이름만 보고 모든 것을 알 필요는 없습니다. 이름은 문패이고, 자세한 내용은 기록표에 있으면 됩니다.

또 하나 중요한 것은 메모입니다. 숫자는 결과를 보여 주지만, 메모는 판단을 보여 줍니다.

"성능은 조금 올랐지만 학습 시간이 5배 증가함."

"새 특징을 추가했지만 검증 성능 개선 없음. 데이터 누수 가능성은 없어 보임."

"정확도는 높지만 재현율이 낮아 이탈 고객 탐지 목적에는 부적절함."

이런 메모는 나중에 프로젝트를 다시 볼 때 큰 도움이 됩니다. 머신러닝 프로젝트는 단순히 점수를 올리는 과정이 아니라, 수많은 선택의 이유를 쌓아 가는 과정입니다.

실험 관리가 좋은 모델을 만든다

처음 머신러닝을 배울 때는 모델 자체가 주인공처럼 보입니다. 선형회귀는 어떤 원리인지, 랜덤포레스트는 왜 강한지, 그래디언트 부스팅은 어떻게 실수를 고치는지 궁금합니다. 물론 모델의 원리를 이해하는 것은 중요합니다.

하지만 실전으로 갈수록 주인공은 조금 바뀝니다. 좋은 데이터, 올바른 평가 절차, 명확한 기록, 재현 가능한 실험이 더 큰 힘을 발휘합니다.

모델 선택과 실험 관리는 화려한 주제가 아닐 수 있습니다. 버튼 하나로 멋진 결과를 내는 장면도 아닙니다. 하지만 이 과정이 없으면 머신러닝 프로젝트는 금방 길을 잃습니다. 성능이 올라도 왜 올랐는지 모르고, 다시 실행하면 결과가 달라지고, 실제 서비스에 넣으면 기대와 다르게 작동합니다.

반대로 실험을 잘 관리하면 프로젝트가 단단해집니다. 어떤 모델이 왜 선택되었는지 설명할 수 있습니다. 새 데이터가 들어왔을 때 이전 결과와 비교할 수 있습니다. 문제가 생겼을 때 어느 단계에서 변화가 있었는지 추적할 수 있습니다.

이제 우리는 좋은 모델을 만들기 위한 중요한 습관들을 갖추었습니다. 데이터를 나누는 법을 배웠고, 검증 데이터와 교차검증을 배웠고, 특징을 만드는 법을 배웠고, 데이터 누수를 피하는 법을 배웠습니다. 그리고 이번 장에서는 여러 모델과 설정을 체계적으로 비교하고 기록하는 방법을 배웠습니다.

다음부터는 이 기초 체력을 가지고 실제 프로젝트를 만들어 볼 차례입니다. 집값을 예측하고, 스팸 메일을 분류하고, 고객 이탈을 예측하고, 사용자를 군집으로 나누고, 간단한 추천 시스템을 맛볼 것입니다.

이제 모델은 더 이상 막연한 마법 상자가 아닙니다. 우리는 데이터를 준비하고, 특징을 만들고, 모델을 비교하고, 오차를 확인하고, 기록을 남기며 조금씩 더 나은 예측기를 만들어 갈 수 있습니다.

머신러닝은 한 번에 정답을 맞히는 기술이 아닙니다. 더 나은 질문을 던지고, 더 공정하게 비교하고, 더 성실하게 기록하면서 모델을 개선해 가는 기술입니다.