AI와 바이브코딩으로 만든 MVP가 화면에서 잘 작동한다고 해서 곧바로 운영 가능한 서비스가 되는 것은 아닙니다. 회원가입, 문의, 결제, 고객정보 저장 기능을 붙이는 순간부터는 누가 어떤 데이터에 접근할 수 있는지, 오류를 어떻게 추적할지, 문제가 생겼을 때 어떻게 복구할지까지 설계해야 합니다.
작동하는 데모는 정상적인 사용 흐름을 보여주는 데 집중할 수 있습니다. 반면 운영 가능한 웹서비스는 잘못된 요청, 권한 없는 접근, 결제 콜백 중복, 외부 서비스 오류, 관리자 계정 탈취, 데이터 손실 같은 상황에도 대응할 수 있어야 합니다. 공개 배포 전 다음 일곱 가지 안전장치를 점검해 보세요.
1. 로그인보다 먼저 객체 단위 권한을 설계합니다
로그인 기능이 있다는 사실만으로 고객·주문·문의 데이터가 보호되지는 않습니다. 권한 설계의 기본값은 접근 허용이 아니라 접근 거부로 두고, 각 역할에는 업무에 필요한 최소 권한만 부여해야 합니다.
특히 주소창, 폼, API 요청 등에 포함된 사용자 입력 ID를 기준으로 고객정보나 주문을 조회하는 기능을 주의해야 합니다. 고객·주문·문의 같은 객체를 조회·수정·삭제하는 모든 API에서 서버가 현재 사용자에게 해당 객체를 다룰 권한이 있는지 확인해야 합니다. 화면에서 버튼을 숨기거나 클라이언트 코드에서만 검사하는 방식으로는 충분하지 않습니다.
배포 전 확인할 질문
고객, 일반 직원, 운영자, 관리자 역할별로 접근 가능한 데이터와 수행 가능한 작업이 구분되어 있는지 확인합니다. 또한 요청에 포함된 ID를 다른 값으로 바꾸더라도 다른 고객의 주문이나 문의를 열람·변경할 수 없도록 서버 측 검사가 적용됐는지 살펴봐야 합니다.
근거: OWASP Authorization Cheat Sheet
2. 고객정보는 사용할 목적이 분명한 항목만 받습니다
MVP 단계에서는 나중에 활용할 가능성을 이유로 고객정보 항목을 늘리기 쉽습니다. 그러나 고객정보는 서비스 목적에 필요한 범위로만 수집하고 보유해야 합니다. 어떤 개인정보가 왜 필요한지 설명할 수 없다면 수집 항목을 다시 검토해야 합니다.
회원가입, 문의 접수, 결제 과정에서 입력받는 항목을 각각 나누어 살펴보는 것이 좋습니다. 각 항목에 대해 사용 목적과 보유 필요성을 확인하고, 필요한 개인정보만 수집·보유한다는 점을 입증할 수 있는 절차도 마련해야 합니다.
기능 목록과 개인정보 목록을 함께 검토합니다
기능이 먼저 정해지고 개인정보 입력란이 관성적으로 추가되지 않도록 해야 합니다. 서비스 목적, 입력 항목, 저장 여부를 함께 검토하면 불필요한 수집을 발견하기 쉬워집니다.
근거: ICO Guide to Data Minimisation
3. API 키와 비밀번호를 코드에서 분리합니다
결제대행사 API 키, 데이터베이스 비밀번호, 인증서 같은 비밀정보를 소스 코드에 직접 적거나 버전관리 시스템에 저장해서는 안 됩니다. 개발이 빠르게 진행되는 바이브코딩 프로젝트일수록 설정값과 코드가 섞이지 않았는지 공개 전 확인해야 합니다.
비밀정보는 전용 시크릿 관리 체계에 중앙화하고, 접근할 수 있는 계정과 시스템을 최소화해야 합니다. 운영 중에는 비밀정보의 회전과 폐기, 접근 내역 감사가 가능하도록 관리하는 것이 권장됩니다.
코드에서 지우는 것으로 끝나지 않습니다
현재 파일에 키가 보이지 않는지만 확인할 것이 아니라 버전관리 시스템에 비밀정보가 포함돼 있지 않은지도 검토해야 합니다. 누가 비밀정보에 접근할 수 있는지, 교체와 폐기 과정을 관리할 수 있는지도 운영 준비 항목에 포함해야 합니다.
근거: OWASP Secrets Management Cheat Sheet
4. 결제 결과를 서버에서 검증하고 오류를 추적합니다
결제 완료 화면으로 이동했다는 사실만 보고 주문을 완료 처리하면 안 됩니다. 브라우저 리다이렉트에 포함된 값을 그대로 신뢰하지 말고, 서버가 결제대행사 API를 통해 결제 상태, 금액, 통화, 주문 ID를 확인해야 합니다.
결제 콜백은 서명을 검증해야 하며, 같은 콜백이 중복으로 도착하더라도 주문 처리는 한 번만 일어나도록 멱등성을 구현해야 합니다. 이는 결제 화면이 정상적으로 보이는지와는 별개의 운영 안전장치입니다.
문의·결제·로그인 오류를 운영 중 추적하려면 어떤 사건을 로그로 남길지도 정해야 합니다. 인증 성공과 실패, 애플리케이션 오류, 외부 서비스 오류, 권한 변경, 민감 데이터 접근, 사용자 생성 콘텐츠의 제출과 처리 등이 로그 대상에 포함됩니다.
오류 메시지보다 처리 경로를 확인합니다
테스트에서는 오류 화면이 표시되는지만 보지 말고, 서버 검증이 수행됐는지, 중복 요청이 한 번만 처리되는지, 관련 사건을 로그에서 추적할 수 있는지까지 확인해야 합니다.
근거: OWASP Third Party Payment Gateway Integration Cheat Sheet, OWASP Logging Cheat Sheet
5. 관리자 화면은 별도 계정과 MFA로 보호합니다
관리자 화면은 고객정보, 문의 내역, 주문이나 금융 데이터에 접근할 수 있으므로 일반 사용자 화면과 같은 수준으로 다뤄서는 안 됩니다. 관리자 화면과 고객·금융 데이터에 접근하는 계정에는 다중요소 인증인 MFA를 요구해야 합니다.
일상 업무용 계정과 관리자 계정도 분리해야 합니다. CISA는 관리자 계정과 민감 데이터를 다루는 직원부터 MFA를 적용하고, 권한 계정을 정기적으로 검토할 것을 권고합니다.
관리자라는 하나의 역할로 묶지 않습니다
관리자 화면에 접속할 수 있다는 이유만으로 모든 기능과 데이터에 접근하게 하지 말고, 실제 업무에 필요한 최소 권한만 부여해야 합니다. 운영 인력이 바뀌거나 업무 범위가 달라졌을 때 권한 계정을 다시 검토할 수 있어야 합니다.
근거: CISA Require Multifactor Authentication
6. 백업 파일이 아니라 복구 가능성을 확인합니다
백업이 자동 생성된다는 설정만으로는 데이터 복구를 보장할 수 없습니다. 중요 데이터의 오프라인·암호화 백업을 유지하고, 재해 복구 상황에서 백업의 가용성과 무결성을 확인해야 합니다.
실제 복구 절차도 정기적으로 시험해야 합니다. 백업이 존재하는지 확인하는 것과 그 백업으로 서비스를 복구할 수 있는지 검증하는 것은 다른 일입니다.
복구 시험까지 운영 절차에 포함합니다
어떤 데이터를 중요 데이터로 관리할지, 백업이 오프라인·암호화 상태로 유지되는지, 복구 과정에서 가용성과 무결성을 어떻게 확인할지를 정해야 합니다. 복구 절차를 실제로 시험하지 않았다면 백업 준비가 끝났다고 보기 어렵습니다.
7. 배포 전 검수 책임자와 승인 기록을 남깁니다
AI가 코드를 생성했더라도 배포 여부를 판단하는 책임까지 자동화되는 것은 아닙니다. 공개 전에는 승인된 검토자가 변경사항을 확인하고, 승인되지 않은 코드가 기본 브랜치에 병합되지 않도록 브랜치·병합 보호를 적용할 수 있습니다.
보안 점검 결과도 개발 과정과 분리하지 않는 것이 중요합니다. 승인, 거절, 예외 요청을 개발 워크플로에 기록하면 어떤 변경이 어떤 판단을 거쳐 배포됐는지 확인할 수 있습니다.
마지막 확인자는 명확해야 합니다
배포 직전에는 변경사항을 검토할 승인된 담당자가 누구인지, 승인이 없으면 기본 브랜치에 병합되지 않는지, 보안 점검의 결정과 예외가 기록되는지를 확인해야 합니다. 검수 책임이 명확하지 않으면 빠른 개발 속도가 곧바로 빠른 배포로 이어질 수 있습니다.
근거: NIST NCCoE DevSecOps Functional Demonstration Scenarios
운영 가능한 MVP는 실패 상황까지 설계합니다
데모의 질문이 “정상적으로 작동하는가”라면 운영 서비스의 질문은 더 넓습니다. 권한 없는 요청을 거부하는지, 필요한 개인정보만 보유하는지, 비밀정보가 코드와 분리됐는지, 결제가 서버에서 검증되는지, 오류를 추적할 수 있는지, 관리자 계정이 보호되는지, 데이터를 실제로 복구할 수 있는지, 승인된 변경만 배포되는지를 함께 확인해야 합니다.
이 일곱 가지는 기능을 더 많이 만드는 작업이 아니라 이미 만든 기능을 실제 고객과 데이터가 있는 환경에서 운영할 수 있도록 경계를 세우는 작업입니다. 로그인·결제·고객정보 기능을 추가하기 전부터 설계에 반영할수록 데모와 운영 서비스 사이의 간격을 줄일 수 있습니다.