바이브 코딩으로 만든 홈페이지, 공개 전 확인할 7가지

AI에게 부탁해 회원가입과 게시판이 있는 홈페이지를 만들었습니다. 내 컴퓨터에서는 잘 됩니다. 이제 도메인을 연결하고 사람들을 초대해도 될까요?

공개 전에는 권한, 비밀키, 업로드, 스팸 대응, 백업·복원, 모바일·검색, 운영비·유지보수까지 7가지를 확인해야 합니다. AI가 코드를 썼다는 사실보다, 실제로 검증했고 문제가 생겼을 때 고칠 사람이 있는지가 중요합니다.

이 글은 AI로 홈페이지·게시판을 만든 비개발자와 소규모 운영자를 위한 점검표입니다. 간단한 소개 페이지라면 회원·업로드 관련 항목은 해당하지 않을 수 있습니다. 반대로 결제·의료정보처럼 민감한 기능이 있다면 이 목록 외에 별도 전문 검토가 필요합니다.

화면은 완성됐지만, 운영은 시작하지 않은 상태

설명용 가상 사례입니다. 동네 독서모임 운영자가 AI로 커뮤니티를 만들었습니다. 가입, 글쓰기, 사진 첨부까지 됩니다. 하지만 테스트한 계정은 관리자 하나뿐입니다. 다른 회원 글을 수정할 수 없는지, 큰 사진을 올리면 어떻게 되는지, 서버가 고장 났을 때 복구할 수 있는지는 확인하지 않았습니다.

이 사이트를 위험하다고 단정할 수는 없습니다. 다만 ‘작동을 봤다’와 ‘공개할 준비를 확인했다’는 다릅니다. 가게 인테리어가 끝났다고 출입문 열쇠, 계산대, 소화기까지 점검된 것은 아닌 것과 같습니다.

다음 점검은 본인 소유의 테스트 환경에서 가짜 계정·데이터로 진행하세요. 실제 회원정보를 AI 대화창에 붙여 넣거나, 다른 사람의 사이트에서 보안 테스트를 해서는 안 됩니다.

1. 로그인만 되면 안전할까? 회원·관리자 권한부터 확인

인증은 ‘누구인지 확인하는 것’, 인가는 ‘무엇을 해도 되는지 결정하는 것’입니다. 로그인은 건물 출입증이고, 권한은 방마다 다른 열쇠에 가깝습니다.

회원 A가 로그인에 성공해도 회원 B의 글을 수정하거나 관리자 페이지를 사용할 수 있어서는 안 됩니다. 비공개 게시판은 목록뿐 아니라 글 상세와 첨부파일도 정책에 맞게 제한돼야 합니다.

OWASP는 기본적으로 접근을 거절하는 “Deny by Default”와 “Validate the Permissions on Every Request”를 권고합니다. 허용된 동작만 열고, 요청마다 권한을 확인하라는 뜻입니다. [1]

계정 네 종류로 같은 동작을 해보세요

위 표는 예시 정책입니다. 운영진 공동 편집처럼 다른 정책이 필요하면 먼저 규칙을 정하고 그 규칙대로 테스트하세요. 로그아웃과 재로그인, 권한 변경 뒤에도 같은 결과인지 확인합니다.

비개발자가 할 일: 다른 브라우저나 시크릿 창으로 계정을 분리해 화면과 결과를 확인합니다. 개발자에게 요청할 일: 테스트 환경에서 API를 직접 요청해도 서버가 거절하는지, 데이터베이스 접근 정책도 같은 경계를 지키는지 검증합니다. 화면에서 버튼이 안 보이는 것만으로는 통과가 아닙니다.

2. API 키와 회원정보가 브라우저에 보이지 않는가

AI API, 메일 발송, 저장소를 연결하다 보면 키를 입력하게 됩니다. 이때 공개가 전제된 식별자와 비공개 자격증명을 구분해야 합니다. 브라우저에 보이는 모든 키가 유출은 아니지만, 서버 전용 비밀키가 공개 코드에 들어가면 문제가 됩니다.

.env라는 파일에 저장했다는 이유만으로 보호되는 것은 아닙니다. 해당 값이 브라우저용 코드에 포함되거나 공개 저장소·로그에 기록되면 노출될 수 있습니다. 서비스 공식 문서에서 공개용인지 서버 전용인지 확인하고, 비밀키를 쓰는 요청은 적절한 서버 측 경로에서 처리하도록 검토해야 합니다.

값을 복사하지 말고, 관리 위치를 기록하세요

GitHub는 비밀정보가 Git 이력에 남을 수 있어, 파일을 지우는 것만으로 충분하지 않으며 노출된 자격증명을 폐기하고 교체해야 한다고 설명합니다. 노출을 발견했다면 키를 회수하고, 사용내역·권한·비용을 확인한 뒤 관련 코드를 수정하세요. [2]

회원정보도 확인해야 합니다. 일반 회원에게 전달되는 응답에 다른 회원의 이메일·전화번호 같은 불필요한 정보가 포함되지 않는지, 오류 로그에 비밀번호·토큰이 남지 않는지 검토하세요. 가입 시 수집 항목, 보관기간, 탈퇴·삭제 처리와 개인정보 안내도 별도로 정해야 합니다. 이 점검만으로 법적 의무가 모두 충족되는 것은 아닙니다.

완료 기준: 비밀키의 위치·접근자·회수 방법을 설명할 수 있고, 공개 저장소와 브라우저 코드·응답·로그의 노출 여부를 개발자가 점검했습니다.

3. 이미지 하나 올리는 기능에도 제한이 필요하다

사진 첨부가 된다는 것과, 어떤 파일이든 받아도 된다는 것은 다릅니다. 확장자, 파일 내용, 용량, 파일명, 저장 위치, 업로드·다운로드 권한을 함께 확인해야 합니다.

OWASP는 허용할 확장자를 제한하고 파일 크기 제한을 두며, 요청에 들어온 Content-Type은 위조될 수 있으므로 그대로 신뢰하지 말라고 권고합니다. 한 가지 검사만으로 전체 파일 안전성을 보장할 수는 없습니다. [3]

• 허용 형식: 이미지 전용이면 필요한 이미지 형식만 받는지 확인합니다.
• 용량·개수: 파일 하나, 게시글 하나, 사용자별 제한을 구분합니다.
• 권한: 비공개 글의 첨부파일 주소를 알아도 권한 없는 사용자가 내려받을 수 없어야 합니다.
• 입력 처리: 제목·댓글은 텍스트로, 서식 있는 본문은 허용된 형식으로 처리하는지 개발자가 검토합니다.
• 서버 검증: 브라우저의 파일 선택 제한을 우회해도 서버가 동일하게 제한해야 합니다.

사진 크기는 운영비와도 연결됩니다

다음은 설명용 가정이며 평균 사용량이 아닙니다. 원본 8MB 사진 3장을 한 페이지에 넣고, 캐시 없이 페이지가 1,000번 로드된다고 가정하겠습니다.

8MB × 3장 × 1,000회 = 24,000MB ≈ 24GB입니다. 장당 0.5MB로 줄이면 0.5MB × 3장 × 1,000회 = 1,500MB ≈ 1.5GB입니다. 같은 가정에서 이미지 전송량은 16분의 1이 됩니다.

계산은 1GB=1,000MB인 십진 단위입니다. 실제 전송량과 요금은 캐시, 지연 로딩, 이미지 변환, 봇 방문, 제공자의 과금 단위·무료 제공량에 따라 달라집니다. 따라서 이 예시를 실제 청구액으로 해석하면 안 됩니다.

비개발자가 할 일: 정상 이미지, 설정 한도를 넘는 이미지, 허용하지 않는 무해한 파일로 오류 안내를 확인합니다. 공격용 파일 대신 가짜 데이터로 검사하고, 입력값 검증·서식 정화·파일 실행 방지는 개발자에게 맡깁니다.

4. 회원이 늘기 전에 스팸·신고·제재를 준비하자

공개 게시판에는 회원뿐 아니라 자동 가입과 광고 댓글도 들어올 수 있습니다. 스팸이 쌓인 뒤 지우는 기능만 준비하기보다, 반복 행동을 줄이는 제한과 사람이 처리하는 절차를 함께 만들어야 합니다.

Google은 사용자 생성 스팸을 줄이기 위해 악용 방지 정책, 사용자 신고, 의심스러운 활동 검토, 자동 가입 방지와 모니터링을 안내합니다. 신뢰할 수 없는 사용자 링크에는 rel="ugc"나 nofollow 적용을 권고합니다. [4]

이 속성은 링크의 성격을 검색엔진에 알리는 것이지, 스팸 내용을 삭제하거나 악성 사이트 접속을 차단하는 기능은 아닙니다. CAPTCHA도 모든 스팸을 해결하는 만능 장치는 아닙니다.

완료 기준: 테스트 회원으로 신고를 접수하고, 운영자가 발견해 처리할 수 있습니다. 제재된 계정이 제한된 동작을 하지 못하는지도 확인합니다. 공개 게시판과 회원 전용 게시판의 검색·접근 정책은 구분하세요.

5. 백업이 있는가보다 중요한 질문: 실제 복원되는가

코드를 Git에 저장했다고 회원과 게시글까지 백업되는 것은 아닙니다. 데이터베이스에는 계정·글·댓글이, 업로드 저장소에는 사진·첨부파일이 있을 수 있습니다. 복구에 필요한 설정과 비밀정보도 안전한 별도 관리가 필요합니다.

CISA의 StopRansomware Guide는 중요 데이터의 오프라인·암호화 백업을 유지하고, 재해 복구 상황에서 백업의 가용성과 무결성을 정기적으로 시험하도록 권고합니다. 바이브 코딩만을 대상으로 한 연구가 아니라 일반적인 복구 원칙입니다. [5]

운영 서버 안에 백업 파일 하나만 두면 서버 장애나 계정 침해 때 함께 잃을 수 있습니다. 운영 환경과 분리된 보관, 접근 제한, 보관기간과 복구 책임자를 정하세요. 백업 자체에도 회원정보가 들어갈 수 있습니다.

복원 테스트는 이렇게 확인합니다

1. 마지막 정상 백업 시각과 DB·업로드 파일의 포함 범위를 확인합니다.
2. 운영 데이터를 덮어쓰지 않는 별도 테스트 환경을 준비합니다.
3. 접근을 제한한 상태에서 백업을 복원합니다. 메일·문자·결제 같은 외부 발송·청구 기능은 차단합니다.
4. 표본 계정 로그인, 글·댓글 연결, 이미지 표시를 확인합니다.
5. 복구에 걸린 시간, 빠진 데이터, 다음 점검일과 담당자를 기록합니다.

‘얼마나 잃어도 되는가’와 ‘얼마나 빨리 돌아와야 하는가’도 정해야 합니다. 예를 들어 하루 한 번 백업한다면, 백업 주기만 놓고 봐도 다음 백업 직전 장애 시 직전 백업 이후의 데이터가 빠질 수 있습니다. 백업 실패를 감지하지 못했다면 손실 범위는 더 커질 수 있습니다.

완료 기준: “백업 기능이 있다”가 아니라 “언제 만든 백업으로 무엇을 복원했고, 실제로 무엇이 돌아왔는지”를 기록했습니다.

6. 공개는 됐는데 왜 느리고 검색에는 안 나올까

개발자 컴퓨터에서 빠른 사이트가 휴대전화에서도 빠르다는 보장은 없습니다. 실제 휴대전화에서 가입, 글 읽기, 사진 업로드, 메뉴 이동을 해보세요. Wi-Fi뿐 아니라 이동통신 환경에서도 입력창 가림, 가로 넘침, 늦게 뜨는 버튼을 확인합니다.

모바일 성능: 점수보다 실제 경험

PageSpeed Insights에서 공개 페이지를 검사하고 실사용자 데이터와 실험실 측정을 구분해서 봅니다. web.dev가 안내하는 Core Web Vitals의 ‘좋음’ 기준은 다음과 같습니다. [6]

이 기준은 모바일·데스크톱을 나눠 실제 페이지 로드의 75번째 백분위에서 평가합니다. 한 번 실행한 테스트 결과가 실사용자 전체를 대표하지는 않습니다. 작은 신규 사이트는 현장 데이터가 충분하지 않을 수 있으므로, 실험실 진단과 직접 사용 테스트를 함께 활용하세요.

검색 노출: 접속 가능과 색인은 다릅니다

Google의 최소 기술 요건은 Googlebot이 차단되지 않고, 페이지가 HTTP 200으로 작동하며, 색인 생성 가능한 콘텐츠가 있는 것입니다. 이 요건을 충족해도 색인이나 검색 순위가 보장되지는 않습니다. [7]

• 공개할 글: 로그인 없이 열리고, 오류가 아닌 실제 본문이 보이는지 확인합니다.
• 검색 허용: 의도치 않은 noindex, Googlebot 차단, 잘못된 대표 주소 설정이 없는지 검토합니다.
• Search Console: URL 검사에서 색인 상태와 실제 URL 테스트 결과를 구분해 확인합니다.
• 사이트맵: 공개해야 하는 정상 URL을 제출하되, 제출 자체를 색인 완료로 보지 않습니다.

회원 전용 자료를 검색에 노출시키려고 공개로 바꾸지는 마세요. 검색 제외 태그와 접근 권한은 다릅니다. noindex는 비밀번호나 권한 검사 대신 쓰는 비공개 장치가 아닙니다. 성능 점수 100점 역시 검색 상위 노출 보증서가 아닙니다.

7. 내일부터 누가 고치고, 얼마까지 운영할 것인가

바이브 코딩에서 놓치기 쉬운 비용은 제작비보다 공개 후에 반복되는 비용과 관리 시간입니다. 도메인·호스팅뿐 아니라 DB, 이미지 저장, 전송량, 메일·문자, 유료 API와 유지보수를 합쳐야 합니다.

월 운영비 = 고정 요금 + 사용량 요금 + 유지보수 비용으로 나눠 적어보세요. 연간 도메인 비용은 월로 환산하되, 실제 결제 시점은 별도로 표시합니다. 무료 제공량과 초과 요금은 각 서비스의 현재 요금표로 확인해야 합니다.

주기는 정답이 아니라 운영 설계 예시입니다. 연락 가능한 실제 담당자를 적고, 예산 알림을 받을 사람과 한도를 정하세요. 예산 알림은 비용 발생을 멈추는 차단 장치가 아닙니다. 제공자가 실제 상한·차단 기능을 지원하는지 따로 확인해야 합니다.

수정 전에는 돌아갈 길부터 확인하세요

수정 내용을 테스트 환경에서 확인한 다음 배포하고, 잘못됐을 때 이전 버전으로 돌릴 절차를 준비합니다. DB 구조가 바뀌었다면 코드만 되돌리는 것으로 복구되지 않을 수 있습니다.

배포 뒤에는 로그인·글쓰기·업로드 같은 기존 기능도 다시 확인합니다. 오류 로그와 장애 알림이 어디로 가는지, 야간 장애 때 누가 판단하는지도 정해야 합니다.

GitHub도 Copilot 코드 리뷰가 모든 문제를 찾아낸다고 보장하지 않으며, 피드백을 검증하고 사람의 검토로 보완하라고 안내합니다. 이는 해당 도구의 공식 한계 설명입니다. 운영 관점에서도 AI 리뷰를 테스트·사람 검토의 대체물로 취급하지 않는 편이 합리적입니다. [8]

완료 기준: 장애 연락처, 예상 비용, 사용량 경고, 배포·롤백 절차를 한 곳에서 찾을 수 있습니다.

직접 개발·AI 제작·와플보드, 무엇을 직접 맡을까?

AI로 첫 화면을 만드는 것과, 회원이 활동하는 커뮤니티를 운영하는 것은 다른 일입니다. 그렇다고 모든 사이트를 처음부터 개발자에게 맡기거나, 반대로 모든 것을 AI로 새로 만들 필요는 없습니다.

AI는 제작 방식이고, 직접 개발이나 기존 플랫폼은 구현·운영 선택지입니다. 서로 완전히 배타적인 선택이 아닙니다. 중요한 것은 무엇을 직접 만들고 무엇을 기존 기능으로 해결할지 나누는 일입니다.

커뮤니티라면 운영 도구까지 비교하세요

와플보드의 문서에는 게시판 읽기·쓰기 등급 설정, 신고 접수·처리, 회원 그룹·제재 관리, 데이터베이스와 업로드 파일의 백업·복원이 안내돼 있습니다. 게시물 작성 간격과 작성량을 제한하는 서버 측 기능도 소스에서 확인할 수 있습니다.

커뮤니티가 목적이라면 이런 기능을 모두 새로 만들기 전에, 기존 기능이 필요한 운영 방식과 맞는지 비교할 수 있습니다. 제품 선택만으로 권한 설정, 신고 확인과 복원 점검이 끝나는 것은 아닙니다.

기능의 존재와 개별 사이트의 설정 완료·외부 보안 검증은 별개입니다. 자동 백업 주기, 분리 보관, 보관기간, 복원 지원과 추가 개발 범위는 적용 버전·계약·운영 환경에 따라 확인해야 합니다. 모든 사이트에 동일한 무손실 복구나 검색 상위 노출을 보장한다는 뜻은 아닙니다.

운영 범위는 기능 안내와 요금 안내를 함께 확인하세요. 무료 제작과 실제 운영비의 차이는 무료 홈페이지의 기능·비용 제한 글에서, 운영 중인 사이트를 살펴볼 때는 커뮤니티 순위에서 참고할 수 있습니다. 방문량은 개별 사이트의 보안이나 수익성을 증명하지는 않습니다.

공개 전 최종 체크리스트

각 항목에 ‘완료’만 적지 말고, 확인한 날짜와 담당자를 함께 남겨보세요. 검토하지 못한 항목을 AI의 답변만으로 통과 처리하지 않는 것이 중요합니다.

7가지를 확인했다고 완전한 보안 인증을 받은 것은 아닙니다. 그래도 ‘일단 열어보고 생각하자’보다 운영 책임과 미확인 위험이 훨씬 분명해집니다. 다른 회원의 비공개 자료 접근, 비밀키 노출, 복원 불가처럼 중대한 문제가 확인됐다면 해당 기능의 공개를 미루고 먼저 해결하세요.

자주 묻는 질문

바이브 코딩으로 만든 사이트는 전부 위험한가요?

그렇게 단정할 근거는 없습니다. AI 사용 여부만으로 안전성을 판단할 수는 없습니다. 데이터의 민감도, 권한 설계, 실제 테스트, 배포·유지보수 상태를 확인해야 합니다. 사람이 만든 사이트도 같은 점검이 필요합니다.

로그인 기능만 붙이면 회원정보가 보호되나요?

아닙니다. 로그인 이후에도 누가 어떤 글·파일·관리 기능에 접근할 수 있는지 서버가 판단해야 합니다. 회원 A와 B로 계정을 나눠 테스트하는 이유입니다.

무료 호스팅으로 시작해도 되나요?

가능할 수 있습니다. 다만 무료 범위, 상업적 사용 조건, 데이터 보관, 초과 요금, 백업·복구와 이전 방법을 확인하세요. 무료 요금은 운영 책임까지 없애주지 않습니다.

검색 등록을 하면 바로 Google에 나오나요?

아닙니다. 사이트맵 제출이나 색인 요청은 발견·재확인을 돕는 절차입니다. 크롤링 가능, 정상 응답과 콘텐츠 요건을 충족해도 색인·시점·순위를 보장하지 않습니다.

와플보드를 쓰면 이 점검은 필요 없나요?

여전히 필요합니다. 기존 운영 기능을 활용할 수 있지만, 게시판 권한과 공개 범위를 정하고 신고를 처리하며 백업·복원 범위와 운영 책임을 확인하는 일은 남습니다.

AI를 포기할 필요는 없습니다. 공개 기준을 정하면 됩니다

바이브 코딩은 아이디어를 빠르게 화면으로 옮기는 데 도움이 됩니다. 그다음 단계는 기능을 더 붙이는 것만이 아니라, 누가 접근하고, 무엇을 저장하며, 문제가 생기면 어떻게 돌아올지를 정하는 일입니다.

간단한 소개 페이지는 가볍게, 독특한 업무 기능은 맞춤 개발로, 회원 커뮤니티의 반복적인 운영 기능은 기존 도구로 해결할 수 있습니다. 제작 방식보다 운영 목적에 맞는 조합을 고르세요.

만들려는 커뮤니티의 기능과 운영 범위를 알려주세요. 와플보드 기본 기능으로 가능한 부분과 별도 개발이 필요한 부분을 나눠 문의하기.

참고자료

원문·제품 문서 확인일: 2026년 10월 15일. 아래 자료는 일반적인 웹 운영 원칙이며, 특정 사이트가 검증됐다는 인증이나 바이브 코딩 전체의 사고율 통계가 아닙니다. 이미지 3개는 AI로 제작한 설명용 이미지입니다.

1. OWASP — Authorization Cheat Sheet: 기본 거절, 요청별 권한 검사.
2. GitHub Docs — Secret leakage risks: 저장소 이력에 남는 비밀정보와 자격증명 회수·교체.
3. OWASP — File Upload Cheat Sheet: 형식·용량·권한 검증과 다층 방어.
4. Google Search Central — 사용자 생성 스팸 방지: 신고·검토·자동 가입 방지·모니터링. 원문 최종 업데이트 2025-12-18.
5. CISA — #StopRansomware Guide: 분리된 백업과 정기 복원 시험.
6. web.dev — Web Vitals: LCP·INP·CLS 기준과 실사용자 75번째 백분위.
7. Google Search Central — 기술 요구사항: Googlebot 접근·HTTP 200·색인 가능한 콘텐츠. 원문 최종 업데이트 2025-12-18.
8. GitHub Docs — About GitHub Copilot code review: AI 리뷰 피드백 검증과 사람 검토.
9. 와플보드 제품 문서: 게시판 · 신고 · 회원 관리 · 백업·복원. 작성 제한은 서버 소스도 확인했으며, 개별 배포 환경의 실동작 전체를 이 글에서 시험한 것은 아닙니다.