AI 코드 감사: 무엇을 점검하고, 언제 필요할까

질문은 하나가 아니라 두 개입니다

감사는 서로 다른 두 가지 질문에 답합니다. 그런데 대부분의 도구는 그중 하나만 묻습니다.

1. 합의한 것을 만들었는가? 제품에는 어딘가에 적힌 요구사항이 있습니다. 모두 구현되었나요? 슬그머니 바뀐 것은 없나요? 누구도 빼기로 결정하지 않았는데 빠진 것은 없나요?
2. 고객에게 내놓아도 안전한가? 한 계정이 다른 계정의 데이터를 볼 수 있나요? 저장소에 시크릿이 들어 있나요? 결제를 재시도하면 두 번 청구되나요?

주목을 더 많이 받는 것은 두 번째 질문입니다. 보안 사고는 비용이 크고 공개적으로 드러나기 때문입니다. 첫 번째 질문은 더 자주 건너뛰지만, 작은 제품에서는 대개 이쪽에서 뜻밖의 문제가 나옵니다. 고객에게 약속했지만 끝내 만들어지지 않은 기능, 혹은 결과물이 “통과”하도록 승인 후에 문구가 바뀐 요구사항 같은 것들입니다.

첫 번째 질문에 필요한 것

존재하지 않는 요구사항, 또는 아무도 테스트할 수 없는 요구사항에 비추어 결과물을 점검할 수는 없습니다. 그래서 감사의 전반부는 훨씬 앞서 해 둔 작업에 달려 있습니다.

• 키가 붙은 요구사항. REQ-014처럼 절대 바뀌지 않는 키가 있어야 작업을 요구사항까지 거슬러 추적할 수 있습니다.
• 인수 조건. 각 요구사항마다, 실제로 동작하는 제품에서 누군가 이를 어떻게 확인할지 적습니다.
• 동결된 버전. 합의된 내용의 고정본입니다. 승인 후에도 요구사항을 수정할 수 있다면, “요구사항”에 대한 감사는 결국 오늘 거기에 적혀 있는 무언가에 대한 감사가 됩니다.

이것들이 갖춰지면 점검은 간단합니다. 모든 Must 요구사항에 완료된 작업이 있습니다. 각 인수 조건 점검이 실제 제품에서 통과합니다. 승인 후 변경된 요구사항은 이전 문구와 새 문구와 함께 표시됩니다. 제외된 요구사항은 삭제되는 것이 아니라 결정으로 기록됩니다.

두 번째 질문에 필요한 것

작은 웹 또는 모바일 제품이라면, 실용적인 보안·안정성 점검은 여섯 가지 영역을 다룹니다.

• 접근 제어. 비공개 데이터에 접근하는 모든 라우트가 세션을 확인합니다. 관리자 작업은 로그인 여부만이 아니라 역할을 확인합니다. URL의 ID를 바꿔도 다른 계정의 레코드에 접근할 수 없습니다. 작은 제품에서 발견되는 심각한 문제는 대부분 여기에 있습니다.
• 시크릿. 저장소나 그 히스토리에 키나 토큰이 없습니다. 공개 환경 변수를 통해 서버 시크릿이 브라우저에 노출되지 않습니다. 유출된 자격 증명은 교체합니다.
• 의존성. 알려진 보안 권고(advisory)를 npm audit이나 OSV 같은 실제 권고 데이터베이스와 대조해 확인하고, 권고 ID를 기록합니다.
• 입력 처리. 매개변수화된 쿼리를 사용하고, 사용자 입력으로 동적 코드를 실행하지 않으며, 출력을 이스케이프하고, 업로드를 검증하고, 사용자가 제공한 URL을 서버에서 가져오는 요청을 제한합니다.
• 결제 경로. 결제 핸들러는 멱등성을 보장하고, 웹훅 서명을 검증하고, 금액은 서버에서 계산하며, 동시 요청이 들어와도 크레딧이나 환불이 두 번 사용되지 않습니다.
• 운영. 오류가 누군가 실제로 확인하는 모니터링으로 전달되고, 백업이 존재하며 복원도 시도해 보았고, 마이그레이션은 그것이 필요한 코드보다 먼저 적용됩니다.

그리고 잊기 쉬운 점검이 하나 더 있습니다. 실제로 배포되어 있는가입니다. 팀 밖의 누구도 접근할 수 없는 것에 대한 감사는 끝난 것이 아닙니다.

AI가 도움이 되는 곳

AI는 감사의 특정 지점에서 분명히 유용합니다.

• 큰 코드베이스를 빠르게 읽고 어디를 봐야 할지 짚어 줍니다. 모든 라우트 핸들러, 가격이 계산되는 모든 위치, URL을 가져오는 모든 호출 같은 것들입니다.
• 우선순위 분류. 긴 발견 사항 목록을, 돈이 새거나 데이터가 노출되는 것부터 순위를 매깁니다.
• 재현 단계와 수정 제안 작성. 이미 확인된 발견 사항에 대해 작성합니다.
• 설명. 수정해야 하는 사람에게, 그 사람의 코드에 맞춰 발견 사항을 설명합니다.

AI가 방해가 되는 곳

실패하는 패턴은 모델의 의견으로 이루어진 감사입니다. “이 코드는 안전한가?”라고 물으면 모델은 자신감 있는 목록을 내놓습니다. 일부는 맞고, 일부는 그럴듯하지만 틀리며, 모두 똑같은 형식으로 정리되어 있습니다. 검증할 수 없는 발견 사항은 아무 발견도 없는 것보다 나쁩니다. 확인하는 데 시간이 들고, 팀이 보고서를 무시하도록 길들이기 때문입니다.

그래서 AI 지원 감사의 규칙은 단순합니다.

• 증거가 없으면 없었던 일입니다. 모든 발견 사항에는 위치(파일과 줄, 또는 라우트), 문제를 보여 주는 증거, 재현 단계가 있어야 합니다. 증거가 없으면 발견 사항도 아닙니다.
• 발견 사항은 감이 아니라 점검에서 나옵니다. 의존성 권고는 기억이 아니라 권고 데이터베이스에서 나옵니다. 접근 제어 관련 발견은 실제로 ID를 바꿔 보고 무슨 일이 일어나는지 확인한 결과에서 나옵니다.
• 안정적인 식별자. 각 발견 사항에 지문(fingerprint)을 부여해, 감사를 다시 실행했을 때 새로운 텍스트 더미가 아니라 무엇이 수정되었는지를 알 수 있게 합니다.
• 분위기가 아니라 판정. 미해결 치명적(critical) 또는 높음(high) 등급 발견 사항이 없고 제품이 실제로 배포되어 있으면 감사는 통과입니다. 그렇지 않으면 한 번 더 반복합니다.

감사가 필요한 시점

작은 팀에 상시 감사 프로그램은 필요하지 않습니다. 답이 중요한 순간에 감사를 하면 됩니다.

• 공개 출시나 앱스토어 제출 전. 접근 제어의 구멍을 저렴하게 찾을 수 있는 마지막 시점입니다.
• 외부에 맡긴 작업이 돌아왔을 때. 외주 개발자, 스튜디오, 또는 코딩 에이전트가 여러분의 요구사항에 맞춰 무언가를 만들었을 때입니다. “합의한 것을 받았는가”에 답이 필요한 바로 그 순간입니다.
• 실사(due diligence) 전, 또는 다른 사람의 코드베이스를 넘겨받을 때.
• 인증, 결제, 데이터 접근에 큰 변경이 있은 후.

이런 시점 사이에는 더 가벼운 습관으로 충분합니다. 요구사항에 키를 유지하고, 커밋과 풀 리퀘스트에서 키를 참조하고, 결제 경로가 바뀔 때마다 다시 점검하세요.

Atrix AI가 맡는 부분과 맡지 않는 부분

범위를 분명히 해 두겠습니다. Atrix AI는 코드를 스캔하거나 분석하지 않습니다. 위의 보안·안정성 점검은 여러분이 직접, 앞서 언급한 도구를 사용해, 또는 신뢰할 수 있는 리뷰어와 함께 수행해야 합니다. Atrix AI가 하는 일은 워크스페이스가 정직하게 답할 수 있는 감사의 일부분과, 나머지 부분을 둘러싼 기록 관리입니다.

첫 번째 질문: 합의한 것을 만들었는가? Atrix AI에서는 요구사항을 수락한 뒤 번호가 매겨진 기준선(baseline)으로 동결합니다. 기준선은 각 요구사항의 정확한 문구와 PRD, 원본 문서를 당시 상태 그대로 보존합니다. 그러면 요구사항 감사가 기준선의 각 요구사항에 대해 작업이 존재하는지, 진행 중인지, 완료되었는지를 보여 주고, 동결 이후 문구가 바뀌었거나 제외된 요구사항, 그리고 동결 후 수정된 문서를 표시합니다. 기준선에 포함된 요구사항은 삭제할 수 없고 Won't로만 표시할 수 있으므로, 아무것도 조용히 사라지지 않습니다. 모든 상태는 모델의 의견이 아니라 여러분의 기록을 바탕으로 계산됩니다.

추적성. 요구사항에는 영구적인 키가 붙습니다. 코딩 에이전트에 개발을 넘길 때 Develop 모드의 인계 번들에는 문서와 키가 담기고, 커밋과 풀 리퀘스트에 키를 포함하도록 요청하므로, 감사자는 작업을 그 목적까지 거슬러 추적할 수 있습니다. AI 에이전트는 요구사항 초안을 쓰고 작업을 계획합니다. 무엇을 합의할지는 사람이 결정합니다.

발견 사항 추적. 감사에서 나온 각 발견 사항은 우선순위와 함께 이슈로 기록할 수 있으며, 영향을 받는 요구사항과 같은 프로젝트에 둘 수 있습니다. 또한 수락되었지만 아직 작업이 없는 요구사항은 이슈로 나눌 수 있습니다. 감사의 후반부는 Atrix 밖에서 이루어지지만, 그 결과까지 스프레드시트에 둘 필요는 없습니다.

점검 자체에는 무료 코드 감사 체크리스트를 사용하세요. 각 행마다 심각도, 위치, 증거, 재현 방법, 수정 제안을 기록하는 발견 사항 로그가 포함되어 있습니다.

요약

쓸모 있는 코드 감사는 먼저 합의되고 테스트 가능한 요구사항에 비추어 결과물을 점검하고, 그다음 안전하며 실제로 배포되어 있는지 점검합니다. AI는 읽고, 순위를 매기고, 설명하는 일을 빠르게 해 줍니다. 하지만 AI 혼자서 발견 사항의 출처가 되어서는 안 됩니다. 검증 가능한 요구사항에서 시작하면 감사의 나머지 부분은 훨씬 쉬워집니다.