AI 코딩 도구는 아이디어를 몇 주가 아닌 단 몇 시간 만에 작동하는 웹사이트로 바꿀 수 있습니다. 인터페이스는 완성된 것처럼 보이고, 사용자는 로그인할 수 있으며, 데이터는 저장되고, 제품은 거의 즉시 배포될 수 있습니다.

하지만 작동하는 웹사이트라고 해서 반드시 안전한 웹사이트인 것은 아닙니다.

애플리케이션이 정당한 사용자에게는 올바르게 동작할 수 있지만, API 키를 노출하거나, 한 계정이 다른 사용자의 데이터에 접근할 수 있게 하거나, 인증 없이 민감한 엔드포인트(endpoint)를 열어둘 수도 있습니다.

그렇다면, Vibe-Coded 웹 개발은 안전할까요?

안전할 수도 있지만, 기본적으로 안전하다고 간주해서는 절대 안 됩니다. 코드, API, 액세스 제어(access controls), 종속성(dependencies), 그리고 프로덕션 설정(production configuration)은 여전히 독립적인 검토가 필요합니다.

다음은 AI가 생성한 웹사이트를 배포하기 전에 확인해야 할 7가지 보안 리스크입니다.

1. 노출된 API 키 및 비밀 정보 (Secrets)

AI 코딩 어시스턴트는 종종 애플리케이션을 데이터베이스, 결제 게이트웨이(payment gateways), 이메일 제공업체, 클라우드 플랫폼 및 외부 API에 연결합니다.

이러한 통합을 빠르게 작동시키기 위해, 자격 증명(credentials)이 소스 코드나 설정 파일에 직접 배치될 수 있습니다.

일반적인 예시는 다음과 같습니다:

• API 키
• 데이터베이스 비밀번호
• JWT 서명 비밀 정보 (JWT signing secrets)
• OAuth 클라이언트 비밀 정보 (OAuth client secrets)
• 웹훅 비밀 정보 (Webhook secrets)
• 클라우드 액세스 키
• 개인 키 (Private keys)
• 서비스 계정 자격 증명 (Service account credentials)

비밀 정보는 커밋된 .env 파일, Git 히스토리, 프론트엔드 번들(frontend bundles), 소스 맵(source maps), 로그, Docker 이미지, CI/CD 설정, 에러 메시지, 스크린샷 또는 AI 도구로 전송된 프롬프트(prompts)를 통해 유출될 수도 있습니다.

특히 흔한 실수는 프론트엔드 코드에서 비밀 환경 변수를 참조하는 것입니다. 애플리케이션이 빌드된 후, 해당 값은 모든 브라우저가 다운로드하는 JavaScript의 일부가 됩니다.

만약 비밀 정보가 공개 저장소(public repository)에 푸시되었다면, 이미 침해되었다고 가정해야 합니다. 나중에 해당 라인을 삭제하는 것만으로는 충분하지 않습니다. 해당 자격 증명을 폐기하고 교체(rotate)해야 합니다.

2. 안전해 보이기만 하는 인증 (Authentication)

완성된 로그인 화면이 백엔드(backend)가 보호되고 있음을 증명하지는 않습니다.

AI가 생성한 애플리케이션은 회원가입, 로그인, 로그아웃, 비밀번호 복구, 역할 선택, "로그인 상태 유지" 기능을 포함할 수 있지만, 다음과 같은 중요한 제어 기능은 누락될 수 있습니다:

• 로그인 속도 제한 (Login rate limiting)
• 안전한 쿠키 설정 (Secure cookie configuration)
• 적절한 토큰 만료 (Reasonable token expiration)
• 비밀번호 변경 후 토큰 취소 (Token revocation after password changes)
• 일회용 비밀번호 재설정 링크 (One-time password-reset links)
• 계정 인증 (Account verification)
• 다요소 인증 (Multi-factor authentication)
• 백엔드 계정 상태 확인 (Backend account-status checks)

흔히 저지르는 실수는 사용자 인터페이스(user interface)만 보호하는 것입니다.

예를 들어, 프론트엔드(frontend)는 인증되지 않은 사용자를 /login으로 리다이렉트할 수 있지만, 다음 엔드포인트(endpoint)는 세션을 검증하지 않고 여전히 고객 정보를 반환할 수 있습니다:

GET /api/customers

공격자는 인터페이스를 사용할 필요가 없습니다. 그들은 스크립트, cURL, Postman 또는 자동화된 보안 도구를 사용하여 API를 직접 호출할 수 있습니다.

인증(Authentication)은 보호된 모든 요청에 대해 서버에서 반드시 강제되어야 합니다.

3. 깨진 권한 부여(Broken authorization) 및 사용자 간 데이터 접근

인증(Authentication)은 다음 질문에 답합니다:

사용자가 누구인가?

권한 부여(Authorization)는 다음 질문에 답합니다:

이 사용자가 무엇을 할 수 있도록 허용되었는가?

애플리케이션이 사용자를 올바르게 인증하더라도, 깨진 권한 부여(broken authorization)를 통해 데이터를 노출할 수 있습니다.

다음 URL을 고려해 보십시오:

/orders/1001

만약 1001을 1002로 변경했을 때 다른 고객의 주문이 나타난다면, 해당 애플리케이션은 요청된 리소스의 소유권을 검증하지 않고 있는 것입니다.

동일한 문제가 다음 항목에 영향을 미칠 수 있습니다:

• 고객 ID (Customer IDs)
• 사용자 ID (User IDs)
• 송장 ID (Invoice IDs)
• 테넌트 ID (Tenant IDs)
• 프로젝트 ID (Project IDs)
• 파일 ID (File IDs)
• 지원 티켓 (Support tickets)
• 문서 다운로드 URL (Document download URLs)

이는 특히 멀티 테넌트(multi-tenant) SaaS 애플리케이션에서 매우 위험합니다. 단 한 번의 권한 부여 실수가 한 회사가 다른 회사의 데이터를 읽거나 수정할 수 있게 만들 수 있습니다.

AI가 생성한 코드는 다음과 같은 비즈니스 규칙을 이해하지 못할 수도 있습니다:

• 요청자가 자신의 요청을 승인할 수 없음
• 직원은 자신의 부서 레코드에만 접근할 수 있음
• 관리자는 레코드를 조회할 수는 있지만 삭제할 수는 없음
• 체험 계정은 유료 기능에 접근할 수 없음
• 지원 요원은 계정 소유권을 이전할 수 없음
• 테넌트 (Tenant) 데이터는 완전히 격리되어 유지되어야 함

스캐너는 비즈니스 의도 (Business intent)를 완전히 이해할 수 없기 때문에, 이러한 문제들은 대개 수동 테스트 (Manual testing)를 필요로 합니다.

4. 프론트엔드 전용 입력 유효성 검사 (Frontend-only input validation)

AI 도구들은 필수 입력 필드, 유효한 이메일 형식, 숫자 전화번호, 파일 확장자, 최소 또는 최대 값 등 양식 (Form)에 유효성 검사 (Validation)를 자주 추가합니다.

하지만 브라우저 측 유효성 검사는 API로 직접 요청을 보냄으로써 우회될 수 있습니다.

공격자는 다음과 같은 것들을 제출할 수 있습니다:

• 음수 또는 극도로 큰 값
• 예상치 못한 필드
• 수정된 가격
• 관리자 권한 (Administrative roles)
• 매우 긴 문자열
• HTML 또는 JavaScript
• 쿼리 파편 (Query fragments)
• 비정상적인 파일 경로
• 실행 파일
• 과도하게 큰 페이로드 (Oversized payloads)

서버 측 유효성 검사 (Server-side validation)가 없다면, 애플리케이션은 SQL 인젝션 (SQL injection), NoSQL 인젝션 (NoSQL injection), 크로스 사이트 스크립팅 (Cross-site scripting), 커맨드 인젝션 (Command injection), 경로 탐색 (Path traversal), 대량 할당 (Mass assignment), 악성 파일 업로드 (Malicious file uploads), 또는 서버 측 요청 위조 (Server-side request forgery)에 취약해질 수 있습니다.

프론트엔드에서 이미 검증했더라도, 백엔드 (Backend)가 수신하는 모든 값은 신뢰할 수 없는 것으로 간주하십시오.

5. 안전하지 않거나 가상의 의존성 (Unsafe or imaginary dependencies)

새로운 기능을 구현하도록 요청받았을 때, 코딩 어시스턴트 (Coding assistant)는 다른 패키지 (Package)를 설치하도록 권장할 수 있습니다.

해당 패키지는 다음과 같은 문제를 일으킬 수 있습니다:

• 알려진 취약점 (Vulnerabilities)을 포함함
• 방치되었거나 유지보수가 제대로 되지 않음
• 인기 있는 라이브러리 (Library)의 이름을 모방함
• 불필요한 전이적 의존성 (Transitive dependencies)을 도입함
• 호환되지 않는 라이선스 (License)를 사용함
• 설치 스크립트를 실행함
• 알 수 없는 유지 관리자로부터 제공됨
• 실제로 아직 존재하지 않음

마지막 사례는 특히 흥미로운 공급망 리스크 (Supply-chain risk)를 생성합니다.

AI 모델은 레지스트리(registry)에 존재하지 않는 그럴듯한 패키지 이름을 생성할 수 있습니다. 공격자는 나중에 해당 이름을 등록하고 악성 코드를 게시할 수 있습니다. AI가 생성한 설치 명령어를 그대로 따르는 개발자는 결과적으로 공격자의 패키지를 설치하게 될 수 있습니다.

악성 의존성(Malicious dependencies)은 환경 변수와 토큰을 탈취하거나, 소스 코드를 수정하고, CI/CD 파이프라인을 침해하거나, 개발 시스템에 대한 지속적인 접근 권한을 생성할 수 있습니다.

단순히 명령어가 성공하고 원래의 에러가 사라졌다는 이유만으로 의존성을 설치해서는 절대 안 됩니다.

6. 안전하지 않은 API 및 프로덕션 설정 (Insecure APIs and production configuration)

상대적으로 안전한 애플리케이션 코드라 할지라도 안전하지 않은 환경에 배포될 수 있습니다.

일반적인 설정 문제는 다음과 같습니다:

• 인터넷에 노출된 데이터베이스 (Databases exposed to the internet)
• 공개된 스토리지 버킷 (Public storage buckets)
• 프로덕션 환경에서 활성화된 디버그 모드 (Debug mode enabled in production)
• 모든 오리진을 허용하는 CORS (CORS allowing every origin)
• 공개된 소스 맵 (Public source maps)
• 인증되지 않은 관리자 대시보드 (Unauthenticated administration dashboards)
• 잊혀진 테스트 엔드포인트 (Forgotten test endpoints)
• 공개 디렉토리에 저장된 백업 (Backups stored in public directories)
• 사용자에게 반환되는 스택 트레이스 (Stack traces returned to users)
• 과도한 권한을 가진 서비스 계정 (Overprivileged service accounts)
• 프로덕션 데이터를 사용하는 데모 환경 (Demo environments using production data)

프로토타입은 내부 대시보드로 시작했다가 나중에 파트너와 공유되거나, 이메일로 전송되거나, 검색 엔진에 의해 인덱싱될 수 있습니다.

인증이나 네트워크 제한이 없다면, "내부 도구"는 조용히 공개 애플리케이션이 될 수 있습니다.

따라서 보안 검토(Security review)는 소스 코드뿐만 아니라 배포 환경까지 포함해야 합니다.

7. 과도한 권한을 가진 AI 코딩 에이전트 (Overprivileged AI coding agents)

보안 리스크는 생성된 코드에만 국한되지 않습니다. 코딩 에이전트 자체가 공격 표면(attack surface)의 일부가 될 수 있습니다.

설정에 따라 에이전트는 다음과 같은 작업을 수행할 수 있습니다:

• 전체 리포지토리(repository) 읽기
• 파일 수정 또는 삭제
• 셸 명령어(shell commands) 실행
• 패키지 설치
• 환경 변수 읽기
• 데이터베이스 접근
• 클라우드 서비스 연결
• MCP 서버 사용
• 애플리케이션 배포
• 프로덕션 환경과 직접 상호작용

만약 에이전트(Agent)가 저장소(Repository), 이슈(Issue), 문서(Document), 웹사이트, 이메일, API 응답 또는 패키지 문서 내에 숨겨진 악성 명령을 처리하게 된다면, 광범위한 권한은 피해를 크게 증가시킬 수 있습니다.

해킹되거나 조작된 에이전트는 비밀 정보(Secrets)를 노출하거나, 악성 패키지를 설치하고, 보안 설정을 약화시키며, 코드를 수정하거나 위험한 명령을 실행할 수 있습니다.

AI 에이전트는 최소 권한 원칙(Principle of Least Privilege)을 따라야 합니다. 현재 작업에 필요한 접근 권한만 부여하고, 민감한 프로덕션(Production) 작업은 명시적인 인간의 검토(Human Review) 절차를 거치도록 유지해야 합니다.

어떤 프로젝트가 가장 세밀한 검토를 필요로 하는가?

모든 Vibe-coded 웹사이트가 동일한 위험 수준을 가진 것은 아닙니다.

계정, 저장된 데이터 또는 백엔드 통합(Backend Integration)이 없는 정적 랜딩 페이지(Static Landing Page)는 일반적으로 멀티 테넌트(Multi-tenant) SaaS 플랫폼보다 위험이 적습니다.

웹사이트가 다음과 같은 경우 보안 평가를 우선시해야 합니다:

• 사용자 계정이 있는 경우
• 개인 정보 또는 고객 데이터를 저장하는 경우
• 결제를 처리하는 경우
• 다중 역할(Multiple Roles)을 지원하는 경우
• API를 노출하는 경우
• 멀티 테넌트(Multi-tenant) 아키텍처를 사용하는 경우
• 내부 시스템에 연결되는 경우
• 관리 패널(Administration Panel)을 포함하는 경우
• 파일 업로드를 허용하는 경우
• 자율적인 AI 에이전트를 사용하는 경우
• 엔터프라이즈(Enterprise) 고객을 대상으로 하는 경우

침해 사고 발생 시 비즈니스 영향이 클수록, AI가 생성한 보안 점검에만 전적으로 의존하는 것은 부적절합니다.

마치며

Vibe coding이 자동으로 보안에 취약한 웹사이트를 만들어내는 것은 아닙니다.

AI는 팀이 프로토타입(Prototype)을 제작하고, 아이디어를 검증하며, 반복적인 작업을 자동화하고, 제품을 더 빠르게 출시하도록 도울 수 있습니다. 위험은 코드 생성 속도가 팀의 검토, 테스트 및 거버넌스(Governance) 능력보다 빨라질 때 발생합니다.

AI가 생성한 웹사이트가 프로덕션(Production)에 배포되기 전에, 팀은 다음 질문에 답할 수 있어야 합니다:

• 애플리케이션이 어떤 데이터를 처리하는가?
• 해당 데이터에 접근할 수 있는 권한은 누구에게 있는가?
• 어떤 API가 공개적으로 사용 가능한가?
• 비밀 정보(Secrets)는 어디에 저장되는가?
• 어떤 의존성(Dependencies)이 설치되어 있는가?
• AI 에이전트가 어떤 동작을 수행할 수 있는가?
• 어떤 장애가 고객이나 비즈니스 운영에 영향을 미칠 수 있는가?
• 사고 대응(Incident response)의 책임은 누구에게 있는가?

AI 도구에게 “보안 코드를 작성해줘(write secure code)”라고 요청하는 것이 일부 실수를 줄여줄 수는 있지만, 코드 리뷰(Code review), API 테스트(API testing), 권한 테스트(Authorization testing), 의존성 분석(Dependency analysis), 설정 리뷰(Configuration review), 그리고 침투 테스트(Penetration testing)를 대체할 수는 없습니다.

민감한 데이터나 중요한 비즈니스 로직을 포함하는 애플리케이션의 경우, 다음 단계는 AI에게 자신의 작업물을 검토하라고 요청하는 또 다른 프롬프트(Prompt)가 아니라, 검증 가능한 보안 프로세스(Verifiable security process)가 되어야 합니다.

원본 베트남어 기사는 여기에서 확인할 수 있습니다:
Are Vibe-Coded websites secure? 7 risks to check

AI가 생성한 애플리케이션에서 가장 자주 접했던 보안 문제는 무엇인가요?