11. Introduction 단계별 학습 문서

원문: sources/mlsysbook/11-introduction/source.md

이 문서는 Machine Learning Systems의 Introduction 장을 세 단계로 다시 풀어쓴 학습 가이드입니다.

처음부터 모든 내용을 완벽히 이해하려고 하지 않아도 돼요. 먼저 1단계로 큰 그림을 잡고, 2단계에서 흐름을 연결한 뒤, 3단계에서 원문에 가까운 깊이로 천천히 들어가면 돼요.

• 1단계는 중학교 수준입니다. 수식과 전문 용어를 줄이고, “이게 무엇이고 왜 필요할까요?”를 직관으로 잡아요.
• 2단계는 고등학교 수준입니다. 개념 사이의 흐름, 간단한 함수, 확률, 순서도를 연결해요.
• 3단계는 대학교 수준입니다. 원문 장의 논리를 거의 빠짐없이 따라가며, ML 시스템 공학의 학문적 의미와 실무적 제약을 촘촘히 해설해요.

읽는 방법

이 문서는 한 번에 끝까지 읽는 것보다 세 번에 나누어 읽는 편이 좋아요.

1. 먼저 1단계만 읽고 “AI는 모델 하나가 아니라 시스템이구나” 정도의 감각을 만들어요.
2. 그다음 2단계를 읽으며 데이터, 모델, 인프라가 어떤 순서로 이어지는지 확인해요.
3. 마지막으로 3단계를 읽으며 원문에서 말하는 학문적 주장과 실제 시스템 제약을 연결해요.

3단계는 일부러 자세하게 썼어요. 처음 읽을 때는 제목과 표, 중간 정리만 먼저 훑어도 괜찮아요.

이 장의 한 줄 요약

현대 AI는 단순히 똑똑한 알고리즘 하나가 아니에요. 데이터, 모델, 컴퓨팅 인프라가 함께 맞물려 움직이는 거대한 시스템이고, 이 시스템을 안정적이고 효율적이며 책임 있게 만드는 학문이 AI Engineering입니다.

1단계: 중학교 수준

여기서는 어려운 단어를 잠시 내려놓고, “왜 이런 분야가 필요해졌는지”만 잡아봐요. 머릿속에 그림이 생기면 성공이에요.

1. AI는 “스스로 규칙을 찾는 기계”에 가까워졌어요

옛날 컴퓨터 프로그램은 사람이 규칙을 하나하나 적어주는 방식이었어요. 예를 들어 체스를 두는 프로그램을 만든다면, 사람이 “중앙을 차지해라”, “왕을 지켜라”, “말을 공짜로 잃지 마라” 같은 규칙을 많이 적어 넣었어요.

하지만 요즘 AI는 다르게 만들어요. 사람이 모든 규칙을 적어주기보다, 아주 많은 예시를 보여주고 컴퓨터가 그 안에서 패턴을 찾게 해요. 체스라면 수많은 경기 기록을 보고, 사진 분류라면 수많은 사진을 보고, 언어 모델이라면 수많은 글을 보면서 “이런 상황에서는 이런 답이 잘 맞는다”는 규칙을 스스로 배워요.

여기서 중요한 말은 두 가지예요.

• AI는 큰 목표예요. 사람처럼 보고, 듣고, 판단하고, 문제를 풀게 만들고 싶은 꿈이에요.
• ML, 즉 머신러닝은 그 목표를 이루는 대표적인 방법이에요. 데이터를 보고 규칙을 배우는 방식이에요.

2. ML 시스템은 세 가지가 함께 있어야 움직여요

AI를 “똑똑한 머리”라고만 생각하면 조금 부족해요. 실제 AI 서비스가 움직이려면 아래 세 가지가 함께 필요해요.

• 데이터: AI가 배우는 재료예요. 사진, 글, 음성, 센서 기록, 클릭 기록 같은 것들이 여기에 들어가요.
• 알고리즘 또는 모델: 데이터를 보고 패턴을 배우는 두뇌예요.
• 컴퓨팅 인프라: 데이터를 저장하고, 모델을 학습시키고, 사용자에게 답을 주는 컴퓨터와 서버와 칩이에요.

이 셋은 삼각형처럼 서로 기대고 있어요.

좋은 모델이 있어도 데이터가 나쁘면 제대로 배울 수 없어요. 데이터가 많아도 컴퓨터가 너무 느리면 학습할 수 없어요. 강력한 컴퓨터가 있어도 모델과 데이터가 엉망이면 쓸모가 없어요.

3. AI는 고장 나도 조용히 고장 날 수 있어요

일반 소프트웨어는 문제가 생기면 보통 에러가 나요. 앱이 꺼지거나, 빨간 오류 메시지가 뜨거나, 서버가 멈춰요.

ML 시스템은 조금 더 까다로워요. 겉으로는 계속 작동하는데, 답의 품질이 조금씩 나빠질 수 있어요.

예를 들어 추천 시스템은 계속 영화를 추천하지만, 사람들의 취향이 바뀌어서 점점 덜 맞는 추천을 할 수 있어요. 자율주행차의 보행자 인식 모델도 계속 작동하지만, 겨울 옷차림이나 새로운 도로 환경 때문에 정확도가 낮아질 수 있어요.

그래서 ML 시스템은 “서버가 살아 있나?”만 보면 안 돼요. “데이터가 변했나?”, “모델의 예측이 아직 맞나?”, “현실에서 성능이 떨어지고 있나?”를 계속 지켜봐야 해요.

4. AI 발전의 큰 교훈은 “규칙을 많이 쓰는 것보다, 많이 배우게 만드는 시스템이 이긴다”예요

AI 역사에서 반복된 일이 있어요. 처음에는 사람이 똑똑한 규칙을 많이 넣으면 AI가 잘될 것이라고 생각했어요. 그런데 시간이 지나면서, 많은 데이터와 많은 계산을 이용해 스스로 배우는 방법이 더 강해졌어요.

이 교훈을 원문에서는 Richard Sutton의 Bitter Lesson으로 설명해요. 조금 씁쓸한 이유는, 인간이 열심히 만든 지식과 규칙이 결국에는 대규모 계산과 학습을 잘 활용하는 일반적인 방법에 밀리는 일이 많았기 때문이에요.

그래서 현대 AI에서 중요한 능력은 “멋진 아이디어 하나”만이 아니에요. 엄청난 데이터를 모으고, 수많은 GPU를 잘 묶고, 모델을 빠르게 학습시키고, 사용자에게 안정적으로 제공하는 능력이 함께 중요해졌어요.

5. AI의 역사는 규칙에서 학습으로 이동해왔어요

AI의 흐름은 대략 이렇게 볼 수 있어요.

1. Symbolic AI: 사람이 규칙을 직접 적어 넣었어요.
2. Expert Systems: 특정 분야 전문가의 지식을 규칙으로 저장했어요.
3. Statistical Learning: 데이터에서 확률적 패턴을 찾기 시작했어요.
4. Shallow Learning: 의사결정나무, SVM, 회귀 같은 모델을 사용했어요.
5. Deep Learning: 여러 층의 신경망이 스스로 특징을 찾아내기 시작했어요.
6. Foundation Models: 아주 큰 데이터와 계산으로 범용 모델을 만들기 시작했어요.

핵심은 점점 사람이 직접 규칙을 쓰는 비중은 줄고, 데이터와 계산과 인프라의 중요성이 커졌다는 점이에요.

6. AI 시스템은 한 번 만들고 끝나는 물건이 아니에요

일반 프로그램은 코드를 만들고 테스트하고 배포하면 어느 정도 마무리돼요. 물론 유지보수는 필요하지만, 기본 규칙은 코드 안에 있어요.

ML 시스템은 달라요. 현실 세계가 바뀌면 데이터가 바뀌고, 데이터가 바뀌면 모델 성능도 바뀌어요. 그래서 ML 시스템은 계속 순환해요.

1. 데이터를 모아요.
2. 데이터를 정리해요.
3. 모델을 학습해요.
4. 모델을 평가해요.
5. 모델을 배포해요.
6. 실제 사용 중 성능을 감시해요.
7. 다시 데이터를 모으고 개선해요.

이 순환이 잘 돌아가면 시스템은 점점 좋아져요. 반대로 데이터 품질이 나쁘고 감시가 약하면 조용히 나빠져요.

7. 이 장에서 꼭 잡아야 하는 핵심 단어

• AI: 지능적인 일을 하는 시스템을 만들려는 큰 목표
• ML: 데이터에서 패턴을 배워 AI를 구현하는 방법
• ML 시스템: 데이터, 모델, 컴퓨팅 인프라가 합쳐진 전체 시스템
• AI Triangle: 데이터, 알고리즘, 인프라의 삼각 관계
• Silent degradation: 시스템은 멀쩡해 보이지만 성능이 조용히 떨어지는 현상
• Data drift: 시간이 지나며 입력 데이터의 성질이 바뀌는 현상
• Bitter Lesson: 대규모 계산을 활용하는 일반적 방법이 손으로 만든 규칙보다 장기적으로 강했다는 교훈
• Deployment: 모델을 실제 환경에서 사용하게 만드는 일
• AI Engineering: ML 시스템을 안정적, 효율적, 책임 있게 만드는 공학

2단계: 고등학교 수준

여기부터는 블랙박스 안을 조금 열어볼게요. 수식은 최소한으로 쓰되, 데이터가 어떤 흐름으로 모델과 시스템을 움직이는지 논리적으로 연결해봐요.

1. 이 장의 논리 흐름

이 장은 “AI가 왜 시스템 공학의 문제가 되었는가”를 단계적으로 설명해요. 아래 흐름을 먼저 머릿속에 넣고 읽으면 훨씬 편해요.

AI라는 목표
  ↓
ML이라는 방법: 데이터에서 패턴을 학습
  ↓
ML 시스템의 정의: 데이터 + 알고리즘 + 컴퓨팅 인프라
  ↓
전통 소프트웨어와 다른 실패 방식: 조용한 성능 저하
  ↓
Bitter Lesson: 큰 계산을 잘 쓰는 일반 방법이 이김
  ↓
AI 역사: 규칙 기반 → 통계 학습 → 딥러닝 → 대규모 모델
  ↓
ML 생명주기: 수집 → 준비 → 학습 → 평가 → 배포 → 모니터링
  ↓
실제 사례: Waymo, FarmBeats, AlphaFold
  ↓
핵심 도전: 데이터, 모델, 시스템, 윤리
  ↓
AI Engineering과 다섯 기둥

2. AI와 ML의 관계

집합으로 보면 다음처럼 이해할 수 있어요.

AI = 지능적인 행동을 하는 시스템을 만들려는 전체 분야
ML = AI를 구현하는 방법 중, 데이터에서 패턴을 학습하는 방법

따라서 ML은 AI의 부분집합이에요.

예를 들어 “사람처럼 체스를 두는 기계”는 AI 목표예요. 이 목표를 달성하는 방법은 여러 가지가 있을 수 있어요. 사람이 규칙을 직접 적는 방식도 있고, 수많은 체스 경기를 학습시키는 방식도 있어요. 후자가 바로 ML이에요.

3. ML 시스템을 함수처럼 보기

고등학교 수준에서는 ML 모델을 일단 함수로 보면 충분해요.

입력 x → 모델 f → 예측 y

예를 들어 사진 x가 들어오면 모델 f가 “고양이일 확률 0.92” 같은 예측 y를 내요.

조금 더 수학적으로는 다음처럼 볼 수 있어요.

y = f_w(x)

여기서 w는 모델이 학습한 값들이에요. 신경망에서는 이 값들을 가중치라고 불러요. 학습이란 정답과 예측의 차이를 줄이도록 w를 계속 조정하는 과정이에요.

하지만 이 장의 핵심은 모델 함수 하나가 아니에요. 실제 ML 시스템은 아래 전체 흐름을 포함해요.

데이터 수집 → 데이터 저장/정리 → 모델 학습 → 모델 평가 → 배포 → 모니터링

모델 f_w는 이 긴 흐름의 한 부분이에요.

4. AI Triangle을 논리적으로 보기

AI Triangle은 데이터, 알고리즘, 인프라의 상호 의존성을 설명해요.

데이터가 바뀌면 → 모델 성능이 바뀌어요.
모델이 커지면 → 더 많은 계산과 메모리가 필요해요.
인프라가 약하면 → 쓸 수 있는 모델과 데이터 규모가 제한돼요.

예를 들어 자율주행차가 더 정확한 인식 모델을 쓰고 싶다고 해볼게요. 모델이 커지면 더 많은 센서 데이터와 더 강한 차량 내 컴퓨터가 필요해요. 하지만 차량 안에서는 전력, 발열, 가격, 지연시간이 제한돼요. 따라서 정확도만 보고 모델을 고를 수 없어요.

5. 전통 소프트웨어와 ML 시스템의 실패 방식 비교

여기서 가장 중요한 위험은 silent performance degradation이에요. 예측은 계속 나오지만, 실제 품질은 떨어질 수 있어요.

6. 데이터 드리프트를 간단한 확률 변화로 이해하기

ML 모델은 훈련 데이터의 분포를 보고 배워요. 단순하게 말하면 모델은 다음 관계를 배워요.

훈련 시점: P_train(x, y)
운영 시점: P_prod(x, y)

여기서 P_train은 학습 때의 데이터 패턴이고, P_prod는 실제 서비스 중 만나는 데이터 패턴이에요.

문제는 시간이 지나면 두 분포가 달라질 수 있다는 점이에요.

P_train(x, y) != P_prod(x, y)

예를 들어 자율주행 모델을 맑은 날, 넓은 도로, 특정 도시 중심으로 학습했는데 실제 운영에서는 눈, 비, 공사 구간, 다른 도시의 복잡한 교통을 많이 만나면 예측 성능이 떨어질 수 있어요.

7. 통계 학습의 감각: 스팸 필터 예시

원문은 스팸 필터를 예로 들어요. 규칙 기반 시스템은 “이 단어가 있으면 스팸”처럼 정해진 규칙을 써요. 통계 기반 시스템은 “이 단어가 스팸 메일에서 얼마나 자주 나오고, 정상 메일에서는 얼마나 드문가”를 봐요.

베이즈 정리로 단순화하면 다음과 같아요.

P(스팸 | 단어) = P(단어 | 스팸) × P(스팸) / P(단어)

뜻을 풀면 이래요.

• 어떤 단어가 있을 때 그 메일이 스팸일 확률을 구하고 싶어요.
• 그러려면 스팸 메일에서 그 단어가 얼마나 자주 나오는지 봐요.
• 전체 메일 중 스팸의 비율도 봐요.
• 그 단어 자체가 얼마나 흔한지도 고려해요.

이 사고방식은 “사람이 규칙을 다 쓰는 것”에서 “데이터가 말해주는 확률을 사용하는 것”으로 넘어가는 중요한 전환이에요.

8. Precision과 Recall의 트레이드오프

ML 시스템에는 보통 하나의 정답만 있는 것이 아니라 trade-off가 있어요.

• Precision: 모델이 “맞다”고 한 것들 중 실제로 맞은 비율
• Recall: 실제로 찾아야 할 것들 중 모델이 찾아낸 비율

스팸 필터는 정상 메일을 스팸으로 잘못 막으면 큰 문제예요. 그래서 precision을 중요하게 볼 수 있어요. 의료 진단은 위험한 질병을 놓치면 큰 문제예요. 그래서 recall을 더 중요하게 볼 수 있어요.

같은 ML 기술이라도 어떤 지표를 우선할지는 도메인의 위험에 따라 달라져요. 그래서 좋은 ML 시스템은 “정확도가 높다”만으로 평가하기 어려워요.

9. 배포 환경이 전체 생명주기를 바꿔요

ML 시스템은 어디서 실행되느냐에 따라 완전히 달라져요.

자율주행차는 즉시 판단해야 하므로 차량 안에서 추론해야 해요. 하지만 모델 개선과 대규모 시뮬레이션은 클라우드가 더 적합해요. 그래서 엣지와 클라우드를 함께 써요.

10. 이 장의 고등학교 수준 결론

이 장의 핵심은 “AI는 수학 모델 하나가 아니라 계속 돌아가는 시스템”이라는 점이에요.

모델 함수 f_w(x)만 이해하면 AI의 일부만 이해한 것이에요. 실제 AI를 더 깊게 이해하려면 다음 질문까지 함께 봐야 해요.

• x는 어디서 오고, 품질은 괜찮은가요?
• w는 어떤 데이터와 계산으로 학습됐는가?
• 모델은 어디서 실행되는가?
• 응답 시간, 전력, 비용은 괜찮은가?
• 현실 데이터가 바뀌면 누가 어떻게 알아차리는가?
• 성능이 떨어졌을 때 다시 학습하고 배포하는 절차가 있나요?
• 이 시스템은 공정하고 안전하며 개인정보를 보호하나요?

3단계: 대학교 수준

3단계는 원문을 가장 가까이 따라가는 부분이에요. 다만 길게 느껴질 수 있으니, 각 절 끝의 중간 정리를 작은 쉼표처럼 사용하면 좋아요.

1. Purpose: 왜 ML Systems Engineering을 배워야 할까요?

이 장은 책 전체의 개념적 출발점이에요.

원문은 머신러닝을 “프로그래머가 직접 규칙을 쓰는 컴퓨팅” 이후 가장 큰 변화로 봐요. 전통 소프트웨어는 명시적 명령으로 행동하지만, ML 시스템은 데이터에서 추출한 통계적 패턴으로 행동해요. 이 차이 때문에 기존 소프트웨어 공학만으로는 충분하지 않아요.

핵심 문제는 세 가지예요.

첫째, ML 시스템은 배운 행동을 해요. 그러므로 정확성은 코드만이 아니라 데이터, 학습 과정, 평가 방식, 운영 환경에 의해 결정돼요.

둘째, ML 시스템은 대규모로 동작해요. 기후 모델링, 의료 진단, 추천 시스템, 자율주행처럼 현대 AI 응용은 거대한 데이터를 다루고, 수많은 사용자에게 낮은 지연시간으로 응답해야 해요.

셋째, ML 시스템은 불확실성 속에서 작동해요. 입력 데이터는 잡음이 많고, 세계는 계속 변하며, 모델은 확률적 판단을 해요. 따라서 “코드가 맞으면 시스템이 맞다”는 단순한 관점이 깨져요.

이 장의 학습 목표는 다음처럼 압축할 수 있어요.

• ML 시스템을 데이터, 알고리즘, 인프라가 결합된 통합 컴퓨팅 시스템으로 정의해요.
• 전통 소프트웨어와 ML 시스템의 실패 방식 차이를 이해해요.
• AI Triangle으로 데이터, 모델, 인프라의 상호 의존성을 분석해요.
• AI 패러다임이 symbolic AI, statistical learning, deep learning으로 이동한 역사적 이유를 추적해요.
• Sutton의 Bitter Lesson이 왜 시스템 공학의 중요성을 설명하는지 이해해요.
• ML lifecycle과 deployment spectrum이 설계 결정에 어떤 영향을 주는지 파악해요.
• 데이터, 모델, 시스템, 윤리 문제를 ML 시스템의 핵심 도전으로 분류해요.
• 다섯 기둥 프레임워크로 AI Engineering의 전체 구조를 잡아요.

중간 정리: 이 장은 “AI가 왜 모델 연구만이 아니라 시스템 공학의 문제가 되었는가”를 설명하는 입구예요.

2. AI에서 일어난 공학적 혁명

원문은 현대 AI의 변화를 산업혁명과 디지털 혁명에 비유해요.

산업혁명은 물리적 힘을 다루는 기계공학을 발전시켰고, 디지털 혁명은 알고리즘 복잡성을 다루는 컴퓨터공학을 발전시켰어요. 현대 AI는 학습하는 시스템, 적응하는 시스템, 거대한 규모로 운영되는 시스템을 다루기 때문에 새로운 공학 패러다임이 필요해요.

전통 소프트웨어는 deterministic architecture에 가까워요. 같은 입력에는 같은 출력이 나와요. 반면 ML 시스템은 probabilistic architecture에 가까워요. 입력과 출력의 관계가 데이터에서 학습한 확률적 패턴에 의해 결정돼요.

이 변화는 세 가지 공학적 요구를 만들어요.

• Reliability: 사람이 직접 코딩하지 않은 학습된 행동을 어떻게 신뢰할 수 있을까요?
• Scalability: 페타바이트급 데이터와 수많은 동시 사용자 요청을 어떻게 처리할 수 있을까요?
• Robustness: 운영 데이터가 훈련 데이터와 달라질 때 어떻게 안전하게 버틸 수 있을까요?

페타바이트급 데이터는 단순히 저장 공간의 문제가 아니에요. 저장, 전송 대역폭, 장애 허용성, 일관성, 병렬 처리, 데이터 검증, 데이터 서빙이 함께 해결되어야 해요.

이 지점에서 ML은 알고리즘 문제가 아니라 시스템 문제가 돼요.

이 장은 이후 논의를 위해 세 가지 이론적 틀을 세워요.

1. AI와 ML의 관계
2. AI Triangle, 즉 데이터, 알고리즘, 인프라의 삼각 구조
3. ML lifecycle과 deployment spectrum

그리고 마지막에는 다섯 기둥 프레임워크로 책 전체를 조직해요.

중간 정리: 현대 AI가 어려운 이유는 모델이 복잡해서만이 아니에요. 데이터 규모, 계산 인프라, 운영 환경이 함께 커졌기 때문이에요.

3. AI라는 비전과 ML이라는 실천 방법

AI는 “무엇을 만들고 싶은가”에 대한 비전이에요. 이미지 인식, 언어 이해, 의사결정, 문제 해결처럼 인간 지능이 필요한 일을 기계가 수행하게 만들고 싶다는 목표예요.

ML은 “그 목표를 어떻게 구현할까요?”에 대한 방법론이에요. ML은 명시적 규칙을 직접 쓰는 대신, 데이터에서 패턴을 자동으로 발견하게 해요.

체스 프로그램 예시는 이 차이를 선명하게 보여줘요.

• Symbolic AI 방식: 사람이 체스 규칙과 전략을 직접 코딩해요.
• ML 방식: 컴퓨터가 수많은 체스 게임을 분석하며 승리로 이어지는 패턴을 학습해요.

규칙 기반 시스템은 프로그래머의 지식과 노동에 따라 확장돼요. 새로운 상황이 생기면 사람이 새 규칙을 추가해야 해요. 반면 ML 시스템은 데이터와 계산 인프라를 통해 확장돼요. 데이터가 많아지고 계산 능력이 커지면 더 넓은 패턴을 배울 수 있어요.

이 전환은 시스템 공학의 역할을 크게 키웠어요. 현대 AI 성능은 모델 아이디어뿐 아니라, 대규모 데이터 수집, 학습 인프라, 분산 계산, 실시간 서빙, 지속적 모니터링 능력에 의존해요.

중간 정리: AI는 목표이고, ML은 그 목표를 데이터 기반 학습으로 구현하는 대표적인 방법이에요.

4. ML 시스템의 정의: AI Triangle

원문은 ML 시스템을 단독 알고리즘이 아니라 데이터, 모델/알고리즘, 컴퓨팅 인프라가 통합된 전체 생태계로 정의해요.

세 구성요소의 역할은 다음과 같아요.

이 세 요소는 독립적이지 않아요.

• 모델 구조는 학습과 추론에 필요한 계산량, 메모리, 데이터량을 결정해요.
• 데이터의 크기와 복잡도는 필요한 저장소와 처리 인프라를 결정하고, 가능한 모델 선택에도 영향을 줘요.
• 인프라의 능력은 모델 크기와 데이터 처리량의 상한을 정해요.

원문은 우주 탐사 비유를 사용해요. 알고리즘 개발자는 새로운 가능성을 탐색하는 우주비행사, 데이터 팀은 정보를 공급하는 미션 컨트롤, 인프라 엔지니어는 우주선을 만드는 로켓 엔지니어에 해당해요. 하나만 뛰어나서는 임무가 성공하기 어려워요.

AlexNet의 2012년 ImageNet 성공은 AI Triangle의 좋은 사례예요. CNN이라는 알고리즘, ImageNet이라는 대규모 데이터, GPU 병렬 처리라는 인프라가 동시에 맞물렸기 때문에 성과가 가능했어요. 이는 hardware-software co-design, 즉 알고리즘과 하드웨어를 함께 고려하는 설계 관점의 중요성을 보여줘요.

중간 정리: ML 시스템을 볼 때는 항상 “데이터는 충분한가요? 모델은 적절한가요? 인프라는 감당할 수 있나요?”를 함께 물어야 해요.

5. 전통 소프트웨어와 ML 시스템의 근본 차이: 실패 방식

전통 소프트웨어는 보통 명시적으로 실패해요. 코드가 깨지면 프로그램이 중단되거나 에러가 발생하고, 모니터링 시스템이 경고를 내요. 문제를 진단할 단서가 비교적 분명해요.

반면 ML 시스템은 조용히 실패할 수 있어요. 서버는 정상이고, API도 응답하고, 모델도 계속 예측을 내지만, 실제 성능은 점점 떨어질 수 있어요.

자율주행차의 보행자 인식 모델을 생각해볼게요. 계절 변화, 조명, 옷차림, 날씨가 훈련 데이터와 달라지면 정확도가 95%에서 85%로 내려갈 수 있어요. 하지만 시스템은 여전히 대부분의 보행자를 감지하고 있으므로 일반적인 오류 로그에는 문제가 드러나지 않을 수 있어요. 추천 시스템도 마찬가지예요. 사용자의 취향이 변하면 추천 정확도가 85%에서 60%로 떨어질 수 있지만, 서버 관점에서는 정상적으로 추천을 생성하고 있어요.

이 현상은 AI Triangle 전체에 걸쳐 나타나요.

• 데이터: 현실의 입력 분포가 변해요.
• 알고리즘: 모델은 과거 훈련 데이터에서 배운 패턴으로 계속 예측해요.
• 인프라: 인프라는 잘못된 예측도 안정적으로 대규모 서빙해요.

특히 training-serving skew가 중요해요. 훈련 때 계산한 feature와 실제 서비스 때 계산한 feature가 다르면, 코드는 정상이어도 모델 성능이 낮아질 수 있어요. 인프라 문제처럼 보이지만 결과는 알고리즘 성능 저하로 나타나요.

따라서 ML 시스템 모니터링은 네 가지 차원을 봐야 해요.

1. Infrastructure health: 서버, 지연시간, 에러율, 처리량
2. Model performance: 정확도, 손실, calibration, drift 이후 성능
3. Data quality: 결측, 이상치, 분포 변화, feature skew
4. Business or safety impact: 사용자 만족도, 안전 지표, 비용, 실패 영향

중간 정리: ML 시스템은 “작동 여부”뿐 아니라 “아직 잘 맞고 있는지”를 계속 확인해야 해요.

6. Bitter Lesson과 시스템 공학의 중요성

Richard Sutton의 Bitter Lesson은 AI 역사에서 반복된 패턴을 요약해요. 인간 지식을 세밀하게 인코딩하는 방식은 단기적으로 좋아 보일 수 있지만, 장기적으로는 대규모 계산을 활용하는 일반적인 방법이 더 강력했다는 것이에요.

원문은 여러 사례를 들어요.

• Deep Blue는 체스에서 인간 전략을 세밀하게 모방하기보다 대규모 탐색을 활용했어요.
• AlphaGo는 인간의 Go 지식을 직접 규칙화하기보다 self-play와 학습을 활용했어요.
• 컴퓨터 비전에서는 손으로 만든 feature engineering보다 CNN이 강력해졌어요.
• 음성 인식에서도 인간 음성학을 세밀히 모델링한 방식보다 end-to-end deep learning이 우세해졌어요.

“Bitter”인 이유는 인간의 직관과 자부심을 거스르기 때문이에요. 우리는 인간의 전문 지식을 넣으면 더 똑똑해질 것이라고 기대하지만, 충분한 규모에서는 일반적인 학습 방법과 계산 자원이 더 큰 성과를 내는 일이 반복되었어요.

현대 언어 모델과 이미지 생성 모델도 이 패턴 위에 있어요. GPT 계열이나 DALL-E 같은 시스템의 능력은 인간이 언어학이나 예술 규칙을 직접 모두 적어 넣어서 나온 것이 아니라, 거대한 데이터와 계산으로 범용 신경망을 학습한 결과예요.

하지만 여기서 중요한 결론은 “계산만 많으면 된다”가 아니에요. 대규모 계산을 실제로 활용하려면 시스템 공학이 필요해요.

• 페타바이트급 데이터를 수집하고 정리해야 해요.
• 수천 개 GPU를 조율해야 해요.
• 메모리 대역폭 병목을 줄여야 해요.
• 전력과 발열을 관리해야 해요.
• 수백만 사용자에게 낮은 지연시간으로 모델을 제공해야 해요.
• 운영 중 성능을 계속 평가하고 업데이트해야 해요.

원문은 현대 ML 시스템의 주요 병목이 단순 compute capacity가 아니라 memory bandwidth라고 강조해요. 행렬 곱 같은 연산은 이론적으로 매우 빠르게 수행할 수 있지만, 실제 시스템에서는 데이터를 메모리에서 프로세서로 옮기는 시간이 지배적일 수 있어요. 큰 모델은 파라미터를 읽어오는 것만으로도 막대한 대역폭을 요구해요.

Amdahl의 법칙도 이 관점을 강화해요. 어떤 작업의 80%가 데이터 이동에 소비된다면, 계산 부분을 무한히 빠르게 해도 전체 속도 향상은 제한돼요. 따라서 현대 ML 시스템 최적화는 연산량뿐 아니라 데이터 이동, 메모리 계층, 캐시, HBM, near-data processing, accelerator 설계까지 포함해요.

중간 정리: Bitter Lesson은 “사람의 지식이 쓸모없다”는 말이 아니에요. 대규모 계산을 실제로 활용할 수 있는 시스템을 만드는 능력이 결정적으로 중요하다는 뜻이에요.

7. AI 패러다임의 역사적 진화

7.1 세 가지 수렴: 데이터, 알고리즘, 하드웨어

AI가 시스템 중심으로 이동한 배경에는 세 가지 요인의 수렴이 있어요.

첫째, 인터넷과 디지털화가 거대한 데이터를 만들었어요. 웹 문서, 이미지, 소셜 미디어, 센서, 거래 기록, 공개 데이터셋이 학습 재료가 되었어요.

둘째, 딥러닝, attention, transformer, transfer learning 같은 알고리즘 발전이 다양한 데이터에서 일반화 가능한 표현을 학습할 수 있게 했어요.

셋째, GPU와 클라우드 인프라가 대규모 계산을 현실적으로 가능하게 했어요. GPU는 원래 그래픽 처리용이었지만, 행렬과 벡터 연산이 많은 ML에 잘 맞았어요.

이 세 요소는 서로를 증폭했어요. 더 큰 데이터는 더 많은 계산을 요구했고, 더 좋은 알고리즘은 더 큰 데이터를 쓸 이유를 만들었고, 더 빠른 하드웨어는 더 큰 모델을 가능하게 했어요.

이 흐름을 한 문장으로 줄이면 다음과 같아요.

데이터가 커짐 → 모델이 커짐 → 계산이 커짐 → 시스템 공학이 중요해짐

7.2 Symbolic AI Era

1956년 Dartmouth Conference에서 AI라는 용어가 공식적으로 등장했어요. 초기 AI 연구자들은 지능을 symbol manipulation, 즉 기호 조작으로 환원할 수 있다고 보았어요. Daniel Bobrow의 STUDENT 시스템은 자연어로 된 대수 문제를 풀 수 있는 초기 사례였어요.

하지만 symbolic AI는 brittle했어요. 입력이 미리 프로그램된 패턴과 조금만 달라도 실패했어요. 실험실에서는 지능적으로 보였지만, 현실의 변형과 예외에는 약했어요. 시스템 관점에서는 새로운 edge case마다 사람이 규칙을 추가해야 하므로 운영 비용이 지속적으로 커졌어요.

7.3 Expert Systems Era

1970년대 중반 이후 연구자들은 범용 지능 대신 특정 분야의 전문가 지식을 시스템에 넣는 방향으로 이동했어요. MYCIN은 혈액 감염을 진단하기 위해 수백 개의 전문가 규칙을 사용한 대표적인 expert system이에요.

MYCIN은 중요한 진전이었지만 세 가지 문제를 드러냈어요.

• Knowledge capture: 전문가의 암묵지를 정확한 규칙으로 바꾸기 어려워요.
• Uncertainty handling: 정보가 불완전하거나 애매할 때 인간처럼 유연하게 판단하기 어려워요.
• Maintenance: 규칙이 많아질수록 새 규칙이 기존 규칙과 충돌하고, 지식이 바뀔 때 업데이트가 어려워요.

이 문제들은 현대 ML에서도 다른 형태로 남아 있어요. 데이터 수집, bias, drift, 모델 업데이트, 운영 유지보수는 여전히 핵심 문제예요.

7.4 Statistical Learning Era

1990년대에는 손으로 규칙을 쓰는 방식에서 데이터 기반 통계 학습으로 이동했어요. 이 이동을 가능하게 한 요인은 디지털 데이터 증가, Moore’s Law에 따른 계산 능력 향상, SVM과 개선된 신경망 같은 알고리즘 발전이에요.

스팸 필터는 좋은 예예요. 규칙 기반 필터는 특정 단어나 패턴을 막지만, 스패머가 표현을 조금 바꾸면 쉽게 우회돼요. 통계 기반 필터는 많은 이메일 예시에서 단어와 스팸 여부의 확률적 관계를 학습해요.

이 시기에 세 가지 핵심 개념이 자리 잡았어요.

• Data quality and quantity: 모델은 훈련 데이터에 있는 패턴만 배울 수 있어요.
• Evaluation: 성능을 객관적으로 비교하려면 지표와 평가 절차가 필요해요.
• Precision-recall trade-off: 어떤 오류를 더 줄일 것인지는 응용 분야의 위험에 따라 달라져요.

스팸 필터는 중요한 메일을 잘못 막는 것을 피해야 하고, 의료 진단은 위험한 질병을 놓치지 않는 것이 중요할 수 있어요. ML 시스템 설계는 항상 이런 trade-off를 명시해야 해요.

7.5 Shallow Learning Era

2000년대의 shallow learning은 보통 하나 또는 두 단계의 처리 구조를 가진 모델을 중심으로 했어요. 대표 알고리즘은 decision tree, k-nearest neighbors, linear regression, logistic regression, SVM 등이에요.

이 시기의 특징은 인간이 feature를 설계하고, 모델은 그 feature를 바탕으로 통계적 판단을 하는 hybrid approach였어요.

• Decision tree는 해석 가능성이 높고 계산량이 작아요.
• KNN은 유사한 과거 사례를 찾아 예측해요.
• Linear/logistic regression은 단순하고 해석 가능해요.
• SVM은 margin과 kernel trick을 통해 복잡한 경계를 다룰 수 있어요.

시스템 관점에서 shallow learning은 작은 데이터와 제한된 계산 환경에서 강했어요. 하지만 대규모 데이터에서는 SVM의 kernel matrix처럼 메모리 요구가 커져 확장성이 문제가 될 수 있어요.

Viola-Jones 얼굴 검출 알고리즘은 이 시대의 상징적 사례예요. 단순한 직사각형 feature와 cascade classifier를 사용해 2001년 하드웨어에서도 실시간 얼굴 검출을 가능하게 했어요. 이 사례는 알고리즘 설계가 하드웨어 제약과 잘 맞을 때 새로운 응용이 가능해진다는 점을 보여줘요.

7.6 Deep Learning Era

딥러닝은 사람이 feature를 직접 설계하는 대신, 여러 층의 신경망이 raw data에서 점점 추상적인 표현을 학습하게 해요. 이미지에서는 초기 층이 edge와 contrast를 잡고, 중간 층이 texture와 shape를 만들고, 높은 층이 귀, 수염, 얼굴 같은 의미 있는 feature를 조합해요.

AlexNet은 2012년 ImageNet에서 결정적 전환점이 되었어요. CNN 구조, 대규모 이미지 데이터, GPU 병렬 계산이 맞물려 이전 방법보다 훨씬 낮은 오류율을 달성했어요. 원문은 AlexNet을 단순한 알고리즘 승리가 아니라 memory bandwidth, GPU 분할, gradient update 조율, framework infrastructure가 결합된 시스템 성과로 해석해요.

중요한 점은 Theano 같은 프레임워크, automatic differentiation, GPU orchestration이 없었다면 알고리즘 아이디어가 실제로 대규모 학습으로 이어지기 어려웠다는 것이에요. 현대 딥러닝의 발전은 모델 논문만의 역사가 아니라 프레임워크와 하드웨어와 데이터 파이프라인의 역사이기도 해요.

이후 foundation model 시대에는 모델 규모가 폭발적으로 증가했어요. GPT-3는 175B parameters를 가지고, 학습과 서빙에 막대한 저장소, GPU, 메모리 대역폭, 전력, 냉각, 분산 학습 인프라를 요구했어요. 이 규모에서 emergent abilities가 나타났지만, 동시에 비용, 접근성, 에너지, 서빙 지연시간, 인프라 집중 문제가 커졌어요.

딥러닝 아이디어 자체는 1950년대 perceptron, 1980년대 backpropagation, LeCun의 CNN 연구 등 오래전부터 있었어요. 하지만 충분한 데이터, 계산 능력, 깊은 네트워크를 안정적으로 학습시키는 기술이 준비되지 않았기 때문에 오랫동안 제한적이었어요. 2012년의 혁명은 갑작스러운 발명이 아니라 AI Triangle 세 요소가 충분히 성숙한 결과였어요.

중간 정리: AI 역사는 “좋은 아이디어가 바로 성공한다”가 아니라 “아이디어, 데이터, 하드웨어, 프레임워크가 함께 준비될 때 도약한다”에 가까워요.

8. ML System Lifecycle과 Deployment

8.1 전통 소프트웨어 생명주기와의 차이

전통 소프트웨어는 명시적 코드가 행동을 정해요. 버전 관리, CI/CD, static analysis, deterministic testing이 강력하게 작동해요. 같은 입력에는 같은 출력이 기대되기 때문이에요.

ML 시스템은 데이터가 행동을 정해요. 코드는 그대로여도 훈련 데이터가 바뀌면 모델이 바뀌고, 운영 데이터가 바뀌면 성능이 바뀌어요. 따라서 코드 버전만 추적해서는 충분하지 않아요. 데이터 버전, 모델 버전, feature pipeline, evaluation set, serving configuration을 함께 관리해야 해요.

ML lifecycle은 선형이 아니라 순환 구조예요.

Data Collection
  → Data Preparation
  → Model Training
  → Model Evaluation
  → Model Deployment
  → Model Monitoring
  → 다시 Data Collection / Retraining

이 순환은 좋은 방향으로도, 나쁜 방향으로도 굴러갈 수 있어요.

• 좋은 데이터와 좋은 인프라가 있으면 더 나은 모델을 만들고, 더 나은 시스템이 더 좋은 데이터를 모으며, 개선이 누적돼요.
• 나쁜 데이터와 약한 인프라가 있으면 모델 성능이 떨어지고, 모니터링이 약해 문제를 놓치며, 개선이 어려워져요.

8.2 Deployment Spectrum

ML 시스템의 배포 환경은 cloud에서 TinyML까지 넓어요.

Cloud ML은 거대한 데이터센터에서 실행돼요. LLM, 추천 시스템, 대규모 검색 모델은 페타바이트급 데이터와 수많은 사용자 요청을 처리해요. 계산 자원은 강력하지만 비용, 운영 복잡도, 전력, 지연시간, 개인정보 문제가 중요해요.

TinyML은 마이크로컨트롤러와 임베디드 장치에서 실행돼요. 메모리와 전력은 극단적으로 제한돼요. 모델 크기, 연산량, 배터리 수명, 센서 신뢰성이 핵심 제약이에요.

Edge ML은 데이터가 생기는 곳 가까이에서 계산해요. 지연시간과 대역폭을 줄이고 개인정보를 보호할 수 있지만, 현장 장비 관리와 업데이트가 어려워져요.

Mobile ML은 스마트폰 같은 개인 기기에서 실행돼요. 개인화와 오프라인 사용이 가능하지만 배터리, 발열, 메모리, OS 자원 경쟁을 고려해야 해요.

Hybrid architecture는 클라우드, 엣지, 기기를 조합해요. 자율주행차는 차량 내부에서 실시간 판단을 하고, 클라우드에서 대규모 학습과 시뮬레이션을 수행해요. 음성 비서는 wake-word detection은 기기에서 처리하고, 복잡한 언어 이해는 클라우드로 보낼 수 있어요.

8.3 Deployment가 Lifecycle을 바꾸는 방식

배포 환경은 단순히 “어디서 실행하나”의 문제가 아니에요. 전체 생명주기의 모든 단계를 바꿔요.

• Performance: 지연시간이 중요한 시스템은 엣지 또는 임베디드를 선택할 수밖에 없어요.
• Resource management: 클라우드는 비용 최적화, 엣지는 고정 자원 최적화, 모바일은 배터리와 발열 최적화가 중요해요.
• Operational complexity: 분산된 기기 수천 개를 관리하려면 모델 버전, OTA 업데이트, rollback, telemetry 집계가 필요해요.
• Data governance: 개인정보와 데이터 주권 때문에 데이터를 중앙으로 모으지 못할 수 있어요.
• Maintenance: 클라우드는 A/B 테스트와 빠른 업데이트가 쉽지만 비용이 크고, 엣지와 임베디드는 업데이트가 어렵지만 지연시간과 개인정보 면에서 유리해요.

Model compression, federated learning, A/B testing, OTA updates 같은 기법은 배포 환경의 제약에서 나와요. 이 장의 핵심은 배포 결정이 모델 크기만이 아니라 데이터 수집, 학습 방식, 평가 지표, 배포 전략, 모니터링 가능성까지 연쇄적으로 바꾼다는 점이에요.

중간 정리: “어디에 배포할까요?”는 단순한 운영 선택이 아니라 모델, 데이터, 평가, 업데이트 방식을 모두 바꾸는 설계 결정이에요.

9. 실제 ML 시스템 사례

9.1 Waymo: hybrid, latency-critical, safety-critical 시스템

Waymo는 자율주행이라는 극단적으로 어려운 ML 시스템 사례예요. 차량은 LiDAR, radar, camera, GPS 등 다양한 센서에서 데이터를 수집해요. 한 차량이 시간당 약 1TB의 데이터를 만들 수 있고, 실제 주행 데이터와 대규모 시뮬레이션 데이터가 함께 사용돼요.

데이터 관점의 문제는 volume, heterogeneity, real-time processing이에요. 구조화 데이터와 비정형 이미지 데이터를 동시에 처리해야 하고, 센서마다 주기와 노이즈 특성이 다르며, 안전-critical 상황에서는 데이터 정제와 검증이 필수예요.

알고리즘 관점에서는 perception, prediction, planning이 결합돼요.

• Perception: 객체 탐지, 차선 인식, 보행자 추적
• Prediction: 다른 차량과 보행자의 미래 움직임 예측
• Planning: 안전하고 효율적인 주행 행동 결정

인프라 관점에서는 edge와 cloud가 모두 필요해요. 차량 안에서는 낮은 지연시간으로 실시간 추론을 해야 하고, 클라우드에서는 대규모 학습, 시뮬레이션, fleet-wide learning을 수행해요. 연결성, fault tolerance, 모델 배포, 지역별 모니터링도 중요해요.

Waymo 사례는 AI Triangle이 실제로 어떻게 작동하는지 보여줘요. 센서 선택은 데이터 품질과 비용을 바꾸고, 모델 선택은 차량 내 컴퓨팅 요구를 바꾸며, 인프라 제약은 가능한 알고리즘을 제한해요.

9.2 FarmBeats: edge, resource-constrained 시스템

FarmBeats는 농업 IoT 환경에서 작동하는 resource-constrained edge ML 사례예요. 네트워크 연결이 약하고, 장치 전력과 계산 능력이 제한되며, 현장 센서가 열악한 환경에 노출돼요.

따라서 이 시스템의 최적화 목표는 Waymo와 달라요.

• 복잡한 모델보다 작은 모델이 중요해요.
• 클라우드 전송보다 현장 처리가 중요할 수 있어요.
• 센서 신뢰성과 데이터 검증이 어려워요.
• 장치가 오랫동안 오프라인일 수 있어 업데이트 전략이 까다로워요.

9.3 AlphaFold: cloud, compute-intensive, accuracy-critical 시스템

AlphaFold는 단백질 구조 예측을 위한 cloud-based scientific ML 사례예요. Waymo처럼 지연시간이 절대적으로 중요한 것은 아니고, FarmBeats처럼 전력이 극단적으로 제한된 것도 아니에요. 핵심은 정확도와 대규모 계산 처리량이에요.

이 경우 시스템 문제는 대규모 데이터베이스 처리, TPU 기반 분산 학습, 실험적 ground truth와의 검증, 긴 학습 시간과 높은 비용 관리예요.

세 사례는 같은 ML 원리를 쓰더라도 배포 맥락에 따라 완전히 다른 시스템 구현이 필요하다는 점을 보여줘요.

중간 정리: Waymo, FarmBeats, AlphaFold는 각각 “빠른 판단”, “극단적 자원 제약”, “정확도와 계산 처리량”을 대표해요.

10. ML 시스템의 핵심 공학 도전

10.1 Data Challenges

데이터는 ML 시스템의 기반이에요. 하지만 현실 데이터는 지저분하고, 불완전하고, 불일치하며, 시간이 지나면 바뀌어요.

Waymo의 센서 데이터는 비, 눈, 빛 반사, 젖은 도로, 센서 노화, 센서 간 시간 동기화 문제에 영향을 받아요. 전통 소프트웨어에서는 잘못된 입력을 validation으로 걸러낼 수 있지만, ML 시스템에서는 현실의 애매함 자체가 입력이에요.

Scale도 핵심 문제예요. 페타바이트 데이터를 저장하는 것만으로는 부족해요. 데이터 품질 메타데이터, dataset versioning, lineage, training retrieval, labeling, privacy, drift detection이 함께 필요해요.

Data drift는 가장 중요한 위험 중 하나예요. 모델은 훈련 후 스스로 이해를 수정하지 않아요. 운영 중에는 훈련 때 배운 패턴을 적용할 뿐이에요. 따라서 분포가 바뀌면 모델은 낡은 규칙처럼 행동할 수 있어요. ML의 장점은 runtime adaptation이 아니라 retraining capacity에 있어요. 즉, 새 데이터를 모아 의도적으로 다시 학습하고 배포할 수 있는 공학적 절차가 있어야 해요.

10.2 Model Challenges

현대 ML 모델은 매우 복잡해요. GPT-3 같은 모델은 수천억 파라미터를 가지며, 학습과 추론에 막대한 계산 자원이 필요해요.

학습 과정에서도 많은 선택이 있어요.

• 모델 구조를 어떻게 잡을까요?
• 얼마나 오래 학습할까요?
• 어떤 optimizer와 learning rate를 쓸까요?
• overfitting을 어떻게 감지할까요?
• hyperparameter search 비용을 어떻게 관리할까요?
• 분산 학습 실패를 어떻게 복구할까요?

Transfer learning은 큰 변화를 만들었어요. 이미 큰 데이터로 학습된 모델을 특정 분야에 맞게 fine-tuning하면 데이터와 계산 비용을 줄일 수 있어요. 하지만 pre-trained model의 bias가 새로운 도메인으로 이전될 수 있고, 원래 데이터와 목표 도메인의 분포 차이도 고려해야 해요.

Generalization gap은 중심 문제예요. 훈련 데이터에서 99% 정확도를 내는 모델이 실제 운영에서는 75%만 낼 수 있어요. 안전-critical 또는 high-stakes 시스템에서는 이 차이를 줄이고 이해하는 것이 배포 가능성의 핵심이에요.

10.3 System Challenges

ML 시스템은 training system과 serving system이 모두 필요해요. 학습 시스템은 대규모 데이터를 읽고, 모델을 훈련하고, 실험을 관리해요. 서빙 시스템은 사용자 요청에 낮은 지연시간으로 예측을 제공해요. 두 시스템은 요구사항이 다르지만 feature definition, 모델 버전, 데이터 schema, 평가 지표를 공유해야 해요.

예를 들어 음성 인식 시스템은 오디오 수집, 저장, 전처리, 모델 학습, 실시간 추론, 사용자 피드백, 모델 업데이트가 모두 연결되어야 해요. 어느 한 부분의 병목이나 오류가 전체 성능을 떨어뜨릴 수 있어요.

운영 관점에서 중요한 질문은 다음과 같아요.

• 모델이 여전히 정확한지 어떻게 알 수 있을까요?
• 모델을 서비스 중단 없이 업데이트할 수 있을까요?
• 새 모델이 나빠지면 rollback할 수 있을까요?
• 예측이 이상해졌을 때 원인이 데이터인지 모델인지 인프라인지 구분할 수 있을까요?
• 수백만 사용자에게 동일한 품질과 latency를 제공할 수 있을까요?

10.4 Ethical Considerations

ML 시스템은 사회적 영향을 가져요. 공정성, 투명성, 개인정보, 안전은 부가 기능이 아니라 시스템 요구사항이에요.

Fairness 문제는 훈련 데이터의 역사적 편향이 모델 행동으로 이어질 때 나타나요. 채용 모델이 과거 채용 기록의 편향을 학습하면 특정 집단에 불리한 판단을 할 수 있어요. 이를 방지하려면 데이터와 모델 출력을 다양한 집단별로 감사해야 해요.

Interpretability 문제도 중요해요. 딥러닝 모델은 입력과 출력은 볼 수 있지만 내부 판단 과정을 이해하기 어려워요. 의료, 금융, 사법, 자율주행 같은 영역에서는 “왜 이런 결정을 했는가”를 설명할 수 있어야 해요.

Privacy 문제는 대규모 데이터 사용과 연결돼요. 모델이 민감한 훈련 데이터를 암기하거나, adversary가 inference attack으로 훈련 데이터 정보를 추출할 수 있어요. 따라서 differential privacy, federated learning, access control, privacy auditing 같은 방법이 필요해져요.

10.5 Challenge Interconnections

이 도전들은 서로 분리되어 있지 않아요.

• 데이터 품질 문제는 모델 성능 저하로 이어져요.
• 더 큰 모델은 latency, 비용, 전력 문제를 만들어요.
• 모델 단순화는 정확도나 공정성 문제를 만들 수 있어요.
• OTA 업데이트 실패는 윤리적 문제를 고친 새 모델 배포를 막을 수 있어요.
• 개인정보 제약은 데이터 중앙화를 어렵게 하고, 이는 학습 전략을 바꿔요.

따라서 ML 시스템 공학은 부분 최적화가 아니라 전체 최적화를 요구해요. 연구 논문에서 benchmark accuracy를 높이는 것만으로는 생산 시스템이 되지 않아요. 실제 시스템은 정확도, latency, 비용, privacy, fairness, maintainability, monitoring을 함께 만족해야 해요.

중간 정리: ML 시스템의 어려움은 문제들이 서로 얽혀 있다는 데 있어요. 데이터 문제는 모델 문제로, 모델 문제는 인프라 문제로, 인프라 문제는 윤리와 운영 문제로 번질 수 있어요.

11. AI Engineering의 정의

원문은 현대 조직이 AI를 만든다고 할 때, 실제로는 대부분 machine learning systems를 만든다고 설명해요. Netflix 추천 시스템, Waymo 자율주행, GPT-4 학습 모두 learning-based system이에요.

따라서 AI Engineering은 production intelligent systems를 만들고 운영하는 전체 lifecycle을 다루는 학문으로 정의돼요.

AI Engineering이 다루는 범위는 넓어요.

• 데이터 수집과 처리
• 대규모 분산 학습
• 하드웨어 효율화
• 모델 서빙과 latency 관리
• 운영 모니터링과 업데이트
• 에너지 효율과 지속 가능성
• 개인정보, 보안, 공정성, 안전

원문은 AI Engineering의 등장을 Computer Engineering의 등장에 비유해요. 컴퓨터 시스템이 복잡해지면서 Electrical Engineering과 Computer Science만으로는 충분하지 않아 Computer Engineering이 생겼어요. 마찬가지로 현대 AI는 알고리즘 연구와 하드웨어 개발만으로는 부족해요. 알고리즘, 데이터, 인프라, 운영, 윤리를 통합하는 새로운 공학 분야가 필요해요.

용어상 AI Engineering은 분야 이름이고, ML systems engineering은 그 분야에서 실제로 수행하는 작업을 가리켜요. 원문은 두 표현이 같은 문제 공간을 가리킨다고 봐요.

중간 정리: AI Engineering은 “AI 모델을 만드는 법”보다 넓어요. AI 시스템을 실제 세계에서 안전하고 효율적으로 운영하는 전체 공학이에요.

12. 다섯 기둥 프레임워크

이 책은 ML Systems Engineering을 다섯 개의 engineering disciplines로 조직해요. 길게 느껴지면 아래 표처럼 기억해도 좋아요.

12.1 Data Engineering

Data Engineering은 데이터 품질, 규모, versioning, drift detection, privacy-preserving data processing을 다뤄요.

Waymo 같은 시스템에서는 차량당 시간당 테라바이트 단위의 센서 데이터를 관리하고, 도시와 날씨별 분포 변화를 감지하며, 품질과 lineage를 유지해야 해요.

12.2 Training Systems

Training Systems는 큰 데이터와 복잡한 모델을 효율적으로 학습시키는 방법을 다뤄요.

여기에는 distributed training, parallelization, hyperparameter tuning, failure recovery, optimization algorithm, framework infrastructure가 포함돼요. Foundation model 학습에서는 수천 개 GPU 조율, gradient synchronization, checkpointing, 비용 관리가 핵심이에요.

12.3 Deployment Infrastructure

Deployment Infrastructure는 모델을 실제 환경에서 안정적으로 제공하는 방법을 다뤄요.

클라우드에서 초당 수많은 요청을 처리하는 model serving도 포함되고, 엣지와 온디바이스처럼 지연시간과 전력 제약이 강한 배포도 포함돼요. A/B testing, staged rollout, rollback, model serving architecture가 중요해요.

12.4 Operations and Monitoring

Operations and Monitoring은 ML 시스템의 조용한 성능 저하를 감지하고 대응하는 체계예요.

전통 모니터링은 uptime, latency, error rate에 집중하지만, ML 운영은 data quality, prediction distribution, model performance, business impact를 함께 추적해야 해요. Incident response와 production debugging도 이 기둥에 속해요.

12.5 Ethics and Governance

Ethics and Governance는 fairness, transparency, privacy, safety, sustainability를 시스템 lifecycle 전반에 통합해요.

Responsible AI는 배포 직전 체크리스트가 아니라 데이터 수집, 학습, 평가, 배포, 모니터링 전 과정의 요구사항이어야 해요. 안전-critical 시스템에서는 scenario-based testing, formal verification, bias mitigation, explainability, stakeholder engagement가 모두 중요해요.

13. AI Triangle, Lifecycle, Five Pillars의 연결

이 장에서 나온 프레임워크들은 서로 연결돼요.

이 구조는 AI가 algorithm-centric research에서 systems-centric engineering으로 이동했음을 보여줘요.

질문은 더 이상 “이 알고리즘이 작동하나요?”에 머물지 않아요. 핵심 질문은 “이 알고리즘을 데이터, 인프라, 운영, 윤리 제약 속에서 안정적으로 배포하고 유지할 수 있나요?”예요.

중간 정리: 다섯 기둥은 책의 목차이면서, 실제 ML 시스템을 점검하는 체크리스트이기도 해요.

14. 미래 방향

원문은 다섯 기둥이 안정적인 틀이지만, 분야 자체는 계속 진화한다고 봐요.

Agentic systems는 단순 예측을 넘어 계획하고 행동하는 시스템이에요. 이런 시스템은 더 강한 안전 제약, 데이터 품질, 모니터링, 윤리 체계가 필요해요.

Sustainability와 efficiency는 모델이 커질수록 중요해져요. Quantization, pruning, neural architecture search, efficient training, specialized hardware는 환경적 압력과 경제적 압력에서 나와요.

Heterogeneous computing은 클라우드 GPU, 데이터센터 TPU, 엣지 가속기, 모바일 NPU처럼 다양한 계산 장치가 함께 쓰이는 환경을 만들어요. 모델은 하나의 장소에서만 실행되지 않고, 조건에 따라 여러 계층에 분산될 수 있어요.

AI democratization은 pre-trained model, cloud API, AutoML로 더 많은 조직이 ML 시스템을 만들 수 있게 해요. 하지만 사용이 쉬워질수록 오히려 신뢰성 있는 시스템 공학의 중요성은 커져요. 전문 엔지니어가 상시 붙어 있지 않아도 안전하게 운영되는 체계가 필요하기 때문이에요.

중간 정리: AI가 더 강력하고 더 쉬워질수록, 그 AI를 책임 있게 운영하는 공학은 더 중요해져요.

15. Systems Knowledge의 성격

원문은 ML Systems Engineering이 순수 이론 분야와 다르다고 설명해요. 알고리즘 이론이나 복잡도 이론은 증명과 정리 중심이지만, ML 시스템 공학은 실제 구축, 배포, 운영에서 생기는 패턴과 trade-off를 다루는 practice이자 craft예요.

이 분야의 지식은 “항상 최적인 해법”을 증명하는 것보다 “이 맥락에서는 어떤 설계가 견고하게 작동할까요?”를 판단하는 능력에 가까워요.

예를 들어 다음 판단들이 중요해요.

• 정확도를 조금 낮추고 latency를 크게 줄일 가치가 있을까요?
• 데이터 품질 문제가 모델 구조 개선보다 더 큰 병목일까요?
• edge 배포가 privacy에는 좋지만 업데이트와 모니터링을 어렵게 만들지는 않을까요?
• 큰 모델을 API로 제공하는 것이 직접 배포보다 운영상 더 안전할까요?

따라서 이 책을 읽을 때는 세부 설정을 암기하기보다, 구성요소 간 관계와 trade-off 공간을 이해해야 해요.

중간 정리: 이 분야에서 중요한 것은 정답 암기가 아니라 “이 상황에서 무엇을 포기하고 무엇을 지킬까요?”를 판단하는 능력이에요.

16. 이 장 이후 책을 읽는 법

원문은 이후 장들을 다음처럼 배치해요.

• Foundation chapters: ML Systems, Deep Learning Primer, DNN Architectures
• Pillar chapters: Data Engineering, Training, ML Operations, Benchmarking, Privacy, Responsible AI 등
• Specialized topics: Sustainable AI, AI for Good, AGI Systems 등

Introduction 장은 이 모든 장의 공통 언어를 제공해요. 앞으로 어떤 장을 읽더라도 다음 질문을 계속 가져가면 돼요.

• 이 장은 AI Triangle의 어느 부분을 다루나요?
• 이 기술은 lifecycle의 어느 단계에 필요할까요?
• 이 선택은 deployment spectrum에서 어떤 제약을 해결하나요?
• 정확도, latency, 비용, 에너지, privacy, fairness 사이에 어떤 trade-off가 있나요?
• 이 기술은 조용한 성능 저하를 어떻게 감지하거나 완화하나요?

17. 자주 생기는 오해 정리

오해 1: AI는 좋은 모델 하나만 만들면 된다고 생각하기 쉬워요

조금 다르게 봐야 해요. 모델은 ML 시스템의 한 부분이에요. 데이터 수집과 품질, 학습 인프라, 배포, 모니터링, 업데이트, 윤리 요구사항이 모두 함께 설계되어야 해요.

오해 2: ML 모델은 배포 후에도 알아서 계속 배운다고 생각하기 쉬워요

대부분의 배포된 모델은 runtime에 스스로 학습 내용을 바꾸지 않아요. 운영 중에는 훈련 때 배운 패턴을 적용해요. 새 현실에 적응하려면 데이터를 모으고, 재학습하고, 평가하고, 다시 배포하는 절차가 필요해요.

오해 3: 서버가 정상이라면 ML 서비스도 정상이라고 생각하기 쉬워요

그렇게 단정하기 어려워요. 서버가 정상이어도 데이터 분포가 바뀌거나 예측 품질이 떨어질 수 있어요. ML 시스템은 인프라 상태와 모델 성능을 함께 감시해야 해요.

오해 4: 더 큰 모델은 항상 더 좋은 시스템이라고 생각하기 쉬워요

항상 그렇지는 않아요. 더 큰 모델은 정확도를 높일 수 있지만 latency, 비용, 전력, 메모리, 배포 난이도, 탄소 배출, privacy risk를 키울 수 있어요. 좋은 시스템은 목표와 제약에 맞는 균형을 찾아야 해요.

오해 5: 윤리는 기술을 만든 뒤 마지막에 점검하면 된다고 생각하기 쉬워요

마지막 점검만으로는 부족해요. 공정성, 개인정보, 안전, 설명 가능성은 데이터 수집부터 배포와 운영까지 전 과정에 들어가야 해요.

18. 대학교 수준 핵심 결론

마지막으로, Introduction 장의 핵심 명제는 다음과 같아요.

현대 AI의 본질은 learning-based computation이며, 그 성공은 데이터, 알고리즘, 인프라의 공동 설계에 달려 있어요. 전통 소프트웨어 공학은 명시적 코드와 결정적 실행을 중심으로 발전했지만, ML 시스템은 데이터 의존적이고 확률적이며 운영 중 조용히 성능이 저하될 수 있어요. 따라서 AI를 실제 사회와 산업에서 안정적으로 운영하려면 AI Engineering이라는 통합 공학 분야가 필요해요.

이 장에서 형성해야 할 최종 mental model은 하나예요.

현대 AI = 모델 하나가 아니라
데이터 + 알고리즘 + 인프라 + 생명주기 + 운영 + 윤리의 통합 시스템

이 관점이 잡히면 이후 장들의 세부 내용은 각각 이 큰 시스템의 한 부분으로 읽혀요. 이 장은 그래서 “암기할 내용”이라기보다, 앞으로 책 전체를 읽을 때 계속 다시 돌아오게 되는 지도에 가까워요.

복습 질문

1. AI와 ML의 차이를 체스 프로그램 예시로 설명할 수 있나요?
2. AI Triangle의 세 구성요소가 서로 어떻게 영향을 주는지 예시를 들 수 있나요?
3. 전통 소프트웨어의 실패와 ML 시스템의 silent degradation은 무엇이 다른가요?
4. Bitter Lesson이 왜 알고리즘보다 시스템 공학의 중요성을 강조하는지 설명할 수 있나요?
5. Symbolic AI, Expert Systems, Statistical Learning, Shallow Learning, Deep Learning의 차이를 한 문장씩 말할 수 있나요?
6. ML lifecycle이 왜 선형이 아니라 순환 구조인지 설명할 수 있나요?
7. Waymo, FarmBeats, AlphaFold는 각각 어떤 배포 제약을 대표하나요?
8. 데이터 드리프트가 발생하면 모델은 왜 자동으로 고쳐지지 않을까요?
9. AI Engineering의 다섯 기둥은 각각 어떤 문제를 해결하나요?
10. 모델 정확도만 높은 연구 결과가 production ML 시스템으로 바로 이어지지 않는 이유는 무엇일까요?