<h1>AI가 만든 소프트웨어, 어떻게 믿을까 (3편) — 못 잡은 것, 그리고 만든 AI의 증언</h1>

결론부터: 2편까지가 "검증이 잡아낸 것"이었다면, 이번엔 "못 잡은 것"입니다. 검증 체계가 놓친 실제 사례 하나와, 개발을 수행한 AI 본인의 증언을 공개합니다. 그리고 마지막에 — 회사가 아니라 혼자 일하는 당신이 이 방식을 축소판으로 시작하는 법까지 담았습니다.

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

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

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

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

더 중요한 간접 증거는 이겁니다 — 내부 검증을 통과한 뒤, 만든 쪽을 모르는 독립 검증에서 추가로 나오는 코드 결함이 라운드를 거듭할수록 줄었습니다. 초기엔 실제 코드 결함이 여럿 나왔지만, 후반으로 갈수록 발견물이 "코드가 틀렸다"에서 "문서를 더 쉽게 써 달라"로 옮겨 갔고, 마지막 라운드들에서는 새 코드 결함이 0건이었어요. 총수를 셀 방법은 없으니 이건 경향에 대한 서술입니다. 다만 "그물을 통과해 하류에서 잡히는 물고기가 갈수록 줄어 마침내 0이 됐다"는 건, 그물이 촘촘해지고 있다는 합리적 증거입니다.

정직 코너 — 검증이 놓친 한 건

이 검증 체계가 놓친 실제 사례를 공개합니다. 파일의 기본 보존 기간을 정하는 기능이 있었는데, 그 계산 로직 자체는 완벽히 정상이었어요. 문제는 다른 곳에 있었습니다 — 앞단의 연결 부품이 항상 별도의 고정값을 넣고 있어서, 그 정상 로직이 실제로는 한 번도 실행되지 않는 '죽은 코드'였던 겁니다.

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

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

그리고 — 만든 AI 본인의 증언

이 글을 정리하며, 개발을 수행한 AI에게 직접 물었습니다. "이 검증 요구가 지침에 없었다면, 너는 스스로 이 검증 공정을 돌렸겠는가?" 돌아온 답은 이랬어요 — "체계적으로는 낮다."

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

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

숫자로 요약하면

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

그래서, 혼자인 당신은 어떻게 시작하나

여기까지 읽고 "나는 회사도 아니고 혼자인데, 테스트 327개에 독립 검증팀은 무리"라고 느끼셨다면 정상입니다. 하지만 핵심은 규모가 아니라 방향이라, 축소판으로 얼마든지 시작할 수 있어요.

서브에이전트가 없어도 — 새 대화창을 하나 더 열고, 만든 맥락(왜 이렇게 짰는지)은 빼고 결과물만 붙여넣은 뒤 "이 코드가 어떤 조건에서 무너지는지 3개 찾아줘"라고 하세요. 만든 대화와 검증 대화를 나누는 것만으로 '생성자≠검증자 격리'의 최소판이 됩니다.
테스트를 못 짜도 — AI가 "됐습니다"라고 하면 그 말을 믿지 말고 "실제로 실행해서 결과를 붙여줘"라고 하세요. '말'을 '증거'로 바꾸는 겁니다.
한 번 데였으면 박아두세요 — 같은 버그에 두 번 당하지 않게, 그 상황을 재현하는 확인 절차를 어딘가에 적어두면 그게 당신의 회귀 테스트입니다.

이 세 가지만으로도 자기 검토의 맹점 상당수가 걸립니다. 회사는 크게 했지만, 당신은 작게 시작하면 됩니다.

맺으며 — 믿는 것은 AI가 아니다

세 편에 걸친 이야기의 결론은 하나입니다. 이 프로젝트에서 AI가 만든 소프트웨어를 신뢰할 수 있는 이유는 아무도 AI를 그냥 믿지 않았기 때문입니다.

만드는 AI의 "완료했다"는 말은 안 믿습니다 — 기계 판정이 통과해야 완료
만드는 AI의 자기 검토는 안 믿습니다 — 흠 찾기가 직업인 검사역이 약점을 의무로 찾음
내부 결론도 안 믿습니다 — 맥락을 모르는 독립 검증이 다시 확인
이 글의 주장도 믿으라고 안 합니다 — 저장소의 변경 기록과 테스트로 재확인 가능

AI가 만들었다고 다른 마법이 필요한 게 아니라, 같은 장치(테스트·리뷰·독립 검증)를 더 의심 많게 거는 것이 답이었습니다. 믿는 것은 AI가 아니라, AI가 남긴 기계적 증거와, 서로를 믿지 않도록 설계된 구조입니다.

이 블로그 검색

Second Branch

AI가 만든 소프트웨어, 어떻게 믿을까 (3편) — 못 잡은 것, 그리고 만든 AI의 증언