- AI의 도움으로 만든 앱은 실제로 잘 작동합니다. 하지만 고객에게 열기 전에 일부러 뚫어 본 사람은 아직 없습니다.
- 보안 구멍이 자주 생기는 곳은 다섯 군데이고, 대표가 코드를 읽지 않아도 질문만으로 직접 확인할 수 있습니다.
- 앱이 고객의 이름, 전화번호, 이용 이력을 저장한다면 실제 데이터를 받기 전에 다섯 곳을 모두 점검해야 합니다.
앱이 잘 돌아간다고 보안까지 확인된 것은 아닙니다
팀의 젊은 직원 한 명이 AI 도구로 주말 동안 예약 시스템을 완성했다고 해 봅시다. 예약을 넣어 보고, 취소해 보고, 보고서도 열어 봅니다. 모두 잘 됩니다. 이런 시험으로 알 수 있는 것은 평범하게 쓰는 사람이 문제없이 쓸 수 있느냐 하나뿐입니다. 작정하고 엉뚱하게 쓰려는 사람이 이 시스템으로 무엇을 할 수 있는지는 아직 아무도 묻지 않았습니다.
바이브 코딩(vibe coding)은 원하는 것을 평소 쓰는 말로 설명하고 코드는 전부 AI에게 맡기는 방식입니다. 지시하는 사람은 대개 결과물 코드를 읽지 않고, 도구는 화면이 돌아갈 때까지 지시를 따르도록 만들어져 있습니다. 지시에 접근 권한, 비밀 키 보관, 사용자 입력값 검사 이야기가 없으면 결과 코드에도 대개 그런 장치가 빠집니다. 화면은 여전히 보기 좋고 버튼도 다 눌리니, 무언가 빠졌다고 알려 주는 것이 하나도 없습니다.
소프트웨어 보안 기업 Veracode는 100개가 넘는 언어 모델에 80가지 코딩 과제를 맡겨 시험했습니다. 2025년 7월에 낸 보고서에 따르면, 코드가 과제의 요구대로 작동했는데도 과제의 45%에서 보안 취약점이 나왔습니다. 같은 해에는 CVE-2025-48757 취약점이 공개되었습니다. 바이브 코딩 플랫폼 Lovable로 만든 170개가 넘는 앱이 데이터 접근 규칙을 설정하지 않은 탓에, 외부인이 로그인하지 않고도 데이터베이스의 데이터를 읽고 고칠 수 있었던 사례입니다.
플랫폼 측은 접근 규칙 설정이 각 앱 소유자의 몫이라고 반박했습니다. 회사 대표 입장에서 이 말은, 데이터가 유출되면 고객에게 해명해야 하는 사람이 대표 자신이라는 뜻입니다. 앱을 만든 도구는 그 책임을 나눠 지지 않습니다.
바이브 코딩 앱에 보안 구멍이 자주 생기는 다섯 지점
인테리어를 막 끝낸 가게를 떠올려 보십시오. 매장 앞은 근사하고 계산대도 잘 돌아갑니다. 그런데 뒷문이 잠겼는지, 여분 열쇠는 어디 두었는지, 돈 서랍은 누가 열 수 있는지 둘러본 사람은 아직 없습니다. 이 표의 다섯 지점이 앱의 뒷문입니다. 지점마다 만든 사람에게 바로 물어볼 수 있는 질문이 하나씩 있습니다.
| 점검할 곳 | 뚫렸을 때 나타나는 증상 | 대표가 던질 확인 질문 |
|---|---|---|
| 데이터 열람 권한 | 고객 한 명으로 로그인해 링크 끝 번호를 바꾸면 다른 고객의 정보가 보입니다. | 링크 끝 번호를 바꾸면 다른 사람의 예약 내역이 보입니까? 지금 직접 보여 주십시오. |
| 시스템 키 | 데이터베이스나 결제 서비스 접속 키가 웹 페이지 코드에 박혀 있어, 열어 보는 사람은 누구나 볼 수 있습니다. | 돈을 내고 쓰는 서비스의 키는 어디에 보관하고, 누가 볼 수 있습니까? |
| 데이터베이스 | 외부인이 앱을 거치지 않고 데이터베이스에 바로 명령을 보내 테이블 전체를 읽어 갑니다. | 앱 화면을 거치지 않고 데이터베이스에 접근할 길이 있습니까? 테이블마다 어떤 규칙으로 막고 있습니까? |
| 사용자가 보내는 데이터 | 입력 칸에 아무 글이나 들어가고, 업로드 칸은 어떤 종류의 파일이든 받습니다. | 누군가 이상한 명령어를 입력하거나 이미지가 아닌 파일을 올리면 시스템은 어떻게 처리합니까? |
| 외부 코드 패키지와 사용 기록 | 앱이 취약점이 있는 버전의 패키지를 쓰고 있고, 사고가 나도 되짚어 볼 기록이 없습니다. | 내일 누군가 데이터가 유출됐다고 알려 오면, 누가 언제 들어와 무엇을 했는지 되짚어 볼 수 있습니까? |
첫 번째 지점은 가장 흔하면서 가장 눈에 띄지 않습니다. 소프트웨어 보안 비영리 단체 OWASP는 Top 10 목록에서 취약한 접근 통제를 웹 애플리케이션의 위험 1위로 꼽습니다. 로그인 단계의 인증(Authentication)은 사용자가 누구인지를 가리고, 권한 부여(Authorization)는 그 사용자가 무엇을 볼 수 있는지를 정합니다. AI는 인증은 대개 빠짐없이 만듭니다. 화면에 보이기 때문입니다. 권한 부여는 앱이 데이터를 가져오는 모든 지점에 규칙을 써 두어야 하는데, 규칙이 빠져도 그 사실을 알려 주는 화면은 없습니다.
두 번째와 세 번째 지점은 대개 함께 나타납니다. 급하게 만든 앱은 웹 페이지에서 데이터베이스로 바로 접속하는 경우가 많고, 그러면 접속 키가 모든 사용자의 브라우저로 그대로 내려갑니다. 최신 데이터베이스는 모든 테이블에 행 수준 보안(Row-Level Security) 규칙을 빠짐없이 걸어 두면 이런 접속 방식도 감당할 수 있습니다. 앞서 본 Lovable 사례는 이 규칙이 없는 테이블에서 생겼습니다.
개발팀 참고 · 기술 점검 목록
데이터 참조 ID를 받는 모든 엔드포인트에서 서버 측 Authorization을 검사합니다. 모든 테이블에 Row-Level Security를 켜고 Policy를 정의합니다. Secret은 번들과 리포지토리 이력에서 빼내 Secret Manager로 옮깁니다. 모든 입력 칸에 Parameterized Query와 Input Validation을 적용하고, 업로드 파일의 형식과 크기를 제한하며, 로그인 페이지에 Rate Limit을 겁니다. CI에서 Dependency Scan과 Secret Scan을 돌리고, 개인정보를 읽거나 고친 기록은 Audit Log로 남깁니다.
가상 사례
끝 번호를 바꿀 수 있었던 물리치료 클리닉의 예약 링크
지점이 세 곳인 한 물리치료 클리닉이 지점장에게 AI 도구로 예약 시스템을 만들게 했습니다. 시스템은 환자에게 예약 확인서 링크를 문자로 보냈고, 링크 끝에는 1042 같은 예약 일련번호가 붙었습니다. 한 환자가 번호를 1041로 바꿔 보았더니 다른 환자의 이름, 전화번호, 증상이 그대로 보였습니다. 이 환자는 화면을 캡처해 클리닉의 SNS 페이지로 보냈습니다.
클리닉은 일주일 동안 시스템을 닫고 공책에 예약을 받아 적었습니다. 수정 작업 자체는 며칠이면 끝났습니다. 서버 쪽에 규칙을 추가해 예약 확인서는 본인과 해당 지점 직원만 열 수 있게 했고, 일련번호를 무작위 코드로 바꿨으며, 열람 기록을 남기기 시작했습니다. 끝내 답하지 못한 질문은 그전에 누군가 남의 예약 확인서를 몇 번이나 열어 봤느냐였습니다. 기존 시스템이 아무것도 기록하지 않았기 때문입니다. 태국 개인정보보호법(PDPA)에서 건강 정보는 민감정보에 해당하므로, 클리닉은 사고 사실을 누구에게 알려야 하는지 법률 자문가의 판단을 받아야 했습니다.
실제 데이터를 받기 전에 점검할 다섯 개의 문
- 앱이 저장하는 데이터를 모두 목록으로 적고, 개인정보이거나 돈과 관련된 항목에 표시합니다.
- 테스트 계정을 두 개 만듭니다. 첫 번째 계정으로 로그인한 상태에서 두 번째 계정에서 얻은 링크를 전부 열어 봅니다.
- 코드를 읽을 줄 아는 사람에게 웹 페이지 코드와 코드 수정 이력에서 비밀 키를 찾아보게 합니다.
- 데이터베이스 접근 규칙을 테이블별로 보여 달라고 합니다. 규칙이 없는 테이블은 열려 있다고 봐야 합니다.
- 질문 하나로 사고를 가정해 봅니다. 어제 누군가 데이터를 빼 갔다면, 오늘 우리는 무엇을 보고 그 사실을 알 수 있습니까?
항목마다 결과를 점검 날짜, 점검한 사람의 이름과 함께 적어 두십시오. 회사가 서비스를 열기 전에 점검했다는 증거가 됩니다. 이 방법으로 기본적인 취약점은 잡을 수 있지만, 전문가가 하는 모의 해킹을 대신하지는 못합니다. 결제를 받거나 민감정보를 저장하는 앱은 한 단계 더 나아가야 합니다.
얼마나 깊이 점검할지는 앱이 가진 데이터에 달려 있습니다
집집마다 문은 잠가야 하지만 금고까지 들여야 하는 집은 일부입니다. 앱도 마찬가지여서, 점검 수준은 데이터의 가치와 민감도에 맞춰야 합니다. 작은 도구에 필요 이상으로 공을 들이면 돈을 엉뚱한 곳에 쓰게 됩니다.
영업팀이 함께 쓰는 가격 계산기처럼 고객 데이터가 없는 사내 도구는 바이브 코딩으로 만들어 바로 써도 괜찮습니다. 단, 회사의 비밀 키가 코드에 박혀 있지 않은지는 확인해야 합니다. 고객의 이름, 전화번호, 이메일을 저장하는 앱은 다섯 개의 문을 모두 통과해야 하고, 공개 전에 직접 만들지 않은 엔지니어가 권한과 비밀 키를 검토해야 합니다.
돈을 받거나 건강 정보, 금융 정보, 신분증 사본을 저장하는 앱에는 그 이상이 필요합니다. 설계 단계부터 위협 모델(Threat Model)을 세워야 합니다. 누가 어떤 경로로 공격할 수 있고 그때 무엇을 잃게 되는지 미리 따져 보는 작업입니다. 그런 다음 공개 전에 외부 테스터에게 모의 해킹(Penetration Test)을 맡기고, 시스템이 크게 바뀔 때마다 다시 받아야 합니다.
사내 문서를 읽는 챗봇이 앱에 들어 있다면 프롬프트 인젝션(Prompt Injection)이라는 위험이 하나 더 생깁니다. 사용자가 숨은 지시문을 입력해서, 자신에게 열람 권한이 없는 정보를 AI가 털어놓도록 속이는 수법입니다. 효과가 있는 방어책은 AI의 권한을 지금 질문하는 사람의 권한과 똑같이 제한하는 것입니다.
다음 중 하나라도 해당하면 아직 실제 데이터를 받지 마십시오
- 시스템 비밀 키를 어디에 보관하는지 팀의 누구도 말하지 못합니다.
- 테스트 계정 하나로 다른 계정의 데이터를 열 수 있습니다.
- 데이터베이스에 접근 규칙이 없는 테이블이 있습니다.
- 누가 고객 데이터를 열어 보거나 고쳤는지 시스템이 기록하지 않습니다.
- 사고가 나면 누가 연락을 받는지 담당자 이름을 대지 못합니다.
비용 면에서도 공개 전에 점검하고 고치는 편이 사고 뒤에 고치는 것보다 쌉니다. 사고가 나면 수정 비용은 똑같이 들고, 거기에 시스템 중단 비용, 고객 응대에 들어가는 팀의 시간, 법적 부담까지 더해지기 때문입니다. 태국 PDPA는 데이터 컨트롤러(개인정보 처리 책임자)가 침해 사실을 알게 된 시점부터 72시간 안에 태국 개인정보보호위원회 사무국에 신고하도록 정하고 있습니다. 다만 정보주체의 권리를 침해할 위험이 없는 사고는 예외입니다. 구체적인 이행 방법은 회사의 법률 자문가에게 확인하십시오.
누구나 바이브 코딩을 할 수 있다면 엔지니어 팀은 어디에 필요할까
AI는 시킨 일을 합니다. 그런데 보안 문제는 대부분 시키는 사람이 미처 생각하지 못한 부분에서 생깁니다. 공격받는 실제 시스템을 지켜본 사람은 코드를 쓰기 전에 무엇을 물어야 하는지, 다 쓴 뒤에는 시스템을 상대로 무엇을 시험해 봐야 하는지 압니다.
올해 잘하는 개발팀도 다른 사람들처럼 AI로 코드를 씁니다. 차이는 코드를 둘러싼 절차에 있습니다. 작업에 들어가기 전에 권한을 설계하고, AI가 쓴 코드는 엔지니어가 읽은 뒤에 시스템에 합칩니다. 코드를 고칠 때마다 취약점 스캔 도구가 돌아가고, 인수인계 문서에는 사고가 났을 때 전화할 수 있는 담당자의 이름이 적혀 있습니다.
대표가 요청해 볼 지표는 몇 개 되지 않습니다. 심각도별 미해결 취약점 수, 심각도가 높은 취약점을 막는 데 걸린 일수, 마지막 점검 날짜, 데이터 유출 대응 훈련 결과입니다. 이 숫자에 답할 수 있는 사람이 없다면, 아직 아무도 보안을 맡고 있지 않다는 뜻입니다.
다 만든 앱은 점검해 보강하고, 새 앱은 설계 첫날부터 보안을 넣습니다
어떤 데이터를 절대 잃으면 안 되는지는 대표와 사내 IT팀이 가장 잘 압니다. 법이 무엇을 요구하는지는 회사의 법률 자문가가 판단합니다. DNA Maker는 이분들과 함께 앱이 어떤 데이터를 저장하는지, 데이터가 어느 지점을 거쳐 흐르는지, 누가 무엇을 봐야 하는지부터 하나씩 짚습니다. 그리고 이를 데이터 흐름도, 역할별 권한표, 사람의 승인이 필요한 지점 목록으로 정리합니다.
이미 바이브 코딩으로 만든 앱이라면, 저희는 이 글의 다섯 지점을 기준으로 보안 리뷰(Security Review)를 진행하고 심각도 순으로 정리한 취약점 보고서를 드립니다. 수정은 기존 팀과 함께 하거나 저희가 맡아서 합니다. 새로 만드는 시스템이라면 권한, 비밀 키 보관, 입력 데이터 검사, 사용 기록을 처음부터 아키텍처에 넣어 설계합니다. AI로 코드를 쓰되 모든 코드를 엔지니어가 리뷰하고, 파이프라인에서 코드와 외부 패키지를 스캔하며, 공개 전에 외부 모의 해킹 전문가가 점검할 수 있도록 시스템을 준비합니다. 곧 고객 데이터를 받기 시작할 앱이 있다면 앱 링크와 앱이 저장하는 데이터 목록을 가지고 저희 엔지니어와 이야기해 보십시오. 공개 전에 어디를 고쳐야 하는지 알 수 있습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
개발팀과 보안 이야기를 할 때 듣게 되는 용어입니다. 맨 오른쪽 열의 질문으로 각 항목을 실제로 챙기는 사람이 있는지 확인할 수 있습니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Authentication | 비밀번호, 문자 인증번호, 얼굴 인식 등으로 사용자가 누구인지 확인한 뒤 시스템에 들여보내는 절차 | 환자가 예약 확인서를 열려고 전화번호와 문자로 받은 인증번호를 입력합니다. | 어느 사용자 그룹에 2단계 인증이 필요하고, 비밀번호를 잊으면 계정을 어떻게 복구합니까? |
| Authorization | 본인 확인을 마친 사용자가 각자 어떤 데이터를 보거나 고칠 수 있는지 정하는 규칙 | 환자는 자기 예약 확인서만, 직원은 소속 지점의 예약만 열 수 있습니다. | 데이터를 가져올 때마다 서버에서 권한 규칙을 검사합니까? 테스트는 누가 합니까? |
| Secret Management | 데이터베이스 비밀번호, 결제 서비스 키 같은 시스템의 비밀 정보를 코드 밖에 두고 볼 수 있는 사람을 제한하는 보관 방식 | 문자 발송 서비스의 키는 비밀 정보 보관 시스템에 있고, 웹 페이지 코드에는 들어 있지 않습니다. | 비밀 키가 새어 나가면 몇 분 안에 새 키로 바꿀 수 있고, 그 일은 누가 합니까? |
| Row-Level Security | 사용자마다 읽거나 고칠 수 있는 데이터 행(row)을 정해 두는 데이터베이스 규칙 | 예약 테이블은 로그인한 환자 본인의 행만 돌려줍니다. | 아직 이 규칙이 없는 테이블이 있습니까? 있다면 이유는 무엇입니까? |
| Threat Model | 누가 어떤 경로로 시스템을 공격할 수 있고 어떤 피해가 생기는지 미리 따져서, 어디부터 막을지 정하는 작업 | 팀이 환자, 퇴사한 직원, 외부인이 각각 어떤 경로로 진료 기록에 접근할 수 있는지 하나씩 따져 봅니다. | 우리 시스템에서 가장 큰 위험 세 가지는 무엇이고, 각각 누가 책임집니까? |
| Penetration Test | 계약을 맺고 전문가에게 실제로 시스템 침투를 시도하게 해서, 악의적인 공격자보다 먼저 취약점을 찾는 일 | 외부 테스터가 계정 없이 환자 데이터에 접근해 보고, 어디까지 할 수 있었는지 보고서로 냅니다. | 마지막 테스트는 언제였고 어느 범위를 다뤘습니까? 발견된 취약점은 모두 해결했습니까? |
| Dependency Scan | 시스템이 가져다 쓰는 외부 코드 패키지 가운데 이미 공개된 취약점이 있는 버전이 있는지 검사하는 일 | 파일 업로드를 처리하는 패키지에 취약점이 있다는 알림을 받고, 팀이 배포 전에 업데이트합니다. | 코드를 고칠 때마다 이 스캔이 돌아갑니까? 알림은 누가 받습니까? |