AI 웹앱은 작동한다는 이유만으로 배포하면 안 된다
바이브 코딩 도구를 이용하면 개발 경험이 많지 않아도 짧은 시간 안에 웹앱을 만들 수 있다. 원하는 기능을 자연어로 설명하면 AI가 화면을 구성하고 데이터베이스와 API까지 연결해 준다.
문제는 개발 화면에서 정상적으로 작동하는 것과 실제 사용자에게 안전한 서비스를 제공하는 것은 전혀 다른 문제라는 점이다. 회원가입 버튼이 작동하더라도 다른 사용자의 개인정보에 접근할 수 있으며, 환경변수를 잘못 설정하면 API 키가 외부에 노출될 수 있다.
AI 생성 코드를 무조건 의심할 필요는 없지만, 사람이 작성한 코드와 동일한 검증 절차를 거쳐야 한다. OWASP의 애플리케이션 보안 검증 표준도 웹 애플리케이션을 신뢰하기 위해 인증, 권한, 입력값, 데이터 보호와 같은 기술적 보안 통제를 점검하도록 안내한다. OWASP 애플리케이션 보안 검증 표준
다음은 AI가 만든 웹앱을 실제 서비스로 배포하기 전에 확인해야 할 20가지 항목이다.
1. 핵심 사용자 기능을 처음부터 끝까지 실행한다
웹앱의 주요 기능을 실제 사용자처럼 처음부터 끝까지 실행해야 한다. 회원가입, 로그인, 정보 수정, 데이터 생성과 삭제, 로그아웃까지 전체 흐름을 확인한다.
각각의 버튼만 따로 확인하면 단계 사이에서 발생하는 오류를 놓칠 수 있다. 회원가입 직후 로그인이 가능한지, 새로고침 후에도 로그인 상태가 유지되는지, 삭제한 데이터가 다시 표시되지 않는지 확인해야 한다.
2. 운영용 빌드가 정상적으로 완료되는지 확인한다
개발 환경에서는 경고가 있어도 웹앱이 실행될 수 있다. 그러나 운영용 빌드 과정에서는 타입 오류, 잘못된 파일 경로 또는 누락된 환경변수 때문에 배포가 실패할 수 있다.
사용하는 프레임워크의 빌드 명령을 실행하고 오류와 경고를 확인한다. 오류 검사를 끄거나 빌드 설정을 완화해 통과시키기보다 원인을 찾아 수정하는 것이 안전하다.
3. 테스트 페이지와 디버그 코드를 제거한다
AI가 기능을 확인하기 위해 만든 테스트 페이지, 임시 관리자 계정, 샘플 API와 디버그 출력이 프로젝트에 남아 있을 수 있다.
사용하지 않는 페이지와 파일을 제거하고 콘솔에 민감한 정보가 출력되지 않는지 확인한다. 관리자 기능을 테스트하기 위해 만든 우회 코드도 반드시 삭제해야 한다.
OWASP 웹 보안 테스트 가이드는 운영 배포 전에 불필요한 샘플 파일과 디버깅 기능을 제거하고 로깅 설정을 검토하도록 안내한다. OWASP 배포 설정 점검 가이드
4. 개발용 설정과 운영용 설정을 분리한다
로컬 개발 환경과 실제 운영 환경은 데이터베이스 주소, 도메인, API 주소와 보안 설정이 다르다. 개발용 설정이 운영 서버에 그대로 사용되면 테스트 데이터가 노출되거나 잘못된 서버에 정보가 저장될 수 있다.
개발, 테스트, 운영 환경의 환경변수를 구분하고 배포 플랫폼에 필요한 값이 모두 등록됐는지 확인한다. 운영 환경에서는 디버그 모드를 비활성화해야 한다.
5. API 키와 비밀번호가 코드에 포함됐는지 검사한다
API 키, 데이터베이스 비밀번호, 관리자 계정 정보가 소스 코드에 직접 들어가 있지 않은지 확인한다. 프런트엔드 코드는 사용자의 브라우저로 전달되므로 중요한 비밀정보를 숨길 수 없다.
민감한 값은 서버 환경변수에 저장해야 한다. 이미 공개 저장소에 올라간 API 키는 코드에서 삭제하는 것만으로 해결되지 않는다. 해당 키를 폐기하고 새로 발급해야 한다.
6. 설치한 패키지의 보안 상태를 확인한다
AI는 기능을 빠르게 구현하기 위해 여러 외부 패키지를 추가할 수 있다. 그중에는 더 이상 관리되지 않거나 알려진 취약점이 있는 패키지가 포함될 수 있다.
사용하지 않는 패키지를 제거하고 패키지 관리 도구의 보안 검사 기능을 실행한다. 업데이트할 때는 버전만 올리지 말고 기존 기능이 정상적으로 작동하는지 다시 테스트해야 한다.
7. 모든 사용자 입력값을 검증한다
회원가입 양식, 검색창, 댓글, 파일 업로드처럼 사용자가 값을 입력할 수 있는 모든 위치를 확인한다. 빈 값, 지나치게 긴 문자열, 잘못된 이메일 주소와 예상하지 못한 특수문자를 입력해 본다.
프런트엔드 검증만으로는 충분하지 않다. 사용자는 브라우저 검사를 우회해 서버에 직접 요청을 보낼 수 있으므로 서버에서도 입력값을 다시 검사해야 한다.
8. 로그인과 로그아웃이 안전하게 작동하는지 확인한다
올바른 계정으로 로그인할 수 있는지 확인하는 것뿐만 아니라 잘못된 비밀번호, 존재하지 않는 계정과 만료된 세션도 테스트해야 한다.
로그아웃 후 뒤로 가기 버튼을 눌렀을 때 개인정보 화면이 다시 표시되지 않는지 확인한다. 비밀번호 재설정 링크가 여러 번 사용되거나 다른 계정에 적용되지 않는지도 점검해야 한다.
9. 사용자별 접근 권한을 검사한다
로그인에 성공한 사용자라고 해서 모든 데이터에 접근할 수 있는 것은 아니다. 일반 사용자, 관리자와 로그인하지 않은 사용자의 권한을 구분해야 한다.
다른 사용자의 게시물 주소나 데이터 번호를 직접 입력했을 때 조회 또는 수정이 가능한지 확인한다. 화면에서 관리자 메뉴를 숨기는 것만으로는 보호되지 않으므로 서버와 데이터베이스에서도 권한을 검사해야 한다.
10. 데이터베이스 백업과 복구 방법을 준비한다
웹앱을 배포하기 전에 데이터베이스 백업 기능이 작동하는지 확인한다. 백업 파일이 존재한다는 사실만 확인하지 말고 실제로 복구할 수 있는지도 테스트하는 것이 좋다.
테이블 구조를 변경하는 작업이 있다면 기존 데이터가 손상되지 않는지 검증한다. 운영 데이터베이스에 직접 명령을 실행하기보다 테스트 환경에서 먼저 마이그레이션을 연습해야 한다.
11. 외부 API 실패 상황을 처리한다
결제, 이메일, 지도, AI 모델처럼 외부 서비스를 이용하는 웹앱은 해당 서비스에 장애가 발생할 수 있다는 점을 고려해야 한다.
응답이 늦거나 연결이 끊겼을 때 화면이 계속 멈춰 있지 않은지 확인한다. 타임아웃, 재시도 횟수와 사용자 안내 메시지를 설정하고 동일한 요청이 중복 실행되지 않도록 처리해야 한다.
12. HTTPS와 쿠키 보안 설정을 확인한다
운영 웹앱은 HTTPS를 사용해야 한다. 로그인 정보를 저장하는 쿠키에는 필요한 보안 속성이 적용됐는지 확인한다.
웹사이트가 HTTP 주소로 접속됐을 때 HTTPS로 이동하는지, 인증서 오류가 없는지도 점검한다. 콘텐츠 보안 정책과 기타 HTTP 보안 헤더도 서비스 환경에 맞게 설정하는 것이 좋다.
13. 오류 메시지와 로그에서 개인정보를 제거한다
사용자에게 데이터베이스 구조, 파일 경로 또는 서버 내부 정보가 포함된 오류 메시지를 그대로 보여줘서는 안 된다. 화면에는 이해하기 쉬운 안내를 표시하고 자세한 오류는 접근이 제한된 서버 로그에 기록한다.
로그에도 비밀번호, 인증 토큰, API 키와 같은 값이 저장되지 않도록 해야 한다. 보안 관련 사건을 조사할 수 있을 정도의 정보는 남기되 불필요한 개인정보는 기록하지 않는 것이 원칙이다.
14. 자동화 테스트를 실행한다
단위 테스트, 통합 테스트와 브라우저 자동화 테스트가 있다면 모두 실행한다. 테스트가 없는 프로젝트라면 로그인, 권한, 데이터 저장처럼 중요한 기능부터 테스트를 추가한다.
성공하는 상황만 검사하지 말고 서버 장애, 잘못된 입력값과 권한이 없는 접근도 포함해야 한다. AI가 작성한 테스트 자체가 잘못될 수 있으므로 테스트가 실제 기능을 검증하는지도 살펴봐야 한다.
15. 모바일과 여러 브라우저에서 확인한다
개발에 사용한 브라우저에서 정상적으로 보인다고 해서 모든 사용자에게 동일하게 보이는 것은 아니다. 크롬, 엣지, 사파리와 모바일 환경에서 주요 화면을 확인한다.
작은 화면에서 버튼이 가려지거나 글자가 잘리는지, 입력창을 선택했을 때 화면이 깨지지 않는지 테스트한다. 터치하기 어려울 정도로 작은 버튼도 수정해야 한다.
16. 웹앱의 로딩 속도를 측정한다
용량이 큰 이미지와 불필요한 스크립트는 첫 화면이 표시되는 시간을 늦춘다. 개발자의 빠른 인터넷 환경에서는 문제가 보이지 않더라도 모바일 사용자는 불편을 겪을 수 있다.
이미지 크기를 줄이고 사용하지 않는 코드와 패키지를 제거한다. 같은 API가 반복 호출되거나 데이터베이스 전체 내용을 한 번에 가져오고 있지 않은지도 확인해야 한다.
17. 키보드와 보조기기 접근성을 확인한다
마우스를 사용하지 않고 키보드만으로 메뉴, 입력창과 버튼을 이동할 수 있는지 테스트한다. 현재 선택된 요소가 화면에서 구분되는지도 확인한다.
이미지에는 내용을 설명하는 대체 텍스트를 제공하고 입력창에는 연결된 라벨을 사용해야 한다. 색상만으로 오류와 성공 상태를 구분하지 않는 것도 중요하다.
18. 검색 노출 설정과 메타데이터를 점검한다
페이지마다 내용을 설명하는 제목과 메타 설명을 설정한다. 대표 이미지, 공유 제목과 설명도 확인해 카카오톡이나 SNS에서 링크를 공유했을 때 올바른 정보가 표시되도록 한다.
운영 사이트가 실수로 검색 차단 상태로 배포되지 않았는지 robots 설정을 확인한다. 반대로 테스트 서버와 관리자 페이지는 검색 결과에 노출되지 않도록 설정해야 한다.
19. 개인정보 처리 내용을 확인한다
이메일, 이름, 접속 기록과 결제 정보 등을 수집한다면 어떤 정보를 왜 수집하는지 사용자에게 알려야 한다. 사용하지 않는 개인정보를 습관적으로 수집하지 않는 것이 좋다.
개인정보처리방침, 문의 방법과 서비스에 필요한 기본 안내 페이지를 준비한다. 외부 분석 도구나 광고 서비스를 사용한다면 해당 서비스가 어떤 데이터를 처리하는지도 확인해야 한다.
20. 장애 감지와 이전 버전 복구 방법을 준비한다
배포가 성공했다는 알림만으로 서비스가 정상이라고 판단해서는 안 된다. 실제 주소에 접속해 주요 기능을 다시 확인하고 서버 오류와 응답 속도를 감시할 방법을 마련해야 한다.
문제가 발생했을 때 이전 버전으로 되돌리는 절차도 준비한다. 배포 전에 복구 방법을 한 번 확인해 두면 장애가 발생했을 때 당황하지 않고 대응할 수 있다.
AI 웹앱 배포 체크리스트를 사용하는 방법
20개 항목을 한 번에 머릿속으로 확인하려고 하면 일부를 놓치기 쉽다. 문서나 프로젝트 관리 도구에 체크리스트를 만들어 항목별로 완료 여부와 확인 결과를 기록하는 것이 좋다.
문제를 발견했다면 AI에게 바로 전체 프로젝트를 다시 작성하도록 요청하지 말고 문제가 발생한 파일과 기능만 수정하도록 지시해야 한다. 수정 후에는 해당 항목뿐만 아니라 영향을 받을 수 있는 기존 기능도 다시 테스트한다.
OWASP 웹 보안 테스트 가이드는 개발 중 테스트뿐만 아니라 배포와 운영 단계에서도 설정과 보안 통제를 지속적으로 확인하는 접근을 권장한다. OWASP 웹 보안 테스트 가이드
마무리
AI가 만든 웹앱을 빠르게 완성하는 것과 안전하게 운영하는 것은 서로 다른 작업이다. 화면이 정상적으로 표시되고 주요 버튼이 작동하더라도 보안, 데이터 보호, 성능과 복구 방법이 준비되지 않았다면 배포를 서두르지 않는 것이 좋다.
배포 전에 기능, 빌드, 환경변수, 비밀정보, 패키지, 입력값, 인증, 권한, 데이터베이스, 외부 API, HTTPS, 로그, 테스트, 호환성, 성능, 접근성, SEO, 개인정보와 복구 절차를 차례로 확인하자.
이 체크리스트를 반복해서 사용하면 바이브 코딩의 빠른 개발 속도는 유지하면서 AI 생성 코드로 인해 발생할 수 있는 위험은 줄일 수 있다.