2025년 7월 14일·8분
주디아 펄의 인과적 사고: 더 나은 AI, 디버깅, 의사결정
주디아 펄의 인과 모델이 팀이 AI 동작을 설명하고 실패를 디버깅하며 상관관계를 넘어 더 명확한 제품 결정을 내리는 데 어떻게 도움이 되는지 알아보세요.
주디아 펄의 인과 모델이 팀이 AI 동작을 설명하고 실패를 디버깅하며 상관관계를 넘어 더 명확한 제품 결정을 내리는 데 어떻게 도움이 되는지 알아보세요.
한 팀이 대시보드에서 "명백해 보이는" 것을 발견합니다: 알림을 더 많이 받은 사용자가 더 자주 돌아온다. 그래서 알림 빈도를 올립니다. 일주일 후, 유지율은 떨어지고 이탈 불만이 늘어납니다. 무슨 일이었을까요?
원래의 패턴은 실제로 존재했지만 오해를 불러일으켰습니다. 가장 참여도가 높은 사용자가 자연스럽게 더 많은 알림을 트리거(제품을 더 많이 사용하기 때문에)하고, 또한 더 자주 돌아옵니다. 알림이 유지율을 일으킨 것은 아니었습니다; 참여도가 둘 다를 일으켰습니다. 팀은 상관관계에 기반해 행동했고 우연히 더 나쁜 경험을 만들어냈습니다.
인과적 사고는 "무엇이 무엇을 일으키고, 우리는 어떻게 아는가?"를 묻는 습관입니다. "이 둘이 함께 움직인다"는 수준에서 멈추지 않고 다음을 구분하려고 합니다:
데이터를 불신하는 것이 아니라, 질문에 대해 구체화하는 것입니다. “알림과 유지율이 상관하는가?”는 “더 많은 알림을 보내면 유지율이 증가할까?”와 다릅니다. 두 번째 질문이 인과적 질문입니다.
이 글은 패턴 탐지가 실패하는 세 가지 실용적 영역(요약)을 다룹니다:
수학 중심의 인과추론 투어는 아닙니다. 여기서 가치를 얻으려면 do-계산법 표기를 배울 필요는 없습니다. 목표는 팀이 사용할 수 있는 정신 모델과 워크플로우를 제공하는 것입니다:
데이터에서는 좋아 보였지만 현실에서는 작동하지 않았던 변경을 배포한 적이 있다면 인과적 사고가 부족한 고리일 가능성이 큽니다.
주디아 펄은 컴퓨터 과학자이자 과학 철학자로, 그의 작업은 많은 팀이 데이터, AI, 의사결정을 바라보는 방식을 재편했습니다. 그의 인과 혁명 이전에는 컴퓨팅에서 "데이터로부터 학습"이 통계적 연관성에 초점을 맞추는 경우가 많았습니다: 패턴을 찾고, 모델을 맞추고, 다음에 일어날 일을 예측합니다. 이 접근은 강력하지만 "왜"라는 단어가 들어가는 제품이나 엔지니어링 질문을 던지는 순간 종종 무너집니다.
펄의 핵심 전환은 인과성을 일급 개념으로 다루는 것이었습니다. 단순히 "X가 높을 때 Y도 높은가?"를 묻는 대신, 인과적 사고는 "X를 바꾸면 Y가 바뀌는가?"를 묻습니다. 이 차이는 작게 들리지만 예측을 의사결정과 구분합니다.
연관성은 "무엇이 함께 발생하는가"를 답합니다. 인과성은 "우리가 개입하면 무엇이 일어나는가"를 답하려고 합니다. 이는 많은 실제 결정이 개입의 형태를 갖기 때문에 중요합니다: 기능 출시, 순위 변경, 가드레일 추가, 학습 데이터 변경, 정책 조정 등.
펄은 인과를 모델 선택과 명시적 가정으로 프레이밍함으로써 더 실용적으로 만들었습니다. 일반적으로 데이터만으로 인과관계를 자동으로 '발견'하지 않습니다; 도메인 지식에 기반해 인과 이야기를 제안한 다음 데이터를 사용해 이를 검증, 추정, 수정합니다.
이 도구들은 패턴 탐지에서 인과적 질문에 명확하고 규율 있게 답하는 공통 언어를 팀에 제공했습니다.
상관관계는 두 변수가 함께 움직인다는 뜻입니다: 하나가 오르면 다른 것이 경향적으로 오릅니다(또는 내립니다). 이는 특히 데이터 중심 팀에서 매우 유용합니다 — 예측과 탐지에 도움을 줍니다.
예를 들어 기온이 오르면 아이스크림 판매가 급증하는 경우, 상관 신호(기온)는 예측력을 높여줍니다. 제품과 AI 작업에서 상관관계는 랭킹 모델, 이상 탐지, 빠른 진단에 힘을 줍니다.
문제는 우리가 상관관계를 "무엇을 의도적으로 바꾸면 무슨 일이 일어나는가?"라는 다른 질문에 대한 답으로 취급할 때 시작됩니다. 그게 바로 인과입니다.
상관관계는 제3의 요인이 두 변수를 모두 영향을 주어 발생할 수 있습니다. X를 바꾼다고 해서 Y가 반드시 바뀌는 것은 아닙니다 — X가 Y를 움직이게 한 이유가 아닐 수 있기 때문입니다.
주간 마케팅 지출과 주간 매출을 플롯했더니 강한 양의 상관관계가 보인다고 상상해보세요. “더 많은 지출이 더 많은 매출을 일으킨다”고 결론짓고 싶어질 수 있습니다.
하지만 둘 다 휴일에 증가한다고 가정합시다. **시즌(휴일)**이 교란변수로 더 높은 수요를 유발하고 더 큰 예산을 촉발합니다. 비휴일 주에 지출을 늘리면 기저 수요가 없기 때문에 매출이 크게 오르지 않을 수 있습니다.
다음과 같은 질문을 자신에게 하고 있다면 당신은 인과 영역에 있습니다:
동사가 변경, 출시, 제거, 감소일 때, 상관관계는 출발 단서이지 결정 규칙이 아닙니다.
인과 다이어그램—흔히 DAG(유향 비순환 그래프)—은 팀의 가정을 가시화하는 간단한 방법입니다. “아마 모델일 것” 또는 “UI 탓일지도” 같은 모호한 말 대신 이야기를 그림으로 올려 논의를 촉진합니다.
목표는 완전한 진실이 아니라 팀이 시스템이 어떻게 작동한다고 생각하는지 공유하고 비판할 수 있는 초안입니다.
예를 들어 **새 온보딩 튜토리얼(T)**이 **활성화(A)**를 증가시키는지 평가한다고 합시다.
분석에서 흔한 반응은 "사용 가능한 모든 변수를 통제하자"는 것입니다. DAG 관점에서는 이것이 실수로:
DAG를 사용하면 변수를 존재한다고 조정하는 대신, 보통은 교란 경로를 차단하기 위해 이유를 가지고 조정합니다.
화이트보드에서 세 단계로 시작하세요:
거친 DAG도 제품, 데이터, 엔지니어링이 숫자를 돌리기 전에 같은 인과 질문에 합의하도록 정렬합니다.
펄의 인과적 사고에서 큰 전환은 관찰과 변경을 분리한 것입니다.
사용자가 알림을 활성화한 사용자가 더 높은 유지율을 보인다고 관찰했다면 패턴을 알긴 했습니다. 그러나 알림이 유지율을 일으키는지, 아니면 단순히 참여도가 높은 사용자가 알림을 켜는 것인지 모릅니다.
개입은 변수를 특정 값으로 적극 설정하고 그 다음에 무슨 일이 일어나는지 묻는 것입니다. 제품 관점에서 이는 "사용자가 X를 선택했다"가 아니라 "우리가 X를 출시했다"는 뜻입니다.
펄은 흔히 이 차이를 이렇게 구분합니다:
"do" 아이디어는 변수가 값을 가지는 평소 이유를 깨뜨린다는 정신적 메모입니다. 개입을 하면 알림은 참여자가 자발적으로 켠 것이 아니라 당신이 설정했기 때문에 인과관계를 고립시키는 데 도움이 됩니다.
대부분 실제 제품 작업은 개입 형태입니다:
이러한 조치는 결과를 변경하려는 것이지 단지 설명하려는 것이 아닙니다. 인과적 사고는 질문을 정직하게 유지합니다: “이걸 하면 무엇이 바뀔까?”
좋은 실험을 설계하거나 개입을 해석하려면 무엇이 무엇에 영향을 주는지에 대한 가정—비공식적인 인과 다이어그램이라도—없이는 어렵습니다.
예를 들어 계절성이 마케팅 지출과 가입 모두에 영향을 준다면, 계절성을 고려하지 않고 지출 변경을 ‘하는 것’은 여전히 오해를 초래할 수 있습니다. 개입은 강력하지만 기본 인과 이야기가 적어도 대략 맞아야 인과 질문에 답할 수 있습니다.
반사실은 특정한 종류의 “만약” 질문입니다: 이 특정 사례에 대해, 우리가 다른 행동을 취했더라면 어떤 일이 있었을까? 이는 평균적으로 무슨 일이 일어났느냐가 아니라 “이 사람, 이 티켓, 이 거래에 대해 결과가 달라졌을까?”를 묻습니다.
반사실은 다음 상황에서 등장합니다:
이 질문들은 자연스럽게 개별 사용자 수준입니다. 또한 제품 변경, 정책, 설명에 실용적 지침을 제공합니다.
대출 모델이 신청을 거절했다고 가정해보세요. 상관관계 기반 설명은 “저축이 적어 거절되었다”라고 말할 수 있습니다. 반사실은 다음을 묻습니다:
신청자의 저축이 3,000달러 더 많았다면(다른 모든 것이 동일하다면) 모델은 승인을 했을까?
만약 답이 "예"라면, 결정을 뒤집을 수 있는 실행 가능한 변경을 알게 됩니다. 만약 "아니오"라면, 빚-소득비나 불안정한 고용 이력이 실제 걸림돌이라는 잘못된 조언(예: 저축만 늘리라)을 피할 수 있습니다.
반사실은 단지 데이터셋에 의존하지 않고 인과 모델—변수들이 서로 어떻게 영향을 주는가에 대한 이야기—에 의존합니다. 무엇이 현실적으로 바뀔 수 있고, 결과로 무엇이 함께 바뀔지, 무엇은 고정되어야 하는지를 결정해야 합니다. 인과 구조가 없으면 반사실은 불가능한 시나리오(“소득이나 지출은 바꾸지 않고 저축만 늘려라”)가 되어 도움이 되지 않거나 불공정한 권고를 만들 수 있습니다.
ML 모델이 운영에서 실패하면 근본 원인은 드물게 "알고리즘이 나빠졌다"입니다. 더 자주 발생하는 것은 시스템의 어딘가가 변했다는 점입니다: 수집하는 데이터, 라벨 생성 방식, 사용자 행동 등. 인과적 사고는 추측을 멈추고 무엇이 성능 저하를 야기했는지 고립시키게 도와줍니다.
반복적으로 나타나는 문제들:
이들은 집계 대시보드에서 "괜찮아 보일" 수 있습니다. 상관관계는 높게 유지되더라도 모델이 옳았던 이유가 변했을 수 있기 때문입니다.
단순한 인과 다이어그램(DAG)은 디버깅을 지도처럼 만듭니다. 이 그래프는 이 피처가 라벨의 원인인지, 결과의 결과인지, 아니면 측정 방식의 결과인지 묻도록 강제합니다.
예: 라벨링 정책 → 피처 엔지니어링 → 모델 입력 경로가 있다면 파이프라인이 모델이 근본 현상 대신 정책을 예측하도록 만들었을 수 있습니다. DAG는 그 경로를 가시화해 피처 제거, 계측 변경, 라벨 재정의를 통해 이를 차단하게 합니다.
예측만 검사하지 말고 통제된 개입을 시도하세요:
많은 "설명가능성" 도구는 좁은 질문에 답합니다: 왜 모델이 이 점수를 냈나? 이들은 종종 영향력 있는 입력(피처 중요도, 살리언시 맵, SHAP 값)을 강조합니다. 이것은 유용할 수 있지만 모델이 놓인 시스템을 설명하는 것과는 다릅니다.
예측 설명은 국소적이고 기술적입니다: “이 대출은 소득이 낮고 사용률이 높아 주로 거절되었습니다.”
시스템 설명은 인과적이고 운영적입니다: “검증된 소득을 올리거나 사용률을 낮춘다면, 실제로 개입으로 결정을 바꿀 수 있고 그 결과 하류 성과도 개선될까?”
첫 번째는 모델 행동을 해석하는 데 도움을 줍니다. 두 번째는 무엇을 해야 하는가를 결정하는 데 도움을 줍니다.
인과적 사고는 설명을 개입과 연결합니다. 어떤 변수가 점수와 상관하는지가 아니라 어떤 변수가 유효한 레버인지, 바꿨을 때 어떤 효과를 낼지를 묻습니다.
인과 모델은 다음을 명시하도록 강제합니다:
이는 "중요한 피처"가 프록시일 수 있음을 보여주기 때문에 중요합니다 — 예측엔 유용하지만 행동에는 위험할 수 있습니다.
사후 설명은 설득력 있어 보이지만 여전히 순전히 상관적인 경우가 많습니다. 예: “지원 티켓 수”가 이탈을 강하게 예측하면 피처 중요도 플롯이 팀을 유혹해 “지원 접근성을 줄여 티켓을 줄이자”고 만들 수 있습니다. 그 개입은 역효과로 이어질 수 있습니다. 티켓은 근본적인 제품 문제의 증상이지 원인이 아닐 수 있습니다.
상관 기반 설명은 분포 변화 중에 취약하기도 합니다: 사용자 행동이 바뀌면 동일하게 강조된 피처가 더 이상 같은 의미를 가지지 않을 수 있습니다.
결정에 결과와 책임이 따를 때 인과적 설명은 특히 가치가 있습니다:
행동해야 할 때, 설명은 인과적 기반이 필요합니다.
A/B 테스트는 가장 단순하고 실용적인 형태의 인과추론입니다. 사용자를 무작위로 A나 B에 배정하면 개입을 수행하는 것입니다: 사용자가 무엇을 선택했는지를 관찰하는 것이 아니라 그들이 보는 것을 설정하는 것입니다. 펄의 용어로 무작위화는 “do(variant = B)”를 현실로 만듭니다 — 따라서 결과 차이는 변경 때문이라고 신뢰할 수 있습니다.
무작위 배정은 사용자 특성과 노출 간 숨은 연결을 많이 끊어 줍니다. 파워 사용자, 신규 사용자, 시간대, 기기 유형 같은 요인들은 여전히 존재하지만(평균적으로) 그룹 간에 균형을 이루게 됩니다. 그 균형이 지표 격차를 인과 주장으로 바꿉니다.
심지어 훌륭한 팀도 항상 깔끔한 무작위 테스트를 실행할 수 있는 것은 아닙니다:
이 경우에도 인과적으로 생각할 수 있지만 가정과 불확실성을 명시해야 합니다.
일반적인 옵션: 차분-차분(그룹 간 시간에 따른 변화를 비교), 회귀불연속(점수 X 이상만 처리 등 컷오프 규칙 사용), 도구변수(노출을 바꾸지만 결과에 직접적 영향을 주지 않는 자연적 충동), 매칭/가중치로 그룹을 더 비교가능하게 만들기. 각 방법은 무작위화를 가정 대신 가정을 요구합니다; 인과 다이어그램이 그 가정을 명확히 하는 데 도움이 됩니다.
테스트(또는 관찰 연구)를 시작하기 전에 주요 지표, 가드레일, 대상 집단, 기간, 의사결정 규칙을 적어두세요. 사전 등록은 편향을 제거하진 않지만 메트릭 쇼핑을 줄이고 인과 주장을 더 신뢰할 수 있게 하며 팀 토론을 쉽게 만듭니다.
대부분 제품 논쟁은 이렇게 들립니다: “Y를 배포한 후 지표 X가 움직였다—그러니 Y가 효과가 있었다.” 인과적 사고는 이를 더 명확한 질문으로 바꿉니다: “변경 Y가 지표 X를 움직이게 했나, 그리고 어느 정도인가?” 이 변화는 대시보드를 증거가 아니라 출발점으로 바꿉니다.
가격 변경: “가격을 10% 올리는 것이 계정 전환, 이탈, 지원 티켓에 어떤 영향을 미치는가(계절성 고정)?”
온보딩 수정: “온보딩을 6단계에서 4단계로 줄이면 신규 사용자의 활성화와 4주차 유지율은 어떻게 변하나?”
추천 순위 변경: “신선도를 우선 배치하면 클릭률이 좋아지는가? 장기 만족(반복 방문, 숨기기, 구독 해지 등)에 어떤 영향이 있는가?”
대시보드는 종종 "변경을 받은 사람"과 "원래 잘했을 사람"을 섞어 보여줍니다. 고전적 예: 새 온보딩 플로우가 더 자주 완료된다면, 그것이 최신 앱 버전을 먼저 본 사용자들에게만 노출되었을 수 있습니다. 최신 버전을 채택하는 사용자가 더 참여도가 높다면 차트의 향상은 일부(또는 대부분) 버전 채택 때문일 수 있습니다.
제품 분석에서 흔한 교란 요인:
유용한 PRD 섹션은 문자 그대로 "인과 질문(Causal Questions)"이라는 제목을 달고 다음을 포함합니다:
특히 LLM 지원 개발처럼 빠른 빌드 루프를 사용하는 팀에서는 이 섹션이 더 중요합니다: "빠르게 배포"가 "무엇을 야기했는지 모르는 채 배포"가 되는 것을 막아줍니다. Koder.ai 같은 플랫폼을 사용하는 팀은 일반적으로 계획 단계에서 이러한 인과 질문을 내장하고, 기능 플래그와 스냅샷/롤백을 통해 결과(또는 부작용)에 놀랐을 때 실험을 안전하게 유지합니다.
PM은 결정과 성공 기준을 정의합니다. 데이터 파트너는 이를 측정 가능한 인과 추정치와 온당성 검사로 번역합니다. 엔지니어링은 변경이 제어 가능하게(기능 플래그, 깨끗한 노출 로깅) 구현되도록 보장합니다. 지원팀은 정성적 신호를 공유합니다—가격 변경은 종종 효과가 있는 듯 보이지만 취소나 티켓 증가를 조용히 초래할 수 있습니다. 모두가 인과 질문에 합의할 때, 배포는 단순 배포가 아니라 학습이 됩니다.
인과적 사고는 박사학위 수준의 출시가 필요 없습니다. 팀 습관으로 다루세요: 인과 이야기를 적고, 압박 검토하고, 데이터(가능하면 실험)로 확인하거나 수정합니다.
진전을 위해서는 다음 네 가지 입력을 사전에 수집하세요:
실무에서는 속도가 중요합니다: 인과 질문을 통제된 변경으로 빠르게 전환할수록 모호한 패턴을 두고 논쟁하는 시간이 줄어듭니다. 이것이 팀들이 Koder.ai 같은 플랫폼을 도입해 "가설 + 계획"에서 작동하는 구현(웹, 백엔드, 모바일)까지 며칠 내에 전환하는 한 이유입니다—동시에 단계적 롤아웃과 롤백으로 엄격함을 유지합니다.
실험에 대한 요약이 필요하면 /blog/ab-testing-basics를 참조하세요. 제품 지표에서 “효과처럼 보이는” 흔한 함정은 /blog/metrics-that-mislead를 보세요.
인과적 사고는 “무엇이 함께 움직이는가?”에서 “우리가 행동하면 무엇이 바뀌는가?”로의 전환입니다. 이 전환은 주디아 펄이 대중화한 개념으로, 팀이 현실 개입 앞에서 버텨내지 못하는 자신감 넘치는 이야기들을 피하게 합니다.
상관관계는 단서일 뿐 해답이 아니다.
인과 다이어그램(DAG)은 가정을 가시화하고 토론하게 한다.
개입(“do”)은 관찰(“see”)과 다르다.
반사실은 단일 사례에 대해 “이것이 달랐다면?”을 설명한다.
좋은 인과 작업은 불확실성과 대안 설명을 문서화한다.
인과는 주의가 필요합니다: 숨은 교란, 측정 오류, 선택 효과가 결론을 뒤집을 수 있습니다. 해독제는 투명성입니다—가정을 적고, 사용한 데이터를 공개하며, 주장이 반증될 수 있는 조건을 명시하세요.
더 깊이 들어가고 싶다면 /blog에서 관련 글을 찾아보고 인과 접근법을 다른 분석 및 “설명가능성” 방법과 비교해 각 방법이 어디에 도움이 되고 어디에서 오해를 불러오는지 확인하세요.
상관관계는 예측이나 탐지에 도움이 됩니다(예: “X가 오르면 Y도 종종 오른다”). 인과관계는 의사결정 질문에 답합니다: “우리가 X를 의도적으로 바꾸면 Y가 바뀔까?”
예측과 모니터링에는 상관관계를 사용하고, 변화를 배포하거나 정책을 정하거나 예산을 배분할 때는 인과적 사고를 사용하세요.
그 상관관계는 교란(confounding) 때문에 생겼을 수 있습니다. 알림 예시에서는 높은 참여도를 가진 사용자가 더 많은 알림을 트리거/수신하고 동시에 더 자주 복귀합니다.
모두에게 알림을 늘리면 경험 자체가 바뀌지만 근본적인 참여도는 바뀌지 않으므로 유지율이 개선되지 않거나 오히려 악화될 수 있습니다.
DAG(Directed Acyclic Graph)는 다음과 같은 단순한 다이어그램입니다:
이렇게 하면 어떤 변수를 조정해야 하는지, 무엇을 실수로 조정하면 안 되는지, 그리고 어떤 실험이 실제로 질문에 답할지를 팀 전체에 명확히 보여줄 수 있습니다.
흔한 실수는 "모든 것을 통제하자"는 태도인데, 이 경우 매개변수나 콜라이더를 실수로 조정해 결과에 편향을 초래할 수 있습니다.
“See”는 자연스럽게 일어난 것을 관찰하는 것입니다(사용자가 선택함, 점수가 높음). “Do”는 변수를 적극적으로 설정하는 것입니다(기능 출시, 기본값 강제 등).
핵심은: 개입(intervention)은 변수가 값을 가지는 평소 이유를 깨뜨리기 때문에 관찰만으로는 드러나지 않던 인과관계를 밝힐 수 있다는 점입니다.
반사실(counterfactual)은 특정 사례에 대한 “만약에” 질문입니다: 이 특정 경우에 우리가 다른 조치를 취했더라면 결과가 달라졌을까?
유용한 상황:
반사실은 현실적인 변경이 무엇인지, 무엇이 함께 바뀌어야 하는지를 규정하는 인과 모델을 필요로 합니다.
생산 환경에서 ML 모델이 실패하면 원인은 종종 ‘알고리즘의 성능 저하’가 아니라 upstream의 어떤 변화입니다:
인과적 사고는 표적 개입(특정 데이터 편집, 기능 제거, 민감도 테스트)을 통해 어떤 변경이 성능 저하를 야기했는지 고립시키도록 유도합니다.
부분적으로는 그렇지 않습니다. 피처 중요도는 예측에 어떤 입력이 영향을 줬는지 설명할 뿐, 무엇을 바꿔야 할지를 알려주지 않습니다.
예: 고객 문의 수가 이탈률을 예측한다면 ‘지원 접근을 어렵게 해서 티켓을 줄이자’는 개입은 역효과를 낼 수 있습니다. 인과적 설명은 어떤 변수가 실제로 레버(조작 가능한 요소)인지, 개입했을 때 어떤 결과가 발생할지를 연결해 줍니다.
가능하다면 무작위 A/B 테스트가 최선입니다. 무작위 배정은 노출과 사용자 특성 간의 숨은 연결을 끊어 주어 측정된 차이를 인과적 효과로 신뢰하게 합니다.
그러나 항상 무작위화가 가능한 것은 아닙니다:
이럴 경우 차분-차분(difference-in-differences), 회귀불연속(regression discontinuity), 도구변수(instrumental variables), 매칭/가중치 등의 준실험적 방법을 고려하되, 각 방법이 요구하는 가정을 명확히 하세요.
PRD와 의사결정 문서에 짧은 섹션을 추가해 초기부터 명확성을 강제하세요:
이렇게 하면 팀이 사후 대시보드 해석 대신 인과적 질문에 합의하게 됩니다.