<!doctype html>
2026년 6월 26일 | 개발 공부
Bland-Altman plot은 두 측정값의 평균을 가로축에 두고, 두 값의 차이를 세로축에 찍어 두 방법이 서로 얼마나 맞는지를 보는 그래프다. 나는 예전에는 두 점수표가 비슷해 보이면 상관계수부터 확인했다. 그런데 모델 평가나 데이터 파이프라인 비교에서는 상관이 높아도 실제 차이가 실무 허용 폭 밖으로 벌어지는 경우가 있다. 그럴 때 Bland-Altman plot은 “둘이 같이 오르내리는가”보다 “서로 바꿔 써도 되는가”를 먼저 묻게 만든다.
상관계수가 놓치는 장면
두 모델의 점수, 두 annotator의 라벨 점수, 새 측정 스크립트와 예전 스크립트의 결과를 비교할 때 상관계수는 꽤 매력적이다. 숫자 하나로 “비슷하게 움직인다”를 말해 주기 때문이다. 문제는 상관계수가 절대적인 차이의 크기를 직접 말해 주지는 않는다는 점이다. 한 방법이 항상 다른 방법보다 0.03점 높게 나오더라도 순서가 비슷하면 상관은 높게 나올 수 있다. 평가 리포트에서는 이 0.03이 아무것도 아닐 수 있지만, 임계값 근처 샘플을 많이 다루는 서비스에서는 꽤 큰 차이일 수 있다.
Bland-Altman 방식은 각 샘플마다 두 값의 평균과 차이를 만든다. 예를 들어 A 파이프라인 점수와 B 파이프라인 점수가 있으면 가로축은 두 점수의 평균, 세로축은 B에서 A를 뺀 값이 된다. 이렇게 놓으면 점수대가 낮을 때만 차이가 큰지, 높은 점수대에서 한쪽이 계속 후하게 나오는지, 차이가 특정 방향으로 기울어지는지 한눈에 보인다. 단순한 산점도보다 덜 화려하지만, 내가 실제로 알고 싶은 질문에는 더 가깝다.
세 줄만 먼저 그려도 충분한 이유
이 그래프에서 먼저 보는 선은 세 개다. 첫 번째는 평균 차이, 흔히 bias라고 부르는 선이다. 두 방법의 차이를 모두 평균냈을 때 어느 쪽으로 치우치는지 보여 준다. 두 번째와 세 번째는 그 평균 차이에서 차이의 표준편차를 약 1.96배만큼 위아래로 벌린 95% limits of agreement다. Bland와 Altman이 제안한 이 읽기 방식은 두 정량 측정값의 차이가 대체로 어느 범위 안에 들어오는지 확인하는 데서 출발한다.
중요한 건 이 선을 통계 장식처럼 붙이지 않는 것이다. 합의 한계가 넓게 나오면 “평균 차이는 작다”는 말만으로는 부족하다. 평균 차이가 0에 가까워도, 개별 샘플에서는 어느 쪽으로든 크게 흔들릴 수 있기 때문이다. 반대로 합의 한계가 업무상 허용 가능한 폭 안에 들어오고, 차이가 평균 점수에 따라 기울지 않는다면 두 방법을 교체하거나 병행해도 되는 후보로 볼 수 있다. 여기서의 핵심은 p-value보다 허용 가능한 오차 폭을 먼저 정하는 습관이다.
모델 평가표에 붙일 때의 감각
AI 모델 평가에서는 이 그래프를 그대로 의료 측정 비교처럼 쓰기보다, 작은 진단 도구로 가져오는 편이 좋다. 예를 들어 retrieval profile A와 B가 같은 query set에 대해 점수를 냈다면 query별 평균 점수와 차이를 그려 볼 수 있다. 새 scoring rule이 전체적으로 0.01점 높아졌는지보다, 특정 점수대의 query에서만 과하게 벌어지는지를 보는 것이다. 이 관점은 [[bootstrap-confidence-interval]]이나 [[minimum-detectable-effect]]를 떠올리게 한다. 평균 차이를 말하기 전에, 그 차이가 샘플 구성과 평가 설계 안에서 어느 정도 버티는지 같이 봐야 하기 때문이다.
나는 특히 새 평가 스크립트를 넣을 때 이 사고방식이 유용했다. 결과표가 거의 같아 보여도 tail query에서만 차이가 커지면, 평균이나 상관만으로는 늦게 잡힌다. Bland-Altman식 그림을 붙이면 “평균 점수 0.7 이상 구간에서 B가 계속 낮다”처럼 디버깅할 문장이 생긴다. 이 문장은 단순히 “상관 0.98이라 괜찮다”보다 다음 행동으로 이어지기 쉽다.
운영 표에서는 이 차이를 한 번 더 쪼갠다. 전체 query를 한 장에 찍은 뒤, 길이·언어·정답 유형·검색 실패 유형 같은 묶음별로 색을 바꿔 본다. 그러면 평균 차이가 같은 두 실험이라도 전혀 다른 문제가 보인다. 한쪽은 전체적으로 조금씩 흔들리고, 다른 한쪽은 특정 묶음에서만 크게 튄다. 내가 후자를 더 조심하는 이유는 간단하다. 특정 묶음의 오차는 배포 뒤 사용자 불만이나 장애 리포트로 더 선명하게 돌아오는 경우가 많기 때문이다.
해석을 망치는 흔한 실수
첫 번째 실수는 합의 한계를 본 뒤에 허용 폭을 정하는 것이다. 결과가 마음에 들면 폭을 넓히고, 마음에 안 들면 좁히는 순간 그래프는 판단 기준이 아니라 변명이 된다. 두 번째 실수는 샘플 독립성을 너무 쉽게 가정하는 것이다. 같은 사용자, 같은 query family, 같은 환자에서 여러 관측치가 반복되면 단순한 점 하나씩으로 처리하기 어렵다. 반복 측정이 있으면 평균을 어떻게 낼지, cluster 단위로 볼지, 별도 모델을 써야 할지 먼저 정해야 한다.
세 번째 실수는 차이의 분포가 점수 크기에 따라 달라지는 장면을 무시하는 것이다. 평균이 커질수록 차이도 커진다면 단순한 고정 오차 범위보다 비율 차이나 log 변환 쪽이 더 자연스러울 수 있다. 그래서 나는 그래프를 볼 때 bias 선이 예쁘게 0에 붙어 있는지보다, 점들이 부채꼴로 퍼지는지와 한쪽 점수대에만 몰린 outlier가 있는지를 먼저 본다.
내가 남기는 최소 기록
작은 실험 노트에는 복잡한 통계표까지 매번 넣을 필요는 없다. 대신 샘플 단위, 평균 차이, 합의 한계, 사전에 정한 허용 폭, 그리고 크게 벗어난 샘플 몇 개를 함께 남긴다. 예를 들면 “query 단위, B-A 평균 0.004, 합의 한계 -0.031에서 0.039, 허용 폭 0.02 초과 query 7개”처럼 적는다. 이 정도만 있어도 다음에 볼 것은 명확해진다. 합의 한계가 허용 폭보다 넓으면 [[tost-equivalence-margin]]식 등가성 주장으로 바로 넘어가지 않고, 먼저 어떤 샘플 묶음에서 차이가 커졌는지 내려가 보는 편이 안전하다.
Bland-Altman plot을 배운 뒤 가장 많이 바뀐 건 “비슷하다”라는 말을 쓰는 순서였다. 이제는 상관이 높다는 문장 앞에, 개별 차이가 실제로 감당 가능한 범위 안에 있는지를 먼저 붙이려고 한다. 모델 평가에서도 측정 도구 비교에서도 결국 필요한 건 멋진 숫자 하나가 아니라, 두 방법을 같은 결정 자리에 올려도 되는지에 대한 근거이기 때문이다.
'[개발 공부]' 카테고리의 다른 글
| Brier score: 확률 예측의 거리 (0) | 2026.06.29 |
|---|---|
| ICC: 반복 측정값의 신뢰도 (1) | 2026.06.26 |
| MDE: 실험표가 잡아낼 수 있는 최소 차이 (0) | 2026.06.25 |
| TOST 등가성 검정과 허용 폭 (0) | 2026.06.25 |
| Hedges' g: 작은 표본 보정이 붙은 효과 크기 (0) | 2026.06.24 |