2025년, 보안 연구원들은 단 하나의 설정 오류(misconfiguration) 패턴을 발견했습니다. 이는 코딩 어시스턴트(coding assistant)가 단 몇 초 만에 기꺼이 생성해 줄 법한 종류의 오류로, 어디를 찾아봐야 할지 아는 사람이라면 누구나 100개 이상의 애플리케이션 데이터베이스에 자유롭게 접근할 수 있게 만들었습니다. 비밀번호 크래킹(password cracking)도, 정교한 익스플로잇 체인(exploit chain)도 필요 없었습니다. 그저 빠르게 출시되고 검토가 소홀했던 앱들에서, 공개된 API 키가 명령받은 대로 정확히 작동했을 뿐입니다. 이 결함은 CVE-2025-48757로 분류되었으며, CVSS 9.3 - 치명적(critical) 등급을 받았습니다.

이것이 바로

CVE-2025-48757은 그 생략된 단계가 대규모로 나타났을 때 어떤 모습인지를 보여줍니다. 2025년에 공개된 이 취약점은 이러한 방식으로 구축된 애플리케이션에서 행 레벨 액세스 규칙 (row-level access rules)이 누락되었거나 잘못 설정된 데서 기인했습니다. 결정적인 세부 사항이자, 이 사건을 공포 이야기보다는 교육적인 순간으로 만드는 핵심은 공격자가 탈취된 관리자 자격 증명 (admin credentials)을 필요로 하지 않았다는 점입니다. 그들은 애플리케이션의 공개 클라이언트 키 (public client key), 즉 설계상 프론트엔드에 포함되어 모든 사람에게 노출되도록 의도된 이른바 익명 키를 사용했습니다. 해당 키는 데이터베이스의 액세스 규칙이 올바를 때만 안전합니다. 규칙이 올바르지 않았을 때, 거의 아무런 권한도 부여하지 않아야 했던 공개 키는 대신 다른 사용자의 개인 데이터에 대한 읽기 권한, 그리고 때로는 쓰기 권한까지 부여했습니다.

다시 말해, 자물쇠는 설치되었고 키는 의도한 대로 대중에게 배포되었지만, 정작 문은 자물쇠와 연결되어 있지 않았던 것입니다. 이번 침해 사고는 정교한 침입이 아니었습니다. 그것은 아무도 검토하지 않은 기본 설정이었으며, 동일한 빠른 구축 패턴 (fast-build pattern)에 의존하는 수많은 애플리케이션에서 반복되었습니다.

불편한 사실은 다음과 같습니다:

노출된 애플리케이션들이 모든 경우에 부주의한 아마추어들에 의해 만들어진 것은 아니었습니다. 그것들은 보안을 플랫폼이 자동으로 처리하는 무언가로 취급하며 빠르게 구축되었습니다. 플랫폼은 대부분 그렇게 처리합니다. 당신이 건너뛴 단 하나의 설정이 가장 중요한 설정이 되기 전까지는 말입니다.

이것은 일회성 사건이 아닙니다: 문제의 규모

이것을 운 나쁜 단일 플랫폼의 사례로 치부한다면 마음은 편하겠지만, 더 넓은 관점에서의 상황은 다릅니다. 2025년의 대규모 연구에서 보안 기업인 Escape.tech는 약 5,600개의 공개 배포된 애플리케이션을 스캔하여 2,000개 이상의 취약점을 발견했습니다. 이는 AI 보조 코드를 빠르게 배포하는 사람이라면 누구라도 멈춰 서서 생각하게 만들 만한 적중률입니다. 구체적인 제품은 다양하지만, 패턴은 동일합니다. 빠른 생성과 빈약한 검토는 예측 가능한 유형의 실수를 반복해서 만들어냅니다.

그리고 이러한 실수들은 결코 생소한 것이 아닙니다. 코딩 어시스턴트(coding assistant)가 코드를 안전하게 만들기 위해서가 아니라, 단순히 코드가 작동하게 만들기 위해 생성하는 몇 가지 매력적이지 않은 기본 설정(defaults) 주위에 집중되어 있습니다.

• 프론트엔드(frontend) 내의 비밀 정보(Secrets). API 키, 토큰, 연결 문자열(connection strings)이 클라이언트 측 코드나 공개 번들(public bundle)에 포함되어, 누구나 브라우저 개발자 도구로 읽을 수 있게 됩니다.
• 부재하거나 지나치게 허용적인 접근 규칙(Access rules). 각 사용자가 실제로 볼 수 있는 행(row)이 무엇인지 아무도 알려주지 않았기 때문에, 데이터베이스는 요청을 신뢰합니다.
• 권한 확인(authorization check)이 없는 엔드포인트(Endpoints). 코드는 당신이 '누구'인지는 확인하지만, 당신이 방금 요청한 작업을 수행할 '권한이 있는지'는 결코 확인하지 않습니다.
• 맹목적으로 신뢰되는 입력값(Inputs). 사용자 제공 값이 검증(validation) 없이 쿼리(queries), 파일 경로, 또는 명령어로 직행합니다. 이는 AI의 속도로 재탄생한 가장 오래된 유형의 웹 취약점입니다.
• 내부 정보를 유출하는 상세한 에러(Verbose errors). 스택 트레이스(Stack traces), 테이블 이름, 설정 세부 정보가 공격자에게 시스템의 무료 지도처럼 제공됩니다.

이 중 그 어떤 것도 찾아내는 데 천재가 필요하지 않습니다. 자동화된 스캐너와 기회주의적인 공격자들은 정확히 이것을 찾습니다. 이들이 계속해서 성공하는 이유는 수정하기 어려워서가 아니라, AI의 도움을 받아 빠르게 작성된 코드가 누군가 검토하기도 전에 배포되는 경우가 많기 때문입니다.

AI 지원 코드가 특히 이러한 문제에 취약한 이유

속도와 위험이 왜 연결되어 있는지 이해하는 것이 도움이 됩니다. 그래야 해결책이 명확해지기 때문입니다. 코딩 어시스턴트는 눈앞의 요청을 만족시키고 작동하는 코드를 생성하도록 최적화되어 있습니다. "회원가입 양식이 데이터베이스에 저장되게 해줘"라고 하면, 데이터베이스에 저장되는 회원가입 양식을 만들어 줍니다. 하지만 사용자가 요청하지 않았다면, 사용자 A가 사용자 B의 기록을 읽는 것을 방지하는 행 단위 접근 규칙(row-level access rule)을 스스로 만들어주지는 않습니다. 왜냐하면 그것은 당신이 요청한 것이 아니며, 보안은 데모에서 작동하는 모습이 보이는 '기능(feature)'이 아니라, '부재(absence)'(일어나서는 안 될 나쁜 일이 일어나지 않는 상태)이기 때문입니다.

세 가지 힘이 이를 가중시킵니다:

• 그럴듯함이 정확성을 앞지릅니다 (Plausibility outruns correctness). AI가 생성한 코드는 자신감 있고 깔끔하게 읽히며, 이는 신뢰할 수 있다는 느낌을 주고 이를 면밀히 조사하려는 본능을 낮춥니다. 보안이 취약한 코드와 보안이 철저한 코드는 똑같이 깔끔해 보입니다.
• 기본 설정(Defaults)이 대규모로 복제됩니다. 수천 명의 개발자가 유사한 프롬프트를 입력하면, 동일한 보안 취약점이 포함된 기본 설정이 포함된 유사한 코드를 얻게 되며, 이는 단일 팀이 검토할 수 있는 속도보다 더 빠르게 제품 전반으로 확산됩니다.
• 속도가 자연스러운 멈춤을 제거합니다. 수동으로 백엔드를 작성할 때 발생하는 전통적인 마찰(friction)은 권한 부여(authorization)와 데이터 노출에 대해 생각할 시간을 만들어 주었습니다. 생성 후 즉시 배포(Generate-and-ship) 방식은 그 마찰을 제거하며, 의도적으로 다시 도입하지 않는 한 보안에 대한 사고 과정도 함께 제거합니다.

중요한 관점의 전환:

AI가 코드를 불안전하게 만든 것이 아닙니다. AI는

배포(shipping)

비용을 극적으로 낮춘 반면,

검토(reviewing)

의 중요성은 예전과 똑같이 유지했습니다. 병목 현상은 조용히 작성(writing)에서 검증(verifying)으로 이동했습니다. 그리고 이 변화에 맞춰 주의를 기울이지 않은 팀들이 바로 CVE를 생성하고 있는 팀들입니다.

배포 전 보안 검토 6단계

여기 실질적인 보상이 있습니다. 위에서 언급한 패턴의 거의 모든 취약점은 코드가 라이브로 배포되기 전, 짧고 반복 가능한 검토를 통해 포착됩니다. 이것은 6개월짜리 보안 프로그램이 아닙니다. 숙련된 엔지니어가 한 시간도 채 걸리지 않아 기능에 대해 실행할 수 있는 체크리스트이며, 첫 번째 항목만으로도 CVE-2025-48757을 잡아냈을 것입니다.

• ☐ 프론트엔드에 비밀 정보(Secrets)를 두지 마세요. 클라이언트 번들(Client bundle)을 grep하여 키(Keys), 토큰(Tokens), 연결 문자열(Connection strings)이 있는지 확인하세요. 민감한 모든 정보는 서버 측(Server-side)이나 비밀 관리자(Secrets manager)에 존재해야 하며, 브라우저가 읽을 수 있는 코드에 절대 포함되어서는 안 됩니다.
• ☐ 액세스 규칙(Access rules)이 존재하고 테스트되었는지 확인하세요. 클라이언트가 접근할 수 있는 모든 테이블에 대해, 행 수준 보안(Row-level rules)이 활성화되어 있고 실제로 강제 적용되는지 확인하세요. 그 다음, 데이터가 정말로 보이지 않는 권한이 없는 두 번째 사용자로 테스트하십시오. 기본 설정이 잠겨 있다고 믿지 마세요.
• ☐ 모든 엔드포인트(Endpoint)는 인증(Authentication)뿐만 아니라 인가(Authorization)를 확인해야 합니다. 코드가 단순히 사용자가 로그인했는지만 확인하는 것이 아니라, 각 작업을 수행할 '권한'이 있는지 검증하는지 확인하세요.
• ☐ 모든 사용자 입력은 검증(Validated)되고 매개변수화(Parameterised)되어야 합니다. 사용자 값을 쿼리(Queries), 파일 경로(File paths), 또는 셸 명령(Shell commands)에 직접 연결(Concatenate)하지 마세요. 경계(Boundary)에서 타입(Type), 범위(Range), 형식을 검증하세요.
• ☐ 운영 환경(Production)에서는 에러를 조용히 처리하세요. 스택 트레이스(Stack traces), 테이블 이름, 또는 설정(Config) 정보가 사용자에게 유출되지 않도록 하세요. 사용자에게는 일반적인 메시지만 전달하고, 상세한 내용은 로그(Logs)에만 기록하세요.
• ☐ 의존성(Dependencies)과 설정(Config)을 스캔하세요. 모든 배포(Deploy) 과정의 일부로 패키지에 대한 자동화된 취약점 스캔(Vulnerability scan)과 알려진 설정 오류(Misconfigurations) 체크를 실행하세요. 그래야 잘못된 기본 설정이 운영 환경에 도달하기 전에 빌드 단계에서 실패하게 됩니다.

이것이 전체 비용이며, 그 금액은 적습니다. 이 검토를 수행하는 비용은 데이터베이스 하나가 노출되거나, 고객에게 침해 통지 이메일을 보내거나, 제품 이름이 붙은 CVE가 발생하는 비용의 아주 작은 일부에 불과합니다.

이것이 여러분에게 의미하는 바

만약 여러분의 팀이 AI 보조 코드(AI-assisted code)를 배포하고 있다면 — 그리고 이제 거의 모든 팀이 그러하고 있다면 — CVE-2025-48757의 교훈은 "속도를 늦추라"거나 "AI 사용을 중단하라"는 것이 아닙니다. 그것은 바로 "주의를 옮기라"는 것입니다. 소프트웨어의 어려운 점은 결코 타이핑하는 것이 아니었습니다. 어려운 점은 코드가 의도한 대로만 작동하도록 보장하는 것이며, 특히 코드를 작성하는 속도는 10배 빨라진 반면 검토(Reviewing) 속도는 그렇지 않은 상황에서는 더욱 그러합니다.

향후 2년 동안 큰 피해를 입게 될 팀은 AI가 생성한 코드가 실행되는 즉시 완성된 것으로 간주한 팀들일 것입니다. 승리하는 팀은 "실행된다(it runs)"와 "배포해도 안전하다(it is safe to ship)"를 서로 다른 두 개의 마일스톤(Milestone)으로 취급하며, 그 사이에 짧고 절제된 보안 검토(Security review)를 배치할 것입니다. 그 검토는 비용이 저렴하고 반복 가능하며, 빠르게 배포하는 것과 9.3(심각한 보안 사고)을 배포하는 것 사이의 차이를 만드는 핵심입니다.

CVE를 배포하지 않고 빠르게 배포하기

우리는 모든 빌드(Build)에 대해 보안 검토가 완료된 전달(Delivery) 프로세스를 실행합니다. 도움이 되는 곳에는 AI 가속을 적용하고, 중요한 곳에는 사람이 검증합니다. 귀사가 빠르게 배포한 앱을 보내주시면, 위에서 언급한 6가지 항목의 검토를 수행하여 무엇이 노출되었는지 정확히 알려드리고, 이를 해결하기 위한 확정된 서면 견적을 제공하겠습니다. 공포 조장 없이, 오직 발견된 사실만을 전달합니다.

보안 검토 요청하기

우리의 안전한 전달 프로세스 보기

Shanti Infosoft 소개

Shanti Infosoft LLP는 보안을 깨뜨리지 않으면서 빠르게 움직여야 하는 기업들을 위해 맞춤형 웹 및 앱 제품, AI 통합 (AI integration), 그리고 맞춤형 소프트웨어 (custom software)를 구축하는 CMMI Level 5 소프트웨어 엔지니어링 기업입니다. 모든 빌드는 보안 검토와 사람에 의한 QA(Quality Assurance)를 거쳐 전달됩니다. 우리는 AI를 사용하여 속도를 높인 후, 무엇인가가 배포되기 전에 시니어 엔지니어가 권한 부여(Authorization), 데이터 노출(Data exposure), 비밀 정보 처리(Secrets handling) 및 설정을 검증합니다. 귀하는 확정된 범위의 서면 견적, 지정된 팀, 그리고 전체 소스 코드 및 IP(지식재산권) 소유권을 보장받습니다. 즉, 감사(Audit)를 거친 귀하만의 코드가 됩니다.

자주 묻는 질문 (FAQ)

"바이브 코딩(Vibe coding)"이란 무엇이며, 본질적으로 보안에 취약한가요?

바이브 코딩은 원하는 것을 일상 언어로 설명하고, AI 어시스턴트가 코드를 생성하게 한 뒤, 가벼운 검토만 거쳐 배포하는 것을 말합니다. 이것이 본질적으로 보안에 취약한 것은 아닙니다. 코드 자체는 종종 문제가 없습니다. 하지만 개발자가 권한 부여, 데이터 노출, 비밀 정보에 대해 생각하던 자연스러운 멈춤의 순간들을 제거해 버립니다. 보안 취약성은 AI를 사용하기 때문이 아니라, 검토 과정을 건너뛰기 때문에 발생합니다.

CVE-2025-48757은 무엇이었나요?

2025년에 공개된 심각한 취약점(CVSS 9.3)으로, 행 수준 접근 규칙(row-level access rules)이 누락되었거나 잘못 설정된 인기 있는 패스트 빌드(fast-build) 데이터베이스 패턴 기반 애플리케이션에 영향을 미쳤습니다. 공격자는 관리자 자격 증명(admin credentials)이 필요하지 않았습니다. 그들은 애플리케이션의 공개된 프론트엔드 배포용 익명 키(anonymous key)를 사용했으며, 데이터베이스의 접근 규칙이 올바르게 설정되지 않았기 때문에 다른 사용자의 데이터가 노출되었습니다.

공개 API 키가 어떻게 개인 데이터를 노출할 수 있나요?

해당 공개 "익명" 키는 프론트엔드에 포함되어 배포되도록 설계되었으며, 데이터베이스가 올바른 행 수준 접근 규칙(row-level access rules)을 강제할 때만 안전합니다. 이러한 규칙이 없거나 너무 허용적일 경우, 거의 아무런 권한도 부여해서는 안 되는 공개 키가 오히려 접근해서는 안 될 데이터에 대한 읽기 또는 쓰기 권한을 부여하게 됩니다. 결함은 키 자체가 아니라, 누락된 접근 규칙이었습니다.

내 AI 지원 앱에 이러한 문제가 있는지 어떻게 알 수 있나요?

다음 6가지 검토 사항을 실행하십시오: 프론트엔드 번들(frontend bundle) 내의 비밀 정보(secrets) 확인, 권한이 없는 두 번째 사용자로 행 수준 접근 규칙(row-level access rules)을 확인 및 테스트, 모든 엔드포인트(endpoint)가 인가(authorization)를 확인하는지 검증, 모든 사용자 입력의 유효성 검사 및 매개변수화(parameterise), 운영 환경(production) 에러 메시지 숨기기, 그리고 모든 배포 시 자동화된 종속성(dependency) 및 설정 스캔 실행. 첫 번째 확인 사항만으로도 CVE-2025-48757 유형의 문제를 잡아낼 수 있습니다.