Machine Learning Platform Engineering Study - 1주차 및 AI 용어 추가공부

CH1. MLOps와 ML 엔지니어링의 시작

 

1.1 머신러닝 수명주기

 

모델을 만들기 전에 예측 결과의 용도부터 정해야 한다. 고객 이탈을 예측한다면 이탈의 기준, 예측할 시점, 결과를 받은 담당자의 후속 행동이 필요하다. 이 기준이 정해져야 수집할 데이터와 평가 방법도 정할 수 있다.

단순한 규칙으로 만든 기준선도 비교 대상이 된다. 모델을 도입했을 때 개선되는 정도와 운영 부담을 함께 판단할 수 있기 때문이다.

 

 

각 단계에서 확인한 문제가 앞 단계의 수정으로 이어진다. 평가에서 특정 입력에 취약한 점을 발견하면 데이터를 보강하고, 운영 목적이 바뀌면 예측 대상부터 다시 정할 수 있다.

 

1.1.1 실험 단계

 

실험 단계에서는 확보한 데이터로 문제를 풀 수 있는지 확인한다. 데이터를 정리하고 기준 모델을 만든 뒤, 후보를 비교하면서 필요한 변경을 찾는다.

 

학습은 데이터로 모델의 내부 값을 조정하는 과정이다. 이렇게 만든 모델을 실행해 새 입력의 예측값을 얻는 과정이 추론이다. 학습 중 바뀌는 가중치와, 학습률·배치 크기처럼 실험자가 정하는 하이퍼파라미터도 구분해 기록한다.

 

 

실험 기록에는 입력 데이터의 버전, 실행한 코드, 설정, 평가값, 생성된 모델을 남긴다. 결과가 좋아졌을 때 어떤 변경이 영향을 줬는지 확인하려면 실행 조건이 함께 있어야 한다.

 

평가값이 충분해 보이더라도 실제 업무에 쓸 수 있는지는 별도로 확인한다. 여기서 업무 요구에 대한 검증은 모델 선택에 사용하는 검증 데이터와 의미가 다르다.

 

1.1.2 개발/스테이징/프로덕션 단계

실험에서 찾은 모델을 서비스에 연결하면서 개발 환경 밖의 조건을 확인한다. 요청 형식, 처리 시간, 접근 권한, 예상 트래픽, 실패했을 때의 동작 등이 포함된다.

 

개발 환경에서는 코드를 수정하고 기능을 점검한다. 스테이징에서는 운영과 유사한 조건으로 배포와 연동을 시험한다. 프로덕션에서는 실제 사용자 요청을 처리하며 상태를 관찰한다.

 

모델을 교체할 때는 서비스 코드와 설정도 호환되어야 한다. 어떤 조합이 배포됐는지 남기고, 문제가 생기면 이전 조합으로 돌아갈 수 있도록 준비한다. 이후의 성능 변화는 다시 실험할 이유와 데이터를 제공한다.

 

 

1.2 ML옵스에 필요한 역량

MLOps 작업에서는 모델, 데이터, 서비스 환경의 문제가 함께 나타난다. 예측 성능 저하처럼 보이는 현상도 입력 변환 오류나 데이터 전달 지연에서 시작될 수 있다.

 

 

한 사람이 모든 영역을 같은 깊이로 다룰 필요는 없다. 다만 자신이 만든 결과가 다음 단계에서 어떻게 사용되는지, 문제가 생기면 어느 담당자와 무엇을 확인해야 하는지는 알아야 한다. 공통된 실험 기록과 배포 이력이 팀 간 대화의 기준이 된다.

 

1.3 머신러닝 플랫폼 구축

여러 프로젝트가 학습 기록, 작업 실행, 모델 저장, 배포 기능을 각각 만들면 관리할 방식도 제각각 늘어난다. 플랫폼은 이런 반복 기능을 공통으로 제공하는 기반이다.

 

1.3.1 직접 구축 vs 구매

관리형 서비스를 선택하면 설치와 운영 부담 일부를 공급자에게 맡길 수 있다. 직접 구성하면 조직의 데이터 경로와 배포 방식에 맞추기 쉽지만, 업그레이드·장애 대응·접근 제어도 직접 책임져야 한다.

 

검토할 항목에는 비용 외에 데이터 접근 조건, 기존 시스템과의 연동, 팀의 운영 인력, 필요한 확장 기능이 들어간다. 작은 작업을 실제로 연결해 보면 설명서만으로 드러나지 않는 제약을 확인할 수 있다.

 

처음 구성에는 실험 추적과 반복 학습처럼 당장 필요한 기능을 넣고, 여러 프로젝트에서 공통 요구가 확인될 때 범위를 넓히는 방법을 생각할 수 있다.

 

1.3.2 ML옵스에서 LLM옵스로

LLM을 이용한 서비스에도 변경 기록과 평가, 배포 후 관찰이 필요하다. 여기에 프롬프트, 생성 설정, 모델 호출 비용 같은 관리 대상이 더해진다.

 

RAG를 사용하는 경우에는 검색 문서와 임베딩·색인·검색 결과도 응답에 영향을 준다. 모델을 바꾸지 않고 문서만 갱신해도 답변이 달라질 수 있으므로 이 경로를 함께 추적해야 한다.

 

1부에서는 이런 확장 관계를 이해해 두면 된다. 문서 처리 파이프라인이나 응답 평가 체계를 자세히 구현하는 내용은 이후 학습 범위로 둔다.

 

1.3.3 이 책에서 사용하는 도구

 

 

ML 플랫폼의 주요 구성요소

 

 

CH2. MLOps란 무엇인가

 

2.1 반복적인 ML옵스 수명주기

 

운영을 시작하면 데이터가 추가되고, 사용 조건이 바뀌며, 기존 평가에서 드러나지 않았던 실패가 발견된다. MLOps는 이런 변경을 다음 학습과 배포에 반영할 수 있도록 작업 절차를 관리한다.

 

처음 합의한 업무 목표와 오류 비용을 반복 과정에서도 확인해야 한다. 점수가 오른 모델이라도 응답 시간이 늘거나 중요한 사용자 집단에서 성능이 떨어지면 교체가 적절하지 않을 수 있다.

 

2.1.1 데이터 수집

 

수집할 데이터는 모델이 실제로 마주할 조건을 반영해야 한다. 데이터 개수와 함께 사용자·기기·시간대 등의 분포, 레이블의 신뢰도, 수집에서 빠진 경우를 확인한다.

 

원본을 정제하거나 중복을 제거했다면 적용한 기준을 기록한다. 나중에 데이터 오류를 발견했을 때 어떤 버전이 영향을 받았는지 찾으려면 변환 이력도 필요하다.

 

데이터셋을 나눌 때는 시간과 개체의 관계를 고려한다. 한 문서에서 잘라낸 유사한 조각이 학습과 평가에 함께 들어가면 실제보다 쉽게 맞히는 평가가 될 수 있다. 전처리에 필요한 통계도 훈련 부분에서 구한 뒤 나머지 분할에 적용한다.

 

 

2.1.2 탐색적 데이터 분석

 

EDA는 모델을 만들기 전에 데이터에 대한 예상이 맞는지 확인하는 작업이다. 필드의 의미, 값의 범위, 결측과 중복, 클래스 비율을 살피고 시간에 따른 변화도 비교한다.

 

이상값을 발견했다고 모두 제거할 수는 없다. 입력 오류인지, 실제 서비스에서도 나타나는 드문 경우인지 구분해야 한다. 피처가 예측에 유용해 보여도 서비스에서 계산하는 데 너무 오래 걸린다면 다른 설계가 필요하다.

 

확인된 조건은 검증 규칙으로 남긴다. 필수 식별자가 없거나 단위가 다른 값이 유입됐을 때 초기에 멈출 수 있으면, 이후 학습 결과를 뒤져야 하는 범위가 줄어든다.

 

 

2.1.3 모델링과 훈련

처음에는 비교 기준이 될 모델을 정하고, 변경할 요소를 좁혀 가며 실험한다. 데이터, 모델 구조, 학습 설정을 한꺼번에 바꾸면 결과 차이의 원인을 설명하기 어려워진다.

 

 

 

학습 조건과 모델·배포를 연결하는 리니지

 

한 번의 학습 실행에 입력 조건과 결과를 묶어 두면 모델끼리 비교하거나 과거 조건을 다시 구성하기 쉽다. 리니지는 이 실행이 어떤 데이터에서 출발해 어느 배포에 사용됐는지 연결하는 기록이다.

 

하이퍼파라미터 탐색도 이 기록 안에 포함한다. 탐색 범위와 선택 기준을 남기고, 검증 데이터에서 후보를 비교한다. 실행 이력이 있어도 하드웨어와 연산 방식에 따라 결과가 달라질 수 있으므로 필요한 재현 수준을 정해 두는 편이 좋다.

 

2.1.4 모델 평가

평가는 업무에서 어떤 오류를 감수할 수 있는지와 연결해야 한다. 같은 분류 문제라도 잘못 경고하는 비용과 놓치는 비용의 크기가 다를 수 있다.

 

 

전체 점수와 함께 실패가 몰리는 조건을 살핀다. 특정 촬영 환경이나 신규 사용자에게 취약하다면 그 조건의 데이터와 처리 과정을 따로 분석한다.

 

최종 평가에 사용할 데이터로 후보를 계속 고르면 그 데이터에도 간접적으로 맞춰지게 된다. 학습과 선택에 사용한 범위를 기록하고, 최종 확인에 사용할 조건을 구분해 두어야 한다.

 

2.1.5 배포

배포 대상은 API 서버일 수도 있고 정해진 시간에 실행하는 배치 작업이나 에지 장치일 수도 있다. 필요한 처리량, 허용 지연, 사용할 자원에 따라 실행 방식을 정한다.

 

실제 배포할 모델의 형식으로 대상 환경에서 시험한다. 모델을 압축하거나 변환했다면 예측 품질이 유지되는지도 다시 확인한다. 서비스 연동과 부하를 스테이징에서 점검한 뒤 운영에 반영한다.

 

롤백을 위해 모델, 이미지, 설정의 조합을 남긴다. 특정 모델 파일만 되돌렸을 때 전처리 코드와 맞지 않는 상황도 피해야 한다.

 

2.1.6 모니터링

운영에서는 실행 상태와 예측 품질을 함께 관찰한다. 서버가 응답하고 있다는 사실만으로 예측 결과의 유효성을 판단할 수는 없다.

 

 

 

입력 분포가 달라지는 데이터 드리프트와, 입력과 정답의 관계가 달라지는 개념 드리프트를 구분한다. 변화가 감지되면 실제 성능에 영향을 주는지 추가로 살펴야 한다.

 

정답을 뒤늦게 얻는 문제에서는 먼저 입력과 예측의 변화를 관찰하고, 결과가 확정되면 예측과 연결해 성능을 계산한다. 로그에는 당시 모델과 처리 코드의 버전도 남겨 조사에 사용할 수 있게 한다.

 

2.1.7 유지보수, 업데이트, 검토

모니터링에서 이상을 발견하면 원인에 맞는 작업을 선택한다. 누락된 입력을 복구하거나 코드를 고쳐야 할 수도 있고, 새로운 사례를 수집해 다시 학습해야 할 수도 있다.

 

 

새 모델은 기존 운영 모델과 같은 조건에서 비교한다. 평균 성능 외에 중요한 기능과 집단의 성능이 나빠지지 않았는지도 확인한다. 검증한 변경을 적용한 뒤에는 실제 효과를 관찰하며 다음 작업을 결정한다.

 

알림에는 기준값뿐 아니라 담당자와 대응 순서가 있어야 한다. 알림이 반복되는 이유와 처리 결과도 남겨 두면 다음 조치에 사용할 수 있다.

 

2.2 견고한 ML옵스가 중요한 이유

여러 도구를 연결하면 각 부분이 정상이어도 전체 결과가 틀릴 수 있다. 작업은 성공했지만 잘못된 데이터 버전을 읽었거나, 모델은 갱신됐는데 서비스가 이전 피처 정의를 사용할 수 있다.

 

단계 사이에서 주고받는 데이터와 버전을 확인하고 실패 조건을 정해야 한다. 입력 검증, 실행 이력, 배포 전 확인은 문제가 다음 단계까지 퍼지는 것을 줄여 준다.

 

이 과정을 수동으로 처리하면 담당자의 기억에 의존하는 부분이 늘어난다. 반복해서 확인할 조건을 절차와 도구에 넣어 두면 변경이 잦아져도 같은 기준을 적용할 수 있다.

 

2.3 성숙한 조직에서 ML옵스의 역할

팀이 늘어날수록 학습 실행, 실험 기록, 배포 권한을 공통 방식으로 제공할 필요가 생긴다. 각 팀이 같은 기반 작업을 다시 만드는 시간을 줄이고, 다른 사람이 결과를 확인할 수 있게 하기 위해서다.

 

플랫폼이 제공할 항목에는 재사용할 작업 컴포넌트, 공통 실행 환경, 모델 승인 절차, 자원 사용 기록 등이 있다. 팀은 이 기반 위에서 데이터와 모델의 가설을 비교하는 데 시간을 쓸 수 있다.

 

표준 절차가 실제 개발 흐름에서 사용하기 쉬워야 한다. 학습 실행 시 기록이 자동으로 남고, 검증 결과를 배포 과정에서 조회할 수 있다면 별도 문서를 수동으로 맞추는 일이 줄어든다.

2.4 데브옵스 vs ML옵스

DevOps에서 사용하는 버전 관리, 테스트, 자동 배포, 운영 관측은 ML 서비스에도 적용된다. MLOps에서는 프로그램 변경 외에 데이터와 학습 결과의 변경을 함께 관리한다.

 

 

서비스 프로그램을 수정하지 않았는데도 입력의 특성이 달라지면 기존 모델이 잘 맞지 않을 수 있다. 모델을 다시 만들었을 때 기능 테스트를 통과하는 것과 예측 품질이 나아지는 것도 별도로 확인해야 한다.

 

2.5 ML옵스 성숙도 수준

성숙도는 현재 무엇을 자동으로 반복하고 검증할 수 있는지 살펴보는 기준이다.

 

 

 

Level 1에서는 파이프라인이 새 모델을 만드는 과정을 반복한다. Level 2에서는 그 파이프라인의 코드가 바뀌었을 때도 검증과 배포를 자동으로 진행할 수 있다. 두 수준은 자동화하는 대상에서 차이가 난다.

 

AI 기초 용어 공부

MLOps를 공부하다 보면 LLM, RAG, MCP, vLLM처럼 서로 다른 역할의 용어가 한꺼번에 등장한다. 이름만 외우기보다 기술의 큰 범위, 모델의 종류, 모델 내부의 처리, 활용 방법, 실행 도구로 나누면 관계를 파악하기 쉽다.

아래에서는 AI 입문 용어 50개를 9개 주제로 묶었다. 각 용어의 뜻과 함께 혼동하기 쉬운 지점을 정리한다.

1. 큰 그림: AI와 머신러닝의 관계

AI 용어를 이해할 때는 먼저 포함 관계와 분류 기준을 구분하면 편하다. 머신러닝은 AI를 구현하는 방법 중 하나이고, 딥러닝은 머신러닝의 한 갈래다. 생성형 AI는 새로운 콘텐츠를 만드는 기능에 초점을 둔 분류이며, 대표적인 현대 생성형 모델은 딥러닝을 사용한다.

 

포함 관계: AI ⊃ 머신러닝 ⊃ 딥러닝
분류의 다른 축: 강화학습은 배우는 방식, 생성형 AI는 생성 기능에 초점을 둔 말이다.

 

 

 

 

2. 모델 이름: 무엇을 받아서 무엇을 내놓는가

모델 이름은 주로 데이터의 종류와 기능을 알려 준다. 다만 용어 사이의 경계는 겹칠 수 있다. 하나의 모델이 언어 모델이면서 동시에 멀티모달 모델일 수 있으며, 아래 설명은 대표적인 사용 형태를 정리한 것이다.

 

 

3. 모델 내부: 입력에서 답변까지

대표적인 자기회귀 언어 모델은 다음 토큰을 예측하는 과정을 반복해 답을 생성한다. 아래 흐름은 이해를 위한 단순화이며, 실제 구현에서는 이전 계산을 캐시하는 등 효율화를 적용한다.

입력 문장 → 토큰화 → 임베딩 → 트랜스포머 계산 → 다음 토큰 선택
선택한 토큰을 문맥에 더하고, 종료 조건에 도달할 때까지 생성을 이어 간다.

 

 

 

4. 활용: 자료를 연결하고 모델을 조정하는 방법

모델을 업무에 맞추는 방법은 바꾸려는 대상에 따라 달라진다. 요청을 명확히 할 것인지, 답에 필요한 자료를 제공할 것인지, 학습을 통해 응답 특성을 조정할 것인지 먼저 구분한다.

 

 

프롬프트, RAG, 파인튜닝은 무엇이 다른가?

프롬프트는 요청과 예시를 바꾸고, RAG는 답변에 참고할 자료를 찾아 전달하고, 파인튜닝은 학습으로 모델의 파라미터를 조정한다. 셋은 함께 사용할 수도 있다.

사내 문서 질의응답 예시
문서를 검색하기 좋게 준비 → 질문과 관련된 자료 검색 → 질문과 자료를 모델에 전달 → 답변과 근거 확인

 

문서가 자주 바뀌고 출처가 중요하다면 RAG가 유용한 선택이 될 수 있다. 일관된 분류나 특화된 출력이 필요하다면 파인튜닝의 효과를 평가한다. 무조건 같은 순서를 따르기보다 오류 원인과 요구사항에 맞춰 고른다.

 

5. 음성과 언어: STT, TTS, NLP

 

전통적인 음성 비서는 목소리를 글로 바꾸고, 요청을 처리한 뒤 답을 다시 음성으로 만든다. 최근에는 음성을 직접 주고받는 모델도 있어 모든 시스템이 아래 단계를 별도 모듈로 나누는 것은 아니다.

목소리 → STT → 요청 이해·답변 생성 → TTS → 답변 음성

 

 

 

6. 이미지 생성: 디퓨전 모델

이미지 생성에는 여러 방식이 있다. 그중 디퓨전은 잡음을 제거하는 과정을 학습해 데이터를 생성하는 대표적인 접근이다.

잡음 → 반복적인 잡음 제거 → 점차 드러나는 구조 → 생성 결과

 

 

 

7. 에이전트: 도구를 사용해 일을 수행하는 AI

AI 에이전트는 목표를 수행하는 과정에서 도구를 호출하고 그 결과를 다음 판단에 활용한다. 검색 결과를 확인하고, 부족한 정보가 있으면 다시 찾는 식이다. 반복 횟수와 종료 조건을 함께 설계해야 한다.

목표 파악 → 필요한 행동 선택 → 도구 실행 → 결과 확인 → 다음 행동 또는 종료

 

 

 

 

8. 설계: 엔지니어링 용어 구분하기

다음 표현은 AI 시스템을 설계할 때 무엇에 초점을 두는지 구분하는 데 도움이 된다. 다만 고정된 포함 관계나 공통의 성숙도 단계는 아니다. 특히 루프·하네스·그래프 엔지니어링은 아래와 같은 의미로 사용한다고 정의해 두는 편이 명확하다.

 

 

9. 실행: 모델을 메모리에 올리고 서비스하기

이 용어들은 앞에서 정리한 MLOps의 배포와 운영 단계에 연결된다. 모델을 직접 운영하면 메모리 사용량, 초기 응답 지연, 처리량과 장애 상황까지 함께 고려해야 한다.