.NET 기반의 프로덕션 AI 구축에 관한 시리즈의 두 번째 파트입니다. Part 1에서는 평가(Evals)가 무엇인지, 그리고 분석(Analyze) → 측정(Measure) → 개선(Improve) 라이프사이클에 대해 다루었습니다. 이 포스트는 모두가 건너뛰고 싶어 하는 단계인 **분석(Analyze)**에 관한 것입니다.

팀이 "평가(Evals)를 진지하게 받아들이기로" 결정했을 때, 그들이 보통 가장 먼저 하는 일은 잘못된 방식입니다. 그들은 대시보드 도구를 열고, 일반적인 "정확성(correctness)" 점수를 연결한 뒤, 숫자가 변하는 것을 지켜봅니다. 생산적인 것처럼 느껴집니다. 차트도 만들어집니다. 하지만 그것은 그들에게 거의 아무것도 알려주지 않습니다. 왜냐하면 그들은 _차트가 무엇을 측정해야 하는지_를 결정하는 단계를 건너뛰었기 때문입니다.

그 단계가 바로 **오류 분석 (error analysis)**입니다. 즉, AI의 실제 출력물을 읽고 그것들이 잘못되는 방식을 정확하게 명명하는 것입니다. 이는 매력적이지 않습니다. 라이브러리도 없고, 대시보드도 없으며, 오직 당신과 수십 개의 실제 사례뿐입니다. 하지만 이는 평가(Evals)에서 당신이 할 수 있는 일 중 압도적으로 가장 영향력이 큰 일입니다. 오류 분석은 신호(signal)가 나오는 곳입니다. 그 이후의 모든 과정은 여기서 발견한 것을 운영화(operationalising)하는 것에 불과합니다.

왜 지표(metrics)로 바로 건너뛸 수 없는가

당신과 실행 중인 시스템 사이에는 과소평가하기 쉬운 간극이 존재합니다. 매일 수천 개의 입력값이 당신이 전혀 예상치 못한 형태로 AI 기능에 흘러 들어오지만, 당신은 이를 대규모로 볼 수 있는 현실적인 방법이 없습니다. 이를 **이해의 간극 (comprehension gap)**이라고 부릅시다. 개발자와 데이터 및 모델이 실제로 무엇을 하고 있는지에 대한 진정한 이해 사이의 거리입니다.

지표(Metrics)는 그 간극을 메워주지 않습니다. 오히려 그 간극이 이미 메워져 있다고 가정합니다. "간결함(conciseness)"을 측정하려면, 먼저 장황함(verbosity)이 신경 써야 할 실패 모드(failure mode)라는 점을 _인지_해야 합니다. 데이터를 읽기 전에 지표를 선택한다면, 당신은 제품이 아니라 당신의 가설을 측정하고 있는 것입니다. 전형적인 결과는 이렇습니다. 사용자들이 당신의 지표가 포착하도록 설계되지 않은 문제 때문에 조용히 이탈하고 있는 동안, 대시보드는 초록색으로 빛나고 있습니다.

오류 분석은 그 간극을 건너는 방법입니다. 당신은 규모(scale)를 포기하는 대신 진실(truth)을 얻습니다. 모든 것을 읽을 수는 없으므로, _샘플(sample)_을 주의 깊게 읽는 것입니다.

오류 분석이 실제로 작동하는 방식

이것은 세 단계의 루프이며, 각 단계는 의도적으로 기술적 수준을 낮게(low-tech) 유지합니다.

1. 시작 데이터셋을 확보하고 읽기. 실제(또는 실제와 유사한) 출력물 샘플을 추출하세요. 시작 단계에서는 50~100개 정도면 충분합니다. 모든 것이 잘 풀리는 '해피 패스(happy-path)' 데모 케이스가 아니라, 이상한 입력값을 포함한 실제 분포(real distribution)를 가져와야 합니다. 그런 다음 실제로 그것들을 읽으세요. 천천히 말이죠.

2. 실패 사례를 오픈 코딩(Open-code)하기. 틀린 출력물 각각에 대해, _무엇이 구체적으로 잘못되었는지_를 자신의 언어로 짧은 자유 형식의 메모로 작성하세요. 아직 정해진 카테고리는 없습니다. "문장에서 가진 의미 대신 사전적 정의를 사용하여 단어를 설명함.", "번역은 정확하지만 일상적인 대화에 비해 어조가 너무 격식적임.", "퀴즈의 오답 선택지(distractor)가 너무 명백하게 틀려서 정답을 알려주는 꼴임." 이것이 오픈 코딩(open coding)입니다. 당신은 현실을 박스 안에 강제로 밀어넣는 것이 아니라, 현실에 라벨을 붙이고 있는 것입니다.

3. 메모를 분류 체계(Taxonomy)로 클러스터링하기. 메모가 40~50개 정도 쌓이면 패턴이 나타납니다. 그것들을 그룹화하세요. 그 그룹들이 바로 당신의 **실패 분류 체계(failure taxonomy)**입니다. 이는 _당신의 기능이 어떻게 실패하는지_를 대략적인 빈도와 함께 순위별로 나열한 목록입니다. 이제 무엇을 먼저 수정해야 할지(흔하고 심각한 유형), 그리고 결정적으로, _당신의 지표(metrics)가 무엇을 측정해야 하는지_를 알게 됩니다.

이것이 전부이자 핵심입니다. 분류 체계(taxonomy)가 결과물이며, 이는 그 어떤 단일 점수보다 가치가 있습니다. 왜냐하면 이후의 모든 단계 — 루브릭(rubric), 골든 세트(golden set), 판정자(judge) — 가 모두 이 분류 체계를 기반으로 이루어지기 때문입니다.

마음가짐에 대한 노트: (아직은) 판사가 아닌 탐정이 되세요

오류 분석에서 어려운 점은 기계적인 작업이 아니라 심리적인 부분입니다. 즉시 1~5점 사이의 점수를 매기고 싶거나, "프롬프트에 한 줄을 추가하는 것이 해결책이다"라고 성급히 결론 내리고 싶은 유혹에 빠질 것입니다. 이 두 가지 모두를 거부하세요. 너무 일찍 점수를 매기면 풍부한 정보("왜 그런지"에 대한 내용)가 단순히 숫자로 축소되어 버립니다. 너무 일찍 수정에 뛰어드는 것은 가장 흔한 실패가 아니라, 눈에 보이는 첫 번째 실패를 임시방편으로 때우는 것을 의미합니다.

가능한 한 오랫동안 기술적인(descriptive) 상태를 유지하세요. 이 단계에서 당신의 유일한 임무는 이해하고 분류하는 것입니다. 판단과 수리는 나중에 하면 됩니다.

두 번째 함정은 혼자서 수행하는 것입니다. 두 사람이 동일한 출력값에 레이블(label)을 붙일 때 의견이 일치하지 않을 수 있는데, 이러한 불일치는 매우 가치 있는 정보(gold)입니다. 왜냐하면 '좋음(good)'이 아직 실제로 정의되지 않았음을 드러내기 때문입니다. 불일치를 해결하기 위한 짧은 정렬(alignment) 세션은 평가 기준(rubric)을 확정하기 전에 품질에 대한 정의를 더욱 날카롭게 다듬어 줍니다. (1인 창업자의 경우, 레이블링을 한 뒤 잠을 자고 나서, 다시 냉정한 상태로 재레이블링함으로써 이를 유사하게 구현할 수 있습니다.)

오류 분석이 TextStack의 평가(evals)를 형성한 방식

이것은 우리에게 추상적인 이야기가 아닙니다. TextStack은 7개의 AI 접점(surfaces)을 가지고 있으며, 우리가 점수를 매기는 모든 평가 기준(rubric)은 일반적인 템플릿이 아니라 실패 사례를 직접 읽는 과정에서 도출되었습니다.

Explain(단어를 탭하면 문맥 내 짧은 설명을 제공하는 기능)을 예로 들어보겠습니다. 실제 출력값을 읽어보니 반복되는 실패 패턴이 나타났습니다. 모델이 사용자가 실제로 보고 있는 문장은 무시한 채, 유능한 사전적(dictionary) 정의만을 생성하는 것이었습니다. 이는 해당 구절을 이해하려는 사람에게는 무용지물입니다. 이러한 단 하나의 관찰 덕분에 Explain 평가 기준은 **문맥적 정확성(accuracy in context)**과 **학습자에게 유용성(usefulness to a learner)**을 별개의 축(axes)으로 점수화하며, 간결성(conciseness) 항목 아래에서 사전식 상투어(boilerplate)를 명시적으로 감점합니다. 이 평가 기준은 분류 체계(taxonomy)를 그대로 옮겨 놓은 것입니다.

다른 접점들은 서로 다른 분류 체계를 만들어냈고, 따라서 서로 다른 축을 가집니다.

• Translate(번역)는 어조(register)(정확하지만 격식이 틀린 경우)에서 계속 실패했습니다. 그래서 어조는 정확성(accuracy) 및 유창성(fluency)과 함께 별도의 점수 산정 차원이 되었습니다.
• Vocabulary distractors(퀴즈의 오답)는 _그럴듯하지 않거나(implausible)(너무 명백하게 틀림) 혹은 정답과 _너무 유사하여(too similar) 실패했습니다. 따라서 평가 기준은 그럴듯함(plausibility), 차별성(distinctness), 그리고 난이도(difficulty)를 점수화합니다.

우리는 회의 중에 이러한 차원들을 발명해낸 것이 아닙니다. 차원들이 명확해질 때까지 출력값을 읽었습니다. 그리고 모든 AI 호출은 추적되어 내부 /ai-quality 페이지에서 확인할 수 있기 때문에, 오류 분석은 일회성 작업이 아닙니다. 실제 운영 환경에서의 새로운 실패 사례들이 계속해서 새로운 카테고리를 분류 체계로 피드백해 줍니다.

함정들

• 설명하기 전에 점수 매기기. 숫자는 '이유(why)'를 지워버립니다. 먼저 글로써 오픈 코드(Open-code)를 작성하세요.
• 모호한 카테고리. "나쁜 출력"은 카테고리가 아닙니다. "문장 맥락을 무시함"이 카테고리입니다. 조치를 취할 수 있을 만큼 구체적이어야 합니다.
• 너무 작은 샘플, 혹은 쉬운 사례만 다루기. 성공 사례만 읽는다면 모든 것이 괜찮다는 결론을 내리게 될 것입니다.
• 분석 도중에 수정하기. 실패를 기록하고 다음으로 넘어가세요. 전체 그림을 볼 수 있는 상태가 된 '후'에 분류(Triage)하세요.
• 보정(Calibration) 없는 단독 라벨링. 의견 불일치는 정보입니다. 그것이 잘못된 루브릭(Rubric)으로 굳어지기 전에 표면화하세요.
• 한 번만 수행하기. 입력값은 변합니다(drift). 분류 체계(Taxonomy)는 실제 트래픽으로부터 갱신되는 살아있는 문서입니다.

핵심 요약 (The takeaway)

오류 분석(Error analysis)은 도구도, 대시보드도 없지만 가장 높은 보상을 주는 평가(Evals)의 단계입니다. 그리고 바로 그 점 때문에 종종 건너뛰게 됩니다. 실패 사례를 읽고, 평이한 언어로 이름을 붙이며, 이를 분류 체계(Taxonomy)로 클러스터링(Cluster)하세요. 그 분류 체계가 무엇을 수정해야 하고 무엇을 측정해야 하는지를 알려줍니다. 이를 건너뛴다면, 잘못된 목표를 향해 있는 아름다운 측정 시스템을 만들게 될 뿐입니다.

시리즈의 다음 내용: 거짓말하지 않는 골든 데이터셋(Golden datasets) — 스스로를 속이지 않으면서, 분류 체계를 점수를 매길 수 있는 큐레이션된 사례 집합으로 전환하는 방법.

TextStack은 당신이 계속 중도 포기하게 되는 난해한 기술 서적을 끝까지 읽을 수 있도록 도와주는 리더입니다. 이 서비스는 모든 현대적 AI 프리미티브(AI primitives: 관측 가능성(Observability), 평가(Evals), RAG, 에이전트(Agents))를 .NET 기반의 실제 운영 기능으로 구축합니다. textstack.app에서 체험하거나, github.com/mrviduus/textstack에서 코드를 읽어보세요.