ai coding

AI 코딩 보안 체크리스트 10가지｜AI 생성 코드 배포 전 반드시 점검할 항목

AI 코딩 도구 덕분에 기능 하나를 만드는 시간이 크게 줄었습니다. 프롬프트 몇 줄이면 로그인 API도, 파일 업로드 기능도 몇 분 만에 동작하는 코드로 나옵니다. 문제는 ‘동작한다’와 ‘안전하다’가 전혀 다른 이야기라는 점입니다.

보안 점검을 하다 보면 AI가 만든 코드에서 반복해서 보이는 패턴이 있습니다. 예제 코드를 흉내 내느라 API 키가 코드에 그대로 들어가 있거나, 화면에서만 입력값을 검사하고 서버에서는 값을 그대로 믿거나, 실제로는 존재하지 않는 패키지를 import 하는 경우입니다.

이 글에서는 AI 코딩 보안의 기본기를 정리하는 차원에서, AI 생성 코드 취약점을 배포 전에 걸러내기 위한 코드 보안 점검 체크리스트 10가지를 소개합니다. 개인 프로젝트나 소규모 팀이 무료 CLI 도구와 오픈소스 버전부터 시작할 수 있도록 구성했습니다. 다만 일부 기능과 CI 연동, 팀 단위 관리 기능은 제품별 요금제와 사용 조건을 확인해야 합니다.

ai 코드

먼저 알아둘 점: AI가 만든 코드는 ‘초안’입니다

AI 도구는 요청받은 기능을 구현하는 데 집중합니다. 보안 요구사항을 따로 말하지 않으면 보안은 우선순위에서 밀리기 쉽습니다. 또 공개된 코드 패턴을 학습하기 때문에 오래된 방식이나 취약한 예제가 섞여 나올 수 있습니다.

그리고 사람이 직접 짠 코드가 아니다 보니 리뷰하는 사람도 내용을 깊이 이해하지 못한 채 ‘돌아가니까’ 승인하게 되는 일이 생깁니다. AI 코드는 사람이 짠 코드와 같은 기준으로, 오히려 한 단계 더 꼼꼼하게 검토해야 합니다.

AI 생성 코드 배포 전 보안 체크리스트 10가지

1. 코드에 하드코딩된 API 키·비밀정보 제거

AI는 예제를 만들면서 api_key = 'sk-...' 같은 값을 코드에 직접 넣는 경우가 많습니다. 여기에 사용자가 실제 키를 넣고 그대로 커밋하면 유출 사고로 이어집니다.

  • gitleaks, TruffleHog 같은 도구로 현재 코드뿐 아니라 Git 히스토리 전체를 스캔합니다. 현재 파일만 검사하는 것과 Git 이력까지 검사하는 것은 다릅니다. 최근 버전의 gitleaks에서는 gitleaks git . 명령으로 저장소의 Git 이력을 검사하며, 이전 글에 자주 나오는 gitleaks detect는 구식 방식입니다. 설치한 버전에 따라 사용법이 다를 수 있으므로 공식 문서를 함께 확인하세요.
  • 이미 커밋된 키는 파일에서 지워도 히스토리에 남습니다. 삭제가 아니라 폐기 후 재발급이 원칙입니다.
  • AI 도구의 프롬프트에 키, 토큰, 고객 데이터를 붙여넣지 않습니다. 붙여넣었다면 유출로 간주하고 교체하는 편이 안전합니다.

2. .env·설정 파일과 시크릿 관리 방식 점검

비밀정보를 코드에서 뺐다면, 어디에 두는지도 중요합니다.

  • .env는 반드시 .gitignore에 포함하고, 저장소에는 키 이름만 담은 .env.example을 둡니다.
  • 운영 환경에서는 환경변수 또는 AWS Secrets Manager, HashiCorp Vault 같은 시크릿 관리 서비스를 사용합니다.
  • NEXT_PUBLIC_, VITE_ 같은 접두사가 붙은 변수는 브라우저 번들에 그대로 노출됩니다. 비밀 값을 여기에 넣지 않았는지 확인합니다.

3. 서버 측 입력값 검증

AI가 만든 코드는 화면(프런트엔드)에서만 검증하고, 서버 API에서는 받은 값을 그대로 사용하는 경우가 있습니다. 프런트엔드 검증은 사용자 편의 기능일 뿐 보안 장치가 아닙니다.

  • 모든 외부 입력(요청 본문, 쿼리스트링, 헤더, 업로드 파일)을 서버에서 검증합니다.
  • 허용할 값을 정의하는 화이트리스트 방식을 우선하고, 타입·길이·형식·범위를 확인합니다.
  • Zod, Pydantic, Joi 같은 스키마 검증 라이브러리를 쓰면 누락을 줄일 수 있습니다.

4. SQL 인젝션·XSS 등 인젝션 취약점 확인

문자열을 이어 붙여 쿼리를 만드는 코드는 AI 생성 코드에서도 자주 나옵니다.

# 위험: 입력값이 쿼리에 그대로 들어감
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

# 안전: 파라미터 바인딩
cursor.execute('SELECT * FROM users WHERE id = %s', (user_id,))

파라미터 자리표시자 문법은 데이터베이스 드라이버마다 다를 수 있습니다. 예를 들어 SQLite의 Python 드라이버는 ?를 사용하고, 다른 드라이버는 %s 등을 사용하므로 사용하는 라이브러리의 문서를 확인하세요.

  • SQL은 파라미터 바인딩 또는 ORM을 사용합니다.
  • innerHTML, dangerouslySetInnerHTML, eval(), os.system(), subprocess(shell=True) 사용 부분을 검색해 입력값이 섞이는지 확인합니다.
  • 사용자 입력을 화면에 출력할 때는 이스케이프 처리가 되는지 확인합니다.

5. 인증 로직 검증

로그인 기능은 AI가 가장 흔하게 만들어주는 코드이면서, 허술하게 만들어지기 쉬운 영역입니다.

  • 비밀번호는 bcrypt, argon2 같은 전용 해시 알고리즘으로 저장합니다. MD5, SHA-1 단독 사용은 피합니다.
  • JWT를 쓴다면 서명 키가 secret 같은 값으로 하드코딩되어 있지 않은지, 만료 시간이 설정되어 있는지, 허용 알고리즘이 고정되어 있는지 확인합니다.
  • 세션 쿠키에는 HttpOnly, Secure, SameSite 속성을 설정하고, 로그인 시도 횟수 제한을 둡니다.

6. 인가(권한) 검증

‘로그인했는가’를 확인하는 것과 ‘이 데이터에 접근할 권한이 있는가’를 확인하는 것은 별개입니다. AI 코드는 앞부분만 구현하고 뒷부분을 빠뜨리는 경우가 많습니다.

  • /api/orders/123처럼 ID로 조회하는 API에서 해당 데이터의 소유자인지 서버가 확인하는지 점검합니다. (IDOR 취약점)
  • 관리자 기능은 URL을 숨기는 것이 아니라 서버에서 역할(role)을 검사해야 합니다. 클라이언트가 보낸 role 값은 신뢰하지 않습니다.
  • 가장 확실한 방법은 다른 계정의 토큰으로 직접 호출해 보는 것입니다.

7. 정적 분석(SAST) 도구 실행

사람의 눈으로 모든 코드를 보는 것은 한계가 있습니다. 정적 분석 도구는 위험한 패턴을 빠르게 걸러줍니다.

  • Semgrep, CodeQL, SonarQube, Bandit(Python) 등을 사용합니다. Semgrep은 semgrep scan --config auto로 간단히 시작할 수 있습니다.
  • 결과는 High·Critical부터 처리하고, 오탐이라고 판단한 항목은 사유를 남깁니다.
  • AI에게 ‘취약점을 고쳐줘’라고 요청해 수정했다면, 반드시 다시 스캔해서 해결 여부를 확인합니다.

8. 의존성 취약점 검사와 존재하지 않는 패키지 확인

AI가 추천하는 라이브러리에는 두 가지 위험이 있습니다. 알려진 취약점이 있는 버전이거나, 아예 존재하지 않는 이름을 그럴듯하게 만들어낸 경우입니다. 후자는 공격자가 같은 이름의 악성 패키지를 미리 등록해 두는 ‘슬롭스쿼팅(slopsquatting)’ 공격으로 이어질 수 있습니다.

  • npm audit, pip-audit, Trivy(trivy fs .), GitHub Dependabot으로 취약한 의존성을 점검합니다.
  • 처음 보는 패키지는 설치 전에 공식 저장소, 배포 이력, 다운로드 수, 관리자 정보를 확인합니다.
  • lock 파일(package-lock.json, poetry.lock 등)을 커밋하고 버전을 고정합니다.

9. 위험한 기본 설정과 에러·로그 처리 점검

개발 중에 편하도록 열어둔 설정이 그대로 운영에 올라가는 경우가 많습니다.

  • DEBUG=True가 운영 환경에 남아 있지 않은지 확인합니다. CORS는 무조건 차단하기보다 필요한 출처만 허용하도록 설정하고, 인증이 필요한 API에서 불필요하게 접근 범위를 넓히지 않았는지 확인합니다. 에러 메시지와 스택 트레이스에 내부 정보가 노출되지 않는지도 점검합니다.
  • 로그에 비밀번호, 토큰, 개인정보가 찍히지 않는지 확인합니다.
  • 파일 업로드는 확장자·크기·저장 경로를 제한합니다.
  • AI가 만든 Terraform, CloudFormation, Dockerfile에서 0.0.0.0/0 전체 개방, 공개 버킷, root 권한 실행 같은 설정이 없는지 봅니다.

10. 테스트·개발·운영 환경 분리

AI가 만든 스크립트나 테스트 코드는 환경 구분 없이 하나의 접속 정보를 쓰도록 작성되는 경우가 있습니다.

  • 개발·테스트·운영의 DB, 키, 계정을 분리합니다. 테스트 코드가 운영 DB에 연결되지 않도록 합니다.
  • 테스트용 계정, 기본 비밀번호, 임시 우회 코드(‘나중에 지울 것’ 주석이 달린 코드)를 제거합니다.
  • AI 에이전트나 자동화 도구에는 운영 자격 증명을 주지 않고, 필요한 최소 권한만 부여합니다. 패키지 설치, 셸 실행, 배포 같은 작업은 필요에 따라 승인 절차를 둡니다.
  • AI 도구가 읽을 수 있는 파일과 전송되는 컨텍스트를 확인하고, .env, 개인 키, 운영 설정 파일은 불필요하게 노출하지 않습니다.
  • AI가 CI 설정, 권한 정책, 에이전트 지침 파일을 변경했다면 일반 코드 변경보다 더 주의해서 검토합니다.
  • 배포 전에는 스테이징 환경에서 먼저 검증합니다.

체크리스트를 자동화하는 방법

매번 손으로 점검하면 결국 빠뜨립니다. 단계별로 자동화해 두면 부담이 줄어듭니다.

  • 커밋 단계: pre-commit에 gitleaks를 걸어 비밀정보 커밋을 차단합니다.
  • Pull Request 단계: CI에서 Semgrep(정적 분석)과 의존성 검사를 실행하고, High 이상이 나오면 병합을 막습니다.
  • 배포 단계: 사람이 최종 리뷰합니다. 이때 ‘이 코드를 내가 설명할 수 있는가?’를 기준으로 삼습니다. 설명할 수 없는 코드는 배포하지 않는 것이 좋습니다.

자동화 도구에서 취약점이 발견되지 않았다고 해서 안전성이 입증된 것은 아닙니다. 권한 검사나 업무 로직 취약점은 스캐너가 놓치기 쉬우므로, 다른 계정으로 접근해 보는 인가 테스트, 잘못된 입력값 테스트, 핵심 업무 흐름에 대한 사람의 검토를 함께 수행해야 합니다.

배포 전 최종 점검 요약

  • 1. 코드와 Git 히스토리에 API 키·비밀정보가 없다
  • 2. .env는 Git에서 제외했고, 운영 시크릿은 별도로 관리한다
  • 3. 모든 입력값을 서버에서 검증한다
  • 4. 쿼리는 파라미터 바인딩이고, 위험 함수에 입력값이 섞이지 않는다
  • 5. 비밀번호 해시, 토큰 만료, 쿠키 속성 등 인증 설정을 확인했다
  • 6. 다른 계정으로 접근해도 데이터가 보호되는지 테스트했다
  • 7. 정적 분석을 실행하고 High 이상을 처리했다
  • 8. 의존성 취약점을 검사했고, 낯선 패키지는 실재 여부를 확인했다
  • 9. 디버그·CORS·에러·로그 설정을 운영 기준으로 바꿨다
  • 10. 개발·테스트·운영 환경을 분리하고 테스트용 코드를 제거했다

자주 묻는 질문

Q. AI가 만든 코드는 사람이 만든 코드보다 더 위험한가요?

단정하기는 어렵습니다. 다만 AI 생성 코드에서 취약점이 발견된다는 보고가 이어지고 있고, 무엇보다 ‘이해하지 못한 채 검증 없이 배포’하기 쉽다는 점이 위험 요인입니다. 그래서 사람이 작성한 코드보다 같거나 더 엄격한 점검 절차가 필요합니다.

Q. 무료 도구만으로도 점검이 가능한가요?

가능합니다. gitleaks, Semgrep(오픈소스 버전), npm audit, pip-audit, Trivy는 무료 CLI 또는 오픈소스 버전으로 시작할 수 있어 개인 프로젝트나 소규모 팀에서 시작하기에 충분합니다. 다만 일부 기능과 CI 연동, 팀 단위 관리 기능은 제품별 요금제와 사용 조건을 확인해야 합니다.

Q. AI에게 보안 점검을 시켜도 되나요?

보조 수단으로는 유용합니다. 하지만 AI도 놓치거나 잘못 판단할 수 있으므로, 정적 분석 도구의 결과와 사람의 리뷰를 최종 판단 기준으로 삼아야 합니다.

마무리

AI 코딩 도구는 개발 속도를 높여주지만, 보안 책임까지 대신 져주지는 않습니다. 배포 버튼을 누르는 것은 결국 사람이기 때문입니다.

처음부터 열 가지를 모두 적용하기 부담스럽다면, 1번(비밀정보), 6번(인가), 8번(의존성) 세 가지부터 시작해 보세요. 노출 시 영향이 크고, 자동화 도구를 활용해 반복적으로 점검하기 좋은 항목들입니다. 이 체크리스트를 팀의 배포 절차에 한 줄씩 넣어 두면, AI를 더 안심하고 활용할 수 있습니다.