요즘 AI 개발 도구를 보면 웹앱을 만드는 장벽이 정말 많이 낮아졌다는 생각이 든다.
예전에는 로그인, DB, 관리자 페이지, 결제, 배포까지 붙이려면 어느 정도 개발 경험이 필요했다.
그런데 이제는 기획만 어느 정도 명확하면 AI 도구의 도움을 받아 꽤 빠르게 MVP를 만들 수 있다.
이건 좋은 변화다.
하지만 문제는 그 다음이다.
웹앱을 만드는 속도는 빨라졌는데, 안전하게 배포하는 난이도는 그대로다.
기능은 눈에 보인다.
버튼이 안 눌리면 바로 알 수 있고, 페이지가 깨지면 바로 고칠 수 있다.
하지만 보안 문제는 다르다.
대부분은 사고가 나기 전까지 잘 보이지 않는다.
그래서 AI로 만든 웹앱을 배포하기 전에 최소한 어떤 것들을 확인해야 할지 정리해봤다.
1. 환경변수와 Secret이 노출되지 않았는가
가장 먼저 봐야 할 것은 민감정보 노출이다.
예를 들면 이런 것들이다.
.env파일- DB 접속 정보
- JWT Secret
- 관리자 계정 정보
- 서버용 API Secret
- 외부 서비스 Secret Key
- 테스트용 토큰
여기서 주의할 점이 있다.
모든 API Key가 곧바로 비밀값인 것은 아니다.
예를 들어 Firebase config나 Supabase anon key처럼 클라이언트에 공개되는 것을 전제로 설계된 값도 있다.
다만 이런 공개용 키는 Security Rules, RLS, API 권한 설정이 제대로 되어 있다는 전제에서만 안전하다.
반대로 서버에서만 써야 하는 secret key, service role key, DB password, JWT secret 같은 값은 프론트엔드 번들에 들어가면 안 된다.
Next.js에서는 NEXT_PUBLIC_ prefix가 붙은 환경변수가 브라우저로 전달될 수 있다.
Vite에서는 VITE_ prefix가 붙은 환경변수가 클라이언트 코드에 포함될 수 있다.
클라이언트로 전달되는 환경변수에는 secret을 넣으면 안 된다.
2. DB 권한이 너무 열려 있지 않은가
AI로 빠르게 만든 서비스에서 자주 걱정되는 부분은 DB 권한이다.
예를 들어 Supabase를 쓴다면 RLS(Row Level Security) 가 필요한 테이블에 제대로 적용되어 있는지 확인해야 한다.
Supabase 공식 문서에서도 노출된 schema의 테이블에는 RLS를 활성화해야 한다고 설명한다.
Firebase를 쓴다면 Security Rules 가 과하게 열려 있지 않은지 봐야 한다.
개발 중 편의를 위해 allow read, write: if true 같은 규칙을 쓰고 그대로 배포하면 누구나 데이터를 읽거나 수정할 수 있다.
문제는 기능 테스트만 하면 이런 권한 문제가 잘 드러나지 않는다는 점이다.
내 계정으로 로그인해서 내 데이터가 보이는 것은 정상이다.
하지만 다른 사람의 데이터까지 볼 수 있는지는 별도의 관점으로 확인해야 한다.
확인해야 할 질문은 단순하다.
- 로그인하지 않아도 데이터를 읽을 수 있는가?
- A 사용자가 B 사용자의 데이터를 볼 수 있는가?
- 클라이언트에서 임의의
userId를 바꿔 요청하면 데이터가 조회되는가? - 로그인만 하면 모든 사용자의 데이터를 볼 수 있는가?
- 관리자가 아닌 사용자가 관리자용 데이터를 볼 수 있는가?
이런 문제는 기능 버그라기보다 권한 설계 문제에 가깝다.
3. 관리자 페이지가 인증 없이 접근 가능하지 않은가
생각보다 흔한 실수는 관리자 페이지를 만든 뒤 접근 제어를 약하게 둔 채 배포하는 것이다.
예를 들면 이런 경로다.
/admin/dashboard/manage/test/dev/cms
관리자 페이지 경로가 존재하는 것 자체가 문제는 아니다.
문제는 인증과 권한 검사가 약한 경우다.
단순히 화면에서 버튼을 숨기는 것은 보안이 아니다.
서버/API 레벨에서 권한을 확인해야 한다.
예를 들어 일반 사용자가 관리자 화면 버튼을 볼 수 없더라도, 직접 API를 호출했을 때 관리자 기능이 실행된다면 문제가 된다.
4. 테스트 데이터와 샘플 계정이 남아 있지 않은가
MVP를 만들다 보면 테스트용 계정이나 샘플 데이터가 남아 있을 수 있다.
예를 들면 이런 것들이다.
test@test.comadmin/adminpassword123- 샘플 고객 정보
- 테스트 주문 데이터
- 임시 관리자 계정
- 개발 중 만든 공개 링크
배포 전에 테스트 계정과 샘플 데이터는 정리하는 게 좋다.
특히 개인정보처럼 보이는 더미 데이터도 외부에서는 실제 데이터처럼 보일 수 있다.
5. HTTPS와 보안 헤더가 설정되어 있는가
최소한 HTTPS는 기본이다.
그 다음으로는 보안 헤더도 확인할 수 있다.
대표적으로 이런 항목들이 있다.
Content-Security-PolicyStrict-Transport-SecurityX-Frame-OptionsX-Content-Type-OptionsReferrer-PolicyPermissions-Policy
보안 헤더가 없다고 해서 바로 해킹당하는 것은 아니다.
하지만 브라우저가 완화해줄 수 있는 일부 공격을 굳이 열어둘 필요는 없다.
특히 Content-Security-Policy는 스크립트, 이미지, iframe 등 리소스 로딩 출처를 제한해 XSS 같은 공격의 영향을 줄이는 데 도움을 줄 수 있다.
간단한 점검은 MDN HTTP Observatory 같은 도구로도 해볼 수 있다.
6. 파일 업로드 기능이 안전한가
파일 업로드는 생각보다 위험한 기능이다.
이미지 업로드 하나만 넣어도 확인할 것이 많다.
- 허용 확장자 allowlist
- 파일 크기 제한
- 서버 측 파일 타입 확인
- 파일 시그니처 검증
- 파일명 재생성
- 업로드 파일 저장 위치
- 공개 URL 접근 범위
- 사용자별 파일 접근 권한
- 악성 스크립트나 실행 가능한 파일 업로드 가능성
주의할 점은 Content-Type이나 MIME type만 믿으면 안 된다는 것이다.
이 값은 요청자가 조작할 수 있기 때문에, 보안 검증의 보조 수단으로 봐야 한다.
특히 스토리지 버킷을 public으로 열어놓은 경우, 의도하지 않은 파일이 외부에 노출될 수 있다.
파일 업로드는 단순 편의 기능이 아니라 보안 검토가 필요한 기능이다.
7. 에러 메시지가 너무 자세하지 않은가
개발 중에는 자세한 에러 메시지가 편하다.
하지만 운영 환경에서는 다르다.
에러 메시지에 이런 정보가 노출되면 좋지 않다.
- DB 테이블명
- SQL 쿼리
- 서버 경로
- 내부 API 주소
- Stack trace
- 사용 중인 프레임워크 버전
- 인증 처리 방식
운영 환경에서는 사용자에게 필요한 수준의 메시지만 보여주고, 자세한 에러는 서버 로그에서 확인하는 방식이 안전하다.
8. 개인정보 입력 폼이 있다면 더 조심해야 한다
문의폼, 회원가입, 예약, 결제, 상담 신청 같은 기능이 있다면 보안의 중요도는 올라간다.
단순 랜딩 페이지와 개인정보를 수집하는 웹앱은 다르게 봐야 한다.
최소한 이런 질문은 해봐야 한다.
- 어떤 개인정보를 수집하는가?
- 꼭 필요한 정보만 받고 있는가?
- 수집한 정보는 어디에 저장되는가?
- 관리자만 볼 수 있는가?
- 삭제 요청이 들어오면 지울 수 있는가?
- 개인정보처리방침은 준비되어 있는가?
기술적인 보안뿐 아니라 운영 관점의 보안도 필요하다.
마무리
AI 개발 도구 덕분에 웹앱을 만드는 속도는 훨씬 빨라졌다.
하지만 배포 전에 확인해야 할 보안 항목은 여전히 남아 있다.
오히려 이제는 개발 경험이 적은 사람도 로그인, DB, 결제, 관리자 페이지가 포함된 서비스를 만들 수 있기 때문에 “작은 서비스니까 괜찮겠지” 라고 넘기기 어려워졌다고 생각한다.
개인적으로는 앞으로 이런 질문이 더 중요해질 것 같다.
이 웹앱은 기능적으로 동작하는가?
그리고 외부에 공개돼도 괜찮은 상태인가?
요즘 이 주제에 관심이 생겨서, AI로 만든 웹앱이나 사이드 프로젝트를 배포하기 전에 확인할 수 있는 보안 점검 체크리스트를 더 정리해보려고 한다.
다음 글에서는 실제로 외부에서 확인할 수 있는 항목들, 예를 들면 HTTPS, 보안 헤더, 공개 파일, 관리자 경로, DNS 설정 같은 것들을 어떻게 점검할 수 있는지 정리해볼 예정이다.
참고자료
