빠른 개발 속 인공지능 코드 보안 취약점 핵심 가이드
빠르게 아이디어를 구현하는 현대 개발 환경에서 인공지능(AI) 코드는 혁신을 가속한다. 그러나 속도에만 집중하면 보안은 뒷전으로 밀리기 쉽다. 이러한 개발 방식을 ‘바이브코딩’이라 부르는데, 이곳에 숨어 있는 치명적인 보안 허점을 정확히 이해하고 대처하는 방안이 필요하다.
인공지능 코드의 숨겨진 위험
최근 AI의 도움을 받아 코드를 빠르게 생성하고 배포하는 일이 흔하다. 로그인 기능과 데이터 저장 시스템을 빠르게 구현하고 제품을 홍보하는 과정에서, 개발자는 미처 생각하지 못한 위험에 노출된다. 바로 앱의 데이터베이스가 통째로 열려 있거나, API 키가 코드에 그대로 박혀 있는 등 기본적인 보안 조치가 전혀 되어 있지 않은 상태로 서비스가 시작될 수 있다는 사실이다.
Veracode의 조사 결과는 AI 생성 코드의 위험성을 명확히 보여준다. 100개 이상의 AI 모델을 대상으로 테스트한 결과, AI 생성 코드의 45%가 보안 테스트를 통과하지 못했다. 이러한 문제는 해커가 작정하고 공격해서 발생하는 사고라기보다, 애초에 문단속을 하지 않아 벌어진 일에 가깝다. 달리 말하면, 간단한 조치만으로도 상당수의 보안 위협을 막을 수 있다는 뜻이다. 이 글은 바이브코더가 흔히 저지르는 보안 실수를 짚고, 이를 막는 방법과 유용한 도구를 정리한다.
바이브코더가 흔히 저지르는 보안 실수 5가지
AI가 코드를 생성할 때 보안 측면을 놓치기 쉽다. 사람이 직접 챙기지 않으면 이러한 취약점은 그대로 배포된다. 각 실수가 어떻게 공격으로 이어지고 어떤 결과를 초래하는지 파악한다.
| 실수 유형 | 문제점 | 공격 과정 | 결과 | 통계/사례 |
|---|---|---|---|---|
| 데이터베이스 잠금장치(RLS) 미설정 | Supabase 같은 백엔드 서비스에서 테이블 생성 시 RLS(Row Level Security)가 기본으로 꺼져 있다. RLS는 ‘누가 어떤 데이터에 접근할 수 있는지’를 정의하는 규칙이다. | 앱 배포 시 데이터베이스 접근용 공개 키(anon 키)가 브라우저 코드에 포함될 수 있다. 공격자는 브라우저 개발자 도구로 이 키를 추출한 다음, 데이터 주소(example.com/rest/v1/표이름)를 직접 호출한다. 잠금장치가 없으면 실제 데이터가 응답으로 돌아오며 고객 정보가 유출된다. 이러한 앱은 자동 점검 프로그램에 의해 쉽게 탐지된다. |
개인 정보 유출: 전체 회원 데이터가 빠져나간다. 이는 유출 공지, 회원 이탈, 집단 소송으로 이어진다. | 한 연구자가 Lovable로 개발한 앱 1,645개를 점검한 결과, 170개에서 잠금장치 없이 데이터가 읽혔다(CVE-2025-48757). |
| LLM API 키 코드에 직접 삽입 | LLM API 키는 곧 비용이다. 키를 등록한 사람의 비용으로 AI 토큰을 무료로 사용할 수 있기 때문에, 공격자들이 가장 먼저 노리는 대상이다. | 키가 포함된 코드를 GitHub 공개 저장소에 올리거나 빌드 결과물에 포함하는 순간 취약해진다. 공격용 프로그램은 GitHub의 새 코드를 실시간으로 분석하여 키를 찾아낸다. 키 노출 후 악용까지 걸리는 시간은 과거 몇 시간에서 현재 몇 분으로 짧아졌다. 공격자는 탈취한 키로 LLM API를 최대치로 호출하여 비용을 발생시킨다. | 비용 급증: 감당할 수 없는 수준의 비용이 발생하며, 키가 교체되기 전까지 요금은 계속 증가한다. | GitGuardian의 집계에 따르면, 2025년 한 해에만 공개 코드에서 키 및 비밀번호 2,865만 건이 발견되었다. AI 서비스 자격증명 유출은 1년 만에 81% 증가했다. |
| 인증 검사 누락 | AI는 관리자 화면 버튼은 만들어주지만, 서버에서 누가 관리자인지 확인하는 인증 절차를 누락하는 경우가 많다. “내부용”이라는 이유로 인증 없이 공개 주소에 올려버리기도 한다. | 공격자는 화면을 거치지 않고 데이터 주소를 직접 호출한다. 서버에 권한 검사 로직이 없으면 관리자 기능이 그대로 실행되며, 간단한 조작만으로 타인의 정보를 열람하는 일이 발생할 수 있다. | 권한 탈취 및 자료 유출: 한 보안 업체가 공개된 바이브코딩 앱 38만 개를 점검한 결과, 약 5,000개 앱에 사실상 인증이 없었다. 이 중 40%는 회원의 민감한 정보를 노출했다. | 이로 인해 권한 탈취와 자료 유출이 쉽게 발생한다. |
| 요청 횟수 제한 부재 | AI가 생성한 예제 코드에는 요청 횟수를 제한하는 장치가 빠져 있는 경우가 많다. 이는 서버와 API에 무제한 요청을 보낼 수 있게 하며, 모든 요청은 비용으로 이어진다. | 공격자가 특정 주소, 특히 LLM을 중계하는 주소에 자동 스크립트로 무작위 요청을 보내기 시작한다. 요청 횟수 제한이 없으면 끝없이 요청이 들어온다. | 서비스 마비 및 비용 폭증: 요금이 감당할 수 없을 만큼 불어나거나, 서버 과부하로 서비스가 중단된다. 매우 짧은 스크립트 하나로 이런 사고가 발생한다. | - |
| 입력값 검증 부족 | AI가 데이터베이스 쿼리를 안전한 방식 대신 문자열을 그대로 이어 붙여 만드는 경우가 있다. | 테스트 입력에서는 문제가 없다가, 공격자가 조작한 값을 입력하면 그 틈을 파고든다. 데이터베이스 명령어를 끼워 넣어 자료를 빼내거나(SQL 인젝션), 외부에서 가져온 글에 숨긴 명령으로 LLM이 원래 지시를 무시하게 만들 수도 있다(프롬프트 인젝션). | 데이터 유출 또는 파괴: 데이터베이스 전체가 탈취되거나 삭제되며, AI 에이전트가 지시받지 않은 위험한 작업을 수행하기도 한다. | Replit에서 AI 에이전트가 작업 중지 지시를 무시하고 운영 데이터베이스를 통째로 지운 사례가 있다. 이는 에이전트에게 운영 권한을 함부로 부여해서는 안 되는 이유를 보여준다. |
이러한 취약점은 크게 접근 통제(①③), 비용 유출(②④), 입력값 공격(⑤)으로 분류된다. AI가 알아서 해결해 주기를 기대하기 어려운 문제들이다.
보안 이슈를 해결하는 단계별 접근법
보안은 단 한 번으로 끝나는 이벤트가 아니라 앱 운영 전반에 걸쳐 지속적으로 챙겨야 할 과제이다. 마이크로소프트의 보안 개발 가이드도 보안이 개발 완료 후 고려할 사항이 아님을 강조한다. 특히 초기 제작 단계, 개발 단계, 배포 후 단계에서 집중적으로 신경 쓰는 것이 효과적이다.
설계 및 초기 세팅
설계 단계에서 발생한 결함은 나중에 고치기 가장 어렵다. 자신의 앱에서 가장 보호해야 할 데이터가 무엇인지 정의하는 일이 보안 설계의 출발점이다.
- 데이터베이스 잠금장치부터 활성화한다. Supabase를 사용한다면 대시보드에서 각 테이블의 RLS 활성화 여부를 확인하고,
auth.uid() = user_id와 같은 규칙을 설정한다. 다른 데이터베이스를 사용하더라도 잠금장치 점검은 필수이다. - 인증은 직접 구현하지 않고 검증된 서비스에 맡긴다. 권한 관련 허점은 자동 점검 도구로도 탐지하기 어려운 영역이므로, 처음부터 Supabase Auth나 Clerk 같은 안전한 서비스를 사용하는 것이 효과적이다.
- API 키를 코드 밖으로 분리한다. 키는
.env파일로 옮기고, 이 파일을.gitignore에 추가한다. 브라우저에서 직접 API를 호출하던 방식은 서버 함수를 거치게 변경하여 키가 사용자 화면에 노출되지 않도록 막는다. - 요청 제한을 설정한다. Cloudflare와 같은 서비스를 앱 앞에 두면 IP당 요청 횟수에 상한을 두는 규칙을 쉽게 만들 수 있다. 특히 AI 관련 서비스라면 콘솔에서 월 지출 한도를 정해두면 비용 사고의 대부분을 막을 수 있다.
- 개발용과 운영용 환경을 분리한다. AI 에이전트가 실수로 운영 데이터베이스에 접근하지 못하도록 처음부터 환경을 분리해 둔다. 어느 정도 규모가 있는 서비스는 이러한 설정을 기본으로 갖춘다.
개발 중 코딩 습관
초기 설정을 마쳤더라도 코드를 새로 작성할 때마다 새로운 취약점이 생길 수 있다. AI가 생성한 코드를 맹목적으로 신뢰하지 않는 습관이 중요하다.
- 쿼리를 수동으로 이어 붙이지 않는다. 데이터베이스 쿼리를 직접 문자열로 합쳐 만들지 말고, SDK(Software Development Kit)나 ORM(Object-Relational Mapping) 같은 도구를 사용한다. Supabase 클라이언트 SDK를 사용하면 SQL 인젝션을 대체로 방지한다. 즉, 사용자 입력을 쿼리 명령어로 직접 삽입하기보다는 파라미터로 처리하는 방식이 안전하다. 형식 검사 도구로 한 번 더 걸러내는 과정도 유용하다.
- AI가 추천한 라이브러리를 의심한다. AI는 존재하지 않거나 오래되고 취약한 라이브러리를 추천하기도 한다. 공격자들이 AI의 흔한 실수를 노려 가짜 패키지 이름을 미리 선점하기도 한다. 라이브러리 설치 전에는 반드시 안전성을 확인하고, 중요 시점마다 검토하는 것이 좋다.
- 커밋 전에 API 키 유출을 방지한다. 커밋 직전에 키가 코드에 포함되었는지 자동으로 확인하는 장치(예: pre-commit 훅)를 설정하면, 키가 GitHub와 같은 저장소로 유출되기 전에 걸러낼 수 있다.
- AI가 생성한 코드는 적용 전 반드시 검토한다. ‘Accept’ 버튼을 누르기 전에 보안 측면을 한 번 더 점검하는 습관이 중요하다. 코드를 직접 검토하기 어렵다면 도구를 활용한다.
- 외부 소스를 가져올 때는 일단 의심한다. 웹에서 가져오거나 다운로드한 소스로 위험한 작업을 수행할 때는 사람이 한 번 승인하는 단계를 둔다. AI가 공격을 스스로 체크하도록 설정하는 것도 방법이다.
배포 후 지속적인 점검
NIST(미국 국립표준기술연구소)의 보안 개발 표준은 ‘취약점 대응’에 큰 비중을 둔다. 이는 허점을 찾아내고 재발을 방지하는 것까지가 보안의 영역임을 의미한다.
- 가장 쉬운 자가 점검을 수행한다. 로그인하지 않은 상태에서 자신의 앱 데이터 주소에 요청을 한 번 보내본다. 데이터가 그대로 반환된다면 어딘가 문이 열려 있는 상태이다. 새 기능을 추가할 때마다 이 과정을 반복한다.
- 알림 기능을 활성화한다. 키 유출이나 라이브러리 취약점 발생 시 이를 알려주는 점검 시스템을 구축하면, 사고를 거의 실시간으로 인지하고 대응할 수 있다.
- 새 기능마다 잠금장치와 인증을 재확인한다. 데이터베이스 테이블을 새로 만들거나 API 주소를 추가할 때, 해당 기능이 제대로 보호되어 있는지 그때그때 확인하는 습관이 가장 확실한 예방책이다.
- 사고 발생 시 대응 순서를 미리 정해둔다. 보안 사고가 의심된다면, 먼저 ① 노출된 키를 즉시 변경하고 문제 기능을 비활성화한다. 다음으로 ② 어떤 데이터가 얼마나 유출되었는지 범위를 파악한다. 마지막으로 ③ 원인을 차단하고 유사한 허점이 다른 곳에 있는지 살핀다.
이러한 방법들은 가장 기초적이며 기본적인 대처 방식이다. 하지만 이것만으로도 초기 단계의 보안 사고 대부분을 막을 수 있다. 서비스가 성장하고 더 많은 정보와 큰 돈이 오갈 때는 보안에 대한 투자를 늘리고 전문적인 노력을 기울여야 한다.
보안 점검을 돕는 도구들
위에 나열된 모든 사항을 사람이 일일이 수동으로 챙기기란 매우 어렵다. 그래서 보안 도구의 도움을 받는다. 하지만 도구는 어디까지나 보조 수단이며, 경고를 이해하고 문제를 해결하는 주체는 사람이다. 코딩 에이전트 내에서 보안을 챙기는 방법은 크게 외부 전용 보안 도구와 코딩 에이전트 벤더사 자체 제공 도구로 나뉜다.
외부 보안 점검 도구
SonarQube, Snyk, Semgrep은 외부 보안 도구 중에서 널리 사용된다. 이들은 주로 MCP(Model Context Protocol) 서버를 연결하여 보안 검수를 수행하고, 코딩 에이전트가 그 결과를 활용하는 구조를 가진다.
- SonarQube: 코드 품질 분석 도구로 시작하여 버그, 코드 복잡성, 취약점 등을 폭넓게 점검한다. MCP 서버를 연동하면 코딩 에이전트가 SonarQube의 분석 결과를 읽고 짧은 코드 조각도 즉석에서 검사한다. 핵심 기능은 무료로 사용할 수 있으며, 커뮤니티 에디션과 클라우드 무료 플랜이 있다. GitHub 인기도와 설치 수 기준으로 SonarQube는 2026년 6월 현재 에디터 플러그인 설치 수 449만 건으로 1위이다.
- Snyk: 라이브러리(오픈소스 의존성) 취약점 감지에 특히 강점을 보인다. 코드, 컨테이너, 인프라 설정까지 함께 분석한다. Snyk CLI에 MCP 서버가 내장되어 있어
snyk mcp -t stdio명령어로 로컬에서 실행하면 에이전트가 코드를 적용(Accept)하기 전에 스캔한다. 무료 계정으로 즉시 사용할 수 있으나, 항목별 월별 스캔 횟수 제한이 있다. - Semgrep: 5,000개 이상의 규칙으로 코드를 의미 단위로 빠르게 분석하는 보안 전용 SAST(Static Application Security Testing) 도구이다. 규칙이 소스 코드와 유사하여 원하는 패턴을 직접 만들기도 쉽다. MCP 서버는 보안 점검, 스캔, 커스텀 규칙 실행 같은 기능을 에이전트에 제공한다. 이는 오픈소스 도구이며, 기본 스캔은 무료로 사용할 수 있다. 보안 위험 감지 측면에서는 SonarQube보다 나은 점도 있다.
내장형 연계 보안 도구
보안은 개발의 핵심적인 문제이므로, 코딩 에이전트 자체적으로 보안 기능을 내장하거나 연계하는 도구도 등장하고 있다.
- Claude Code의
/security-review: Claude Code를 사용한다면/security-review명령어를 활용할 수 있다. 코드 근처에서 이 명령어를 입력하기만 하면 SQL 인젝션, XSS(Cross-Site Scripting), 인증 허점 등을 검토한다. 토큰은 사용하지만 추가 비용은 없으며, 코드 단위로 통합할 수 있는 GitHub Action도 제공한다. - Codex Security: Codex 사용자에게 제공되는 이 도구는 현재 프로 이상 가입자만 사용할 수 있는 프리뷰 버전이다. “보안 전용” 기능으로, 코드를 분석하여 취약점을 식별 및 검증하고, 수정 패치까지 제안하는 에이전트형 도구이다. 격리된 환경에서 재현을 검증하여 정확도를 높인다. Codex에서 보안 점검이 필요할 때 유용하게 활용될 전망이다.
- Copilot Autofix: GitHub에 코드를 올린다면 Copilot Autofix가 취약점 검증과 수정 코드를 제안한다. 공개 및 오픈소스 저장소에서는 무료이며, Copilot 구독도 필요 없다.
보안, 미루지 말고 지금 시작한다
바이브코딩에서는 ‘지식을 엮는 일’이 중요하다. 이는 어떤 위험이 있고 무엇이 부족한지 아는 것을 의미한다. 모든 보안 지식을 깊이 쌓을 필요는 없다. 어떤 위험이 존재하는지 인지하고, 시점에 맞춰 기본적인 조치를 취하는 것만으로도 초기 단계 보안 사고의 대부분을 막는다. 아는 만큼 대응할 수 있다.
보안은 공격 방법이 끊임없이 진화하므로 완전한 방패를 세울 수는 없다. 따라서 원칙적인 접근이 중요하다. 일단 시작할 때 기억해야 할 두 가지 원칙이 있다. 첫째, AI를 맹목적으로 신뢰하지 않는다. AI가 생성한 코드일수록 한 번 더 의심하고, 배포 전에 사람이 직접 확인해야 한다. 둘째, ‘나중에 하자’는 생각을 버린다. 트래픽이 늘면, 결제가 붙으면, 시간이 나면 챙기겠다는 생각은 대개 사고가 터진 후에야 보안에 관심을 갖게 만든다. 지금 사고가 발생한 서비스들도 ‘일단 돈부터 벌고 나중에 하자’는 생각에서 시작했을 것이다. 괜찮을 것이라 안일하게 생각하지 말고, 지금 당장 보안의 첫걸음을 뗀다.