AI 코딩 에이전트가 작성한 코드를 보안 검토하는 방법

AI 코딩 에이전트는 빠르며, 그 속도는 양날의 검입니다. 몇 분 만에 동작하는 기능을 기꺼이 만들어 내지만 — 그와 똑같이 기꺼이 문자열 연결로 SQL 쿼리를 짜맞추고, 비밀 값을 로그에 남기고, 권한 검사를 건너뜁니다. 코드는 돌아가고, 테스트는 통과하며, 취약점은 그대로 출시됩니다. 타이핑을 하는 것이 에이전트일 때 보안 검토는 선택 사항이 아닙니다. 그것은 여전히 당신의 몫으로 남는 부분입니다.

프로덕션에 도달하기 전에 AI가 생성한 코드를 검토하기 위한, 실용적이고 도구에 구애받지 않는 워크플로를 소개합니다.

무엇을 찾아야 하는지 알기

실제 세계의 취약점은 대부분 몇 가지 패턴으로 묶입니다. 당신(또는 도구)이 에이전트의 출력을 검토할 때는 먼저 다음을 훑어보세요.

• 인젝션(Injection) — 매개변수화된 쿼리를 쓰는 대신 문자열을 연결해 만든 SQL, 셸, 템플릿 입력.
• 크로스 사이트 스크립팅(XSS) — 이스케이프 없이 HTML로 렌더링되는 사용자 입력.
• 깨진 인증/인가 — 당신이 누구인지는 확인하지만 권한이 있는지는 확인하지 않는 엔드포인트; 레코드에 대한 소유권 검사 누락.
• 안전하지 않은 데이터 처리 — 코드 안의 비밀 값, 로그에 담긴 자격 증명, 오류 메시지 속 민감한 데이터.
• 취약한 의존성 — 에이전트가 추가한, 알려진 CVE가 있는 패키지.

이것들은 OWASP Top 10과 밀접하게 대응하며, Anthropic이 자사의 자동 보안 검토가 찾는다고 밝힌 바로 그 범주들입니다. 이 짧은 목록을 머릿속에 담아 두면 수동 검토가 훨씬 효과적이 됩니다.

에이전트가 스스로를 검토하게 하되 — 새로운 컨텍스트에서

코드를 작성한 바로 그 모델이 그것을 검토할 수 있지만, 같은 흐름 안에서는 안 됩니다. 방금 20턴에 걸쳐 어떤 기능을 동작시킨 에이전트는 그것을 옹호하도록 길들여져 있습니다. 새 세션을 시작하고 단 하나의 임무를 주세요: 결함을 찾아라.

잘 작동하는 프롬프트:

Review the diff on this branch for security vulnerabilities only.
For each finding, give me: the file and line, the vulnerability class
(e.g. SQL injection), a concrete exploit scenario, and the fix.
If you find nothing, say so — do not invent issues.

"concrete exploit scenario"라는 구절이 중요한 부분입니다. 이는 모델이 "입력값 검증을 고려하라"는 식의 막연한 상투적 문구를 나열하는 대신, 문제가 실제임을 증명하도록 강제합니다.

내장 도구를 활용하기

Claude Code를 사용한다면, 변경 사항을 일반적인 취약점 패턴에 대해 분석하고 당신이 승인하면 수정을 직접 적용하는 전용 /security-review 명령이 있습니다. 이는 유료 Pro 및 Max 요금제와 사용량 기반 API 계정에서 이용할 수 있습니다.

지속적인 커버리지를 위해 Anthropic은 오픈소스 GitHub Action도 제공합니다. 이것은 모든 pull request에서 실행되며 우려되는 바로 그 줄에 인라인 코멘트를 남깁니다. 저장소에 넣는 모습은 대략 다음과 같습니다.

# .github/workflows/security.yml
name: Security Review
on: [pull_request]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-security-review@main
        with:
          claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

이제 사람이 열었든 에이전트가 열었든, 모든 PR은 누군가 merge를 누르기 전에 보안 검사를 거칩니다. Cursor, Copilot을 비롯한 다른 어시스턴트도 비슷한 검토 통합을 제공하며, 원리는 도구와 무관하게 동일합니다.

결정론적 검사를 건너뛰지 말 것

AI 검토는 강력한 추가 수단이지, 결코 지치지 않는 지루한 도구들을 대체하는 것이 아닙니다.

• 의존성 스캔 — npm audit, pip-audit, 또는 Dependabot은 LLM이 이름만으로는 알아보지 못할, 알려진 취약 패키지를 잡아냅니다.
• 비밀 값 스캔 — gitleaks 같은 도구나 GitHub의 push protection은 유출된 키가 애초에 히스토리에 들어가는 것을 막습니다.
• 정적 분석(SAST) — 린터와 Semgrep 같은 도구는 코드베이스 전반에 걸쳐 규칙을 일관되게 적용합니다.

로직과 맥락에 대해 추론하는 데는 AI를 사용하고 — "여기서 인증된 사용자가 다른 사용자의 레코드를 읽을 수 있는가?" — 기계적이고 패턴으로 매칭 가능한 일에는 결정론적 스캐너를 사용하세요. 둘은 서로의 사각지대를 메워 줍니다.

구체적인 예

에이전트가 다음 엔드포인트를 생성했다고 합시다.

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(f"SELECT * FROM invoices WHERE id = '{invoice_id}'")

보안 검사는 두 가지 문제를 짚어야 합니다. 이 쿼리는 언제든 터질 SQL 인젝션이며(invoice_id가 문자열에 삽입됨), 그 인보이스가 실제로 user의 것인지 확인하는 검사가 없다는 점입니다 — 로그인한 어떤 계정이든 ID를 추측해 아무 인보이스나 읽을 수 있습니다. 수정 방법은 매개변수화된 쿼리에 소유권 필터를 더하는 것입니다.

@app.get("/invoices/{invoice_id}")
def get_invoice(invoice_id: str, user=Depends(current_user)):
    return db.query(
        "SELECT * FROM invoices WHERE id = %s AND owner_id = %s",
        [invoice_id, user.id],
    )

인젝션은 스캐너가 잡아내는 부류의 것입니다. 누락된 인가 검사는 누군가 — 또는 적절한 프롬프트를 갖춘 AI 검토자 — 가 그 코드가 무엇을 위한 것인지 이해해야 하는 부류의 것입니다. 이것이 염두에 두어야 할 구분입니다.

요점

에이전트가 만들어 내는 모든 diff는 검토되기 전까지 신뢰할 수 없는 것으로 취급하세요 — 새 팀원의 첫 pull request에 적용할 바로 그 기준입니다. 새로운 컨텍스트의 AI 검토, 자동화된 PR 검사, 그리고 결정론적 스캐너를 결합하면, AI 지원 개발의 속도를 대부분 누리면서도 그 최악의 습관을 물려받지 않을 수 있습니다.