검증 체계가 없으면 AI는 위험하다

이 글의 배경이 되는 이야기는 12화: 새우깡 사건과 13화: 다시는 틀리지 않겠다는 약속에서 읽을 수 있습니다.

이 글을 읽으면 알 수 있는 것

• AI 출력을 “코드 수준에서” 신뢰해도 되는 기준
• 새우깡 사건 이후 프로젝트에 도입된 구체적 규칙들
• “AI가 잘 한다”와 “AI를 신뢰해도 된다” 사이의 간극

문제: AI가 “잘 했습니다”라고 말하면

AI와 함께 코드를 작성하면, AI가 결과를 보고합니다.

“2,434건 매칭 완료. 매칭률 99.5%.”

이 보고를 보고 “잘 됐네”라고 넘긴 적이 있습니다. 그 2,434건이 전부 틀렸다는 것을 나중에야 알게 됐습니다.

AI는 거짓말을 한 것이 아닙니다. 2,434건을 매칭한 것은 사실이고, 전체 매칭률이 99.5%인 것도 사실입니다. 다만 그 매칭이 맞는지는 확인하지 않았을 뿐입니다.

이것은 AI의 결함이라기보다, AI를 사용하는 방식의 결함이었습니다.

AI를 신뢰할 수 있는 경우와 없는 경우

이 프로젝트를 통해 AI 출력의 신뢰도를 경험적으로 분류했습니다.

가장 위험한 것은 **“에러가 나지 않는 실패”**입니다.

코드가 컴파일되지 않으면 즉시 발견됩니다. 테스트가 실패하면 발견됩니다. 하지만 “A 제품의 영양정보를 B 제품에 연결했는데, 프로그램은 정상적으로 끝남” — 이런 종류의 실패는 누군가 결과를 직접 확인하지 않으면 발견되지 않습니다.

새우깡 사건 이후 도입된 규칙들

규칙 1: 데이터 연결 전 교차검증 필수

새로운 방법으로 데이터를 연결하기 전에, 독립된 식별자로 교차검증합니다. 이름으로 연결했다면 품목보고번호로 확인하고, 품목보고번호로 연결했다면 이름으로 확인합니다.

샘플 100건 무작위 추출 → 독립 키로 검증
→ 불일치율 5% 초과 시 → 적용 금지

규칙 2: 매칭 후 전수 자동 검증

매칭을 적용한 후, 자동 검증 커맨드를 실행합니다. 5가지 항목을 전수 확인합니다.

규칙 3: 검증 없는 매칭은 저장하지 않는다

“일단 넣고 나중에 확인”을 금지합니다. 검증을 거치지 않은 매칭 결과는 DB에 반영하지 않습니다.

규칙 4: AI 출력의 “성공” 보고를 액면 그대로 받지 않는다

“2,434건 매칭 완료”라는 보고를 받으면, “그중 맞는 건이 몇 건인가”를 반드시 확인합니다.

프로젝트 규칙으로 명문화

이 규칙들은 머릿속에만 있으면 안 됩니다. 시간이 지나면 잊고, 바쁘면 건너뜁니다.

그래서 프로젝트 설정 파일에 규칙을 기록했습니다. AI가 작업을 시작할 때 이 파일을 읽고, 규칙을 준수하도록 합니다.

데이터 매칭 무결성 규칙:
- FK 연결 전 교차검증 필수 (독립 키 100건 이상)
- 검증 없는 매칭은 커밋하지 않는다
- 오류 발생 시 즉시 보고 (추측 금지)
- 완료 보고 시 증거 제시 (SELECT COUNT 등)

AI에게 이 규칙을 지키게 하는 것이 핵심입니다. “조심하세요”라고 말하는 것보다, “이 규칙을 위반하면 안 됩니다”라고 명시하는 것이 효과적입니다.

갈림길: AI를 믿을 것인가, 의심할 것인가

세 번째를 선택했습니다.

AI가 작성한 코드가 실행되는가 — 이것은 신뢰합니다. 실행 결과가 즉시 나오니까요. AI가 연결한 데이터가 맞는가 — 이것은 검증합니다. 실행 결과만으로는 알 수 없으니까요.

비개발자에게 이것이 더 중요한 이유

개발자는 AI의 코드를 읽고 “이 로직이 맞는가”를 직접 판단할 수 있습니다. 비개발자는 이것이 어렵습니다.

비개발자가 AI를 검증하는 방법은 코드를 읽는 것이 아니라, 결과를 확인하는 것입니다.

• “새우깡의 영양정보가 맞는가?” → 실제 포장지와 비교
• “매칭 건수가 합리적인가?” → 전체 건수 대비 비율 확인
• “어제와 오늘의 결과가 크게 다른가?” → 변화 추이 확인

코드를 모르더라도, 결과의 합리성은 판단할 수 있습니다. 이 판단을 자동화한 것이 검증 시스템이고, 자동화할 수 없는 부분은 사람이 직접 확인합니다.

새우깡 사건은 “결과를 한 번도 직접 확인하지 않았기 때문에” 일어났습니다.

결과

한계

검증 자체도 AI에게 의존합니다. 검증 코드를 AI가 작성했으므로, 검증 코드 자체에 결함이 있을 수 있습니다. 이것은 재귀적인 문제입니다. 완전한 해결은 어렵고, 크로스 리뷰와 수동 샘플 확인으로 보완합니다.

규칙이 있어도 지키지 않으면 소용없습니다. 바쁠 때 “이번만 건너뛰자”는 유혹이 생깁니다. 새우깡 사건의 기록을 프로젝트 문서에 남겨둔 이유는, 이 유혹이 생길 때마다 “그때 무슨 일이 있었는지” 떠올리기 위해서입니다.

한 줄 교훈

AI가 “완료”라고 보고하면, 그것은 “실행이 끝났다”는 뜻이지 “결과가 맞다”는 뜻이 아닙니다. 에러가 나지 않는 실패를 잡으려면, 에러가 아닌 것을 확인하는 체계를 직접 만들어야 합니다.

이 글이 기술 블로그의 마지막 글입니다. 전체 목차는 기술 블로그 목차에서 확인할 수 있습니다.