#9. 모델은 왜 정답을 100% 확신하지 않는가?
1. 모델은 왜 "정답" 대신 "확률"을 말할까?
정말 100%?모델이 출력하는 값이 꼭 Yes/No 가 아니고,
0.83 / 0.47 / 0.68처럼 확률로 나오는 이유는?
그건 당연하게도 현실의 데이터가 애매한 경우가 많기 때문이다.
예)
이 유저, 내일도 앱스토어에서 결제할까? → 하지만... 갑자기 내일 갤럭시로 바꿀 수도..? → 확률로 표현
이 문장, 긍정일까 부정일까? → 근데... 반어법일 수도..? → 확률로 표현
이처럼 모델은 결과를 "0 또는 1"로 예단하지 않고, "그럴 가능성이 얼마 정도 되는지"를 출력한다. 이게 바로 확률 기반 예측이다.
2. 그럼 어디서 끊어야 할까? Threshold란?
이 선 넘어오는 유저들은 다 타깃이야모델이 이렇게 확률을 출력하면, 기획자는 그 수치를 어느 지점부터 "긍정"으로 판단할지를 정하는 값이 바로 Threshold다.
예) 결제 확률: 0.83
threshold가 0.7이라면?
→ 이 유저는 타깃 대상
만약 threshold가 0.9였다면?
→ 같은 유저라도 타깃이 아님!
'Threshold'는 모델의 출력을 서비스 동작으로 바꾸는 기준선이라고 할 수 있다. 이 기준은 정해진 게 아니라 서비스 목적에 따라 조정하는 것이다.
3. 출력값의 해석 기준 – Threshold는 어떻게 정할까?
Threshold 설정을 위한 실험 방법은 여러 가지가 있을 수 있다.
(1) A/B 테스트로 직접 실험
Threshold 조정 중인 기철이1. 여러 기준값을 나눠서 테스트해 본다
예: 0.6 / 0.7 / 0.8 / 0.9
2. 각 그룹에 동일한 액션을 실행해 본다
예: 할인 쿠폰 노출, 추천 메시지 발송 등
3. 전환율, 클릭률, 실제 결제율 등 실질 KPI를 비교한다
4. 가장 성과가 좋은 threshold 구간을 선택
→ 이 방식은 실제 유저 반응을 기반으로 최적점을 찾기 때문에 제품이나 마케팅 쪽 실험에서 기획자가 주도하기에 적합하다.
(2) Precision / Recall Curve로 분석
이건 모델 자체의 성능 관점에서 threshold를 조정하는 방식이다. 즉, “정확히 예측했느냐”를 수학적으로 따져보는 것이다.
핵심 개념 두 가지
1. Precision (정밀도): 모델이 긍정이라고 예측한 것 중 진짜 긍정인 비율
→ “타깃이라더니 진짜 타깃이었나?”
2. Recall (재현율): 실제 긍정 중에서 모델이 얼마나 잘 찾아냈는가
→ “타깃 중에 얼마나 놓치지 않고 찾아냈나?”
Threshold에 따라 둘은 이렇게 움직인다. Threshold를 조정하면서 Precision을 높이면 Recall은 낮아지고, Recall을 높이면 Precision은 낮아지는 트레이드오프 관계가 생긴다.
Threshold를 낮추면?
Recall ↑, Precision ↓
- 더 많은 유저가 타깃 대상이 됨
- 놓치진 않지만, 헛발질이 많아짐 (정확도 ▽)
Threshold를 높이면?
Precision ↑, Recall ↓
- 아주 확실한 유저만 타깃으로 정함
- 정확하지만, 놓치는 경우가 많아짐 (범위 ▽)
4. 그럼 어떤 상황에 각각 Precision/Recall을 우선해야 할까?
그래서 어떻게 활용하나? 모델의 목적에 따라 균형을 다르게 가져가야 한다.
기획자는 서비스 목적에 따라 우선순위를 선택해야 하는 것이다.
Precision을 우선하는 경우
- 예측이 틀리면 손해가 발생하는 경우
- 헛발질을 줄여야 하니까 Precision이 중요
ex) 비싼 리워드를 줄 때, “확실히 결제할 사람에게만" 리워드를 줘야 하기 때문에, Threshold를 높임
→ 적은 수에게 정확하게 준다
Recall을 우선하는 경우
- 놓치는 게 더 위험한 경우
- 다 잡는 게 더 중요하니까 Recall이 중요
ex) 구독 해지할 유저들을 일단 다 잡아야 할 때, Threshold를 낮춤
→ 헛발질이 있더라도 전체 커버를 우선
(참고) F1 Score란?
F1 Score는 Precision과 Recall의 조화 평균이다. 둘 다 중요할 때, 적절한 균형을 갖춘 모델을 찾기 위해 사용된다.
- Precision이 너무 낮거나, Recall이 너무 낮으면 → F1도 낮아짐
- 둘 다 중간 이상이면 → F1이 안정적
예)
Precision: 0.8, Recall: 0.2 → F1 Score: 낮음
Precision: 0.6, Recall: 0.6 → F1 Score: 높음
F1은 ‘균형이 잘 맞는 모델인가?’를 보는 지표라고 이해하면 된다.
5. 예시로 이해해 보기 – Threshold 튜닝
상황: 완결 웹툰을 전체 구매할 유저를 찾는 예측 모델을 만들고, “결제 확률이 0.7 이상인 유저에게만 할인쿠폰 배너를 노출”하고 있다.
(1) PR Curve 확인
모델이 출력하는 결제 확률에 따라 Precision과 Recall이 어떻게 바뀌는지 그래프를 그려봄
임의로 만들어본 PR Curve(2) 기획자가 해석한 상황
0.9일 때는 거의 다 맞지만, 너무 적게 타겟됨 → 쿠폰 발행 수 너무 적음
0.5일 때는 많이 타겟되지만, 정확도가 떨어짐 → 헛발질 많아 쿠폰 낭비
0.7 구간이 Precision/Recall 균형이 괜찮음. 하지만 타깃 수가 너무 적어서 실적이 미미함
(3) 결정
“전환은 조금 낮아져도 괜찮으니, 더 넓게 타겟팅하자”
→ Threshold를 0.6으로 낮추기로 결정
이후 A/B 테스트로 2개 그룹의 실제 결제율, ARPU, 할인 사용률 비교
0.6 기준 그룹 (타깃 많고 전환 중간) vs. 0.7 기준 그룹 (타깃 적고 전환 높음)
이 사례에서 기획자의 판단
"이번 프로모션은 단기 매출 상승보다 유저 풀 확장이 목표다" → Recall 우선
"리워드 쿠폰 예산이 작고, 손해 날 수 있다" → Precision 우선
"균형점에서 시작하고, 실험 결과 보고 정하자" → 0.65 정도부터 실험 설계
이런 흐름을 한 번 겪으면, 모델을 분석하고 적용하는 역할에서 기획자가 주도적으로 일할 수 있지 않을까?
기획자의 시선
☞ 정확도만 보면 착각할 수도 있다. Precision vs Recall도 고려해야 한다.
- Threshold의 기준이 너무 엄격하면 기회를 잃고, 느슨하면 자원을 낭비한다.
- 놓치지 않는 게 중요한 경우(Recall), 헛발질을 줄이는 게 중요한 경우(Precision)
☞ 모델이 좋은지 아닌지는 수치보다 '문제에 적합한가?'로 판단해야 한다.
- 이 모델이 잘 맞추는 것보다 뭘 놓치면 더 치명적인가?
- 지금의 평가 기준은 실제 서비스 KPI와 연결되는가?
- 이 지표가 높다고 해서, 정말 유의미한 결과인가?
