AI가 성공했다고 보고했습니다

그것이 사실인지 아무도 확인하지 않았습니다.

당신의 에이전트(Agent)가 성공했다고 보고했습니다.

그것은 실제로 작업이 수행된 것과는 다릅니다.

저는 이번 주 dev.to에서 가장 높은 참여도를 기록한 세 개의 AI 관련 기사를 읽었고, 그다음 그 아래의 댓글들을 읽었습니다. 진짜 신호(Signal)는 바로 그곳에 있습니다.

그 기사들은 개발자들이 AI를 사용하는 방법, AI 코드 디버깅(Debugging), 그리고 97.3%의 커버리지(Coverage)를 주장하는 테스트 보고서를 다루었습니다.

주제는 달랐습니다. 하지만 다섯 명의 독자가 다섯 가지 방식으로 질문한 근저에는 동일한 의문이 깔려 있었습니다.

AI가 완료했다고 말한 내용을 실제로 검증(Verify)했는가?

아무도 답을 쓰지 않고 있습니다. 그래서 월요일에 오답을 낼 여유가 없는 엔터프라이즈(Enterprise) 팀들을 위해 프로덕션(Production) 환경에서 이를 실행하며 얻은 저의 답변을 공유합니다.

초록색 체크 표시 대 진술의 진실

초록색 체크 표시와 진실된 진술은 서로 다른 것입니다.

"테스트 통과"라고 쓰는 에이전트(Agent)는 자신의 행동을 보고하는 것입니다.

현실을 보고하는 것이 아닙니다.

한 독자는 그 어떤 기사보다 더 명확하게 말했습니다. 97.3%의 커버리지(Coverage)는 테스트 중에 해당 라인들이 실행되었다는 것을 의미합니다. 그것은 무언가가 단언(Asserted)되었다는 것을 의미하지 않습니다. 시스템이 당신이 생각하는 대로 작동한다는 것을 의미하지도 않습니다.

그것이 문제의 핵심을 한 문장으로 요약한 것입니다. 지표(Metric)는 실행을 측정했습니다. 독자는 검증(Verification)을 원했습니다. 이 두 가지는 서로 다른 것이며, 대부분의 팀은 이 교체(Swap)를 결코 알아차리지 못합니다.

왜 엔터프라이즈 팀이 가장 큰 타격을 입는가

검증되지 않은 변경 사항을 배포한 1인 개발자는 다음 날 아침에 이를 느끼고 수정합니다.

엔터프라이즈 팀은 동일한 변경 사항을 수익 대시보드, 지원 워크플로우(Workflow), 규제 프로세스에 배포합니다. 실패는 일주일 후에 나타나며, 그때 운영 책임자는 다른 모든 사람이 기다리는 동안 어제의 배치(Batch) 작업을 수동으로 다시 실행하고 있습니다.

여기서 발생하는 비용은 개발자의 시간으로 나타나지 않습니다. 그것은 비즈니스가 연극(Theatre)으로 밝혀진 숫자에 부여했던 신뢰로 나타납니다.

저는 대규모 DACH(독일어권) 조직의 팀들을 대상으로 정확히 이 과정을 안내해 왔습니다. 기업의 규모는 패턴을 바꾸지 않습니다. 중요한 것은 에이전트(Agent)가 주장한 것과 실제 사실 사이의 루프(Loop)를 누군가가 닫았느냐 하는 것입니다.

이를 잡아내는 하나의 질문

팀이 나에게 "작동하는" 시스템을 가져왔지만 계속해서 그들을 놀라게 할 때, 나는 먼저 한 가지를 묻습니다.

에이전트(Agent)가 완료했다고 보고하는 모든 작업에 대해, 에이전트와 독립적으로 이를 검증한 사람은 누구입니까?

정직한 답변은 거의 항상 "아무도 없다"입니다.

에이전트가 작업을 실행합니다. 그리고 그 결과를 보고합니다. 그 작업이 성공했다는 유일한 목격자는 바로 그 에이전트 자신입니다. 당신은 외부 확인 절차가 없는 폐쇄 루프(Closed loop)를 가지고 있으며, 폐쇄 루프는 항상 성공했다고 말할 것입니다.

이번 주 댓글 스레드 이면에는 이러한 구조가 자리 잡고 있습니다. 실행 과정이 자체적인 추적(Trace)을 보존했는지 묻는 독자들, 자신이 직접 검증한 것과 모델이 주장한 것이 무엇인지 묻는 독자들, 시스템 내부에서 작업이 진행되는 동안 어떻게 자체적인 진실을 유지하는지 묻는 독자들이 있습니다.

그들은 모두 하나의 누락된 조각을 중심으로 돌고 있습니다. 바로 독립적인 검증자(Independent verifier)입니다.

루프를 닫지 못하는 것들

팀들은 처음에 똑같은 세 가지 조치를 취하려 하지만, 그 중 어느 것도 문제를 해결하지 못합니다.

더 많은 재시도(Retries). 재시도는 불안정한(Flaky) 작업이 결국 성공을 보고하게 만듭니다. 하지만 그 성공이 진짜인지 확인하지는 않습니다.

더 큰 모델(Bigger model). 더 강력한 모델은 더 설득력 있는 보고서를 작성합니다. 하지만 그 보고서는 여전히 스스로 발행된 것입니다.

신뢰도 점수(Confidence score). 에이전트가 자신의 신뢰도를 평가하는 것은 에이전트가 자신의 시험 성적을 매기는 것과 같습니다.

이 세 가지 모두 가시적인 오류율을 낮춥니다. 그것은 진전처럼 느껴집니다. 하지만 실제로는 그 반대입니다. 요란한 실패가 조용한 실패로 변할 뿐이며, 조용한 실패는 고객에게 도달할 때까지 숨어 있기 때문에 더 많은 비용을 발생시킵니다.

실제로 루프를 닫는 법

이 해결책은 하나의 규율(Discipline)입니다. 도구(Tooling)는 그 다음에 따라옵니다.

어떤 주장(Claims)이 중요한지 결정하십시오. 대부분의 출력은 건너뛰십시오. 틀렸을 때 실제 비용이 발생하는 소수의 항목만 남기십시오.

그러한 각 주장들에 대해, 에이전트가 말(Talking)만으로는 충족할 수 없는 확인 절차를 구축하십시오. 좋은 확인 절차는 현실을 관찰합니다. 에이전트가 설명하는 현실의 서사(Narration)는 무시합니다.

만약 에이전트가 기록이 작성되었다고 말한다면, 에이전트가 아닌 다른 무언가가 그 기록을 다시 읽어야 합니다.

만약 에이전트가 워크플로(Workflow)가 실행되었다고 말한다면, 에이전트가 아닌 다른 무언가가 후속 효과(Downstream effect)가 발생했음을 확인해야 합니다.

원칙은 간단합니다. 주장(Claim)과 그 증명(Proof)은 서로 다른 출처에서 나와야 합니다. 일단 두 가지가 동일한 출처를 공유하게 되면, 당신이 검증(Verification)을 원했던 자리에 보도 자료(Press release)가 놓이게 됩니다.

제가 이 원칙을 적용했던 기업용 배포(Enterprise rollouts) 사례 전반에서, 침묵하는 실패(Silent failures)의 비율은 첫 달 이내에 급격히 감소했습니다. 에이전트(Agents)가 이전보다 더 똑똑해진 것은 아니었습니다. 변한 것은 결과물을 목격하는 주체가 누구인가 하는 점이었습니다.

이 글이 당신에게 제공하지 않는 것

저는 이 방식의 특정 버전을 실제 운영 환경(Production)에서 실행하고 있습니다. 정확한 체크리스트, 임계값(Thresholds), 그리고 실패한 주장(Failed claim)을 첫 번째 응답으로 매핑하는 런북(Runbook) 같은 것들 말입니다. 그것들이 제가 고객 업무에 가져가는 것들입니다.

저는 그것들을 여기에 붙여넣지 않을 것이며, 그 이유는 솔직합니다.

구현 방법(Implementation)을 포스트에 올려버리면, 다음에 이 문제에 부딪힌 팀은 검색을 하고, 복사하고, 배포할 것입니다. 그리고 애초에 왜 자신들의 루프(Loop)가 닫혀 있었는지에 대한 근본적인 대화는 결코 나누지 않을 것입니다.

구현은 저렴한 부분입니다. 어떤 주장들이 그 주장을 하는 주체 이외의 무언가에 의해 증명되어야 하는지 결정하는 것이야말로 부하(Load)를 견뎌내는 핵심적인 부분입니다.

당신을 위한 질문 하나

대부분의 "내 컴퓨터에서는 잘 되는데(It works on my machine)"라는 식의 놀라움은, 사실 "아무도 독립적으로 검증하지 않았다"라는 놀라움이 변장하고 있는 것에 불과합니다.

그래서 제가 함께 일하는 팀들에게 던지는 것과 동일한 질문을 드립니다.

현재 당신의 스택(Stack)에서, AI가 완료되었다고 보고하지만 AI 이외의 그 어떤 것도 확인한 적 없는 것을 하나만 말씀해 주세요.

댓글로 남겨주세요. 그것이 안전한 상태인지, 아니면 월요일을 기다리며 도사리고 있는 다음 침묵하는 실패(Silent failure)인지 알려주는 질문으로 답해드리겠습니다.