내 에이전트는 12라고 보고했다. 실제 숫자는 13이었다.

측정 도구를 신뢰하기 전에 왜 직접 확인해야 하는가

ForgeFlow 시리즈의 일부 — M5 Max에서 실행 루프를 로컬로 실행하는 코딩 에이전트를 구축하며, 실제로 무엇이 고장 나는지 기록합니다. 계획은 Claude에서 실행되고, 코드 생성은 Ollama를 통해 로컬 모델에서 실행되며, Docker 샌드박스 내부에서 테스트 주도(test-driven) 방식으로 진행됩니다.

나는 시스템 스스로를 측정하는 부분을 구축하고 있었고, AI 에이전트에게 숫자를 세도록 맡겨도 안전하다고 느껴지는 단계에 도달했습니다. 작업은 일상적이었습니다. 특정 체크가 얼마나 자주 발생했는지 집계하고, 이를 합산하여 숫자를 보고하는 것이었습니다. 에이전트는 실행되었고 12라고 보고했습니다.

나는 그 숫자를 그대로 받아들일 뻔했습니다. 믿을 만한 숫자였고, 자신 있게 생성되었으며, 나는 이런 종류의 장부 정리(bookkeeping)를 수동으로 하는 것에 지쳐 있었습니다. 하지만 무언가 내 마음을 움직여 터미널에서 직접 확인해 보게 만들었습니다. 실제 카운트는 13이었습니다. 집계에 포함되어야 할 항목 하나가 에이전트의 원시 카운트(raw count)에서 조용히 누락되어 있었습니다.

하나의 차이. 12 대 13. 그 자체로는 사소합니다. 하지만 이는 내가 한동안 고민해 온 질문, 즉 '측정의 최종 목격자가 될 수 있는 권한은 누구에게 있는가?' 라는 질문에 맞닿아 있었고, 그 답은 내가 이 시스템에 AI를 허용하는 방식을 바꾸어 놓았습니다. 이것은 그 더 큰 주제에 관한 짧은 연재의 세 번째 포스트입니다. 즉, 내 작업을 검증하기 위해 사용하는 도구들 자체가 틀릴 수 있으며, 대개 겉보기에는 멀쩡해 보이는 방식으로 틀린다는 것입니다.

왜 카운팅을 넘기고 싶었는가

솔직한 이유는 피로감이었습니다. 스스로 측정하는 시스템은 많은 작고 정확한 장부 정리 작업을 생성합니다. 발생 횟수를 세고, 관련 항목을 필터링하고, 나누고, 요약하는 작업 말입니다. 이는 에이전트의 겉으로 보이는 능력보다는 낮고, 나의 인내심보다는 높은 수준의 작업이기에 이를 넘기는 것이 당연하게 느껴졌습니다. 에이전트가 데이터를 읽고, 에이전트가 숫자를 보고하면, 나는 보고서를 읽습니다. 깔끔하죠.

그리고 에이전트 입장에서 공정하게 말하자면, 에이전트가 한 일의 대부분은 맞았습니다. 터무니없는 환각(hallucinating)을 일으킨 것도 아니었습니다. 에이전트는 거의 정확한 숫자를 생성했습니다. 내가 직접 확인하지 않았다면 보이지 않았을 정도로 단 하나가 틀렸을 뿐입니다. 그것이 바로 위험한 종류의 오류입니다. 명백하게 고장 난 것이 아니라, 받아들이기에 충분히 그럴듯한 오류 말입니다.

놓쳐버린 하나

실제 숫자가 12가 아니라 13이라는 것을 제가 어떻게 아느냐 하면, "에이전트가 틀렸다"라고 말하려면 기준이 되는 정답(Ground Truth)이 필요하기 때문입니다. 저는 에이전트에게 요약을 요청한 것이 아닙니다. 동일한 소스 데이터(Source Data)에서 동일한 포함 규칙(Inclusion Rule)을 적용하여, 일치하는 각 레코드를 하나씩 출력하도록 터미널에서 결정론적 패스(Deterministic Pass)를 실행한 뒤, 출력된 레코드들을 직접 세었습니다. 다시 실행해도 똑같이 13이 나왔습니다. 누락된 항목은 동일한 규칙을 충족했습니다. 다만 다른 12개와 달리 불규칙한 형태(Irregular Shape)로 들어와 있었기에, 에이전트의 요약 패스(Summarizing Pass)에서 건너뛰어진 것입니다. 재현 가능한 열거(Reproducible Enumeration)로는 13이었고, 에이전트 요약으로는 12였습니다. 이 차이는 제 의견의 문제가 아니었습니다. 동일한 데이터를 두 가지 방식으로 계산한 것이며, 그중 오직 한 가지 방식만이 동일한 결과로 재실행될 수 있었습니다.

이제 실제로 저를 불안하게 만든 세부 사항입니다. 제가 신경 썼던 최종(Final) 숫자 — 즉, 다운스트림 단계(Downstream Step)를 거쳐 원시 카운트(Raw Count)를 더 거칠고 정규화된 수치(Normalized Figure)로 축소한 후 생성된 요약된 지표(Summarized Metric) — 는 원시 카운트가 12이든 13이든 동일하게 나왔습니다. 이는 1의 차이가 그냥 사라져 버릴 수 있는 종류의 단계(반올림(Rounding), 버킷팅(Bucketing))였습니다. 따라서 만약 제가 헤드라인 지표(Headline Metric)만 확인했다면, 에이전트의 보고가 제 보고와 일치하는 것을 보고 모든 것이 괜찮다고 결론 내렸을 것입니다. 오직 그 밑바탕에 있는 원시(Raw) 카운트만이 불일치했을 뿐입니다.

이 부분이 바로 깊이 고민해 볼 가치가 있는 지점이며, "최종 숫자가 같았는데 무엇이 문제인가?"라는 질문에 대한 답이 있는 곳입니다. 문제는 이 특정 헤드라인 지표가 변했다는 것이 아니었습니다. 변하지 않았습니다. 문제는 원시 측정 계층(Raw Measurement Layer)이 이미 틀렸다는 것이었으며, 정규화된 계층(Normalized Layer)에서의 일치는 그 사실을 숨겼을 것이라는 점입니다. 다른 임계값(Threshold), 다른 집계(Aggregation), 혹은 다음 다운스트림 소비자(Downstream Consumer)는 동일한 오류를 흡수하지 않았을 수도 있습니다. 일단 원시 계층이 틀리면, 그 이후의 모든 사용(감사(Audit), 추세선(Trend Line), 회귀 점검(Regression Check))은 그 오류를 상속받게 됩니다. 여기서의 안전성은 제가 설계한 것이 아니었습니다. 그것은 운이었으며, 운은 일반화될 수 없습니다.

따라서 교훈은 "에이전트가 산술적 실수를 했다"가 아니었습니다. 에이전트는 실수를 하기 마련이며, 이는 예상된 일입니다. 교훈은 _내가 누구를 최종 확인(last check) 단계에 둘 것인가_에 관한 것이었습니다. 나는 에이전트의 자기 보고(self-report)가 측정값에 대한 최종 결론이 되도록 내버려 두려 했으나, 그 자기 보고는 오직 결정론적(deterministic)이고 재실행 가능한(re-runnable) 카운트만이 잡아낼 수 있는 방식으로 틀려 있었습니다.

측정 도구가 자기 자신에 대한 유일한 목격자가 되어서는 안 된다

내가 방어하고자 하는 부분이기 때문에, 이 원칙이 최종적으로 정립된 방식대로 말씀드리겠습니다.

측정 시스템을 구축할 때, 작업을 수행하는 동일한 시스템이 그 결과가 맞는지 _판단(judge)_하게 만들고 싶은 유혹이 생깁니다. 특히 그 시스템이 로그를 읽고, 숫자를 세고, 요약할 수 있는 유능한 모델일 때는 더욱 그렇습니다. 편리하기 때문입니다. 하지만 이는 조용히 역할을 뒤바꿔 놓습니다. 모델의 판단은 보조(assistance) 역할을 해야 합니다. 만약 모델이 당신과 기록된 진실 사이를 가로막는 유일한 존재가 된다면, 모델은 진실의 근원(source of truth)이 되어버린 것입니다. 그리고 확률적(probabilistic)이며 때때로 1의 오차(off-by-one)를 내는 진실의 근원이, 재현 가능하고 감사(auditable) 가능해야 할 유일한 자리에 앉아 있게 되는 것입니다.

해결책은 에이전트 사용을 중단하는 것이 아닙니다. 적어도 내가 신뢰를 구축하는 동안에는, _사람이 결정론적으로 출력을 목격(human deterministically witnesses the output)_하도록 강제하는 것입니다. 즉, 자동화된 측정이 독자적으로 인정되기 전에, 내가 직접 터미널 앞에 앉아 실제 숫자가 나오는 것을 내 눈으로 직접 확인하는 것입니다. 모델은 힘든 작업(heavy lifting)을 수행할 수 있습니다. 다만, 그 힘든 작업이 정확했는지에 대한 유일한 목격자가 될 수는 아직 안 됩니다. 왜냐하면 측정값을 검증하는 과정은, 결정론적인 무언가가 그렇지 않다고 말하기 전까지는 "거의 맞음"과 "맞음"을 구분할 수 없는 영역이기 때문입니다.

이 내용을 글로 적는 것이 조금 불편한 이유는, 에이전트가 숫자를 세고, 에이전트가 확인하며, 나는 요약본을 읽는 편리한 워크플로우가 숫자가 중요할 때만큼은 내가 특별히 가질 수 없는 방식임을 의미하기 때문입니다.

내가 변경한 사항

두 가지 조정 사항이 있습니다.

자동화가 신뢰받기 전에는 인간 목격자가 필요합니다. 어떤 자기 측정 (self-measurement)이든 방치된 상태로 실행되게 두기 전에, 저는 적어도 한 번은 제 눈앞에서 결정론적 (deterministic) 버전을 실행합니다. 즉, 실제 데이터로부터 생성되는 과정을 직접 지켜보고, 동일한 결과로 재실행 가능한 실제 수치를 확인하는 것입니다. 만약 자동화된 경로와 관찰된 경로가 일치하지 않는다면, 다른 증거가 나타날 때까지 자동화된 경로가 틀린 것으로 간주합니다. 이 비교 과정에서 에이전트의 확신 (confidence)은 아무런 무게를 갖지 못합니다.

측정 대상을 제가 실제로 목격할 수 있는 단위로 고정하십시오. 이번 실수가 거의 그냥 지나칠 뻔했던 이유 중 하나는 에이전트가 집계한 것과 실제로 범위 (scope) 내에 있는 것 사이의 불일치 때문이었습니다. 그래서 저는 에이전트가 해석하게 두는 느슨한 모집단 (population) 대신, 실제로 계측되고 관찰 가능한 단위, 즉 인간이 직접 관찰하고 열거할 수 있는 단위만을 세도록 측정을 좁혔습니다. 모집단이 명확하게 정의될 때, 사람이 직접 확인한 숫자와 기계의 숫자를 실제로 비교할 수 있습니다. 모집단이 느슨하면 두 숫자는 어긋나게 되고, 심지어 그 차이조차 알 수 없게 됩니다.

이 두 가지 방식 모두 작업 속도를 늦춥니다. 하지만 이것은 제가 신뢰하고자 하는 측정치를 위해 의도적으로 지불하는 비용입니다.

이것이 증명하지 못한 것

이 내용을 적절한 비중에 맞춰 전달하고 싶습니다.

이것은 단 한 번의 카운팅 작업에서 발생한, 단 한 번 포착된 '1 차이 (off-by-one)' 오류일 뿐입니다. 이것이 AI 에이전트가 숫자를 셀 수 없다거나, 일반적으로 신뢰할 수 없다거나, 혹은 에이전트가 생성하는 모든 숫자를 일일이 수동으로 검증해야 한다는 것을 증명하지는 않습니다. 이해관계가 낮은 많은 집계 작업에서 에이전트의 숫자는 충분히 괜찮을 수 있으며, 수동으로 다시 세는 것은 훌륭한 도구를 낭비하는 일이 될 것입니다. 저는 편집증을 주장하는 것이 아닙니다.

제가 지지하는 주장은 좁고 조건부적입니다. 추가적인 결론을 도출하기 위해 활용하려는 측정값의 경우, 최종적인 확인은 결정론적이어야 하며, 적어도 초기에는 인간이어야 합니다. 이해관계 (stakes)가 기준을 설정합니다. 일회성 내부 집계에는 이것이 필요하지 않습니다. 하지만 시스템의 자기 평가 (self-assessment)에 의존하게 될 숫자에는 이것이 필요합니다. 왜냐하면 그 숫자의 오류는 복리로 쌓이기 때문입니다.

또한 명백한 긴장 상태를 지적하고 싶습니다. 이것을 수동으로 영원히 확장할 수는 없습니다. 측정을 자동화하는 목적 자체가 앉아서 무언가를 세지 않기 위함이었기 때문입니다. 따라서 "사람이 이를 목격한다"는 것은 하나의 단계이지, 영구적인 상태가 아닙니다. 이는 자동화가 스스로 작동하기 전에 신뢰를 구축하는 방법이지, 매일 수동으로 현실을 다시 계산하겠다는 서약이 아닙니다. 현재로서는 결정론적 경로 (deterministic path)와 자동화된 경로가 반복된 실행을 통해 일치하고, 포함 규칙 (inclusion rule)이 두 경로 모두 동일한 모집단을 세울 수 있을 만큼 충분히 단단하게 고정되었을 때에만 인간의 목격 단계를 완화하기 시작합니다. 그 이후에 정확히 어느 시점에서 졸업할지는 여전히 고민 중인 부분이며, 아직 명확한 규칙을 가지고 있지는 않습니다.

솔직하게 밝히는 핵심 요약 (The takeaway)

AI가 코드를 작성하게 할 수 있습니다. AI가 분석을 수행하게 할 수도 있습니다. 하지만 만약 "답을 생성한 바로 그 시스템"이 그 답이 맞는지 여부를 판단하는 최종 심판자가 되게 한다면, 당신은 수험생을 채점자로 만든 것이며, 그 점수는 그 자체만으로는 신뢰하기 어려워집니다. 중요한 숫자들에 대해서는, 결정론적인 무언가 — 그리고 신뢰가 쌓이는 동안에는 인간적인 무언가 — 가 마지막으로 확인하는 주체가 되어야 합니다.

에이전트는 거의 모든 것에 대해 맞았지만, 하나가 틀렸습니다. 관건은 그 '하나'의 오류를 당신이 찾아낼 수 있느냐 하는 것이며, 그것은 전적으로 제가 직접 확인할 의지가 있었는지에 달려 있었습니다.

다른 사람들은 이 선을 어떻게 긋나요? AI 에이전트가 무언가를 측정하거나 집계하게 할 때, 독립적으로 검증하나요? 그리고 어떤 숫자가 수동 확인 (hand-check)을 받을 자격이 있고, 어떤 숫자가 확인 없이 통과될 수 있는지 어떻게 결정하나요? 이번에는 제가 직접 하는 것에 의존했지만, 이것이 확장 가능하지 않다는 것을 알고 있습니다. 더 앞서 나간 분들이 신뢰의 인계 (trust handoff)를 어떻게 처리하는지 듣고 싶습니다.

시리즈의 다음 내용 — 이번 회차의 마지막: 우리는 얼마 전부터 더 나은 모델을 쫓는 것을 멈췄습니다. 이것은 우리 자신의 측정치조차 신뢰하기를 멈춘 순간, 그리고 그 대신 우리가 무엇을 유지했는지에 관한 이야기입니다.