하루에 1,000개의 결정을 내리는 AI 시스템을 구축했습니다. 제가 선을 그은 지점은 여기입니다.

CostGuard의 프록시 엔드포인트(proxy endpoint)는 이를 통과하는 모든 LLM 호출에 대해 자율적인 결정을 내립니다. 응답의 점수를 매기고, 이를 임계값(threshold)과 비교하여, 인간의 개입 없이 약 1밀리초(ms) 내에 수락하거나 거부합니다.

처음에는 그것이 올바른 설계처럼 느껴졌습니다. 빠르고, 자동화되었으며, 확장 가능했습니다. LLM 신뢰성 계층(reliability layer)이 마땅히 해야 할 일이었습니다.

그러다 시스템이 실제로 무엇을 잡아내고 있는지, 그리고 더 중요하게는 무엇을 놓치고 있는지를 살펴보게 되었고, 자동화가 어디서 끝나고 인간의 판단이 어디서부터 시작되어야 하는지를 재고해야만 했습니다.

이것은 프로덕션(production) LLM 파이프라인의 핫 패스(hot path)에 위치한 시스템을 구축하며 제가 배운 점이며, 왜 제가 이제 인간 참여형(human-in-the-loop) 설계가 단순한 윤리적 결정이 아닌 엔지니어링 결정이라고 생각하는지에 대한 이유입니다.

CostGuard가 실제로 하는 일

CostGuard는 LLM 호출을 감싸는 HTTP 프록시(proxy)입니다. 에이전트의 요청을 제공자(provider)에게 직접 보내는 대신 이를 통해 라우팅합니다. 모든 호출 시 다음과 같은 작업을 수행합니다:

1. 제공자의 서킷 브레이커(circuit breaker) 상태 확인
2. 30초 타임아웃(timeout)을 설정하여 LLM 호출 수행
3. 휴리스틱 유효성 점수 측정기(heuristic validity scorer)로 응답 점수 산출 (~1ms)
4. 점수가 임계값 미만인 경우 응답을 거부하고 다음 모델로 폴백(fallback) 수행
5. 비용, 지연 시간(latency), 유효성 점수, 그리고 폴백 사용 여부를 로그(log)로 기록

이러한 결정 하나하나가 자동화되어 있습니다. 인간은 개입하지 않습니다. 프로덕션 규모에서는 그것이 올바른 판단입니다. 실시간 파이프라인에서 모든 LLM 응답을 인간이 검토할 수는 없기 때문입니다.

하지만 자동화의 품질은 점수 측정기가 실제로 무엇을 감지할 수 있느냐에 달려 있습니다.

제 자신의 README에 기록한 결함

CostGuard의 /proxy 엔드포인트에 있는 휴리스틱 점수 측정기는 통계적 지표인 신뢰 구간(confidence intervals), p-값(p-values), 불확실성 언어(uncertainty language)에는 보상을 주고, 빈 출력(empty outputs), 에러 트레이스백(error tracebacks), 거부 문구(refusal phrases)와 같은 실패 신호에는 벌점을 주는 방식으로 작동합니다.

이 방식은 명백한 실패를 안정적으로 잡아냅니다. 빈 문자열(empty string), 에러 메시지(error message), 또는 '그것은 도와드릴 수 없습니다(I cannot help with that)'를 반환하는 모델은 매번 걸러집니다.

잡아낼 수 없는 것: 유창하고 자신감 넘치며, 통계적으로 타당하지 않은 분석을 생성하는 모델입니다.

잘못된 방법론으로 그럴듯하게 들리는 신뢰 구간(confidence intervals)을 생성하는 모델은 어떤 임계값(threshold)에서도 휴리스틱 필터(heuristic filter)를 통과할 것입니다. CostGuard README, 알려진 한계점(Known Limitations)

저는 제품을 출시하기 전에 이 내용을 문서에 작성했습니다. 향후 개선 사항이 아니라, 시스템이 어떻게 사용되어야 하는지를 결정짓는 엄격한 제약 조건(hard constraint)으로서 말입니다.

왜냐하면 벤치마크 데이터가 보여주는 결과가 이렇기 때문입니다. RealDataAgentBench의 1,412회 실행 전반에 걸쳐, 가장 흔한 실패 패턴은 모델이 거부하거나 에러를 생성하는 것이 아니었습니다. 그것은 모델이 내부적으로는 망가진 추론(reasoning)을 가지고 있으면서도, 겉보기에는 올바른 출력을 생성하는 것이었습니다.

모델이 올바른 특성 중요도(feature importances)를 계산합니다. 그것들을 정확하게 순위 매깁니다. 그러고 나서 멈춥니다. 신뢰 구간(confidence intervals)도 없고, 폴드(folds) 간의 안정성 검사(stability check)도 없으며, 과적합(overfitting) 위험에 대한 인정도 없습니다.

정확도 점수(Correctness score): 1.0. 통계적 타당성 점수(Statistical validity score): 0.25.

CostGuard의 핫 패스(hot path)에 있는 휴리스틱 스코어러(heuristic scorer)는 이를 구분할 수 없습니다. 그리고 이것은 더 나은 정규 표현식(regex)으로 고칠 수 있는 버그가 아닙니다. 이는 전체 평가(full evaluation)를 실행하지 않고 1밀리초(millisecond) 내에 확인할 수 있는 것에 대한 근본적인 한계입니다.

실제로 작동하는 2계층 설계 (The Two-Layer Design That Actually Works)

해결책은 자동화된 스코어러(automated scorer)를 더 똑똑하게 만드는 것이 아니었습니다. 두 가지 서로 다른 문제에는 두 가지 서로 다른 도구가 필요하다는 점을 받아들이고, 어떤 도구가 무엇을 처리하는지 명시하는 것이었습니다.

/proxy 레이어는 모든 호출에서 실행됩니다. 이 레이어는 자율적(autonomous)이어야 합니다. 왜냐하면 모든 요청마다 실시간 파이프라인을 3분 동안 차단할 수는 없기 때문입니다.

/evaluate 레이어는 인간의 판단(human judgment)이 다시 개입되는 곳입니다. 데이터셋을 업로드하고 전체 벤치마크(benchmark)를 실행하면, 모델 선택이나 라우팅(routing) 결정을 내리기 전에 사람이 결과를 검토합니다.

그것이 제가 그은 선입니다. 낮은 위험도의 실시간 필터링은 자율적으로, 높은 위험도의 모델 결정은 인간의 검토를 거치도록 했습니다.

그 외 모든 것에 적용하는 나의 규칙

CostGuard를 구축하면서 저는 제가 설계하는 모든 AI 시스템에 적용할 수 있는 더 깔끔하고 일반적인 규칙을 갖게 되었습니다.

틀렸을 때의 비용이 낮고 되돌릴 수 있다면 자동화(Automate)하라. 틀렸을 때의 비용이 높거나 되돌릴 수 없다면 인간의 검토(human review)를 요구하라.

CostGuard의 경우: 실제로 괜찮았던 응답을 거절하는 것? 비용이 낮습니다. 폴백(fallback) 모델이 이를 처리하며, 사용자는 약간 느린 응답을 받게 될 뿐입니다. 유창하지만 틀린 응답을 놓치는 것? 잠재적으로 높은 비용이 발생할 수 있습니다. 이는 해당 출력을 다운스트림 에이전트(downstream agent)가 어떻게 처리하느냐에 전적으로 달려 있습니다.

이러한 비대칭성 때문에 /proxy 임계값(threshold)은 품질 게이트(quality gate)가 아닌 보수적인 사전 필터(pre-filter)로 명시적으로 문서화되었습니다. 단어 선택이 중요합니다. '품질 게이트'는 품질 실패를 잡아낸다는 의미를 내포합니다. 반면 '사전 필터'는 명백한 실패를 잡아낸다는 의미를 내포합니다. 이 둘은 서로 다른 주장입니다.

위험 수준에 따른 적용 모습

동일한 원칙이 제가 목격한 모든 AI 시스템 배포 사례에 적용됩니다. 모델, 프롬프트(prompts), 점수(scores), 임계값(thresholds) 등 모든 레이어에서 기술은 유사해 보입니다. 변하는 것은 틀렸을 때 발생하는 비용입니다.

제가 가장 자주 보는 실수: 팀들이 데모가 잘 작동했다는 이유로 '낮은 위험' 패턴을 중간 또는 높은 위험의 결정에 적용하는 것입니다. 데모는 항상 작동합니다. 데모는 깨끗한 데이터, 예상된 입력, 그리고 신중하게 선택된 예시들을 사용하기 때문입니다. 운영 환경(Production)은 그렇지 않습니다.

진정한 Human-in-the-Loop 시스템에 필요한 세 가지

AI 워크플로우 끝에 '검토(review)' 버튼을 추가하는 것은 Human-in-the-loop 디자인이 아닙니다. 그것은 Human-in-the-loop 연극(theater)에 불과합니다. 실제로 작동하는 시스템에는 세 가지가 필요합니다.

1. 단순한 신뢰도 임계값(confidence thresholds)이 아닌 명시적인 에스컬레이션(escalation) 규칙

신뢰도 점수(Confidence scores)는 모델이 얼마나 확신하는지를 알려줍니다. 하지만 그 결정이 얼마나 중요한지는 알려주지 않습니다. 저는 두 가지 독립적인 신호, 즉 모델의 신뢰도(model confidence)와 작업 위험 카테고리(task risk category)를 기반으로 인간의 검토로 에스컬레이션합니다. 위험도가 높은 작업에서 높은 신뢰도를 가진 출력물은 여전히 검토 단계로 넘어갑니다. 반면, 위험도가 낮은 작업에서 불확실한 출력물은 인간의 검토가 아닌 폴백(fallback)으로 넘어갑니다.

2. 무엇(what)뿐만 아니라 왜(why)를 포착하는 감사 로그(Audit logs)

CostGuard는 유효성 점수(validity score), 사용된 모델, 폴백 체인(fallback chain), 그리고 응답이 수락되었는지 또는 거부되었는지를 매 호출마다 기록합니다. 이것 없이는 실패를 디버깅하거나 실패로부터 배울 수 없습니다. RDAB에서는 이를 더 발전시켜 SCORING_SPEC.md를 통해 모든 공식과 임계값을 문서화함으로써, 소스 코드를 읽지 않고도 어떤 점수든 재현할 수 있도록 합니다. 감사 추적(audit trail)은 시스템의 신뢰성입니다.

3. 완결되는 피드백 루프(feedback loop)

인간의 수정 사항은 시스템을 개선해야 합니다. 만약 검토자들이 동일한 모델 오류를 반복적으로 무시(override)하고 있다면, 그 패턴은 프롬프트 업데이트, 임계값 조정, 또는 평가 데이터셋 확장으로 피드백되어야 합니다. CostGuard에서 /replay 엔드포인트가 존재하는 이유가 바로 이것입니다. Tether를 통해 운영 환경의 트레이스(traces)를 캡처하고, 이를 다른 모델로 재실행(replay)하며, 품질 차이(quality delta)를 사용하여 다음번에 더 나은 라우팅(routing) 결정을 내릴 수 있습니다. 인간의 판단은 단순히 현재의 실수를 바로잡는 것에 그치지 않습니다. 시스템이 실수를 덜 하도록 훈련시킵니다.

모델이 발전할수록 이것이 더 중요해지는 이유

여기에는 직관에 반하는 함의가 있습니다. 프론티어 모델(frontier models)이 발전할수록, 이해관계가 큰(high-stakes) 영역에서 Human-in-the-loop의 필요성은 약해지는 것이 아니라 오히려 더 강력해집니다.

그 이유는 다음과 같습니다. 1,412회의 벤치마크 실행(benchmark runs) 결과, 12개의 프런티어 모델(frontier models) 전반에 걸친 정확도 점수(correctness scores)는 0.84에서 0.99 사이였습니다. 매우 조밀한 군집(Tight cluster)을 형성하고 있습니다. 대부분의 모델이 정확도 측면에서는 유사해 보입니다.

통계적 타당성(Statistical validity)은 0.52에서 0.85 사이였습니다. 훨씬 더 넓게 퍼져 있으며, 바로 이 지점에 실제 실패 모드(failure modes)가 존재합니다.

정확도가 1.0에 가까워질수록, 남은 실패들은 감지하기가 더 어려워집니다. 모델은 더 자신감 있게 들리고, 출력물은 더 세련되어 보입니다. 오류는 더욱 미묘해집니다. 잘못된 방법론을 유창하게 진술하거나, 유효한 상관관계 속에 인과적 주장(causal claim)을 숨기거나, 잘못된 데이터에 대해 올바른 공식으로 계산된 신뢰 구간(confidence interval)을 제시하는 식입니다.

2024년 시대의 모델 출력물을 보는 인간 검토자라면 무엇인가 잘못되었다는 것을 종종 알아챌 수 있었습니다. 하지만 2026년 시대의 모델 출력물은 해당 특정 분야의 전문가가 아니라면 올바른 추론과 구별할 수 없을지도 모릅니다.

이것은 더 나은 모델을 사용하지 말라는 주장이 아닙니다. 실패 모드를 자동으로 잡아내기가 점점 더 어려워지기 때문에, 바로 그 점 때문에 중요한 결정에는 인간 도메인 전문가(human domain experts)를 루프(loop) 안에 유지해야 한다는 주장입니다.

자동화하기 전에 던져야 할 가치 있는 질문들

어떤 AI 시스템이 결정에 대해 완전히 자율적으로(fully autonomous) 작동하기 전에, 저는 네 가지 질문을 검토합니다.

1. 모델이 틀렸을 때의 비용은 얼마인가? 그것은 되돌릴 수 있는가?

2. 나의 평가 시스템(evaluation system)이 실제로 중요한 실패 모드를 감지할 수 있는가, 아니면 그저 명백한 것들만 감지하는가?

3. 만약 인간이 이 출력물을 검토한다면, 모델이 제공할 수 없는 어떤 판단을 추가하게 되는가?

4. 모델이 실패했을 때, 나의 시스템은 그로부터 배우는가, 아니면 그 실패가 아무도 읽지 않는 로그 속으로 사라져 버리는가?

만약 2번 질문에 대한 답이 '명백한 것들만'이고, 1번 질문에 대한 답이 '높고 되돌릴 수 없음'이라면, 모델이 얼마나 뛰어나든 상관없이 그곳은 바로 Human-in-the-loop 설계가 필요한 지점입니다.

진정한 교훈

가장 강력한 AI 시스템이 항상 가장 자율적인 시스템인 것은 아닙니다. 최고의 설계란 자동화가 있어야 할 곳, 즉 반복적이고 위험이 낮으며 되돌릴 수 있는 결정에는 자동화를 배치하고, 인간의 판단이 있어야 할 곳, 즉 틀렸을 때의 비용이 높거나, 실패 모드(failure modes)가 미묘하거나, 혹은 그 영향이 사람들의 실제 삶에 닿는 곳에는 인간의 판단을 유지하는 설계입니다.

CostGuard의 /proxy 필터는 하루에 1,000개의 자율적인 결정을 내립니다. 저는 이것이 무엇을 포착할 수 있고 무엇을 포착할 수 없는지 정확히 알고 있으며, 그 두 가지 모두를 문서화했기 때문에 이 상태에 안심할 수 있습니다. 반면 /evaluate 엔드포인트는 인간의 검토를 필요로 합니다. 왜냐하면 이 엔드포인트가 내리는 결정(어떤 모델을 사용할지, 어떤 임계값(threshold)을 신뢰할지, 어떤 라우팅 로직을 변경할지)이 하류(downstream)의 모든 것에 영향을 미치기 때문입니다.

이것은 제가 기술적으로 제거하려고 노력하는 한계점이 아닙니다. 이것이 바로 설계입니다.

전체 벤치마크, 평가 스택(evaluation stack) 및 점수 산정 방법론은 오픈 소스로 공개되어 있습니다: github.com/patibandlavenkatamanideep/RealDataAgentBench

여러분의 프로덕션 파이프라인(production pipeline) 중 어디에서 자동화와 인간의 판단 사이에 선을 그었으며, 그 선을 어디에 그을지 어떻게 결정하셨나요?