AI 기능에서 '완료(Done)'가 의미하는 것 (기록하십시오)

AI 기능의 경우, "완료(done)"란 데모에서 한 번 좋은 답변을 생성했다는 뜻이 아니라, 합의된 성공률(success rate)에 따라 실제 입력값에 대한 작성된 수용 테스트(acceptance tests)를 통과했음을 의미합니다. 만약 지표(metric)와 임계값(threshold)을 명시할 수 없다면, 그 기능은 정의되지 않은 것이며, 사전에 합의하는 대신 최종 승인(sign-off) 단계에서 논쟁을 벌이게 될 것입니다.

이것은 제가 모든 AI 프로젝트를 시작할 때 나누는 대화입니다. 왜냐하면 이 대화가 프로젝트 종료 시점에 발생할 수 있는 최악의 대화를 방지해주기 때문입니다. 제가 이 과정을 어떻게 진행하는지 소개합니다.

전통적인 "완료" 개념은 AI에서 깨집니다

일반적인 소프트웨어는 입력 X가 출력 Y를 반환한다는 명확한 계약(contract)을 가집니다. 테스트를 작성하면 통과하거나 실패하며, 모두가 그 상태에 동의합니다. 하지만 생성형 AI (Generative AI)는 이를 깨뜨립니다. 동일한 입력이라도 실행할 때마다 다른 출력을 반환할 수 있습니다. 따라서 "내가 해봤을 때는 잘 작동했다"는 것은 더 이상 기능이 완료되었다는 증거가 될 수 없습니다. 그것은 단지 그 입력에 대해, 그 시점에 작동할 수 있다는 증거일 뿐입니다.

제가 "데모를 통과했다"를 완료의 정의로 받아들이지 않는 이유가 바로 이것입니다. 데모는 확률적 시스템 (probabilistic system)에서 추출한 단 하나의 샘플일 뿐입니다. 저는 기능이 실제 입력 분포 (input distribution) 전체에서 어떻게 작동하는지 알아야 하며, 이를 구축하기 전에 미리 합의해야 합니다. 수용 기준 (acceptance criteria)은 고객과 팀이 "완료"가 실제로 무엇을 의미하는지에 대해 합의하는 방식이기 때문입니다.

완료를 느낌이 아닌 측정 가능한 목표로 정의하십시오

AI 기능의 경우, 저는 테스트 세트와 연결된 숫자로 수용 기준을 작성합니다:

작업 완료율 (Task completion rate): 고정된 현실적 케이스 세트에 대한 비율. "에이전트(agent)가 골든 테스트 케이스 (golden test cases) 중 최소 N%에서 요청을 올바르게 해결한다."
도구/인자 정확도 (Tool/argument correctness): 행동을 취하는 에이전트의 경우. 단순히 멋진 텍스트를 생성하는 것을 넘어, 올바른 입력값으로 올바른 함수를 호출했는가?
근거성 (Groundedness): 검색 기반 (retrieval-based)의 모든 사항에 대해. 답변이 소스(source)에 의해 뒷받침되는가, 아니면 자신만만한 허구(fabrication)인가?
거절 품질 (Refusal quality): 답변해서는 안 될 때, 추측하는 대신 깔끔하게 거절하는가?
지연 시간 (Latency) 및 비용 (cost): 요청당 비용. 9초가 걸리거나 토큰 (tokens) 비용이 엄청나게 발생하는 정답은 여전히 실제 요구 사항을 충족하지 못할 수 있기 때문입니다.

정확한 지표는 기능에 따라 다릅니다. 원칙은 그렇지 않습니다. 모든 기준은 명시된 테스트 세트를 기준으로 한 수치이며, 클라이언트가 승인한 임계값(threshold)이 있습니다.

평가 시스템(eval harness)은 오버헤드가 아닌 결과물입니다

팀들이 건너뛰었다가 후회하는 부분이 바로 여기입니다. 반복 가능한 방식으로 기능을 골든 케이스(golden cases)에 대입하여 출력을 채점할 수 있는 평가 시스템 없이는 그 어떤 것도 측정할 수 없습니다. 그래서 저는 이것을 자체적인 작업 시간이 필요한 실제 결과물로 간주합니다. 몇 가지 핵심 작업을 선정하고, 성공의 기준을 정의하며, 골든 예시를 구축하고, 가장 복잡한 것보다 간단한 결정론적(deterministic) 확인부터 시작하여 채점하는 것입니다.

제가 사용하는 실질적인 순서는 다음과 같습니다:

1~2주차: 핵심 작업과 각 작업에 성공이 의미하는 바에 대해 합의합니다. 실제 예시들을 모아 골든 세트를 만듭니다.
3~4주차: 평가 시스템을 구축하고, 기본적인 지표(성공률, 단계 수, 지연 시간, 비용)를 추가하며, 기준선(baseline)을 설정합니다.
이후부터는: 모든 변경 사항이 이 평가 시스템을 거치게 되므로, '이 개선 사항이 다른 것을 망가뜨렸나?'라는 질문은 의견이 아니라 숫자가 됩니다.

이는 프로토타입을 만들기 전에 생산 요구사항(production requirements)을 정의하는 것과 같은 본능입니다. 저희는 AI 데모가 작동한다는 것이 문제입니다.에서 이 점을 주장했습니다. 평가 세트(eval set)는 '운영 준비 완료(production-ready)'라는 느낌이 아니라 측정 가능한 지표로 만들어 줍니다.

이것이 모두를 보호하는 이유

'완료(done)'가 문서화되고 측정된 목표일 때, 승인 과정은 더 이상 협상이 아닙니다. 클라이언트는 자신이 정확히 무엇을 수용하는지 알고 있습니다. 팀은 자신이 언제 끝났는지 정확히 압니다. 그리고 이해관계자가 '하지만 어제 잘못된 답이 나왔잖아요'라고 말하고 팀이 '저희 기계에서는 작동해요'라고 하는, 최악의 회의에 갇힐 필요가 없습니다. 비결정론적(non-deterministic) 시스템의 경우 두 가지 모두 사실일 수 있습니다. 평가 시스템은 그 대립각을 몇 주 전에 합의한 숫자로 바꿔줍니다.

핵심 요약

"데모에서 잘 작동했다"는 AI의 완료(Done)에 대한 정의가 아닙니다. 확률적 시스템(Probabilistic system)의 샘플 하나는 능력을 증명할 뿐, 완료를 증명하지는 않습니다.
수락 기준(Acceptance criteria)을 고정된 테스트 세트에 대한 지표로 작성하십시오: 완료율(Completion rate), 도구 정확성(Tool correctness), 근거성(Groundedness), 거절 품질(Refusal quality), 지연 시간(Latency), 비용(Cost).
평가 하네스(Eval harness)는 실제 산출물입니다. 사후 고려 사항이 아니라 투입 시간(Hours) 단위로 범위를 지정하십시오.
구축하기 전에 임계값(Thresholds)을 합의하십시오. 그래야 승인(Sign-off)이 논쟁이 아닌 확인 과정이 됩니다.
복잡한 채점기(Graders)를 찾기 전에 단순한 결정론적 체크(Deterministic checks)로 채점을 시작하십시오.

FAQ

매번 다른 답변을 내놓는 것을 어떻게 테스트하나요? 단일 출력물을 테스트하는 것을 멈추고, 고정된 실제 사례 세트에 대한 비율(Rates)을 측정하기 시작해야 합니다. 완료(Done)는 "한 번 좋은 답변을 내놓았다"가 아니라 "골든 세트(Golden set)에서 합의된 임계값을 통과했다"가 됩니다.

골든 세트(Golden set)란 무엇인가요? 알려진 양질의 결과가 포함된, 실제적이고 대표적인 입력값들의 선별된 모음입니다. 기능의 모든 버전을 이 세트에 대해 실행함으로써, 성능이 좋아지고 있는지 나빠지고 있는지를 수치로 확인할 수 있습니다.

평가(Evals) 구축은 비용이 많이 들지 않나요? 초기에 투입되는 시간은 들지만, 승인 과정에서의 분쟁, 회귀(Regressions), 재작업(Rework)을 방지함으로써 훨씬 더 많은 비용을 아껴줍니다. 이는 AI 프로젝트에서 가장 저렴한 보험입니다.

만약 귀하의 팀이 AI 기능을 구축하려 하는데 "완료(Done)"가 여전히 "데모가 좋아 보였다"를 의미한다면, 코드 한 줄을 배포하기 전에 이를 바로잡을 가치가 있습니다. Shanti Infosoft의 팀은 측정 가능한 수락 기준과 이를 뒷받침할 평가 하네스(Eval harness)를 정의하는 데 도움을 줄 수 있습니다.