AI 코드 검증의 병목, 명세 기반 거버넌스가 실제로 바꾸는 것
AI 코딩 어시스턴트가 개발 인프라로 자리 잡으면서 소프트웨어 팀의 병목이 '코드 작성'에서 '코드 검증'으로 옮겨갔다는 진단이 나왔다. GAISS 2026에 채택된 한 연구는 이 병목을 명세(specification) 기반 거버넌스로 다루는 접근을 실제로 측정했다. 결론은 "버그를 더 잘 찾는다"가 아니라 "찾은 문제에 근거와 책임 소재를 붙인다"였다.
배경에는 규제가 있다. EU AI Act는 고위험 AI에 리스크 관리, 기록 보존, 효과적 인간 감독을 요구하고, ISO/IEC 42001은 문서화된 AI 관리 체계와 통제 조치, 감사 추적을 요구한다. NIST AI 리스크 관리 프레임워크는 이를 Govern·Map·Measure·Manage 네 축으로 정리한다. 프로덕션 코드에서 AI 생성 비중이 커질수록 "우리가 AI 출력을 꼼꼼히 검토한다"는 선언만으로는 이 요구사항이 어떻게 이행되는지 설명하기 어렵다.
연구가 제안하는 구조는 명세를 프롬프트 장식이 아니라 거버넌스 산출물로 취급하는 것이다. 명세는 세 계층으로 나뉜다. 비즈니스 요구와 규칙을 담은 명세 자체, 컴포넌트와 인터페이스를 정의하는 상위 설계(HLD), 각 메서드가 만족해야 할 불변식을 규정하는 하위 설계(LLD)다. 송금 서비스를 예로 들면 "송금은 계좌 잔액을 음수로 만들 수 없다"는 규칙이 LLD에서 테스트 가능한 불변식으로 구체화되고, transfer_idempotent, transfer_atomic_on_fail, transfer_moves_funds, assets_conserved 같은 이름이 붙는다. 연구에서 쓴 기준선은 핵심 자금 조작, 송금, 이자, 일일 한도, 청구, 계좌 생명주기에 걸쳐 이런 불변식 20개를 정의했다. 리뷰는 이 번호 붙은 목록을 계약 삼아 코드가 이탈했는지 확인한다.
거버넌스 모델은 세 원칙 위에 선다. 산출물 이전에 입력을 통제하고, 승인된 기준선을 명시적·감사 가능하게 유지하며, 기계적 검사가 아니라 핵심 판단 지점에 사람을 배치한다. 여기서 다섯 개의 생명주기 통제점이 나오고 각각 다음 단계로 넘어가는 산출물을 남긴다. 승인된 기준선, 코드 생성 기록, 이탈 로그, 검토 기록이 그것이다. 책임 배분도 분명하다. RACI 모델에서 모델은 코드 생성에 대해 Responsible이지만 Accountable은 결코 아니다. 최종 책임은 사람에게 남는다.
실측 결과는 갈렸다. 연구진은 경력 3~10년의 리뷰어 5명을 대상으로 2×2 교차 설계를 돌렸다. 대상은 다계좌 은행 서비스 두 개로, Java와 Python으로 구현하고 JUnit과 Mockito로 테스트했다. 판정된 실제 이탈은 서비스 A가 11개, B가 10개였다. 기준선이 있을 때와 코드만 볼 때를 비교하니 발견한 이탈 수는 0.525 대 0.518로 통계적 차이가 없었다(p=0.69). 반면 귀속률, 즉 발견한 문제를 특정 요구사항이나 명명된 불변식에 연결할 수 있는 비율은 기준선이 있을 때 81%, 코드만 볼 때 0%였다(p=0.043). 코드만 본 리뷰어들은 "이 동작이 원래 의도된 것인지 판단할 수 없다"는 말을 반복했다고 한다.
같은 설계를 대규모 언어모델로 재현한 결과도 같은 방향이었다. Anthropic Claude Opus 4.8, OpenAI GPT-5.2, DeepSeek V4, Google Gemini 3.1 등이 코드 생성과 자동 리뷰 재현에 투입됐고, 3개 모델로 90회의 기계 리뷰를 돌려 Mann-Whitney U 검정으로 비교했다. 재현율은 두 조건에서 동일했고 귀속률은 기준선 0.67 대 0.00으로 3개 모델 모두 일치했다. 이 0.00은 채점 방식의 문제가 아니라 구조적 결과다. 승인된 계약이 없으면 인용할 요구사항 자체가 없기 때문이다. 연구진은 LLM 코드 리뷰 도구가 사전 스크리닝 단계로는 적합하지만, 거버넌스된 기준선 없이는 문제를 특정 요구사항에 연결하거나 추적 가능한 책임 사슬을 만들 수 없다고 정리한다. 통계 분석에는 Wilcoxon 부호순위 검정, Mann-Whitney U 검정, Fleiss' kappa가 Python 표준 라이브러리로 구현됐다.
코드 생성 쪽에서는 명세를 어떻게 전달하느냐가 더 중요했다. 불변식 20개짜리 은행 서비스 과제에서 한 프롬프트에 "명세를 먼저 쓰고 코드를 써라"고 요구한 방식은 그냥 코드를 요구한 것과 차이가 없었다. 성능이 낮은 모델에서 두 방식의 통과율은 모두 23.8%였다. 반면 SPEC.md를 별도로 생성한 뒤 새 단계에서 그것을 근거로 구현하게 하는 분리 방식은 통과율을 약 45%로 두 배 가까이 올리고 빌드 실패도 절반으로 줄였다. 다만 이 결과는 표본 4개, p≈0.18에 더해 실험군이 모델을 두 번 실행했다는 교란 요인이 있다. 연구진은 추론을 먼저 시키되 명세는 쓰지 않게 한 대조 실험도 붙였다. 단일 함수 과제 10종에서 직접 생성 59%, 추론 후 생성 95%, 명세 후 생성 92%가 나와, 명세 우선의 겉보기 효과 상당 부분이 추론에서 나온 것임을 보였다.
비용은 실재한다. 명세 기반 리뷰는 평균 약 48분, 코드만 보는 리뷰는 약 27분이 걸렸다. 명세와 HLD, LLD를 작성하고 시스템 변화에 맞춰 계속 동기화하는 유지보수 부담도 남는다. 연구진은 이 결과가 리뷰어 5명, 서비스 2개, 도메인 1개에 그친 초기 연구이며 표본 5에서 대응 표본 검정의 최소 p값이 0.043이라는 점을 명시한다. 결론은 "항상 명세를 먼저 쓰라"가 아니라, 이 비용을 언제 지불할지 판단하라는 쪽에 가깝다.