AI 에이전트 검증 자동화, 스크립트 210개가 712개 될 때

AI 에이전트로 혼자 여러 제품을 만들면 검증은 왜 무너지나?

AI 에이전트 검증 자동화가 필요해지는 순간은 코드가 늘 때가 아니라, 사람이 같은 화면을 두 번 보기 시작할 때입니다. 저희는 2026-08-21부터 2026-10-19까지 두 달 동안 저장소를 42개에서 55개로, 사람이 시킨 작업 커밋을 4,612개에서 7,959개로 늘렸습니다. 같은 기간 자동으로 도는 스크립트는 210개에서 712개로, 정해진 시각에 도는 예약 작업(크론)은 142개에서 369개로 불었습니다.

만드는 속도는 AI가 올려 줬지만 검수하는 눈은 여전히 한 사람 몫이었습니다. 활성 프로젝트 13개, 제품마다 화면 수십 개, 그리고 그 화면을 매번 고칩니다. 검수량이 제품 수 × 화면 수 × 변경 횟수로 곱해지면 한 사람이 감당할 수 없고, 실제로 벌어진 일은 단순했습니다. 안 보게 됐습니다. 안 보는 검수는 없는 검수와 같습니다.

이 글은 그 병목을 어떻게 재고, 처음 세운 가설이 어디서 틀렸고, 무엇을 바꾼 뒤 다시 쟀는지 적은 기록입니다. 숫자가 좋아진 대목만이 아니라 다시 재 보니 오히려 낮아진 숫자도 그대로 남깁니다.

처음 잰 숫자: 백엔드 테스트는 수십 개, 화면 검증은 0개

병목을 느낌으로 말하지 않으려고 먼저 검증이 실제로 어디에 있는지 셌습니다. 2026-08-19 실측에서 영업 운영 저장소의 백엔드 로직 테스트는 이미 수십 개였습니다. 반면 화면이 제대로 그려지는지 보는 프론트엔드 시각 검증은 인프라가 0이었습니다. 브라우저 자동화 설정 파일(playwright.config)도 0개, 승인된 기준 화면(baseline)도 0개였습니다.

이 숫자가 말하는 바는 분명했습니다. 자동화는 기계가 일하는 층에만 깔려 있었고, 사람 눈이 실제로 소비되는 층에는 아무것도 없었습니다. 함수가 맞는 값을 돌려주는지는 테스트가 봐 주는데, 고객이 보는 첫 화면의 글자가 잘렸는지는 사람이 열어 봐야만 알 수 있었습니다.

같은 시점에 늘어난 자산 쪽 숫자도 함께 기록했습니다. 에이전트가 파일을 쓰거나 커밋하기 직전·직후에 자동으로 도는 검사 스크립트(훅)는 2026-08-21 기준 22개였고, 두 달 뒤 68개가 됩니다. 스킬은 60개에서 73개, 에이전트 정의는 23개에서 28개, 규칙 문서는 29개에서 32개로 늘었습니다. 코드 줄 수는 2026-10-19 기준 1,680,153줄이지만 기준선이 추적 밖 파일까지 센 옛 방식이라 비교하지 않습니다. 비교할 수 없는 숫자는 비교하지 않는다는 원칙을 여기서 먼저 세웠습니다.

늘어난 양은 저장소마다 고르지 않았습니다. 영업 운영 저장소가 커밋 1,410개에서 3,568개로 가장 많이 늘었고, 콘텐츠 자동 발행 저장소가 187개에서 511개, 자동매매 저장소가 1,305개에서 1,445개로 뒤를 이었습니다. 회사 업무 쪽에서도 같은 기간 자동화 시스템 41개를 작업일 110일에 걸쳐 운영했습니다. 화면과 결과물을 내놓는 곳이 이만큼 많아지자, 한 사람이 매번 열어 보는 방식은 처음부터 셈이 맞지 않았습니다.

세운 가설: 검사기를 만들어 통과시키면 된다

첫 가설은 소박했습니다. 사람이 보던 것을 검사기로 바꾸고, 검사기가 통과시키면 믿는다. 구체적으로는 세 갈래였습니다.

• 화면 비교는 고정 임계로 충분하다. 기준 화면과 새 화면의 픽셀 차이가 0.2%를 넘으면 변경으로 보고, 넘지 않으면 같은 화면으로 본다
• 사람 판정 대신 LLM에게 판정을 맡기면 눈을 아낄 수 있다
• 새 검사기를 만들면 정상 입력 몇 건을 넣어 통과하는지 보고, 통과하면 믿을 만하다고 본다

세 가설 모두 당시에는 합리적으로 보였습니다. 하지만 셋 다 같은 전제를 깔고 있었습니다. 검사기가 통과시킨 것은 맞다는 전제입니다. 이 전제가 어디서 깨졌는지가 이 글의 중심입니다.

두 번째 가설은 착수 전에 문헌에서 먼저 막혔습니다. 2025년 여러 연구에서 LLM 판정자와 전문가의 동의율은 64~68%였고, 위치 편향과 점수 편향이 실증돼 있었습니다. 그래서 LLM은 검사 규칙과 시나리오를 쓰는 단계에만 두고, 매 실행의 판정은 결정론 코드가 내리도록 방향을 잡았습니다. 나머지 두 가설은 직접 돌려 보고 나서야 틀렸다는 사실을 알았습니다.

가설이 틀린 지점: 통과한 것이 정답이 아니었다

고정 임계 가설은 첫 구현에서 흔들렸습니다. 아무것도 바꾸지 않은 화면을 여러 번 찍어 픽셀 차이를 재 보니 노이즈 바닥이 0.160%였습니다. 임계 0.2%와의 거리가 0.04%p밖에 안 됐습니다. 애니메이션 한 프레임, 시각 표시 한 줄만 달라져도 넘을 수 있는 거리입니다. 오탐이 한 번만 나와도 사람은 그 검사를 다시 믿지 않습니다.

두 번째 균열은 검사를 통과한 결함이었습니다. 2026-08-19 첫 실행에서 영문 페이지(/en) 첫 화면의 문구가 잘려 있었는데, 이 결함은 자동 검사 규칙을 전부 통과했고 사람이 합본 한 장을 훑어보다 잡았습니다. 규칙에 적지 않은 결함은 통과합니다. 통과는 "검사한 것 중 걸린 게 없다"는 뜻일 뿐이었습니다.

세 번째 가설은 더 아프게 깨졌습니다. 2026-08-31 해외 법령명을 판정하는 검사기를 만들고 정상 입력 5건만 넣어 본 뒤 믿을 만하다고 보고했습니다. "믿을만해?"라는 한 마디 되물음에 일부러 틀린 입력을 넣어 보니 거짓 통과가 4건 나왔습니다. the · Act · Law · Regulations 같은 일반 단어가 전부 법령으로 통과했습니다. 같은 작업 묶음에서 결론이 뒤집힌 것이 7건이었고, 그중 5건은 사람이 되물어야만 뒤집혔습니다. 사람의 되물음이 사실상 유일한 검증 단계로 돌고 있었습니다.

평가 수치에서도 같은 일이 있었습니다. 2026-10-15 공공 과제용 챗봇 실험에서 평가 질문을 쓰는 쪽에 예시 주제를 줬더니, 그 주제가 학습 문장에도 들어가 있었습니다. 지식에 없는 질문 40건 중 14건에서 담당자 안내율이 43%, 나머지에서는 23%로 갈렸습니다. 평가가 측정하는 대상이 모델이 아니라 출제자의 힌트였던 셈입니다.

진짜 원인은 무엇이었나? 검수량이 제품 수에 비례하는 구조

세 가설이 틀린 이유를 하나씩 고치기 전에, 공통 원인을 다시 적었습니다. 문제는 검사기가 부정확해서가 아니었습니다. 검수량이 제품 수에 정비례하는 구조 자체가 문제였습니다.

지금: O(제품 × 화면 × 변경 횟수). 지수를 줄이는 것 말고는 답이 없다.

이 구조 위에서는 검사기를 아무리 정교하게 만들어도 사람 눈이 끝에 남습니다. 그리고 그 눈이 내린 판정을 어디에도 저장하지 않으면, 다음 대화에서 같은 질문을 다시 합니다. 한 번 승인한 화면을 다음 주에 또 보고, 이미 고친 부분을 또 확인합니다. 이 반복이 다른 어떤 비효율보다 컸습니다.

AI 쪽에도 같은 구조가 있었습니다. 외부 신호 없이 "다시 확인해 봐"라고 시키면 강한 모델일수록 오히려 정답을 오답으로 바꿉니다. 정확도 94% 모델의 자기 교정 성공률이 16.7%라는 연구가 있고, 사용자가 "이거 맞아?"라고만 물어도 답을 뒤집는 비율이 58.19%, 한번 뒤집은 답을 유지하는 비율이 78.5%였다는 연구도 있습니다. 에이전트에게 스스로 검증하라고 맡기는 방식은 구조적으로 믿을 수 없었습니다.

판정자 설계도 같은 원인에서 다시 정했습니다. LLM은 규칙과 시나리오를 쓰는 작성자로만 쓰고, 매 실행은 결정론 엔진이 돌립니다. 그래야 빠르고 싸고 결과가 흔들리지 않습니다. 품질의 최종 판단은 도메인을 아는 한 사람이 내리고, 여러 LLM의 다수결은 쓰지 않습니다. 같은 질문에 같은 답이 나오지 않는 판정자는, 아무리 똑똑해도 매일 돌리는 검사의 판정자가 될 수 없었습니다.

정리하면 원인은 셋이었습니다. 검수량이 곱셈으로 늘어나는 구조, 사람 판정을 쌓지 않고 흘려보내는 습관, 그리고 통과를 정답의 증거로 읽는 해석입니다.

어떻게 고쳤나? 사람 판정은 저장하고, 기계는 부정형만 본다

조치는 검사기를 더 똑똑하게 만드는 쪽이 아니라 곱셈의 축을 하나씩 지우는 쪽으로 잡았습니다.

• 시간축 제거: 사람이 승인한 화면은 기준 화면으로 동결합니다. 같은 화면을 두 번 보지 않습니다. 승인을 받으면 그 대화 안에서 바로 저장하고, 빼먹으면 판정이 날아가 다음 대화가 같은 질문을 합니다
• 제품축 제거: 여러 제품이 같은 버튼·카드·폼을 쓰면 그 부품은 한 번만 검수합니다. 제품별로 보는 것은 부품이 아니라 새 조합뿐입니다
• 선별: 기계가 전수로 훑고, 위반과 변경분만 한 장짜리 합본(contact sheet)으로 모읍니다. 사람이 여는 파일은 언제나 1개입니다
• 부정형 규칙: "이게 맞나"는 기계가 답할 수 없습니다. 대신 "어떤 경우에도 이건 아니다"를 적습니다. 부정형은 명세 없이도 돌고 모든 제품에 그대로 재사용됩니다
• 노이즈 바닥 자동 측정: 고정 임계 0.2%를 버리고, 화면마다 노이즈를 먼저 재서 임계를 정합니다

모든 제품에 같은 깊이로 투자하지도 않았습니다. 제품 대부분은 살아남지 못하는데, 죽을 제품에 기준 화면을 쌓는 일은 낭비입니다. 그래서 검수 투자를 제품의 생존 신호에 맞췄습니다. 막 만든 제품은 부정형 규칙만 돌리고 사람 눈은 0회입니다. 셋업은 2~3초입니다. 방문·문의 같은 실제 신호가 생기면 기준 화면을 추가하고 사람이 최초 1회 승인합니다. 셋업은 5분 더 듭니다. 매출이 생기면 결제·데이터 흐름까지 넣고 셋업은 30분 더 듭니다.

오탐이 나왔을 때의 순서도 정했습니다. 임계부터 만지지 않습니다. 먼저 원인을 봅니다. 애니메이션, 시각 표시, 무작위로 바뀌는 콘텐츠가 대부분입니다. 노이즈 바닥 자동 측정이 이 대부분을 흡수하므로, 그래도 오탐이 나면 그 화면은 정말로 흔들리는 화면이라고 판단합니다. 검사 인프라를 제품 저장소마다 따로 세우지도 않았습니다. 제품이 갖는 것은 검사 대상 설정 파일 한 장뿐이고, 제품을 접으면 그 한 줄만 지웁니다. 제품마다 설정·테스트·배포 검사를 새로 세우는 순간 그 일 자체가 새 병목이 되기 때문입니다.

에이전트 쪽에는 차단 장치를 붙였습니다. Claude Code의 훅은 종료 코드 2를 내야 실제로 막고, 1은 경고만 남깁니다. 막을 의도인 검사는 전부 2로 바꿨습니다. 같은 도구 호출 결과가 3회 똑같이 반복되면 멈추게 했는데, 공개 사례에서 같은 호출이 58회나 반복되는 동안 아무도 몰랐던 일이 있었기 때문입니다. 새 검사기를 만들면 일반 단어·짧은 입력, 옆 분야의 정답, 부정 문맥 세 가지를 일부러 넣어 거짓 통과를 찾은 뒤에만 믿을 만하다고 말합니다.

평가 수치에는 감사 3종을 붙였습니다. 평가 표본의 출처가 학습 문장 출처와 겹치는지, 출제자가 본 설명을 모델 입력에서 빼도 숫자가 유지되는지, 차이의 95% 구간 하한이 0 이하인지를 확인하고 통과한 숫자만 소개 문서로 옮깁니다. 검사는 매일 08:35 예약 작업으로 전체 제품을 돌고, 승인된 것은 알림에 뜨지 않습니다. 빨간불이 계속 켜져 있다면 그건 진짜 안 고친 것입니다.

병렬 작업에서 작업 목록이 사라지던 문제도 같은 방식, 즉 문장으로 적힌 규칙을 명령과 커밋 검사로 바꾸는 방식으로 풀었습니다. 그 과정은 Claude Code 병렬 세션이 작업 목록을 지운 이유에 따로 적었습니다.

재측정 결과: 낮아진 숫자가 진짜 숫자였다

화면 검사는 2026-08-19 첫 실행에서 실제 운영 중인 사이트의 결함 3건을 잡았습니다. 0개였던 프론트엔드 시각 검증이 처음으로 무언가를 찾아낸 날입니다. 그중 하나인 영문 첫 화면 문구 잘림은 앞서 쓴 대로 규칙이 아니라 합본을 본 사람 눈이 잡았습니다. 그래서 실신호가 있는 제품부터는 눈이 최초 1회 들어가도록 단계를 설계했습니다.

평가 수치는 재측정 뒤 오히려 낮아졌습니다. 출제자가 본 설명을 학습에서 빼고 다시 재자 정답 도달률이 89.4%에서 81.7%로 떨어졌습니다. 다른 실험에서는 보강 표본을 규칙과 같은 출처에서 뽑았던 탓에 재현율이 0.818로 나왔는데, 출처를 분리하자 0.64가 됐습니다. 처음 숫자로 소개 문서를 썼다면 부풀린 실적을 내보낼 뻔했습니다. 낮아진 숫자가 진짜 숫자였습니다.

같은 원칙을 회사 업무 자동화에도 적용했습니다. 사내 메신저 업무 비서는 요청마다 누적 대화를 다시 읽던 구조 탓에 응답이 최대 292초까지 늘어졌습니다. 명령을 즉시 처리하는 상시 대기 워커로 바꾼 뒤 다시 재자 접수 표시가 3.0~5.2초, 명령 완료가 3.4초였고, 주기 작업과 같은 처리 기록을 공유해 중복 발송 0건을 확인했습니다. 복합기 스캔 문서 자동 명명은 건당 판독 10초로 운영합니다. 여기서도 판정을 맹신하지 않았습니다. 판독 신뢰도가 낮은 문서는 이름을 바꾸지 않고 원본명을 기록해 되돌릴 수 있게 했고, 스캔 문서 속 문구가 판독 모델의 지시로 쓰이지 않도록 입력을 데이터로 격리했습니다.

두 달 끝의 자산 숫자도 다시 셌습니다. 2026-10-19 기준 신규 저장소 13개, 커밋이 늘어난 저장소 14개입니다. 영업 운영 저장소 하나에서만 커밋이 1,410개에서 3,568개로 2,158개 늘었습니다. 검수를 사람 눈 하나에 묶어 두었다면 이 속도는 나오지 않았을 것입니다. 다만 이 숫자는 만든 양이지 품질의 증거가 아닙니다. 그 이야기는 다음 절에 적습니다.

남는 한계는 무엇인가?

첫째, 통과는 여전히 정답이 아닙니다. 부정형 규칙에 없는 결함은 통과하고, 그래서 사람 눈을 0으로 만들지 못했습니다. 실신호가 있는 제품에는 최초 1회 눈이 들어갑니다.

둘째, 기계로 못 보는 영역이 분명히 남습니다. 접근성은 자동 검사로 57%만 잡힙니다. 대체 텍스트가 실제로 그림을 설명하는지, 에러 메시지가 사용자에게 도움이 되는지 같은 의미 판단은 검사하지 않고, 검사한 척도 하지 않습니다.

셋째, 자산 숫자 자체에도 한계가 있습니다. 신규 저장소 13개 중에는 커밋 112개·4,189줄짜리도 있지만 커밋 3개·15줄짜리 시험용 저장소도 섞여 있습니다. 커밋 수는 일한 양을 보여 줄 뿐 쓸모를 보여 주지 않습니다. 코드 줄 수 1,680,153줄은 기준선 셈법이 달라 증감을 말할 수 없습니다.

넷째, 사람의 되물음이 마지막 검증 단계였던 구조는 줄었지만 사라지지 않았습니다. 적대적 입력 세 종류를 의무로 넣어도 저희가 떠올리지 못한 입력은 여전히 빠집니다. 자동화를 늘린 만큼 "이 검사가 무엇을 안 보는가"를 문서로 남기는 일이 함께 늘었습니다.

AI 에이전트 자동화가 실제로 어디까지 믿을 만한지는 AI 업무 자동화 에이전트의 신뢰성 한계에서 다른 각도로 다뤘습니다.

AI 에이전트로 여러 제품을 만들 때 먼저 볼 것

• 검증이 어느 층에 있는지 먼저 셉니다. 백엔드 테스트 수와 화면 기준 화면 수를 따로 세면, 사람 눈이 소비되는 층이 비어 있는지 바로 보입니다
• 사람이 승인한 판정은 그 자리에서 저장합니다. 저장하지 않은 승인은 다음 대화에서 같은 질문으로 돌아옵니다
• 고정 임계를 쓰기 전에 아무것도 안 바꾼 상태의 노이즈를 잽니다. 저희는 그 거리가 0.04%p였습니다
• 새 검사기는 정상 입력이 아니라 일부러 틀린 입력으로 시험합니다. 정상 5건 통과는 믿을 근거가 아니었습니다
• 평가 숫자가 좋게 나오면 출제 쪽 정보가 모델 쪽으로 새지 않았는지부터 의심합니다
• 검수 투자는 제품의 생존 신호에 맞춥니다. 막 만든 제품에 기준 화면을 쌓지 않습니다

저희는 이 방식으로 홈페이지 제작과 AI 업무 자동화를 납품할 때도 화면 검수와 판정 기록을 함께 넘깁니다. 비슷한 검증 문제를 겪고 있다면 상담으로 상황을 보내 주세요.