AI 생성 코드를 배포하기 전에 감사하는 방법: 3인 팀을 위한 5단계 프로세스

AI 생성 코드에 다른 감사가 필요한 이유

AI가 쓴 코드는 사람이 쓴 코드와 다른 패턴으로 실패합니다. 요구사항을 잘못 이해한 사람은 보통 흔적을 남깁니다. 주석, 채팅의 질문, 이상한 변수 이름 같은 것입니다. 에이전트는 자신감 있고 형식이 잘 갖춰진 코드를 만들어내고, 그 코드는 컴파일되고 스스로 작성한 테스트를 통과하면서도 여전히 잘못된 일을 할 수 있습니다.

2026년 10월 기준으로 문제를 보여주는 숫자가 둘 있습니다.

• Veracode의 2025 GenAI Code Security Report(2025년 7월 30일 발행)는 100개가 넘는 대형 언어 모델에 80개의 코딩 과제를 수행시켰고, 생성된 코드의 45%에 보안 취약점이 포함되어 있다는 것을 발견했습니다. 모델은 관련 과제의 86%에서 크로스 사이트 스크립팅을, 88%에서 로그 인젝션을 막지 못했고, Java의 실패율은 70%를 넘었습니다.
• Stack Overflow의 2025 Developer Survey(응답자 49,000명 이상, 2025년 7월 29일 발행)에 따르면 개발자의 80%가 AI 도구를 사용하지만, 정확성에 대한 신뢰는 29%로 떨어졌습니다. 45%가 꼽은 가장 큰 불만은 "거의 맞지만 완전히 맞지는 않은 AI 해결책"이었고, 66%는 거의 맞는 AI 코드를 고치는 데 더 많은 시간을 쓴다고 답했습니다.

따라서 감사해야 할 두 가지 실패 유형은 범위 이탈(요청한 것과 다른 것을 만듦)과 조용한 불안전성(요청한 것을 정보가 새는 방식으로 만듦)입니다. 풀 리퀘스트의 diff 리뷰는 둘 중 어느 것도 확실하게 잡지 못합니다. 리뷰어는 에이전트가 보여주기로 한 코드를, 반쯤 기억나는 요구사항에 대고 읽기 때문입니다.

1단계: 요구사항 베이스라인 동결하기

채팅 기록에만 존재하는 요구사항에 대해 코드를 감사할 수는 없습니다. 감사 전에, 코드가 해야 했던 일을 짧은 선언문의 번호 매긴 목록으로 적고 동결하십시오.

좋은 베이스라인 항목은 이렇게 생겼습니다.

• R-07 로그아웃 상태의 방문자가 /app/*를 열면 /sign-in으로 리디렉션되고, 로그인 후 원래 URL로 돌아온다.
• R-12 인보이스를 결제 완료로 표시할 수 있는 것은 워크스페이스 소유자 또는 관리자뿐이다.
• R-15 Stripe 웹훅 페이로드는 서명이 검증되지 않으면 거부된다.

나쁜 항목은 "인증을 제대로 처리한다"입니다. 실행 중인 제품을 보고 그 항목이 충족되었는지 판단할 수 없다면, 가능해질 때까지 다시 쓰십시오.

Cursor나 Claude Code로 일주일에 걸쳐 만든 기능이라면 베이스라인은 보통 15~40개 항목입니다. PRD, 이슈 설명, 에이전트에게 준 프롬프트에서 끌어오십시오. 그다음 편집을 멈추십시오. 요구사항 베이스라인의 핵심은 고정된 기준점이라는 것이며, 그래야 다음 단계가 협상이 아니라 비교가 됩니다.

Atrix에서는 Develop 실행이 브리프를 요구사항 목록으로 바꾸고, 그것을 제품의 베이스라인으로 동결합니다. Atrix를 쓰지 않는다면 저장소에 커밋한 번호 매긴 Markdown 파일이 같은 역할을 합니다. 중요한 것은 적혀 있고, 번호가 있고, 날짜가 있다는 점입니다.

2단계: 구현과 베이스라인 비교하기

이제 베이스라인을 한 줄씩 훑으며 각 요구사항을 세 가지 상태 중 하나로 표시합니다.

코드만이 아니라 실행 중인 제품을 열어놓고 하십시오. 에이전트는 requireAdmin이라는 함수를 써놓고 한 라우트에서만 호출하지 않는 데 능숙합니다.

특히 찾아야 할 세 가지가 있습니다.

1. 통과시키려고 바꾼 테스트. diff에서 수정된 단언문, 삭제된 테스트 케이스, 새로 추가된 skip이나 only 마커를 찾으십시오. 우리 경험상 이것이 에이전트가 실패한 작업을 닫는 가장 흔한 방법입니다.
2. 에이전트가 재해석한 요구사항. "로그인 후 리디렉션"이 "대시보드로 리디렉션"이 되고, "소유자 또는 관리자"가 "로그인한 아무 멤버"가 됩니다. 코드는 깔끔하고, 틀렸습니다.
3. 아무도 요청하지 않은 추가 동작. 에이전트는 기능을 덧붙입니다. 각각이 검토되지 않은 공격 표면입니다. 베이스라인에 추가해서 검토하거나, 제거하십시오.

이것이 Atrix가 자동화하는 부분입니다. Atrix AI의 요구사항 감사는 동결된 베이스라인을 팀이 워크스페이스에서 계획하고 만든 것과 비교해, 요구사항별 충족률과 이탈을 보고합니다. 한계를 분명히 하겠습니다. 감사하는 것은 요구사항이지 소스 코드가 아닙니다. 저장소를 읽지 않고, 정적 분석을 실행하지 않으며, 취약점을 찾지 않습니다. "우리가 만들겠다고 한 것을 만들었는가"라는 2단계의 질문에 답할 뿐, 3~5단계에는 관여하지 않습니다.

3단계: 저장소 전체에 정적 분석 실행하기

정적 애플리케이션 보안 테스트(SAST)는 가장 저렴한 단계이면서 팀들이 건너뛰는 단계입니다. diff만이 아니라 저장소 전체에 실행하십시오. 에이전트의 변경이 이전에는 안전했던 코드를 새로운 경로로 도달 가능하게 만들 수 있기 때문입니다.

2026년 10월 기준으로, 세 가지 도구가 대부분의 소규모 팀을 커버합니다.

가격은 2026년 10월에 각 공급사의 요금 페이지에서 확인한 것이며 자주 바뀝니다.

스캔은 CI에서 실행해 모든 풀 리퀘스트마다 돌게 하고, 첫 실행 결과는 수동으로 분류하십시오. 처음에는 노이즈가 많을 것으로 예상하십시오. 목표는 깨끗한 기준 상태에 도달해서, 다음에 에이전트가 쓴 변경에서는 새로운 결과만 보이게 하는 것입니다.

SAST가 AI 작성 코드에서 잡아내는 것: 인젝션(SQL, 명령, 로그), 출력 인코딩 누락, 하드코딩된 시크릿, 안전하지 않은 난수, 알려진 취약 의존성. 잡아내지 못하는 것: 한 라우트에서 빠진 인가 검사, 서명되지 않은 페이로드를 신뢰하는 웹훅 핸들러, 클라이언트에서 계산된 가격. 이것들은 4단계의 몫입니다.

4단계: 인증과 결제 경로를 사람이 직접 검토하기

베이스라인을 열어둔 채로 사람이 처음부터 끝까지 읽습니다.

1. 데이터를 변경하는 모든 라우트. 각각에 대해 호출자가 누구이고 무엇을 할 수 있는지 확인하는 줄을 찾으십시오. 그 줄을 찾을 수 없다면, 없는 것입니다.
2. 세션과 토큰 처리. 세션이 어디서 생성되고, 얼마나 유지되며, 로그아웃과 비밀번호 변경 시 어떻게 무효화되는지.
3. 웹훅과 콜백. 파싱 전의 서명 검증. 재시도 시 멱등성.
4. 돈. 가격, 합계, 할인이 어디서 계산되는지. 브라우저에서 계산되고 서버가 신뢰하는 것은 모두 발견 사항입니다.
5. 시크릿과 설정. diff에서 API 키, 연결 문자열, 토큰을 grep하십시오. 에이전트는 사람보다 더 자주 예시 키를 코드에 붙여넣습니다.

기능 규모의 변경이라면 2~4시간을 잡으십시오. 리뷰어는 에이전트에게 프롬프트를 준 사람이어서는 안 됩니다. 작가가 자기 초고를 교정하면 안 되는 것과 같은 이유입니다.

GitHub 연동을 사용하면 이 검토에서 생성한 이슈가 요구사항과 풀 리퀘스트로 연결되므로, "R-12 부분 충족: 관리자는 결제 완료로 표시할 수 있지만 소유자는 못 함"이 담당자가 있는 추적 항목이 되고, 흘러가 버리는 댓글이 되지 않습니다.

5단계: 발견 사항을 기록하고 순서대로 고치기

각 발견 사항을 네 개의 필드를 가진 이슈로 기록합니다. 대응하는 요구사항, 심각도, 파일과 줄, 수정 방법입니다. 이 규모에서 심각도는 단순합니다.

• Critical: 인증되지 않았거나 테넌트를 넘는 데이터 접근, 또는 금액 계산 오류. 배포 전에 수정.
• High: 로그인한 사용자가 있어야 악용 가능한 보안 결함. 같은 스프린트 안에 수정.
• Medium: 사용자가 마주칠 엣지 케이스 누락. 일정에 넣기.
• Low: 스타일, 죽은 코드, 중복 로직. 모아서 처리.

Critical과 High 항목을 현재 사이클에 넣고, 닫히면 감사를 다시 실행하십시오. 두 번째는 베이스라인과 스캔이 이미 있으므로 빠릅니다. 새로 할 일은 바뀐 줄을 다시 읽는 것뿐입니다.

Cursor와 Claude Code로 이 과정을 쉽게 만드는 도구

에이전트가 작업하는 동안 베이스라인을 눈앞에 두고 있으면 감사가 저렴해집니다. 우리가 하는 세 가지입니다.

• 프롬프트만이 아니라 베이스라인을 에이전트에게 주기. Cursor 연동이나 Claude 연동을 쓰면 에이전트가 Atrix의 MCP 서버를 통해 요구사항 페이지와 이슈를 읽을 수 있어, 구현의 기준이 되는 번호 매긴 목록이 감사의 기준이 되는 목록과 같아집니다.
• 풀 리퀘스트에서 매핑을 요구하기. 에이전트 지침에 "이 변경이 구현하는 요구사항 ID를 나열하라"는 규칙을 넣으면 2단계가 수색이 아니라 확인이 됩니다.
• PR을 열기 전에 에이전트가 SAST를 실행하게 하기. Semgrep은 로컬에서 몇 초 만에 돕니다. 에이전트가 결과를 보면 대부분 스스로 고칩니다.

이 중 어느 것도 3단계와 4단계를 대체하지 않습니다. 짧게 만들 뿐입니다.

3인 팀이라면 에이전트로 만든 기능의 첫 전체 감사에 하루 정도 걸립니다. 두 번째는 베이스라인 프로세스와 스캐너가 이미 갖춰져 있어 절반이면 됩니다.

자주 묻는 질문

요구사항 감사와 코드 감사의 차이는 무엇인가요?

요구사항 감사는 만든 것이 만들기로 한 것의 목록과 일치하는지 확인합니다. 요구사항별 충족률과 이탈입니다. 코드 감사는 코드 자체가 올바르고 안전하며 유지보수 가능한지 확인합니다. 정적 분석, 의존성 검토, 민감한 경로를 사람이 읽는 것입니다. AI 생성 코드에는 둘 다 필요하며, 각각 위의 2단계와 3~4단계입니다. Atrix AI는 전자를 합니다. 후자는 SAST와 사람입니다. Atrix의 에이전시 부문인 Atrix Digital은 사람이 수행하는 코드 감사를 서비스로 제공합니다.

AI 도구로 AI 생성 코드를 감사할 수 있나요?

부분적으로는요. 일부는 이제 분류에 모델을 쓰는 SAST 도구들은 패턴 수준의 결함을 잘 잡습니다. 첫 번째 모델의 출력을 두 번째 모델이 검토하면 로직 오류를 일부 잡지만, 인가와 비즈니스 규칙에 관한 사각지대는 첫 번째 모델과 공유합니다. 2026년 10월 기준으로 우리는 AI 리뷰를 4단계 사람 리뷰의 사전 필터로 취급하지, 대체재로 보지 않습니다.

내가 만들지 않은 "바이브 코딩" 앱은 어떻게 감사하나요?

그래도 1단계부터 시작하십시오. 제품 자체를 화면별로 보면서 앱이 해야 할 일을 적고 번호를 매기십시오. 그다음 저장소 전체에 SAST를 돌리고, 데이터나 돈을 변경하는 모든 라우트를 읽으십시오. 요구사항이 한 번도 문서화되지 않았으므로, 직접 만든 코드보다 베이스라인에 시간이 더 걸릴 것으로 예상하십시오.

얼마나 자주 감사해야 하나요?

기능마다, 유료 사용자에게 도달하기 전에 하고, Critical과 High 발견 사항이 닫히면 다시 합니다. 매주 배포하는 팀이라면 매주 짧은 감사, 사이클마다 전체 감사입니다.

소규모 팀은 어떤 SAST 도구를 골라야 하나요?

Semgrep의 Free Edition은 2026년 10월 기준으로 기여자 10명과 비공개 저장소 10개까지 지원하고, 로컬과 CI에서 돌며, 시작하기 가장 쉽습니다. 코드가 GitHub에 있고 이미 Code Security를 결제하고 있다면 CodeQL의 풀 리퀘스트 통합이 마찰이 가장 적은 선택지입니다. 하나를 골라 모든 풀 리퀘스트에서 실행하십시오. 어떤 것을 고르느냐보다 실행하느냐가 더 중요합니다.

다음 단계

먼저 베이스라인을 쓰십시오. Atrix AI의 요구사항 감사는 모든 플랜에서 그 베이스라인에 대해 실행되며, 이전 글 AI를 활용한 코드 감사는 소규모 팀에 전체 감사가 필요한 때와 가벼운 감사로 충분한 때를 다룹니다.

출처

Veracode 2025 GenAI Code Security Report 보도자료, 2025년 7월 30일. Stack Overflow 2025 Developer Survey 결과, 2025년 7월 29일. 가격은 2026년 10월에 Semgrep 요금, GitHub Advanced Security, GitHub 결제 문서, Snyk 플랜에서 확인했습니다.