29. AI for Good 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/29-ai_for_good/source.md

짧은 소개

이 장은 AI를 사회적 문제 해결에 쓰려면 무엇을 다르게 설계해야 하는지 설명해요. 핵심은 “좋은 목적”만으로는 충분하지 않다는 점입니다. 농업, 의료, 재난 대응, 환경 보전처럼 사람들의 삶과 직접 연결된 현장에서는 전기, 인터넷, 장비, 데이터, 유지보수 인력이 모두 부족할 수 있어요.

그래서 이 장은 AI for Good을 단순한 응용 사례 모음이 아니라, 가장 어려운 환경에서도 신뢰할 수 있는 ML 시스템을 만드는 공학 문제로 다룹니다.

읽는 방법

처음부터 모든 수치와 패턴을 외우려고 하지 말고, 세 번에 나누어 읽어보면 좋아요.

추천 흐름은 다음과 같아요.

서론과 요약을 먼저 읽어요
-> 사회 문제와 실제 사례를 봐요
-> 자원 제약을 숫자로 확인해요
-> 네 가지 설계 패턴을 비교해요
-> 각 패턴의 구조, 장점, 한계를 자세히 읽어요
-> 마지막으로 실패 사례와 이론적 배경을 복습해요

이 장의 한 줄 요약

AI for Good은 AI를 좋은 곳에 쓰는 구호가 아니라, 전력ㆍ네트워크ㆍ데이터ㆍ유지보수가 부족한 환경에서도 신뢰성, 안전성, 지속가능성, 지역사회 소유권을 함께 만족시키는 ML 시스템 설계 문제예요.

1단계: 중학교 수준

1. AI for Good은 “도움이 되는 AI”예요

AI for Good은 농부가 작물 병을 빨리 알아차리게 돕고, 의사가 없는 곳에서 진단을 보조하고, 홍수나 산불 같은 재난을 더 빨리 알려주고, 야생동물과 숲을 보호하는 데 AI를 쓰는 일이에요.

쉽게 말해, AI를 “편리한 추천 앱”이 아니라 “꼭 필요한 도움을 멀리까지 전달하는 도구”로 쓰는 거예요.

2. 그런데 가장 필요한 곳일수록 조건이 어렵습니다

도움이 가장 필요한 곳은 오히려 인터넷이 약하고, 전기가 자주 끊기고, 비싼 장비를 쓰기 어렵고, 전문가가 멀리 있을 수 있어요.

도시의 병원이라면 큰 컴퓨터와 빠른 인터넷을 쓸 수 있지만, 외딴 진료소에서는 작은 태양광 패널과 오래된 휴대폰만 있을 수도 있어요. 숲속 감시 장비는 배터리를 자주 갈 수 없고, 농부의 휴대폰은 항상 인터넷에 연결되어 있지 않을 수 있어요.

이 장에서 말하는 가장 중요한 역설은 바로 이것이에요.

도움이 가장 필요한 곳
-> AI를 돌릴 자원은 가장 부족한 곳

3. AI는 전문가를 “복사해서 데려오는 도구”처럼 쓰일 수 있어요

AI가 현장에서 중요한 이유는 전문가가 항상 직접 갈 수 없기 때문이에요.

농부가 작물 사진을 찍으면 AI가 병을 알려줄 수 있어요. 보건 요원이 아이의 기침 소리를 기록하면 AI가 폐렴 가능성을 알려줄 수 있어요. 숲속 센서가 총소리와 비슷한 소리를 듣고 감시원에게 알릴 수 있어요.

이때 AI는 완벽한 전문가가 아니라, 멀리 있는 전문가의 판단을 작은 기계 안에 일부 담아두는 도구처럼 볼 수 있어요.

4. 좋은 AI는 “작고, 오래가고, 끊겨도 버티는” AI예요

사회적 현장의 AI는 멋진 기능보다 생존력이 더 중요할 때가 많아요.

5. 네 가지 설계 방식은 생활 속 방식으로 이해할 수 있어요

6. 기술보다 먼저 물어야 하는 질문이 있어요

이 장은 “우리가 만들 수 있는가?”보다 “현장에서 실제로 도움이 되는가?”를 먼저 묻습니다.

예를 들어 정확도가 높은 의료 AI라도, 현지 언어로 설명하지 못하거나 인터넷이 없으면 쓸 수 없어요. 농업 AI가 좋아 보여도, 농부들이 실제로 걱정하는 문제가 아니라면 사용되지 않을 수 있어요.

그래서 AI for Good에서 중요한 질문은 다음과 같아요.

누구의 문제인가요?
그 사람들이 정말 원하나요?
전기와 인터넷이 없어도 되나요?
현지 사람이 고치고 운영할 수 있나요?
몇 년 뒤에도 계속 쓸 수 있나요?

1단계 중간 정리

AI for Good은 “착한 AI”라는 이름보다 훨씬 구체적인 문제예요. 작은 장치, 약한 인터넷, 부족한 데이터, 어려운 유지보수, 높은 책임을 모두 고려해서 실제 현장에서 버티는 시스템을 만드는 일이에요.

2단계: 고등학교 수준

1. 이 장의 논리 흐름

이 장은 다음 순서로 이야기를 전개해요.

사회 문제를 확인해요
-> AI가 도울 수 있는 지점을 찾어요
-> SDGs 같은 목표 체계와 연결해요
-> 현실의 자원 제약을 숫자로 봐요
-> 제약을 해결할 설계 패턴을 고릅니다
-> 실제 사례와 이론적 한계를 검토해요
-> 흔한 실패 이유를 정리해요

즉, 이 장은 “AI를 어디에 쓸까?”에서 시작하지만, 곧바로 “그 AI가 실제 환경에서 어떻게 살아남을까?”로 넘어갑니다.

2. 사회 문제와 AI 기회의 연결

원문은 여러 영역에서 AI가 전문가 수준의 분석을 더 넓게 제공할 수 있다고 설명해요.

하지만 여기서 중요한 조건이 있어요. AI가 해결책이 되려면 현지 제약에 맞아야 합니다. 기술적으로 좋아도 현장에서 쓸 수 없으면 실패예요.

3. 자원 역설을 숫자로 이해해요

원문은 사회적 목적의 AI에서 가장 중요한 현상을 “resource paradox”로 설명해요.

필요도는 높음
인프라는 낮음
설계 난도는 매우 높음

예를 들어, 도시의 클라우드 시스템은 수십 GB 메모리와 안정적인 전력을 기대할 수 있어요. 반면 농촌이나 숲속 장치는 몇 KB에서 몇 MB 수준의 메모리, 밀리와트 단위의 전력, 느린 네트워크에 맞춰야 할 수 있습니다.

간단히 비교하면 이렇습니다.

4. 모델 압축은 “큰 짐을 작은 가방에 넣는 과정”이에요

원문은 PlantVillage 작물 병 탐지 예시를 통해 모델 압축을 설명해요. 큰 모델을 그대로 작은 장치에 넣을 수 없기 때문에, 크기를 줄이면서 정확도 손실을 감수해야 합니다.

여기서 고등학교 수준으로 이해할 핵심은 “모든 성능을 다 유지할 수는 없으니, 정확도와 자원 사용량 사이에서 균형을 잡는다”는 점이에요.

5. 전력 예산은 하루 용돈처럼 나눠 써야 해요

전력도 무한하지 않아요. 원문은 태양광으로 하루 5-20Wh 정도를 얻는 환경을 예로 들어요. 이 에너지를 센서 측정, 모델 실행, 데이터 전송, 대기 상태에 나누어 써야 합니다.

간단히 생각하면 다음 관계가 있어요.

하루에 쓸 수 있는 에너지
>= 센서가 쓰는 에너지
 + 모델 추론이 쓰는 에너지
 + 통신이 쓰는 에너지
 + 대기 상태에서 새는 에너지

그래서 배터리가 적을 때는 덜 자주 측정하거나, 작은 모델을 쓰거나, 통신을 미루는 설계가 필요해요.

6. 네트워크 제약은 데이터 흐름을 바꿔요

빠른 인터넷이 있으면 사진이나 영상을 클라우드로 보낼 수 있어요. 하지만 LoRa 같은 저전력 네트워크에서는 아주 작은 데이터만 보낼 수 있습니다.

그래서 원본 이미지를 보내는 대신, 장치가 먼저 판단한 결과만 보낼 수 있어요.

카메라가 사진을 찍어요
-> 장치 안에서 먼저 분석해요
-> "질병 가능성 높음" 같은 작은 결과만 보내요
-> 연결이 좋을 때 더 자세한 데이터를 동기화해요

이 흐름이 바로 edge 처리와 압축된 통신의 이유예요.

7. 네 가지 패턴을 고르는 기준

원문은 패턴을 고를 때 세 가지 축을 보라고 해요.

이 세 가지 질문에 따라 다음 패턴을 고르게 됩니다.

8. 실패는 기술 점수가 낮아서만 생기지 않아요

원문은 기술적으로 성공했지만 사회적으로 실패하는 경우를 강하게 경고해요.

대표적인 실패 흐름은 다음과 같아요.

모델 정확도만 높임
-> 현지 언어, 문화, 업무 흐름을 놓침
-> 사람들이 신뢰하거나 사용하지 않음
-> 유지보수와 비용 계획이 없음
-> 파일럿은 성공했지만 장기 운영은 실패함

AI for Good에서는 정확도, 지연시간, 처리량 같은 기술 지표뿐 아니라 실제 채택, 신뢰, 비용, 유지보수, 지역사회 소유권까지 함께 봐야 해요.

2단계 중간 정리

이 장의 논리는 분명해요. 사회적 AI는 높은 필요도와 낮은 인프라가 만나는 곳에서 작동해야 하므로, 모델 압축, 에너지 예산, 오프라인 처리, 분산 학습, 지역사회 기반 유지보수가 모두 설계의 핵심이 됩니다.

3단계: 대학교 수준

1. Trustworthy AI Under Extreme Constraints

원문은 AI for Good을 “극단적 제약 아래에서 trustworthy AI를 구현하는 분야”로 봅니다. 여기서 trustworthy는 단순히 정확한 모델이 아니라, 책임성, 보안과 프라이버시, 견고성, 지속가능성을 모두 포함하는 개념이에요.

일반적인 상업 서비스에서 장애가 나면 사용자 경험이나 매출이 나빠질 수 있어요. 하지만 사회적 현장에서는 장애가 의료 진단 지연, 재난 대응 실패, 식량 안보 악화로 이어질 수 있습니다. 그래서 이 장에서 신뢰성과 안정성은 선택사항이 아니라 기본 요구사항이에요.

원문이 강조하는 제약은 매우 구체적입니다.

따라서 AI for Good은 기존 ML 시스템 지식을 “자원이 충분한 곳”에서만 적용하는 문제가 아니에요. 모든 최적화와 운영 원칙을 가장 가혹한 환경에 맞게 조합하는 종합 문제입니다.

2. Societal Challenges and AI Opportunities

원문은 먼저 역사적 사례를 통해 “늦은 감지와 대응”이 얼마나 큰 피해를 만들 수 있는지 보여줘요. 2014-2016년 서아프리카 Ebola outbreak, 2011년 Somalia famine, 2010년 Haiti earthquake는 모두 빠른 탐지, 자원 배분, 피해 평가의 중요성을 드러낸 사례로 제시됩니다.

이 사례들은 오늘날 여러 영역의 문제와 이어져요.

하지만 원문은 여기서 기술 중심 접근의 함정을 지적해요. 엔지니어가 먼저 기술을 만들고 나중에 현장 문제를 끼워 맞추면, 시스템은 멋져 보여도 사용되지 않을 수 있습니다. 성공적인 배포는 community-identified problems, 즉 지역사회가 실제로 중요하다고 보는 문제에서 출발해야 해요.

핵심 능력은 “전문가의 분석 능력을 전문가가 없는 곳까지 가져가는 것”입니다. 작물 사진 진단, 폐렴 triage, 밀렵 감지처럼 현장 판단을 보조하되, 연결 불안정, 태양광 전력, 희소 라벨 데이터라는 조건을 정면으로 받아들여야 해요.

3. Real-World Deployment Paradigms

원문은 Cloud ML, Mobile ML, Edge ML, TinyML 같은 배포 패러다임이 사회적 현장에서 어떻게 쓰이는지 사례 중심으로 보여줘요. 이 절의 핵심은 “하나의 AI 방식이 모든 문제를 해결하지 않는다”는 점입니다.

3.1 Agriculture

농업에서는 기후 변동, 병충해, 제한된 자원 속에서 더 많은 식량을 생산해야 하는 문제가 있어요. AI는 작물 상태를 관찰하고, 질병을 탐지하고, 물과 비료 같은 자원을 더 잘 배분하도록 도울 수 있습니다.

PlantVillage Nuru는 Mobile ML 사례로 제시돼요. 스마트폰에서 작물 병을 실시간으로 탐지하며, 2-5MB 크기의 양자화 모델로 85-90% 진단 정확도를 달성한다고 원문은 설명해요. 전력은 100mW 미만 수준으로 언급됩니다. 즉, 클라우드가 없어도 기본 진단을 제공하는 방식이에요.

동남아시아의 벼농사 맥락에서는 TinyML 센서가 논의 미세기후를 관찰해 물 사용을 최적화하는 사례가 나와요. 원문은 미세기후 센서가 10m 구역의 온도, 습도, 토양 수분 차이를 포착할 수 있다고 설명합니다. Microsoft FarmBeats는 IoT 센서, 드론, Cloud ML을 결합해 토양, 날씨, 작물 건강 데이터를 분석하는 사례로 제시돼요.

3.2 Healthcare

의료에서는 접근성 문제가 핵심이에요. 원격 지역 주민은 진료소까지 멀리 이동해야 하고, 전문의와 장비가 부족할 수 있습니다.

TinyML은 환자 옆에서 작동하는 진단 도구로 등장해요. 원문은 기침 패턴을 분석해 폐렴을 탐지하는 저가 wearable 사례를 소개합니다. 인터넷 없이 microcontroller에서 동작한다는 점이 중요해요.

또 다른 예는 모기 날갯짓 주파수로 종을 구분하는 장치예요. 말라리아 매개 모기와 그렇지 않은 모기를 구분하면 방역 자원을 더 정확하게 쓸 수 있습니다. Cloud ML은 Google Genomics 같은 대규모 유전체 분석 사례에서 등장해요. 여기서는 수십 PB급 데이터와 수십억 base pair 규모의 분석이 필요하므로 클라우드가 적합합니다.

3.3 Disaster Response

재난 대응은 시간, 불확실성, 망가진 인프라가 동시에 문제가 되는 영역이에요. 원문은 TinyML 드론이 무너진 건물 안에서 열화상과 음향 신호를 로컬로 분석해 생존자나 위험을 탐지하는 사례를 제시합니다. 클라우드 연결이 없어도 판단해야 하므로 로컬 처리와 자율성이 중요해요.

Cloud ML은 위성 이미지를 분석해 홍수 지역을 예측하고 정부의 자원 배분을 돕는 데 쓰일 수 있어요. Mobile ML은 스마트폰으로 위치 기반 재난 경보를 보내는 역할을 합니다.

즉, 재난 대응에서는 다음처럼 여러 계층이 동시에 필요해요.

드론과 센서의 현장 판단
-> 지역 단위의 상황 집계
-> 클라우드 기반 위성/기상 분석
-> 시민에게 전달되는 모바일 경보

3.4 Environmental Conservation

환경 보전에서는 넓고 외딴 지역을 감시해야 해요. Edge ML이 들어간 동물 collar는 움직임과 소리를 현장에서 처리해 배터리 소모와 데이터 전송량을 줄입니다. TinyML 시스템은 총소리나 사람 활동을 감지해 ranger에게 알릴 수 있어요.

Cloud ML은 Global Fishing Watch처럼 위성 데이터를 분석해 불법 어업을 감시하는 대규모 분석에 쓰입니다. 원문은 육상 보전과 해양 보전 모두에서 local autonomy와 global coordination이 함께 필요하다고 보여줘요.

3.5 Cross-Domain Integration Challenges

원문은 위 사례들이 각각 성공 가능성을 보여주지만, 고립된 혁신만으로는 충분하지 않다고 말해요. 농업, 의료, 환경, 재난은 서로 연결되어 있고, 대규모 문제는 기관, 지역, 이해관계자의 협력이 필요합니다.

여기서 중요한 질문은 세 가지예요.

제한된 자원을 어디에 먼저 투자할까요?
가장 기술적으로 흥미로운 문제가 아니라 가장 절실한 문제를 어떻게 고를까요?
다양한 지역과 맥락에서 성공을 어떻게 측정하고 책임을 질까요?

4. Sustainable Development Goals Framework

원문은 UN Sustainable Development Goals, 즉 SDGs를 사회적 AI가 어떤 문제를 다뤄야 하는지 판단하는 규범적 틀로 소개해요. SDGs는 빈곤, 기아, 교육, 성평등, 기후 행동, 도시, 생태계 등 다양한 목표를 연결합니다.

ML 시스템은 여러 SDG에 동시에 기여할 수 있어요.

하지만 SDGs는 “무엇이 중요한가”를 알려줄 뿐, “어떻게 구현할 것인가”를 자동으로 해결하지는 않아요. 원문은 이 차이를 분명히 합니다. SDG 3을 목표로 한다고 해서 태양광으로 작동하고 인터넷이 끊겨도 버티는 진단 시스템이 자동으로 생기지는 않습니다.

즉, 목표는 규범을 주고, 공학은 가능성을 결정해요.

SDGs: 어떤 문제를 풀어야 하는가
Engineering constraints: 그 문제를 실제 시스템으로 만들 수 있는가

5. Resource Constraints and Engineering Challenges

이 절은 이 장의 기술적 중심부예요. 원문은 계산, 네트워크, 전력, 데이터, 유지보수, 복구 문제가 서로 얽혀 있다고 설명합니다.

5.1 Model Compression for Extreme Resource Limits

자원 제약 환경에서는 모델 압축이 선택적 최적화가 아니라 배포 가능성을 결정하는 핵심 조건입니다. PlantVillage 예시는 압축 파이프라인을 수치로 보여줘요.

마지막 3.2MB 모델은 ESP32 microcontroller에서 50-80ms 수준의 추론을 가능하게 한다고 원문은 설명해요. 여기서 중요한 것은 정확도 4%p 손실을 감수하는 대신, 실제 오프그리드 농업 환경에서 쓸 수 있는 시스템이 된다는 점입니다.

전력 분석도 함께 따라와요. 원문은 neural network inference가 MAC 연산당 0.1-1mJ 정도를 소비하고, 1M parameter 모델은 inference당 1-10mJ가 필요할 수 있다고 설명합니다. 농촌 태양광은 하루 5-20Wh를 제공할 수 있고, 변환 손실과 배터리 열화를 고려해야 해요.

전력 계층은 다음처럼 나뉩니다.

5.2 Resource Paradox

Resource paradox는 필요와 인프라가 반대로 분포한다는 뜻이에요. 원문은 사하라 이남 아프리카가 세계 경작 가능 토지의 큰 비중을 갖지만 인터넷 연결성은 낮고, 높은 질병 부담을 가진 원격 진료소는 작은 태양광 패널에 의존하며, 생물다양성 손실이 큰 숲 지역은 클라우드 연결 감시망을 갖추기 어렵다고 설명합니다.

도시의 클라우드 배포는 100-200W 서버, 여러 CPU core, 32-64GB RAM을 기대할 수 있어요. 반면 농촌 배포는 5W single-board computer나 milliwatt급 microcontroller, KB 단위 RAM으로 동작해야 할 수 있습니다.

네트워크도 마찬가지예요. 도시의 fiber나 5G는 Mbps-Gbps 수준이지만, 농촌에서는 LoRa나 NB-IoT처럼 50kbps 수준의 저전력 네트워크에 의존할 수 있어요. 그래서 시스템은 payload 크기, 전송 빈도, 오프라인 캐시를 매우 신중하게 설계해야 합니다.

5.3 Data Scarcity and Quality Constraints

자원 역설은 데이터에도 적용돼요. 상업 시스템은 수백만 개의 표준화된 예시를 쓸 수 있지만, 사회적 AI는 제한적이고 이질적인 데이터로 견고한 시스템을 만들어야 합니다.

원문은 농촌 clinic이 하루 50-100개 patient record, 약 500KB 정도를 만들 수 있다고 설명해요. 이 데이터는 structured vital signs와 handwritten notes가 섞일 수 있어요. 도시 병원의 표준화된 전자의무기록과는 규모와 형식이 완전히 다릅니다.

농업 센서도 reading당 100-200 bytes만 전송할 수 있고, 1000개 센서가 하루 4-5MB 정도만 만들 수 있다고 설명돼요. 이는 영상 스트리밍 한두 분보다도 작은 규모일 수 있습니다.

프라이버시는 더 어려워져요. 의료와 위치 데이터는 매우 민감하지만, differential privacy나 federated learning을 microcontroller급 장치에 구현하려면 512KB RAM, 2-4MB storage 같은 한계에 부딪힙니다. 보안 연산은 10-50% 추가 계산 오버헤드를 만들 수 있고, 오프라인 운영에서는 실시간 인증과 폐기 확인도 어렵습니다.

5.4 Development-to-Production Resource Gaps

개발 환경과 실제 배포 환경의 차이도 큽니다. 개발자는 Raspberry Pi 4 같은 장치에서 Python framework로 빠르게 실험할 수 있어요. 하지만 대규모 배포에서는 비용과 전력 때문에 ESP32 같은 microcontroller를 써야 할 수 있습니다.

원문 수치를 기준으로 보면 Raspberry Pi 4는 1.5GHz processor와 4GB RAM을 제공하지만, ESP32는 240MHz dual-core processor와 총 520KB SRAM 수준이에요. 즉, 개발 때 되던 코드가 생산 배포에서는 그대로 돌아가지 않을 가능성이 큽니다.

이 간극 때문에 필요한 작업은 다음과 같아요.

모델 구조 재설계
-> quantization과 pruning
-> 작은 메모리 footprint에 맞춘 inference
-> 느린 네트워크와 작은 storage에 맞춘 update mechanism

원문은 forest monitoring 예시에서 50MB computer vision model을 약 500KB로 줄여야 할 수 있다고 설명합니다.

5.5 Long-Term Viability and Community Ownership

AI for Good 시스템은 배포 순간보다 그 이후가 더 어렵습니다. 원문은 수명, 환경 영향, 지역사회 역량, 재정 지속가능성이 장기 성공을 결정한다고 설명해요.

하드웨어는 -20°C에서 50°C의 온도, 80-95% 습도, 먼지 같은 환경을 견뎌야 할 수 있습니다. 태양광 시스템은 지역과 계절에 따라 3-7kWh/m²/day 수준으로 달라질 수 있는 일사량에 맞춰야 해요.

환경 지속가능성도 중요합니다. 1000개 sensor node 배포에는 약 500kg의 전자 부품을 고려해야 한다고 원문은 말해요. 제조, 운송, 운영 전력, 유지보수 방문, e-waste 처리가 모두 전체 생애주기 영향에 들어갑니다.

지역사회 소유권은 단순 교육보다 더 넓은 개념이에요. 현지 기술자가 고칠 수 있어야 하고, 문서는 여러 언어와 형식으로 접근 가능해야 하며, domain expert, social scientist, community organizer, local partner가 함께 설계해야 합니다.

원문은 엔지니어의 역할을 기술 제공자라기보다 community-defined goals를 돕는 facilitator와 problem-solver에 가깝게 봐요.

재정적으로는 운영 비용, 부품, 네트워크 연결비가 지역 경제와 맞아야 합니다. 원문은 지속 가능한 배포가 beneficiary의 지역 월소득 5% 미만 운영비를 목표로 할 수 있다고 설명해요.

5.6 System Resilience and Failure Recovery

사회적 배포에서는 장애가 생명과 생계에 영향을 줄 수 있으므로 failure recovery가 필수입니다. 원문은 50개 이상의 social good deployment 분석에서 downtime 원인을 세 가지로 나눠요.

분산 복구에는 modified Raft 같은 consensus mechanism, 3-5개 node geographic replication, regional node의 조정 업데이트가 등장합니다. 단, 원문은 이것이 일반적인 대규모 데이터센터 consensus가 아니라 resource constraint에 맞춘 변형임을 보여줘요.

지역사회 기반 유지보수도 중요합니다. community health worker가 흔한 실패의 80%를 식별하고 해결하도록 훈련받고, 지역 inventory가 2주치 critical components를 유지하며, 복잡한 문제는 remote expert로 escalation합니다. 이 방식은 외부 기술자 파견의 7-14일 수리 시간을 2-4시간 지역 대응으로 줄일 수 있다고 원문은 설명해요.

6. Design Pattern Framework

원문은 세 가지 핵심 제약을 설계 패턴의 출발점으로 제시합니다.

communication bottlenecks
sample scarcity
energy limitations

즉, 데이터 전송 비용이 로컬 계산보다 커질 수 있고, 이론적으로 필요한 데이터보다 실제 라벨 데이터가 100-1000배 부족할 수 있으며, 정확도와 배터리 수명 사이에서 명시적 trade-off가 필요하다는 뜻이에요.

따라서 resource-constrained deployment는 cloud system의 축소판이 아닙니다. 문제 구조가 다르기 때문에 아키텍처도 달라져야 해요.

6.1 Pattern Selection Dimensions

패턴 선택 기준은 세 가지입니다.

6.2 Pattern Overview

원문은 하나의 시스템이 여러 패턴을 함께 쓸 수 있다고 설명해요. 예를 들어 야생동물 감시망은 개별 센서에서 Adaptive Resource를 쓰고, 센서 간 협력에는 Distributed Knowledge를 쓰며, 연결 상태에 따라 Progressive Enhancement를 쓸 수 있습니다.

7. Design Patterns Implementation

이 절은 네 가지 패턴을 실제 구조, 사례, 현대적 변형, ML 시스템에서의 의미, 한계까지 자세히 설명합니다.

7.1 Hierarchical Processing

Hierarchical Processing Pattern은 시스템을 edge, regional, cloud 같은 계층으로 나누고, 각 계층이 가능한 만큼의 일을 맡는 방식이에요.

edge tier
-> 데이터 수집, 기본 전처리, 낮은 전력의 즉시 판단

regional tier
-> 여러 edge 데이터 집계, 지역별 분석, 중간 수준 decision

cloud tier
-> 대규모 학습, 고급 분석, 전체 모델 업데이트

이 패턴은 네트워크나 전력이 끊겨도 edge와 regional tier가 중요한 기능을 계속 수행하게 해요. 연결이 돌아오면 cloud 분석과 모델 업데이트를 다시 받을 수 있습니다.

Google Flood Forecasting 사례

원문은 Google Flood Forecasting을 계층적 처리의 사례로 설명해요. 강 주변 edge device가 수위를 관찰하고 기본 anomaly detection을 합니다. regional center는 여러 sensor 데이터를 모아 지역 판단을 하고, cloud tier는 위성 이미지와 날씨 데이터를 결합해 고급 홍수 예측과 inundation map을 만듭니다.

이 구조의 장점은 graceful degradation이에요. cloud 연결이 없어도 edge와 regional tier가 완전히 멈추지 않습니다.

Structure

edge tier는 adaptive sampling, 1-4MB local buffer, quantized model inference, device health tracking, store-and-forward communication을 포함해요. regional tier는 data fusion, 50-100GB 규모의 distributed database, eventual consistency, load balancing, failover, 여러 model version serving을 담당합니다. cloud tier는 parallel training, model lineage, high-throughput data pipeline, authentication과 audit trail, global state management를 담당해요.

Modern Adaptations

현대적 변형에서는 edge device가 단순 센서에서 벗어나 image recognition이나 anomaly detection까지 수행할 수 있어요. 이는 model compression, pruning, quantization, edge accelerator, low-power GPU 덕분입니다.

regional tier도 단순 aggregation을 넘어 federated learning과 local adaptation을 수행할 수 있어요. 즉, cloud가 모든 것을 지시하는 구조에서 점점 더 동적인 계층 분배로 이동합니다.

System Implications

ML 시스템에서 hierarchical pattern은 model lifecycle 관리가 복잡해져요. model drift를 막기 위해 업데이트가 필요하지만, edge와 regional tier는 연결 지연 때문에 오래된 model version으로 계속 동작할 수 있습니다.

따라서 필요한 설계는 다음과 같아요.

model versioning
-> update compatibility
-> edge preprocessing
-> regional aggregation
-> cloud retraining
-> model update propagation

inference도 동적으로 분배됩니다. edge는 빠른 anomaly detection을 하고, cloud는 더 복잡한 inference를 수행해 latency, energy, accuracy를 균형 있게 맞춰요.

Performance Characteristics by Tier

원문은 bandwidth constraint를 구체적으로 설명합니다. 2G 50kbps에서는 분당 1-2개 image upload 정도만 가능하고, 3G 1Mbps에서는 분당 10-20개 image가 가능할 수 있어요. 그래서 routine inference의 95% 이상은 edge에서 처리해야 network를 압도하지 않습니다.

분산 처리에서 communication cost도 중요해요.

parameter synchronization cost
= O(model_size x participants)

참여 노드가 많고 모델이 크면 통신 비용이 병목이 됩니다. 원문은 지속 가능한 분산 운영을 위해 compute-to-communication ratio를 10:1 정도로 유지하는 규칙을 제시해요.

Limitations

한계도 분명합니다. 계층이 많아지면 resource allocation, 비용 관리, 지연시간, data imbalance, debugging이 모두 어려워져요. 도시 지역 데이터가 더 많으면 모델이 rural region에서 덜 잘 작동할 수 있고, 문제 원인이 hardware failure인지 network인지 model drift인지 찾기 어려워집니다.

7.2 Progressive Enhancement

Progressive Enhancement Pattern은 최소 자원에서도 기본 기능을 제공하고, 자원이 늘어나면 기능을 점점 확장하는 방식이에요.

웹 개발에서 오래된 브라우저도 기본 페이지를 보여주고, 좋은 브라우저에서는 더 풍부한 기능을 제공하는 방식과 비슷합니다. ML 시스템에서는 작은 모델부터 큰 모델까지 여러 capability layer를 둡니다.

baseline layer: 매우 작은 모델, 오프라인, 핵심 기능
enhanced layer: 연결 가능, 더 많은 데이터와 기능
advanced layer: cloud 분석, 높은 정확도와 상세 권고

PlantVillage Nuru 사례

PlantVillage Nuru는 이 패턴의 대표 사례로 나와요. entry-level smartphone에서 2-5MB quantized CNN을 실행해 1-2 fps로 작물 이미지를 처리하고, 100mW 미만 전력으로 85-90% 정확도의 기본 진단을 제공합니다.

연결이 생기면 cloud의 50-100MB 모델이 고급 분석을 수행하고, 위성 이미지, weather data, soil sensor readings를 결합해 95-98% 정확도와 더 자세한 mitigation strategy를 제공할 수 있어요.

스마트폰 접근성이 낮은 지역에는 community digital hub가 intermediate layer가 됩니다. tablet이 10-20GB diagnostic model과 agricultural database를 local cache로 보관하고, 연결 가능한 시간에 cloud와 동기화합니다.

Structure

이 패턴은 각 layer가 독립적으로 작동하도록 설계해야 해요. higher layer가 없어도 baseline layer는 계속 동작해야 합니다. layer 간 전환은 사용자에게 큰 혼란을 주지 않아야 하고, resource 상태가 좋아지거나 나빠질 때 자연스럽게 이동해야 해요.

Modern Adaptations

현대 구현에서는 Neural Architecture Search로 500KB부터 50MB까지 model family를 만들 수 있습니다. knowledge distillation은 큰 모델의 지식을 작은 모델로 옮기고, federated optimization은 base layer 장치도 간단한 model averaging에 참여하게 해요.

resource-aware neural architecture는 모델의 depth, width, activation을 현재 장치 상태에 맞춰 조절할 수 있습니다.

System Implications

progressive enhancement에서는 model architecture 설계가 여러 resource tier를 동시에 고려해야 해요. baseline model은 보통 100-500KB 크기 안에서 full model 성능의 85-90% 정도를 목표로 할 수 있습니다.

training pipeline은 여러 model variant 간 consistency를 유지해야 합니다. 예를 들어 작은 모델이 큰 모델과 완전히 다른 판단을 하면 사용자는 시스템을 신뢰하기 어려워요. 그래서 progressive knowledge distillation과 cross-layer consistency가 중요합니다.

inference에서는 adaptive batching, dynamic quantization, selective layer activation이 쓰일 수 있습니다. model synchronization과 versioning도 어려워져요. 여러 layer의 모델이 동시에 존재하므로 backward compatibility가 필요합니다.

Framework Implementation Patterns

원문은 PyTorch Mobile, TensorFlow Lite 같은 framework 선택이 layer별 배포 성공에 영향을 준다고 설명합니다. PyTorch Mobile은 torchscript optimization과 quantization을 제공하고, TensorFlow Lite는 resource-constrained deployment에 최적화된 모델 생성에 강점이 있어요.

또한 power-aware model scheduling이 필요합니다. 배터리와 네트워크 상태에 따라 작은 모델과 큰 모델 중 어떤 것을 실행할지 정해야 해요.

Limitations

한계는 model version proliferation입니다. layer마다 3-5개의 model variant가 있으면 관리, 테스트, 검증 부담이 급격히 증가해요. baseline layer는 1-5% 계산 자원만으로 advanced model의 85-90% 성능을 내야 할 수 있어, 복잡한 task에서는 매우 어렵습니다.

resource layer를 전환하는 결정 자체도 50-200ms latency를 만들 수 있어요. 출력 품질과 응답 시간이 layer마다 달라지면 사용자는 혼란을 느낄 수 있습니다.

7.3 Distributed Knowledge

Distributed Knowledge Pattern은 중앙 서버에 모든 것을 모으지 않고, 분산된 노드들이 각자 학습하고 서로 지식을 나누는 방식이에요. hierarchical pattern처럼 계층별 역할이 엄격히 나뉘는 것이 아니라, 각 노드가 비슷한 기본 능력을 가지고 peer-to-peer로 협력합니다.

각 노드는 1-5MB quantized model로 local inference를 수행하고, federated learning 같은 방법으로 공동 모델 개선에 참여할 수 있어요. 공유되는 것은 raw data가 아니라 model parameter update, derived feature, processed insight일 수 있습니다.

이 패턴은 하루 1-2시간만 네트워크가 열리거나, 노드당 하루 50-100KB 정도만 보낼 수 있는 환경에 특히 유용합니다.

Wildlife Insights 사례

원문은 Wildlife Insights와 camera trap network를 사례로 제시해요. 각 camera trap은 독립적인 processing node로 동작하며, 50-100mW 전력 안에서 lightweight CNN으로 종을 식별하고 motion activity를 분석합니다.

중요한 점은 raw image를 모두 보내지 않는다는 거예요. 몇 MB짜리 이미지를 바로 전송하는 대신, edge에서 분석해 몇 KB짜리 insight vector로 줄입니다.

camera trap들은 low-power radio protocol로 local mesh network를 만들고, 중요한 활동이나 밀렵 징후가 감지되면 이 정보를 네트워크에 퍼뜨립니다. 위성이나 cellular link가 가능해질 때는 accumulated knowledge를 cloud와 동기화하고, cloud는 population dynamics와 movement pattern을 더 깊게 분석합니다.

Structure

Distributed Knowledge Pattern의 구조는 세 요소로 나뉩니다.

이 구조는 connectivity가 불안정해도 각 노드가 독립적으로 계속 동작하게 만들고, 연결이 가능할 때만 지식을 합칩니다.

Modern Adaptations

edge computing은 각 노드가 더 복잡한 처리를 로컬에서 수행하게 해요. 예전에는 중앙 서버로 데이터를 보내야 했지만, 이제 camera trap이나 smartphone, IoT sensor가 anomaly detection과 image classification을 직접 수행할 수 있습니다.

mesh network는 일부 노드가 실패해도 네트워크가 스스로 우회 경로를 만들게 도와요. 5G는 대역폭과 지연시간을 개선할 수 있지만, 원문 맥락에서는 여전히 remote region의 제한된 연결성을 고려해야 합니다.

System Implications

ML 관점에서는 non-IID data가 큰 문제예요. 각 노드가 보는 데이터가 서로 다르기 때문입니다. 어떤 카메라는 밤에 동물을 많이 보고, 어떤 카메라는 사람 활동을 더 많이 볼 수 있어요. Federated averaging은 이런 편향을 고려해 가중 aggregation을 해야 합니다.

모델은 node-level memory 1-5MB 안에서 작동하면서 centralized model accuracy의 85-90% 정도를 유지해야 할 수 있어요. inference는 sub-100ms latency와 50-150mW power envelope를 목표로 할 수 있습니다.

model lifecycle management도 복잡해집니다. 부분 연결만 가능한 상태에서 update가 퍼지므로, 일부 node는 새 모델을 쓰고 일부 node는 옛 모델을 쓸 수 있어요. 시스템은 model divergence를 막고 forward/backward compatibility를 관리해야 합니다.

Limitations

주요 한계는 model synchronization, data fragmentation, scalability, latency, security/privacy입니다.

분산 노드는 서로 다른 모델 버전을 가질 수 있고, 데이터가 여러 노드에 흩어져 전체 분포를 보기 어렵습니다. 노드가 늘어나면 재균형, 재보정, coordination mechanism이 필요해져 복잡성이 커져요.

보안 면에서는 Sybil attack처럼 가짜 노드를 넣어 시스템을 교란하는 공격도 고려해야 합니다. 민감한 의료나 금융 데이터라면 encryption과 authentication이 필수지만, 자원 제약이 이를 어렵게 만들 수 있어요.

7.4 Adaptive Resource

Adaptive Resource Pattern은 현재 자원 상태에 따라 시스템 동작을 동적으로 바꾸는 방식입니다. 전력, CPU, 메모리, 저장공간, 네트워크 대역폭을 계속 관찰하고, 그때그때 처리 강도를 조절해요.

low resource
-> 단순 모델, 낮은 sampling rate, local-only mode

medium resource
-> 중간 모델, 일부 동기화, 제한적 고급 기능

high resource
-> 큰 모델, cloud offload, detailed analysis

이 패턴은 독립 패턴이라기보다 다른 패턴 안에 섞여 들어가는 경우가 많아요.

Case Studies

Google flood forecasting에서는 인프라가 약한 지역일수록 edge processing 비중을 높이고, 인프라가 좋은 지역에서는 cloud 분석을 더 많이 쓸 수 있어요.

PlantVillage Nuru에서는 기기와 네트워크 상태에 따라 처리 복잡도를 조절할 수 있습니다. Wildlife Insights에서는 camera trap이 전력과 연결 상태가 나쁠 때 로컬 처리만 하고, 연결이 좋아지면 더 많은 정보를 중앙 시스템으로 보낼 수 있어요.

Structure

구조는 monitoring mechanism, adaptive decision-making, feedback loop로 이루어집니다.

Modern Adaptations

cloud computing은 수요가 많을 때 자원을 늘리고, 줄어들면 비용을 줄이는 elastic scaling을 제공합니다. edge computing은 중앙 서버 의존을 줄이고 real-time responsiveness를 높여요.

AI-driven resource management는 reinforcement learning이나 predictive model로 미래의 traffic, compute, storage 필요를 예측해 자원을 미리 조정할 수 있습니다. 재난 대응에서는 rescue team, medical supplies, communication tool을 상황 변화에 맞게 동적으로 배분하는 데도 같은 사고방식이 적용돼요.

System Implications

Federated learning에서는 장치별 계산 능력이 다르므로, 강한 장치는 더 무거운 local update를 수행하고 약한 장치는 가벼운 update만 수행하게 할 수 있어요.

real-time inference에서는 resource가 부족할 때 낮은 해상도 frame이나 단순 모델을 쓰고, resource가 충분할 때 더 복잡한 모델을 적용할 수 있습니다. cloud-based ML에서는 batch inference나 training 자원을 수요에 따라 늘리고 줄여 비용을 최적화합니다.

edge AI는 이 패턴의 대표 수혜자예요. remote region에서 네트워크가 나쁘면 단순 모델로 계속 동작하고, 연결이 돌아오면 cloud로 복잡한 분석을 넘길 수 있습니다.

Limitations

Adaptive Resource의 한계는 performance predictability입니다. 8GB RAM 환경에서 50ms latency를 내던 시스템이 500MB RAM 환경으로 내려가면 200ms가 될 수 있어요. 사용자는 같은 시스템이 상황마다 다르게 동작한다고 느낄 수 있습니다.

state synchronization도 어려워집니다. 50Mbps에서 50Kbps로 대역폭이 떨어질 때 partial update를 어떻게 처리할지 정해야 해요. 모델을 50MB full model에서 5MB quantized model로 바꾸는 데 100-200ms 전환 비용이 생길 수 있습니다.

정확도도 줄어들 수 있어요. 예를 들어 lightweight architecture로 바꾸면서 정확도가 95%에서 85%로 떨어질 수 있습니다. 따라서 어떤 자원 상태에서도 넘지 말아야 할 quality threshold를 미리 정해야 해요.

8. Theoretical Foundations for Constrained Learning

이 절은 앞의 패턴들이 단순 경험칙이 아니라 이론적 제약에서 나온 것임을 설명해요.

8.1 Statistical Learning Under Data Scarcity

전통적 supervised learning은 클래스당 1000개 이상의 label을 기대하는 경우가 많지만, resource-constrained environment에서는 클래스당 100개 미만, 심하면 질병 종류당 50개 미만 예시로 학습해야 할 수 있습니다.

원문은 learning curve를 통해 gap을 설명해요. 정확도 향상이 데이터 크기의 거듭제곱 법칙을 따른다고 보면,

accuracy ∝ (data_size)^α

전통적 deep learning에서는 α가 보통 0.1-0.3 정도로 작아 데이터가 많이 필요합니다. 하지만 제약 환경에서는 α가 0.7 이상처럼 훨씬 효율적인 학습이 필요하다고 설명해요.

8.2 Information-Theoretic Bounds

PAC-learning 관점에서는 질병 수를 k, feature dimension을 d, 목표 오차를 ε라고 할 때 전통적 sample complexity가 대략 다음처럼 표현됩니다.

O(k x d / ε²)

의미는 간단해요. 분류해야 할 종류가 많고, feature 차원이 크고, 더 낮은 오차를 원할수록 필요한 샘플 수가 빠르게 늘어납니다. 그런데 실제 사회적 현장에서는 이론적으로 필요한 양보다 100-1000배 적은 데이터만 있을 수 있어요.

이 gap을 줄이기 위해 원문은 세 가지 접근을 제시합니다.

8.3 Learning Without Labeled Data

라벨은 부족하지만 unlabeled data는 많을 수 있어요. 병원 이미지는 많이 생기지만 전문가 annotation은 부족한 상황이 대표적입니다.

Self-supervised learning은 라벨 없이 데이터 구조를 먼저 배우고, 적은 라벨로 fine-tuning하는 방법이에요. 원문은 contrastive learning을 예로 들며, 비슷한 예시와 다른 예시를 구분하도록 학습해 representation을 만든다고 설명합니다.

시스템 흐름은 다음과 같아요.

edge device가 unlabeled data를 계속 수집해요
-> regional server가 self-supervised pretraining을 해요
-> edge device가 작은 labeled set으로 fine-tuning해요
-> bandwidth와 compute 제약 안에서 업데이트해요

이 방식은 scratch training 대비 sample complexity 부담을 5-15배 줄일 수 있다고 원문은 설명합니다.

정보이론적으로는 input X와 label Y 사이의 mutual information I(X;Y)가 성능 한계를 좌우합니다. self-supervised pretraining은 입력 분포의 task-relevant structure를 더 잘 포착해 effective mutual information을 높이는 방식으로 이해할 수 있어요.

8.4 Communication and Energy-Aware Learning

분산 학습에서는 계산보다 통신이 더 비쌀 수 있습니다. federated learning에서 n개 edge device가 있고 각 device가 model parameter θ_i를 가진다고 하면, 한 round의 통신 비용은 대략 다음처럼 커져요.

O(n x model_size)

따라서 큰 모델과 많은 참여자는 통신 병목을 만듭니다. 이 환경에서는 gradient compression, sparse update, local personalization이 단순 최적화가 아니라 이론적으로 필요한 전략이 됩니다.

전력 제약도 목적함수에 들어와야 해요. 원문은 energy per inference와 battery lifetime을 다음처럼 표현합니다.

E_inf = α x model_size + β x computation_time

T_battery = E_total / (inference_rate x E_inf + E_idle)

여기서 E_inf는 한 번 추론하는 데 드는 에너지, T_battery는 배터리 지속시간이에요. 모델이 크고 계산 시간이 길수록 에너지가 많이 들고, inference rate가 높을수록 배터리가 빨리 줄어듭니다.

따라서 목표는 단순히 정확도 최대화가 아니라 다음과 같이 바뀝니다.

deployment requirement를 만족하는 배터리 수명 안에서
정확도를 최대화해요

이 사고가 hierarchical processing, progressive enhancement, distributed knowledge, adaptive resource pattern의 이론적 배경이 됩니다.

9. Common Deployment Failures and Sociotechnical Pitfalls

원문은 기술 구현이 성공해도 사회적 배포는 실패할 수 있다고 강조해요.

9.1 Performance Metrics Versus Real-World Impact

가장 흔한 오류는 technical performance가 곧 real-world impact라고 착각하는 것입니다. 실험실에서 95% 정확도를 내는 healthcare diagnostic system이라도, 현장 인터넷이 불안정하거나, 출력 언어가 맞지 않거나, 사용자가 신뢰하지 않으면 실제 효과는 낮습니다.

이 오류는 기술 최적화와 outcome 최적화를 혼동하는 데서 나와요. 정확도, latency, throughput은 통제된 조건의 시스템 행동을 측정하지만, 사회적 영향은 adoption, trust, community priority, institutional workflow와 함께 결정됩니다.

9.2 Hidden Dependencies on Basic Infrastructure

offline-first라고 해도 주기적 update, synchronization, remote monitoring이 필요할 수 있어요. 그런데 농촌 배포에서는 네트워크가 몇 주씩 끊길 수 있고, 위성 연결은 너무 비쌀 수 있습니다.

전력도 마찬가지예요. 태양광은 이론상 좋아 보이지만 우기, 먼지, panel theft, battery degradation, temperature extreme을 고려해야 해요. 실험실 배터리 수명 계산은 현장에서 과도하게 낙관적일 수 있습니다.

유지보수 인프라도 숨은 의존성입니다. battery replacement가 매년 필요하지만 부품이 현지에 없거나 배송비가 장치 가격보다 비싸면 시스템은 지속될 수 없어요.

9.3 Underestimating Social Integration Complexity

커뮤니티 참여는 부가 활동이 아니라 핵심 설계 제약입니다. clinic director나 school principal만 만나고, traditional leader, women’s group, youth organization, informal network를 놓치면 실제 adoption에 실패할 수 있어요.

서구식 개인 의사결정, 개인 성취 중심 교육, 선형 문제 해결 방식이 모든 문화에 맞는 것도 아닙니다. community consensus, traditional knowledge, collaborative learning이 더 중요할 수 있어요.

동의 과정도 조심해야 합니다. 외부 조직이 자원과 funding을 가지고 들어오면 지역사회가 거절하기 어렵다고 느낄 수 있어요. 진짜 informed consent는 데이터 사용, 소유권, 장기 운영 책임을 명확히 이해하고 선택할 수 있을 때 가능합니다.

9.4 Avoiding Extractive Technology Relationships

원문은 AI for social good이 extractive relationship을 만들 수 있다고 경고해요. 지역사회가 데이터와 노동을 제공하고, 외부 조직이 가치와 통제권을 가져가면 사회적 목적과 반대되는 결과가 됩니다.

데이터 주권이 중요합니다. 의료 데이터, 농업 생산 데이터, 교육 데이터는 모두 민감하고 경제적 의미가 있어요. 명확한 community data governance 없이 수집되면 원래 목적을 넘어 제3자에게 공유되거나 수익화될 수 있습니다.

기술 아키텍처도 착취 구조를 만들 수 있어요. raw data는 지역에서 나오지만 model improvement, algorithm control, system evolution은 외부 조직이 독점할 수 있습니다. 지역사회는 계속 의존하게 되고, 가치 창출은 외부로 이동해요.

따라서 local data processing, transparent algorithm, community-controlled system evolution, local capacity building이 필요합니다.

9.5 Short-Term Success Versus Long-Term Viability

많은 프로젝트는 pilot success에 집중하지만, 장기 유지 가능성을 충분히 계획하지 않습니다. software maintenance, security update, hardware compatibility, dependency breakage, cloud API discontinuation은 모두 장기 위험이에요.

재정 지속가능성도 중요합니다. grant funding은 초기 개발과 배포를 지원할 수 있지만, 운영비와 유지보수비를 계속 보장하지는 않아요. target community가 비용을 지불하기 어려운 경우 cost recovery model은 access barrier가 될 수 있습니다.

조직 지속가능성도 필요합니다. 특정 연구자, 연구실, nonprofit에 의존하면 funding cycle이나 인력 이동으로 프로젝트가 무너질 수 있어요. governance structure와 succession planning이 필요합니다.

환경 지속가능성도 빠질 수 없어요. e-waste, rare earth mineral, cloud carbon emission은 환경 정의 문제와 충돌할 수 있습니다. 특히 이미 기후 변화 영향을 받는 지역에서 배포할 때 더 중요합니다.

10. Summary and Looking Forward

원문 결론은 명확합니다. AI for social good은 severe resource constraints 아래에서 meaningful impact를 만들어야 하는 가장 어려운 ML 시스템 응용 중 하나예요.

네 가지 패턴은 제약 아래의 trustworthiness architecture로 볼 수 있습니다.

Looking Forward에서 원문은 이 장의 constraint-first thinking이 사회적 AI에만 국한되지 않는다고 말해요. privacy concern, energy cost, sustainability requirement가 커질수록 모든 ML 시스템은 점점 resource-aware 설계를 필요로 하게 됩니다.

즉, 이 장의 질문은 다음과 같이 확장돼요.

기존 ML을 제약 아래에 어떻게 배포할까요?
-> 제약을 기본값으로 생각하는 ML 시스템을 어떻게 다시 설계할까요?

복습 질문

1. AI for Good이 단순히 “좋은 목적의 AI”가 아니라 별도의 ML 시스템 공학 문제인 이유는 무엇인가요?
2. resource paradox란 무엇이며, 왜 사회적 AI 배포에서 특히 중요할까요?
3. PlantVillage Nuru 사례에서 모델 압축이 왜 필수였나요?
4. 전력 예산이 제한된 환경에서 모델 크기, 추론 빈도, 통신 빈도는 어떤 관계를 가지나요?
5. SDGs는 AI 시스템 설계에서 어떤 역할을 하고, 어떤 한계를 가지나요?
6. Hierarchical Processing Pattern에서 edge, regional, cloud tier는 각각 어떤 역할을 하나요?
7. Progressive Enhancement Pattern은 왜 다양한 장치와 네트워크 환경에 적합한가요?
8. Distributed Knowledge Pattern이 raw data 대신 processed insight나 parameter update를 공유하는 이유는 무엇인가요?
9. Adaptive Resource Pattern에서 feedback loop가 중요한 이유는 무엇인가요?
10. PAC-learning sample complexity 관점에서 resource-constrained environment가 어려운 이유는 무엇인가요?
11. self-supervised learning은 라벨 부족 문제를 어떻게 완화하나요?
12. federated learning에서 communication cost가 computation cost보다 더 큰 문제가 될 수 있는 이유는 무엇인가요?
13. technical performance metric이 real-world impact를 보장하지 않는 이유는 무엇인가요?
14. hidden infrastructure dependency의 예를 세 가지 들어보세요.
15. extractive technology relationship을 피하려면 데이터, 모델, 운영 권한을 어떻게 설계해야 할까요?