2026 AI 코드 감사 체크리스트 (무료 템플릿)

AI 생성 코드 감사 체크리스트는 여섯 섹션으로 구성됩니다. AI가 작성한 코드와 실행 위치의 인벤토리, 정적 분석(SAST), 인증과 입력 검증의 수동 점검, 존재하지 않는 패키지를 잡아내는 의존성 감사, 원래 요구사항에 대한 비즈니스 로직 테스트, 그리고 돈·신원·개인정보를 다루는 경로의 시니어 리뷰입니다. 아래에 전체 체크리스트, 2026년에 이것이 중요해진 이유, 복사해 쓸 수 있는 무료 템플릿을 정리했습니다.

AI 생성 코드에 별도의 감사가 필요한 이유

Cursor, Claude Code, Copilot, Codex가 만든 코드는 완성된 것처럼 보입니다. 컴파일되고, 모델이 작성한 테스트는 통과하고, 풀 리퀘스트도 잘 읽힙니다. MetaCTO가 2026년 7월에 낸 AI 생성 코드 리뷰 기준 가이드는 이것을 "리뷰의 함정"이라고 부릅니다. 요구사항을 빠뜨리고, 없는 API를 지어내고, 권한 검사를 건너뛴 그럴듯한 코드가 스타일만 보던 리뷰를 그대로 통과하는 것입니다.

수치는 벤더의 과장이 아닙니다. Veracode의 2025 GenAI Code Security 보고서는 엄선한 코딩 과제 80개를 100개 이상의 언어 모델에 풀게 했고, 45퍼센트의 사례에서 보안 취약점이 들어갔다고 밝혔습니다. Java는 70퍼센트 이상 실패했고, Python·C#·JavaScript는 38~45퍼센트였습니다. 크로스 사이트 스크립팅은 86퍼센트, 로그 인젝션은 88퍼센트의 사례에서 막히지 않았습니다.

의존성은 더 새로운 문제입니다. Spracklen 등이 발표한 USENIX Security 2025 연구는 16개 모델로 약 57만 6,000개의 생성 코드 샘플을 검사했고, 추천된 패키지의 19.7퍼센트가 존재하지 않는다는 사실을 발견했습니다. 공격자들은 이제 그 지어낸 이름을 등록하는데, 이를 슬롭스쿼팅이라고 부릅니다. 기존 리뷰는 패키지가 실재하는지 확인한 적이 없습니다. 최근까지는 항상 실재했기 때문입니다.

따라서 AI 코드 감사는 일반 리뷰를 더 꼼꼼히 하는 것이 아닙니다. 사람이 쓴 코드에는 없던 점검을 추가하고, 그럴듯해 보이는 실수가 가장 비싼 곳으로 사람의 노력을 옮기는 일입니다.

2026년의 세 가지 동인

바이브 코딩으로 만든 MVP가 고객에게 도달하고 있다. 창업자들이 에이전트가 대부분 만든 제품을, 종종 한 사람이 몇 주 만에 출시합니다. 감사는 누군가 그 코드를 전체로 읽는 첫 번째 순간입니다. 이런 코드베이스에서 찾은 것을 공개하는 업체들은 같은 패턴을 보고합니다. UI에서는 보호되지만 API에서는 보호되지 않는 관리자 화면, 속도 제한 없음, 행 수준 보안의 부재나 잘못된 설정, 저장소 안의 시크릿입니다.

SOC 2 실사. 변경 관리 기준(AICPA Trust Services Criteria의 CC8)에서 감사인의 질문은 모든 중요한 변경이 프로덕션 전에 검토·승인·테스트되었는가입니다. SOC 2도 ISO 27001도 "코드 리뷰"를 통제로 명시하지 않지만, 둘 다 변경 관리가 시행되고 검증 가능하기를 기대합니다. 에이전트가 쓰고 프롬프트를 입력한 사람이 승인한 풀 리퀘스트는 약한 답입니다. 검토자 이름이 적힌 문서화된 감사는 강한 답입니다.

EU AI법. 범용 AI 모델 의무는 2025년 8월 2일부터 적용되었고, 법 자체는 2026년 8월 2일에 전반적으로 적용되기 시작했습니다. AI 옴니버스(규정 (EU) 2026/1744, 2026년 7월 27일 발효)는 부속서 III의 독립형 고위험 의무를 2027년 12월 2일로, 내장 제품 의무를 2028년 8월 2일로 미뤘습니다. 고용, 교육, 신용, 핵심 인프라 분야에 판매한다면 "에이전트가 썼고 우리는 확인하지 않았다"는 기술 문서에 쓸 수 있는 답이 아닙니다.

체크리스트: 섹션별 정리

인쇄하거나 코드 감사 체크리스트 템플릿을 워크스페이스에 복사하세요. 각 항목을 체크하고, 증거(스캔 결과, 테스트, 커밋 링크)를 기록하고, 확인한 사람의 이름을 적습니다.

1. 인벤토리와 아키텍처 맵

범위에 포함된 모든 저장소, 서비스, 예약 작업, 인프라 정의를 나열한다.
어떤 파일이나 모듈이 AI 생성, AI 보조, 수작업인지 표시한다. git blame과 커밋 메시지로 대개 알 수 있다. 팀이 모른다면 보고서에 그렇게 적는다.
요청 경로를 그린다: 진입점, 인증 계층, 데이터 저장소, 서드파티 호출, 백그라운드 워커.
런타임 버전과 배포 대상을 기록한다.
개인정보, 결제 정보, 자격 증명이 저장되거나 지나가는 모든 위치를 나열한다.

이 섹션이 없으면 나머지 감사는 무작위 샘플링이 됩니다.

2. 정적 분석(SAST)과 시크릿 스캔

전체 코드베이스에 SAST 도구(Semgrep, CodeQL, SonarQube 또는 언어별 도구)를 실행하고 원본 출력을 보관한다.
시크릿 스캐너(gitleaks, trufflehog 또는 호스팅 제공자의 내장 스캔)를 HEAD만이 아니라 전체 git 이력에 실행한다.
발견 항목을 참양성, 거짓양성, 수용된 위험으로 분류하고 각각 한 줄의 이유를 적는다.
모델이 자주 놓치는 약점을 수동으로 확인한다: 모든 템플릿과 API 응답의 출력 인코딩(XSS), 로그 문에 도달하는 사용자 입력(로그 인젝션).
빌드를 통과시키려고 에이전트가 CI의 타입 검사나 린트 규칙을 느슨하게 만들지 않았는지 확인한다.

3. 인증, 권한, 입력 검증

모든 보호된 라우트는 UI만이 아니라 서버에서 신원을 확인한다.
모든 객체 단위 접근(id 기준)은 호출자가 그 객체를 소유하거나 볼 수 있는지 확인한다.
관리자 기능은 역할로 제한되며, 역할은 요청 본문이 아니라 세션에서 읽는다.
세션과 토큰은 만료되고, 권한 변경 시 교체되며, HttpOnly와 Secure 플래그로 저장된다.
비밀번호는 현행 해시(Argon2id, scrypt, bcrypt)를 쓰고 자체 암호화는 쓰지 않는다.
모든 입력은 경계에서 스키마(Zod, Pydantic, JSON Schema)로 검증되고 데이터베이스 접근은 매개변수화되어 있다.
로그인, 가입, 비밀번호 재설정, 이메일이나 SMS를 보내는 모든 엔드포인트에 속도 제한이 있다.
상태를 바꾸는 브라우저 요청에 CSRF 보호가 있다.

바이브 코딩 앱이 가장 자주 실패하는 곳이 여기이며, 모델의 출력이 가장 그럴듯해 보이는 곳도 여기입니다. 이 파일들은 한 줄씩 읽으세요.

4. 의존성 감사

락파일의 모든 패키지가 정확히 그 이름으로 공개 레지스트리에 존재하고 그럴듯한 이력(공개 기간, 메인테이너, 다운로드 수)을 가진다.
AI 도구가 처음 추가한 패키지는 사람이 레지스트리 페이지에서 확인했다.
소프트웨어 구성 분석 도구(npm audit, pip-audit, OSV-Scanner, Snyk, Dependabot)를 실행하고 미해결 권고를 기록한다.
라이선스가 배포 방식과 호환된다(클로즈드 소스 SaaS의 GPL에 주의).
버전이 고정되어 있고 락파일이 커밋되어 있다.

5. 비즈니스 로직과 요구사항 테스트

코드가 충족해야 했던 요구사항을 적는다. 프롬프트에만 존재한다면 프롬프트 이력에서 복원해 베이스라인으로 동결한다.
각 요구사항마다 그것을 증명하는 테스트나 수동 점검을 명시한다. 빈틈은 발견 항목이다.
모델이 건너뛰기 쉬운 엣지 케이스를 테스트한다: 빈 목록, 중복 제출, 동시 업데이트, 시간대, 통화 반올림, 다단계 작업의 부분 실패.
에이전트가 작성한 테스트가 함수가 예외 없이 반환되는지만이 아니라 동작을 검증하는지 확인한다.
깨끗한 환경에서 애플리케이션을 엔드투엔드로 실행하고 돈의 흐름을 따라간다: 결제, 수령, 환불, 청구.

6. 시니어 리뷰와 서명

코드를 작성하지 않은 시니어 엔지니어가 레드 리스트의 모든 파일을 읽는다: 인증, 결제, 개인정보, 마이그레이션, 공개 API 표면, 인프라.
각 발견 항목에 심각도, 증거, 담당자, 목표 날짜가 있다.
검토자는 직접 확인한 것과 샘플링한 것을 기록한다.
이름이 명시된 사람이 날짜와 감사한 커밋 해시와 함께 보고서에 서명한다.

사용할 심각도 척도

심각도	정의	수정 기한
Critical	지금 악용 가능: 인증 우회, 노출된 시크릿, 공개 라우트의 SQL 인젝션, 결제 로직 오류	다음 배포 전
High	전제 조건이 있으면 악용 가능하거나, 핵심 흐름에서 요구사항이 조용히 미충족	다음 릴리스
Medium	심층 방어 공백, 고정되지 않았거나 오래된 의존성에 알려진 권고, 저가치 라우트의 속도 제한 누락	30일 이내
Low	스타일, 데드 코드, 차단하지 않는 린트 발견, 문서	백로그

척도는 짧게 유지하세요. 모두가 쓰는 4단계가 아무도 동의하지 않는 10단계보다 낫습니다.

공개된 프레임워크 비교

2026년 10월 기준으로 가장 많이 인용되는 공개 구조 두 가지는 다음과 같습니다.

프레임워크	형태	더해주는 것	부족한 곳
SolGuruz, "How to Audit AI-Generated Code in 2026"	5단계: 인벤토리와 아키텍처 매핑, SAST 스캔, 비즈니스 로직 테스트, 의존성 감사, 시니어 전문가 리뷰. 저자들은 체크리스트가 아니라 프레임워크라고 부른다	인벤토리를 처음에, 시니어 리뷰를 마지막에 두어 유료 감사가 실제로 진행되는 방식과 맞는다	코드가 만들어진 근거인 요구사항을 복원하는 일에 대해서는 거의 말하지 않는다
MetaCTO, "Establishing Code Review Standards for AI-Generated Code"(2026년 7월)	각각 담당자가 지정된 10개의 머지 전 점검과 녹색·노란색·빨간색 위험 레인. AI 리뷰어는 조언할 수 있지만 빨간 레인 변경을 승인할 수 없다	책임 소재와 PR에서 AI 관여를 공개하는 것에 대한 가장 좋은 처리	지속적인 리뷰를 위해 쓰였고, 기존 코드베이스의 일회성 감사용은 아니다
이 체크리스트	6개 섹션, 인쇄 가능, 심각도 척도, 서명	요구사항 베이스라인 단계와 EU AI법·SOC 2 증거 관점을 추가	침투 테스트를 대체하지 않는다

우리의 6개 섹션은 SolGuruz의 순서를 따르고, 코드의 프롬프트를 입력한 사람이 유일한 승인자가 될 수 없다는 규칙을 MetaCTO에서 빌려왔습니다.

5단계로 감사 진행하기

범위 설정과 동결. 저장소, 커밋 해시, 요구사항 베이스라인을 합의한다. 보고서에 서명하기 전까지 감사 대상 브랜치에는 아무것도 머지하지 않는다.
자동화 먼저. 첫날에 SAST, 시크릿 스캔, 의존성 스캔을 실행해 사람은 발견이 아니라 분류에 시간을 쓴다.
레드 리스트 읽기. 인증, 결제, 개인정보, 마이그레이션, 공개 API, 인프라. 작성하지 않은 사람이 한 줄씩 읽는다.
요구사항 테스트. 동결된 각 요구사항을 테스트나 수동 점검에 대응시킨다. 빠진 것을 기록한다.
작성, 서명, 추적. 보고서 하나, 심각도 표 하나, 발견 항목당 담당자 한 명, 수정이 완료될 때까지 보이는 트래커 하나.

2만 줄 코드베이스를 가진 3인 팀이라면 근무일 기준 일주일을 잡으세요. 1~~2단계에 하루, 3단계에 2~~3일, 4단계와 5단계에 각각 하루입니다.

Atrix가 맞는 곳과 맞지 않는 곳

Atrix AI는 소스 코드를 스캔하지 않고, 정적 분석을 실행하지 않으며, 취약점을 찾지 않습니다. 에이전트가 하는 일은 요구사항 감사입니다. PRD 페이지나 Develop 실행에서 요구사항 베이스라인을 동결하면, 감사는 어떤 요구사항이 계획되었거나 출시된 작업으로 충족되는지, 어떤 것이 벗어났는지, 어떤 것에 담당자가 없는지 보고합니다. 이것은 이 체크리스트의 섹션 5에 해당하고 그 외에는 해당하지 않습니다. 코드 감사 기능 페이지에 그 경계가 명시되어 있습니다.

사람이 하는 코드 감사는 별도의 서비스입니다. 제품 뒤에 있는 에이전시 Atrix Digital은 사람이 코드를 읽는 코드 감사를 수행하며, 섹션 1~4와 6을 다룹니다. Atrix 안에서는 발견 항목이 사이클의 이슈가 되고, 보고서는 고객용 공유 링크가 있는 페이지로 보관되며, 체크리스트 템플릿은 체크해 나가는 페이지 데이터베이스입니다. 우리가 자체 감사에서 쓰는 구성이 바로 이것입니다.

자주 묻는 질문

AI 코드 감사란 무엇인가요?

주로 AI 도구가 작성한 코드에 대한 구조화된 검토로, 인벤토리, 정적 분석, 인증과 입력 검증, 의존성, 비즈니스 로직 테스트, 시니어 리뷰를 다루며, 발견 항목은 심각도로 분류되고 이름이 명시된 검토자가 서명합니다. 존재하지 않는 패키지와 모델이 조용히 빠뜨린 요구사항에 대한 점검이 추가됩니다.

AI 생성 코드 감사는 일반 코드 리뷰와 어떻게 다른가요?

세 가지가 달라집니다. 의존성이 실재하고 주장하는 그대로인지 검증합니다. 모델이 약간 다른 문제를 풀었을 수 있으므로 프롬프트에서 요구사항을 복원해 그에 대해 테스트합니다. 그리고 Veracode의 2025년 테스트에서 모델이 가장 자주 실패하는 것으로 나타난 인증, 결제, 데이터 경로로 사람의 주의를 옮깁니다.

AI 코드 감사에는 시간이 얼마나 걸리나요?

서비스 한두 개에 2만 줄 미만인 코드베이스라면 시니어 엔지니어 한 명이 약 근무일 일주일입니다. 더 큰 코드베이스는 전체 줄 수가 아니라 레드 리스트의 크기에 따라 늘어납니다.

SOC 2를 위해 감사가 필요한가요?

SOC 2는 그 이름의 감사를 요구하지 않지만, 변경 관리 기준은 변경이 프로덕션 전에 작성자가 아닌 사람에 의해 검토·승인·테스트되었다는 증거를 기대합니다. 서명된 감사 보고서와 강제된 풀 리퀘스트 리뷰는 강한 증거입니다. 1인 창업자가 자기 에이전트의 출력을 승인하는 것은 증거가 아닙니다.

EU AI법은 AI 생성 코드 감사를 요구하나요?

직접적으로는 아닙니다. 이 법은 AI 시스템을 코드가 작성된 방식이 아니라 용도에 따라 규제합니다. 하지만 제품이 부속서 III의 고위험 시스템이라면, 2027년 12월 2일부터 적용되는 기술 문서와 위험 관리 의무는 코드가 어떻게 검토되고 테스트되었는지 보여줄 수 있을 때 훨씬 충족하기 쉽습니다.

Atrix AI가 제 코드를 감사할 수 있나요?

아니요. Atrix AI는 동결된 베이스라인에 대해 요구사항을 감사하며, 소스 코드를 읽거나 스캔하지 않습니다. 사람이 하는 코드 감사는 에이전시 Atrix Digital의 서비스를 이용하고, 발견 항목은 Atrix에서 이슈로 추적하세요.

다음 단계

코드 감사 체크리스트 템플릿을 페이지에 복사하고, 요구사항 베이스라인을 동결한 뒤, 여섯 섹션을 순서대로 진행하세요. 직접 작성하지 않은 코드베이스를 감사한다면, 관련 글 AI 생성 코드를 출시 전에 감사하는 방법에서 베이스라인 단계를 더 자세히 다룹니다.

출처

2026년 10월에 확인한 사실: Veracode 2025 GenAI Code Security 보고서 보도자료, MetaCTO, Establishing Code Review Standards for AI-Generated Code, SolGuruz, How to Audit AI-Generated Code in 2026, 유럽연합 집행위원회, AI법 규제 프레임워크와 일정, Spracklen 등의 패키지 환각 연구, Xygeni 요약, AICPA Trust Services Criteria.

2026년 AI 생성 코드 감사 체크리스트: 6개 섹션, 인쇄 가능, 무료 템플릿 포함