지난 2주 동안 저는 Dev.to의 AI 에이전트 관련 논의에 깊이 빠져 있었습니다. 품질 게이트(quality gates), 결정론적 라우팅(deterministic routing), 오류 분류법(error taxonomies), 웹훅 디버깅 등 모든 스펙트럼을 살펴보았습니다. 저를 놀라게 한 것은 어떤 단일한 통찰력이 아니었습니다. 완전히 다른 대화 속에서 동일한 세 가지 패턴이 나타나는 것을 목격했다는 점입니다.

AI 에이전트를 구축하고 있거나 (혹은 생각하고 있다면) 이 패턴들이 제가 절약했던 디버깅 시간을 당신에게도 아껴줄 수 있습니다.

패턴 1: 판단을 내리는 모델(Judge)은 작업을 수행하는 모델과 같아서는 안 된다

이것은 zxpmail의 LLM 품질 검사관(quality inspectors)에 대한 훌륭한 시리즈에서 나왔습니다. 설정 자체는 명백해 보입니다. 약한 모델의 출력이 좋은지 확인하기 위해 강력한 모델을 사용하는 것입니다. 문제는 무엇일까요? 강력한 모델이 항목별 판단자(per-item judge)가 되고 — 유창한 판단자는 실제로는 그렇지 않으면서도 객관적으로 들리는 데 능숙하다는 것입니다.

실제로 작동하는 방식은 모델을 판단 과정에서 완전히 제거하는 것입니다.

‘관련성(relevant)’이라는 단어가 모든 무거운 작업을 처리하며, 대부분의 경우 ‘관련성’은 나열할 수 있는 무언가에 매핑됩니다. 나머지 10%—즉, 참조 공간을 실제로 나열할 수 없는 경우—에서 여러분의 샘플링 계층이 제 역할을 합니다.

이는 품질 게이트 논의에서의 C1/C2/C3 프레임워크와 직접적으로 연결됩니다. C3(인수 공간, arg-space)가 5/5점을 받고 C1(정규표현식, regex)과 C2(LLM)가 2/5점을 받은 것은 C3가

공통적인 핵심은 기술 선택이 아닙니다. 그것은 디자인 원칙입니다: 결정론적(deterministic) 영역과 확률론적(probabilistic) 영역 사이의 경계를 명확하게 만드세요. 흐릿해지도록 내버려 두지 마십시오. 그들이 흐릿해지는 것을 포착했을 때 (모델이 자체 작업에 대해 판단하거나, 실제로는 조회(lookup)인 '스마트한' 요구사항, 통과하는 침묵적 실패 등), 그것들을 분리하세요.

과거의 나에게 해주고 싶은 말

2주 전까지만 해도 저는 에이전트의 품질을 모델 문제로 생각했습니다. 더 좋은 모델을 얻으면, 더 좋은 품질을 얻을 것이라고요. 그 관점은 틀렸습니다. 품질은 시스템 문제입니다. 모델은 하나의 구성 요소일 뿐이며, 주변 아키텍처—라우팅(routing), 샘플링(sampling), 활성 상태 확인(liveness checks)—가 시스템이 크게 실패하는지 (수정 가능) 아니면 조용히 실패하는지 (비용이 많이 드는)를 결정합니다.

에이전트 시스템을 구축하고 있다면, 배관 공사(plumbing)에 시간을 쓰십시오. 모델은 더 좋아질 것입니다. 위에 언급된 패턴들은 여전히 적용될 것입니다.

여러분의 에이전트 작업에서 어떤 패턴들을 보고 계신가요? 다른 분들도 같은 수렴 현상에 부딪혔는지 궁금합니다.