31. Conclusion 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/31-conclusion/source.md

짧은 소개

이 장은 앞에서 다룬 ML 시스템 개념들을 하나의 관점으로 묶는 결론 장이에요. 핵심 메시지는 단순해요. 현대 AI의 성과는 모델 하나만 잘 만들어서 생기는 것이 아니라, 데이터 파이프라인, 학습 인프라, 하드웨어, 최적화, 운영, 보안, 책임성, 지속가능성이 함께 맞물릴 때 만들어진다는 점입니다.

그래서 이 장은 새로운 기술 하나를 깊게 파기보다, ML 시스템 엔지니어가 오래 가져가야 할 여섯 가지 공학 원리를 정리해요. 그리고 그 원리가 기술 기반, 대규모 성능, 실제 운영, 미래 AI 시스템에서 어떻게 반복해서 나타나는지 보여줘요.

읽는 방법

이 장은 결론이기 때문에 처음부터 문장을 하나씩 외우기보다, 먼저 큰 뼈대를 잡고 다시 세부로 내려가는 방식이 좋아요.

읽을 때는 다음 흐름을 계속 떠올리면 이해가 쉬워요.

측정해요 → 크게 커질 것을 예상해요 → 가장 막히는 부분을 찾아요 → 실패를 준비해요 → 비용을 계산해요 → 하드웨어와 소프트웨어를 함께 맞춰요

이 장의 한 줄 요약

ML 시스템 엔지니어링은 AI를 모델 하나가 아니라 여러 구성요소가 통합된 시스템으로 보고, 성능과 신뢰성뿐 아니라 비용, 보안, 사회적 책임까지 함께 설계하는 공학입니다.

1단계: 중학교 수준

AI는 혼자 일하는 천재가 아니라 팀이에요

AI를 한 명의 천재 학생이라고 생각하기 쉬워요. 하지만 이 장은 그렇게 보면 부족하다고 말해요. 실제 AI는 큰 팀에 더 가까워요.

데이터를 모으는 사람, 데이터를 정리하는 사람, 공부시키는 컴퓨터, 빠르게 답하게 도와주는 장비, 문제가 생기면 알려주는 감시 시스템, 나쁜 사용을 막는 안전장치가 모두 필요해요. 모델은 그중 눈에 가장 잘 보이는 한 부분일 뿐이에요.

좋은 AI 시스템은 식당 운영과 비슷해요

맛있는 메뉴 하나만 있어도 식당이 잘되는 것은 아니에요. 재료가 신선해야 하고, 주문이 몰려도 주방이 버텨야 하고, 손님에게 음식이 늦지 않게 나가야 해요. 전기가 나가거나 배달 주문이 폭주할 때도 대응 방법이 있어야 해요.

ML 시스템도 비슷해요.

이 장의 핵심은 “AI도 실제 세계에서 운영되는 서비스”라는 점이에요.

여섯 가지 원리를 쉬운 말로 바꿔볼게요

이 장이 말하는 “시스템 사고”란 무엇인가요?

시스템 사고는 한 부품만 보는 것이 아니라, 부품들이 서로 영향을 주고받는 모습을 보는 태도예요.

예를 들어 모델이 조금 더 똑똑해졌다고 해도 너무 느리거나, 너무 비싸거나, 휴대폰에서 돌아가지 않거나, 잘못된 답을 안전하게 막지 못하면 좋은 시스템이라고 말하기 어려워요.

그래서 ML 시스템 엔지니어는 늘 이런 질문을 해요.

• 데이터는 믿을 만한가요?
• 사용자가 많아져도 버틸 수 있나요?
• 어디가 가장 느린가요?
• 고장 나면 어떻게 되나요?
• 비용과 전력은 감당 가능한가요?
• 사용하는 장비와 알고리즘이 잘 맞나요?
• 사람과 사회에 도움이 되나요?

1단계 중간 정리

이 장은 “AI는 모델 하나가 아니라 많은 부품이 맞물린 큰 시스템”이라고 설명해요. 좋은 AI를 만들려면 정확도만 높이면 되는 것이 아니라, 측정, 확장, 병목, 실패, 비용, 하드웨어, 책임까지 함께 봐야 해요.

2단계: 고등학교 수준

블랙박스 안의 흐름을 조금 열어볼게요

1단계에서는 AI 시스템을 식당이나 팀으로 비유했어요. 이제는 조금 더 논리적으로 흐름을 볼게요.

ML 시스템은 대략 다음 순서로 움직여요.

데이터 수집 → 데이터 품질 확인 → 모델 학습 → 모델 최적화 → 하드웨어에 맞춘 실행 → 배포 → 모니터링 → 문제 발견 → 재학습 또는 복구

여기서 중요한 점은 한 번 만들고 끝나는 것이 아니라 계속 돌아가는 순환 구조라는 점이에요. 실제 세상에서는 데이터가 변하고, 사용자가 늘고, 공격이 생기고, 비용이 바뀌기 때문이에요.

여섯 원리를 논리 흐름으로 연결하기

이 장의 여섯 원리는 따로따로 외우는 목록이 아니라 하나의 판단 순서로 볼 수 있어요.

이 순서대로 생각하면 “모델 정확도를 조금 올릴까?” 같은 좁은 질문에서 벗어나, “실제 서비스로 오래 운영할 수 있을까?”라는 더 중요한 질문을 할 수 있어요.

간단한 수학으로 보는 병목

시스템 속도는 보통 가장 느린 부분에 크게 끌려가요. 아무리 다른 부분이 빨라도 한 구간이 막히면 전체가 느려져요.

아주 단순하게 쓰면 이렇게 생각할 수 있어요.

전체 처리 시간 = 데이터 준비 시간 + 모델 계산 시간 + 통신 시간 + 후처리 시간

이때 모델 계산 시간을 10% 줄였는데, 실제로는 통신 시간이 대부분을 차지하고 있다면 전체 속도는 별로 빨라지지 않아요. 그래서 이 장은 “먼저 병목을 찾아야 한다”고 강조해요.

예를 들어요.

10배 규모 설계는 여유를 만드는 일이에요

원문은 연구 환경에서 잘 작동한 시스템이 실제 트래픽을 만나면 쉽게 무너질 수 있다고 말해요. 그래서 현재 필요한 양만 보고 설계하지 말고, 데이터와 사용자와 계산량이 한 자릿수 더 커질 수 있다고 보고 준비해야 해요.

여기서 “10배”는 정확히 10이라는 숫자만 뜻한다기보다, 예상보다 훨씬 큰 변화에 대비하라는 공학적 태도예요.

비용도 성능의 일부예요

고등학교 수준에서 비용을 단순화하면 다음처럼 볼 수 있어요.

총비용 = 학습 비용 + 인프라 비용 + 데이터 준비 비용 + 운영 비용 + 장애 비용

모델이 조금 더 빠르더라도 운영비가 지나치게 높으면 좋은 선택이 아닐 수 있어요. 반대로 모델 크기를 줄이거나, 계산 정밀도를 낮추거나, 하드웨어에 맞게 연산을 바꾸면 매달 큰 비용을 절약할 수 있어요.

이 장은 성능을 “빠름”만으로 보지 않아요. 실제 운영에서는 빠름, 정확함, 비용, 전력, 안정성이 함께 성능이에요.

세 가지 적용 영역

원문은 여섯 원리가 세 영역에서 반복된다고 설명해요.

2단계 중간 정리

이 장의 논리는 이렇게 압축할 수 있어요.

좋은 ML 시스템은 측정 가능한 상태여야 해요. 측정한 뒤에는 10배 규모를 예상하고, 가장 큰 병목을 고치며, 실패를 대비하고, 비용을 계산하고, 하드웨어와 알고리즘을 함께 맞춰야 해요. 이 여섯 원리는 클라우드, 엣지, 모바일, 생성형 AI, AGI 같은 다양한 상황에서도 계속 반복돼요.

3단계: 대학교 수준

3.1 ML 시스템 엔지니어링의 종합: 구성요소에서 지능으로

원문은 현대 AI의 성과가 고립된 알고리즘 혁신에서 나오지 않는다고 말해요. 실제 성과는 계산 이론과 공학 실천이 결합될 때 생겨요. 즉, 지능은 단일 모델 내부에서만 생기는 것이 아니라 여러 시스템 구성요소의 통합 결과로 나타나요.

예를 들어 트랜스포머 구조는 대규모 언어 모델의 핵심 아키텍처로 중요해요. 하지만 트랜스포머라는 아이디어만으로 실제 서비스가 완성되지는 않아요. 대규모 데이터를 처리하는 파이프라인, 수많은 프로세서를 조율하는 분산 학습 인프라, 계산량을 줄이는 최적화 기법, 안정적인 운영 체계가 함께 있어야 해요.

원문은 이 관점을 “시스템 관점의 인공지능”으로 설명해요. GPT-4 같은 현대 AI 애플리케이션도 데이터 파이프라인, 분산 학습, 효율적 추론, 보안, 거버넌스가 결합된 결과로 이해해야 해요.

이 장이 던지는 세 가지 근본 질문

원문은 이 질문에 답하기 위해 여섯 가지 원리를 뽑아요. 포괄적 측정, 규모 지향 설계, 병목 최적화, 체계적 실패 계획, 비용 의식적 설계, 하드웨어 공동 설계가 그것이에요.

여기서 중요한 점은 이 원리들이 단순한 체크리스트가 아니라 의사결정 프레임워크라는 점이에요. ML 시스템 엔지니어는 매번 “정확도가 몇 퍼센트인가?”만 묻지 않고, “이 시스템이 커지고, 고장 나고, 공격받고, 비용 압박을 받아도 버틸 수 있는가?”를 함께 물어야 해요.

AGI로 확장될 때의 핵심 문제

원문은 AGI도 알고리즘만의 문제가 아니라고 봐요. AGI 수준의 시스템은 현재보다 훨씬 큰 계산량, 에너지 효율적 하드웨어, 새로운 분산 아키텍처, 거대한 인프라 투자를 요구할 수 있어요. 그래서 핵심 도전은 “새 알고리즘 하나를 찾는 것”이 아니라, 현재 ML 시스템 원리를 전례 없는 규모로 확장하는 일이에요.

3.2 ML을 위한 시스템 공학 원리

원리 1: 모든 것을 측정해요

측정은 최적화의 출발점이에요. 원문은 “측정하지 않는 것은 최적화할 수 없다”는 관점으로 ML 시스템의 모든 구성요소를 계측해야 한다고 설명해요.

측정은 세 가지 큰 역할을 해요.

원문에서 중요한 예시는 루프라인 분석입니다. 루프라인 분석은 연산 집약도와 최대 성능을 함께 보면서 시스템이 메모리 대역폭에 묶여 있는지, 계산 처리량에 묶여 있는지 알려줘요.

여기서 연산 집약도는 대략 “데이터를 한 번 가져올 때 얼마나 많은 계산을 하느냐”로 이해할 수 있어요. 연산은 많은데 메모리 접근이 적으면 계산 장치가 중요하고, 데이터를 계속 옮겨야 하면 메모리 대역폭이 중요해져요.

또 하나의 핵심은 재현 가능한 벤치마킹이에요. 최적화는 느낌으로 하면 안 돼요. 실제 병목이 아닌 곳을 고치면 시간만 쓰고 시스템은 거의 나아지지 않아요. 원문은 시스템이 보통 예상 부하에서는 잘 버티지만, 설계 가정을 훨씬 뛰어넘는 수요에서 실패한다고 강조해요.

원리 2: 10배 규모를 염두에 두고 설계해요

연구용 실험이 성공했다고 해서 운영 환경에서도 성공하는 것은 아니에요. 원문은 데이터, 사용자, 계산 요구가 현재보다 한 자릿수 이상 커질 수 있다고 보고 설계해야 한다고 말해요.

배포 환경별로 보면 요구가 달라져요.

하지만 규모만 키우는 것은 충분하지 않아요. 원문은 자원이 중요하지 않은 경로에서 낭비된다면 규모 확장 자체는 가치가 없다고 말해요. 그래서 10배 설계는 병목 최적화와 함께 생각해야 해요.

원리 3: 병목을 최적화해요

원문은 성능 개선의 큰 부분이 주된 제약 하나를 제대로 찾고 고치는 데서 나온다고 설명해요. 모든 부분을 조금씩 고치기보다 전체 시스템을 막는 가장 큰 제약을 찾아야 해요.

이 관점은 효율적 AI와 모델 최적화 기법을 하나로 묶어줘요. 가지치기, 양자화, 지식 증류 같은 기법도 결국 모델의 메모리, 계산, 에너지 병목을 줄이기 위한 방법이에요.

원리 4: 실패를 계획해요

운영 시스템은 실패한다고 가정해야 해요. 원문은 컴포넌트 고장, 네트워크 분리, 적대적 입력이 매일 발생할 수 있다고 말해요.

그래서 처음부터 다음 장치를 넣어야 해요.

서킷 브레이커는 전기 차단기와 비슷한 패턴이에요. 오류율이 기준을 넘으면 잠시 요청을 막아 실패한 서비스에 더 큰 부담을 주지 않아요. 이후 일정 시간이 지나면 다시 시도해 회복 여부를 확인해요.

원리 5: 비용을 의식해서 설계해요

원문은 모든 기술 결정에 경제적 의미가 있다고 말해요. 특히 대형 모델에서는 클라우드 GPU 비용만 해도 한 달에 수만 달러 수준으로 커질 수 있어요. 그래서 단순 성능이 아니라 총소유비용, 즉 TCO를 봐야 해요.

TCO에는 학습 비용, 인프라 비용, 데이터 준비 비용, 운영과 모니터링 비용, 규제 대응 비용, 장애 비용이 포함돼요. 모델이 조금 더 정확하더라도 운영비가 폭발적으로 늘어난다면 좋은 결정이 아닐 수 있어요.

이 원리는 지속가능성과도 연결돼요. 전력과 탄소 비용은 외부 문제가 아니라 설계 제약이에요. 효율화는 돈을 아끼는 동시에 환경 부담도 줄일 수 있어요.

원리 6: 하드웨어와 함께 설계해요

원문은 효율적인 AI 시스템이 알고리즘만 좋거나 하드웨어만 좋은 것으로 만들어지지 않는다고 설명해요. 알고리즘의 계산 패턴과 하드웨어의 강점이 맞아야 해요.

이 원리는 모바일과 엣지에서 특히 중요해요. 같은 모델이라도 어떤 하드웨어에서, 어떤 정밀도로, 어떤 메모리 접근 패턴으로 실행하느냐에 따라 실제 성능이 크게 달라져요.

3.3 세 가지 핵심 영역에 원리 적용하기

원문은 여섯 원리가 추상적 구호가 아니라 실제 기술 결정의 기준이라고 설명해요. 그리고 이를 세 영역으로 나누어 보여줘요.

영역 1: 기술적 기반 만들기

기술적 기반의 출발점은 데이터 엔지니어링이에요. 원문은 데이터 품질이 시스템 품질을 결정한다고 말해요. “데이터는 새로운 코드”라는 표현은 신경망에서 데이터가 사실상 프로그램의 행동을 결정한다는 뜻으로 이해할 수 있어요.

운영 시스템에서는 데이터가 조용히 변할 수 있어요. 스키마가 바뀌거나, 라벨 기준이 흔들리거나, 실제 사용자 분포가 학습 시점과 달라질 수 있어요. 그래서 데이터 거버넌스는 단순 관리 업무가 아니라 기술적 필요이자 윤리적 의무예요.

다음 기반은 프레임워크와 학습 시스템이에요. 원문은 TensorFlow의 운영 성숙도와 PyTorch의 연구 유연성 같은 절충을 언급해요. 프레임워크 선택은 개발 속도뿐 아니라 배포 제약에도 영향을 줘요.

분산 학습은 규모 설계와 하드웨어 공동 설계가 동시에 드러나는 영역이에요. 데이터 병렬화, 모델 병렬화, 혼합 정밀도, 그래디언트 압축은 모두 단일 머신을 넘어 학습을 확장하면서 하드웨어 능력을 더 잘 쓰기 위한 방법이에요.

마지막으로 효율성과 최적화가 기술 기반의 중요한 축이에요. 가지치기, 양자화, 지식 증류는 각각 불필요한 파라미터, 과도한 정밀도, 너무 큰 모델이라는 병목을 줄이는 방식이에요. 원문은 효율성이 실험실 밖의 자원 제약 환경으로 AI를 이동시키는 조건이라고 봐요.

영역 2: 대규모 성능 엔지니어링

기술 기반이 “작동하는가?”에 답한다면, 대규모 성능 엔지니어링은 “수백만 사용자에게도 효율적으로 작동하는가?”에 답해요.

모델 아키텍처와 최적화

원문은 단순 퍼셉트론, 합성곱 네트워크, 트랜스포머로 이어지는 모델 아키텍처의 발전을 언급해요. 하지만 아키텍처 혁신만으로는 운영 배포가 어렵다고 말해요. 실제 배포에서는 모델 최적화가 연구 아키텍처와 운영 제약 사이를 이어줘야 해요.

세 가지 압축 접근은 병목 최적화와 하드웨어 공동 설계를 잘 보여줘요.

원문은 Deep Compression 파이프라인을 예로 들어요. 가지치기, 양자화, 코딩을 결합하면 큰 압축 효과를 얻을 수 있어요. 또한 연산자 퓨전은 여러 연산을 하나로 묶어 메모리 대역폭 부담을 줄여요. 예를 들어 합성곱, 배치 정규화, 활성화 함수를 따로따로 실행하면 중간 결과를 메모리에 여러 번 저장하고 읽어야 하지만, 이를 결합하면 데이터 이동을 줄일 수 있어요.

MobileNets 같은 효율적 아키텍처도 같은 메시지를 보여줘요. 모바일이라는 제약 때문에 계산을 크게 줄이는 구조가 나왔고, 이런 제약 기반 혁신은 다른 환경에도 영향을 줘요.

하드웨어 가속과 시스템 성능

원문은 GPU, TPU, FPGA를 대표적인 가속 하드웨어로 제시해요.

하지만 하드웨어를 고르는 것만으로 충분하지 않아요. 소프트웨어 최적화도 하드웨어 능력에 맞아야 해요. 커널 퓨전, 연산자 스케줄링, 정밀도 선택은 정확도와 처리량 사이의 균형을 조정해요.

벤치마킹은 성능 엔지니어링의 피드백 루프예요. MLPerf 같은 표준 벤치마크는 학습과 추론 성능을 공정하게 비교할 수 있게 해요. 벤치마크가 있어야 “이 하드웨어가 정말 빠른가?”, “어떤 배포 대상이 비용 대비 좋은가?”, “최적화가 실제로 효과가 있었는가?”를 데이터로 판단할 수 있어요.

영역 3: 실제 운영 현실 통과하기

원문은 실제 운영에서는 여섯 원리가 한꺼번에 만난다고 말해요. 시스템은 사용자에게 안정적으로, 안전하게, 책임 있게 서비스를 제공해야 해요.

MLOps는 모델 개발을 장인식 수작업에서 산업적 소프트웨어 엔지니어링으로 바꾸는 역할을 해요. 지속적 통합, 품질 게이트, 배포, A/B 테스트, 모니터링, 거버넌스가 전체 수명주기를 조율해요.

엣지 배포는 여러 원리의 충돌을 잘 보여줘요. 데이터를 기기 안에 두면 프라이버시에 유리할 수 있지만, 기기 성능과 지연 시간 제약이 커져요. 네트워크가 끊겼을 때는 기능을 줄이더라도 안전하게 동작해야 해요.

보안과 프라이버시는 ML 시스템의 고유한 취약점을 드러내요.

책임 있는 AI와 지속가능성은 비용 의식의 범위를 넓혀요. 공정성 지표와 설명 가능성 요구는 아키텍처 선택 초기부터 영향을 줘야 해요. 또한 원문은 대형 모델 학습의 전력 비용을 언급하며, 환경 영향이 설계 제약이 되어야 한다고 강조해요. 특히 수십억 대 스마트폰에서 작동하는 모델의 효율 개선은 데이터센터 최적화보다 더 큰 누적 효과를 낼 수 있어요.

이 영역의 결론은 분명해요. 기술적으로 뛰어난 모델만으로는 충분하지 않아요. 운영 성숙도, 보안 방어, 윤리 프레임워크, 환경 책임이 함께 통합되어야 지속적인 가치를 만들 수 있어요.

3.4 미래 방향과 새 기회

원문은 앞의 세 영역을 바탕으로, 여섯 원리가 미래 환경에서 어떻게 시험받는지 설명해요.

새 배포 환경에 원리 적용하기

클라우드에서는 높은 처리량과 확장성이 중요해요. GPU를 놀리지 않으려면 커널 퓨전, 혼합 정밀도 학습, 그래디언트 압축 같은 기법이 필요해요. 동시에 큰 규모에서는 비용도 함께 최적화해야 해요.

모바일과 엣지는 데이터센터보다 계산 능력이 훨씬 작아요. 원문은 이런 기기들이 100배에서 1000배 적은 계산 자원을 가진다고 설명해요. 그래서 깊이별 분리 합성곱, 신경망 아키텍처 탐색, 양자화 같은 효율 기법이 중요해져요. AI가 전 세계 수십억 대 기기에서 돌아가려면 이런 최적화가 접근성을 좌우해요.

생성형 AI는 기존 원리를 전례 없는 규모로 밀어붙여요. 자동회귀 방식의 계산, 동적 모델 분할, 추측 디코딩 같은 접근은 측정, 최적화, 공동 설계 원리가 새 기술에도 그대로 적용된다는 것을 보여줘요.

TinyML과 임베디드 시스템은 더 극단적이에요. 메모리는 킬로바이트 단위이고, 전력은 밀리와트 수준이며, 배포 수명은 10년 이상일 수 있어요. 이런 환경에서는 실제 병목을 정확히 측정하고, 하드웨어에 맞춰 설계하며, 고장과 자원 고갈을 미리 계획해야 해요.

강건한 AI 시스템 만들기

원문은 강건성이 처음부터 실패를 염두에 둔 설계라고 설명해요. ML 시스템은 전통적 소프트웨어와 다른 실패 모드를 가져요.

이에 대응하려면 중복 하드웨어, 앙상블, 불확실성 정량화가 필요해요. 앙상블은 하나의 모델에 모든 판단을 맡기지 않게 해주고, 불확실성 정량화는 모델이 자신 없는 상황에서 조심스럽게 행동하도록 도와요. AI가 더 자율적인 역할을 맡을수록 실패 계획은 선택이 아니라 안전 배포의 조건이 돼요.

사회적 이익을 위한 AI

원문은 의료, 기후 과학, 교육, 접근성 같은 영역에서 AI의 가능성을 언급해요. 이때도 여섯 원리가 모두 모여요.

원문은 기술적 탁월함만으로 충분하지 않다고 말해요. 사회적 문제를 다루려면 기술자, 도메인 전문가, 정책 입안자, 영향을 받는 공동체가 함께 협력해야 해요.

AGI로 가는 길

원문은 고급 지능 시스템의 청사진으로 복합 AI 시스템을 제시해요. 복합 AI 시스템은 하나의 거대한 모델에 모든 것을 맡기기보다, 여러 특화된 구성요소를 결합하는 구조예요.

이 구조에는 몇 가지 장점이 있어요.

원문은 AGI로 가는 길에서도 알고리즘 돌파구보다 전체 스택의 숙련이 중요하다고 말해요. 데이터 엔지니어링, 분산 학습, 모델 최적화, 운영 인프라가 모두 필요하기 때문이에요. 결국 AGI에 가까운 시스템도 시스템 공학 원리를 피해갈 수 없어요.

3.5 앞으로의 여정: 지능을 공학적으로 만들기

마지막 절은 독자에게 ML 시스템 엔지니어로서의 관점을 제시해요. 원문은 GPT-4 같은 시스템도 신경망 아키텍처 하나로 설명할 수 없다고 말해요.

GPT-4의 성공을 시스템 관점에서 보면 다음 요소들이 함께 필요해요.

원문은 여섯 원리가 특정 기술보다 오래간다고 강조해요. 프레임워크가 바뀌고, 하드웨어가 발전하고, 새 아키텍처가 등장해도 측정, 확장, 병목, 실패, 비용, 공동 설계라는 판단 기준은 계속 남아요.

하지만 기술 원리만으로는 충분하지 않아요. 원문은 AGI가 올 것인가보다 “잘 만들어질 것인가”가 중요하다고 말해요. 잘 만들어진다는 것은 더 많은 사람이 접근할 수 있을 만큼 효율적이고, 악용에 버틸 만큼 안전하고, 지구 환경을 해치지 않을 만큼 지속가능하고, 모든 사람에게 공정하게 기여할 만큼 책임 있게 설계된다는 뜻이에요.

따라서 ML 시스템 엔지니어의 성공 지표는 지연 시간 감소나 정확도 향상에만 있지 않아요. 실제로 삶을 개선했는지, 중요한 문제를 해결했는지, 더 많은 사람에게 능력을 열어주었는지도 함께 봐야 해요.

3단계 최종 정리

이 장의 전공 수준 메시지는 다음과 같아요.

복습 질문

1. 원문이 현대 AI 성과를 “고립된 알고리즘 혁신”이 아니라 “시스템 통합”의 결과로 보는 이유는 무엇인가요?
2. “모든 것을 측정하라”는 원리가 데이터 엔지니어링, 벤치마킹, 운영 모니터링에서 각각 어떻게 다르게 나타나나요?
3. 10배 규모 설계가 클라우드, 엣지, 임베디드 환경에서 각각 어떤 의미를 가지나요?
4. 병목 최적화에서 먼저 “무엇이 가장 큰 제약인가”를 찾아야 하는 이유는 무엇인가요?
5. ML 시스템의 실패 모드는 전통적 소프트웨어 장애와 어떻게 다를 수 있나요?
6. 총소유비용을 고려하면 모델 선택이나 배포 방식이 어떻게 달라질 수 있나요?
7. 하드웨어-소프트웨어 공동 설계가 모바일과 엣지 배포에서 특히 중요한 이유는 무엇인가요?
8. MLOps가 단순 배포 자동화를 넘어 전체 수명주기 관리로 이해되어야 하는 이유는 무엇인가요?
9. 차등 프라이버시, 연합 학습, 적대적 학습은 각각 어떤 위험에 대응하나요?
10. 사회적 이익을 위한 AI에서 기술자만이 아니라 도메인 전문가, 정책 입안자, 영향을 받는 공동체가 함께 필요하다는 말은 어떤 뜻인가요?
11. 복합 AI 시스템이 단일 거대 모델보다 해석 가능성과 안전성 측면에서 유리할 수 있는 이유는 무엇인가요?
12. 이 장의 결론에 따르면, 좋은 ML 시스템 엔지니어는 기술 성능 외에 어떤 성공 기준을 함께 봐야 하나요?