모델을 만드는 일과 모델을 살려두는 일은 다른 직업이다. 학습이 끝난 모델을 노트북에서 꺼내 실제 트래픽 앞에 세우는 순간, 문제는 정확도에서 배포·버전·지연·비용·재현성으로 옮겨간다. MLOps 엔지니어는 그 이후를 담당한다. 클라우드 인프라 직군이 한 칸 위로 계속 이동해 온 흐름에서 가장 최근에 놓인 칸이기도 하다.
왜 이 직무가 따로 생겼나
모델은 배포하면 끝나는 소프트웨어가 아니다. 코드가 그대로여도 입력 데이터가 변하면 성능이 조용히 떨어진다. 계절이 바뀌고, 사용자 구성이 바뀌고, 상류 로그 스키마가 바뀐다. 게다가 결과가 확률적이라 “정상 동작”의 기준선 자체를 따로 관리해야 한다. 일반 백엔드 배포 도구만으로는 이 문제를 다룰 수 없어서, 별도의 직무가 생겼다.
하루의 일
- 파이프라인: 데이터 수집 → 전처리 → 학습 → 평가 → 등록까지를 사람 손 없이 반복 가능하게 만든다. 같은 입력이면 같은 모델이 나와야 하고, 실패 지점이 어디였는지 추적할 수 있어야 한다.
- 배포: 모델 레지스트리에서 특정 버전을 꺼내 서빙에 올린다. 카나리 배포, 섀도 트래픽, A/B, 그리고 즉시 이전 버전으로 돌아가는 경로까지가 한 세트다.
- 모니터링: 지연과 오류율 같은 시스템 지표에 더해 예측 분포·입력 분포·정답 지연 도착 후 실제 정확도를 본다. 데이터 드리프트 감지가 이 직무의 상징적 업무다.
- 재학습: 언제 다시 학습할지 규칙을 정하고 자동화한다. 주기 기반이든 드리프트 임계값 기반이든, 사람이 매번 판단하지 않아도 되게 만든다.
- 거버넌스: 어떤 데이터로 어떤 코드가 어떤 모델을 만들었고 지금 무엇이 서비스 중인지 답할 수 있게 남긴다. 규제 산업에서는 이 기록이 곧 감사 대응이다.
- 비용: GPU는 비싸고, 놀고 있는 GPU는 더 비싸다. 스케줄링과 오토스케일링, 그리고 팀별 비용 가시화가 실제 업무 시간의 상당 부분을 차지한다.
옆 직무와 어떻게 다른가
| 직무 | 주로 답하는 질문 |
|---|---|
| 데이터 사이언티스트 | 이 문제를 어떤 모델로 풀 것인가 |
| ML 엔지니어 | 그 모델을 제품 코드로 어떻게 구현할 것인가 |
| MLOps 엔지니어 | 그 모델을 어떻게 반복 배포하고 계속 정상 상태로 유지할 것인가 |
| 플랫폼·데브옵스 엔지니어 | 팀이 스스로 배포할 수 있는 기반을 어떻게 만들 것인가 |
| SRE | 시스템 전체의 신뢰성 목표를 어떻게 지킬 것인가 |
경계가 칼같지는 않다. 작은 조직에서는 한 사람이 네 칸을 다 맡고, 큰 조직에서는 MLOps가 플랫폼 팀 안의 한 갈래로 들어간다. 다만 채용 공고를 읽을 때 이 표의 어느 칸을 원하는지 먼저 판별하면 준비 방향이 갈린다.
2026년의 변화: LLMOps와 에이전트
지난 2년 사이 이 직무의 무게중심이 옮겨갔다. 전통적인 표 형태 데이터 모델과 LLM이 같은 레지스트리·모니터링·배포 도구 아래로 합쳐지는 흐름이 자리를 잡았고, 그 위에 LLM 고유의 과제가 얹혔다.
- 평가(eval)가 테스트를 대신한다. 출력이 비결정적이라 단위 테스트로 잡히지 않는다. 평가셋과 채점 기준을 만들어 릴리스마다 돌리는 일이 새 업무가 됐다.
- 프롬프트가 코드다. 버전 관리, 리뷰, 롤백 대상이다.
- 토큰 비용이 곧 운영 지표다. 컨텍스트 길이, 재시도, 폴백 경로, 캐시 적중률이 모두 청구서에 나타난다.
- GPU 스케줄링이 쿠버네티스 쪽 과제로 넘어왔다. 학습 작업의 공정한 갱 스케줄링, 추론 밀도를 높이는 GPU 분할, 처리량 최적화 서빙, 비용 기준 오토스케일링이 실무 주제로 자리 잡았다.
- 에이전트 운영(AgentOps)이 다음 칸으로 거론된다. 여러 단계를 스스로 도는 시스템은 추적·평가·안전장치가 한 겹 더 필요하다.
무엇을 준비해야 하나
기본기는 여전히 인프라 쪽이다. 리눅스, 파이썬, 깃, 도커, 쿠버네티스, CI/CD, 그리고 클라우드 하나. 그 위에 얹는 것이 학습·서빙 파이프라인 도구(예: MLflow 계열의 실험 추적·모델 레지스트리, 워크플로 오케스트레이터, 특성 저장소), 모니터링, 그리고 최근에는 LLM 평가·추적 도구다.
준비의 지름길은 작아도 끝까지 도는 프로젝트 하나다. 공개 데이터로 모델을 학습해 레지스트리에 올리고, 컨테이너로 서빙하고, 입력 분포를 감시해 임계값을 넘으면 재학습이 자동으로 돌게 만든다. 정확도가 낮아도 상관없다. 면접에서 확인하는 것은 모델의 성능이 아니라 끊긴 곳 없이 자동으로 도는가이기 때문이다.
대우와 수요
미국 기준 공개 집계는 출처별 편차가 크다. 2026년 9월 기준 집페크루터는 평균 약 11만 5천 달러, 글래스도어는 평균 약 16만 1천 달러에 상위 10%를 약 24만 달러로 본다. 다른 보상 가이드는 9만~25만 7천 달러 범위를 제시한다. 자가 보고 표본과 채용 공고 기반 집계는 원래 어긋난다는 점을 감안하고, 범위로만 읽는 편이 안전하다.
국내는 공개 표본이 더 적다. 참고선으로 삼을 만한 값은 잡플래닛이 집계한 2025년 국내 개발 직군 평균 연봉 4,839만 원 정도이고, MLOps는 그보다 위 밴드에서 형성되는 경우가 많다. 정확한 감을 잡으려면 원티드·링크드인의 실제 공고 범위를 몇 주 관찰하는 편이 낫다. 수요 자체는 늘고 있다 — 세계경제포럼은 2030년까지 미국의 AI·머신러닝 전문 인력 수요가 큰 폭으로 증가할 것으로 전망했다.
⚠️ 보상 수치는 2026년 9월 기준 공개 집계이며, 자가 보고와 채용 공고 기반 집계가 섞여 있어 출처별 차이가 크다. 지역·회사 규모·경력에 따라 실제 범위는 크게 달라지므로 개별 공고와 현직자 자료로 다시 확인하는 것이 좋다.
자주 묻는 질문
데이터 사이언스를 몰라도 MLOps를 할 수 있나요?
모델을 직접 설계하지 않아도 시작할 수 있습니다. 다만 모델이 어떻게 학습되고 왜 성능이 떨어지는지는 이해해야 합니다. 백엔드나 데브옵스 경험이 있다면 인프라 기본기를 그대로 가져오고, 그 위에 실험 추적·모델 레지스트리·드리프트 모니터링을 얹는 순서가 현실적입니다.
어떤 프로젝트를 포트폴리오로 만들면 좋을까요?
규모보다 완결성이 중요합니다. 학습 → 등록 → 컨테이너 서빙 → 모니터링 → 자동 재학습까지 한 바퀴가 사람 손 없이 도는 작은 프로젝트 하나면 충분합니다. 실패했을 때 이전 버전으로 되돌아가는 경로까지 있으면 더 좋습니다.
MLOps와 LLMOps는 다른 직무인가요?
현재로서는 같은 직무의 확장으로 보는 시각이 우세합니다. 파이프라인·레지스트리·모니터링이라는 뼈대는 그대로 두고, 평가셋 기반 릴리스 검증, 프롬프트 버전 관리, 토큰 비용 관리가 추가되는 형태입니다. 채용 공고에서도 두 용어가 섞여 쓰이는 경우가 많습니다.
Leave a Reply