AI엔지니어 취업 모델 학습만으론 부족(데이터, 배포, 평가)

AI 엔지니어 취업을 준비하는 학생의 포트폴리오를 검토할 때 처음에는 상당히 잘 준비된 것처럼 보이는 경우가 있습니다. 이미지 분류 모델을 만들었고, 자연어 처리 프로젝트도 진행했으며, 학습 정확도와 검증 정확도 그래프도 깔끔하게 정리되어 있습니다. 사용한 모델과 하이퍼파라미터, epoch에 따른 loss 변화까지 설명되어 있으면 머신러닝 공부를 꾸준히 했다는 점도 보입니다. 그런데 프로젝트를 조금 더 깊게 확인하면 예상하지 못한 빈틈이 나타납니다. 학습 데이터는 어디에서 왔는지, 누락값과 중복값은 어떻게 처리했는지, 학습용과 검증용 데이터를 어떤 기준으로 나눴는지 물으면 답변이 짧아지는 식입니다.

모의면접에서도 비슷한 장면이 나옵니다. 모델 정확도가 90% 이상 나왔다고 설명한 뒤 새로운 데이터가 들어오면 같은 전처리를 어떻게 적용할 것인지, 모델을 다른 사람이 사용할 수 있도록 API로 제공해 본 적이 있는지, 실제 서비스에서는 정확도 외에 어떤 기준으로 모델을 평가해야 하는지 질문하면 프로젝트 설명이 갑자기 학습 코드 수준으로 돌아갑니다. 모델 파일은 만들어졌지만 배포해 본 적이 없고, 테스트 데이터에서는 성능이 좋았지만 어떤 유형에서 예측이 자주 틀리는지는 확인하지 않은 경우도 있습니다.

반대로 모델 자체가 아주 복잡하지 않아도 데이터 수집과 정제 기준을 설명하고, 학습한 모델을 API 형태로 연결해 보고, 실제 추론 결과에서 오류 유형을 다시 분석한 프로젝트는 훨씬 다르게 보입니다. AI 엔지니어링은 모델을 학습시키는 순간 끝나는 일이 아니라 데이터를 준비하고, 모델을 실행 가능한 형태로 배포하고, 실제 사용 조건에서 결과를 다시 평가하는 과정까지 연결되어야 하기 때문입니다. 이번 글에서는 AI 엔지니어 취업 준비생이 모델 학습만 하면 부족한 이유를 데이터, 배포, 평가 세 가지 기준으로 정리해 보겠습니다.

데이터는 모델 성능보다 먼저 확인해야 하는 출발점입니다

좋은 모델도 데이터 기준이 흔들리면 결과를 믿기 어렵습니다

AI 프로젝트를 처음 시작하면 어떤 모델을 사용할지 고민하기 쉽습니다. CNN을 사용할지, Transformer 기반 모델을 적용할지, 어떤 라이브러리를 활용할지에 관심이 집중됩니다. 하지만 모델이 학습하는 대상은 결국 데이터이기 때문에 데이터 기준이 잘못되어 있으면 복잡한 모델을 사용해도 결과를 신뢰하기 어렵습니다.

프로젝트를 다시 점검할 때는 아래 부분부터 확인하는 것이 좋습니다.

데이터가 어디에서 수집되었는지 설명합니다.
한 행이나 한 이미지가 무엇을 의미하는지 정의합니다.
누락된 값과 중복 데이터가 얼마나 있는지 확인합니다.
학습에 사용하면 안 되는 정보가 포함되어 있지 않은지 점검합니다.
학습 데이터와 검증 데이터가 어떤 기준으로 나뉘었는지 확인합니다.
실제 사용할 데이터와 학습 데이터의 형태가 비슷한지 비교합니다.

예를 들어 고객 이탈을 예측하는 프로젝트라면 단순히 고객 데이터를 모델에 넣는 것이 아니라 예측 시점 이후에만 알 수 있는 정보가 학습 데이터에 포함되어 있지는 않은지 확인해야 합니다. 이미지 분류라면 동일하거나 매우 유사한 이미지가 학습 데이터와 검증 데이터 양쪽에 들어가 성능이 실제보다 높게 보이지 않는지도 살펴봐야 합니다.

AI 엔지니어 취업 준비에서는 좋은 성능 수치를 만드는 것만큼 그 수치를 믿을 수 있는 데이터 구조인지 설명하는 능력이 중요합니다.

전처리는 학습 코드보다 기준의 일관성을 설명할 수 있어야 합니다

전처리는 AI 프로젝트에서 거의 빠지지 않지만 단순히 결측치를 제거했습니다, 정규화했습니다 정도로 끝나는 경우가 많습니다. 실제로는 어떤 기준으로 처리했고 그 기준이 새로운 데이터에도 동일하게 적용되는지를 설명할 수 있어야 합니다.

결측값 처리 기준: 값이 없다는 이유로 모두 제거한 것이 아니라 해당 값이 분석과 예측에 어떤 의미가 있는지 먼저 확인해야 합니다. 특정 변수의 결측 자체가 중요한 정보일 수도 있기 때문입니다.
범주형 데이터 처리 기준: 학습 데이터에 있던 범주와 실제 서비스에서 새롭게 등장하는 범주가 다를 수 있다는 점을 생각해야 합니다. 새로운 값이 들어왔을 때 어떻게 처리할지도 정리할 필요가 있습니다.
수치 데이터 처리 기준: 학습 단계에서 사용한 스케일링 기준을 실제 추론에서도 동일하게 적용해야 합니다. 새로운 데이터마다 다시 기준을 계산한다면 모델 입력 조건이 달라질 수 있습니다.
이미지나 텍스트 처리 기준: 이미지 크기, 토큰화 방식, 최대 길이 같은 전처리 조건 역시 학습과 추론 단계에서 일관되어야 합니다.

이런 내용을 포트폴리오에 남기면 데이터 전처리가 단순한 코드 한 줄이 아니라 모델이 안정적으로 동작하기 위한 설계 과정으로 보이게 됩니다.

데이터 불균형은 정확도 하나만 보면 놓치기 쉽습니다

AI 프로젝트에서 전체 정확도가 높다고 해서 모든 경우를 잘 예측한다는 뜻은 아닙니다. 특히 한 클래스가 다른 클래스보다 훨씬 많은 데이터에서는 대부분을 많은 쪽으로 예측해도 높은 정확도가 나올 수 있습니다. 이 문제를 직접 확인해 보는 경험은 취업 준비에서도 좋은 소재가 됩니다.

불균형 데이터를 점검할 때는 아래 내용을 살펴볼 수 있습니다.

각 클래스의 데이터 개수를 비교합니다.
전체 정확도만 보지 않고 클래스별 결과를 확인합니다.
어떤 유형에서 오분류가 많이 발생하는지 기록합니다.
데이터가 적은 그룹의 예측 결과를 따로 확인합니다.
데이터 구성이나 평가 방식 변경 전후를 비교합니다.
성능 향상보다 실제 오류 감소 여부를 함께 봅니다.

예를 들어 이상 거래 탐지처럼 정상 데이터가 압도적으로 많은 상황에서는 모든 거래를 정상으로 판단해도 겉으로 높은 정확도가 나올 수 있습니다. 이런 프로젝트에서는 어떤 이상 거래를 놓쳤는지, 정상 거래를 얼마나 잘못 경고했는지를 함께 확인해야 합니다.

이 경험이 있으면 면접에서도 모델 정확도가 높았습니다라는 답변을 넘어 어떤 데이터 구조 때문에 특정 지표를 함께 봤는지 설명할 수 있습니다.

데이터 버전이 달라지면 모델 결과도 달라질 수 있습니다

모델을 여러 번 학습하다 보면 데이터도 계속 바뀝니다. 잘못된 라벨을 수정하거나, 새로운 데이터를 추가하거나, 특정 조건의 데이터를 제외할 수 있습니다. 그런데 어떤 데이터로 어떤 모델을 학습했는지 기록하지 않으면 나중에 성능 차이의 원인을 찾기 어려워집니다.

기록이 없는 경우: model_final, model_final2, final_best 같은 파일만 남아 있고 각각 어떤 데이터와 설정으로 학습했는지 알기 어렵습니다.
데이터가 연결된 경우: 데이터셋 버전, 전처리 기준, 주요 학습 설정, 모델 결과를 함께 기록해 어떤 변경이 성능에 영향을 주었는지 비교할 수 있습니다.
재현 가능한 경우: 동일한 데이터와 전처리 조건, 모델 설정을 다시 적용했을 때 비슷한 실험 흐름을 재현할 수 있도록 기록을 남깁니다.

포트폴리오에 모든 실험 기록을 보여줄 필요는 없습니다. 다만 대표 모델 하나에 대해서라도 어떤 데이터와 전처리를 사용했고 이전 버전과 무엇이 달라졌는지는 설명할 수 있어야 합니다.

AI 엔지니어에게 데이터는 모델을 학습시키기 전 잠깐 거치는 재료가 아닙니다. 모델의 결과를 해석하고 다시 개선할 때까지 계속 관리해야 하는 핵심 요소입니다.

배포는 학습된 모델을 실제로 사용할 수 있는 형태로 바꾸는 과정입니다

모델 파일을 저장하는 것과 서비스를 만드는 것은 다릅니다

AI 프로젝트가 학습 코드 실행에서 끝나는 경우가 많습니다. Notebook에서 모델을 학습하고 예측 결과를 출력한 뒤 정확도 그래프를 보여주는 방식입니다. 학습 프로젝트로서는 충분할 수 있지만 AI 엔지니어 취업을 생각한다면 한 단계 더 나아가볼 필요가 있습니다. 다른 프로그램이나 사용자가 모델을 어떻게 호출할 수 있는지를 고민해야 합니다.

배포 경험을 만들 때는 아래 흐름부터 시작해 볼 수 있습니다.

학습된 모델을 저장하고 다시 불러와봅니다.
새로운 입력 데이터를 받을 구조를 정합니다.
학습 때 사용한 전처리를 추론 단계에도 적용합니다.
입력값을 모델에 전달하고 결과를 반환하도록 구성합니다.
정상 입력과 잘못된 입력을 각각 테스트합니다.
여러 번 요청해도 동일한 방식으로 동작하는지 확인합니다.

예를 들어 텍스트 분류 모델을 만들었다면 Notebook에서 문장 하나를 직접 입력해 결과를 보는 데서 끝내지 않고, 문장을 요청으로 받아 분류 결과를 반환하는 간단한 API 형태로 만들어볼 수 있습니다.

이 과정만 경험해도 모델 학습과 실제 서비스의 차이를 이해하는 데 큰 도움이 됩니다.

API를 만들면 모델 외에 확인해야 할 부분이 보이기 시작합니다

모델을 API 형태로 연결하면 학습할 때는 보이지 않던 문제가 나타납니다. 입력값이 비어 있을 수도 있고, 예상하지 못한 데이터 형태가 들어올 수도 있으며, 모델 파일을 불러오는 데 시간이 오래 걸릴 수도 있습니다.

모델만 확인한 상태: 테스트 데이터셋을 넣으면 예측 결과가 정상적으로 출력됩니다.
API까지 연결한 상태: 사용자가 보내는 요청값을 어떤 형식으로 받을지 정하고, 필요한 전처리를 적용한 뒤 모델 결과를 응답 형태로 다시 반환해야 합니다.
오류까지 고려한 상태: 입력값이 없거나 형식이 맞지 않는 경우 모델을 실행하기 전에 검증하고, 사용자가 이해할 수 있는 실패 응답을 반환하도록 구성할 수 있습니다.

이렇게 모델을 서비스 흐름에 넣어보면 AI 엔지니어 업무가 모델 파일 하나로 끝나지 않는다는 점을 이해하게 됩니다. 프런트엔드나 다른 백엔드 서비스가 어떤 방식으로 모델을 호출할지까지 생각하게 되기 때문입니다.

포트폴리오에서도 정확도 그래프만 보여주는 것보다 요청 → 전처리 → 모델 추론 → 결과 반환이라는 흐름을 함께 보여주면 프로젝트의 완성도가 달라집니다.

로컬에서 잘 되는 모델이 다른 환경에서도 잘 된다는 보장은 없습니다

개발자 PC에서는 잘 동작하던 모델이 서버에서는 실행되지 않는 경우가 있습니다. Python 버전, 패키지 버전, 모델 파일 경로, 환경변수, 메모리와 같은 실행 조건이 다르기 때문입니다. 그래서 배포 경험에서는 모델 자체뿐 아니라 실행 환경도 함께 관리해야 합니다.

환경 차이를 점검할 때는 아래 항목을 확인해 보는 것이 좋습니다.

사용하는 Python과 주요 라이브러리 버전을 기록합니다.
모델이 사용하는 패키지 의존성을 정리합니다.
모델 파일과 설정 파일의 경로를 확인합니다.
실행에 필요한 환경변수를 코드와 분리합니다.
서버의 메모리와 저장 공간을 점검합니다.
배포 후 실제 API 요청으로 다시 테스트합니다.

이런 과정에서 컨테이너 같은 기술을 추가로 학습할 수도 있습니다. 하지만 처음부터 복잡한 배포 시스템을 구축할 필요는 없습니다. 중요한 것은 내 컴퓨터에서는 됩니다라는 상태에서 벗어나 다른 환경에서도 실행 조건을 정리해 보는 것입니다.

이 경험은 AI 엔지니어 취업에서 모델 개발과 소프트웨어 개발의 연결을 보여주는 좋은 근거가 될 수 있습니다.

배포 이후에는 추론 속도와 장애 상황도 확인해야 합니다

모델을 서버에 올리고 API가 한 번 정상 응답했다고 해서 배포가 완성되는 것은 아닙니다. 실제 사용에서는 반복 요청이 들어오고, 입력 크기가 달라지며, 모델이 응답하는 데 걸리는 시간도 중요해질 수 있습니다.

정상 동작 확인: 대표 입력 데이터를 보내 모델이 예상한 형태의 응답을 반환하는지 봅니다.
응답 시간 확인: 모델이 결과를 만드는 데 얼마나 걸리는지 측정하고, 입력 크기에 따라 차이가 생기는지 확인합니다.
실패 상황 확인: 잘못된 입력값이나 모델 로딩 실패처럼 예상 가능한 문제에서 API가 어떻게 반응하는지 살펴봅니다.
운영 관점 확인: 오류가 발생했을 때 어떤 로그가 남고 어느 단계에서 실패했는지 추적할 수 있는지 확인합니다.

이 정도만 정리해도 포트폴리오 설명은 크게 달라집니다. 모델을 학습했습니다가 아니라 학습한 모델을 API 형태로 배포하고 반복 요청과 오류 상황까지 확인했습니다라고 말할 수 있기 때문입니다.

AI 엔지니어 취업 준비에서는 거대한 AI 서비스를 만드는 것이 목표가 아닙니다. 작은 모델이라도 학습부터 실제 호출까지 하나의 흐름으로 연결해 보는 경험이 중요합니다.

평가는 높은 점수보다 모델이 어디에서 실패하는지 이해하는 과정입니다

정확도 하나만 보고 모델을 선택하지 않아야 합니다

모델 평가에서 가장 먼저 보는 값이 정확도인 경우가 많습니다. 하지만 프로젝트 목적과 데이터 구조에 따라 더 중요한 지표가 달라질 수 있습니다. 따라서 모델 성능을 설명할 때는 왜 해당 평가 지표를 사용했는지 함께 말할 수 있어야 합니다.

평가 기준을 점검할 때는 아래 항목을 살펴보는 것이 좋습니다.

모델이 해결하려는 문제를 먼저 정의합니다.
클래스별 데이터 분포를 확인합니다.
어떤 종류의 오류가 더 중요한지 생각합니다.
정확도 외에 필요한 지표가 있는지 확인합니다.
여러 모델을 동일한 평가 데이터로 비교합니다.
지표 차이가 실제 오류 사례에서도 보이는지 확인합니다.

예를 들어 특정 위험 상황을 찾아내는 모델이라면 실제 위험 데이터를 놓치는 오류와 정상 데이터를 위험하다고 판단하는 오류의 의미가 다를 수 있습니다. 어느 오류가 더 중요한지는 프로젝트 목적에 따라 달라집니다.

그래서 좋은 포트폴리오는 평가 점수 하나를 크게 보여주는 것이 아니라 그 지표를 선택한 이유와 모델의 한계를 함께 설명합니다.

검증 데이터 성능과 실제 사용 성능은 다를 수 있습니다

모델을 학습할 때는 학습 데이터와 검증 또는 테스트 데이터를 나누어 성능을 확인합니다. 하지만 프로젝트에서 준비한 테스트 데이터와 실제 서비스에서 들어오는 데이터가 항상 같은 분포를 가진다는 보장은 없습니다.

테스트 데이터에서 좋은 경우: 학습 과정에서 준비한 데이터와 비슷한 형태의 입력에서는 안정적인 결과를 보일 수 있습니다.
새로운 데이터가 들어온 경우: 촬영 환경, 문장 표현, 사용자 행동처럼 학습 데이터에서 충분히 보지 못했던 조건에서는 결과가 달라질 수 있습니다.
실제 운영을 고려한 경우: 배포 후 잘못 예측한 데이터를 따로 수집하고 어떤 조건에서 오류가 반복되는지를 분석하는 과정이 필요해집니다.

이런 관점을 가지고 있으면 모델 성능을 지나치게 확신하는 것을 피할 수 있습니다. 포트폴리오에서도 테스트 정확도가 높았다고만 적기보다 어떤 데이터에서는 성능이 떨어졌고 무엇을 추가로 확인해야 하는지를 함께 적는 것이 좋습니다.

AI 엔지니어에게 평가는 모델 순위를 정하는 작업이 아니라 모델의 사용 가능 범위를 이해하는 과정에 가깝습니다.

오답을 직접 분류하면 다음 개선 방향이 보입니다

모델 평가에서 숫자만 보면 왜 틀렸는지 알기 어렵습니다. 그래서 오분류 데이터를 직접 확인하고 유형별로 나누는 과정이 중요합니다. 작은 프로젝트에서도 충분히 해볼 수 있는 작업입니다.

오류 분석에서는 아래 내용을 확인해 보는 것이 좋습니다.

자주 틀리는 데이터를 따로 모아봅니다.
특정 클래스나 조건에서 오류가 집중되는지 봅니다.
라벨 자체가 잘못된 데이터가 있는지 확인합니다.
입력 데이터 품질 때문에 틀린 경우를 구분합니다.
모델이 구분하기 어려운 유사 사례를 찾아봅니다.
추가 데이터가 필요한 유형을 정리합니다.

예를 들어 이미지 분류에서 어두운 사진에서만 오류가 많이 발생한다면 모델 구조를 무조건 바꾸기보다 학습 데이터에 다양한 밝기의 이미지가 충분한지 먼저 확인할 수 있습니다.

텍스트 분류에서 특정 표현이 포함된 문장만 자주 틀린다면 토큰화나 학습 데이터 분포를 다시 볼 수도 있습니다.

이렇게 오답을 직접 살펴보면 데이터, 모델, 평가가 다시 연결됩니다. 모델 평가가 다음 학습 실험의 출발점이 되는 것입니다.

모델 개선은 점수 상승보다 변경 이유가 기록되어야 합니다

AI 프로젝트를 진행하면 여러 모델과 설정을 시험하게 됩니다. 문제는 최종적으로 가장 높은 점수만 남기고 중간 과정은 모두 지워버리는 경우입니다. 하지만 취업 포트폴리오에서는 최고 점수보다 어떤 문제를 발견했고 왜 변경했는지를 보여주는 것이 더 좋은 경험이 될 수 있습니다.

점수만 남긴 프로젝트: 여러 모델을 테스트했고 가장 정확도가 높은 모델을 최종 선택했습니다.
분석이 남은 프로젝트: 특정 클래스의 오분류가 많다는 점을 확인하고 데이터 분포와 오류 사례를 분석했습니다. 이후 데이터 구성과 학습 조건을 변경해 같은 평가 기준으로 다시 비교했습니다.
한계까지 남긴 프로젝트: 전체 지표는 개선되었지만 특정 유형의 오류는 여전히 남아 있었고, 추가 데이터 확보와 별도 평가가 필요하다는 점을 프로젝트 한계로 정리했습니다.

이런 설명은 AI 프로젝트를 단순 실험이 아니라 엔지니어링 과정으로 보여줍니다. 좋은 AI 엔지니어 포트폴리오는 최고 성능만 보여주는 자료가 아니라 데이터 변경, 모델 변경, 배포 결과, 평가 결과가 왜 달라졌는지 추적할 수 있는 자료에 가깝습니다.

conclusion

AI 엔지니어 취업 준비에서 모델 학습은 반드시 필요한 과정입니다. 머신러닝과 딥러닝의 원리를 이해하고 직접 모델을 학습해보지 않으면 데이터와 결과 사이의 관계를 이해하기 어렵습니다. 문제는 모델 학습 자체를 프로젝트의 마지막 단계라고 생각하는 것입니다. 실제 AI 엔지니어링에서는 학습 이전의 데이터 준비와 학습 이후의 배포와 평가가 모두 연결되어야 합니다.

프로젝트 하나를 다시 살펴보면 현재 부족한 부분을 쉽게 찾을 수 있습니다. 정확도 그래프만 있다면 데이터를 어떤 기준으로 나누었는지 추가하고, Notebook 안에서만 동작한다면 간단한 API로 연결해 볼 수 있습니다. 모델 평가도 전체 정확도에서 끝내지 말고 잘못 예측한 데이터를 직접 확인해 어떤 조건에서 실패하는지 기록해 보는 것이 좋습니다. 이렇게 하면 같은 모델 프로젝트라도 설명의 깊이가 완전히 달라집니다.

최종 점검은 아래 기준으로 해보면 좋습니다.