전역 코드의 41%가 AI 생성이라는 수치는 이미 낯설지 않다. 일부 조직에서는 90%에 육박한다. 그런데 Stack Overflow의 2025년 설문(49,009명)은 그와 정반대의 수치를 함께 내놓는다. AI 도구를 신뢰한다는 개발자는 29%—1년 전 40%에서 급락했고, '높은 신뢰'를 표명한 비율은 3%에 불과하다. 생성 속도는 올라갔는데 신뢰는 무너졌다. 이 역설이 팀 리드에게 던지는 질문은 하나다. 우리는 AI가 만든 산출물을 어떻게 검증하고 있는가?
이 질문을 세 가지 소스가 서로 다른 각도에서 찌른다. AI 코드 품질 데이터, Claude 홈 디렉토리 삭제 사고, 그리고 Airbnb의 평가 주도 개발(EDD) 방법론. 세 이야기가 가리키는 공통 결론은 '검증은 사후 작업이 아니라 설계 시점의 결정'이라는 것이다. 그리고 그 검증은 단일한 층이 아니다—코드 품질, 실행 권한, 에이전트 추론 경로, 각각 다른 방식의 검증이 필요하다.
1층: 코드 품질 검증—읽지 말고 실행하라
METR의 무작위 대조 실험(arXiv:2507.09089)은 불편한 측정값을 내놓는다. 경험 많은 OSS 개발자 16명이 자신의 코드베이스 이슈 246개를 AI와 함께 풀었을 때, 주관적으로는 20% 빨라졌다고 느꼈지만 실측 결과는 19% 느렸다. AI 제안을 받아들인 비율은 44%에도 못 미쳤다. 병목이 코드 작성에서 코드 검증으로 이동한 것이다.
보안 데이터는 더 냉정하다. Veracode가 100개 이상의 LLM으로 80개 태스크를 테스트한 결과, AI 생성 코드의 45%에서 OWASP Top 10 수준의 취약점이 발견됐다. 인간 작성 코드 대비 2.74배 더 많은 취약점이 포함된다. CodeRabbit의 오픈소스 PR 470건 분석에서도 AI 기여 PR은 1.7배 더 많은 이슈를 만들고, 취약점을 도입할 가능성이 1.88배 높았다. 더 불안한 건 추세다—AI 생성 코드의 문법 통과율은 2023년 이후 50%에서 95%로 올랐지만, 보안 통과율은 45~55%에서 여전히 제자리다. 코드가 읽기 좋아질수록 취약점은 더 잘 숨는다.
이 층에서 팀이 설계해야 할 검증은 '읽는 리뷰'가 아니라 '실행하는 리뷰'다. 구체적으로는 다섯 가지를 기계적으로 강제해야 한다. 첫째, 테스트가 구현을 그대로 흉내 내는지 확인—AI는 로직을 재구현하는 테스트를 잘 만든다. 이런 테스트는 뮤테이션 테스팅으로 걸러낼 수 있다. 둘째, 의존성 버전 검증—Sonatype에 따르면 AI의 패키지 버전 추천 중 27.76%가 실제로 존재하지 않는 버전을 참조한다. 셋째, 삭제 없는 PR 경계—코드만 추가되고 아무것도 제거되지 않은 PR은 잘못된 추상화를 쌓고 있다는 신호다. 넷째, 에러 경로 실제 실행—AI가 생성한 에러 핸들링이 실제로 트리거되지 않는 dead code인 경우가 많다. 다섯째, 인증·암호화·결제·파일시스템 경로는 시니어가 직접 입력부터 신뢰 경계까지 트레이싱한다.
리스크 기반 Tier 시스템을 도입하면 이 검증을 팀 전체에 일관되게 적용할 수 있다. 보일러플레이트·설정·문서는 가볍게 확인하고 넘긴다(Tier 0). 비즈니스 로직·CRUD·테스트는 정상 리뷰에 전체 테스트 수트 실행(Tier 1). 인증·암호화·결제·인프라·동시성은 시니어 전체 리뷰 + SAST + 위협 모델, 절대 자동 머지 금지(Tier 2). hybrid-strict 게이트(Tier 1 이상 자동 승인 없음, Tier 2는 지명된 인간 승인자)를 적용했을 때 결함 탈출률은 4.1%에서 1.7%로 떨어진다는 데이터가 있다. 이 게이트는 명예 시스템이 아니라 기계적으로 강제되어야 한다.
2층: 실행 권한 검증—에이전트가 할 수 있는 것과 해야 하는 것을 구분하라
지난주 레딧 Claude Code 커뮤니티에 한 개발자의 사연이 올라왔다. Claude Opus 5에 시스템 백업을 요청했더니, 에이전트가 백업 디렉토리를 잘못 판단하고 rm -rf를 실행해 사용자 홈 디렉토리 전체를 삭제했다. Windows 환경에서 Unix 스타일 셸을 쓰는 과정에 C:\\Users\\와 /c/Users/를 혼동한 것으로 추정된다. 에이전트는 모든 데이터를 삭제한 뒤 "죄송합니다, 오타였습니다(Sorry, typo)"라고 답했다.
이 사건의 핵심은 모델이 틀렸다는 게 아니다. 에이전트가 파괴적 명령을 확인 없이 실행할 수 있는 권한을 가지고 있었다는 것이다. 유사한 사고는 이미 여러 차례 보고됐다. AI 코딩 플랫폼이 코드 동결 기간 중 운영 DB를 삭제했고, Google 에이전트형 AI가 하드 드라이브 전체를 날렸으며, Anthropic Claude 기반 코딩 도구가 기업 DB를 수 초 만에 삭제하고 백업까지 함께 영향받았다. AI 에이전트가 파일시스템·DB·클라우드 인프라에 직접 접근하는 사례가 늘면서, '실행 권한' 자체가 독립적인 리스크 레이어로 부상하고 있다.
이 층의 검증은 코드 품질과 완전히 다른 설계가 필요하다. 최소 권한 원칙(Principle of Least Privilege)을 에이전트에 적용하는 것이 출발점이다. 구체적으로는 세 가지다. 첫째, 파일 삭제·DB 변경·인프라 수정 같은 파괴적 작업은 에이전트가 직접 실행하지 못하게 하고, 별도 승인 플로우를 거치도록 강제한다. 둘째, 에이전트가 접근할 수 있는 경로와 리소스 범위를 명시적으로 제한한다—Claude Code의 경우 허용 디렉토리와 금지 명령어를 Hooks로 기계적으로 통제할 수 있다. 셋째, 백업은 에이전트가 접근할 수 없는 별도 영역에 보관한다. 원본과 백업이 동시에 삭제되는 시나리오는 설계로 막아야 한다.
여기서 한 가지 짚어야 할 점이 있다. 에이전트 실행 권한 문제는 '도구 품질'의 문제가 아니다. Claude Opus 5가 나쁜 모델이어서 발생한 사고가 아니라, 팀이 에이전트에게 권한을 부여하는 방식을 설계하지 않아서 발생한 구조적 문제다. 에이전트가 강력해질수록, 팀이 설계해야 할 통제 구조는 더 정밀해져야 한다.
3층: 에이전트 추론 검증—최종 답변이 아니라 실행 경로를 평가하라
Airbnb가 공개한 평가 주도 개발(Eval-Driven Development, EDD) 방법론은 이 맥락에서 가장 구조화된 답을 내놓는다. Airbnb가 리뷰 하이라이트·AI 고객 지원·스마트 커뮤니케이션 기능에 LLM을 적용하면서 직면한 문제는 기존 테스트 방식으로는 AI 출력을 검증할 수 없다는 것이었다. 출력이 비결정적이고, '정답'의 기준 자체가 주관적이며, 검색→추론→도구 호출→생성으로 이어지는 각 단계가 독립적으로 실패할 수 있다.
EDD가 기존 TDD와 다른 핵심은 '모든 실패를 사전에 예측하는 대신, 나타나는 실패를 발견하고 명문화하며 지속적으로 검사하는 인프라와 습관을 구축'하는 데 있다. 방법론의 출발점은 단순하다. 프로토타입에 100개 예제를 실행하고 출력을 직접 읽는 것. 모델의 오류를 찾아 유형별로 분류하고, 관찰된 실패를 평가 항목으로 만든다. Airbnb의 지원 정책 AI 어시스턴트 사례에서는 이 과정에서 충실성 실패 15건, 과도한 길이 8건, 과잉 거부 5건, JSON 파싱 오류 3건이 분류됐고, 이것이 평가기 설계의 기반이 됐다.
평가 방식은 세 층으로 구성된다. 결정론적 검사가 첫 번째 필터다—JSON 스키마 유효성, 길이 제한, 형식 규칙 같은 것은 LLM 없이 코드로 처리한다. LLM-as-a-Judge가 두 번째 층이다—더 강한 모델이 세밀하게 설계된 루브릭으로 다른 모델의 출력을 평가한다. 여기서 중요한 것은 보정이다. 보정하지 않은 LLM 심판은 잘못된 확신을 주므로 심판이 없는 것보다 나쁠 수 있다. 나쁜 사례를 포함한 50~100개의 골든 데이터셋을 구성하고, LLM 심판의 판단이 인간 레이블과 80% 후반~90% 수준 이상으로 일치할 때까지 루브릭과 퓨샷 예제를 반복 수정해야 한다. 인간 평가는 기준 데이터 구축, 고위험 영역, 자동 평가기 간 불일치 해결에서 최종 심판 역할을 유지한다.
에이전트 시스템에서는 추가로 실행 추적(execution trace) 검증이 필요하다. 올바른 최종 답변이 나왔더라도, 잘못된 추론 경로나 부정확한 도구 매개변수, 비효율적 실행 경로를 감출 수 있다. Airbnb는 에이전트 실행 추적과 스팬을 관측 가능성 플랫폼에 기록하고, DFS 순회로 재구성해 적절한 시점에 특정 하위 에이전트가 실행됐는지, 올바른 도구가 호출됐는지를 검사한다. 최종 답변만 보는 것은 프로세스가 아니라 결과만 감사하는 것과 같다.
EDD의 다섯 원칙 중 팀 리드가 가장 먼저 챙겨야 할 것은 하나다. 출시 게이트를 사전에 정의하라. 무엇을 최적화할지, 출시 전에 어떤 조건을 충족해야 할지를 먼저 정하지 않으면 평가 전체가 방향을 잃는다. 그리고 올바른 동작에 대한 팀 내 의견이 갈릴 때 최종 판단을 내릴 인간 의사결정자를 지정해야 한다. AI 제품의 성과는 최고의 모델이 아니라 원활한 소통과 명확한 제품 기준에 달려 있다는 것이 Airbnb의 결론이다.
검증은 사후가 아니라 설계 시점의 결정이다
세 층의 검증을 통합해서 보면 하나의 패턴이 보인다. AI 도입 초기에는 '어떤 도구를 쓸 것인가'를 먼저 결정했다. 지금 필요한 결정은 다르다. 코드 품질 층에서는 어떤 리스크 Tier로 어떤 SAST/뮤테이션 테스트를 강제할 것인가. 실행 권한 층에서는 에이전트에게 어떤 작업을 위임하고 어떤 작업은 승인 플로우를 거치게 할 것인가. 에이전트 추론 층에서는 최종 답변 외에 어떤 실행 경로를 평가 항목으로 만들 것인가.
cURL은 AI가 생성한 쓰레기 버그 리포트 때문에 86,000달러 규모의 버그 바운티를 중단했다. 유효 리포트 비율이 15%에서 5%로 떨어지는 데 오래 걸리지 않았다. Ghostty, QEMU, Gentoo, Debian은 AI 기여를 공식 제한했다. 이 반응들은 AI에 대한 반발이 아니라, 검증 없는 AI 산출물이 시스템 전체에 어떤 비용을 만드는지에 대한 반응이다. 팀 리드가 설계해야 할 것은 AI를 쓸지 말지가 아니라, 각 층에서 무엇을 검증할지—그리고 그 검증이 명예 시스템이 아니라 기계적으로 강제되는 구조인지다.