AI가 코드를 짤수록 팀이 설계할 검증자 역할

AI가 코드를 짤수록 팀이 설계할 검증자 역할

2,059개 테스트와 '구현자는 검증할 수 없다'는 원칙—AI 코드 품질은 생성 단계가 아니라 검증 설계 단계에서 결정된다.

AI 코드 검증 LLM 코드 리뷰 webernetes 테스트 설계 AI-First 워크플로우 이음새 버그 검증자 역할
광고

AI가 빠르게 짤수록, 검증 설계가 느려지면 안 된다

AI가 코드를 생성하는 속도는 이제 팀의 리뷰 속도를 압도한다. webernetes 프로젝트는 이 긴장을 정면으로 드러낸 사례다. Kubernetes 컨트롤 플레인 일부를 TypeScript로 포팅해 브라우저에서 실행시킨 이 프로젝트는, 2개월 만에 552개 커밋·약 10만 줄 규모로 완성됐다. 코드의 대부분은 Claude가 작성했다. 그런데 이 프로젝트가 주목받는 이유는 AI가 얼마나 빠르게 코드를 뽑아냈는가가 아니다. 그 코드를 어떻게 검증했는가 때문이다.

LLM이 반복한 세 가지 실수

webernetes 개발자는 LLM이 포팅 과정에서 세 가지 패턴의 실수를 반복했다고 명확히 기록했다. 첫째, 축약: LRU 캐시, FIFO 캐시 같은 복잡한 자료구조를 단순 Map으로 대체해 동작 오류를 만들었다. 둘째, 과도한 정리: 원본 Go 코드에 없는 헬퍼 함수를 임의로 추가해 리뷰를 어렵게 하고 미묘한 동작 차이를 만들었다. 셋째, 누락: Go의 table test를 포팅할 때 테스트 케이스를 임의로 빼먹었다.

이 세 가지는 AI가 '틀린' 코드를 생성한 게 아니다. 컴파일은 된다. 문법도 맞다. 그러나 원본의 의도와 동작이 다르다. 이것이 핵심이다.

2,059개 테스트가 설계된 이유

팀이 선택한 검증 전략은 두 축으로 구성됐다. 모든 줄을 사람이 리뷰한다는 원칙과, 실제 클러스터와 동일한 테스트를 실행한다는 원칙이다. 현재 webernetes에는 204개 통합 테스트와 1,855개 단위 테스트가 있다. 통합 테스트는 k3s와 webernetes를 동일한 테스트 코드로 실행해 동작 일치 여부를 비교한다. pnpm test:node는 실제 k3s를 대상으로, pnpm test:browser는 headless 브라우저에서 webernetes를 대상으로 실행된다.

이 구조가 나온 배경은 명확하다. Anthropic이 C 컴파일러를 LLM으로 작성할 때는 비교할 기존 구현이 있었다. Bun이 Rust로 포팅할 때는 100만 줄 이상을 수동 리뷰 없이 병합할 수 있는 대규모 테스트 스위트가 이미 있었다. webernetes에는 그런 기반이 없었다. 검증 기반이 없으면 직접 만들어야 한다는 결론이다.

'구현자는 검증할 수 없다'는 원칙

두 번째 소스는 다른 각도에서 같은 문제를 짚는다. Claude Code로 개인 프로젝트를 개발한 Francisco Ponton은 프롬프트 가드레일이 잘 작동하는 환경에서도 자동화 테스트를 통과한 버그들이 조용히 살아남았다고 보고했다. 클릭해도 아무것도 하지 않는 UI 버튼, 단위 테스트는 통과했지만 DI 컨테이너에 등록이 누락돼 런타임에서 실패하는 다이얼로그, 특정 사용자 역할에서만 조용히 실패하는 인증 경로—이것들은 AI가 '환각'한 코드가 아니다. 각 레이어는 개별적으로 올바르다. 문제는 레이어 사이의 이음새에 있다.

그의 결론은 webernetes와 수렴한다. QA를 세 단계로 분리해야 한다. 자동화 테스트, 구현자가 아닌 검증자의 수동 UI 검토, 그리고 새로 추가되거나 수정된 모든 컨트롤의 스모크 테스트. 특히 '검증자는 구현자가 될 수 없다' 는 원칙이 핵심이다. 확증 편향 때문에 구현한 사람은 성공을 기대하며 클릭하게 돼 있다.

테크 리드가 설계해야 할 검증 레이어

두 사례를 합치면 AI-First 팀이 당장 설계해야 할 검증 구조가 보인다.

첫 번째 레이어: 코드 리뷰는 생략할 수 없다. AI가 생성한 코드도 사람 PR과 동일한 리뷰 규율을 적용해야 한다. webernetes가 '모든 줄을 직접 리뷰했다'는 건 단순한 성실함이 아니라, 검증 책임을 구현 단계에서 명시적으로 부담한 것이다. 리뷰 없이 AI 코드를 머지하면 실수의 책임 소재가 사라진다.

두 번째 레이어: 테스트는 AI 생성 전에 설계한다. LLM은 테스트 케이스를 임의로 빼먹는다. 성공 기준을 먼저 정의하지 않으면 LLM이 어떤 기준을 목표로 작업하는지 팀도 알 수 없다. 테스트 코드도 리뷰 대상이다.

세 번째 레이어: 구현자가 아닌 검증자를 지정한다. AI가 코드 생성량을 늘릴수록, 이음새 버그는 늘어난다. 자동화 테스트의 신호가 가장 약한 지점이 레이어 간 연결부다. 이 지점을 검증하는 역할은 구현과 분리돼야 한다. 혼자 AI와 작업하는 경우에도, 인간이 수행해야 할 마지막 역할은 '검증자'다.

전망: AI 시대에 늘어나는 것은 코드가 아니라 검증 부채다

webernetes는 마지막 주에 여러 에이전트를 병렬로 돌려 포팅과 리뷰를 가속하다가 토큰 비용이 주당 1,811달러까지 치솟았다. 에이전트를 늘려도 수동 리뷰는 결국 필요했다. 작성자의 시간이 프로젝트 전체에서 가장 비싼 항목이었다는 결론은 역설적이지만 구조적이다.

AI가 코드를 생성하는 속도가 올라갈수록 검증 설계의 부재는 빠르게 기술 부채로 전환된다. 이 시점에서 팀이 설계해야 할 것은 더 좋은 프롬프트가 아니라, 더 명확한 검증자 역할 구조다. '테스트가 초록불이면 배포 준비 완료'라는 가정은 AI-First 워크플로우에서 이미 위험한 단순화가 됐다. 이음새를 보는 눈, 그리고 그 이음새를 볼 수 있는 사람을 구조 안에 설계해두는 것—이것이 2025년 AI 코딩 팀의 실질적 차별점이다.

출처

더 많은 AI 트렌드를 Seedora 앱에서 확인하세요