AI 웹앱 만들기 공부 7편｜바이브코딩 보안 취약점 3가지와 배포 전 점검 방법

AI 웹앱 만들기 공부 7편｜바이브코딩 보안 취약점 3가지와 배포 전 점검 방법

AI에게 프롬프트 몇 줄만 입력하면 웹사이트와 앱을 만들 수 있는 시대입니다. 코드를 직접 작성하지 못하더라도 ChatGPT, Claude 등의 AI 도구를 활용하면 간단한 웹앱을 만들고 실제로 배포할 수 있습니다.

그런데 AI가 만들어 준 웹앱은 정말 안전할까요?

화면이 정상적으로 작동하고 버튼을 눌렀을 때 원하는 결과가 나온다고 해서 개인정보와 데이터까지 안전하게 보호되는 것은 아닙니다. 입력값 검증이 빠져 있거나, 사용자 권한을 잘못 처리하거나, API 키가 코드에 노출되면 심각한 보안 문제가 발생할 수 있습니다.

이번 글에서는 AI 웹도구 만들기 공부 7편으로, 바이브코딩으로 웹앱을 개발할 때 알아야 할 대표적인 보안 취약점 3가지와 예방 방법을 정리했습니다. 개발을 처음 시작하는 분도 이해할 수 있도록 쉬운 사례와 실제로 사용할 수 있는 보안 점검 프롬프트까지 소개합니다.

---

목차

• 1. 바이브코딩에서 보안이 중요한 이유
• ⭐ 2. 첫 번째 취약점: 입력값 검증과 SQL Injection·XSS
• ⭐ 3. 두 번째 취약점: 클라이언트 측 인증과 권한 우회
• ⭐ 4. 세 번째 취약점: API 키와 비밀번호 노출
• 5. AI에게 보안 검토를 요청하는 방법
• ⭐ 6. 웹앱 배포 전 보안 체크리스트
• 7. 자주 묻는 질문
• 8. 공식 참고 자료 및 다음 공부

---

1. 바이브코딩에서 보안이 중요한 이유

바이브코딩(Vibe Coding)은 AI에게 자연어로 원하는 기능을 설명하고, AI가 작성한 코드를 활용해 프로그램을 만드는 개발 방식입니다.

예를 들어 다음과 같이 요청할 수 있습니다.

• 학생별 체육 미션 도장판을 만들어 줘.
• 학급별 기록을 저장하고 엑셀 파일로 내려받게 해 줘.
• 관리자만 학생 기록을 수정할 수 있게 해 줘.
• AI API를 연결해 질문에 답변하는 기능을 추가해 줘.

AI는 이러한 요구사항을 바탕으로 화면과 기능을 빠르게 구현할 수 있습니다. 하지만 개발자가 보안 요구사항을 명확하게 설명하지 않거나, AI가 작성한 코드를 충분히 검토하지 않으면 예상하지 못한 취약점이 남을 수 있습니다.

기능이 작동하는 것과 안전한 것은 다릅니다

예를 들어 관리자 화면이 정상적으로 열리고 학생 기록이 저장된다고 가정해 보겠습니다. 화면에서는 문제가 없어 보여도 다른 사용자가 관리자 권한을 얻거나 다른 학급의 기록을 조회할 수 있다면 안전한 앱이라고 할 수 없습니다.

웹 애플리케이션 보안 위험을 정리한 OWASP Top 10:2025에서도 접근 제어 실패, 보안 설정 오류, 소프트웨어 공급망 문제, 인젝션 등을 주요 위험으로 다루고 있습니다.

따라서 바이브코딩으로 앱을 만들 때는 기능 구현뿐 아니라 데이터 보호, 권한 확인, 비밀 정보 관리까지 함께 고려해야 합니다.

---

2. 첫 번째 취약점: 입력값 검증과 SQL Injection·XSS

2-1. 입력값 검증이란?

입력값 검증은 사용자가 입력한 데이터가 올바른 형식과 허용 범위에 맞는지 확인하는 과정입니다.

예를 들어 학생 번호를 입력하는 기능이 있다면 다음과 같은 사항을 확인할 수 있습니다.

• 필수 입력값이 비어 있지 않은가?
• 학번이 정해진 형식에 맞는가?
• 허용된 길이나 범위를 벗어나지 않았는가?
• 사용자가 해당 기록을 입력하거나 수정할 권한이 있는가?

입력값 검증은 단순히 잘못된 입력을 거부하는 데 그치지 않습니다. 입력한 데이터가 프로그램의 명령으로 해석되지 않도록 안전하게 처리하는 것도 중요합니다.

2-2. SQL Injection이란?

SQL은 데이터베이스에 정보를 저장하거나 조회·수정·삭제할 때 사용하는 언어입니다. SQL Injection은 사용자가 입력한 내용이 데이터베이스 명령에 영향을 주어 프로그램이 의도하지 않은 작업을 수행하게 만드는 취약점입니다.

쉽게 비유하면 은행 창구에서 이름을 적으라고 했는데, 직원이 그 내용을 이름이 아니라 금고를 여는 명령으로 해석해 버리는 상황과 비슷합니다.

이러한 취약점이 발생하면 데이터베이스의 구조와 권한에 따라 정보가 노출되거나 수정·삭제될 수 있습니다.

SQL Injection 예방 방법

• 매개변수화된 쿼리 사용: SQL 명령과 입력 데이터를 분리해 처리합니다.
• 입력값 검증: 데이터의 형식과 허용 범위를 확인합니다.
• 최소 권한 원칙: 데이터베이스 계정에 필요한 권한만 부여합니다.
• 실제 요청 경로 점검: 데이터 조회·수정·삭제가 이루어지는 모든 경로를 확인합니다.

특히 입력값에서 특수문자를 무조건 삭제하는 방식만으로는 SQL Injection을 충분히 예방할 수 없습니다. 데이터베이스 쿼리를 안전하게 작성하는 것이 중요합니다.

2-3. XSS는 무엇일까?

XSS(Cross-Site Scripting)는 웹사이트에 입력된 내용이 안전하지 않게 처리되어 다른 사용자의 브라우저에서 스크립트로 실행되는 취약점입니다.

예를 들어 게시판이나 댓글 기능에서 사용자 입력을 안전하게 처리하지 않으면 공격자가 삽입한 스크립트가 다른 사용자의 브라우저에서 실행될 수 있습니다.

XSS를 예방하려면 다음과 같은 방법을 고려해야 합니다.

• 사용자 입력을 화면에 표시할 때 안전한 출력 처리를 적용합니다.
• HTML을 직접 삽입하는 기능은 필요한 경우에만 사용합니다.
• HTML을 허용해야 한다면 허용할 요소와 속성을 제한합니다.
• 사용 중인 프레임워크의 자동 이스케이프 기능을 올바르게 활용합니다.

SQL Injection은 주로 데이터베이스 명령 처리와 관련되고, XSS는 브라우저에서 콘텐츠가 처리되는 방식과 관련됩니다. 두 취약점은 발생 원리와 예방 방법이 다르므로 각각 점검해야 합니다.

핵심 정리: 사용자 입력을 무조건 신뢰하지 말고, 데이터베이스 쿼리와 화면 출력 단계에서 각각 안전한 처리 방법을 적용해야 합니다.

---

3. 두 번째 취약점: 클라이언트 측 인증과 권한 우회

3-1. 클라이언트와 서버의 차이

웹앱의 보안을 이해하려면 먼저 클라이언트와 서버의 차이를 알아야 합니다.

• 클라이언트: 사용자가 보는 브라우저나 앱 화면입니다. 버튼, 메뉴, 입력창 등을 표시하고 사용자 요청을 전달합니다.
• 서버: 요청을 처리하고, 데이터베이스에 접근하며, 사용자의 신원과 권한을 검증할 수 있는 영역입니다.

클라이언트는 건물의 안내판과 출입문, 서버는 실제 출입 자격을 확인하는 보안 담당자라고 생각하면 이해하기 쉽습니다.

화면에 '관리자 전용'이라고 표시하거나 관리자 메뉴를 숨기는 것만으로는 실제 접근을 차단할 수 없습니다. 보호해야 할 데이터와 기능은 신뢰할 수 있는 서버 측 코드나 서버리스 API 등에서 권한을 검증해야 합니다.

3-2. localStorage에 관리자 여부를 저장하면 왜 위험할까?

localStorage는 브라우저에 문자열 형태의 데이터를 저장하는 기능입니다. 설정값이나 간단한 기록을 보관할 때 유용하지만, 사용자가 개발자 도구 등을 통해 값을 변경할 수 있습니다.

예를 들어 다음과 같은 구조를 생각해 보겠습니다.

isAdmin = true

앱이 이 값만 확인해 관리자 화면을 열어 주거나 기록 수정 권한을 인정한다면, 사용자가 값을 변경해 권한을 우회할 가능성이 있습니다.

따라서 localStorage에 저장된 관리자 여부를 실제 권한의 증거로 사용해서는 안 됩니다.

3-3. 인증과 권한 부여는 다릅니다

• 인증(Authentication): 사용자가 누구인지 확인하는 과정입니다. 예를 들어 로그인을 통해 계정을 확인합니다.
• 권한 부여(Authorization): 해당 사용자가 어떤 데이터와 기능에 접근할 수 있는지 결정하는 과정입니다.

로그인한 사용자라고 해서 모든 데이터에 접근할 수 있는 것은 아닙니다. 특정 교사가 자신의 학급 기록만 조회하고 수정할 수 있도록 하려면, 실제 요청이 들어올 때 해당 학급의 기록을 다룰 권한이 있는지 확인해야 합니다.

3-4. JWT를 사용하면 무조건 안전할까?

JWT(JSON Web Token)는 인증 관련 정보를 전달할 때 사용할 수 있는 토큰 형식입니다. 하지만 JWT를 사용한다는 사실만으로 보안이 자동으로 확보되는 것은 아닙니다.

토큰의 서명과 유효성을 올바르게 검증하고, 만료와 권한 확인 등을 적절하게 구현해야 합니다. 서버 세션 방식도 사용할 수 있으므로 모든 서비스에 JWT가 반드시 필요한 것은 아닙니다.

핵심 정리: 화면에서 버튼을 숨기는 것과 실제 권한을 차단하는 것은 다릅니다. 보호해야 할 데이터와 기능은 실제 요청 처리 단계에서 권한을 검증해야 합니다.

---

4. 세 번째 취약점: API 키와 비밀번호 노출

4-1. API 키란?

API는 서로 다른 프로그램이나 서비스가 정해진 방식으로 정보를 주고받을 수 있도록 하는 인터페이스입니다.

API 키는 서비스에 요청을 보낼 때 사용자를 식별하거나 접근을 허용하는 데 사용될 수 있는 정보입니다. 키의 권한과 종류에 따라 다른 사람이 무단으로 사용하면 데이터 접근이나 예상하지 못한 비용 발생으로 이어질 수 있습니다.

예를 들어 AI API를 연결한 웹앱에서 비밀 키가 외부에 노출되면, 다른 사람이 해당 키를 이용해 요청을 보내고 소유자의 사용량이나 요금에 영향을 줄 수 있습니다.

4-2. 하드코딩이란?

하드코딩(Hardcoding)은 바뀔 수 있는 설정값이나 비밀 정보를 코드 안에 직접 입력해 두는 방식입니다.

코드에 데이터베이스 비밀번호나 비밀 API 키를 직접 적어 두면, 해당 파일이 공개 저장소에 올라가거나 브라우저에 전달되는 JavaScript에 포함될 때 다른 사람이 값을 확인할 수 있습니다.

4-3. 환경 변수와 .gitignore 활용하기

환경 변수는 프로그램 실행에 필요한 설정값을 코드와 분리해 전달하는 방법입니다. 서버에서 사용하는 비밀 정보는 서버 환경이나 비밀 정보 관리 기능에 보관하고 서버 측에서만 사용하도록 설계해야 합니다.

.gitignore는 Git이 특정 파일을 추적하지 않도록 지정하는 설정 파일입니다. 로컬 환경 설정 파일 등이 저장소에 올라가는 위험을 줄이는 데 도움이 됩니다.

예를 들어 .gitignore 파일에 다음과 같이 작성할 수 있습니다.

.env
.env.local

단, .gitignore에 파일을 추가했다고 해서 이미 저장소에 올라간 비밀 정보가 자동으로 삭제되거나 무효화되는 것은 아닙니다. 또한 프런트엔드 빌드 과정에서 브라우저에 포함된 환경 변수는 사용자가 확인할 수 있으므로 주의해야 합니다.

4-4. API 키가 이미 노출됐다면?

1. 노출된 키가 어떤 서비스와 연결되어 있는지 확인합니다.
2. 해당 키의 권한과 사용 내역을 확인합니다.
3. 서비스 제공자에서 기존 키를 폐기하거나 교체합니다.
4. 새 키를 안전한 서버 측 설정에 등록합니다.
5. 저장소 기록과 로그 등에 추가 노출이 없는지 확인합니다.
6. 비정상 사용이나 예상하지 못한 요금이 발생했는지 점검합니다.

이미 노출된 키는 코드에서 문자열을 삭제하는 것만으로 충분하지 않습니다. 다른 사람이 이미 키를 복사했을 수 있기 때문에 제공자 측에서 키를 폐기하거나 교체해야 합니다.

핵심 정리: API 키와 비밀번호는 공개 코드에 직접 입력하지 말고, 서버 측에서 안전하게 관리해야 합니다.

---

5. AI에게 보안 검토를 요청하는 방법

이미 웹앱을 만들어 배포했거나 코드가 완성된 상태라면 AI에게 보안 검토를 요청하는 것도 출발점이 될 수 있습니다.

다만 AI의 답변만으로 앱이 안전하다고 확정해서는 안 됩니다. 코드 검토는 실제 서버 설정, 데이터베이스 권한, 배포 환경 등을 모두 확인하지 못할 수 있기 때문입니다.

복사해서 사용하는 보안 검토 프롬프트

아래 프롬프트를 ChatGPT, Claude, Cursor 등 코드 검토가 가능한 AI 도구에 입력해 보세요. 코드나 프로젝트 파일을 제공할 때 활용할 수 있습니다.

너는 웹 애플리케이션 보안 검토 전문가다.

내가 제공하는 코드와 시스템 구조를 바탕으로
보안 취약점을 검토해 줘.

다음 항목을 반드시 확인해 줘.

1. SQL Injection 및 안전하지 않은 데이터베이스 쿼리
2. XSS 및 사용자 입력의 안전하지 않은 화면 출력
3. 인증 우회와 권한 검증 누락
4. 다른 사용자의 데이터에 대한 무단 접근 가능성
5. 관리자 권한을 브라우저 저장값만으로 판단하는 문제
6. 코드와 프런트엔드 파일에 포함된 API 키와 비밀번호
7. 환경 변수 및 비밀 정보 관리
8. 데이터베이스 접근 권한과 데이터 노출
9. 파일 업로드·다운로드와 백업 파일의 접근 통제
10. 데이터 삭제·변경·복원 과정의 위험

검토 결과는 다음 형식으로 작성해 줘.

- 발견한 문제
- 관련 코드 또는 설정
- 문제가 발생하는 이유
- 발생 가능한 피해
- 위험도와 판단 근거
- 권장 수정 방법
- 수정 후 확인할 테스트
- 코드만으로 확인할 수 없는 사항

실제로 확인한 내용과 추정한 내용을 구분해 줘.
확인하지 못한 서버 설정이나 데이터베이스 정책은
안전하다고 단정하지 마.

먼저 검토 보고서만 작성하고,
내 동의 없이 기존 코드를 변경하지 마.

이 프롬프트는 잠재적인 문제를 찾는 데 도움을 줄 수 있지만, 보안 검토를 완전히 대신하지는 않습니다. AI가 놓친 취약점이 있을 수 있으므로 실제 코드와 설정을 확인하고 테스트하는 과정이 필요합니다.

---

6. 웹앱 배포 전 보안 체크리스트

웹앱을 배포하기 전에는 다음 항목을 확인해 보세요. 모든 앱에 같은 조치가 필요한 것은 아니므로 실제로 사용하는 기능과 데이터 구조에 맞게 점검해야 합니다.

입력값과 데이터 처리

• 입력값의 형식과 허용 범위를 검증하는가?
• 데이터베이스 쿼리를 안전하게 처리하는가?
• 사용자 입력을 화면에 표시할 때 XSS 방어를 고려했는가?

인증과 권한

• 관리자 여부를 브라우저 저장값만으로 결정하지 않는가?
• 보호해야 할 서버 API에서 권한을 검증하는가?
• 사용자가 다른 사람의 데이터에 접근하거나 수정할 수 없는지 확인했는가?

비밀 정보

• API 키와 비밀번호가 공개 코드에 포함되어 있지 않은가?
• 비밀 정보가 브라우저에 전달되는 파일에 포함되어 있지 않은가?
• 저장소와 배포 환경에서 비밀 정보를 안전하게 관리하는가?

배포와 운영

• 실제 개인정보 대신 테스트 데이터를 이용해 점검했는가?
• 백업과 복원 절차 및 데이터 접근 범위를 확인했는가?
• 서비스의 보안 알림과 비정상 사용 내역을 확인할 수 있는가?

위 항목을 확인했다고 해서 모든 취약점이 제거되는 것은 아닙니다. 서비스의 구조와 위험 수준에 따라 추가 점검이 필요할 수 있습니다.

로그인 없는 HTML 웹앱도 보안 점검이 필요할까?

로그인 기능 없이 브라우저에만 데이터를 저장하는 간단한 웹앱과, 서버 데이터베이스에 여러 사용자의 개인정보를 저장하는 웹서비스는 위험 구조가 다릅니다.

브라우저에만 데이터를 저장하는 앱이라면 서버 측 인증이나 데이터베이스 접근 제어가 필요하지 않을 수도 있습니다. 하지만 같은 기기를 다른 사람이 사용할 수 있고, 백업 파일이 공유되거나 학생 정보가 포함된 파일이 외부로 전달될 수 있습니다.

따라서 로그인 기능이 없다는 이유만으로 안전하다고 단정해서는 안 됩니다. 어떤 데이터를 처리하고 어디에 저장하며 누가 접근할 수 있는지부터 확인해야 합니다.

---

7. 자주 묻는 질문

Q1. 바이브코딩으로 만든 앱은 모두 보안에 취약한가요?

그렇지는 않습니다. 바이브코딩으로 만든 앱도 적절한 보안 설계와 검증을 거치면 안전하게 운영할 수 있습니다. 다만 AI가 생성한 코드라는 이유만으로 안전성을 보장할 수 없으므로 실제 코드와 설정을 확인해야 합니다.

Q2. 로그인 기능이 있으면 사용자 데이터가 안전한가요?

로그인은 사용자를 확인하는 과정입니다. 로그인한 사용자가 다른 사용자의 데이터에 접근하지 못하도록 별도의 권한 검증과 데이터 접근 제어가 필요합니다.

Q3. API 키를 .env 파일에 넣으면 무조건 안전한가요?

아닙니다. .env 파일은 설정값을 코드와 분리하는 데 도움이 되지만, 파일이 저장소에 올라가거나 비밀 정보가 브라우저 코드에 포함되면 노출될 수 있습니다. 실제 실행 환경과 배포 설정까지 확인해야 합니다.

Q4. AI에게 보안 검토를 요청하면 전문가 검토를 대신할 수 있나요?

AI는 잠재적인 취약점을 찾고 수정 방향을 제안하는 데 도움을 줄 수 있습니다. 그러나 모든 문제를 발견한다고 보장할 수 없으므로 중요한 데이터나 서비스라면 테스트와 전문적인 보안 검토를 고려해야 합니다.

Q5. 학생 기록을 저장하는 교사용 웹앱은 무엇을 특히 조심해야 하나요?

학생 정보의 저장 위치, 접근 가능한 사용자, 데이터 공유 범위, 백업 파일의 관리 방법을 먼저 확인해야 합니다. 여러 사용자가 서버를 통해 데이터를 공유한다면 사용자별 접근 권한과 데이터 분리 여부도 중요합니다. 실제 학생 데이터를 활용하기 전에는 학교의 개인정보 보호 담당자와 관련 지침을 확인하는 것이 좋습니다.

---

8. 공식 참고 자료 및 다음 공부

이번 글은 웹 애플리케이션 보안에 관한 공식 자료를 바탕으로 작성했습니다. 실제 개발 과정에서는 사용하는 프레임워크와 배포 환경에 맞는 추가 문서도 확인하세요.

• OWASP Top 10:2025 — 주요 웹 애플리케이션 보안 위험
• OWASP SQL Injection Prevention Cheat Sheet — SQL Injection 예방
• OWASP Cross Site Scripting Prevention Cheat Sheet — XSS 예방
• OWASP Authorization Cheat Sheet — 권한 검증과 접근 제어
• OWASP Secrets Management Cheat Sheet — 비밀 정보 관리
• GitHub 비밀 정보 노출 대응 가이드 — 노출된 키의 폐기와 교체

AI 웹도구 만들기 공부 시리즈

AI를 활용해 웹앱을 만드는 과정을 단계별로 공부하고 있다면, 이전 글과 연결해서 읽어 보세요.

• AI 웹도구 만들기 공부 1편｜HTML부터 AI까지, 내가 만든 웹도구는 어떻게 작동할까?
• AI 웹도구 만들기 공부 2편｜API Key와 서버는 왜 필요할까?
• AI 웹도구 만들기 공부 3편｜서버·호스팅·도메인·AI 비용은 어떻게 연결될까?
• AI 웹도구 만들기 공부 4편｜AI API를 연결하면 실제로 무슨 일이 일어날까?
• AI 웹도구 만들기 공부 5편｜나이스 Open API란? 학교정보를 내 웹앱으로 가져오기
• AI 웹도구 만들기 공부 6편｜데이터베이스·RESTful API·인증·디자인 패턴 이해하기

※ 위 목록의 제목은 시리즈 연결을 위한 안내입니다. 각 항목에 실제 게시글 주소를 연결한 뒤 발행하세요.

---

마무리

바이브코딩은 개발을 처음 시작하는 사람도 자신의 아이디어를 웹앱으로 구현할 수 있도록 도와줍니다. 하지만 기능을 빠르게 만드는 것과 안전하게 운영하는 것은 별개의 문제입니다.

이번 글에서 살펴본 세 가지를 기억하세요.

• 첫째, 사용자 입력을 안전하게 처리합니다.
• 둘째, 실제 데이터와 기능에 대한 접근 권한을 검증합니다.
• 셋째, API 키와 비밀번호 등 비밀 정보를 안전하게 관리합니다.

AI가 만든 코드를 무조건 믿기보다, 보안 요구사항을 명시하고 결과를 확인하는 습관이 중요합니다.

다음에는 AI 웹도구 만들기 과정에서 배운 내용을 실제 프로젝트에 적용하면서, 안전한 데이터 저장과 배포 전 점검 방법을 더 구체적으로 살펴보겠습니다.

공부하는 체육쌤
교사가 학교에서 업무가 막혔을 때 검색해서 해결할 수 있도록, 직접 공부하고 활용한 내용을 기록합니다.

▲ 목차로 돌아가기