새벽 3시, 상관관계가 인과관계를 가장한 순간
근거는 있나요? 위성 이상 대응 시뮬레이션에서 블랙박스 RL 에이전트가 센서 고장 상황을 '안전 상태'로 오인해 비상 전력을 거의 소진시킨 사건이 보고됐습니다(dev.to, Explainable Causal RL for Satellite Anomaly Response). 원인은 명확합니다. 에이전트가 correlation을 causation으로 취급한 겁니다. 특정 센서 읽기값과 '안전'이라는 보상 신호가 높은 상관을 보였고, 센서 자체가 오작동하는 분포 외(out-of-distribution) 상황에서 에이전트는 그 가짜 상관을 유지하기 위해 극단적 행동을 선택했습니다. 이건 시뮬레이션이니까 로그를 뒤져서 복구할 수 있었지만, 실제 운영 환경이었다면 ablation study 결과를 들이밀 시간조차 없었을 겁니다.
핵심 이슈: 설명 불가능한 모델은 프로덕션 자격이 없다
이 사례의 저자가 제안한 해법은 Causal MDP(CMDP) 프레임워크입니다. 기존 MDP·POMDP가 상태-행동 매핑에 집중하는 반면, CMDP는 에이전트 내부에 인과 그래프(causal graph)를 유지하면서 do-calculus 기반 개입 예측(intervention prediction)을 수행합니다. 여기에 zero-trust 거버넌스를 결합해 모든 행동이 실행 전에 인증·인가·암호화 검증을 통과해야 하는 구조를 제안했습니다. 구조적으로는 흥미롭습니다. 하지만 데이터 분석가로서 먼저 던져야 할 질문이 있습니다: 이 인과 그래프의 구조 학습(structure learning)에 사용된 관측 데이터의 샘플 사이즈와 분포는 충분한가요? PC 알고리즘이든 NOTEARS든, 인과 발견 알고리즘의 성능은 데이터 품질에 극도로 민감합니다. 저자의 코드에서 learn_structure 메서드가 하드코딩된 엣지(solar_flux → power_generation 등)로 단순화된 것은 illustration이라지만, 실제 위성 환경의 센서 수백 개에서 인과 구조를 자동 발견할 때 false edge rate과 missed edge rate의 trade-off를 어떻게 관리할지가 관건입니다. 재현 가능성(reproducibility) 측면에서도, 시뮬레이션 환경의 하이퍼파라미터와 보상 함수 설계가 공개되어야 베이스라인 대비 개선 폭을 검증할 수 있습니다.
맥락 해석: RAG 파이프라인과 색상 추출이 같은 문제를 가리킨다
위성 시나리오만의 문제가 아닙니다. 개인 금융 AI 앱 사례(dev.to, Web/Mobile Personal AI CFO)를 보면, RAG 기반 재무 Q&A 서비스에서 임베딩 품질이 응답의 정확도를 좌우한다는 점이 솔직하게 기술되어 있습니다. 저자는 "무엇을 임베딩할 것인가(전체 거래 텍스트 vs. 요약)"와 "언제 재인덱싱할 것인가"를 초기에 결정하지 못해 채팅 품질 개선이 지연됐다고 밝혔습니다. 여기서 핵심은 벡터 검색의 recall과 precision이 임베딩 파이프라인의 전처리 전략에 종속된다는 점입니다. user_id와 household_id로 쿼리를 스코핑해 데이터 누수를 방지한 설계는 좋지만, 임베딩 드리프트—사용자의 소비 패턴이 변하면서 기존 임베딩이 현재 쿼리와 의미적으로 괴리되는 현상—에 대한 모니터링 전략은 언급되지 않았습니다. 프로덕션에서 이 성능이 유지될까요?
더 단순한 사례도 같은 패턴을 보여줍니다. 이미지 색상 추출 API를 선택하는 과정(velog, 10-색상 추출 API)에서, 저자는 Google Cloud Vision API, Imagga, Cloudinary, Color Thief 네 가지를 비교한 후 Vision API를 선택했습니다. 선택 근거는 "분석이 정교함", "픽셀 밀도까지 추출" 같은 정성적 판단입니다. 그런데 정량적 비교가 빠져 있습니다. 동일 이미지 세트에 대해 각 API가 추출한 dominant color의 RGB 편차가 얼마인지, 추출된 색상의 분류 정확도(ground truth 대비)가 어떤지 측정한 결과가 없습니다. DB에 색상 이름 컬럼을 만들고 RGB 범위를 수동으로 정의하겠다는 설계는, 경계값(boundary case)에서 분류 오류가 어떤 비율로 발생하는지 실험 없이는 평가할 수 없습니다.
시사점: 파이프라인의 모든 단계에 '감사 로그'가 필요하다
세 사례를 관통하는 교훈은 하나입니다. 모델의 최종 출력만 평가하는 것은 충분하지 않고, 데이터가 흘러가는 파이프라인의 각 단계가 설명 가능해야 합니다. 위성 CMDP는 인과 그래프의 엣지 하나하나가 검증 가능해야 의미가 있고, 금융 RAG는 임베딩 생성→벡터 검색→프롬프트 주입의 각 단계에서 recall@k 같은 중간 지표를 모니터링해야 hallucination을 통제할 수 있습니다. 색상 분류조차 RGB 범위 정의라는 '피처 엔지니어링' 단계의 품질이 전체 시스템 정확도의 상한을 결정합니다.
위성 사례의 zero-trust 거버넌스 아이디어—모든 행동에 대해 실행 전 암호화 검증을 요구하는 구조—는 개념적으로는 MLOps의 모델 거버넌스(model governance)와 정확히 같은 문제를 풀고 있습니다. 프로덕션 ML 시스템에서 모델 버전, 입력 데이터 분포, 피처 스토어 상태, 추론 결과를 모두 감사 가능(auditable)하게 만드는 것이 결국 'AI의 zero-trust'입니다. 다만 현실은, zk-SNARK 기반 행동 검증의 latency 오버헤드가 실시간 위성 운영의 응답 시간 요구사항과 양립할 수 있는지 벤치마크가 필요합니다.
전망: Explainability는 선택이 아니라 인프라다
앞으로 프로덕션 AI에서 설명 가능성은 모델 아키텍처의 부가 기능이 아니라, 데이터 파이프라인 인프라의 기본 요건으로 자리잡을 것입니다. 인과 추론이 RL에 통합되는 흐름, RAG 파이프라인에서 중간 검색 결과의 출처 추적(citation), 심지어 색상 추출 같은 단순한 API 선택에서도 정량적 비교 실험의 부재가 기술 부채로 돌아옵니다. 결국 질문은 같습니다: 이 파이프라인의 어느 단계에서 데이터 품질이 무너지면, 최종 출력이 얼마나 틀어지는지 추적할 수 있습니까? 이 질문에 답할 수 없는 시스템은, 아무리 SOTA 성능을 주장해도 프로덕션 자격이 없습니다.