<h1>AI가 만든 소프트웨어, 어떻게 믿을까 (2편) — 검증이 실제로 잡아낸 것들</h1>

결론부터: 1편에서 "AI를 안 믿는 3겹 구조"를 이야기했습니다. 이번엔 그 구조가 실제로 무엇을 잡아냈는지입니다. 검증 과정에서 걸린 문제는 기록상 60건이 넘는데, 그중 조용히 자물쇠를 바꿔치기하던 코드, 철거 중인 방에 들어간 청소부 같은 버그 세 편을 비유로 풀어봅니다. 셋 다 실제 기록에 남은 사건입니다.

지난 편 → 1편 — 우리는 AI를 믿지 않기로 했습니다

사례 1 — 조용한 자물쇠 바꿔치기

이런 시공업자를 상상해 보세요. "국산 자물쇠로 채워 주세요"라고 주문했는데, 마침 재고가 없자 말없이 다른 자물쇠를 채워 놓는 겁니다. 문은 잠기니까 겉보기엔 아무 문제가 없습니다. 주문한 사람은 국산 자물쇠라고 믿고 살죠.

파일 암호화 기능에서 정확히 이런 동작이 발견됐습니다. 설정 파일에 암호화 방식을 잘못 적으면(오타 등), 프로그램이 에러를 내는 대신 조용히 기본 방식(AES)으로 바꿔서 암호화했어요. 암호화 자체는 되고 있으니 어떤 정상 동작 테스트도 실패하지 않습니다. 이걸 검사역 AI가 잡았습니다.

수정 방향이 핵심입니다. "몰래 다른 걸로 해주는 친절"을 금지하고, 주문과 다르면 프로그램이 아예 기동을 거부하고 즉시 알리도록 바꿨습니다. 시작 시점에 시끄럽게 실패하는 것이, 몇 달을 조용히 틀리게 도는 것보다 백배 낫기 때문이에요.

막은 사고: 규정상 특정 암호 방식이 필수인 엄격한 환경에서, 담당자는 그 방식을 쓴다고 믿는데 실제로는 다른 방식으로 저장되는 규정 위반 상태가 장기간 지속될 뻔했습니다. 파일이 쌓인 뒤에 발견되면 전량을 다시 암호화해야 하는 유형의 사고예요.

사례 2 — 딛고 선 사다리를 치워버리다

높은 곳에서 사다리를 딛고 일하는 사람이 있는데, 다른 사람이 "이제 정리하자"며 그 사다리를 치워버리면 어떻게 될까요. 딛고 있던 발판이 사라져 그대로 추락합니다.

프로그램에도 똑같은 상황이 있어요. 프로그램을 종료하면서 내부 자원을 하나씩 정리(사다리 치우기)하는데, 아직 끝나지 않은 다른 작업이 방금 치워진 그 자원을 딛으려는 경우입니다. 한 언어용 연결 부품을 검증하던 중, 종료가 진행되는 동안 다른 작업이 이미 정리된 내부 자원을 건드리면 프로그램 전체가 통째로 죽을 수 있다는 게 발견됐습니다. 수정은 간단한 원칙이었어요 — "사다리 위에 누가 있는 동안엔 아무도 못 치우게." 종료가 시작되면 다른 작업이 그 자원에 접근하지 못하도록 잠금을 걸어, 아직 쓰는 중이면 정리를 미루게 했습니다.

막은 사고: 이런 문제의 고약한 점은 매번이 아니라 가끔, 그것도 특정 실사용 환경에서만 터진다는 겁니다. "종료 버튼을 눌렀는데 가끔 프로그램이 죽어요" 같은 신고는 재현도 추적도 극히 어렵습니다. 프로그램 종료는 실제 사용에서 반드시 일어나는 동작이므로, 배포 전에 이 유형을 차단한 것은 배포 후의 긴 추적 비용을 통째로 지운 것과 같아요.

사례 3 — 한 사람의 건강검진이 가족의 같은 병을 찾아내다

이 소프트웨어는 네 가지 프로그래밍 언어(C++, Python, C#, Java)에서 쓸 수 있도록 언어별 연결 부품을 각각 만들었고, 언어마다 검증 공정을 처음부터 다시 돌렸습니다. 비용이 드는 방식이지만, 그 비용이 수익으로 돌아온 사건이 있어요.

가장 나중에 만든 Java용 부품을 검증하던 중, 검사역 AI가 특정한 불완전 문자(깨진 이모지처럼 짝이 맞지 않는 특수 문자)가 들어오면 경고 없이 데이터가 조용히 손상되는 약점을 보고했습니다. 그런데 확인 과정에서 놀라운 게 드러났어요 — 이미 검증을 마치고 출고된 C# 부품에도 똑같은 결함이 잠복해 있었던 겁니다. 한 언어의 건강검진이 다른 언어의 같은 병을 찾아낸 셈이고, 두 언어를 동시에 수정했습니다(조용한 손상 대신 명시적으로 거부하고 알리도록).

이 사례의 의미: 검증을 반복할수록 새 결과물만 좋아지는 게 아니라 이미 만든 것까지 소급해서 좋아지는 구조라는 증거입니다. 데이터가 소리 없이 깨지는 사고는 손상 시점과 발견 시점이 멀어 원인 추적이 가장 어려운 유형인데, 두 언어에서 미리 제거됐어요.

"그 성과 기록도 결국 자기들이 쓴 것 아닌가요?"

맞는 지적입니다. "우리가 60건을 잡았다"는 문장 자체는 자기 보고이고, 자기 보고는 1편 첫머리에서 우리가 스스로 믿지 않겠다고 한 바로 그것이에요.

그래서 이 프로젝트의 모든 수정은 버전 관리 시스템(모든 변경의 일시·내용이 지워지지 않게 남는 장부, 개발 용어로 '커밋')에 기록되어 있고, 잡힌 약점 하나하나는 그 재현 조건이 자동 테스트의 이름으로 저장소에 남아 있습니다. 즉 각 사례는 "우리 말을 믿어 달라"가 아니라, 제3자가 저장소를 열어 변경 기록과 테스트 이름으로 직접 재확인할 수 있는 형태로 존재해요. 확인 경로가 열려 있다는 사실 자체가 신뢰의 근거입니다.

다음 편

여기까지는 "잡아낸 것들"입니다. 그런데 정말 중요한 질문이 남았어요 — 그럼 못 잡은 건 몇 건인가? 다음 편에서는 이 검증 체계가 실제로 놓친 한 건과, 개발을 수행한 AI 본인의 증언까지 공개하겠습니다. → 3편 — 못 잡은 것, 그리고 만든 AI의 증언