AI가 짠 코드, 검증은 이렇게 (3편·완결) — 못 잡은 것, 그리고 AI 본인의 증언

앞의 두 편이 "안 믿는 그물"과 "그물이 건진 것"이었다면, 이번엔 정반대입니다. 그물이 놓친 것, 그리고 개발을 수행한 AI 스스로의 고백입니다. 여기까지 읽으며 "잡았다는 숫자도 자기들이 쓴 거고, 못 잡은 건 얼마나 되냐"는 의심이 들었다면 — 그게 정상이고, 이 편이 그 질문에 답하는 자리예요.

지난 편 → 2편 — 검증이 실제로 잡아낸 것들

"잡은 게 60건이면, 못 잡은 건 몇 건입니까?"

가장 정직하게 답해야 하는 질문입니다. 먼저 인정부터 — 못 잡은 결함의 총수는 아무도 모릅니다. 이 프로젝트만이 아니라 세상 모든 소프트웨어가 그래요. "버그가 없다"는 증명은 원리적으로 불가능하고, 오히려 그렇게 주장하는 쪽을 의심해야 합니다.

할 수 있는 건 간접 증거를 보이는 일이에요.

먼저 잡은 쪽 숫자 — 기록상 13개 작업 묶음에 걸쳐 약 60여 건의 약점이 완료 선언 이전에 잡혔습니다(건수가 명시된 기록만 보수적으로 합산한 하한값). 전부 수정·재검증 통과·사실 정정·사유 명시 보류 중 하나로 종결됐고, 무응답 방치는 0건입니다.

더 중요한 간접 증거 — 내부 검증을 통과한 뒤, 독립 실사용 검증에서 추가로 발견되는 코드 결함이 라운드를 거듭할수록 줄었습니다. 초기엔 실제 코드 결함이 여럿 나왔지만, 후반으로 갈수록 발견물이 "코드가 틀렸다"에서 "문서를 더 쉽게 써 달라" 류로 옮겨 갔고, 마지막 라운드들에선 새 코드 결함이 0건이었어요.

정확한 총수를 셀 방법은 없으니 이건 경향에 대한 서술이지 그 이상은 아닙니다. 다만 "그물을 통과해 하류에서 잡히는 물고기가 갈수록 줄어 마침내 0이 됐다"는 건, 그물이 촘촘해지고 있다는 합리적 간접 증거예요.

정직 코너 (1) — 검증이 실제로 놓친 한 건

이 검증 체계가 놓친 실제 사례를 공개합니다.

파일의 기본 보존 기간을 설정하는 기능이 있었는데, 그 계산 로직 자체는 완벽히 정상이었어요. 문제는 다른 데 있었습니다 — 앞단의 연결 부품이 항상 별도의 고정값을 주입하고 있어서, 그 정상 로직이 실제로는 한 번도 실행되지 않는 '죽은 코드'였던 겁니다.

서류 심사의 한계와 같아요. 서류(코드)만 보면 "규정이 있고, 내용도 맞다"까지는 확인되지만, 그 규정이 현장에서 실제로 집행되는지는 서류에 안 보입니다. 검사역 AI의 코드 검토는 이 결함을 통과시켰고, 잡아낸 건 독립 실사용 검증이었어요 — "설정했는데 적용이 안 됩니다"라는, 현장에서만 나올 수 있는 보고로요.

그 후가 진짜 요점입니다. 이 실패를 계기로 "핵심 로직은 따로 떼어 자동 테스트로 직접 못 박는" 관행이 추가됐고, 그 결함의 재현 조건이 회귀 테스트(재발하면 즉시 실패)로 저장소에 박혔습니다. 같은 실수가 반복되면 이제 사람도 AI도 아닌 기계가 잡아요. 검증 체계는 완벽해서 믿을 만한 게 아니라, 실패를 기록하고 그 실패로 구조를 고치기 때문에 믿을 만해집니다.

정직 코너 (2) — 만든 AI 본인의 증언

하나 더, 개발을 수행한 AI 본인의 증언입니다. 이 글을 정리하며 그 AI에게 직접 물었어요.

"이 검증 요구가 작업 지침에 없었다면, 너는 스스로 이 검증 공정을 돌렸겠는가?"

답은 이랬습니다 — "체계적으로는 낮다."

위험해 보이는 부분(암호화, 동시 실행 등)은 지침이 없어도 추가 검토를 했을 확률이 어느 정도 있지만, 그건 자기가 만든 걸 자기가 다시 읽어보는 약한 형태에 그쳤을 거고, "약점 3건 이상을 의무로, 매 작업마다, 통과 전엔 완료 보고 금지"라는 적대적 공정은 지침이 강제하지 않았다면 스스로 만들지 않았을 확률이 높다는 답이었어요.

근거도 프로젝트 안에 있습니다. 지침이 있었는데도 만드는 AI는 같은 실수(배포용 문서 동기화 누락)를 두 번 반복했고, 두 번 다 잡은 건 본인이 아니라 검사역이었어요. 자기 사각지대는 자기가 못 봅니다 — AI도 똑같습니다.

숫자로 요약하면

항목	값
완료 선언 이전에 잡힌 약점	13개 작업 묶음, 약 60여 건 (하한값)
발견 약점의 처리	전건 종결 — 무응답 방치 0건
현재 자동 테스트	327개 (상당수가 잡힌 약점의 재현 조건)
독립 실사용 검증의 경향	라운드 거듭할수록 코드 결함 감소, 마지막은 0건
검증이 놓친 뒤 외부 검증이 잡은 사례	1건 공개(위) — 이후 검증 관행 자체를 수정

맺으며 — 우리는 AI를 믿지 않습니다

역설처럼 들리겠지만, 이 프로젝트에서 AI가 만든 소프트웨어를 신뢰할 수 있는 이유는 아무도 AI를 그냥 믿지 않기 때문입니다.

• 만드는 AI의 "완료했다"는 말은 안 믿습니다 — 기계 판정이 통과해야 완료.
• 만드는 AI의 자기 검토는 안 믿습니다 — 흠 찾기가 직업인 검사역이 약점 3건 이상을 의무로 찾음.
• 프로젝트 내부 결론도 안 믿습니다 — 맥락 모르는 독립 프로젝트가 배포본만 받아 실환경에서 재확인.
• 이 글의 주장도 믿으라 하지 않습니다 — 저장소의 변경 기록과 테스트 이름으로 직접 재확인 가능.

이 시리즈를 관통하는 한 문장으로 닫겠습니다.

믿는 것은 AI가 아닙니다. AI가 남긴 기계적 증거와, 서로를 믿지 않도록 설계된 구조입니다.

(AI가 짠 코드, 검증은 이렇게 — 3부작 완결. 1편 원리 → 2편 사례 → 3편 정직·결론)