채용 담당자의 시선

머신러닝 엔지니어 이력서 작성법 - 모델 다음에 서빙과 운영의 숫자를 적습니다

2026-10-15

여기서 말하는 머신러닝 엔지니어는 모델을 실제 서비스 안에서 돌아가게 만드는 엔지니어입니다. 서비스에 쓸 모델을 학습시켜 올리는 일, 모델을 빠르고 싸게 서빙하는 일, 학습과 배포를 자동화하고 운영하는 일이 여기에 들어갑니다. 자리에 따라 맡는 범위는 다르지만 결과물이 서비스에서 돌아가는 모델과 그 시스템이라는 점은 같습니다. 이 직무의 경력은 추천 모델 서빙 담당, 모델 성능 최적화, Kubernetes 기반 모델 배포, MLOps 파이프라인 구축 같은 문장으로 적히곤 합니다. 이런 문장은 어떤 기술을 다뤘는지 알려 줍니다. 그런데 담당자가 확인하려는 것은 그 모델이 서비스에서 어떤 구조로, 어떤 속도와 비용으로 돌아갔는지입니다. 모델을 바꾸고 지키는 과정을 어떻게 만들었는지, 지원자가 그 가운데 어디를 직접 맡았는지도 봅니다. 무신사의 Machine Learning Engineer (AI) 공고도 이력서에 프로젝트별 기여도를 표시해 달라고 안내했습니다.

모델과 시스템 구조를 함께 정했는지

머신러닝 엔지니어는 모델 하나만이 아니라 그 모델이 들어가는 시스템의 구조를 함께 정합니다. 추천이나 검색이라면 후보를 먼저 넓게 뽑고 그중에서 순서를 정하는 단계를 어떻게 나눌지, 임베딩을 미리 계산해 둘지 요청이 올 때 계산할지를 정해야 합니다. 이런 결정이 정확도와 응답 속도, 비용을 함께 좌우합니다. 에이블리의 추천 머신러닝 엔지니어 공고는 모델 성능뿐 아니라 데이터 흐름, 응답 속도, 시스템 안정성까지 고려해 추천 시스템 구조를 설계할 수 있는 사람을 자격 요건으로 찾았습니다. 후보 추출부터 최종 순서 결정까지 추천 파이프라인의 각 단계를 직접 개발해 본 경험은 우대 사항으로 꼽았습니다. 토스의 ML Engineer (Search Relevance) 공고는 가벼운 임베딩 모델로 많은 후보를 먼저 거르고 무거운 모델로 최종 순위의 정확도를 높이는 Light/Heavy 2-tier 구조에서 두 모델과 그 학습 데이터 파이프라인을 맡는 일을 업무에 적었습니다. 직무 인터뷰 주제로는 ML 시스템 설계를 밝혔습니다. 무신사 공고의 전형에도 System Design 단계가 있습니다. 이런 경험을 적을 때는 구조를 어떻게 나눴는지와 그 결정의 근거를 함께 밝힙니다. 단계마다 후보를 몇 개로 줄였는지, 응답 시간 예산을 단계별로 어떻게 나눴는지, 벡터 검색에 어떤 방식을 썼는지가 그 근거입니다. 그 결과 정확도와 응답 시간, 비용이 어떻게 달라졌는지도 씁니다.

모델 품질: 오프라인 지표와 온라인 실험

추천이나 검색 모델을 바꿨다면 그 모델이 얼마나 나아졌는지도 숫자로 적습니다. 기존 모델과 비교한 오프라인 지표(Recall@K, NDCG 같은 순위 지표)와, 실제 트래픽으로 돌린 온라인 실험에서 클릭률이나 전환율이 어떻게 달라졌는지가 함께 있어야 출시까지 이어진 개선이라는 것을 보여 줄 수 있습니다. 당근의 검색 머신러닝 엔지니어 공고와 토스 공고는 실험 설계와 A/B 테스트를 자격 요건이나 업무에 적었습니다. 토스 공고는 정확도·Recall 같은 오프라인 평가 지표를 정하는 일부터 A/B 실험까지 엔드투엔드로 오너십을 가진다고 밝혔습니다. 쿠팡의 Search & Discovery 추천 머신러닝 엔지니어 공고는 실험으로 새 모델을 검증해 출시하는 일을 업무로 꼽았습니다. 추천·검색 모델을 맡는 머신러닝 엔지니어에게 실험은 출시를 정하는 과정의 일부입니다.

서빙의 숫자: 지연 시간, 처리량, 비용

모델이 서비스에 올라가면 응답 속도, 처리량, 비용도 함께 따져야 합니다. 정확도가 조금 오른 모델이라도 응답이 두 배 느려지거나 GPU 비용이 두 배가 되면 서비스에 쓰지 못할 수 있습니다. 미리디에서 모델 추론과 서빙을 맡는 머신러닝 엔지니어 공고는 배치 크기와 GPU 메모리, 처리량, 지연 시간 사이의 트레이드오프를 설명할 수 있어야 한다고 했습니다. 업스테이지의 LLM 추론 최적화 연구 엔지니어 공고는 latency, throughput, cost 사이의 trade-off를 최적화하고 토큰당 추론 비용을 계속 줄이는 일을 업무로 두었습니다. 당근의 검색 공고도 모델의 실시간 서빙을 위한 경량화와 아키텍처 설계를 업무에 포함했습니다. 서빙한 모델이 있다면 응답 시간(평균보다는 p95, p99 같은 느린 쪽 기준), 초당 처리 요청 수, 요청 한 건이나 토큰당 비용, GPU 사용률을 적습니다. LLM을 서빙했다면 첫 토큰이 나오기까지 걸리는 시간과 초당 생성 토큰 수가 더해집니다. 최적화를 했다면 무엇을 바꿨는지와 함께 전후 숫자를 나란히 씁니다. 미리디 공고는 PyTorch 모델을 가속 프레임워크로 변환하고 변환 전후의 정확도와 추론 속도를 측정하는 일을 업무로 적었습니다. 양자화나 경량화로 정확도를 얼마나 내주고 지연 시간이나 비용을 얼마나 줄였는지를 함께 적어야 왜 그렇게 정했는지 설명이 됩니다. 프로파일링으로 어떤 연산이 병목이었는지 찾았다면 그 과정도 적을 수 있습니다.

모델을 바꾸고 지키는 일

머신러닝 엔지니어의 일은 모델을 한 번 올리는 데서 끝나지 않습니다. 새 모델로 교체하고, 문제가 생기면 되돌리고, 성능이 떨어지기 전에 알아채는 일이 계속 이어집니다. 미리디의 서빙 공고는 모델 교체, 버전 롤아웃, 용량 산정, 트래픽 급증 대응을 업무로 두었습니다. p99 지연 시간과 GPU 활용률, 토큰 처리량, 큐 대기 시간을 수집해 대시보드와 알림을 만드는 일도 같은 공고의 업무입니다. 카카오뱅크의 LLM 서빙·추론 최적화 엔지니어 공고는 모델이나 추론 엔진을 바꾸기 전후를 비교하는 회귀 테스트로 문제를 일찍 찾는 일을 업무로 적었습니다. Kubernetes 환경에서 트래픽에 맞춰 GPU 자원을 나누는 일도 맡습니다. 삼일PwC의 LLMOps Engineer 공고는 CI/CD와 MLOps 체계 구축, 모델의 성능과 품질, 인프라 모니터링을 업무에 포함했습니다. 이런 경험은 모델을 어떤 방식으로 배포했는지(트래픽 일부에 먼저 적용하는지 한 번에 바꾸는지), 어떤 지표가 기준을 넘으면 롤백하도록 했는지, 재학습과 배포를 얼마나 자동화했는지로 적습니다. 모니터링은 서버 지표만이 아니라 입력 피처의 결측이나 예측 값의 분포처럼 모델 쪽 지표를 무엇으로 봤는지까지 적어야 이 직무의 운영 경험이라는 점이 분명해집니다. 맡은 기간 동안 모델을 몇 번 교체했고 그 사이 장애가 몇 번 있었는지 같은 숫자가 있으면 운영의 규모를 가늠할 수 있습니다.

학습 파이프라인과 피처 파이프라인

모델이 서비스에서 계속 좋은 결과를 내려면 학습 데이터와 피처가 정해진 시간에 같은 방식으로 만들어져야 합니다. 이 파이프라인을 만들고 운영하는 것도 머신러닝 엔지니어의 일입니다. 당근의 검색 공고는 Python 기반의 머신러닝 훈련 파이프라인을 구축한 경험을 자격 요건으로 요구했습니다. 에이블리의 추천 공고는 학습·평가 파이프라인과 서빙 구조, 그 안정성까지 설계하고 개선하는 일을 업무로 두었습니다. 대규모 데이터 처리와 ETL 경험, 그리고 모델 서빙·분산 학습·GPU 환경 같은 프로덕션 ML 시스템 경험은 우대 사항에 있습니다. 쿠팡의 추천 공고는 피처 생성용 데이터 작업을 만들고 모델을 학습시켜 실험으로 검증한 뒤 출시하는 과정을 업무로 꼽았습니다. 파이프라인을 만들었다면 처리한 데이터의 규모, 학습이나 피처 생성에 걸리는 시간이 어떻게 바뀌었는지, 피처가 얼마나 최신으로 유지되는지가 이력서에 들어갈 숫자입니다. 학습할 때와 서빙할 때 피처를 같은 정의로 만들도록 맞춘 경험이 있다면 그것도 적을 만합니다. 두 쪽의 피처가 어긋나면 오프라인에서 좋았던 모델이 서비스에서 다르게 동작하기 때문입니다.

어느 단계의 일을 했는지

같은 머신러닝 엔지니어 직무로 묶여도 하는 일은 크게 다릅니다. 기업 채용 분석의 머신러닝 엔지니어 공고를 보면(2026년 10월 분석 기준) 추천·검색 모델을 만들어 서비스에 올리는 자리, 학습된 모델을 빠르고 싸게 서빙하는 자리, 학습과 추론을 돌리는 GPU 플랫폼을 운영하는 자리가 함께 있습니다. 요구하는 경험도 단계마다 다릅니다. 카카오뱅크의 서빙 공고는 vLLM, SGLang, TensorRT-LLM, TGI 가운데 하나 이상을 실무에서 쓰고 내부 코드를 고쳐 가며 튜닝해 본 경험을 요구했습니다. 크래프톤의 ML Infrastructure Engineer 공고는 GPU 플랫폼의 스케줄링과 워크로드 격리, 관측성, 장애 대응 체계를 직접 개선해 본 경험을 요구했습니다. 이력서에는 경험을 단계별로 나눠 적습니다. 모델을 학습시켜 출시한 것, 서빙과 최적화를 맡은 것, 학습과 배포를 자동화한 것, 플랫폼과 인프라를 운영한 것을 구분합니다. 그리고 지원하는 공고가 어느 단계의 사람을 찾는지 보고 그 단계의 경험을 더 자세히 씁니다. 한 프로젝트 안에서도 모델 학습은 다른 팀이 하고 서빙만 맡았다면 그렇게 밝혀 둡니다. 논문을 우대 사항에 적은 공고도 있었습니다. 카카오뱅크의 서빙 공고, 무신사의 Machine Learning Engineer (AI) 공고, 업스테이지의 LLM 추론 최적화 공고가 그렇습니다. 세 공고 모두 오픈소스 기여도 함께 우대했습니다. 카카오뱅크와 무신사 공고는 논문과 오픈소스 기여 가운데 하나를 우대 항목으로 적었고, 업스테이지 공고에서는 두 가지가 각각 우대 항목입니다. 관련 오픈소스에 기여한 기록이 있다면 논문이 없어도 이런 공고에서 우대받을 수 있습니다.

자리에 따라 맡는 범위가 넓어지기도 합니다

머신러닝 엔지니어라는 이름의 공고가 앞에서 본 단계들보다 넓은 범위를 맡기기도 합니다. 에이블리의 추천 공고는 사용자 행동과 상품 데이터를 직접 분석해 추천으로 풀 고객 문제를 정하는 일까지 업무로 적었습니다. 비상교육의 AI ML 엔지니어 공고는 모델 개발·배포와 함께 AI 엔지니어 공고에 자주 나오는 LLM API와 RAG, AI 에이전트로 AI 모듈을 만드는 일도 업무에 두었습니다. 연구 쪽으로 넓어지는 자리도 있습니다. 업스테이지의 Post-training 연구 엔지니어 공고는 모델의 사후 학습을 연구하는 자리입니다. 이 공고는 국제 학회에 1저자나 교신저자로 논문을 낸 기록을 자격 요건으로 요구했습니다. 이런 공고에 지원한다면 머신러닝 엔지니어링 경험에 더해 그 공고가 요구하는 일을 해 본 경험도 따로 적습니다. 데이터 분석으로 풀 문제를 정한 경험, LLM API나 RAG로 기능을 만든 경험처럼 나눠 적어야 지원자가 어느 범위까지 맡을 수 있는지 분명해집니다. 연구 쪽 자리는 논문 기록을 필수로 두기도 하므로 엔지니어링 경험만으로 요건을 채울 수 있는지 먼저 확인합니다.

같은 경력을 이렇게 적으면

약한 문장: 모델 서빙 및 성능 최적화
강한 문장: 검색어 임베딩 모델을 TensorRT로 변환하고 FP16을 적용했습니다. 검색 Recall@10은 0.2%p 낮아졌지만 p99 응답 시간이 45ms에서 15ms로 줄었고, 같은 트래픽을 처리하는 GPU 서버는 4대에서 2대가 됐습니다.
약한 문장: 추천 모델 배포 및 운영
강한 문장: 추천 모델 교체 방식을 전체 일괄 교체에서 트래픽 5%부터 단계적으로 늘리는 방식으로 바꿨습니다. 새 버전의 p99 응답 시간, 오류율, 예측 점수 분포 가운데 하나라도 기준을 넘으면 이전 버전으로 자동으로 돌아가게 했습니다. 한 분기 동안 모델을 6번 교체하는 사이 서비스 장애는 없었습니다.
약한 문장: 실시간 피처 파이프라인 구축
강한 문장: 하루 한 번 배치로 만들던 사용자 행동 피처를 Kafka와 Flink 기반 스트리밍으로 바꿔 피처가 반영되는 시간을 하루에서 5분 이내로 줄였습니다. 학습과 서빙이 같은 피처 정의를 쓰도록 피처 스토어로 옮겨 오프라인과 온라인 예측 값이 어긋나는 요청 비율을 2%에서 0.1% 아래로 낮췄습니다. 온라인 실험에서는 추천 클릭률이 상대 3% 올랐습니다.
약한 문장: MLOps 파이프라인 구축
강한 문장: 수요 예측 모델의 학습부터 배포까지를 Airflow와 MLflow로 자동화해 재학습 주기를 월 1회에서 주 1회로 줄였습니다. 새로 학습한 모델의 검증 오차가 기준을 넘으면 배포를 멈추고 이전 모델을 유지하게 했고, 학습 데이터 일부가 빠진 채 학습된 모델 두 개가 이 단계에서 걸러졌습니다.

강한 문장에는 무엇을 바꿨는지, 그 결과 서비스의 속도나 비용, 안정성이 어떻게 달라졌는지, 그리고 지원자가 정한 기준이 들어 있습니다. 같은 기술을 썼더라도 강한 문장에서는 지원자가 모델을 서비스 안에서 책임지고 운영해 왔다는 점이 드러납니다.

서비스에 올려 본 적이 없다면

대학원이나 개인 프로젝트에서 모델을 학습시켜 왔지만 실제 서비스에 올려 본 적은 없을 수 있습니다. 이런 경력은 서빙과 운영의 숫자가 없어 약해 보인다고 느끼기 쉽습니다. 신입을 뽑는 안랩의 ML/MLOps 엔지니어 공고가 무엇을 보는지 참고할 수 있습니다. 이 공고는 Python과 Scala, PyTorch 같은 프레임워크, Spark 같은 대규모 데이터 처리, git 같은 형상관리 도구 경험과 AI/ML 모델 설계·개발 경험을 자격 요건으로 적었습니다. MLOps 경험은 우대 사항에 있습니다. 이 공고는 모델을 만들어 본 경험에 더해 그 모델을 다루는 엔지니어링 경험을 함께 봅니다. 이런 공고라면 서비스 경험이 없어도 개인 프로젝트나 연구에서 아래 같은 숫자를 만들어 적을 수 있습니다.

학습한 모델을 컨테이너로 묶어 API로 띄우고 p95 응답 시간과 초당 처리 요청 수를 잰 결과
배치 크기나 동시 요청 수를 바꿔 가며 처리량과 지연 시간이 어떻게 달라지는지 비교한 결과
양자화나 경량화 전후의 정확도, 응답 시간, 메모리 사용량
공개 데이터로 후보를 뽑는 단계와 순위를 정하는 단계를 나눠 만들고 단계별 Recall과 응답 시간을 잰 결과
여러 GPU로 분산 학습해 학습 시간을 얼마나 줄였는지
새 데이터가 들어오면 재학습과 평가, 배포가 이어서 돌도록 만든 작은 파이프라인
vLLM 같은 추론 엔진이나 학습 프레임워크에 낸 오픈소스 기여

숫자를 적을 때는 어떤 장비(GPU 종류)에서 동시 요청 몇 개로 쟀는지를 함께 밝혀 둡니다. 조건이 없는 숫자는 비교할 수 없기 때문입니다. 이런 숫자는 실제 트래픽을 받은 경험을 대신하지는 못해도 모델을 서비스에 올릴 때 무엇을 재야 하는지 알고 있다는 것은 보여 줄 수 있습니다.

운영 숫자는 회사 대시보드 안에 남아 있습니다

모델을 운영하는 동안에는 위에 적은 숫자를 찾기 어렵지 않습니다. 응답 시간과 GPU 사용률은 모니터링 화면에, 배포와 롤백 기록은 배포 시스템에, 학습 기록은 실험 관리 도구에 남아 있습니다. 그런데 이 기록은 대개 회사 계정 안에 있어서 회사를 옮기면 다시 열어 보기 어렵습니다. 이력서를 쓸 때쯤이면 기억에는 사용한 기술 이름과 대략의 개선 폭만 남고, 이력서에도 그것만 적힙니다. 그래서 최적화나 배포 작업 하나가 끝나는 날 결과를 개인 기록으로 남겨 두는 것이 좋습니다. 무엇을 바꿨는지, 지연 시간과 비용이 전후로 어떻게 달라졌는지, 어떤 기준으로 배포하고 되돌렸는지 정도를 몇 줄로 적으면 됩니다. 회사의 코드나 데이터는 빼고 결과 숫자와 판단만 남깁니다. 회사 밖에 적어도 되는 숫자인지는 보안 규정에서 먼저 확인합니다. GridResume 커리어 기록에 이렇게 남겨 두면 이력서를 쓸 때 서빙과 운영의 숫자가 들어간 문장을 바로 만들 수 있습니다.

정리하면

머신러닝 엔지니어 이력서에 들어가야 할 것은 다섯 가지입니다.

모델과 시스템 구조를 어떻게 정했고 모델 지표가 어떻게 달라졌는지
서비스에서 모델이 어떤 지연 시간과 처리량, 비용으로 돌아갔는지
모델을 어떻게 배포하고 모니터링하고 되돌렸는지
학습과 피처 파이프라인을 어떻게 만들었는지
학습·서빙·자동화·인프라 가운데 어느 단계의 일을 했는지

기술 이름만으로는 이력서가 기술 목록에 그칩니다. 여기에 서비스에서 잰 숫자와 지원자가 정한 기준을 더해 적어야 머신러닝 엔지니어의 경력으로 보입니다.

← 블로그 목록