정확도 83.5%라는 말을 들으면 마음이 놓입니다. 그런데 그 숫자는 Microsoft의 시험 결과이지, 여러분 서비스의 보장이 아닙니다. 더 중요한 건 확률이 99%여도 돈을 보내거나 파일을 지우면 안 된다는 원칙입니다.

이 글은 도입 전에 재야 할 네 가지와, 자동 실행하면 안 되는 일을 정리합니다. 앞의 개요 글과 실전 패턴 글에서 온 분기를 안전하게 닫는 순서입니다.

생성, 판단, 검증, 실행과 사람 승인을 나눈 구조와 도입 전 측정 4가지 개념도

도입 전에 재야 할 네 가지

단순 정확도만 보면 안 됩니다. 같은 라벨 데이터와 같은 요청 조건으로 모델별로 네 가지를 함께 재세요.

재야 할 것 물어볼 질문 왜 중요한가
정확도 + 실패 비용 틀리면 뭘 잃나 맞춘 비율보다 틀렸을 때의 대가가 큼
보정 Calibration 90%가 정말 90% 맞나 임계값을 걸고 자동 처리하려면 필수
p95 지연 느린 꼬리는 어느 정도인가 평균· 중앙값만 보면 운영에서 터짐
정답당 비용 올바른 판단 1건에 뭐가 드나 토큰 단가가 아니라 재시도· 검토 포함 값

하나씩 풀어봅니다.

정확도는 "무엇을 틀렸나"와 함께 봐야 합니다. 전체 90%여도 결제 관련에서만 틀리면 도입이 안 됩니다. 작업별로 쪼개서 보세요. 공정 비교 글에서 본 것처럼 한 모델이 전 유형에서 이기지는 않습니다.

보정은 확신도를 믿어도 되는지 보는 지표입니다. 0.9라고 말한 것들이 실제로 90%쯤 맞아야 임계값을 걸 수 있습니다. Microsoft의 보정 점수 92.2, Quyet의 93.1 같은 숫자는 참고만 하고, 여러분 데이터로 기대보정오차(ECE)까지 확인하세요. sysone-bench에서도 선택· 예/아니오보다 점수형 질문의 보정이 더 흔들린다는 보고가 있습니다.

지연은 p50이 아니라 p95와 분포로 봐야 합니다. Decision-1의 p50 85ms, p95 125ms 같은 숫자도 자기 트래픽에서는 달라집니다. 네트워크와 오케스트레이션을 포함한 종단간 지연을 재고, 20단계가 이어지면 단계당 지연이 어떻게 쌓이는지 보세요. 속도 글에서 본 것처럼 체감은 꼬리에서 갈립니다.

비용은 성공 1건당 비용 글의 관점 그대로입니다. 입력 토큰에 재시도와 상위 모델 확인, 사람 검토까지 더한 값으로 비교하세요. 100만 토큰당 $0.042는 시작점일 뿐입니다.

실험 틀 (100개로 시작):
  같은 입력 100개 + 정답 라벨
  → 기존 방법 vs Decision AI, 동일 조건
  → 작업별 정확도 + 보정 + p50· p95 + 정답당 비용
  → 확신도 분포 보고 임계값 정하기 (낮으면 위로)

99%여도 자동 실행하면 안 되는 일

정확도가 높아도 이 네 가지는 별도 승인이 필요합니다.

자동 실행 금지:
  - 돈 보내기 (결제· 환불· 송금)
  - 지우기 (파일· 데이터 삭제)
  - 바꾸기 (권한· 설정 변경)
  - 내보내기 (개인정보 전송)

모델이 HIGH CONFIDENCE라고 말한 건 법적 승인이나 정책 검증과 다릅니다. 환불 요청일 확률 99%는 환불 자격이 있다는 뜻이 아닙니다. 결제 기록과 정책, 승인 규칙은 코드가 봐야 합니다. 실전 예제의 게이트가 0.99에서도 결제를 사람에게 넘긴 이유입니다.

Microsoft 카탈로그에도 경계가 있습니다. 신용· 고용· 주거· 보험· 교육· 의료· 법적 권리 같은 중대한 결정의 유일한 자동 판단자로 쓰지 말고, 감시· 프로파일링· 개인 추적에는 쓰지 말라는 제한입니다. 확률 점수를 사람에 대한 판단처럼 쓰면 안 된다는 뜻입니다. Decision AI는 안전한 워크플로 안에 들어가야 합니다.

원칙:
  모델 = 의미를 읽고 확률을 준다
  코드 = 정책· 자격· 위험 조건을 강제한다
  사람 = 위험한 일의 최종 승인자다

이 분업이 중요한 이유는 책임이 선명해지기 때문입니다. Jev 글에서도 본 구조 그대로입니다.

아키텍처로 닫기: Generate → Decide → Verify → Act

오늘 브리핑의 결론을 구조로 그리면 이렇습니다.

Generate (LLM): 긴 글· 분석· 코드 초안
  → Decide (Decision AI): 선택· 점수· 예/아니오
    → Verify (코드): 정책· 자격· 임계값· 위험 플래그 확인
      → Act: 실행 / 재시도 / 사람 검토

좋은 AI 시스템은 모델 하나로 모든 일을 시키는 시스템이 아니라, 일을 알맞게 나눠서 설계한 시스템입니다. 하네스 글에서 본 실행과 검증의 분리와 같은 얘기입니다.

처음부터 크게 나누지 마세요. 기존 에이전트에서 반복 판단 하나를 찾아 100개로 비교하는 것부터 시작하면 됩니다. 일치율 95% 이상에 지연이 크게 줄면 분리를 확정하고, 확신도 분포를 보고 임계값을 정합니다. 그게 오늘 바로 해볼 일 하나입니다.

CodeBridge Mini Lab: 이번 주 검증표

① 판단 1개 고르기 (라우팅· 재시도· 검증· 검토 중 1개)
② 100개 모으기 (실제 예제 + 정답 + 애매한 케이스 포함)
③ 네 가지 재기:
   [ ] 작업별 정확도와 실패 비용 정리
   [ ] 보정 확인 (90% 구간의 실제 정답률)
   [ ] p50· p95 종단간 지연
   [ ] 정답당 비용 (재시도· 상위 확인· 검토 포함)
④ 게이트 정하기:
   [ ] 임계값 (예: 0.85 아래는 상위로)
   [ ] 위험 조건 (결제· 삭제· 권한· 개인정보는 무조건 검토)
   [ ] 버전 고정과 로그 (모델 버전· 입력· 확률 기록)

이 표가 있으면 "도입할까"가 아니라 "어디까지 자동화할까"를 정할 수 있습니다. 그게 Decision AI 도입의 실제 결론입니다.

결론: 나누고, 재고, 사람이 닫는다

한 줄로 정리합니다.

복잡한 생성은 LLM에게, 반복 판단은 Decision AI에게, 실행 여부는 코드와 사람에게.

모델 하나로 다 하려 하지 마세요. 고르는 일을 떼어내고, 내 데이터로 재고, 위험한 일은 사람이 닫는 것. 그 세 단계가 이 브리핑 전체의 요지입니다.

여러분 서비스에서 답이 아니라 선택만 하는 단계를 하나 찾아보세요. 어떤 판단을 자동화하고 싶은지 댓글로 남겨주시면 다음 글에서 더 파봅니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

검증표까지 알았으면 다음은 내 업무에 붙이는 일만 남습니다. 어디서 100개를 모으고, 어떤 기준으로 정답을 정하고, 확신도 몇에서 사람에게 넘길지 정하는 부분이 실무에서 가장 막막합니다.

실무 Decision AI 과정에서는 Laya를 직접 실행하면서 상태와 질문을 만들고, 확신도를 정책과 Human Review로 연결하는 법과 내 업무에 적용하기 전 검증 틀을 함께 잡습니다. 올바른 판단 하나당 비용으로 따져보고 싶은 분이라면, 이 글의 Mini Lab과 그대로 이어집니다.