26. Robust AI 단계별 학습 문서

원문 경로: /Users/keumky/Documents/New project 3/sources/mlsysbook/26-robust_ai/source.md

짧은 소개

이 장은 AI 시스템이 현실 세계에서 계속 믿을 만하게 동작하려면 무엇을 고려해야 하는지 설명해요. 여기서 중요한 질문은 단순히 “모델이 테스트 데이터에서 잘 맞히나요?”가 아니에요. 하드웨어가 작은 오류를 내도 괜찮은지, 누군가 입력을 교묘하게 바꿔도 버티는지, 시간이 지나 데이터 환경이 바뀌어도 성능을 유지하는지를 함께 봐야 해요.

원문은 Robust AI를 크게 세 갈래로 설명해요. 첫째는 하드웨어 결함처럼 시스템 아래쪽에서 생기는 문제예요. 둘째는 adversarial attack이나 data poisoning처럼 입력과 학습 데이터를 의도적으로 조작하는 문제예요. 셋째는 distribution shift와 concept drift처럼 운영 환경이 자연스럽게 바뀌는 문제예요. 여기에 소프트웨어 버그와 fault injection 도구까지 연결해서, 실제 운영 가능한 AI를 어떻게 평가하고 보호할지 다뤄요.

읽는 방법

이 장은 처음부터 모든 세부 수치와 도구 이름을 외우려고 하면 어렵게 느껴질 수 있어요. 반복해서 깊이를 높이는 방식으로 읽으면 훨씬 편해요.

읽기 단계	먼저 볼 것	목표
1회독	서론, 실제 실패 사례, 세 기둥	”AI가 왜 조용히 실패할 수 있는가?”를 잡아요
2회독	하드웨어 결함, 입력 공격, 환경 변화의 흐름도	문제가 어디서 들어와 어디로 퍼지는지 봐요
3회독	수식, 정량 수치, 도구, 방어 전략	실제 시스템 설계 시 어떤 비용과 한계가 생기는지 따져요

이 장의 학습 흐름은 이렇게 잡으면 좋아요.

현실의 실패 사례
  -> Robust AI의 세 기둥
  -> 각 기둥의 원인, 전파, 영향
  -> 감지, 완화, 복구 전략
  -> 평가 도구와 흔한 오해

이 장의 한 줄 요약

Robust AI는 AI가 하드웨어 결함, 악의적 입력 조작, 데이터 환경 변화, 소프트웨어 버그가 있는 현실 조건에서도 문제를 감지하고 피해를 줄이며 계속 믿을 만하게 동작하도록 만드는 시스템 설계 원칙이에요.

1단계: 중학교 수준

AI도 “튼튼함”이 필요해요

우리가 튼튼한 가방을 고를 때는 예쁜지만 보지 않아요. 비가 와도 젖지 않는지, 무거운 책을 넣어도 찢어지지 않는지, 지퍼가 쉽게 고장 나지 않는지도 봐요. AI도 비슷해요. 시험지처럼 깔끔한 데이터에서만 잘 맞히는 AI는 현실에서 충분하지 않아요.

현실에서는 AI가 이런 일을 만날 수 있어요.

현실 상황	쉬운 비유	AI에서 생기는 문제
컴퓨터 부품이 순간적으로 실수해요	계산기가 숫자 하나를 잘못 눌러요	모델 안의 값이 틀어질 수 있어요
누군가 입력을 일부러 속여요	표지판에 작은 스티커를 붙여 헷갈리게 해요	AI가 전혀 다른 답을 낼 수 있어요
학습 데이터가 오염돼요	선생님이 일부러 틀린 예시를 섞어 가르쳐요	AI가 잘못된 규칙을 배울 수 있어요
세상이 바뀌어요	예전 지도만 들고 새로 생긴 길을 찾아요	학습 때와 다른 현실에서 성능이 떨어져요
프로그램에 버그가 있어요	조리법에 오타가 있어 요리가 망쳐져요	데이터 처리나 예측 과정이 틀어져요

Robust AI는 고장 나지 않는 AI가 아니라, 고장을 다루는 AI예요

Robust AI를 “절대 틀리지 않는 AI”라고 생각하면 안 돼요. 현실에는 예상 못 한 일이 늘 생겨요. 그래서 튼튼한 AI는 세 가지를 잘해야 해요.

해야 할 일	쉬운 설명
감지하기	”뭔가 이상하다”는 신호를 빨리 알아차려요
버티기	전체가 멈추지 않고 중요한 기능은 유지해요
적응하기	상황이 바뀌면 방식도 조정해요

예를 들어 자율주행차가 흐린 날씨 때문에 표지판을 잘 못 읽는다면, 그냥 자신 있게 잘못 달리면 위험해요. “지금은 확신이 낮다”고 판단하고 속도를 줄이거나, 다른 센서 정보를 더 보거나, 사람에게 개입을 요청하는 쪽이 더 튼튼한 행동이에요.

조용한 실패가 특히 위험해요

일반 프로그램은 문제가 생기면 에러 메시지를 내거나 꺼지는 경우가 많아요. 그런데 AI는 조용히 틀릴 수 있어요. 의료 진단 AI가 멈추지 않고 잘못된 판단을 내리거나, 수요 예측 모델이 에러 없이 엉뚱한 예측을 계속 내놓을 수 있어요.

그래서 Robust AI의 핵심은 “작동하느냐”가 아니라 “믿을 만하게 작동하느냐”예요.

이 장의 큰 그림

AI 시스템
  ├─ 컴퓨터 부품 문제를 견뎌야 해요
  ├─ 속이려는 입력을 의심해야 해요
  ├─ 시간이 지나 바뀐 세상을 감지해야 해요
  └─ 소프트웨어 버그가 퍼지지 않게 막아야 해요

중간 정리해볼게요. Robust AI는 AI에게 갑옷을 입히는 일과 비슷해요. 갑옷은 공격을 모두 없애지는 못하지만, 공격을 줄이고, 치명상을 막고, 다음 행동을 할 시간을 벌어줘요.

2단계: 고등학교 수준

정확도에서 신뢰성으로 질문을 넓혀요

보통 모델을 평가할 때는 정확도, 지연 시간, 처리량 같은 값을 봐요. 하지만 실제 운영에서는 여기에 신뢰성이라는 축이 추가돼요.

기존 질문: 이 모델은 평균적으로 얼마나 잘 맞히나요?
Robust AI 질문: 이상한 조건에서도 얼마나 안전하게 버티나요?

이를 간단히 확률 관점으로 보면, 학습 때의 데이터 분포와 운영 때의 데이터 분포가 달라질 수 있어요.

[ P_{\text{train}}(x, y) \neq P_{\text{prod}}(x, y) ]

여기서 (x)는 입력, (y)는 정답이에요. 학습 때 본 세상과 실제 운영 세상이 달라지면, 모델이 배운 규칙이 더 이상 잘 맞지 않을 수 있어요.

Robust AI의 세 기둥

원문은 robust AI의 핵심 위험을 세 기둥으로 정리해요.

기둥	어디서 생기나요?	대표 예시	기본 대응
System-level faults	하드웨어와 인프라	bit flip, 메모리 오류, GPU 오류, 네트워크 분리	ECC, redundancy, checkpoint, monitoring
Input-level attacks	입력과 학습 데이터	adversarial example, data poisoning, backdoor	input sanitization, adversarial training, data validation
Environmental shifts	운영 환경	covariate shift, label shift, concept drift	drift detection, retraining, online learning, ensemble

이 세 기둥은 서로 완전히 분리되지 않아요. 예를 들어 하드웨어 오류가 모델 가중치를 조금 바꾸면, 원래는 통하지 않던 adversarial attack이 더 잘 통할 수 있어요. 반대로 환경 변화가 생겼는데 모니터링 코드에 버그가 있으면 성능 저하를 오래 놓칠 수 있어요.

하드웨어 결함을 논리 흐름으로 보기

하드웨어 결함은 보통 이렇게 전파돼요.

물리적 원인
  -> bit flip 또는 잘못된 연산
  -> weight, activation, gradient, 데이터 패킷 손상
  -> 학습 불안정 또는 잘못된 예측
  -> 서비스 품질 저하 또는 안전 문제

세 종류를 구분하면 이해가 쉬워요.

결함 종류	특징	쉬운 예
Transient fault	잠깐 나타났다 사라져요	우주선 입자나 전자기 간섭으로 비트가 순간적으로 바뀌어요
Permanent fault	계속 남아요	부품이 닳거나 제조 결함 때문에 특정 회로가 계속 틀려요
Intermittent fault	가끔 나타나요	온도나 진동 조건이 맞을 때만 접촉 불량이 생겨요

ML에서는 작은 오류도 커질 수 있어요. 예를 들어 신경망의 중요한 weight 하나가 바뀌면, 그 뒤 층의 activation이 바뀌고, 마지막 예측까지 달라질 수 있어요. 그래서 하드웨어 신뢰성은 단순한 인프라 문제가 아니라 모델 성능 문제예요.

입력 공격을 간단한 수학으로 보기

Adversarial attack은 원래 입력 (x)에 아주 작은 변화 (\delta)를 더해 모델을 속이는 방식으로 볼 수 있어요.

[ x_{\text{adv}} = x + \delta ]

사람에게는 (x)와 (x_{\text{adv}})가 거의 같아 보이지만, 모델은 둘을 다르게 판단할 수 있어요. 핵심은 변화량 (\delta)가 작아도, 모델의 decision boundary를 넘게 만들면 예측이 바뀐다는 점이에요.

FGSM은 이 아이디어를 더 직접적으로 사용해요. 손실이 가장 빨리 커지는 방향을 찾아서 입력을 조금 움직여요.

[ x_{\text{adv}} = x + \epsilon \cdot \text{sign}(\nabla_x J(\theta, x, y)) ]

이 식을 고등학교 수준으로 풀면 이렇게 이해하면 돼요.

기호	뜻
(x)	원래 입력
(x_{\text{adv}})	공격자가 만든 입력
(\epsilon)	얼마나 살짝 바꿀지 정하는 크기
(J)	모델이 얼마나 틀렸는지 나타내는 손실
(\nabla_x J)	입력을 어느 방향으로 바꾸면 손실이 커지는지 알려주는 기울기

즉, 모델이 가장 헷갈리는 방향으로 아주 조금 밀어버리는 거예요.

데이터 오염은 학습 전 단계의 공격이에요

Adversarial attack은 보통 학습이 끝난 뒤 입력을 조작해요. Data poisoning은 학습하기 전에 데이터 자체를 오염시켜요.

구분	공격 시점	효과
Adversarial attack	배포 후 입력 단계	특정 입력을 잘못 분류하게 해요
Data poisoning	학습 데이터 수집/학습 단계	모델이 잘못된 규칙을 배우게 해요

선생님 비유로 보면, adversarial attack은 시험 시간에 학생을 헷갈리게 하는 것이고, data poisoning은 수업 시간에 틀린 내용을 계속 가르치는 것과 같아요.

환경 변화는 분포의 변화예요

운영 환경은 계속 바뀌어요. 원문은 이를 세 가지로 나눠요.

변화 종류	수학적 표현	의미	예시
Covariate shift	(P(x))가 바뀜	입력 모양이 달라져요	낮에 학습한 자율주행 모델을 밤에 사용해요
Label shift	(P(y))가 바뀜	정답 비율이 달라져요	특정 질병의 발생 비율이 갑자기 늘어요
Concept drift	(P(y \mid x))가 바뀜	입력과 정답의 관계가 달라져요	사기 거래 패턴이 시간이 지나 바뀌어요

이 변화는 공격이 없어도 생겨요. 그래서 운영 중 모니터링이 중요해요.

전체 방어 흐름

Robust AI의 방어는 한 번 막고 끝나는 구조가 아니에요.

1. 관찰해요
   - 하드웨어 오류, 입력 이상, 데이터 분포, 모델 성능을 봐요

2. 판단해요
   - 정상 범위인지, 공격인지, 환경 변화인지 구분해요

3. 완화해요
   - 재시도, fallback, input filtering, ensemble, checkpoint 복구 등을 써요

4. 적응해요
   - retraining, fine-tuning, online learning, 모델 교체를 고려해요

중간 정리해볼게요. 2단계에서의 핵심은 Robust AI를 “오류가 생기면 어디로 전파되고, 어떤 관측값으로 잡고, 어떤 비용을 내고 막을 것인가?”라는 시스템 문제로 보는 거예요.

3단계: 대학교 수준

1. Introduction to Robust AI Systems

원문은 먼저 ML 시스템의 실패 방식이 전통적인 소프트웨어와 다르다고 설명해요. 일반 소프트웨어는 서버가 죽거나 에러 메시지가 뜨는 식으로 크게 실패하는 경우가 많아요. 반면 ML 시스템은 조용히 실패할 수 있어요. 자율주행 인식기가 트럭을 하늘로 잘못 분류하거나, 수요 예측 모델이 아무 에러 없이 엉뚱한 예측을 계속 내는 식이에요.

이 조용한 실패는 robust AI가 필요한 가장 중요한 이유예요. ML 시스템은 단순히 코드 버그만 상대하지 않아요. 학습 데이터와 달라지는 현실, 물리 하드웨어의 오류, 악의적 입력, 데이터 오염, 소프트웨어 스택의 복잡성까지 함께 상대해야 해요.

원문은 Robust AI를 “동적이고 불확실한 환경에서도 안전하고 효과적으로 동작하는 ML 시스템을 설계하는 원칙”으로 다뤄요. 이때 중요한 특성은 다음 세 가지예요.

특성	의미
Fault tolerance	오류가 있어도 전체 시스템이 즉시 무너지지 않아요
Error resilience	오류가 결과에 미치는 영향을 줄여요
Sustained performance	시간이 지나거나 조건이 바뀌어도 핵심 성능을 유지해요

다만 robustness는 공짜가 아니에요. 원문은 에러 정정이 메모리 대역폭을 더 쓰고, 중복 처리가 에너지를 더 쓰며, 지속적 모니터링이 연산 오버헤드를 만든다고 설명해요. 즉 robust AI 설계는 안전성, 성능, 에너지, 열 관리 사이의 균형 문제예요.

2. Real-World Robustness Failures

이 장은 실제 실패 사례를 통해 robust AI가 추상적인 개념이 아니라 운영상의 필수 조건임을 보여줘요.

2.1 Cloud Infrastructure Failures

2017년 AWS US-East-1 장애는 유지보수 중 잘못된 명령이 여러 서버 종료로 이어지고, 많은 서비스에 연쇄 영향을 준 사례예요. Alexa 같은 AI 서비스도 응답하지 못했어요. 이 사례의 핵심은 클라우드 기반 ML 서비스가 모델만 튼튼하다고 안전해지는 것이 아니라, 인프라 장애와 사람의 운영 실수에도 대비해야 한다는 점이에요.

Facebook의 silent data corruption 사례도 중요해요. 파일 크기 확인 과정에서 정상 파일이 가끔 크기 0으로 반환되어 압축 해제가 실패했고, 출력 데이터베이스에 항목이 누락됐어요. 문제는 이 오류가 항상 재현되지 않았다는 점이에요. ML 학습에서는 이런 조용한 데이터 손상이 학습 데이터나 파이프라인을 오염시켜 모델 정확도를 떨어뜨릴 수 있어요.

2.2 Edge Device Vulnerabilities

자율주행차는 cloud보다 현장 조건의 영향을 크게 받아요. Tesla Autopilot 사고 사례에서는 밝은 하늘을 배경으로 흰색 트레일러를 구분하지 못한 인식 실패가 치명적 결과로 이어졌어요. Uber 자율주행 테스트 차량 사고에서는 보행자를 회피해야 할 장애물로 분류하지 못한 소프트웨어 문제가 언급돼요.

여기서 중요한 점은 edge AI가 지연 시간을 줄이기 위해 현장에서 직접 판단하지만, 바로 그 현장에는 조명, 날씨, 센서 노이즈, 예외 상황이 많다는 거예요. 따라서 perception, decision-making, control 전체에 failsafe가 필요해요.

2.3 Embedded System Constraints

임베디드 시스템은 자원 제약과 안전 요구가 동시에 강해요. NASA Mars Polar Lander는 착륙 다리 전개 진동을 착륙 신호로 오해해 엔진을 너무 일찍 껐고, 임무 실패로 이어졌어요. Boeing 787 사례에서는 발전기 제어 장치가 긴 연속 동작 후 동시에 failsafe mode에 들어갈 수 있는 소프트웨어 문제가 언급돼요.

스마트 심박조율기 같은 의료 장치에서는 작은 예외 상황도 생명과 연결될 수 있어요. 이런 시스템에서는 모델 불확실성, 드문 edge case, 설명하기 어려운 모델 동작이 모두 위험 요소가 돼요.

3. A Unified Framework for Robust AI

원문은 다양한 실패 사례를 하나의 프레임워크로 묶어요. ML 성능을 accuracy와 latency로만 보지 않고, reliability engineering의 개념을 결합해야 한다고 설명해요.

3.1 ML Performance에서 System Reliability로

ML 모델의 성능은 하드웨어의 신뢰성과 분리되지 않아요. 원문은 단일 bit flip이 신경망의 중요한 weight를 바꾸면 ImageNet 정확도가 크게 떨어질 수 있다고 설명해요. 대형 Transformer 모델은 한 번의 추론에도 매우 많은 부동소수점 연산을 수행하므로, 오류가 들어올 기회도 많아요.

Reliability engineering 관점에서는 다음 질문을 던져요.

질문	Robust AI에서의 의미
어떤 fault가 가능한가요?	fault model을 정의해요
fault가 어디까지 전파되나요?	error model과 propagation을 봐요
언제 감지하나요?	monitoring, checksum, anomaly detection을 설계해요
어떻게 복구하나요?	checkpoint, failover, graceful degradation을 사용해요

3.2 Three Pillars

세 기둥은 다음과 같아요.

기둥	설명	대표 위험
System-level faults	계산 인프라에서 시작되는 오류예요	transient, permanent, intermittent hardware faults
Input-level attacks	입력 또는 학습 데이터를 조작해 모델 행동을 바꿔요	adversarial attack, data poisoning, prompt injection
Environmental shifts	운영 데이터가 학습 가정과 달라져요	distribution shift, concept drift, label shift

3.3 Common Robustness Principles

세 기둥은 원인이 다르지만 공통 원칙이 있어요.

원칙	설명	예시
Detection and monitoring	문제가 결과를 망치기 전에 신호를 잡아요	온도, 전압, 메모리 오류, 입력 분포, p-value, MMD
Graceful degradation	전체 실패 대신 핵심 기능을 유지해요	ECC, fallback model, quantized model로 축소 운영
Adaptive response	감지된 조건에 따라 시스템이 대응을 바꿔요	error correction 활성화, retraining, preprocessing 변경

3.4 Pipeline 전체 통합

Robustness는 한 컴포넌트에만 붙이는 기능이 아니에요. 데이터 수집, 전처리, 학습, 평가, 배포, 모니터링, 업데이트 전 과정에 들어가야 해요. 예를 들어 학습 데이터 검증이 약하면 poisoning에 취약하고, 운영 모니터링이 약하면 distribution shift를 늦게 발견하며, checkpoint가 약하면 긴 학습 작업이 하드웨어 오류 한 번에 크게 손상될 수 있어요.

4. Hardware Faults

하드웨어 결함은 모든 ML 연산이 물리 장치 위에서 실행된다는 사실에서 출발해요. 특히 ML은 연산량이 많고, 학습 시간이 길며, 파라미터가 민감하고, 분산 의존성이 커서 결함의 영향을 크게 받아요.

4.1 Hardware Fault Impact on ML Systems

원문은 ML 시스템이 하드웨어 fault에 민감한 이유를 네 가지로 설명해요.

이유	설명
Computational intensity	초당 수많은 연산을 하므로 오류가 끼어들 기회가 많아요
Long-running training	며칠 또는 몇 주 동안 학습하므로 fault를 만날 확률이 커져요
Parameter sensitivity	weight의 작은 손상이 출력에 큰 변화를 만들 수 있어요
Distributed dependencies	많은 노드가 함께 학습하므로 한 지점의 실패가 전체 작업에 영향을 줄 수 있어요

신경망에서는 하나의 bit flip이 단순히 숫자 하나의 오류로 끝나지 않아요. sign bit가 바뀌면 feature map의 방향이 뒤집히고, 다음 층으로 cascade가 이어질 수 있어요.

4.2 Transient Faults

Transient fault는 잠깐 나타났다가 사라지는 결함이에요. 하드웨어를 영구적으로 망가뜨리지는 않지만, 그 순간의 계산이나 메모리 값을 틀리게 만들 수 있어요.

주요 원인은 다음과 같아요.

원인	설명
Single Event Upsets	우주선이나 방사선 입자가 memory 또는 logic bit를 뒤집어요
Voltage fluctuation	전원 공급 불안정으로 회로가 정상 범위를 벗어나요
EMI	주변 전자기파가 회로에 간섭해요
ESD	정전기 방전이 순간 전압 변화를 만들어요
Crosstalk, ground bounce	인접 신호나 동시 스위칭이 의도치 않은 전기적 간섭을 만들어요
Timing violation	신호가 정해진 시간 안에 안정되지 못해요

정량적으로도 중요해요. 원문은 최신 미세 공정에서 soft error rate가 과거 공정보다 크게 높아질 수 있고, 대규모 accelerator 클러스터에서는 개별 장치의 MTBF가 길어도 전체 클러스터 관점의 실패 간격은 짧아진다고 설명해요. 예를 들어 accelerator 1000개를 묶으면, 각 장치가 드물게 실패해도 전체 시스템에서는 실패가 훨씬 자주 관측돼요.

메모리 계층도 robustness 비용을 크게 만들어요.

메모리/보호	Robustness 관점
ECC memory	bit error를 감지하고 일부는 고치지만 대역폭 오버헤드가 있어요
Memory scrubbing	배경에서 메모리를 주기적으로 검사하지만 대역폭과 전력을 사용해요
Cache parity/ECC	cache 계층별로 detection과 replay를 지원해요
Persistent storage redundancy	Reed-Solomon 같은 코드로 저장 오류를 견뎌요

Training 단계에서는 weight, gradient, training sample, label 손상이 convergence를 방해해요. Inference 단계에서는 activation이나 model parameter 손상이 잘못된 예측으로 이어져요. TinyML이나 BNN처럼 자원이 작고 수치 표현이 단순한 환경에서는 bit flip 하나의 영향이 더 클 수 있어요.

4.3 Permanent Faults

Permanent fault는 지속되는 물리적 결함이에요. 제조 결함, electromigration, oxide breakdown, thermal stress처럼 시간이 지나며 회로가 손상되는 원인이 있어요.

대표 사례로 원문은 Intel Pentium FDIV bug를 들어요. lookup table 오류 때문에 특정 부동소수점 나눗셈에서 잘못된 결과가 나왔고, 과학 계산이나 금융 계산처럼 정밀도가 중요한 영역에 영향을 줄 수 있었어요. ML 시스템에서도 faulty floating-point unit이 training 또는 inference 계산에 계속 작은 오류를 넣으면, 모델 신뢰성을 해칠 수 있어요.

Permanent fault의 전파 방식은 다양해요.

fault 형태	의미
Stuck-at fault	값이 0 또는 1에 고정돼요
Device failure	transistor나 memory cell이 동작하지 않아요
Bridging fault	신호선이 의도치 않게 연결돼요
Delay fault	논리값은 맞아도 너무 늦게 도착해요
Interconnect fault	끊김, 고저항, capacitance 증가로 신호 품질이 나빠져요
Memory coupling fault	인접 memory cell 상태가 서로 영향을 줘요

Permanent fault는 사라지지 않으므로 replacement, redundancy, ECC, checkpoint/restart가 중요해요.

4.4 Intermittent Faults

Intermittent fault는 가끔 나타났다 사라지는 결함이에요. 재현이 어렵기 때문에 진단이 특히 힘들어요. 원인은 aging, thermal cycling, mechanical stress, solder joint degradation, manufacturing residue, humidity, vibration, loose connection 등일 수 있어요.

ML 시스템에서는 intermittent fault가 더 난감해요. 같은 입력에 대해 어떤 때는 맞고 어떤 때는 틀릴 수 있고, 학습 중 gradient나 loss가 가끔 이상해져서 전체 convergence가 불안정해질 수 있어요. 저장 장치의 intermittent fault는 checkpoint나 입력 데이터를 가끔 손상시킬 수 있어요.

대응은 한 계층으로 충분하지 않아요.

계층	대응
하드웨어	더 견고한 설계, 환경 제어, redundancy, error detection
소프트웨어	runtime monitoring, anomaly detection, data validation, ensemble
운영	정기 점검, 조기 교체, graceful degradation, adaptive control

4.5 Hardware Fault Detection and Mitigation

원문은 hardware-level과 software-level detection을 모두 설명해요.

방법	계층	핵심 아이디어
BIST	하드웨어	회로가 스스로 test pattern을 실행하고 기대값과 비교해요
Parity, CRC, ECC	하드웨어/데이터	중복 비트나 checksum으로 저장/전송 오류를 잡아요
DMR/TMR	하드웨어 redundancy	같은 계산을 2개 또는 3개가 수행하고 결과를 비교해요
Hot spares	인프라	문제가 있는 worker를 대기 장비로 교체해요
Watchdog timer	하드웨어/임베디드	정해진 시간 안에 신호가 없으면 reset이나 failover를 해요
Runtime monitoring	소프트웨어	예측, activation, 성능 지표의 이상을 관찰해요
Consistency check	소프트웨어/분산	checksum, hash, range check로 데이터 무결성을 확인해요
Heartbeat/timeout	분산 시스템	노드가 살아 있는지 주기적으로 확인해요
SIFT	소프트웨어 redundancy	N-version programming이나 software ECC로 fault tolerance를 높여요

중요한 차이는 DMR과 TMR이에요. DMR은 두 결과를 비교해 불일치를 감지할 수 있지만, 어느 쪽이 맞는지 항상 알 수는 없어요. TMR은 세 결과 중 다수결로 fault masking이 가능해요. 하지만 비용이 더 들어요.

5. Intentional Input Manipulation

이 절은 무작위 하드웨어 오류가 아니라, 누군가 의도적으로 모델 행동을 바꾸려는 경우를 다뤄요.

5.1 Adversarial Attacks

Adversarial attack은 사람에게 거의 보이지 않는 작은 입력 변화를 만들어 모델의 예측을 바꾸는 공격이에요. 원문은 모델이 의미를 이해한다기보다 고차원 공간의 통계적 패턴과 decision boundary를 학습하기 때문에 이런 취약점이 생긴다고 설명해요.

FGSM은 손실 함수의 기울기를 이용해 한 번에 공격 입력을 만들어요. PGD는 이를 여러 번 반복하고 허용된 perturbation 범위 안으로 다시 projection해 더 강력한 공격을 만들어요. 물리 세계 공격은 스티커, 패치, 조명, 각도 변화 속에서도 공격이 유지되도록 만들어 자율주행 같은 시스템에 특히 위험해요.

5.2 Data Poisoning Attacks

Data poisoning은 학습 데이터에 악성 샘플을 섞어 모델이 잘못된 연관성을 배우게 해요.

poisoning 방식	설명
Label flipping	정답 라벨을 일부러 바꿔요
Backdoor attack	특정 trigger가 있을 때만 원하는 오답을 내게 해요
Gradient-based poisoning	학습 gradient가 공격자 목표 쪽으로 움직이게 샘플을 설계해요

이 공격은 전체 clean accuracy가 많이 떨어지지 않아도 특정 class나 trigger에서 큰 피해를 만들 수 있어 탐지가 어려워요.

5.3 Detection and Mitigation

입력 공격 방어는 여러 방법을 겹쳐야 해요.

방어	장점	비용/한계
Input sanitization	JPEG compression, denoising, random transform으로 perturbation을 줄여요	정상 입력 품질도 일부 손상될 수 있어요
Adversarial training	공격 예시를 학습에 포함해 robust accuracy를 높여요	학습 시간이 크게 늘고 clean accuracy가 낮아질 수 있어요
Certified defense	특정 범위 안의 perturbation에 수학적 보장을 줘요	Monte Carlo sampling 등으로 추론 비용이 커질 수 있어요
Ensemble	여러 모델의 불일치나 entropy로 이상 입력을 잡아요	추론 시간과 메모리가 모델 수만큼 증가해요

6. Environmental Shifts

환경 변화는 악의가 없어도 생겨요. 현실 세계가 계속 변하기 때문이에요.

6.1 Distribution Shift and Concept Drift

원문의 예시는 의료 X-ray 모델이에요. 최신 병원 데이터로 학습한 모델을 오래된 장비를 쓰는 시골 병원에 배포하면, 질병 자체는 같아도 이미지 특성이 달라져 성능이 떨어질 수 있어요.

세 가지 shift를 다시 엄밀하게 정리해볼게요.

종류	수식 관점	예시
Covariate shift	(P(x))가 변하고 (P(y \mid x))는 유지돼요	낮 이미지로 학습한 모델을 밤, 비, 눈, 안개 조건에 배포해요
Concept drift	(P(y \mid x))가 시간에 따라 변해요	사기 거래 규칙이나 추천 선호가 바뀌어요
Label shift	(P(y))가 변해요	특정 질병이나 작물 병해의 비율이 계절, 사건에 따라 달라져요

6.2 Monitoring and Adaptation

환경 변화 대응은 감지와 적응으로 나뉘어요.

방법	역할
MMD, KS test, PSI	학습 분포와 운영 분포가 얼마나 다른지 측정해요
Online learning	새 데이터를 받아 모델을 계속 조금씩 조정해요
Elastic Weight Consolidation	새 지식을 배우면서 예전 지식을 잊지 않도록 도와요
Model ensemble/selection	환경별 전문 모델을 두고 상황에 맞는 모델을 선택해요
Federated learning	여러 배포 환경에서 privacy를 유지하며 적응해요

이때도 비용이 있어요. online learning은 추론 지연과 메모리 오버헤드를 만들 수 있고, federated learning은 통신 비용이 커질 수 있어요.

7. Robustness Evaluation Tools

이 절은 개념을 도구와 연결해요.

위험	평가 도구/프레임워크 예
Hardware fault	PyTorchFI, TensorFI 같은 fault injection 도구
Adversarial attack	FGSM, PGD 구현을 제공하는 adversarial attack library
Distribution shift	statistical distance와 drift detection framework

중요한 점은 robust evaluation을 개발 workflow에 통합해야 한다는 거예요. 한 번 논문식 benchmark를 돌리는 것이 아니라, 학습, 검증, 배포, 모니터링 과정에서 계속 평가해야 해요.

8. Input-Level Attacks and Model Robustness

이 절은 앞의 입력 조작 내용을 더 깊게 확장해요. 하드웨어 신뢰성은 물리 계산 기판을 보호하는 문제이고, model robustness는 learned representation과 decision boundary를 보호하는 문제예요.

8.1 Adversarial Attack의 취약점

신경망은 고차원 입력 공간에서 decision boundary를 만들어요. 이미지 하나가 224 x 224 x 3 차원이라면 입력 차원이 매우 커요. 각 픽셀에 아주 작은 변화가 누적되면 사람 눈에는 거의 차이가 없어도 모델 내부에서는 큰 이동이 될 수 있어요. 원문은 이를 human perception과 machine perception의 차이로 설명해요.

8.2 Attack Categories and Mechanisms

공격 범주는 다음과 같아요.

범주	대표 기법	특징
Gradient-based	FGSM, PGD, JSMA	모델 gradient를 이용해 손실을 키우는 방향으로 입력을 바꿔요
Optimization-based	C&W, EAD	가장 작은 perturbation으로 misclassification을 만들도록 최적화해요
Transfer-based	surrogate model attack	한 모델에서 만든 공격이 다른 모델에도 통하는 transferability를 이용해요
Physical-world	adversarial patch, adversarial object	스티커, 3D 물체, 도로 표식처럼 실제 센서 입력을 속여요

FGSM 식은 이 절의 핵심 수식이에요.

[ x_{\text{adv}} = x + \epsilon \cdot \text{sign}\big(\nabla_x J(\theta, x, y)\big) ]

이 식의 의미는 “입력 (x)를 손실 (J)가 커지는 방향으로 (\epsilon)만큼 움직인다”예요. PGD는 이 과정을 반복하되, 원래 입력에서 너무 멀어지지 않도록 norm ball 안으로 projection해요. JSMA는 Jacobian으로 어떤 입력 feature가 target class에 큰 영향을 주는지 찾아 선택적으로 바꿔요.

C&W는 perturbation 크기를 줄이면서도 확실한 오분류를 만들도록 최적화 문제로 공격을 구성해요. EAD는 L1과 L2 성격을 함께 쓰는 elastic net regularization으로 더 sparse하고 국소적인 perturbation을 만들 수 있어요.

Transfer-based attack은 실전에서 중요해요. 공격자가 target model의 내부 gradient를 몰라도 비슷한 surrogate model을 만들어 공격 예시를 생성하고, 그것이 target model에도 통할 수 있기 때문이에요.

Physical-world attack은 디지털 이미지만 바꾸는 수준을 넘어가요. stop sign에 작은 스티커를 붙여 모델이 speed limit sign으로 착각하게 만들거나, 3D 출력물을 특정 물체로 오분류하게 만드는 식이에요.

8.3 Impact on ML

Adversarial attack은 단순한 accuracy 하락이 아니라 시스템 위험을 만들어요. 원문은 stop sign 스티커 공격, Microsoft Tay 챗봇 사례, 의료 영상과 금융 시스템 위험을 언급해요.

핵심 영향은 다음과 같아요.

영향	설명
Safety risk	자율주행, 의료, 항공 같은 영역에서 잘못된 행동으로 이어질 수 있어요
Trust erosion	사용자가 모델을 믿기 어려워져요
Operational cost	adversarial training, preprocessing, monitoring 때문에 비용과 latency가 늘어요
Maintenance burden	새로운 공격이 나오면 방어도 계속 업데이트해야 해요

8.4 Data Poisoning 심화

Data poisoning은 training pipeline을 공격해요. 원문은 세 단계를 설명해요.

Injection
  -> poisoned sample을 학습 데이터에 넣어요
Training
  -> 모델이 잘못된 패턴, bias, backdoor를 배워요
Deployment
  -> 공격자가 특정 입력이나 trigger로 잘못된 동작을 끌어내요

Poisoning의 유형은 availability attack, targeted poisoning, backdoor poisoning, subpopulation poisoning으로 나뉘어요.

유형	목표
Availability attack	전체 모델 성능을 낮춰 쓸 수 없게 만들어요
Targeted poisoning	특정 class나 특정 입력만 잘못 분류하게 해요
Backdoor poisoning	trigger가 있을 때만 공격자 의도대로 행동하게 해요
Subpopulation poisoning	특정 demographic 또는 feature cluster에만 성능 저하를 만들어요

공격 방법은 label 변경, input feature 변경, synthetic malicious sample 생성, web scraping이나 crowdsourcing 데이터 수집 경로 악용, online learning stream에 점진적 오염 주입, insider access 악용 등이 있어요.

원문은 Nightshade 사례도 소개해요. 이는 예술가가 자신의 작품이 동의 없이 생성 모델 학습에 쓰이는 것을 막기 위해 이미지에 사람 눈에는 거의 보이지 않는 변화를 넣는 방어적 poisoning 사례예요. 하지만 같은 기술은 합법적 학습 파이프라인을 방해하는 데 악용될 수도 있어 dual-use dilemma를 만들어요.

8.5 Distribution Shifts 심화

Distribution shift는 배포 후 가장 흔한 robustness 문제 중 하나예요. 원문은 domain mismatch, temporal drift, contextual changes, unrepresentative training data를 주요 원인으로 설명해요.

또한 shift mechanism으로는 data source 변화, 시간에 따른 변화, domain-specific variation, selection bias, feedback loop, adversarial manipulation이 있어요. 특히 feedback loop는 모델의 예측이 사용자 행동을 바꾸고, 바뀐 사용자 행동이 다시 미래 데이터를 바꾸는 구조라서 시스템적으로 까다로워요.

효과는 다음과 같아요.

효과	설명
Prediction degradation	운영 데이터가 달라져 예측이 체계적으로 틀려져요
Reliability loss	사용자는 모델이 일관되지 않다고 느껴요
Bias amplification	원래 약했던 집단에서 더 자주 실패할 수 있어요
Operational risk	자동화된 의사결정 downstream에 연쇄 실패를 만들 수 있어요
Maintenance complexity	drift detection, retraining, rollback, validation이 필요해져요

Tesla Autopilot의 construction zone, unusual lane marking, weather 조건 문제나 병원 간 의료 영상 장비 차이는 distribution shift가 실제 시스템에서 어떻게 나타나는지 보여주는 사례예요.

8.6 Input Attack Detection and Defense

Adversarial attack defense는 detection과 mitigation으로 나뉘어요.

Detection 방법:

방법	설명
Statistical tests	KS test, Anderson-Darling test로 입력 분포 이상을 봐요
Feature squeezing	색상 정밀도나 해상도를 낮춰 perturbation 의존성을 줄이고 예측 변화를 확인해요
Uncertainty estimation	Bayesian neural network, ensemble, Monte Carlo dropout으로 불확실성이 높은 입력을 찾습니다

Defense 방법:

방법	설명	주요 trade-off
Adversarial training	공격 예시를 학습에 넣어요	학습 시간, 메모리, clean accuracy 비용
Defensive distillation	teacher의 soft label로 student를 학습해 민감도를 낮춰요	강한 공격에 충분하지 않을 수 있어요
Input preprocessing	denoising, JPEG, random resizing, padding 등을 적용해요	정상 입력도 변형될 수 있어요
Ensemble	다양한 모델의 예측을 결합해요	추론 비용 증가
Robustness metrics/benchmarks	adversarial accuracy, distortion, MNIST-C/CIFAR-10-C/ImageNet-C 등을 봐요	benchmark만으로 실전 위협 전체를 대표하지 못해요

Data poisoning defense는 데이터 중심이에요.

방어	설명
Statistical outlier detection	Z-score, Tukey, Mahalanobis distance로 이상치를 찾아요
Clustering	K-means, DBSCAN 등으로 비정상 cluster를 찾아요
Autoencoder	reconstruction error가 큰 샘플을 의심해요
Data cleaning/validation	deduplication, missing value 처리, range/type/cross-field check를 해요
Provenance/lineage	데이터 출처와 변환 이력을 기록해요
Robust optimization	Huber loss, Tukey loss, trimmed mean, minimax objective 등으로 이상치 영향을 줄여요
Data augmentation/randomization	모델이 특정 poisoned pattern에 과하게 민감해지지 않게 해요
Governance/access control	최소 권한 원칙과 audit log로 데이터 변조를 막아요

Distribution shift adaptation은 운영 중심이에요.

방법	설명
Statistical tests	KS, Anderson-Darling으로 train/test 분포 차이를 봐요
Divergence metrics	KL divergence, JS divergence로 분포 차이를 정량화해요
Uncertainty quantification	분포 밖 입력에서 예측 불확실성이 커지는지 봐요
Domain classifier	train domain과 test domain을 구분할 수 있으면 shift가 있다고 봐요
Transfer learning	target domain의 적은 labeled data로 fine-tuning해요
Continual learning	EWC, GEM 등으로 새 분포를 배우되 catastrophic forgetting을 줄여요
Data augmentation	다양한 변형을 학습해 unseen distribution에 강하게 해요
Regular update	새 데이터로 모델을 주기적으로 retrain 또는 fine-tune해요
Robust metrics	F1, AUPRC처럼 class imbalance와 shift에 더 적합한 지표를 써요

8.7 Self-Supervised Learning for Robustness

원문은 self-supervised learning이 더 robust한 representation을 만들 가능성을 설명해요. SSL은 label만 외우는 대신 데이터 구조와 regularity를 학습해요. Contrastive learning은 같은 대상의 다양한 view에서 invariant feature를 배우고, masked modeling은 표면 패턴보다 context를 활용하게 만들 수 있어요.

다만 SSL이 만능은 아니에요. 여전히 adversarial attack에 취약할 수 있고, 왜 언제 robustness가 좋아지는지 이론이 완전히 정리된 것은 아니며, pretraining 비용이 큽니다. 원문은 이를 유망하지만 진행 중인 연구 방향으로 제시해요.

9. Software Faults

소프트웨어 결함은 하드웨어, 입력 공격, 환경 변화와 다른 네 번째 차원의 문제예요. 인간의 설계와 구현 실수에서 생기며, ML pipeline 어디에서나 발생할 수 있어요.

9.1 Software Fault Properties

소프트웨어 fault의 특징은 다음과 같아요.

특징	설명
Diversity	syntax error, logic error, memory leak, concurrency bug, integration bug 등 형태가 다양해요
Propagation	낮은 수준의 tensor allocation이나 preprocessing 오류가 학습, 추론, 평가로 퍼져요
Intermittency	높은 부하, 특정 hardware, 드문 입력에서만 나타날 수 있어요
Model interaction	데이터 변환 버그가 입력 분포를 바꾸거나 serving과 training 간 차이를 만들어요
External dependency	OS, library version, hardware platform 차이로 미묘한 버그가 생겨요

9.2 Software Fault Propagation

전파 메커니즘은 여러 가지예요.

메커니즘	영향
Resource mismanagement	memory leak, GPU memory 미해제로 학습 중단이나 성능 저하가 생겨요
Concurrency/synchronization error	race condition, deadlock, inconsistent state가 생겨요
Compatibility issue	library upgrade나 train/inference 환경 차이가 재현성을 깨요
Numerical instability	overflow, underflow, division by zero, rounding error가 gradient와 convergence를 흔들어요
Poor exception handling	시스템이 조용히 실패하거나 진단이 어려워져요

9.3 Software Fault Effects on ML

소프트웨어 fault는 latency 증가, throughput 감소, crash뿐 아니라 잘못된 예측을 만들 수 있어요. 특히 preprocessing 오류나 feature encoding 불일치는 모델이 전혀 다른 입력 분포를 받게 만들 수 있어요. 보안 측면에서는 buffer overflow, 부적절한 validation, unguarded input이 공격 표면이 될 수 있어요.

분산 학습에서는 checkpointing이나 serialization fault가 긴 학습 작업을 중단시키거나 모델 상태를 손상시킬 수 있어요. 또한 비결정적인 버그는 디버깅 비용을 크게 높여 모델 개발과 운영 속도를 늦춰요.

9.4 Software Fault Detection and Prevention

대응은 개발, 테스트, 배포, 운영 전 과정에 걸쳐야 해요.

단계	방법	역할
개발	unit test, static analysis, code review	작은 결함을 일찍 잡아요
통합	integration test, regression test	모듈 간 상호작용과 변경 후 회귀를 확인해요
운영	logging, monitoring, profiling	실제 환경에서 latency, memory, exception, throughput을 봐요
설계	structured exception, assertion, modular architecture	오류 전파를 줄여요
복구	checkpoint, fallback model, failover	중단 후 다시 시작하거나 안전한 대체 경로를 써요
환경	Docker, Kubernetes 같은 containerization	의존성 차이로 인한 재현성 문제를 줄여요
배포	CI/CD에 테스트와 검증 삽입	검증되지 않은 코드가 운영으로 나가지 않게 해요

10. Fault Injection Tools and Frameworks

Fault injection은 일부러 fault를 넣어 시스템이 어떻게 반응하는지 보는 평가 방법이에요. 실제 장애가 날 때까지 기다리지 않고, 통제된 실험으로 취약 지점을 찾는 방식이에요.

10.1 Fault and Error Models

Fault model은 하드웨어 결함이 어떻게 나타나는지 정의해요. 예를 들어 single-bit flip, stuck-at, burst error, multi-bit error처럼요. Error model은 그 fault가 시스템 동작에 어떤 오류로 보이는지 설명해요. 예를 들어 corrupted weight, miscomputed activation, wrong prediction 같은 결과예요.

중요한 구분은 abstraction level이에요. architectural register 수준의 bit flip과 PyTorch tensor 값의 bit flip은 비슷해 보이지만, 실제 hardware propagation과 masking을 반영하는 정도가 달라요. 낮은 수준은 정확하지만 느리고 복잡하고, 높은 수준은 빠르고 쓰기 쉽지만 현실 hardware behavior를 놓칠 수 있어요.

10.2 Hardware-Based Fault Injection

하드웨어 기반 fault injection은 실제 물리 시스템에 fault를 넣어요.

방법	장점	한계
FPGA-based injection	특정 bit나 위치를 정밀하게 겨냥할 수 있어요	하드웨어 준비와 재구성이 필요해요
Radiation/beam testing	우주선 입자 같은 실제 환경을 매우 현실적으로 재현해요	비용이 높고 특정 bit를 정확히 겨냥하기 어려워요

이 방법은 fidelity가 높지만 비용, 확장성, 유연성 문제가 있어요. 그래서 소프트웨어 기반 도구를 검증하는 기준으로도 중요해요.

10.3 Software-Based Fault Injection

소프트웨어 기반 도구는 ML framework 안에서 weight, activation, gradient, tensor, computational graph를 조작해 하드웨어 fault 효과를 흉내 내요.

장점은 빠르고, 유연하며, 접근성이 좋다는 점이에요. 수천 번의 injection 실험을 큰 비용 없이 돌릴 수 있고, PyTorch나 TensorFlow workflow에 통합하기 쉬워요.

한계는 fidelity예요. 실제 하드웨어의 cache, memory hierarchy, timing, masking, data movement를 완전히 반영하지 못할 수 있어요. 따라서 소프트웨어 실험 결과는 실제 하드웨어 측정이나 더 낮은 수준의 모델과 함께 해석해야 해요.

대표 도구는 다음과 같아요.

도구	대상/특징
Ares	Keras 기반으로 시작해 DNN fault injection을 체계화했고 PyTorch도 지원해요
PyTorchFI	PyTorch 모델의 weight, activation, gradient에 fault를 넣어요
PyTorchALFI	PyTorchFI를 자동차 안전 평가 맥락으로 확장해요
Dr. DNA	fault injection workflow를 더 간결한 Python API로 제공해요
GoldenEye	AdaptivFloat, BlockFloat, bfloat16 같은 수치 형식의 fault tolerance를 연구해요
TensorFI	TensorFlow computational graph에 fault를 넣어요
BinFi	중요한 bit에 집중해 injection 속도를 높이려 해요
NVBitFI	GPU assembly 수준에서 fault를 넣어 더 낮은 수준의 동작을 봐요

10.4 ML-Specific Injection Tools

도메인별 도구도 있어요.

도구	도메인	설명
DriveFI	자율주행	perception과 control pipeline에 fault를 넣어 end-to-end 안전성을 봐요
PyTorchALFI	자율주행	camera, LiDAR 같은 multimodal sensor data fault를 평가해요
MAVFI	UAV/로보틱스	ROS 기반으로 sensor, actuator, flight control fault를 평가해요

10.5 Bridging Hardware-Software Gap

원문은 software-based injection과 실제 hardware behavior 사이의 abstraction gap을 강조해요. 실제 hardware fault는 single point, same row, bullet wake, shatter glass처럼 공간적 패턴을 가질 수 있어요. 단순히 tensor 값 하나를 바꾸는 simulation은 이런 패턴을 놓칠 수 있어요.

Fidelity는 이 간극을 줄이려는 도구예요. 모든 hardware bit flip을 다 모델링하기보다, hardware fault가 software-visible state에서 어떻게 나타나는지 관찰하고 equivalent fault class를 묶어 효율적으로 모델링해요.

핵심 아이디어는 세 가지예요.

아이디어	설명
Fault propagation	hardware에서 시작한 fault가 register, memory, numeric operation을 거쳐 software 값에 어떻게 보이는지 봐요
Fault equivalence	비슷한 software-visible 결과를 내는 fault들을 대표 사례로 묶어요
Layered modeling	hardware origin부터 weight, activation, prediction 영향까지 계층적으로 연결해요

이런 hardware-aware modeling은 안전 중요 시스템에서 특히 중요해요. 잘못된 fault model을 고르면, 평가 결과가 실제 위험을 과소평가하거나 과대평가할 수 있어요.

11. Fallacies and Pitfalls

원문은 robust AI에서 흔한 오해를 정리해요.

오해/함정	왜 문제인가요?
Adversarial defense에는 trade-off가 없다고 믿어요	clean accuracy 하락, 연산 오버헤드, 새 공격에 대한 취약성이 생길 수 있어요
알려진 공격 몇 개로만 테스트해요	새로운 공격이나 복합 장애에 대한 false confidence가 생겨요
다양한 데이터만 모으면 distribution shift가 해결된다고 봐요	현실 변화는 무한하고 예측 불가능하므로 monitoring과 adaptive response가 필요해요
한 threat의 방어가 모든 failure mode를 막는다고 생각해요	adversarial training이 hardware fault나 poisoning을 자동으로 막지는 못해요
failure mode가 독립적이라고 가정해요	실제로는 hardware, adversarial, environmental, software 문제가 서로 증폭할 수 있어요

복합 취약점 예시는 특히 중요해요.

복합 상황	설명
Hardware-adversarial interaction	bit flip으로 바뀐 weight가 새로운 adversarial vulnerability를 만들 수 있어요
Environmental-software cascade	distribution shift가 생겼는데 monitoring bug 때문에 감지가 늦어질 수 있어요
Attack-enabled distribution exploitation	자연 drift 방향에 맞춘 poisoning이 detection을 피하면서 성능 저하를 가속할 수 있어요
Triple-threat scenario	bit flip, adversarial marking, seasonal shift가 동시에 작용할 수 있어요

따라서 robust AI는 threat를 하나씩 따로 막는 체크리스트가 아니에요. failure mode analysis, cross-domain testing, layered defense가 필요해요.

12. Summary

이 장의 결론은 분명해요. Robust AI는 모델 개발 후 마지막에 붙이는 옵션이 아니라, 설계 초기부터 배포와 운영까지 이어지는 핵심 원칙이에요.

정리하면 다음과 같아요.

핵심 메시지	설명
세 기둥을 함께 봐야 해요	system-level faults, input-level attacks, environmental shifts가 연결돼요
공통 원칙이 있어요	detection, graceful degradation, adaptive response가 모든 영역에 적용돼요
하드웨어 오류는 모델 성능 문제예요	bit error 하나도 weight와 activation을 통해 예측을 망칠 수 있어요
Robustness는 pipeline 전체 문제예요	데이터 수집부터 monitoring, retraining, rollback까지 포함해요
평가가 중요해요	fault injection, adversarial benchmark, drift detection으로 실제 취약성을 확인해야 해요
비용과 trade-off가 있어요	energy, memory bandwidth, latency, clean accuracy, 운영 복잡도를 함께 고려해야 해요

마지막으로 기억할 문장은 이것이에요. Robust AI는 “절대 실패하지 않는 AI”를 만드는 일이 아니라, 실패가 일어날 수 있음을 인정하고 그 실패를 빨리 감지하며, 피해를 줄이고, 안전하게 회복하는 AI 시스템을 만드는 일이에요.

복습 질문

ML 시스템의 “조용한 실패”가 전통적인 소프트웨어 실패보다 위험할 수 있는 이유는 무엇인가요?
Robust AI의 세 기둥인 system-level faults, input-level attacks, environmental shifts를 각각 한 문장으로 설명해보세요.
Transient fault, permanent fault, intermittent fault의 차이를 예시와 함께 설명해보세요.
ECC, DMR/TMR, watchdog timer, heartbeat는 각각 어떤 종류의 문제를 감지하거나 완화하나요?
FGSM 수식에서 (\epsilon)과 (\nabla_x J(\theta, x, y))는 각각 어떤 역할을 하나요?
Adversarial attack과 data poisoning은 공격 시점이 어떻게 다른가요?
Covariate shift, label shift, concept drift를 수식 관점과 실제 예시로 구분해보세요.
Distribution shift가 단순히 “데이터를 더 많이 모으면 해결되는 문제”가 아닌 이유는 무엇인가요?
Software fault가 hardware fault, adversarial attack, distribution shift를 증폭할 수 있는 예를 하나 들어보세요.
Hardware-based fault injection과 software-based fault injection의 장단점을 비교해보세요.
Fault model과 error model의 차이는 무엇인가요?
Robust AI 방어 전략에서 detection, graceful degradation, adaptive response가 각각 왜 필요한가요?
Robustness를 높일 때 clean accuracy, latency, memory bandwidth, energy 사이에 어떤 trade-off가 생길 수 있나요?
복합 취약점을 고려하지 않고 threat를 따로따로만 테스트하면 어떤 false confidence가 생길 수 있나요?
이 장의 관점에서 “운영 가능한 AI 시스템”이 단순히 높은 정확도의 모델보다 더 많은 것을 요구하는 이유를 설명해보세요.