12. ML Systems 단계별 학습 문서

원문: sources/mlsysbook/12-ml_systems/source.md

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

처음 읽을 때는 모든 숫자와 하드웨어 이름을 외우려고 하지 않아도 돼요. 이 장의 핵심은 “AI 모델을 어디에서 실행하느냐가 시스템 전체를 바꾼다”는 감각을 잡는 것입니다.

1단계는 중학교 수준입니다. Cloud, Edge, Mobile, TinyML을 일상적인 비유로 이해해요.
2단계는 고등학교 수준입니다. 지연시간, 전력, 메모리, 비용 같은 제약이 어떤 선택을 만드는지 논리적으로 연결해요.
3단계는 대학교 수준입니다. 원문 장의 흐름을 따라가며 배포 패러다임, 물리적 제약, 하이브리드 구조, 의사결정 프레임워크까지 자세히 설명해요.

읽는 방법

이 장은 비교의 장이에요. 그래서 한 번에 모든 패러다임을 따로 외우기보다, 같은 질문을 네 번 반복해보면 좋아요.

이 환경에는 계산 능력이 얼마나 있나요?
얼마나 빨리 응답해야 하나요?
데이터가 밖으로 나가도 괜찮나요?
전력, 비용, 네트워크는 얼마나 제한되어 있나요?
이 시스템은 혼자 동작하나요, 아니면 다른 계층과 함께 동작하나요?

이 질문을 Cloud, Edge, Mobile, TinyML에 각각 적용하면 장 전체가 훨씬 선명해져요.

이 장의 한 줄 요약

ML 시스템은 모델이 똑같아도 어디에서 실행하느냐에 따라 완전히 다른 시스템이 돼요. Cloud는 강력하지만 멀고, Edge는 빠르지만 관리가 어렵고, Mobile은 개인적이고 오프라인에 강하지만 배터리와 발열이 문제이며, TinyML은 아주 작고 오래 버티지만 모델 복잡도가 크게 제한됩니다.

1단계: 중학교 수준

여기서는 배포 패러다임이라는 어려운 말을 잠깐 내려놓고, “AI가 사는 장소”라고 생각해볼게요.

1. AI는 어디에 사느냐에 따라 성격이 달라져요

같은 AI라도 실행되는 장소가 다르면 완전히 다른 성격을 가져요.

예를 들어 사진을 보고 고양이인지 강아지인지 맞히는 AI가 있다고 해볼게요. 이 AI를 아주 큰 데이터센터에서 돌릴 수도 있고, 공장 안의 작은 컴퓨터에서 돌릴 수도 있고, 스마트폰에서 돌릴 수도 있고, 작은 센서 칩에서 돌릴 수도 있어요.

겉으로는 모두 “AI가 사진을 판단한다”는 같은 일처럼 보이지만, 실제로는 전혀 다른 문제가 됩니다.

데이터센터에서는 큰 모델을 쓸 수 있지만, 인터넷을 오가느라 시간이 걸려요.
공장 안 컴퓨터에서는 빠르게 판단할 수 있지만, 설치와 관리가 필요해요.
스마트폰에서는 내 데이터를 밖으로 보내지 않아도 되지만, 배터리가 닳아요.
작은 센서에서는 몇 년 동안 배터리로 버틸 수 있지만, 아주 간단한 판단만 할 수 있어요.

그래서 이 장은 “AI 모델을 어디에 둘까요?”라는 질문을 다룹니다.

2. Cloud ML은 큰 연구실 같아요

Cloud ML은 아주 큰 연구실이나 거대한 중앙 주방처럼 생각하면 쉬워요.

많은 컴퓨터, 많은 저장공간, 강력한 GPU와 TPU가 모여 있어요. 그래서 아주 큰 모델을 학습하거나, 수많은 사용자의 데이터를 분석하거나, 복잡한 언어 모델을 실행하기 좋아요.

하지만 단점도 있어요. 내 기기에서 클라우드까지 데이터를 보내고 다시 결과를 받아와야 하므로 시간이 걸려요. 인터넷이 끊기면 쓸 수 없고, 민감한 데이터를 밖으로 보내야 할 수도 있어요.

Cloud ML은 이런 경우에 잘 맞아요.

큰 모델을 학습해야 할 때
수많은 데이터를 처리해야 할 때
응답이 몇백 밀리초 늦어져도 괜찮을 때
중앙에서 여러 사용자를 함께 처리하는 것이 효율적일 때

3. Edge ML은 현장에 있는 빠른 판단자예요

Edge ML은 클라우드까지 가지 않고, 데이터가 생기는 곳 가까이에서 AI를 실행하는 방식이에요.

공장 카메라가 불량품을 바로 찾아야 한다고 생각해보세요. 카메라 영상을 매번 클라우드로 보내면 늦을 수 있어요. 그 대신 공장 안에 있는 edge server나 IoT gateway가 바로 판단하면 훨씬 빠릅니다.

Edge ML은 이런 경우에 잘 맞아요.

아주 빠른 반응이 필요할 때
데이터를 외부로 보내기 어렵거나 보내면 안 될 때
네트워크가 불안정할 때
카메라, 센서, 기계가 많은 현장에서 바로 판단해야 할 때

대신 Edge ML은 여러 장소에 장비를 설치하고 업데이트해야 해서 관리가 어려울 수 있어요.

4. Mobile ML은 내 손 안의 개인 AI예요

Mobile ML은 스마트폰, 태블릿, 스마트워치 같은 개인 기기 안에서 AI를 실행하는 방식이에요.

예를 들어 얼굴 인식, 음성 명령, 키보드 자동완성, 사진 보정, 건강 모니터링 같은 기능이 여기에 들어가요. 데이터가 내 기기 안에 머물 수 있어서 개인정보 보호에 좋고, 인터넷이 없어도 동작할 수 있어요.

하지만 스마트폰은 배터리와 발열을 조심해야 해요. 너무 큰 모델을 오래 돌리면 기기가 뜨거워지고 배터리가 빨리 닳아요.

Mobile ML은 이런 경우에 잘 맞아요.

사용자 바로 옆에서 빠르게 반응해야 할 때
개인정보를 기기 밖으로 보내고 싶지 않을 때
오프라인에서도 동작해야 할 때
짧고 자주 실행되는 AI 기능이 필요할 때

5. TinyML은 아주 작은 센서 속 AI예요

TinyML은 마이크로컨트롤러 같은 아주 작은 장치에서 AI를 실행하는 방식이에요.

이 장치들은 스마트폰보다 훨씬 작고, 메모리도 아주 적고, 전력도 거의 쓰지 않아요. 대신 몇 달이나 몇 년 동안 배터리 하나로 버틸 수 있어요.

예를 들어 이런 일을 할 수 있어요.

기계가 이상하게 진동하는지 감지하기
숲속에서 특정 새소리를 감지하기
농장 토양 상태를 계속 확인하기
“Hey Siri” 같은 wake-word를 아주 낮은 전력으로 듣기

TinyML은 아주 똑똑한 AI라기보다, 아주 작은 곳에 심어놓는 간단하고 오래 버티는 판단 장치에 가까워요.

6. 실제 시스템은 보통 하나만 쓰지 않아요

현실의 좋은 ML 시스템은 한 가지 방식만 쓰지 않는 경우가 많아요.

음성 비서를 생각해볼게요.

작은 칩이 wake word를 계속 듣습니다.
스마트폰이나 스피커가 간단한 음성 처리를 합니다.
더 어려운 언어 이해는 클라우드가 처리합니다.

이렇게 여러 방식을 섞는 것을 Hybrid ML이라고 볼 수 있어요. 각 방식의 장점을 가져오고, 단점을 서로 보완하는 구조예요.

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

Deployment paradigm: ML 모델을 어디에서 실행할지에 대한 방식
Cloud ML: 데이터센터에서 큰 계산 자원으로 ML을 실행하는 방식
Edge ML: 데이터가 생기는 현장 가까이에서 ML을 실행하는 방식
Mobile ML: 스마트폰, 태블릿, 웨어러블에서 ML을 실행하는 방식
TinyML: 마이크로컨트롤러처럼 아주 작은 장치에서 ML을 실행하는 방식
Hybrid ML: 여러 배포 방식을 함께 섞어 쓰는 구조
Latency: 요청을 보내고 결과를 받기까지 걸리는 시간
Power wall: 더 빠른 칩을 만들수록 전력과 발열이 한계가 되는 문제
Memory wall: 계산보다 메모리에서 데이터를 가져오는 일이 병목이 되는 문제

2단계: 고등학교 수준

이제 조금 더 논리적으로 들어가 볼게요. 이 장은 “배포 환경이 시스템 설계를 결정한다”는 사실을 물리적 제약과 비용, 개인정보, 지연시간으로 설명합니다.

1. 이 장의 논리 흐름

ML 시스템은 데이터 + 알고리즘 + 인프라로 이루어져요
  ↓
그런데 인프라가 어디에 있느냐가 중요해요
  ↓
빛의 속도, 전력, 메모리, 비용은 마음대로 없앨 수 없어요
  ↓
그래서 Cloud, Edge, Mobile, TinyML이라는 배포 패러다임이 생겨요
  ↓
각 패러다임은 서로 다른 장점과 제약을 가져요
  ↓
현실 시스템은 여러 패러다임을 섞어 Hybrid 구조를 만들어요
  ↓
좋은 선택은 유행이 아니라 요구사항에서 나와야 해요

2. 왜 하나의 방식으로 모든 ML을 처리할 수 없을까요?

이유는 단순합니다. 물리 법칙과 하드웨어 제약이 있기 때문이에요.

첫째, 빛의 속도가 있어요. 데이터를 멀리 있는 클라우드까지 보내면 아무리 좋은 서버라도 왕복 시간이 생깁니다. 자율주행차가 급정거해야 하는 상황에서 100ms, 300ms를 기다릴 수는 없어요.

둘째, 전력과 발열이 있어요. 스마트폰이나 센서는 무한히 전기를 쓸 수 없어요. 계산을 많이 하면 배터리가 닳고 기기가 뜨거워집니다.

셋째, 메모리 대역폭이 있어요. 큰 모델은 파라미터를 계속 읽어와야 하는데, 실제 성능은 계산 속도보다 데이터를 옮기는 속도에 막힐 수 있어요.

넷째, 비용이 있어요. 클라우드는 처음 장비를 사지 않아도 되지만 계속 비용이 나가요. Edge나 TinyML은 장비를 설치해야 하지만, 장기적으로는 통신비와 클라우드 비용을 줄일 수 있어요.

3. 네 가지 배포 패러다임을 한눈에 보기

패러다임	가장 큰 장점	가장 큰 제약	잘 맞는 예시
Cloud ML	계산 능력이 매우 강해요	지연시간, 개인정보, 지속 비용	대규모 학습, 추천 시스템, LLM
Edge ML	현장 가까이에서 빠르게 판단해요	장비 설치와 분산 관리가 어려워요	공장 검사, 자율주행, 스마트 빌딩
Mobile ML	개인 기기에서 빠르고 사적으로 동작해요	배터리, 발열, 기기별 성능 차이	얼굴 인식, 음성 인식, 사진 보정
TinyML	매우 싸고 오래 버텨요	메모리와 모델 크기가 매우 작아요	센서, wake-word, 환경 모니터링

이 표에서 중요한 점은 “어느 하나가 항상 최고”가 아니라는 거예요. 요구사항이 다르면 좋은 선택도 달라집니다.

4. 지연시간을 기준으로 생각해보기

지연시간은 “얼마나 빨리 답해야 하나요?”라는 질문이에요.

느려도 괜찮아요 → Cloud ML 가능
100ms 안팎이 필요해요 → Edge 또는 Mobile이 유리
10ms 이하가 필요해요 → Edge, Mobile, TinyML을 고려
마이크로초 단위가 필요해요 → TinyML 또는 특수 하드웨어가 필요

예를 들어 영화 추천은 200ms 늦어도 큰 문제가 아닐 수 있어요. 하지만 로봇 팔이 사람과 부딪히기 전에 멈춰야 한다면 클라우드 왕복을 기다릴 수 없습니다.

5. 개인정보를 기준으로 생각해보기

데이터가 밖으로 나가면 안 되는 경우에는 로컬 처리가 중요해져요.

데이터를 외부로 보내도 괜찮아요 → Cloud 가능
민감하지만 일부 요약 정보는 보낼 수 있어요 → Edge 또는 Hybrid
데이터가 기기 밖으로 나가면 안 돼요 → Mobile 또는 TinyML

얼굴, 음성, 건강 데이터, 공장 내부 영상, 의료 정보는 모두 민감할 수 있어요. 이런 경우에는 정확도만 보고 클라우드를 선택하면 나중에 법적, 윤리적, 운영상 문제가 생길 수 있습니다.

6. 비용을 기준으로 생각해보기

비용은 한 번 내는 비용과 계속 내는 비용을 나눠서 봐야 해요.

Cloud ML: 초기 장비 구매는 적지만, 사용량이 늘수록 비용이 계속 늘어요.
Edge ML: 장비 설치 비용이 있지만, 장기적으로 네트워크와 클라우드 비용을 줄일 수 있어요.
Mobile ML: 사용자가 이미 가진 기기를 활용할 수 있어요.
TinyML: 장치 하나는 매우 싸지만, 개발과 유지보수에는 전문성이 필요해요.

그래서 좋은 비용 판단은 “지금 당장 무엇이 싼가요?”가 아니라 “전체 수명 동안 무엇이 합리적인가요?”에 가까워요.

7. 하이브리드 구조를 흐름도로 보기

음성 비서를 예로 들면 이런 구조가 됩니다.

TinyML
  wake word 감지
  ↓
Mobile 또는 Edge
  간단한 음성 인식과 명령 처리
  ↓
Cloud
  복잡한 자연어 이해와 큰 모델 추론
  ↓
Mobile 또는 Edge
  사용자에게 결과 전달

이 구조의 장점은 각 계층이 잘하는 일을 맡는다는 점이에요.

TinyML은 항상 켜져 있어도 전력을 적게 써요.
Mobile과 Edge는 빠르고 사적인 처리를 맡아요.
Cloud는 크고 복잡한 판단을 맡아요.

8. 고등학교 수준 결론

이 장의 핵심은 “ML 시스템 설계는 모델 선택보다 먼저 배포 환경을 이해해야 한다”는 거예요.

좋은 ML 시스템을 설계하려면 다음 질문을 먼저 던져야 해요.

응답은 몇 ms 안에 나와야 하나요?
데이터는 외부로 나가도 되나요?
네트워크가 끊겨도 동작해야 하나요?
전력과 발열 제약은 어느 정도인가요?
모델은 얼마나 커도 되나요?
이 시스템은 몇 년 동안 어떤 비용 구조로 운영되나요?
하나의 패러다임으로 충분한가요, 아니면 하이브리드가 필요한가요?

3단계: 대학교 수준

3단계에서는 원문 구조를 따라가며 자세히 살펴볼게요. 이번 장은 모델 구조보다 “운영 환경이 ML 시스템을 어떻게 바꾸는가”에 초점이 있어요.

1. Purpose: 배포 환경은 왜 ML 시스템의 본질을 바꿀까요?

이 장의 출발 질문은 “머신러닝이 실행되는 환경이 시스템의 성격을 어떻게 바꾸나요?”예요.

ML 시스템은 아주 다양한 환경에서 동작해야 해요. 클라우드 데이터센터, 공장 안의 edge server, 스마트폰, 웨어러블, 작은 마이크로컨트롤러까지 모두 ML을 실행할 수 있습니다. 하지만 이 환경들은 계산 능력, 전력, 메모리, 네트워크, 비용, 개인정보 조건이 완전히 달라요.

그래서 같은 모델 아이디어라도 배포 환경에 따라 다른 시스템이 됩니다.

Cloud에서는 큰 모델과 복잡한 preprocessing을 사용할 수 있어요.
Edge에서는 빠른 반응과 현장 처리가 중요해져요.
Mobile에서는 사용자 경험, 개인정보, 배터리, 발열이 핵심이에요.
TinyML에서는 모델 크기, 전력, 비용, 오랜 배터리 수명이 핵심이에요.

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

빛의 속도, power wall, memory wall이 왜 다양한 배포 패러다임을 필요하게 하는지 이해해요.
Cloud, Edge, Mobile, TinyML의 자원 특성과 적합한 use case를 구분해요.
계산 능력, 지연시간, 개인정보, 에너지 효율의 trade-off를 분석해요.
privacy, latency, computation, cost를 기준으로 배포 방식을 선택하는 프레임워크를 적용해요.
여러 패러다임을 결합한 hybrid ML architecture를 설계할 수 있어요.
흔한 배포 오해를 피하고, 시스템 요구사항에서 출발하는 결정을 내릴 수 있어요.

중간 정리: 이 장은 “모델을 어디서 실행할까요?”라는 질문이 사실상 “시스템 전체를 어떻게 설계할까요?”와 같다는 점을 보여줘요.

2. Deployment Paradigm Framework

이전 장에서는 ML 시스템을 데이터, 알고리즘, 컴퓨팅 인프라의 세 요소로 보았어요. 이 장은 여기에 아주 중요한 축을 하나 더 붙입니다. 바로 deployment environment, 즉 실행 환경이에요.

컴퓨터 비전 모델을 예로 들어볼게요. 같은 CNN 이미지 분류 모델이라도 환경에 따라 완전히 달라집니다.

클라우드 의료 영상 분석에서는 큰 모델 여러 개를 ensemble로 묶고, 복잡한 preprocessing을 할 수 있어요.
모바일 실시간 객체 탐지에서는 지연시간과 배터리를 줄이기 위해 모델을 작게 만들어야 해요.
공장 자동화에서는 정확도뿐 아니라 deterministic response time과 power efficiency가 중요해요.

이 차이는 알고리즘 자체보다 환경 제약에서 나오는 경우가 많아요. 그래서 이 장은 네 가지 주요 배포 패러다임을 체계적으로 나눕니다.

Cloud ML
Edge ML
Mobile ML
TinyML

각 패러다임은 다음 조건의 조합으로 결정돼요.

계산 자원이 얼마나 풍부한가요?
전력 소비를 얼마나 제한해야 하나요?
응답 지연시간은 어느 정도까지 허용되나요?
데이터가 외부로 이동해도 되나요?
네트워크 연결을 항상 기대할 수 있나요?
시스템 운영 비용 구조는 어떤가요?

현대 ML 시스템은 단순히 중앙 집중형 또는 분산형으로 나뉘지 않아요. 실제로는 여러 패러다임을 섞는 hybrid architecture가 점점 중요해지고 있어요.

예를 들어 음성 인식 시스템은 이렇게 나뉠 수 있어요.

TinyML: 초저전력 wake-word detection
Mobile ML: 간단한 음성 처리와 개인정보 보호
Cloud ML: 복잡한 자연어 이해

이런 다중 패러다임 구조는 좋은 ML 시스템이 단순히 모델 정확도만으로 설계되지 않는다는 점을 보여줍니다.

중간 정리: 배포 패러다임은 모델을 넣을 상자가 아니라, 모델 구조와 데이터 흐름과 운영 방식을 함께 결정하는 설계 축이에요.

3. The Deployment Spectrum: 물리 법칙이 만드는 배포 스펙트럼

원문은 배포 스펙트럼이 취향의 문제가 아니라 필요의 문제라고 설명해요. 이유는 물리적 제약이 있기 때문입니다.

3.1 Speed of Light: 클라우드는 아무리 빨라도 멀어요

클라우드는 강력하지만 멀리 있어요. 데이터가 사용자의 기기에서 클라우드 데이터센터까지 갔다가 다시 돌아와야 합니다.

빛은 매우 빠르지만 무한히 빠르지는 않아요. 광섬유 안에서도 왕복 지연시간은 생기고, 실제 인터넷에서는 라우팅, DNS, 서버 처리, 네트워크 혼잡까지 더해져요. 그래서 클라우드 왕복 지연시간은 수십 ms에서 수백 ms까지 커질 수 있습니다.

이것은 자율주행 긴급 제동, 산업용 로봇 제어, 의료 수술 보조처럼 sub-10ms 반응이 필요한 응용에는 치명적이에요. 이런 경우에는 계산을 데이터 가까이로 가져와야 합니다.

3.2 Power Wall: 더 빠른 칩은 더 뜨거워져요

Dennard scaling이 무너지면서 트랜지스터가 작아져도 전력 밀도가 예전처럼 줄어들지 않게 되었어요. 쉽게 말해, 칩을 계속 빠르게 만들면 전력과 발열이 한계가 됩니다.

이 문제는 모든 계층에서 나타나요.

데이터센터는 냉각에 큰 전력을 써야 해요.
스마트폰은 발열이 심해지면 thermal throttling으로 성능을 낮춰야 해요.
웨어러블과 센서는 배터리가 작기 때문에 더 엄격한 전력 제약을 받아요.

그래서 Mobile ML과 TinyML에서는 모델을 단순히 “돌아가게” 만드는 것만으로는 부족해요. 전력과 발열 안에서 지속적으로 동작해야 합니다.

3.3 Memory Wall: 계산보다 데이터 이동이 더 큰 병목일 수 있어요

현대 ML 모델은 많은 파라미터를 읽고, 중간 activation을 저장하고, 다시 불러와야 해요. 이때 실제 병목은 연산 장치의 이론적 FLOPS가 아니라 메모리 대역폭일 수 있습니다.

프로세서는 빠르게 계산할 수 있지만, 필요한 데이터를 제때 가져오지 못하면 기다려야 해요. 이것이 memory wall입니다.

큰 모델일수록 이 문제가 심해져요. 그래서 deployment paradigm을 고를 때는 단순히 “연산량이 몇 FLOPs인가요?”만 보면 안 돼요. 모델 크기, 메모리 접근 패턴, bandwidth, cache, storage hierarchy를 함께 봐야 합니다.

3.4 Economics of Scale: 비용 구조도 패러다임을 갈라요

클라우드 서버는 비싸지만 수많은 사용자가 나눠 쓸 수 있어요. 그래서 대규모 서비스에서는 per-user cost가 낮아질 수 있습니다. 반대로 응답시간 보장이나 개인정보 문제 때문에 자원을 공유하기 어렵다면 클라우드의 경제성이 줄어들 수 있어요.

작은 임베디드 칩은 개당 가격이 낮아서 수많은 위치에 배포할 수 있어요. 농장, 공장, 도시, 다리, 숲처럼 넓은 공간에 센서를 깔아야 할 때는 클라우드 연결보다 TinyML이 더 현실적일 수 있습니다.

중간 정리: Cloud, Edge, Mobile, TinyML은 유행어가 아니에요. 빛의 속도, 전력, 메모리, 비용이라는 제약이 만들어낸 필연적인 선택지예요.

4. Deployment Paradigm Foundations

원문은 네 가지 패러다임이 AI Triangle의 세 요소를 서로 다르게 최적화한다고 설명해요.

패러다임	데이터	알고리즘	인프라
Cloud ML	대규모 중앙 데이터	복잡한 모델 가능	강력하지만 멀어요
Edge ML	현장 데이터	중간 규모 모델	빠르지만 분산 관리가 필요해요
Mobile ML	개인 데이터	최적화된 모델	배터리와 발열 제약이 커요
TinyML	센서 데이터	매우 작은 모델	극단적 전력/메모리 제약이 있어요

Cloud ML은 풍부한 infrastructure로 algorithmic complexity를 밀어붙입니다. Mobile ML은 data locality와 user proximity를 중시해요. TinyML은 infrastructure가 극도로 제한되어 있으므로 algorithmic efficiency가 핵심이 됩니다.

여기서 중요한 점은 “인프라가 모델을 제한한다”는 거예요. 모델은 수학적으로 가능하다고 해서 아무 곳에나 배포할 수 없습니다. 메모리, 전력, latency, cost가 실제 가능성을 결정합니다.

5. Cloud ML: 계산 능력을 최대로 쓰는 패러다임

Cloud ML은 중앙집중형 인프라를 사용해 계산적으로 무거운 작업을 처리하는 방식이에요. 대규모 데이터 처리, 큰 모델 학습, 복잡한 inference, 협업형 모델 개발에 강합니다.

5.1 Cloud Infrastructure and Scale

Cloud ML의 핵심은 규모예요. Google TPU Pod, 대규모 GPU cluster, hyperscale data center 같은 인프라는 모바일이나 edge 장치와 비교할 수 없을 정도로 큰 계산 능력과 메모리 대역폭을 제공합니다.

이런 인프라는 다음 작업에 강해요.

수백 TB 이상 데이터 처리
수백 또는 수천 GPU를 이용한 distributed training
foundation model 학습
추천 시스템, 검색, 자연어 처리 같은 대규모 서비스
여러 팀이 공유하는 모델 개발과 실험 관리

Cloud API도 중요한 장점이에요. 한 번 학습한 모델을 API로 제공하면 모바일, 웹, IoT 서비스가 전 세계 어디서든 접근할 수 있습니다. Pay-as-you-go 모델 덕분에 처음부터 비싼 하드웨어를 사지 않아도 되는 장점도 있어요.

하지만 이 장점이 모든 문제를 해결해주지는 않아요. 클라우드는 강력하지만 멀고, 민감한 데이터를 외부로 보내야 할 수 있으며, 사용량이 늘수록 비용도 늘어납니다.

5.2 Cloud ML Trade-offs and Constraints

Cloud ML의 가장 큰 제약은 latency예요. 네트워크 왕복이 필요하기 때문에 real-time safety-critical application에는 부적합할 수 있어요.

또 다른 제약은 privacy와 compliance입니다. 의료, 금융, 생체 정보, 산업 기밀 데이터는 클라우드로 전송하는 것 자체가 규제나 보안 위험을 만들 수 있어요. GDPR, HIPAA 같은 규제 환경에서는 encryption, access control, audit trail, data deletion 같은 요구사항이 복잡해집니다.

비용도 중요해요. 클라우드는 초기 비용이 낮아 보일 수 있지만, inference 요청이 매일 수백만 건 발생하면 운영 비용이 빠르게 커질 수 있습니다. 사용량 spike도 예산 관리를 어렵게 만들어요.

또한 cloud provider의 API와 도구에 의존하면 vendor lock-in이 생길 수 있어요. 나중에 다른 제공자로 옮기려면 모델 배포, 데이터 파이프라인, 모니터링 체계를 다시 손봐야 할 수 있습니다.

5.3 Large-Scale Training and Inference

Cloud ML은 대규모 consumer-facing application에서 특히 강력해요.

예를 들어 Siri, Alexa 같은 virtual assistant는 많은 사용자 요청을 처리하고, 복잡한 자연어 처리를 수행하며, 다양한 언어 패턴에서 계속 개선됩니다. Netflix와 Amazon의 recommendation engine도 수많은 사용자 행동 데이터를 분석해 개인화된 추천을 만들어요.

금융권의 fraud detection도 좋은 예예요. 수많은 거래 데이터를 분석하고, 과거 사기 패턴을 학습해 이상 거래를 탐지합니다. 이런 작업은 데이터 규모와 모델 복잡도가 크기 때문에 클라우드가 잘 맞습니다.

중간 정리: Cloud ML은 “큰 계산”이 필요한 곳에 강해요. 하지만 latency, privacy, cost, network dependency 때문에 항상 정답은 아니에요.

6. Edge ML: 데이터 가까이에서 빠르게 판단하기

Edge ML은 Cloud ML의 한계를 보완하기 위해 등장했어요. 클라우드는 강력하지만 멀고, 민감한 데이터를 외부로 보내야 할 수 있어요. Edge ML은 계산을 데이터가 생기는 곳 가까이로 옮깁니다.

6.1 Distributed Processing Architecture

Edge device는 cloud와 mobile/tiny 사이의 중간 지점에 있어요. IoT gateway, edge server, industrial PC, smart camera, local appliance 등이 여기에 들어갈 수 있습니다.

Edge ML은 보통 다음 특징을 가져요.

cloud보다 훨씬 낮은 latency
mobile이나 tiny보다 큰 계산 능력
local processing을 통한 privacy 개선
네트워크 대역폭 절감
네트워크 장애 시에도 일정 수준의 동작 가능

예를 들어 1000개의 카메라 영상을 모두 클라우드로 보내면 uplink 비용과 bandwidth 부담이 매우 커집니다. 하지만 edge에서 영상을 처리하고 metadata나 event만 보내면 통신량을 크게 줄일 수 있어요.

6.2 Edge ML Benefits and Deployment Challenges

Edge ML의 가장 큰 장점은 latency 감소예요. 클라우드 왕복이 필요 없기 때문에 1-50ms 수준의 응답이 가능해질 수 있습니다. 자율주행, 산업용 로봇, 실시간 품질 검사처럼 빠른 반응이 필요한 시스템에 중요해요.

두 번째 장점은 bandwidth 절감입니다. 고해상도 영상이나 센서 스트림을 계속 클라우드로 보내지 않고, 현장에서 필요한 정보만 추출해 전송할 수 있어요.

세 번째 장점은 privacy예요. 원본 데이터를 외부로 보내지 않고 현장에서 처리하면 규제 대응과 보안 위험을 줄일 수 있습니다.

하지만 edge는 운영이 어려워요.

여러 지역의 장치를 업데이트해야 해요.
하드웨어 성능이 제각각일 수 있어요.
물리적으로 접근 가능한 장치라 tampering 위험이 있어요.
수천 대 edge device의 버전과 상태를 관리해야 해요.
초기 장비 설치 비용이 큽니다.

즉 Edge ML은 빠르고 사적인 처리를 가능하게 하지만, 분산 시스템 운영 능력이 필요해요.

6.3 Real-Time Industrial and IoT Systems

Edge ML은 산업 현장에서 특히 자주 등장해요.

자율주행차는 카메라, LiDAR, radar 데이터를 실시간으로 처리해야 해요. 이 데이터를 클라우드로 보내고 기다리는 것은 물리적으로 불가능합니다.

Amazon Go 같은 스마트 리테일 환경도 edge processing이 잘 맞아요. 수많은 카메라 영상을 모두 클라우드로 보내는 대신 매장 내 edge server가 고객 움직임과 상품 선택을 처리하면 bandwidth와 privacy 문제를 줄일 수 있습니다.

제조업에서는 불량 검사와 predictive maintenance가 핵심 사례예요. 카메라가 부품을 검사하고, 센서가 기계 진동을 분석해 고장을 예측합니다. 이때 수 ms 단위 판단이 생산성과 안전에 직접 영향을 줘요.

스마트 빌딩과 의료 시스템도 edge를 활용할 수 있어요. 빌딩 센서 데이터는 현장에서 빠르게 처리해 에너지 사용을 조절하고, 의료 데이터는 privacy를 지키면서 낮은 latency로 처리할 수 있습니다.

중간 정리: Edge ML은 “클라우드까지 기다리기엔 너무 늦고, 데이터를 밖으로 보내기엔 부담스러운” 상황에서 빛나요.

7. Mobile ML: 개인 기기 안의 AI

Mobile ML은 스마트폰, 태블릿, 스마트워치 같은 개인 기기 안에서 ML을 실행하는 방식이에요. Edge ML이 현장 인프라 중심이라면, Mobile ML은 사용자 바로 옆의 개인 기기 중심이라고 볼 수 있습니다.

7.1 Battery and Thermal Constraints

Mobile ML의 핵심 제약은 배터리와 발열이에요. 스마트폰은 클라우드 서버처럼 수백 와트를 쓸 수 없어요. 작은 배터리로 하루 종일 버텨야 하고, 손에 들고 쓰는 장치라 뜨거워지면 안 됩니다.

현대 스마트폰에는 CPU, GPU, NPU가 통합된 SoC가 들어가요. NPU는 신경망 연산을 빠르고 전력 효율적으로 처리하기 위해 설계된 전용 장치예요. TensorFlow Lite나 Core ML 같은 프레임워크는 이런 하드웨어를 활용해 모바일 inference를 최적화합니다.

하지만 제약은 여전해요.

모델 크기는 제한됩니다.
긴 시간 연속 실행하면 thermal throttling이 발생할 수 있어요.
배터리 사용량이 사용자 경험에 바로 드러나요.
Android처럼 기기 성능 차이가 큰 생태계에서는 여러 모델 variant가 필요할 수 있어요.

7.2 Mobile ML Benefits and Resource Constraints

Mobile ML의 장점은 사용자 가까이에 있다는 점이에요.

첫째, latency가 낮아요. 네트워크를 기다리지 않고 바로 추론할 수 있습니다. 얼굴 인식, 카메라 효과, 키보드 예측처럼 즉각 반응해야 하는 기능에 좋아요.

둘째, privacy가 좋아요. 얼굴, 음성, 키보드 입력, 건강 데이터 같은 민감한 정보를 기기 밖으로 보내지 않고 처리할 수 있어요.

셋째, offline functionality가 가능해요. 인터넷이 없어도 번역, 지도, 음성 명령, 이미지 처리 같은 기능 일부를 사용할 수 있습니다.

넷째, personalization에 유리해요. 사용자의 습관, 입력 패턴, 사진 취향, 건강 패턴을 기기 안에서 학습하거나 반영할 수 있습니다.

하지만 자원 제약은 분명해요. 클라우드 수준의 거대 모델을 그대로 올릴 수 없고, app store 승인과 platform-specific optimization도 고려해야 합니다.

7.3 Personal Assistant and Media Processing

Mobile ML의 대표 사례는 computational photography예요. 스마트폰 카메라는 단순히 렌즈로 사진을 찍는 장치가 아니라, 여러 ML pipeline을 거쳐 사진을 만들어내는 시스템입니다.

Portrait mode는 사람과 배경을 분리해요.
Night mode는 여러 장의 사진을 정렬하고 노이즈를 줄여요.
HDR과 super-resolution은 여러 정보를 합쳐 더 좋은 이미지를 만들어요.

음성 기능도 Mobile ML의 중요한 사례예요. Wake-word detection, 간단한 음성 명령, 키보드 예측, 실시간 번역은 사용자 가까이에서 빠르게 동작해야 합니다.

건강 모니터링도 중요해요. 스마트워치가 심박, 움직임, ECG 같은 데이터를 분석할 때, 민감한 건강 데이터를 기기 안에서 처리하면 privacy와 latency 면에서 유리합니다.

AR 기능도 mobile inference가 없으면 자연스럽게 동작하기 어려워요. AR은 카메라 영상에서 공간을 추적하고, 손과 얼굴 landmark를 추정하며, 60fps 수준으로 반응해야 하기 때문이에요.

중간 정리: Mobile ML은 “개인적이고 즉각적이며 오프라인에서도 동작해야 하는 AI”에 잘 맞아요. 대신 배터리와 발열이라는 벽을 항상 의식해야 해요.

8. TinyML: 아주 작은 장치 위의 지능

TinyML은 배포 스펙트럼의 가장 작은 끝에 있어요. 마이크로컨트롤러, 작은 센서, 아주 낮은 전력의 칩에서 ML을 실행합니다.

8.1 Extreme Resource Constraints

TinyML 장치는 스마트폰보다도 훨씬 작아요. RAM은 KB에서 몇 MB 수준일 수 있고, flash storage도 매우 작습니다. 전력은 mW 이하 수준을 목표로 할 수 있어요.

이런 극단적 제약 때문에 TinyML은 일반적인 딥러닝 배포와 매우 달라요.

모델은 수십 KB에서 수백 KB 수준이어야 할 수 있어요.
floating point 대신 integer quantization이 필요할 수 있어요.
training은 보통 장치 안에서 하지 않고, 미리 학습한 모델을 배포합니다.
디버깅에는 embedded toolchain, JTAG, oscilloscope 같은 지식이 필요할 수 있어요.

TinyML은 “작은 모바일 ML”이 아니에요. 문제 자체가 달라집니다.

8.2 TinyML Advantages and Operational Trade-offs

TinyML의 가장 큰 장점은 비용과 전력이에요. 장치 하나가 매우 싸고, 배터리 하나로 몇 달에서 몇 년까지 동작할 수 있습니다.

또 다른 장점은 latency예요. 데이터를 전송하지 않고 센서 바로 옆에서 판단하므로 마이크로초 단위 반응도 가능해요.

privacy도 매우 강해요. 데이터가 센서를 떠나지 않으면 네트워크 전송 중 유출될 위험 자체가 크게 줄어듭니다.

하지만 trade-off도 큽니다.

모델 정확도는 cloud나 mobile보다 낮을 수 있어요.
업데이트가 어렵고, 잘못된 firmware update는 장치를 망가뜨릴 수 있어요.
장치가 몇 년 동안 현장에 박혀 있을 수 있어 초기 설계가 매우 중요해요.
microcontroller vendor와 framework fragmentation 때문에 개발 난이도가 높아요.

8.3 Environmental and Health Monitoring

TinyML은 넓은 공간에 많은 센서를 깔아야 하는 분야에서 강력해요.

산업 predictive maintenance에서는 수천 개 진동 센서가 기계 상태를 계속 감시할 수 있어요. 기존 wired sensor보다 훨씬 싸게 설치할 수 있고, 고장 징후를 미리 감지해 downtime을 줄일 수 있습니다.

Wake-word detection도 TinyML의 대표 사례예요. 항상 듣고 있어야 하지만 전력 소모는 극히 낮아야 하므로 작은 모델이 적합합니다.

정밀 농업에서는 토양, 습도, 온도, 식물 상태를 넓은 지역에서 감시할 수 있어요. 모든 데이터를 클라우드로 보내는 대신, TinyML 장치가 현장에서 필요한 이벤트만 전송할 수 있습니다.

야생동물 보전이나 환경 모니터링에서도 TinyML이 유용해요. 숲속에 설치한 오디오 센서가 특정 동물 소리를 감지하고, 전체 오디오가 아니라 탐지 결과만 전송하면 통신 비용을 크게 줄일 수 있어요.

의료 wearable도 TinyML의 중요한 응용이에요. 작은 장치가 ECG나 움직임 데이터를 계속 분석하며, 낮은 전력으로 장시간 모니터링할 수 있습니다.

중간 정리: TinyML은 “작고 싸고 오래 버티는 AI”예요. 복잡한 사고보다, 현장에서 작고 빠른 판단을 수없이 많이 배치하는 데 강합니다.

9. Hybrid Architectures: 패러다임을 섞어 더 좋은 시스템 만들기

원문은 실제 production system이 하나의 패러다임에만 갇히는 경우가 드물다고 설명해요. 각 패러다임은 장단점이 뚜렷하기 때문에, 현실에서는 여러 계층을 섞는 hybrid architecture가 자주 등장합니다.

Cloud는 강력하지만 멀고, Edge는 빠르지만 관리가 어렵고, Mobile은 개인적이지만 배터리 제약이 있고, TinyML은 작고 싸지만 모델이 제한돼요. Hybrid ML은 이 장점들을 조합합니다.

9.1 Train-Serve Split

Train-serve split은 가장 흔한 hybrid pattern 중 하나예요.

Cloud에서 큰 데이터로 학습해요
  ↓
모델을 압축하고 최적화해요
  ↓
Edge, Mobile, Tiny 장치에서 inference를 실행해요

이 패턴은 cloud의 학습 능력과 local inference의 latency/privacy 장점을 함께 활용해요. 스마트홈 기기, 모바일 비전 모델, 공장 edge 모델에서 자주 나타납니다.

핵심은 학습과 서빙의 요구사항이 다르다는 점이에요. 학습은 큰 데이터와 큰 계산이 필요하지만, inference는 빠르고 싸고 안정적이어야 합니다.

9.2 Hierarchical Processing

Hierarchical processing은 여러 계층이 각자 자기 수준에 맞는 일을 처리하는 구조예요.

예를 들어 산업 IoT에서는 이렇게 나눌 수 있어요.

Tiny sensor: 간단한 이상 감지
  ↓
Edge server: 여러 센서 결과를 묶어 분석
  ↓
Cloud: 장기 분석, 모델 업데이트, 전체 최적화

이 구조는 데이터가 아래에서 위로 올라갈수록 더 요약되고, 분석은 점점 더 복잡해지는 방식이에요. 각 계층이 감당할 수 있는 계산에 맞춰 일을 나누는 것이 핵심입니다.

9.3 Progressive Deployment

Progressive deployment는 큰 모델을 여러 계층에 맞게 점진적으로 최적화하는 방식이에요.

예를 들어 같은 기능을 다음처럼 나눌 수 있어요.

Cloud version: 가장 크고 정확한 모델
Edge version: 지연시간과 비용을 줄인 모델
Mobile version: 배터리와 메모리에 맞춘 모델
Tiny version: 아주 작은 이벤트 감지 모델

Amazon Alexa 같은 시스템을 생각하면 쉬워요. Wake-word detection은 TinyML로, 간단한 명령은 edge나 local device로, 복잡한 언어 이해는 cloud로 보낼 수 있습니다.

하지만 이 방식은 운영 복잡도가 커요. tier마다 모델 버전이 다르고, update와 rollback을 조율해야 하며, connectivity loss 상황도 고려해야 합니다.

9.4 Federated Learning

Federated learning은 데이터를 중앙으로 모으지 않고, 각 기기에서 local training을 수행한 뒤 model update만 모으는 방식이에요.

예를 들어 키보드 입력 데이터를 생각해볼게요. 사용자가 입력한 문장을 서버로 보내지 않고, 스마트폰에서 local model update를 만든 뒤, 서버는 여러 update를 aggregation해 global model을 개선할 수 있어요.

이 방식은 privacy에 큰 장점이 있지만 운영은 어렵습니다.

기기가 언제 온라인일지 알 수 없어요.
배터리 상태가 다릅니다.
네트워크 품질이 다릅니다.
데이터 분포가 사용자마다 다릅니다.
differential privacy 같은 보호 장치가 필요할 수 있어요.

9.5 Collaborative Learning

Collaborative learning은 같은 계층의 장치들이 서로 정보를 나누는 방식이에요. 예를 들어 자율주행차들이 도로 상황이나 위험 정보를 직접 공유할 수 있습니다.

이 방식은 중앙 서버를 항상 거치지 않고도 빠르게 정보를 확산할 수 있다는 장점이 있어요. 다만 consistency, trust, security, communication overhead를 조심해야 합니다.

9.6 Production System Case Studies

실제 시스템은 위 패턴을 하나만 쓰는 것이 아니라 여러 개를 섞어요.

산업 defect detection에서는 cloud에서 여러 공장 데이터를 모아 vision model을 학습하고, edge server와 embedded camera에 최적화된 모델을 배포할 수 있습니다.

농업 monitoring에서는 soil sensor가 local anomaly를 감지하고, edge processor가 여러 센서 데이터를 묶어 분석하며, cloud가 장기 farm-wide analytics를 수행하고, mobile app이 농부에게 결과를 보여줄 수 있어요.

fitness tracker는 TinyML로 움직임을 계속 감지하고, smartphone과 sync한 뒤, cloud가 장기 추세를 분석할 수 있습니다.

중간 정리: Hybrid ML의 핵심은 “가장 강한 곳에 모든 일을 맡기기”가 아니라, “각 계층이 가장 잘하는 일을 맡게 하기”예요.

10. Shared Principles Across Deployment Paradigms

Cloud, Edge, Mobile, TinyML은 매우 달라 보이지만, 공통 원리는 있어요. 원문은 이를 세 층으로 설명합니다.

10.1 구현 계층

가장 위에는 실제 deployment paradigm이 있어요.

Cloud ML
Edge ML
Mobile ML
TinyML

각각 실행 장소, 하드웨어, 전력, 네트워크 조건이 다릅니다.

10.2 핵심 시스템 원리 계층

가운데에는 모든 패러다임에 공통으로 적용되는 원리가 있어요.

Data pipeline management
Resource management
System architecture principles

클라우드에서 페타바이트 데이터를 처리하든, TinyML에서 몇 KB 센서 데이터를 처리하든, 데이터 흐름을 관리해야 한다는 점은 같아요. 자원도 항상 제한되어 있어요. 단지 제한의 형태가 다를 뿐입니다.

10.3 시스템 고려사항 계층

가장 아래에는 실제 시스템 고려사항이 있어요.

Optimization and efficiency
Deployment, monitoring, updates
Security, privacy, reliability
Trustworthy AI

Cloud에서는 GPU cluster 효율화가 중요하고, Mobile에서는 thermal management가 중요하며, TinyML에서는 numerical precision과 quantization이 중요해요. 형태는 다르지만 “제약 안에서 성능을 최대화한다”는 목적은 같습니다.

이 공통 원리 덕분에 패러다임 간 기술이 이전될 수 있어요. Mobile optimization에서 얻은 아이디어가 cloud efficiency에 도움을 줄 수 있고, TinyML의 극단적 최적화 기술이 edge model compression에 영감을 줄 수 있습니다.

중간 정리: 네 패러다임은 겉모습은 다르지만, 모두 데이터 흐름, 자원 관리, 신뢰성, 최적화라는 같은 시스템 문제를 풀고 있어요.

11. Comparative Analysis and Selection Framework

이제 네 패러다임을 비교해볼게요.

11.1 계산 자원과 배포 위치

Cloud에서 TinyML로 갈수록 계산 능력, 저장공간, 전력 사용량은 크게 줄어듭니다.

Cloud → Edge → Mobile → TinyML
계산 능력: 많음 → 중간 → 제한적 → 극도로 제한적
지연시간: 큼 → 작음 → 작음 → 매우 작음
개인정보 보호: 약해질 수 있음 → 강해짐 → 강함 → 매우 강함
전력 사용: 큼 → 중간 → 작음 → 매우 작음

Cloud는 가장 큰 모델과 데이터를 다룰 수 있지만, latency와 privacy가 약점이에요. TinyML은 가장 작고 싸고 오래 버티지만, 복잡한 모델을 실행할 수 없어요. Edge와 Mobile은 그 사이에서 균형을 잡습니다.

11.2 Development Complexity

개발 난이도도 단순히 자원이 적을수록 높아지는 것이 아니에요.

Cloud는 분산 시스템, 비용 관리, 보안, scaling이 어려워요.
Edge는 수많은 현장 장치 관리와 orchestration이 어려워요.
Mobile은 iOS/Android 최적화와 기기 다양성이 어려워요.
TinyML은 embedded system, 메모리 관리, firmware, toolchain이 어려워요.

즉 “하드웨어가 강하면 쉽고, 작으면 어렵다”가 아니라, 각 패러다임마다 다른 어려움이 있습니다.

11.3 Accuracy만 보면 안 돼요

원문은 정확도만 보고 배포 방식을 고르는 것을 큰 함정으로 봐요.

예를 들어 cloud model이 99% 정확도를 내도 자율주행 긴급 제동에는 쓸 수 없을 수 있어요. 네트워크 지연시간이 반응 시간보다 길기 때문입니다.

반대로 edge model이 정확도가 높아도 mobile battery를 몇 분 만에 소모한다면 좋은 시스템이 아니에요.

좋은 deployment selection은 다음을 함께 봐야 해요.

Latency requirement
Power budget
Network reliability
Data privacy regulation
Total cost of ownership
Model accuracy
Operational complexity

중간 정리: 배포 선택은 “가장 정확한 모델을 어디에 올릴까요?”가 아니라 “요구사항 전체를 만족하는 시스템은 무엇일까요?”를 묻는 일입니다.

12. Decision Framework for Deployment Selection

원문은 deployment paradigm을 고를 때 계층적 decision framework를 사용하라고 설명해요. 유행이나 조직 취향이 아니라 application constraint에서 출발해야 합니다.

12.1 Privacy를 먼저 물어봐요

첫 질문은 이것이에요.

데이터가 기기 밖으로 나가도 되나요?

나가면 안 된다면 cloud-only deployment는 바로 제외될 수 있어요. 의료, 생체 정보, 개인 키보드 입력, 산업 기밀, 군사 정보 같은 데이터는 local processing이 필요할 수 있습니다.

12.2 Latency를 확인해요

두 번째 질문은 이것이에요.

응답이 sub-10ms 안에 나와야 하나요?

그렇다면 cloud는 물리적으로 어려울 가능성이 큽니다. Edge, Mobile, TinyML 또는 specialized local hardware를 고려해야 해요.

12.3 Computational Demand를 확인해요

세 번째 질문은 이것이에요.

이 작업은 큰 모델이나 무거운 계산이 필요한가요?

그렇다면 cloud나 edge가 필요할 수 있어요. Mobile이나 TinyML이 감당할 수 있는 모델인지, compression으로 충분한지 확인해야 합니다.

12.4 Cost Constraints를 봐요

마지막으로 비용 구조를 봅니다.

초기 장비 구매를 피하고 싶다면 cloud가 유리할 수 있어요.
장기적으로 수많은 요청이 발생한다면 edge나 on-device가 더 저렴할 수 있어요.
수십만 개 센서를 설치해야 한다면 TinyML이 경제적으로 현실적일 수 있어요.

12.5 Organizational Factors도 봐야 해요

기술 요구사항만으로는 충분하지 않아요. 조직이 그 패러다임을 운영할 능력이 있는지도 중요합니다.

Cloud ML은 distributed system과 cloud cost governance가 필요해요.
Edge ML은 device orchestration과 현장 운영 능력이 필요해요.
Mobile ML은 platform-specific optimization 능력이 필요해요.
TinyML은 embedded system 전문성이 필요해요.

아무리 기술적으로 좋은 선택이라도 팀이 유지보수할 수 없으면 production system으로는 위험해요.

중간 정리: 좋은 배포 결정은 privacy → latency → computation → cost → team capability 순서로 차분히 좁혀가는 과정이에요.

13. Fallacies and Pitfalls

이 장은 흔한 오해를 여러 개 짚어요. 이 부분은 실무적으로 특히 중요합니다.

13.1 “하나의 패러다임이면 충분해요”라는 오해

어떤 팀은 cloud만, edge만, mobile만 표준으로 정하려고 할 수 있어요. 하지만 모든 ML 문제를 한 방식으로 해결할 수는 없습니다.

실시간 로봇은 cloud latency를 견딜 수 없고, 큰 언어 모델은 TinyML 장치에 들어갈 수 없어요. 현실 시스템은 hybrid architecture가 필요한 경우가 많습니다.

13.2 “Edge는 항상 latency를 줄여요”라는 오해

Edge라고 해서 자동으로 빠른 것은 아니에요. Edge server가 느리거나, load balancing이 복잡하거나, edge device 사이 network hop이 많으면 cloud보다 느릴 수도 있어요.

Edge의 장점은 local processing time과 줄어든 network distance의 합이 cloud보다 작을 때 나타나요. 설계가 나쁘면 edge도 느립니다.

13.3 “Mobile은 최적화하면 어떤 모델이든 돌릴 수 있어요”라는 오해

모델 압축은 강력하지만 마법은 아니에요. 배터리 용량, 발열, 메모리, 지원 연산이라는 물리적 한계가 있습니다.

너무 큰 모델은 아무리 줄여도 mobile user experience를 망칠 수 있어요. 모바일에서는 accuracy뿐 아니라 battery, temperature, responsiveness가 함께 중요합니다.

13.4 “TinyML은 그냥 더 작은 Mobile ML이에요”라는 오해

TinyML은 mobile ML의 작은 버전이 아니에요. KB 단위 메모리, mW 이하 전력, firmware update 위험, embedded debugging이라는 완전히 다른 세계입니다.

TinyML에 맞는 문제는 복잡한 reasoning보다 단순하고 반복적인 local detection인 경우가 많아요.

13.5 “비용 최적화는 자원을 덜 쓰는 거예요”라는 오해

자원을 덜 쓰는 것이 항상 비용을 줄이는 것은 아니에요.

클라우드는 더 많은 compute를 쓰더라도 운영이 단순하고 자동 scaling이 가능해 전체 비용이 낮을 수 있어요. 반대로 edge나 tiny는 하드웨어 자원은 적게 쓰지만, 개발과 배포와 유지보수 비용이 커질 수 있습니다.

비용은 compute만이 아니라 개발 시간, 운영 복잡도, 장애 대응, 업데이트, 보안, 장기 유지보수를 포함해서 봐야 해요.

중간 정리: 배포 패러다임 선택에서 가장 위험한 태도는 “항상”이라는 말이에요. 항상 cloud가 좋지도, 항상 edge가 빠르지도, 항상 tiny가 싸지도 않습니다.

14. Summary: 이 장의 결론

이 장은 ML 시스템의 deployment context가 시스템 설계의 거의 모든 부분을 바꾼다는 점을 보여줘요.

Cloud ML은 대규모 학습과 복잡한 추론에 강하지만 latency, privacy, cost, network dependency를 고려해야 해요. Edge ML은 데이터를 현장 가까이에서 처리해 latency와 bandwidth를 줄이고 privacy를 높이지만, 분산 장치 관리가 어려워요. Mobile ML은 사용자 가까이에서 개인화되고 오프라인 가능한 AI를 제공하지만, 배터리와 발열 제약이 큽니다. TinyML은 극단적으로 낮은 비용과 전력으로 ubiquitous sensing을 가능하게 하지만, 모델 복잡도와 업데이트 유연성이 크게 제한돼요.

중요한 것은 resource constraint가 단순한 한계가 아니라 innovation driver가 된다는 점이에요. 자원이 부족하기 때문에 model compression, quantization, federated learning, train-serve split, hierarchical processing 같은 기술이 발전합니다.

이 장의 핵심 메시지는 다음과 같아요.

배포 환경은 알고리즘 선호보다 시스템 구조를 더 강하게 결정할 수 있어요.
자원 제약은 한계이면서 동시에 새로운 최적화 기회를 만들어요.
현실 production ML은 점점 hybrid architecture로 이동하고 있어요.
privacy와 latency 요구사항은 intelligence를 중앙에서 현장으로 밀어내고 있어요.
좋은 deployment decision은 정확도 하나가 아니라 전체 시스템 요구사항에서 출발해야 해요.

다음 장인 DL Primer는 이제 알고리즘 쪽으로 들어갑니다. 이 장에서 배운 배포 환경 관점을 가지고 다음 장을 읽으면, 신경망의 연산과 메모리 요구가 왜 deployment paradigm을 바꾸는지 더 잘 보일 거예요.

복습 질문

Cloud, Edge, Mobile, TinyML의 가장 큰 장점과 제약을 각각 설명할 수 있나요?
빛의 속도, power wall, memory wall이 왜 배포 패러다임을 나누게 만드는지 설명할 수 있나요?
Cloud ML이 항상 좋은 선택이 아닌 이유는 무엇일까요?
Edge ML이 Cloud ML보다 유리한 상황은 어떤 경우인가요?
Mobile ML에서 배터리와 발열이 왜 중요한 설계 조건이 되나요?
TinyML이 Mobile ML의 단순한 축소판이 아닌 이유는 무엇인가요?
Train-serve split과 hierarchical processing의 차이를 설명할 수 있나요?
Federated learning이 privacy에 유리하지만 운영상 어려운 이유는 무엇일까요?
배포 방식을 선택할 때 privacy, latency, computation, cost 중 무엇을 먼저 봐야 할까요?
“정확도가 가장 높은 모델”이 반드시 좋은 production ML 시스템이 아닌 이유는 무엇일까요?