AI 도입 효과를 묻기 전에 인과 그래프에 적어야 할 가정

AI를 도입한 팀이 더 빨랐다는 관찰만으로 도입 효과를 알 수는 없다. DoWhy의 그래프 가정, 효과 식별, 추정, 반증 검사를 구분해 업무 평가를 설계한다.

이 글을 위해 GPT Image 2로 생성한 개념 이미지다. 실제 분석 결과나 인과 그래프를 재현한 그림은 아니다.

어느 기획팀이 AI 도구를 먼저 도입했고, 다른 팀보다 보고서를 빨리 끝냈다고 가정해 보자. 도입 담당자는 시간을 줄였다는 근거를 얻은 것처럼 느낄 수 있다. 그런데 먼저 도입한 팀은 원래 문서 작성에 익숙했고, 자료도 잘 정리해 두었을지 모른다. 빨라진 결과에는 AI의 영향과 도입 전부터 있던 차이가 함께 들어갈 수 있다.

이 장면은 실제 기업의 성과 보고가 아닌 가상 사례다. 문제는 도입팀의 기록을 못 믿겠다는 데 있지 않다. 그 기록으로 답할 수 있는 질문을 구분해야 한다는 데 있다. “AI를 쓰는 팀의 완료 시간이 짧은가”라는 관찰과 “이 팀에 AI를 제공하면 완료 시간이 얼마나 바뀌는가”라는 개입의 질문은 서로 다르다.

인과 추론 도구 DoWhy는 이런 구분을 분석 순서에 드러낸다. 원인과 결과에 관한 가정을 모델로 적고, 그 가정 아래에서 관심 효과를 식별한 뒤, 데이터로 추정하고, 결과를 흔드는 검사를 수행한다.[1] AI가 표와 그래프를 빨리 만들어 주더라도 이 순서를 건너뛸 수는 없다. 먼저 드러내야 할 것은 화려한 분석 결과보다 그 결과가 기대고 있는 가정이다.

그래프의 화살표에는 확인할 가정이 들어간다

지식 그래프에는 “문서가 팀에 속한다”, “자료가 주장을 뒷받침한다” 같은 여러 관계가 들어간다. 인과 그래프의 화살표는 더 특정한 의미를 갖는다. DoWhy의 모델링 안내는 방향 비순환 그래프인 DAG를 사용하며, X → Y를 X가 Y의 원인이라는 관계로 설명한다. 그래프는 변수 사이의 조건부 독립 관계도 표현한다.[2] 단순한 관련성이나 문서 간 연결을 그대로 옮겼다고 인과 모델이 되는 것은 아니다.

앞의 사례에서 팀의 도입 전 숙련도를 S, AI 도구 제공 여부를 T, 보고서 완료 시간을 Y라고 하자. 숙련된 팀이 도구를 먼저 받았고 원래 작업도 빠르다고 가정하면 S → T와 S → Y를 함께 고려해야 한다. 조사하려는 도입 효과는 T → Y에 해당한다. 이때 제공받은 팀과 그렇지 않은 팀의 평균 시간 차이에 숙련도 차이가 섞일 수 있다는 문제가 눈에 보인다.

이 화살표는 사례를 설명하기 위해 세운 가정이지 데이터로 확인된 사실이 아니다. 실제 평가에서는 누가 도입 순서를 정했는지, 숙련도를 언제 어떻게 측정했는지, 업무 난도와 지원 인력은 어떻게 배정됐는지 살펴봐야 한다. 이미 결과가 나온 뒤에 편리한 화살표만 남기면 분석은 결론을 꾸미는 그림이 된다.

DoWhy는 도메인 지식이나 전문가 판단으로 그래프를 만들 수 있고, 데이터에서 구조를 학습하는 방법도 안내한다. 동시에 그래프를 진단하는 검사가 유효성을 확정해 주지는 않는다고 명시한다.[2] LLM이 제안한 그래프도 같은 위치에 놓아야 한다. 검토할 가설을 빠르게 정리하는 데 쓸 수 있지만, 생성된 화살표를 곧 검증된 원인으로 받아들이지는 않는다.

효과를 식별하는 일과 숫자를 계산하는 일

DoWhy의 identify_effect()는 주어진 그래프와 가정에서 관심 인과 효과를 표현할 방법을 찾는 단계다. 이어서 estimate_effect()가 식별된 대상을 통계 방법으로 추정한다.[1][3] 식별은 어떤 조건에서 무엇을 계산하면 관심 효과에 도달할 수 있는지의 문제이고, 추정은 실제 표본으로 그 값을 구하는 문제다.

이 구분은 도구 도입 평가의 시작 문장을 바꾼다. 먼저 “AI 효과”라는 넓은 말부터 좁혀야 한다. 도구 접근권을 제공한 효과를 묻는가, 실제로 도구를 사용한 효과를 묻는가. 결과는 초안 작성 시간인가, 검토와 수정이 끝난 완료 시간인가. 누구를 대상으로 어느 업무 기간을 비교하는가. 이 질문들이 달라지면 같은 표에서 분석해도 답하려는 효과가 달라진다.

도구를 제공받아도 쓰지 않은 팀원이 있을 수 있다. 반대로 사용량이 많은 사람은 원래 어려운 일을 맡았을 수도 있다. 따라서 제공 여부와 실제 사용량을 같은 처치 변수처럼 바꿔 쓰지 않는다. 무엇을 바꾸는 개입을 상정했는지와 어떤 결과를 측정했는지를 먼저 고정하는 편이 낫다. 여기서 제시하는 구분은 가상 사례를 위한 평가 설계 제안이며, DoWhy가 조직의 업무 정의를 대신 정해 준다는 뜻은 아니다.

그다음에는 그래프의 가정과 관측 가능한 변수로 관심 효과를 식별할 수 있는지 살핀다. 현재 가정과 자료로 효과를 정할 수 없다면 더 복잡한 추정기를 고르는 것만으로 문제가 해결되지는 않는다. 빠진 정보를 수집하거나, 비교 대상을 다시 정하거나, 도입 배정 방식을 바꾸는 설계를 검토해야 한다. 관측자료의 조건을 그대로 둔 채 모델의 정밀도만 높이는 일은 인과 가정을 강화하지 않는다.

DoWhy는 하나의 식별된 대상에 여러 추정 방법을 연결할 수 있도록 이 단계를 나눈다.[3] 여러 방법의 숫자가 비슷하다는 것은 비교할 만한 결과지만, 모두 같은 잘못된 가정을 공유할 수도 있다. 추정기 간 일치와 가정의 타당성을 분리해 기록해야 한다.

반증 검사는 무엇이 흔들리는지 보여 준다

DoWhy의 refute_estimate()는 추정 결과를 여러 조건에서 시험한다.[1][3] 예를 들어 결과와 무관한 독립 난수 변수를 추가했을 때 추정값이 크게 달라지는지 살펴볼 수 있다. 실제 처치 대신 독립적인 무작위 변수를 넣는 위약 검사에서는 효과가 0에 가까워지는지를 본다. 관측하지 못한 공통 원인이 있다고 가정했을 때 결론이 얼마나 민감한지도 검토할 수 있다.[3]

이 검사들은 같은 일을 반복하지 않는다. 무관한 변수 추가는 추정 절차의 불안정성을 드러낼 수 있고, 위약 검사는 의미 없는 처치에도 효과가 나오는지 묻는다. 누락된 공통 원인에 대한 민감도 분석은 관측하지 못한 요인이 어느 정도 강할 때 결론이 달라지는지 살피는 작업이다. 결과를 하나의 통과 표시로 압축하면 어떤 가정을 시험했는지 놓치기 쉽다.

특히 검사를 통과했다고 관측하지 못한 원인이 없다는 결론을 내릴 수는 없다. DoWhy의 모델링 문서도 그래프 검사는 타당한 그래프가 만족해야 할 필요 성질을 확인하며, 잘못된 그래프를 기각하거나 개선하는 데 쓰인다고 설명한다.[2] 시험한 조건에서 반례를 찾지 못한 것과 현실의 원인 구조를 모두 알아낸 것은 구분해야 한다.

예측 모델의 검증 점수도 별도다. DoWhy의 소개 문서는 개입 후 분포의 표본을 갖고 있지 않은 상황에서는 일반적인 예측 교차검증으로 인과 추정의 타당성을 평가할 수 없다고 설명한다.[4] 완료 시간을 잘 예측하는 모델이 있다고 해서, AI를 제공하는 정책을 바꿨을 때의 효과까지 정확히 알게 되는 것은 아니다. 결과를 예측하는 능력과 개입의 영향을 알아내는 능력은 평가 대상부터 다르다.

도입 회의에는 추정값 옆에 가정과 한계를 남긴다

다음 표는 공식 문서의 네 단계를 업무 평가 기록으로 옮긴 필자의 제안이다. 실제 조직에서 검증한 성과표나 DoWhy가 자동으로 생성하는 표준 양식은 아니다.

가상 기획팀의 평가라면 최종 보고서에 “AI 도입 후 빨라졌다”만 적기보다, 도구 제공의 효과를 어떤 팀과 업무 범위에서 추정했는지 밝히는 편이 낫다. 숙련도와 업무 난도를 고려했다면 그 값을 도입 전에 확보했는지, 비교할 만한 팀이 실제로 있었는지 함께 적는다. 제공한 도구나 업무 배정이 바뀌면 이전 분석의 가정을 그대로 가져올 수 있는지도 다시 살핀다.

효과를 식별하지 못했다는 결과도 다음 행동을 정하는 데 쓸 수 있다. 같은 비교표를 계속 정교하게 만드는 대신, 도입 순서를 평가 가능한 방식으로 설계하거나 빠진 측정 항목을 준비할 근거가 된다. 어느 설계가 가능한지는 조직의 운영 조건에 달려 있으며, 특정 라이브러리의 실행 성공으로 결정되지 않는다.

인과 그래프의 실용적 가치는 보고서에 원인을 그려 넣는 데서 끝나지 않는다. 어떤 가정이 필요했고, 어디까지 자료로 확인했으며, 무엇을 바꾸면 결론이 달라질 수 있는지를 팀이 함께 검토할 수 있게 하는 데 있다. AI 도입 효과를 주장하는 숫자는 그 기록과 함께 읽힐 때 다음 결정의 근거가 된다.

참고 자료

• [1] PyWhy, DoWhy README — 관측한 main 커밋의 효과 식별·추정 예제. 기본 브랜치와 커밋을 2026-11-03 확인했다.
• [2] DoWhy, Modeling Causal Relations.
• [3] DoWhy, Effect Estimation Using specific Effect Estimators.
• [4] DoWhy, Introduction to DoWhy. 공식 main 문서는 2026-11-03 직접 읽었다. 이 글에서 도입 효과를 계산하거나 DoWhy 코드를 실행한 것은 아니다.
• 함께 읽기: 관계에 출처를 붙였다고 그 관계가 사실이 되지는 않는다. 지식 그래프의 주장과 채택을 다룬 배경 글이며, 인과 효과의 검증 근거를 대신하지 않는다.