15. AI Workflow 단계별 학습 문서

원문 경로

/Users/keumky/Documents/New project 3/sources/mlsysbook/15-workflow/source.md

짧은 소개

이 장은 머신러닝 시스템을 만드는 일을 “모델 하나를 잘 학습시키는 일”보다 훨씬 넓게 바라봐요. 문제를 정의하고, 데이터를 모으고, 모델을 만들고, 검증하고, 실제 환경에 배포하고, 운영 중에 계속 관찰하며 개선하는 전체 흐름을 다룹니다.

원문은 당뇨망막병증 선별 시스템을 예로 들어요. 연구실에서는 잘 맞던 의료 AI가 실제 시골 병원, 낡은 카메라, 불안정한 인터넷, 다양한 환자 집단, 병원 업무 흐름을 만나면 어떤 제약을 겪는지 보여줍니다. 그래서 이 장의 핵심은 “AI는 모델만의 문제가 아니라 시스템 전체의 문제”라는 점이에요.

읽는 방법

처음부터 모든 세부 수치와 용어를 외우려고 하지 않아도 돼요. 이 장은 반복해서 깊이를 올리며 읽는 편이 좋습니다.

1. 먼저 목차와 요약을 보며 전체 뼈대를 잡아요.
2. 그다음 데이터가 어디서 들어와 모델과 배포로 어떻게 이어지는지 흐름을 그려봐요.
3. 마지막으로 각 단계의 제약 조건, 피드백 루프, 수치적 trade-off를 자세히 읽어요.

이 장의 기본 흐름은 다음과 같아요.

문제 정의
  -> 데이터 수집과 준비
  -> 모델 개발과 학습
  -> 평가와 검증
  -> 배포와 통합
  -> 모니터링과 유지보수
  -> 앞 단계로 피드백

중요한 점은 이 흐름이 일방통행 도로가 아니라는 거예요. 배포 후 문제가 발견되면 데이터 수집으로 돌아가고, 모니터링에서 성능 저하가 보이면 모델 개발이나 문제 정의까지 다시 손봐야 해요.

이 장의 한 줄 요약

ML workflow는 데이터, 모델, 배포 환경, 운영 모니터링이 서로 영향을 주고받는 반복적인 시스템 개발 방법이며, 실제 AI 시스템의 성공은 각 단계를 따로 잘하는 것이 아니라 전체 생명주기를 함께 설계하는 데서 나와요.

1단계: 중학교 수준

1. AI workflow는 병원 진료 과정과 비슷해요

AI를 만드는 일은 “똑똑한 프로그램 하나를 만드는 일”처럼 보일 수 있어요. 하지만 실제로는 병원 진료 과정과 더 비슷해요.

환자가 병원에 오면 의사는 바로 치료부터 하지 않아요. 먼저 증상을 묻고, 검사를 하고, 결과를 해석하고, 치료 계획을 세우고, 치료 후에도 상태를 지켜봐요. 문제가 다시 생기면 원인을 찾아 치료 방법을 바꿔요.

AI도 같아요.

그래서 AI workflow는 “AI를 처음 만드는 법”이면서 동시에 “AI가 실제 세상에서 계속 잘 작동하게 돌보는 법”이에요.

2. 전통적인 프로그램과 AI는 배우는 방식이 달라요

전통적인 프로그램은 사람이 규칙을 직접 적어줘요. 예를 들어 “잔액이 물건값보다 많으면 결제 허용”처럼요. 규칙이 분명하면 프로그램도 그대로 따라 해요.

AI는 조금 달라요. 사람이 모든 규칙을 직접 적지 않고, 예시를 많이 보여주면서 패턴을 배우게 해요. 마치 강아지에게 “앉아”를 가르칠 때 다리 근육을 어떻게 움직이라고 설명하지 않고, 잘했을 때 칭찬하며 점점 행동을 익히게 하는 것과 비슷해요.

이 차이 때문에 AI는 한 번 만들고 끝내기 어려워요. 세상이 바뀌면 예시도 바뀌고, 배운 패턴도 다시 확인해야 해요.

3. 데이터는 AI의 재료예요

요리를 할 때 재료가 상했거나 한쪽으로만 치우쳐 있으면 맛있는 음식을 만들기 어렵죠. AI도 데이터가 좋지 않으면 좋은 결과를 내기 어려워요.

당뇨망막병증 선별 AI를 생각해볼게요. 깨끗한 병원 사진만 보고 배운 AI는, 어두운 조명에서 찍은 사진이나 오래된 카메라 사진을 만나면 당황할 수 있어요. 그래서 데이터는 “많이 모으는 것”만으로 충분하지 않아요. 실제 사용할 환경을 잘 대표해야 해요.

4. 배포는 시험장 밖으로 나가는 순간이에요

학교에서 문제를 잘 푸는 학생이 실제 현장에서 바로 일을 잘한다고 보장할 수는 없어요. 시험장과 현실은 다르니까요.

AI도 연구실에서 높은 성능을 냈다고 실제 병원에서 바로 잘 작동하는 것은 아니에요. 병원 컴퓨터가 느릴 수도 있고, 인터넷이 자주 끊길 수도 있고, 의료진이 결과 화면을 이해하기 어려울 수도 있어요.

그래서 배포는 단순히 AI를 서버에 올리는 일이 아니에요. 실제 사람이 쓰는 흐름에 자연스럽게 들어가야 해요.

5. 모니터링은 AI의 건강검진이에요

AI도 시간이 지나면 성능이 떨어질 수 있어요. 카메라 종류가 바뀌거나, 환자 집단이 달라지거나, 데이터 품질이 나빠질 수 있기 때문이에요.

그래서 배포 후에는 AI가 잘 작동하는지 계속 지켜봐야 해요. 문제가 보이면 데이터를 다시 모으고, 모델을 고치고, 배포 방식을 조정해야 해요.

1단계 중간 정리

이 장에서 꼭 잡아야 할 큰 그림은 하나예요.

AI 시스템은 “만들기”보다 “계속 잘 돌아가게 하기”가 더 중요해요. 문제 정의, 데이터, 모델, 배포, 모니터링은 따로 떨어진 단계가 아니라 서로 연결된 하나의 순환 과정이에요.

2단계: 고등학교 수준

1. ML lifecycle은 순서가 있지만, 직선은 아니에요

원문은 ML lifecycle을 구조화된 반복 과정으로 설명해요. 각 단계는 다음 단계의 입력이 되지만, 뒤 단계에서 얻은 정보가 앞 단계로 다시 돌아오기도 해요.

원시 데이터
  -> 수집
  -> 정리와 검증
  -> 학습용 데이터
  -> 모델 학습
  -> 평가와 검증
  -> 실제 배포
  -> 운영 관찰
  -> 데이터와 모델 개선

전통적인 소프트웨어라면 요구사항을 정하고 코드를 작성한 뒤 테스트하고 배포하는 흐름이 비교적 분명해요. 하지만 ML은 데이터와 현실 환경이 계속 변하므로, “정답 규칙을 코드로 완성했다”라고 말하기가 어려워요.

2. 전통 소프트웨어와 ML의 차이

예를 들어 금융 거래 시스템에서 전통 프로그램은 “잔액이 충분하면 승인” 같은 규칙을 따를 수 있어요. 반면 사기 탐지 ML은 과거 거래 데이터에서 의심스러운 패턴을 배워요. 이 방식은 더 유연하지만, 사기 수법이 바뀌면 모델도 다시 적응해야 해요.

3. 간단한 수학으로 보는 성능 판단

의료 AI에서는 단순히 “몇 퍼센트 맞췄다”만 보면 부족해요. 특히 당뇨망막병증 선별처럼 놓치면 큰 피해가 생기는 문제에서는 두 가지를 나눠서 봐야 해요.

F1 점수는 보통 이렇게 생각할 수 있어요.

$$ F1 = 2 \times \frac{precision \times recall}{precision + recall} $$

여기서 precision은 “모델이 병이라고 한 것 중 실제 병인 비율”, recall은 “실제 병인 사람 중 모델이 찾아낸 비율”이에요. 의료 선별에서는 recall, 즉 민감도가 특히 중요해질 수 있어요.

4. 제약 조건은 단계 사이를 타고 이동해요

원문에서 중요한 표현은 constraint propagation이에요. 한 단계의 제약이 다른 단계로 퍼지는 현상을 말해요.

예를 들어 시골 병원에서 인터넷 업로드 속도가 느리다고 해볼게요. 그러면 모든 이미지를 클라우드로 보내기 어렵습니다. 이 제약은 다음처럼 이어져요.

인터넷이 느림
  -> 클라우드 추론이 어려움
  -> 병원 안 장비에서 추론해야 함
  -> 모델 크기와 지연 시간을 줄여야 함
  -> 모델 압축과 경량화가 필요함
  -> 모니터링도 분산 환경에 맞춰야 함

즉 데이터 수집 단계에서 발견된 제약이 모델 구조, 배포 방식, 모니터링 방식까지 바꿔요.

5. 모델 정확도와 배포 가능성은 trade-off 관계예요

원문의 DR 예시는 이 점을 수치로 보여줘요. 연구용 모델은 크고 정확할 수 있지만, 실제 병원 장비에서는 너무 느리거나 메모리를 많이 쓸 수 있어요.

그래서 ML workflow는 “가장 정확한 모델 찾기”가 아니라 “현실에서 쓸 수 있는 성능과 제약의 균형 찾기”에 가까워요.

6. 피드백 루프는 여러 속도로 돌아가요

운영 중 피드백은 한 가지 속도만 갖지 않아요.

빠른 피드백은 운영 문제를 빨리 고치게 해주고, 느린 피드백은 시스템의 큰 방향을 조정하게 해줘요.

2단계 중간 정리

ML workflow를 고등학교 수준에서 이해한다는 것은 다음 세 가지를 연결하는 거예요.

1. 데이터가 모델 성능을 결정해요.
2. 배포 환경이 모델 구조를 제한해요.
3. 운영 피드백이 다시 데이터와 모델 개선으로 돌아와요.

이제 3단계에서는 원문의 section 흐름을 따라, 각 단계가 실제 시스템에서 어떤 세부 문제를 만드는지 자세히 볼게요.

3단계: 대학교 수준

1. Systematic Framework for ML Development

원문은 이 장을 “컴포넌트 하나를 분석하는 단계에서 시스템 전체를 설계하는 단계로 넘어가는 장”으로 위치시켜요. 머신러닝 모델, 데이터 파이프라인, 배포 인프라, 운영 모니터링은 따로따로 존재하지 않고 하나의 개발 방법론 안에서 연결됩니다.

전통 소프트웨어는 요구사항이 비교적 명확하면 구현 경로도 비교적 직접적이에요. 반면 ML 시스템은 다음과 같은 특징을 가져요.

원문은 ML 개발이 과학적 방법론과 닮았다고 설명해요. 가설을 세우고, 실험하고, 결과를 분석하고, 다시 수정하는 방식이에요. 여기서 가설은 “이 모델 구조가 좋을 것이다”, “이 전처리가 도움이 될 것이다”, “이 데이터가 성능 저하 원인을 줄일 것이다” 같은 형태로 나타나요.

당뇨망막병증 선별 시스템은 이 장 전체의 사례로 쓰여요. 처음에는 “망막 사진을 보고 병을 찾아내는 이미지 분류 문제”처럼 보이지만, 실제로는 의료 규제, 환자 안전, 병원 업무 흐름, 인터넷 연결, 카메라 품질, 지역별 환자 분포가 모두 얽힌 시스템 문제가 됩니다.

2. Understanding the ML Lifecycle

ML lifecycle은 머신러닝 시스템을 만들고 평가하고 개선하는 반복적 과정이에요. 원문은 이 lifecycle을 이해하려면 systems thinking이 필요하다고 해요. 여기서 systems thinking은 부분을 따로 떼어 보는 것이 아니라, 부분 사이의 관계와 시간이 지나며 생기는 변화를 함께 보는 관점이에요.

원문이 강조하는 네 가지 시스템 패턴은 다음과 같아요.

원문의 Figure 1은 두 개의 병렬 pipeline을 설명해요.

핵심은 두 파이프라인이 서로 떨어져 있지 않다는 점이에요. 배포에서 발견된 문제가 데이터 수집을 바꾸고, 데이터 품질 문제가 모델 학습 전략을 바꾸며, 모델 성능 문제가 다시 평가 기준을 조정하게 만들어요.

3. ML vs Traditional Software Development

원문은 ML 개발이 전통 소프트웨어 개발과 근본적으로 다르다고 설명해요. 전통 개발에서는 요구사항 수집, 시스템 설계, 구현, 테스트, 배포가 순차적으로 진행되는 경우가 많아요. 각 단계는 문서나 코드 같은 명확한 산출물을 만들고, 다음 단계가 그것을 이어받아요.

ML에서는 시스템 행동의 일부가 코드가 아니라 데이터에서 나와요. 이 차이가 workflow 전체를 바꿉니다.

사기 탐지 예시는 이 차이를 잘 보여줘요. 규칙 기반 시스템은 사람이 정한 조건을 따르지만, ML 기반 사기 탐지는 과거 거래 데이터에서 수많은 행동 특징을 분석해요. 이 방식은 더 높은 성능을 낼 수 있지만, 사기꾼이 모델의 패턴에 적응하면 몇 달 안에 성능이 떨어질 수 있어요. 따라서 지속적인 재학습과 검증이 필요해요.

이 장에서 중요한 구분은 “테스트”와 “실험”이에요. 전통 소프트웨어 테스트는 이미 정해진 명세를 만족하는지 확인하는 성격이 강해요. 반면 ML 실험은 어떤 데이터, 특징, 모델 구조, 하이퍼파라미터 조합이 실제로 좋은지 발견하는 개발 과정 자체예요.

4. Six Core Lifecycle Stages

원문은 AI 시스템 개발을 여섯 단계로 정리해요.

원문은 이 여섯 단계가 순서대로만 진행된다고 말하지 않아요. 오히려 뒤 단계의 정보가 앞 단계로 돌아가는 반복 구조가 핵심이에요.

DR 사례: 연구 성공에서 임상 현실로

당뇨망막병증 선별 시스템은 처음에는 전문가 수준의 정확도를 달성하는 이미지 분류 문제처럼 보였어요. 그러나 실제 임상 배포에서는 여러 문제가 드러나요.

원문은 DR이 전 세계적으로 많은 사람에게 영향을 주며, 특히 의료 접근성이 낮은 지역에서는 조기 발견이 큰 의미를 갖는다고 설명해요. 이 때문에 AI 선별 시스템은 단순한 기술 실험이 아니라 실제 의료 접근성을 개선할 수 있는 시스템으로 다뤄져요.

5. Problem Definition Stage

문제 정의 단계는 “AI가 무엇을 해야 하는가”뿐 아니라 “AI가 어떻게 배워야 하고, 어떤 현실 제약 안에서 작동해야 하는가”를 정하는 단계예요.

전통 소프트웨어에서는 “입력 X이면 출력 Y” 같은 규칙 명세가 중심이 될 수 있어요. 하지만 ML 문제 정의에서는 비즈니스 목표나 사회적 목표를 학습 가능한 목표로 바꿔야 해요. 이를 problem formulation이라고 볼 수 있어요.

5.1 Balancing Competing Constraints

DR 선별 시스템의 문제 정의는 여러 목표를 동시에 만족해야 해요.

원문은 DR 시스템에서 90% 이상의 민감도와 80% 이상의 특이도 같은 목표를 예로 들어요. 이 수치는 단순한 모델 성능 지표가 아니라 환자 안전과 병원 운영 부담을 함께 반영하는 요구사항이에요.

5.2 Collaborative Problem Definition Process

좋은 문제 정의는 데이터 과학자만의 일이 아니에요. 의료진, 현장 운영자, 규제 담당자, 시스템 엔지니어가 함께 문제를 정의해야 해요.

DR 유형의 프로젝트에서는 의료진이 어떤 병변을 중요하게 보는지, 어떤 결과 설명이 진료에 도움이 되는지, 어떤 경우에는 사람이 반드시 최종 확인해야 하는지를 알려줘야 해요. 엔지니어는 해당 요구가 실제 장비와 네트워크에서 가능한지 평가해요. 규제와 개인정보 요건도 초기에 반영되어야 해요.

이 협업이 없으면 모델은 연구실 점수는 높지만 실제 현장에서 받아들여지지 않을 수 있어요.

5.3 Adapting Definitions for Scale

처음에는 몇 개 병원에서만 쓰던 시스템이 수십, 수백 개 병원으로 확장될 수 있어요. 이때 문제 정의도 같이 확장되어야 해요.

원문은 의료 AI가 인구 집단에 따라 성능 차이를 보일 수 있음을 언급해요. 따라서 처음부터 다양한 집단에서 검증할 수 있도록 데이터 전략과 평가 기준을 설계해야 해요.

6. Data Collection & Preparation Stage

데이터 수집과 준비는 원시 데이터를 모델 개발에 쓸 수 있게 만드는 단계예요. 원문은 이 단계가 단순히 샘플을 많이 모으는 일이 아니라고 강조해요. 특히 의료 AI에서는 통계적 엄밀성과 운영 가능성을 동시에 만족해야 해요.

DR 사례에서는 문제 정의의 요구사항이 데이터 요구사항으로 바로 바뀌어요. 다양한 환자 집단, 여러 장비, 실제 병원 조건, 규제 검증에 견딜 수 있는 라벨이 필요하기 때문이에요.

원문의 주요 수치는 다음과 같아요.

라벨링 비용도 중요해요. 원문은 전문가 의료 라벨링 비용이 매우 크며, DR 데이터셋의 전문가 시간 비용이 270만 달러를 넘는 수준이라고 설명해요. 그래서 의료 데이터에서는 라벨 품질, 비용, 규모 사이의 균형이 매우 중요합니다.

6.1 Bridging Laboratory and Real-World Data

연구실 데이터는 보통 깨끗하고 잘 정리되어 있어요. 하지만 실제 병원 데이터는 다릅니다.

원문은 태국이나 인도 같은 지역의 시골 클리닉 배포를 예로 들어요. 이 환경에서는 카메라 장비, 촬영자 숙련도, 조명, 환자 자세가 모두 달라져요. 따라서 robust preprocessing과 품질 보증 체계가 필요해요.

데이터 전송량 문제는 아키텍처 결정을 직접 바꿔요. 원문은 local preprocessing으로 주간 전송량을 15GB에서 750MB로 줄일 수 있다고 설명해요. 이는 약 95% 절감이에요. 대신 병원 현장에 더 많은 계산 자원이 필요해져요. 이 때문에 NVIDIA Jetson 같은 엣지 장비가 등장해요.

예시 아키텍처는 다음처럼 구성돼요.

원문은 이런 분산 접근이 200개 이상의 클리닉 배포에서 80ms 미만의 추론 지연과 94% uptime을 달성하는 사례적 목표를 설명해요.

또한 환자 개인정보 규제 때문에 federated learning이 필요할 수 있어요. 이 방식은 민감한 데이터를 중앙으로 모으지 않고, 각 병원에 데이터를 두면서 모델 학습에 참여하게 해요. 하지만 통신 비용이 커지고, 병원별 데이터 분포가 달라 모델 수렴이 어려워질 수 있어요.

6.2 Data Infrastructure for Distributed Deployment

각 망막 이미지는 여러 단계를 거쳐요.

카메라 촬영
  -> 로컬 저장
  -> 초기 처리
  -> 품질 검증
  -> 보안 전송
  -> 중앙 시스템 통합
  -> 학습 데이터셋 반영

데이터 접근 패턴에 따라 저장 방식도 달라져요. 자주 쓰는 학습 데이터는 빠른 저장소가 필요하고, 오래된 이력 데이터는 비용 효율적인 저장소로 옮길 수 있어요. 캐싱도 중요해요. 반복 실험에서 자주 접근하는 데이터를 빠르게 가져오면 모델 개발 속도가 빨라지기 때문이에요.

연결이 안정적인 병원은 실시간 전송을 사용할 수 있지만, 연결이 불안정한 병원은 store-and-forward 방식이 필요해요. 즉 일단 로컬에 저장해두고 연결이 가능할 때 안전하게 전송하는 방식이에요.

6.3 Managing Data at Scale

초기 병원 몇 곳에서 수백 곳으로 확장하면 각 병원이 하나의 독립적인 데이터 노드처럼 됩니다. 장비, 촬영 방식, 환자 집단, 업무 흐름이 모두 조금씩 달라요.

이를 관리하려면 다음이 필요해요.

고해상도 장비가 늘어나면 데이터 크기도 커져요. 이는 저장소, 전처리, 학습, 추론 비용을 모두 키워요. 따라서 데이터 단계의 선택은 이후 모델 개발과 배포 비용을 미리 결정하는 효과를 가져요.

6.4 Quality Assurance and Validation

데이터 품질 보증은 downstream 단계 전체를 보호하는 장치예요. 원문은 촬영 시점에서 초점 불량이나 잘못된 framing을 자동으로 감지해 현장 직원이 즉시 다시 촬영할 수 있게 하는 방식을 설명해요.

검증 대상은 이미지 품질만이 아니에요.

데이터 단계에서 발견한 제한된 대역폭, 다양한 하드웨어, 불안정한 연결, 품질 편차는 바로 다음 단계인 모델 개발 전략을 바꿔요. 이 장의 핵심인 lifecycle 통합이 여기서 잘 보입니다.

7. Model Development & Training Stage

모델 개발과 학습은 머신러닝 시스템의 중심처럼 보이지만, 원문은 이 단계도 단독으로 최적화하면 안 된다고 설명해요. 모델은 데이터 품질, 배포 환경, 임상 요구사항의 영향을 동시에 받아요.

DR 사례에서 목표는 전문가 수준의 정확도와 엣지 장비 호환성을 동시에 만족하는 것이었어요. 원문은 ImageNet으로 사전학습된 모델을 의료 이미지에 맞게 fine-tuning하는 transfer learning 전략을 설명해요. 128,000장의 라벨링된 이미지와 결합해 F-score 0.91-0.95 수준을 달성할 수 있다고 설명합니다.

F1 점수는 다음과 같이 해석해요.

$$ F1 = 2 \times \frac{precision \times recall}{precision + recall} $$

이 수식은 정밀도와 재현율의 조화평균이에요. 한쪽만 높고 다른 쪽이 낮으면 F1도 크게 높아지기 어렵습니다. 특히 질병이 드문 데이터에서는 단순 정확도만 보면 위험해요. 모두 “정상”이라고 예측해도 정확도가 높아 보일 수 있기 때문이에요.

7.1 Balancing Performance and Deployment Constraints

원문은 모델 개발 단계에서 accuracy와 deployment feasibility 사이의 trade-off를 강하게 보여줘요.

여기서 중요한 것은 95.2%에서 94.8%로 약간 낮아지는 성능 손실을 감수하더라도, 실제 현장에서 동작 가능한 모델을 만드는 것이 더 가치 있을 수 있다는 점이에요.

모델 압축 기법은 다음과 같이 쓰여요.

원문은 32-bit float를 8-bit integer로 줄이면 약 4배 크기 감소가 가능하다고 설명해요. pruning은 경우에 따라 많은 파라미터를 제거할 수 있어요. 다만 이런 최적화는 반드시 임상 성능 검증과 함께 진행되어야 해요.

7.2 Constraint-Driven Development Process

모델 개발은 데이터 과학자와 도메인 전문가의 협업으로 시작돼요. 의료 영상에서는 안과 전문의가 어떤 병변이 중요한지 알려줘야 하고, 엔지니어는 그 특징을 모델이 포착하도록 데이터와 구조를 설계해야 해요.

하이퍼파라미터 탐색도 비용 문제를 만들어요. 원문은 예시로 다음 조합을 제시해요.

10개 모델 변형
  x 5개 하이퍼파라미터 sweep
  x 3개 전처리 방식
  = 150개 학습 실행

한 번의 학습 실행이 500-2000달러 수준이라면, 한 실험 cycle이 15만 달러까지 갈 수 있어요. 따라서 무작정 실험을 많이 하는 방식은 지속 가능하지 않아요.

효율적인 실험을 위해 원문은 다음 요소를 언급해요.

ML 실험은 통계적 잡음과 진짜 개선을 구분해야 해요. 그래서 fixed random seed, 환경 버전 고정, ablation study, confounding factor 분석, A/B testing 같은 방법이 중요해요.

Ablation study는 구성 요소를 하나씩 빼거나 바꾸면서 무엇이 성능에 기여했는지 보는 방법이에요. 복잡한 모델에서는 여러 요소가 함께 작용하므로, “좋아진 이유”를 분리해서 확인해야 합니다.

7.3 From Prototype to Production-Scale Development

프로토타입이 성공해도 production-scale 개발은 다른 문제를 만나요.

원문은 ML artifact 관리가 중요하다고 설명해요. artifact는 학습된 모델만이 아니에요. 데이터 버전, 전처리 코드, 하이퍼파라미터, 체크포인트, 로그, 평가 지표, 문서가 모두 연결된 산출물이에요.

재현 가능성을 위해서는 다음 관계가 추적되어야 해요.

데이터 버전
  + 전처리 코드
  + 모델 구조
  + 하이퍼파라미터
  + 학습 환경
  -> 특정 모델 checkpoint
  -> 특정 평가 결과

이 추적이 없으면 나중에 “왜 이 모델이 더 좋았는지”, “어떤 데이터로 학습했는지”, “이 모델을 병원 A에 배포해도 되는지”를 확인하기 어려워져요.

8. Deployment & Integration Stage

배포와 통합 단계는 학습된 모델을 실제 production system과 업무 흐름에 넣는 단계예요. 원문은 배포가 모델 파일을 올리는 행위가 아니라, compatibility, scalability, operational constraints를 해결하는 작업이라고 설명해요.

DR 시스템에서는 엣지 배포가 중요해요. 시골 병원의 인터넷 연결이 불안정할 수 있기 때문에, 망막 이미지를 병원 안에서 처리하고 품질이 나쁜 이미지는 다시 촬영하도록 알려주는 방식이 필요해요.

8.1 Technical and Operational Requirements

배포 요구사항은 기술 요구와 운영 요구가 합쳐진 형태예요.

클라우드 배포는 모델을 크게 쓰기 쉬울 수 있지만, 연결이 불안정하면 임상 workflow에 맞지 않을 수 있어요. 엣지 배포는 빠르고 독립적으로 동작하지만 모델 크기와 계산량을 강하게 제한해요.

8.2 Phased Rollout and Integration Process

원문은 점진적 배포를 강조해요.

시뮬레이션 환경 테스트
  -> 소수 pilot site 배포
  -> 현장 피드백 수집
  -> 인터페이스와 pipeline 수정
  -> 더 넓은 rollout

시뮬레이션 환경에서는 목표 병원의 기술 제약과 업무 흐름을 흉내 내요. 여기서 병목과 호환성 문제를 먼저 찾습니다. 이후 pilot site에서는 실제 의료진과 기술 담당자의 피드백을 받으며, 실험실에서는 보이지 않던 문제를 발견해요.

HIS 통합도 중요한 작업이에요. 시스템은 환자 정보를 가져오고, 연결된 카메라의 망막 이미지를 처리하고, 의료진이 해석할 수 있는 형태로 결과를 돌려줘야 해요. 이를 위해 robust API, 실시간 데이터 처리 pipeline, 사용자 친화적인 인터페이스가 필요해요.

8.3 Multi-Site Deployment Challenges

여러 병원에 배포하면 각 병원이 서로 다른 환경을 갖고 있다는 점이 문제가 돼요.

원문은 배포 현실이 다시 개발 단계로 역류한다고 설명해요. 예를 들어 특정 병원 장비에서 지연 시간이 너무 길면, 모델을 더 압축하거나 전처리 pipeline을 바꿔야 할 수 있어요.

또한 사용자의 신뢰와 숙련도도 중요해요. 의료진이 시스템을 믿지 못하거나 결과 화면을 이해하기 어렵다면, 알고리즘 성능이 좋아도 실제 도입은 실패할 수 있어요.

8.4 Ensuring Clinical-Grade Reliability

의료 시스템에서는 reliability가 핵심이에요. DR 시스템은 환자가 많을 때도, 이미지 품질이 나쁠 때도, 외부 시스템과 연결이 불안정할 때도 안전하게 동작해야 해요.

필요한 장치는 다음과 같아요.

배포는 lifecycle의 끝이 아니라 운영 단계로 넘어가는 관문이에요. 실제 배포에서 얻은 피드백은 모니터링과 유지보수 전략의 입력이 됩니다.

9. Monitoring & Maintenance Stage

운영에 들어간 ML 시스템은 전통 소프트웨어와 다르게 계속 변하는 데이터 분포를 상대해야 해요. 코드가 그대로여도 환자 집단, 촬영 장비, 사용 방식, 의료 지식이 바뀌면 모델 성능은 달라질 수 있어요.

원문은 모니터링이 세 가지 중요한 피드백 루프를 만든다고 설명해요.

Data drift는 입력 데이터 특성이 시간이 지나며 바뀌는 현상이에요. Model drift는 모델의 성능이 시간이 지나며 떨어지는 현상이에요. ML 시스템에서는 이런 성능 저하가 조용히 일어날 수 있어요. 그래서 관찰 체계가 필수입니다.

9.1 Production Monitoring for Dynamic Systems

DR 시스템에서는 기술적 지표와 운영 지표를 함께 봐야 해요.

원문은 실제 배포 후 드러날 수 있는 성능 저하를 수치로 설명해요.

이런 blind spot은 실험실 검증에서는 잘 보이지 않을 수 있어요. 그래서 원문은 real-world performance gap, 즉 연구실 성능과 실제 임상 성능의 차이를 강조해요. 의료 AI에서는 실제 배포 연구가 중요한 이유가 여기에 있어요.

PSI, 즉 Population Stability Index는 데이터 분포 변화 정도를 보는 지표로 소개돼요.

$$ PSI = \sum ((actual% - expected%) \times \ln(actual% / expected%)) $$

대략적으로 0-0.1은 작은 변화, 0.1-0.2는 조사 필요, 0.2 초과는 큰 변화로 보고 재학습이나 데이터 분석을 검토할 수 있어요.

원문은 다음과 같은 운영 기준 예시도 들어요.

알림은 너무 많아도 문제예요. alert fatigue를 막기 위해 팀당 하루 알림 수를 제한하고, escalation과 suppression 정책을 둬야 해요.

9.2 Continuous Improvement Through Feedback Loops

유지보수는 고장 난 뒤 고치는 작업만이 아니에요. 모니터링에서 얻은 정보를 바탕으로 모델, 데이터, 배포 방식을 계속 개선하는 순환 과정이에요.

모델 업데이트에는 careful validation과 controlled rollout이 필요해요. 전통 소프트웨어 rollback은 이전 코드 버전으로 되돌리는 일이지만, ML rollback은 더 복잡해요. 모델 행동이 현재 데이터 분포와 feature dependency에 의존하기 때문이에요.

따라서 ML용 CI/CD에는 일반적인 unit test 외에도 다음이 포함되어야 해요.

9.3 Distributed System Monitoring at Scale

원문은 5개 pilot site에서 200개 이상의 clinic으로 확장하면 모니터링 복잡도가 크게 증가한다고 설명해요.

분산 모니터링은 전역 지표와 지역별 지표를 함께 봐야 해요. 전체 평균은 괜찮아 보여도 특정 병원이나 특정 환자 집단에서 문제가 생길 수 있어요.

Data lineage도 중요해요. 어떤 데이터가 어떤 변환을 거쳐 어떤 예측에 영향을 줬는지 추적해야 디버깅과 규제 감사가 가능해요. 의료나 금융처럼 책임 소재가 중요한 분야에서는 이 추적성이 시스템 신뢰의 일부가 됩니다.

9.4 Anticipating and Preventing System Degradation

원문은 reactive maintenance만으로는 부족하다고 말해요. 문제가 임상 운영에 영향을 주기 전에 예측하고 예방해야 해요.

예측 유지보수는 운영 로그에서 이상 패턴을 찾아 장비 문제나 성능 저하 가능성을 미리 감지해요. Continuous learning pipeline은 새 데이터를 반영해 시스템을 적응시키지만, 의료 시스템에서는 안전성과 검증 절차를 반드시 함께 가져가야 해요.

이 단계에서는 정확도뿐 아니라 adaptability와 resilience도 중요한 지표가 돼요. 시스템이 새로운 장비, 새로운 지역, 새로운 환자 집단, 새로운 의료 지식에 얼마나 안전하게 적응할 수 있는지가 production ML의 핵심입니다.

10. Integrating Systems Thinking Principles

원문은 각 lifecycle 단계를 살핀 뒤, 성공적인 AI 시스템에 공통적으로 나타나는 네 가지 systems thinking 원리를 다시 정리해요.

10.1 How Decisions Cascade Through the System

제약 전파는 ML workflow의 핵심 패턴이에요.

DR 사례를 연결하면 이렇게 돼요.

의료 규제와 환자 안전
  -> 90% 이상 민감도 요구
  -> 전문가 합의 라벨링 필요
  -> 고품질 데이터 수집 비용 증가
  -> 고성능 모델 구조 필요
  -> 엣지 배포를 위한 압축 필요
  -> 분산 모니터링과 감사 추적 필요

이 전파는 한 방향만이 아니에요. 시골 병원의 대역폭 제한처럼 나중에 발견된 배포 제약이 전처리와 모델 구조를 다시 바꾸기도 해요. 그래서 원문은 lifecycle을 선형 의존성이 아니라 dynamic constraint network로 보는 관점을 제시해요.

10.2 Orchestrating Feedback Across Multiple Timescales

ML 시스템은 여러 시간 규모의 피드백을 함께 운영해야 해요.

빠른 루프만 있으면 일시적 흔들림에 과민하게 반응할 수 있어요. 느린 루프만 있으면 중요한 변화를 너무 늦게 발견해요. 둘을 조율해야 robust system이 됩니다.

10.3 Understanding System-Level Behaviors

창발적 복잡성은 개별 구성 요소를 볼 때는 보이지 않던 문제가 전체 시스템에서 나타나는 현상이에요.

예를 들어 각 병원은 94% 정도의 안정적 정확도를 보일 수 있어요. 하지만 전체 데이터를 모아 보면 특정 인구 집단이나 특정 장비 조합에서 성능이 낮아지는 패턴이 나타날 수 있어요. 이런 문제는 단일 병원 로그만으로는 보이지 않을 수 있습니다.

전통 분산 시스템은 서버 장애나 네트워크 분리처럼 비교적 명확한 failure를 다루는 경우가 많아요. 반면 ML 시스템은 data drift, bias amplification, subtle performance erosion처럼 통계적이고 점진적인 degradation을 다뤄야 해요.

10.4 Multi-Dimensional Resource Trade-offs

ML 자원 최적화는 단순히 “더 빠르게” 또는 “더 정확하게”가 아니에요. 정확도, 모델 크기, latency, 메모리, 하드웨어 비용, 네트워크, 운영 인력을 함께 봐야 해요.

원문의 예시는 매우 구체적이에요.

작은 성능 향상이 큰 비용 증가를 만들 수 있어요. 반대로 엣지 배포는 latency를 크게 줄이지만 모델 복잡도를 제한해요. 클라우드 배포는 큰 모델을 허용하지만 200ms 이상의 지연이 임상 흐름을 방해할 수 있어요.

10.5 Engineering Discipline for ML Systems

원문이 결론적으로 말하는 engineering discipline은 다음과 같아요.

이 관점이 있어야 머신러닝은 연구실 기법을 넘어 신뢰 가능한 시스템 엔지니어링이 됩니다.

11. Fallacies and Pitfalls

원문은 ML workflow에서 흔한 오해와 함정을 정리해요.

11.1 오해: ML 개발은 전통 소프트웨어 workflow를 그대로 따라도 된다

ML은 데이터 변동성, 알고리즘의 확률성, 모델 성능 변화라는 불확실성을 갖고 있어요. 전통적인 waterfall 방식이나 수정 없는 일반 agile 방식만으로는 데이터 검증, 실험 추적, 반복적 모델 개선을 충분히 다루기 어려워요.

11.2 함정: 데이터 준비를 한 번만 하는 전처리로 본다

현실 데이터는 계속 바뀌어요. 분포가 달라지고, 품질이 나빠지고, 새 데이터 출처가 생길 수 있어요. 따라서 데이터 준비는 초기 단계에서 끝나는 일이 아니라 지속적 검증과 drift 모니터링이 필요한 운영 활동이에요.

11.3 오해: 개발 환경 성능이 production 성능을 그대로 예측한다

개발 데이터는 깨끗하고 통제되어 있는 경우가 많아요. production에서는 낮은 품질의 입력, 지연 시간 제한, 자원 부족, 예상하지 못한 입력이 들어와요. 그래서 연구실 성능이 실제 성공을 보장하지 않아요.

11.4 함정: 빨리 배포하려고 체계적 검증을 건너뛴다

검증을 마지막 체크포인트나 형식적 절차로 보면 위험해요. 숨은 편향, 낮은 일반화 성능, 특정 조건의 실패는 배포 후 훨씬 더 비싸게 돌아옵니다. 원문은 robust workflow가 개발 전 과정에 검증을 포함해야 한다고 강조해요.

12. Summary

이 장은 ML lifecycle을 머신러닝 시스템 엔지니어링의 기본 지도처럼 제시해요. 핵심은 두 가지예요.

첫째, ML 시스템은 데이터 pipeline과 모델 pipeline이 함께 움직여요. 데이터 수집, 준비, 라벨링, 검증은 모델 학습과 평가, 배포에 직접 영향을 줘요.

둘째, feedback loop가 ML workflow를 전통적인 선형 개발과 구분해요. 배포에서 얻은 insight는 데이터 보강, 모델 재학습, 전처리 개선, 문제 정의 수정으로 돌아옵니다.

원문의 최종 메시지는 다음처럼 정리할 수 있어요.

복습 질문

1. ML workflow가 전통 소프트웨어 개발 workflow와 가장 크게 다른 점은 무엇인가요?
2. “데이터가 1급 설계 요소”라는 말은 어떤 의미인가요?
3. DR 선별 시스템에서 높은 민감도와 높은 특이도는 각각 왜 중요한가요?
4. 시골 병원의 느린 인터넷 연결은 데이터 처리, 모델 구조, 배포 방식에 어떤 영향을 주나요?
5. 연구실에서 성능이 좋은 모델이 실제 병원에서 성능이 떨어질 수 있는 이유를 설명해보세요.
6. 모델 압축 기법인 quantization, pruning, knowledge distillation은 각각 어떤 문제를 해결하려고 하나요?
7. 배포와 통합 단계에서 HIS 연동이 중요한 이유는 무엇인가요?
8. Data drift와 model drift의 차이를 설명해보세요.
9. 여러 병원에 배포된 의료 AI를 모니터링할 때 전역 지표와 지역별 지표를 모두 봐야 하는 이유는 무엇인가요?
10. 이 장에서 말하는 systems thinking의 네 가지 패턴을 DR 사례와 연결해 설명해보세요.