AI가 짠 코드, 검증은 누가 하나

요즘 Dev.to, HN 가릴 것 없이 "AI가 짠 코드를 어떻게 검증할 것인가"를 다루는 글이 동시다발적으로 올라오고 있습니다. 바이브 코딩이 한바탕 지나간 뒤 찾아온 반작용처럼 보여서, 실제 데이터로 얼마나 심각한 문제인지 찾아봤습니다.

📊 숫자로 보는 검증 격차

Sonar의 2026 State of Code Developer Survey(개발자 1,100명 이상 대상)가 이 간극을 정확히 짚었습니다.

정리하면 이렇습니다. 믿지는 않는데(96%), 절반 정도만 매번 확인한다(48%). 코드를 만드는 속도는 AI 덕분에 빨라졌는데, 그걸 검증할 사람의 속도는 그대로라 격차가 벌어지는 구조입니다. Sonar는 이걸 "AI가 일을 없앤 게 아니라 일의 모양을 바꿨을 뿐"이라고 표현했는데, 코드 작성의 비중은 줄고 검증·교정의 비중이 늘었다는 뜻입니다.

흥미로운 건 AI 활용 자체의 만족도예요. 새 코드 작성엔 90%가 AI를 쓰지만 "매우 효과적"이라고 답한 비율은 55%뿐이고, 리팩토링은 72%가 쓰지만 효과적이라는 응답은 43%에 그칩니다. 반면 문서 작성(74%)이나 코드 설명(66%)처럼 구조화된 작업에선 만족도가 훨씬 높았습니다. AI는 "만들기"보다 "설명하기"에 더 강하다는 뜻으로 읽힙니다.

🦀 Rust 프로젝트의 대응: 만들기 금지, 검토는 허용

이 문제에 정면으로 대응한 사례가 있습니다. Rust 컴파일러/libs/types/rustdoc/bootstrap 등 5개 핵심 팀이 최근 rust-lang/rust 저장소에 적용할 LLM 정책을 채택했습니다. 원칙은 한 문장으로 요약됩니다.

"LLM으로 질문에 답하고, 분석하고, 요약하고, 정제하고, 확인하고, 제안하고, 리뷰하는 건 괜찮다. 하지만 만드는(create) 건 안 된다."

허용되는 것

• 코드 분석, 정제, 확인 등 보조 작업 (기계 번역, 버그 발견 시엔 공개 의무)

제한되는 것

• LLM이 생성한 코드 변경 — 사전 협의, 철저한 테스트, 비핵심 영역 한정, 명시적 공개까지 다 갖춰야 함. 사람이 쓴 코드보다 더 높은 기준을 요구

리뷰 봇 관련 규칙

• LLM 리뷰는 어디까지나 참고용, 머지/거부를 결정할 수 없음
• 사람의 리뷰나 셀프 리뷰를 대체할 수 없음
• 리뷰 봇은 별도 계정으로 운영되고, 개별 사용자가 차단할 수 있어야 함

이 정책이 다루는 문제의식은 세 가지입니다. 잘 다듬어진 코드가 더 이상 "충분히 이해하고 썼다"는 신호가 되지 못한다는 것, LLM이 만든 기여가 한정된 리뷰 역량을 잠식한다는 것, 그리고 사람과 기계 사이의 기계적인 복붙이 리뷰어의 시간을 낭비시킨다는 것. 결국 "생성은 쉬워졌지만 신뢰는 저절로 따라오지 않는다"는 같은 문제를 규칙으로 풀어낸 사례입니다.

📚 정리

• AI 코드 생성(42%)과 신뢰(4%만 완전 신뢰) 사이의 격차가 계속 벌어지는 중
• 검증 부담이 동료 리뷰보다 크다는 응답이 38% — 생성 속도를 검증 속도가 못 따라감
• AI는 만들기보다 설명·문서화 같은 구조화된 작업에서 더 신뢰받음
• Rust 프로젝트는 "LLM은 검토 보조까지만, 생성은 사람이 책임"이라는 원칙으로 대응
• 결국 관건은 생성 속도가 아니라 검증을 시스템에 어떻게 박아넣느냐

참고: Sonar 「State of Code Developer Survey」, Rust 「rust-lang/rust is adopting an LLM policy」