AI가 짠 코드, 검증은 이렇게 (1편) — 우리는 AI를 믿지 않기로 했습니다

AI가 짠 코드를 어떻게 믿냐고요? 저도 안 믿습니다. 그런데도 그 결과물을 신뢰할 수 있었던 건, 역설적으로 아무도 AI 말을 곧이듣지 않도록 세 겹의 그물을 쳤기 때문입니다 — ① 사람이 아니라 기계가 통과·실패를 매기고, ② 흠 잡는 것만 전담하는 별도의 검사 AI를 두고, ③ 만든 과정을 전혀 모르는 제3자가 결과물만 받아 다시 확인. 이 편은 그 세 겹 이야기입니다.

"AI가 만들었습니다"라는 말이 왜 불안한가

"이 소프트웨어, AI가 만들었습니다." 이 말에 마음이 편해지는 사람은 별로 없죠. 오히려 이런 생각이 정상입니다 — "AI는 그럴듯한 거짓말을 잘한다던데, 그게 만든 걸 어떻게 믿어?"

그 불신은 정당합니다. 실제로 AI 언어모델(LLM)은 하지 않은 일을 "완료했습니다"라고 보고하는 경향이 있어요. 이건 소문이 아니라 제가 개발의 출발점으로 삼은 전제였습니다. 개발 상당 부분을 AI가 수행하는 프로젝트였고, 그래서 첫날부터 규칙이 하나 있었어요.

"AI의 '완료했다'는 말은 믿지 않는다. 실제로 실행해서 확인된 것만 완료다."

"검증하는 것도 AI라며? 그게 무슨 검증이냐"

가장 뼈아픈 질문입니다. AI가 만든 걸 AI가 검사하면 한통속 아니냐는 거죠. 답은 세 겹입니다.

첫째, 최종 판정은 AI가 아니라 기계가 한다

소프트웨어엔 '자동 테스트'가 있습니다. "이 상황에서 이 결과가 나와야 한다"를 미리 못 박으면, 컴퓨터가 실제로 돌려서 통과 아니면 실패로만 판정해요. 의견이나 해석, 봐주기가 낄 자리가 없습니다.

검사역 AI의 일은 감상평이 아니라 약점을 찾아 테스트로 못 박는 것입니다. 이렇게 약점을 하나 잡을 때마다 테스트로 쌓아온 게 지금 327개예요. 코드를 고칠 때마다 이 327개가 전부 다시 돌고, 하나라도 실패하면 다음 단계로 못 넘어갑니다. 한 번 잡힌 약점은 테스트로 남아, 나중에 누가(사람이든 AI든) 같은 실수를 하면 기계가 즉시 잡습니다.

둘째, 만드는 AI와 트집 잡는 AI를 분리했다

변호사와 검사를 떠올리면 됩니다. 검사가 변호사를 안 봐주는 건 검사의 성과가 '흠 찾기'로 매겨지기 때문이죠. 검증 공정도 똑같이 짰습니다.

• 만드는 AI는 기능을 구현
• 검사역 AI(내부 명칭 critic)는 "어떤 조건에서 무너지나"만 탐색. 정상 동작 확인은 아예 업무가 아니고, "약점 3건 이상 보고"가 의무입니다 — "다 괜찮아 보입니다"라는 보고 자체가 금지된 역할 설계예요.
• 심각한 약점은 수정·재검증 전엔 완료로 인정 안 함

봐주기가 되려면 검사역이 "약점 없음"이라 말할 수 있어야 하는데, 이 구조에선 그 말이 곧 직무 태만이 됩니다.

셋째, 만든 쪽 말을 안 믿는 외부 검증을 따로 뒀다

만드는 AI와 검사역 AI는 같은 프로젝트 맥락을 공유합니다. 그래서 한 겹 더 뒀어요. 만든 과정을 전혀 모르는 별도 프로젝트를 세우고, 완성 배포본만 건네준 뒤 실제 환경에서 문서만 보고 처음부터 써 보게 했습니다. 이 외부 검증은 만든 쪽 설명을 안 듣고, 문서가 틀렸으면 틀렸다고 보고할 뿐이에요. 내부 검증을 통과하고도 남은 문제들이 여기서 추가로 잡혔습니다.

정리 — 믿는 것은 구조지, AI가 아니다

믿음의 뿌리는 AI의 판단력이 아닙니다.

1. 통과/실패만 있는 기계 판정 (자동 테스트 327개)
2. 흠 찾기가 직업인 분리된 검사역 (약점 3건 이상 의무)
3. 만든 쪽 말을 안 믿는 독립 재검증

사람이 만든 소프트웨어도 결국 테스트·리뷰·독립 검증 위에서 신뢰를 얻어왔죠. AI가 만들었다고 다른 마법이 필요한 게 아니라, 같은 장치를 더 의심 많게 거는 것이 답이었습니다.

다음 편

다음 편에서는 이 검증이 실제로 뭘 잡아냈는지 — 조용히 자물쇠를 바꿔치기하던 코드, 딛고 선 사다리를 치워버리는 버그 — 실제 사례를 비유로 풀어봅니다. → 2편 — 검증이 실제로 잡아낸 것들