[논문 분석] 구글이 경고한 '숨겨진 기술 부채': ML 시스템은 왜 배포 이후에 무너지는가

기업 AI 프로젝트의 실패는 대개 배포 직전이 아니라 배포 1년 뒤에 모습을 드러냅니다. 모델은 여전히 서빙되고 있고, 대시보드는 정상이며, 아무도 코드를 망가뜨리지 않았습니다. 그런데 어느 순간부터 아무도 그 시스템을 건드리려 하지 않습니다. 피처 하나를 수정하는 데 2주가 걸리고, 원인을 아는 사람은 이미 퇴사했으며, 파이프라인의 어느 단계를 지워도 되는지 판단할 수 있는 사람이 없습니다.

2015년 NeurIPS에서 구글 연구진이 발표한 《Hidden Technical Debt in Machine Learning Systems》은 11년이 지난 지금도 이 현상을 가장 정확하게 설명하는 텍스트입니다. 논문의 출발점은 냉정합니다. 머신러닝 시스템을 개발하고 배포하는 일은 상대적으로 빠르고 저렴하지만, 그것을 시간에 걸쳐 유지하는 일은 어렵고 비싸다.

핵심 주장은 이것입니다. ML 시스템의 기술 부채는 코드가 아니라 시스템 경계에 쌓이며, 그래서 코드 레벨의 도구로는 보이지 않습니다.

---

1. 모든 부채의 뿌리: 얽힘(Entanglement)과 CACE 원칙

소프트웨어 공학이 지난 50년간 복잡도와 싸운 방법은 캡슐화와 모듈 경계였습니다. 변경의 영향 범위를 인터페이스 안에 가두면, 시스템의 나머지 부분은 그 변경을 몰라도 됩니다.

머신러닝은 이 전제를 정면으로 위반합니다. 모델은 입력 신호들을 분리된 채로 다루지 않고, 서로 얽힌 하나의 결합 분포로 흡수합니다. 논문은 이를 CACE 원칙으로 명명했습니다.

CACE: Changing Anything Changes Everything. 무엇이든 바꾸면, 모든 것이 바뀐다.

피처 하나를 추가하거나 제거하거나 그 분포를 살짝 바꾸면, 학습된 나머지 가중치 전체의 의미가 재배치됩니다. 하이퍼파라미터, 학습률, 샘플링 방식, 데이터 수집 기간도 마찬가지입니다. ML 시스템에는 “이 부분만 고쳤다”가 존재하지 않습니다.

실무에서 이것이 무서운 이유는 변경이 실패하지 않기 때문입니다. 피처 하나를 뺀 모델은 에러를 내지 않습니다. 그냥 조금 다르게, 그리고 대개는 아무도 모니터링하지 않는 세그먼트에서 조금 더 나쁘게 동작할 뿐입니다.

---

2. 데이터 의존성: 코드 의존성보다 비싸고, 아무도 선언하지 않는다

논문이 가장 강조하는 부채는 데이터 의존성(Data Dependency Debt)입니다. 코드 의존성은 컴파일러와 링커, 정적 분석 도구가 강제로 드러냅니다. 쓰지 않는 import는 경고가 뜨고, 사라진 함수는 빌드를 깨뜨립니다.

데이터 의존성에는 그런 장치가 없습니다.

1) 불안정한 데이터 의존성 (Unstable Data Dependencies)

내 모델이 다른 팀이 운영하는 모델의 출력을 입력 피처로 쓰는 경우입니다. 그 팀은 자기 모델을 개선할 때마다 정당한 일을 하고 있다고 믿습니다. 그리고 그 개선은 내 모델의 입력 분포를 소리 없이 이동시킵니다.

논문의 권고는 명확합니다. 의존하는 신호의 버전을 고정(versioned snapshot)하라. 다만 그 대가로 스냅샷 갱신 지연이라는 또 다른 부채가 생기며, 이 트레이드오프는 공짜가 아닙니다.

2) 미사용 데이터 의존성 (Underutilized Data Dependencies)

한때 의미가 있었지만 지금은 모델 성능에 거의 기여하지 않으면서 파이프라인에만 남아 있는 피처들입니다. 이들은 비용은 계속 발생시키면서, 언젠가 원천 데이터가 깨질 때 시스템을 무너뜨릴 권한만 유지합니다.

전형적인 발생 경로는 레거시 피처(리팩터링 이후 쓸모가 사라졌지만 제거되지 않음), 번들 피처(마감에 쫓겨 피처 그룹을 통째로 투입), ε-피처(정확도를 아주 미세하게 올린다는 이유로 남겨둔 것)입니다.

3) 보정 캐스케이드 (Correction Cascades)

이미 있는 모델 m_a를 조금 손봐서 인접 문제에 쓰기 위해, 그 출력에 보정 레이어를 얹어 m'_a를 만듭니다. 빠르고 효율적으로 보입니다. 문제는 그다음입니다. 누군가 m'_a 위에 또 보정을 얹고, 다시 그 위에 얹습니다.

결과는 어떤 레이어도 독립적으로 개선할 수 없는 계층입니다. 맨 아래 모델의 정확도를 올리면 그 위에 쌓인 모든 보정이 동시에 틀어집니다. 개선이 곧 회귀가 되는 구조에 도달하면, 조직은 합리적으로 “아무것도 건드리지 않는” 선택을 하게 됩니다.

4) 미신고 소비자 (Undeclared Consumers)

모델의 예측 결과를 파일이나 테이블로 떨어뜨려 두면, 접근 통제가 없는 한 내가 모르는 다른 팀이 그것을 자기 시스템의 입력으로 쓰기 시작합니다. 소프트웨어 공학에서 말하는 가시성 부채(visibility debt)의 ML 버전입니다.

이것이 위험한 이유는 두 가지입니다. 첫째, 내 모델의 변경이 어디까지 파급되는지 아무도 모릅니다. 둘째, 그 소비자의 출력이 다시 돌아 내 모델의 입력이 되는 숨은 피드백 루프를 만들 수 있습니다.

---

3. 피드백 루프: 오프라인 검증으로는 원리적으로 못 찾는 부채

ML 시스템의 특징은 자신의 행동이 미래의 학습 데이터를 바꾼다는 것입니다.

• 직접 피드백 루프: 추천 모델이 노출한 항목만 클릭을 받고, 그 클릭이 다시 학습 데이터가 됩니다. 모델은 자기가 이미 좋아하는 것이 옳다는 증거를 스스로 생산합니다.
• 숨은 피드백 루프: 서로 다른 두 시스템이 세상을 통해 간접적으로 연결된 경우입니다. 같은 웹페이지의 서로 다른 영역을 담당하는 두 모델이 있다면, 한쪽의 개선이 다른 쪽의 노출과 클릭을 바꾸고, 그것이 다시 양쪽의 학습 데이터가 됩니다.

핵심은 이 부채가 오프라인 홀드아웃 평가에서 절대 드러나지 않는다는 점입니다. 테스트셋은 이미 그 루프를 통과한 데이터이기 때문입니다. 탐지하려면 일부 트래픽을 모델의 영향에서 의도적으로 격리하는 등 시스템 설계 차원의 개입이 필요합니다.

---

4. 시스템 레벨의 배관 부채: 글루 코드, 파이프라인 정글, 죽은 실험 코드

논문이 널리 인용되는 이유 중 하나는, 실제 운영 ML 시스템에서 순수한 머신러닝 코드가 차지하는 비중이 극히 작다는 지적입니다. 나머지는 설정, 데이터 수집, 피처 추출, 데이터 검증, 리소스 관리, 서빙 인프라, 모니터링 같은 배관(plumbing)이며, 실패는 대부분 이 배관에서 발생합니다.

부채 유형	증상	전형적 발생 원인
글루 코드(Glue Code)	범용 라이브러리에 데이터를 밀어 넣고 빼내는 지원 코드가 시스템의 대부분을 차지	자체 구현 대신 범용 패키지를 쓰되, 그 패키지의 자료구조에 시스템 전체를 맞춰버림
파이프라인 정글(Pipeline Jungles)	스크래이프·조인·샘플링 단계가 유기적으로 증식해 전체를 이해하는 사람이 없음	새 신호가 필요할 때마다 기존 준비 과정에 한 단계씩 덧붙임
죽은 실험 코드 경로	프로덕션 코드 안에 실험용 분기가 누적되어 조합 폭발	“일단 플래그로 막아두고 나중에 정리”
설정 부채(Configuration Debt)	설정 라인 수가 코드 라인 수를 넘어서고, 오타 하나가 조용히 성능을 떨어뜨림	설정은 코드가 아니라는 인식, 리뷰·테스트 대상에서의 제외

설정 부채는 특히 과소평가됩니다. 어떤 피처를 쓰는지, 데이터를 어떻게 선택하는지, 알고리즘별 학습 설정이 무엇인지, 전·후처리가 무엇인지가 전부 설정에 있습니다. 그런데 대부분의 조직에서 설정 파일은 코드 리뷰를 거치지 않고, 테스트되지 않으며, 누가 왜 그 값을 넣었는지 기록되지 않습니다.

---

5. 필자의 생각과 실무 제언

[!NOTE] 저자의 현장 메모: 국내 대기업의 AI 거버넌스 자문에서 이 논문을 인용할 때 가장 자주 받는 반응은 “그건 구글처럼 시스템이 거대할 때 얘기 아닌가요”입니다. 경험상 정반대입니다. 구글은 이 부채를 인식하고 조직적으로 관리했기 때문에 논문을 쓸 수 있었습니다. 오히려 모델 서너 개를 운영하는 중견 조직에서, 담당자 한 명의 퇴사와 함께 파이프라인 전체가 블랙박스가 되는 경우를 훨씬 많이 봤습니다. 부채의 절대량이 아니라 부채를 읽을 수 있는 사람의 수가 문제입니다.

이 논문이 10년 넘게 유효한 진짜 이유는, 논문이 제시하는 해법이 도구가 아니라 질문이기 때문입니다. 논문 말미의 자가진단 항목을 실무에 맞게 옮기면 다음과 같습니다.

1. 완전히 새로운 알고리즘 버전을 얼마나 빨리 전체 배포까지 보낼 수 있습니까? 이 리드타임이 곧 부채의 크기입니다. 분기 단위라면 이미 위험 구간입니다.
2. 이 모델의 입력이 되는 모든 데이터 의존성을 한 장으로 그릴 수 있습니까? 그릴 수 없다면, 그 시스템은 아무도 안전하게 변경할 수 없는 상태입니다.
3. 내 모델의 출력을 누가 소비하고 있는지 전부 알고 있습니까? 파일이나 테이블로 예측을 노출하고 있다면, 접근 통제와 소비자 등록을 먼저 만드십시오. 사후에 추적하는 비용이 훨씬 큽니다.
4. 성능 하락을 얼마나 빨리 감지합니까? 논문의 기준은 명확합니다. 모니터링이 없다면 부채가 아니라 시한폭탄입니다.
5. 작년에 제거한 피처와 실험 코드 경로가 몇 개입니까? 0개라면 부채는 단조 증가하고 있습니다.

무엇보다 조직 차원의 전환은 이것입니다. 연구 부채를 갚는 일을 “성과 없는 일”로 취급하지 않는 평가 체계. 정확도를 0.3%p 올린 엔지니어는 승진하고, 파이프라인에서 피처 40개와 죽은 실험 분기를 걷어낸 엔지니어는 보고할 성과가 없는 조직에서는, 부채가 쌓이는 것이 모든 구성원에게 합리적인 선택이 됩니다.

---

6. 결론: 부채는 실패의 원인이 아니라 실패의 지연된 청구서다

기술 부채는 그 자체로 악이 아닙니다. 빠른 검증을 위해 의도적으로 부채를 지는 것은 정당한 전략적 선택입니다. 논문이 경고하는 것은 부채의 존재가 아니라, ML 시스템의 부채는 눈에 보이지 않는 형태로 쌓이기 때문에 조직이 자신이 얼마를 빌렸는지 모른 채 이자를 내고 있다는 사실입니다.

앞선 분석 《랩실에서 99%였던 모델이 프로덕션에서 무너지는 이유》가 데이터 분포의 이동이라는 런타임 실패를 다뤘다면, 이 논문은 그 실패를 감지하고 복구할 수 없게 만드는 구조적 조건을 설명합니다. 드리프트는 증상이고, 숨겨진 기술 부채는 그 증상을 고칠 수 없게 만드는 체질입니다.

그래서 배포는 프로젝트의 끝이 아니라, 유지보수 비용이라는 장부가 처음 열리는 시점입니다. 조직이 그 장부를 읽지 않기로 선택할 수는 있습니다. 다만 청구서는 언제나 도착합니다.