AI 코드 감사 보고서 템플릿 (고객이 기대하는 것)

AI 생성 코드 감사 보고서는 일곱 부분으로 구성됩니다. 경영진 요약, 범위와 제외 항목, 감사 방법, 심각도 표, 증거와 수정 방법이 붙은 발견 사항별 항목, 담당자와 날짜가 있는 수정 계획, 그리고 승인(사인오프)입니다. 고객은 발견 사항에 돈을 내지만, 보고서를 평가하는 기준은 당신에게 전화하지 않고도 조치할 수 있는가입니다.

이 글은 AI 생성 코드 감사를 판매하는 에이전시와 스튜디오, 그리고 그 보고서를 받아 읽는 창업자를 위한 것입니다. 아래 구조는 보안 테스터들이 이미 쓰는 공개 관행, 즉 OWASP Web Security Testing Guide의 보고서 장과 CVSS v4.0 심각도 척도를 따르되, 요즘 고객이 실제로 묻는 대상에 맞췄습니다. Cursor, Claude Code, Copilot이 몇 주 만에 대부분 작성했고, 무엇이 들어 있는지 아무도 확신하지 못하는 코드베이스입니다.

AI 코드 감사 보고서는 무엇을 위한 것인가

코드 감사 보고서는 세 가지 일을 동시에 합니다. 비기술 구매자에게 이 제품을 출시하고 판매하고 투자를 받아도 안전한지 알려줍니다. 엔지니어에게 무엇을 어떤 순서로 고쳐야 하는지 정확히 알려줍니다. 그리고 나중의 검토자, 투자자의 기술 자문, SOC 2 감사인이 대조할 수 있는 기록을 남깁니다.

AI 생성 코드가 바꾸는 것은 강조점이지 형식이 아닙니다. 우리가 가장 자주 보는 결함은 OWASP Top 10:2025가 상위에 두는 것과 같습니다. 접근 제어 실패, 보안 설정 오류, 누구도 의도해서 고르지 않은 의존성에서 오는 공급망 문제. 여기에 생성 코드 특유의 문제가 더해집니다. 데모 경로에서는 동작하지만 엣지 케이스에서는 조용히 아무것도 하지 않는 기능, 그리고 기능을 만든 프롬프트에 언급되지 않아 구현되지 않은 요구사항입니다.

그래서 좋은 보고서는 하나가 아니라 두 가지 질문에 답합니다. 코드는 안전한가? 그리고 코드는 요청한 대로 동작하는가? 두 번째는 요구사항 감사이며, 고객은 대개 이것을 요청해야 한다는 사실을 모릅니다.

고객이 기대하는 일곱 가지 섹션

OWASP Web Security Testing Guide는 보안 테스트 보고서에 Introduction, Executive Summary, Findings, Appendices의 네 가지 최상위 섹션을 권장합니다. 널리 쓰이는 Lenny Zeltser의 평가 보고서 템플릿은 같은 내용을 여덟 개로 나눕니다. 우리는 일곱 개를 씁니다. 코드 감사는 코드가 어떻게 공격당할 수 있는지뿐 아니라 코드가 무엇을 하는지도 다뤄야 하기 때문입니다.

섹션	읽는 사람	반드시 담을 내용
1. 경영진 요약	창업자, 투자자, 구매자	한 문단의 결론, 심각도별 건수, 세 가지 주제, 팀이 잘하고 있는 점
2. 범위와 제외 항목	모두	저장소, 커밋, 환경, 날짜, 보지 않은 것과 그 이유
3. 방법	엔지니어, 감사인	도구와 버전, 사용한 체크리스트, 심각도 모델, 생성 코드를 식별한 방법
4. 심각도 표	모두	발견 사항마다 한 줄: ID, 제목, 심각도, 상태
5. 발견 사항	엔지니어	항목마다 하나: 증거, 영향, 재현 방법, 수정 방법
6. 수정 계획	엔지니어링 리드, 고객 측 PM	순서가 정해진 수정, 담당자, 목표일, 검증 단계
7. 승인	양측	누가 감사했고 누가 수락했는지, 재테스트 조건, 비밀 유지

순서가 중요합니다. 경영진은 첫 페이지와 표를 읽습니다. 엔지니어는 곧장 5번 섹션으로 갑니다. 두 그룹 중 하나라도 찾아 헤매야 한다면 그 보고서는 제 역할을 못 한 것입니다.

1. 경영진 요약

마지막에 쓰고 반 페이지로 유지합니다. 무엇을 감사했는지 한 문장으로, 결론을 한 문장으로("두 건의 치명적 발견 사항이 수정되기 전까지 이 애플리케이션은 유료 고객에게 제공할 준비가 되지 않았다"), 그다음 심각도별 건수, 그다음 발견 사항 대부분을 설명하는 두세 가지 주제. 코드베이스가 잘하고 있는 점 하나를 언급하세요. 나머지 내용의 신뢰도가 올라갑니다. 여기에는 페이로드, CVE 번호, 도구 이름을 쓰지 않습니다.

2. 범위와 제외 항목

감사한 각 저장소와 커밋 해시, 브랜치, 접근할 수 있었던 환경, 날짜를 나열합니다. 그다음 제외 항목을 이유와 함께: 서드파티 서비스, 볼 수 없었던 인프라, 범위 밖의 모바일 앱, 고객이 건드리지 말라고 한 것. 포함된 것만 나열한 범위 섹션은 나머지 모든 것에 대한 보증으로 읽힙니다.

AI 생성 코드라면 출처에 대해 한 줄을 추가합니다. 고객이 코드베이스의 어느 정도가 생성되었다고 생각하는지, 어떤 도구로, 병합 전에 사람이 검토했는지. 이를 정확히 검증할 수는 없으므로 고객의 진술로 적습니다.

3. 방법

도구와 버전(SAST 스캐너, 의존성 감사, 시크릿 스캐너), 따른 수동 검토 체크리스트, 심각도 모델을 명시합니다. 검토 중 AI 어시스턴트를 썼다면 그 사실과 무엇을 허용했는지 밝힙니다. 참고한 표준을 적습니다. 카테고리 이름은 OWASP Top 10:2025, 심각도는 CVSS v4.0 정성 척도, 고객이 검증 수준의 이름을 필요로 하면 OWASP ASVS 5.0.0. 나중에 다른 회사를 고용한 고객이 두 보고서를 비교할 수 있어야 합니다.

4. 심각도 표

발견 사항마다 한 줄. 우리는 CVSS v4.0 정성 구간을 씁니다. 공개되어 있고 아무도 이의를 제기하지 않기 때문입니다. Critical은 점수 9.0~~10.0, High는 7.0~~8.9, Medium은 4.0~~6.9, Low는 0.1~~3.9입니다. 취약점은 아니지만 나중에 팀에 비용이 되는 것, 예컨대 테스트 스위트 부재나 관리되지 않는 의존성에는 Informational 수준을 추가합니다.

ID	발견 사항	카테고리	심각도	상태
F-01	인증된 모든 사용자가 `/api/invoices/:id`로 어떤 워크스페이스의 청구서든 읽을 수 있음	Broken Access Control	Critical	미해결
F-02	Stripe 웹훅이 서명되지 않은 이벤트를 수락함	Software or Data Integrity Failures	High	미해결
F-03	알려진 권고가 있는 의존성 14개, 관리자가 없는 의존성 2개	Software Supply Chain Failures	Medium	미해결
F-04	비밀번호 재설정 토큰이 만료되지 않음	Authentication Failures	Medium	미해결
F-05	명세에 있는 내보내기 기능이 구현되지 않음	요구사항 누락	Informational	미해결

위 행은 형식을 보여주는 예시이며 실제 프로젝트의 발견 사항이 아닙니다. 세 번째 열의 카테고리는 OWASP Top 10:2025의 이름이므로 고객이 직접 찾아볼 수 있습니다.

5. 증거가 있는 발견 사항

모든 발견 사항에 매번 같은 항목을 같은 순서로 붙입니다. WSTG가 나열하는 항목은 참조 ID, 제목, 발생 가능성, 영향, 위험 등급, 문제와 악용 방법에 대한 설명, 단계별 수정 안내, 그리고 선택적으로 개발자가 수정을 확인할 수 있는 curl 명령 같은 재현 가능한 산출물입니다. 우리는 AI 생성 코드를 위해 두 항목을 추가합니다.

어디서 왔는가. 파일과 줄, 그리고 같은 패턴이 다른 곳에도 반복되는지. 생성 코드는 자기 실수를 복제합니다. 검사되지 않은 테넌트 ID가 하나라면 보통 다섯입니다.
왜 생겼을 가능성이 높은가. 책임을 묻기 위해서가 아니라, 수정이 코드뿐 아니라 프롬프트나 템플릿에 있는 경우가 많기 때문입니다. "지시문에 멀티테넌시 언급이 없어서 라우트 핸들러가 워크스페이스 범위 없이 생성되었다"는 설명은 팀에게 같은 버그를 더 만들지 않는 방법을 알려줍니다.

증거란 고객의 엔지니어가 실행할 수 있는 것입니다. 스캐너 결과 스크린샷은 증거가 아닙니다. 다른 테넌트의 데이터를 반환한 요청이 증거입니다.

6. 수정 계획

발견 사항을 작업으로 바꿉니다. 심각도순으로, 그다음 하나의 수정이 닫는 다른 발견 사항 수 순으로 정렬합니다. 각각에 고객 측 담당자, 목표일, 검증 단계("부록 B의 2테넌트 스크립트로 F-01 재테스트")를 붙입니다. 지금 수정, 출시 전 수정, 분기 내 수정을 구분합니다. 날짜 없는 계획은 목록일 뿐입니다.

7. 승인

누가 감사를 수행했고 어떤 자격이 있는지, 고객 측 누가 언제 보고서를 수락했는지, 비용에 어떤 재테스트가 포함되는지, 보고서가 언제까지 유효한지(우리는 날짜가 아니라 커밋을 적습니다), 비밀 유지 조건. 고객이 제3자에게 보고서를 보여줄 거라면 어떤 버전인지 명시합니다. 대부분의 구매자에게 필요한 것은 경영진 요약과 심각도 표이지 재현 단계가 아닙니다.

복사해 쓰는 Markdown 뼈대

문서 도구에 붙여 넣고 채우세요. 붙여 넣는 페이지의 제목과 충돌하지 않도록 섹션 라벨은 굵은 글씨로 썼습니다.

**감사 보고서: <제품명>**
버전 1.0 · <날짜> · <회사>가 <고객>을 위해 작성 · 기밀

**1. 경영진 요약**
범위를 한 문장으로. 결론을 한 문장으로.
발견 사항: Critical <n>건, High <n>건, Medium <n>건, Low <n>건, Informational <n>건.
주제: (1) ... (2) ... (3) ...
잘 되고 있는 점: ...

**2. 범위와 제외 항목**
저장소와 커밋: <repo>@<sha>
환경: ...
기간: <시작>부터 <종료>까지
출처(고객 진술): 약 <x>%를 <도구>로 생성, 검토자 ...
범위 밖: ... (이유)

**3. 방법**
도구와 버전: ...
체크리스트: <링크>
심각도 모델: CVSS v4.0 정성 척도 + Informational
검토 중 AI 사용: 예/아니오, 용도 ...

**4. 심각도 표**
| ID | 발견 사항 | 카테고리 (OWASP Top 10:2025) | 심각도 | 상태 |

**5. 발견 사항**
F-01 <제목>
심각도: ... 발생 가능성: ... 영향: ...
위치: <파일:줄>, 그 외 ...
설명: ...
증거(재현 가능): ...
왜 생겼을 가능성이 높은가: ...
수정: 1단계, 2단계 ...
참고: ...

**6. 수정 계획**
| 순서 | 발견 사항 | 담당자 | 목표일 | 검증 |

**7. 승인**
감사자: ... 수락자: ... 날짜: ...
포함된 재테스트: ... 유효한 커밋: ...

호스팅된 코드 감사 체크리스트 템플릿은 검토 쪽 짝입니다. 5번 섹션에 넣을 것이 생기기 전에 차례로 확인하는 목록입니다.

보고서를 만드는 다섯 단계

시작하기 전에 범위를 서면으로 확정합니다. 커밋 해시, 환경, 제외 항목. 고객에게 보내고 답을 받습니다. 보고서의 모든 내용이 여기를 참조합니다.
자동 검사를 먼저 돌리고 선별합니다. SAST, 의존성 감사, 시크릿 스캔. 결과의 대부분은 잡음입니다. 보고서에는 직접 확인한 것만 담고, 스캐너 출력은 부록에 넣습니다.
체크리스트에 따라 수동 검토를 합니다. 인증, 모든 라우트의 권한 부여, 입력 처리, 결제와 웹훅, 데이터 내보내기와 삭제, 백그라운드 작업. AI 생성 코드라면 고객이 갖고 있는 프롬프트, 템플릿, 규칙 파일도 읽으세요. 발견될 패턴을 설명해 줍니다.
코드뿐 아니라 요구사항도 감사합니다. PRD나 원래 브리프를 꺼내 요구사항을 하나씩 나열하고 구현됨, 일부, 누락으로 표시합니다. 생성된 코드베이스는 흔히 해피 패스는 완성되어 있고 프롬프트가 언급하지 않은 것은 모두 비어 있습니다. 누락은 고객이 자기 고객에게 약속한 내용에 따라 Informational 이상으로 심각도 표에 올립니다.
발견 사항, 그다음 계획, 그다음 요약을 씁니다. 이 순서로. 요약은 발견 사항의 압축입니다. 먼저 쓰면 자기 가정의 요약이 됩니다.

Atrix에서 우리가 하는 방식

우리는 보고서를 Word 파일이 아니라 Atrix의 페이지로 씁니다. 보고서와 수정 작업이 나란히 있어야 하기 때문입니다. 페이지에 일곱 섹션을 담고, 수정 계획의 각 행은 사이클 안의 이슈가 되어 담당자, 마감일, 검증 단계를 설명에 가집니다. 엔지니어가 F-01을 닫으면 계획이 갱신되고, 재테스트는 누군가의 받은편지함 알림이 아니라 두 번째 이슈가 됩니다.

고객은 페이지 공유 링크를 받으므로 항상 현재 버전을 읽고 댓글은 하나의 스레드에 모입니다. 버전 기록은 초안과 수락된 보고서 사이에 무엇이 바뀌었는지 보여줍니다. 프로젝트가 끝나면 Markdown 내보내기로 고객이 소유하는 파일을 전달합니다.

분명히 말해 둘 한계가 하나 있습니다. Atrix의 AI 에이전트는 코드를 스캔하지 않습니다. 그 감사 기능은 요구사항 감사로, 고정된 요구사항 기준선에 대해 무엇이 만들어졌는지 확인하고 커버리지와 편차를 보고합니다. 이것이 위의 4단계이며 유용합니다. 2단계와 3단계, 즉 스캐너와 인증·결제 경로를 사람이 읽는 작업은 당신의 SAST 도구와 검토자의 머릿속에서 이뤄집니다. 고객이 소프트웨어가 아니라 우리가 수행하는 사람의 코드 감사를 원한다면 그것은 제품이 아니라 에이전시의 일입니다. 검토에서 AI가 돕는 지점과 오도하는 지점은 AI를 활용한 코드 감사에 대한 우리의 접근을 참고하세요.

자주 묻는 질문

AI 코드 감사 보고서에는 무엇이 들어가야 하나요?

일곱 섹션입니다. 경영진 요약, 범위와 제외 항목, 방법, 심각도 표, 재현 가능한 증거와 수정이 있는 발견 사항별 항목, 담당자와 날짜가 있는 수정 계획, 승인. AI 생성 코드라면 범위에 출처를, 발견 사항에 요구사항 커버리지 확인을 추가합니다.

코드 감사 보고서는 어떤 심각도 척도를 써야 하나요?

고객이 보고서를 비교할 수 있도록 공개된 것을 씁니다. FIRST가 발행한 CVSS v4.0 정성 척도는 9.0~~10.0을 Critical, 7.0~~8.9를 High, 4.0~~6.9를 Medium, 0.1~~3.9를 Low로 평가합니다. 테스트 부재나 미구현 요구사항처럼 취약점이 아닌 발견 사항을 위해 Informational 수준을 추가합니다.

코드 감사 보고서는 얼마나 길어야 하나요?

발견 사항이 필요로 하는 만큼이고 그 이상은 아닙니다. 소규모 SaaS를 2주간 감사하면 보통 반 페이지의 경영진 요약, 한 페이지의 심각도 표, 각각 반 페이지인 발견 사항 항목 5~20개가 나옵니다. 스캐너 출력과 원시 도구 로그는 본문이 아니라 부록에 넣습니다.

고객에게 전체 보고서를 줘야 하나요, 요약만 줘야 하나요?

둘 다, 별도의 문서로 줍니다. 전체 보고서는 고객의 엔지니어링 리드에게 갑니다. 경영진 요약과 심각도 표만 있고 재현 단계가 없는 짧은 버전은 구매자, 투자자, 감사인에게 전달할 수 있는 것입니다.

AI 코드 감사가 침투 테스트를 대체하나요?

아니요. 코드 감사는 소스를 읽고, 침투 테스트는 실행 중인 시스템을 공격합니다. 겹치지만 다른 것을 찾습니다. SOC 2를 요구하는 구매자 대부분은 최근 12개월 이내의 침투 테스트를 요구합니다. 코드 감사는 그 전에 해서 테스트에서 발견되는 것을 줄이는 작업입니다.

AI 코드 감사는 일반 코드 감사와 무엇이 다른가요?

형식은 같습니다. 강조점이 잘못된 접근 제어가 아니라 빠진 접근 제어, 누구도 고르지 않은 의존성, 여러 파일에 반복되는 패턴, 프롬프트가 언급하지 않아 구현되지 않은 요구사항으로 옮겨갑니다. 보고서는 코드의 어느 정도가 생성되었는지 밝히고 보안과 함께 요구사항도 확인해야 합니다.

다음 단계

5번 섹션을 쓰기 전에 호스팅된 코드 감사 체크리스트를 차례로 확인하고, 에이전시가 Atrix에서 고객 작업을 운영하는 방법에서 보고서를 페이지로, 수정을 이슈로, 고객을 공유 링크로 두는 방식을 보세요. 페이지와 화이트보드는 공동 편집, 버전 기록, Markdown 내보내기를 다룹니다.

출처

보고서 구조와 발견 사항 항목: OWASP Web Security Testing Guide, Reporting Structure, Lenny Zeltser의 보안 평가 보고서 템플릿. 심각도 구간: CVSS v4.0 명세, FIRST, 표 22. 카테고리 이름: OWASP Top 10:2025. 검증 수준: OWASP ASVS 5.0.0, 2025년 5월 30일 발행. 모두 2026년 10월에 확인.

AI 코드 감사 보고서 템플릿: 유료 감사가 반드시 납품해야 하는 섹션