AI 코딩 어시스턴트를 도입한 팀이 가장 먼저 경험하는 것은 속도다. 그다음 경험하는 것은 불안이다. 코드가 빠르게 나오는데, 그게 진짜 맞는 코드인지 확신할 수 없다는 불안. 이 불안을 '조심하자'는 다짐으로 해결하려는 팀은 결국 실패한다. 검증은 의지가 아니라 구조의 문제다.
최근 커뮤니티에서 주목할 만한 세 가지 실전 사례가 나왔다. Claude Code에 SlopScan을 연동한 훅 구현, GitHub PR에 AI 기반 취약점 탐지를 자동화한 NeuralGuard 설계, 그리고 AI가 생성한 테스트가 왜 '통과'와 '정확'을 혼동하게 만드는지에 대한 날카로운 분석. 각각 다른 문제를 다루는 것 같지만, 사실 이 세 가지는 하나의 파이프라인을 구성한다. 패키지 신뢰 검증 → 코드 취약점 탐지 → 테스트 신뢰성 재정의, 이 순서가 AI-First 팀이 설계해야 할 품질 관리의 실제 레이어다.
1단계: 패키지를 설치하기 전에 막아라
LLM이 코드를 생성할 때 존재하지 않는 패키지 이름을 참조하는 비율이 약 20%에 달한다는 연구 결과가 있다. 더 무서운 건 그다음이다. 공격자들이 LLM이 반복적으로 환각하는 패키지 이름—같은 모델을 여러 번 실행했을 때 약 43%가 동일한 이름을 생성한다—을 미리 실제 레지스트리에 선점 등록해 악성 페이로드를 심는다. 이를 '슬롭스쿼팅(slopsquatting)'이라고 부른다.
dev.to에 공개된 SlopScan + Claude Code 훅 구현 사례는 이 문제를 구조적으로 막는 방법을 보여준다. 핵심은 스킬과 훅의 차이를 정확히 이해하는 것이다. 스킬(SKILL.md)은 AI가 '기억해서' 사용하는 문서다. 하지만 AI가 매번 기억한다는 보장은 없다. 반면 PreToolUse 훅은 Claude Code가 Bash 명령을 실행하기 전에 결정론적으로 실행되는 쉘 스크립트다. 모델의 판단과 무관하게 시스템이 항상 개입한다.
구현 방식은 명확하다. npm install, pip install, uv add 등 패키지 매니저 명령을 감지하면, 설치 전에 SlopScan API를 호출해 SAFE/CAUTION/SUSPICIOUS/DANGEROUS 네 단계로 위험도를 평가한다. DANGEROUS이거나 레지스트리에 존재하지 않는 패키지라면 즉시 차단(deny), SUSPICIOUS이면 사용자에게 확인을 요청(ask), 그 외엔 통과(allow). 이 로직은 팀 전체 세션에 예외 없이 적용된다. "AI가 깜빡했다"는 상황 자체가 설계 수준에서 차단된다.
2단계: PR 단계에서 취약점을 자동으로 잡아라
패키지를 검증했다고 끝이 아니다. AI가 생성한 코드 자체에 SQL Injection, XSS, Command Injection 같은 보안 취약점이 포함될 수 있다. NeuralGuard 프로젝트는 이 문제를 PR 자동화로 해결한다. CodeBERT 기반 취약점 분류기를 학습시키고, Claude를 '세컨드 오피니언'으로 활용해 잠재적 취약점을 분석한 뒤, GitHub Actions를 통해 PR에 자동으로 코멘트를 달거나 머지를 차단한다.
이 접근법이 흥미로운 이유는 단일 모델에만 의존하지 않는다는 점이다. 학습된 분류기가 1차 필터 역할을 하고, LLM이 컨텍스트를 고려한 분석을 추가한다. 두 단계를 거치면 단순 패턴 매칭의 한계와 LLM의 환각 리스크를 동시에 보완할 수 있다. 중요한 건 이게 코드 리뷰 도구를 '설치'하는 이야기가 아니라, PR 워크플로우 자체에 검증 로직을 내장하는 설계 이야기라는 점이다.
3단계: 테스트가 통과했다고 믿지 마라
여기가 가장 철학적이면서 가장 실용적인 레이어다. Raghu Bharadwaj가 dev.to에서 꺼낸 핵심은 1970년 Dijkstra의 명제로 시작한다. "테스트는 버그의 존재를 보여줄 수 있지만, 부재를 증명할 수는 없다." 테스트가 통과했다는 건 '이번에 찾지 못했다'는 뜻이지, 코드가 옳다는 뜻이 아니다.
AI 코딩 어시스턴트는 이 격차를 더 위험하게 만든다. AI는 코드와 테스트를 동시에 생성하는데, 둘 다 같은 방향으로 틀릴 수 있다. 코드가 처리하는 케이스를 테스트가 검증하고, 테스트가 확인하는 케이스를 코드가 통과한다. 표면적으로 완성된 것처럼 보이지만, 실제 엣지 케이스는 아무도 건드리지 않은 채 프로덕션으로 넘어간다. 초록 불은 정확성의 증거가 아니라, 아직 실패를 찾지 못했다는 신호다.
대응 전략은 태도의 전환이다. AI가 코드와 테스트를 건네줬을 때, 그걸 리뷰의 끝이 아니라 시작으로 봐야 한다. 함수가 무엇을 받았을 때 깨지는지 물어보고 그 케이스를 추가하라. 빈 입력, 경계값, 동시 접근, 오류 경로를 테스트하라. AI가 생각하지 않은 케이스를 찾는 능력이 AI 시대에 개발자가 가진 희소 자산이다.
세 레이어를 하나의 파이프라인으로
이 세 단계는 선택지가 아니라 순서다. 패키지 신뢰 검증이 없으면 악성 의존성이 코드베이스에 들어온다. PR 단계 취약점 탐지가 없으면 AI 생성 코드의 보안 결함이 머지된다. 테스트 신뢰성 재정의가 없으면 초록 불을 보고 안심한 팀이 프로덕션 버그를 맞는다. 각 레이어는 앞 레이어가 놓친 것을 잡는다.
지금 팀에 AI 코딩 어시스턴트를 도입했다면, 이 세 레이어 중 어디까지 설계했는지 물어봐야 한다. 도구를 쓰는 속도는 팀이 결정하지만, 그 코드가 프로덕션에서 신뢰받을 수 있는지는 구조가 결정한다. AI가 빠를수록 검증 파이프라인의 설계는 더 인간의 몫이 된다.