커피 한 모금 마시고 브라우저를 켰는데 화면이 통째로 빨간색이에요. "위험한 사이트"라고요. Attackers on the site you tried visiting might trick you into installing software or revealing things like your passwords, phone, or credit card numbers.

방금 제가 올린 사이트인데요. 결제 기능 가맹 신청하려고 테스트 배포한 건데 피싱으로 분류됐어요. 기분이 참 묘했어요. 욕부터 나왔거든요.

상황

한 줄로 요약하면 이래요. 최근에 산 신규 도메인에 Next.js 앱 배포하고, 결제 페이지랑 구독 플로우 붙였는데, 런칭 며칠 만에 Google Safe Browsing 블랙리스트에 올랐어요.

Chrome, Firefox, Safari, Brave, Arc 전부 경고를 띄우더라고요. 브라우저 시장 95% 이상이 이 DB를 참조하니까 사실상 결제 사이트가 죽은 거예요. 실사용자도 못 들어오고, 심사관도 못 들어와요. 토스 심사 준비하던 중이었어서 타이밍 진짜 최악이었어요.

플래그된 URL이 더 황당해요

Google Search Console 켜서 보안 문제 탭 들어가봤어요. 플래그된 URL이 찍혀있는데요. 제가 만든 적 없는 서브도메인이었어요.

DNS 레코드에 그 이름은 아예 없어요. dig 때려봐도 응답 없고, curl도 안 닿아요. Wayback Machine에도 기록 없고요. 정말로 존재하지 않는 URL을 Google이 "여기에 피싱이 있습니다"라고 주장하는 상황이었어요. 이거 보고 한참 멍했어요. 뭐지 싶더라고요.

가능성을 좁혀봤는데요. 이전 주인의 흔적은 아니에요 — WHOIS 보니 최근 최초 등록된 도메인이거든요. 그럼 이메일 스푸핑 가능성이 남아요. 제 도메인에 SPF·DKIM·DMARC 같은 이메일 인프라가 걸려있으니까, 누군가 임의 서브도메인을 발신자로 스푸핑해서 피싱 메일을 보냈고 수신자가 신고했을 수 있어요. 아니면 그냥 Google 크롤러가 유추한 서브도메인을 외부 신고와 엉뚱하게 매칭했을 수도 있고요. 솔직히 저도 확신 못 해요.

결론은 제가 통제 못 하는 이유로 도메인 루트가 통째로 의심 리스트에 올라간 거예요.

근데 진짜 원인은 따로 있었어요

서브도메인 추적은 미궁이었지만, 활성 서브도메인 코드를 감사해보니 진짜 걸릴 만한 페이지가 있었어요. /service 경로에 남겨둔 QA 가이드 페이지.

심사용 스크린샷 찍으려고 만든 내부 안내 페이지였어요. 로그인, 결제, 구독 플로우 순서대로 링크 나열한 페이지요. 각 단계에 테스트 계정 평문이랑 "여기 결제하기 클릭" 안내가 있었어요. 저도 다시 열어보고 얼굴 뜨거워졌어요. 피싱 튜토리얼 같더라고요. 테스트 계정 평문 + 결제 유도 단계 + 단계별 클릭 지시. Google 자동 크롤러가 보면 피싱 훈련 키트로 분류하기 딱 좋은 패턴이에요.

제가 운영하는 다른 결제 사이트에도 비슷한 하드코딩 테스트 계정이 서버 코드에 남아있었는데 그쪽은 플래그 안 됐어요. 둘을 비교해보니 답이 명확하더라고요. Google이 HTML로 읽을 수 있는 공개 페이지에 그 문구들이 노출된 게 결정적 차이예요. 서버 코드는 크롤러가 못 읽거든요.

production에 올라가 있는 게 근본 문제였죠. 개발 중에만 쓰려고 만들었는데 빌드·배포에 그대로 포함됐어요. /admin 네임스페이스 아래에 뒀거나, 환경변수로 gate 했어야 했는데 놓쳤어요. 지금 돌아보면 진짜 기본 실수예요.

Google이 이걸 왜 차단할 수 있는 거냐

솔직히 처음 경고 뜬 순간 욕부터 나왔어요. 무슨 권한이냐고요. 법적 권한은 없어요. Google이 운영하는 사설 블랙리스트 DB예요. 근데 문제는 Chrome·Firefox·Safari·Brave·Arc가 전부 이걸 참조한다는 거죠. Chrome 점유율만 65%고, Chromium 기반 포함하면 75% 넘어요. Safari는 iOS 때문에 별도 25% 안팎이고, Firefox도 Google Safe Browsing API를 씁니다.

즉 현실적으로 전 인터넷 트래픽의 95% 이상이 이 DB에 의해 통제돼요. Google이 "위험"이라고 판정하면 내 사이트는 사실상 죽어요. 사전 경고 없고, 구체 증거도 비공개고, 구제 경로는 Google Search Console 검토 요청 하나뿐이에요. 대기 시간은 몇 시간에서 수 주. EU에선 이 구조를 비판하는 규제 움직임이 있긴 한데 아직 실효 없어요. 한국에서 Google 본사 상대로 소송 걸 수도 있죠. 근데 변호사비만 나가요.

해제 타임라인

결과부터 적자면 조치 + 리뷰 요청 후 약 4시간 만에 해제됐어요.

타임라인은 대략 이래요. Google Safe Browsing 측 플래그 등재는 Search Console 상 최초 업데이트 시점으로 이틀 전이었고, 경고를 인지한 건 오늘 오후였어요. 바로 원인 추적 들어가서 /service 페이지 삭제하고, robots.txt 정상화하고, 재배포했어요. 같은 날 오후에 리뷰 요청을 2경로로 제출했어요. 하나는 Google Search Console 보안 문제 탭의 "검토 요청" 버튼이고, 다른 하나는 safebrowsing.google.com/safebrowsing/report_error 별도 폼이에요. 그리고 4시간쯤 지나고 나서 Search Console 상태가 "감지된 문제 없음"으로 바뀌었어요.

근데 어느 쪽 경로가 실제 해제를 촉발했는지 몰라요. Google이 해제 통지 자체를 안 해주고, 어느 채널에서 처리됐는지도 공개 안 하거든요. 두 경로가 내부적으로 같은 큐로 들어가는지, 별도로 돌아가는지도 불투명해요. 신경 써서 양쪽 다 제출해도 최종적으로는 "알아서 조용히 풀렸다"밖에 남지 않았어요.

실무 팁을 하나 드리면 두 경로 다 제출하세요. 어차피 5분 차이고, 하나가 먼저 돌아가면 좋으니까요.

진짜 화나는 건 피드백의 완전 부재

전체 프로세스 돌아보면 이런 식이에요. 차단 알림은 없어요. 브라우저 켜야 알게 돼요. 차단 사유 설명은 "피싱으로 분류됨" 한 줄. 어떤 시그널로 판정했는지 증거 공개 없어요. 검토 요청 후 상태 조회도 불가. 해제 알림도 없어요. Search Console 직접 확인해야 알게 돼요. 사후에 "뭐가 문제였는지" 최종 확인도 안 줘요.

하루 반 동안 결제 사이트 죽이고 "그냥 됐어요" 끝. 제3자가 신고하면 당사자는 신고 내용 못 보고, 소명 기회도 없이 차단부터. 인디 해커 입장에선 영업 중단 통보 + 원인 직접 추리 + 조치 + 증명 + 해제 확인까지 전부 혼자예요.

Google Safe Browsing은 인터넷 결제의 95%를 좌우하면서 due process가 없어요. 이게 진짜 문제라고 생각해요. 에어비앤비로 치면 숙소 예약 끊겼다가 설명 없이 다시 풀린 거랑 비슷하거든요. 근데 Google은 이걸 24시간 돌려요. 대안이 없고요.

터지기 전에 체크할 것

제가 당한 거 복붙 안 당하려면 런칭 전에 몇 가지 봐두세요. 중요도 순서로 정리했어요.

1. QA/데모 페이지를 프로덕션에 두지 마세요

이게 진짜 제일 중요해요. /admin, /demo, /test, /service 경로에 평문 테스트 계정이나 "여기 결제하세요" 안내가 HTML에 드러나 있으면 피싱 훈련 키트로 자동 분류될 확률 높아요. Google 크롤러는 공개 HTML만 보니까, 이 한 페이지가 있고 없고가 플래그 여부를 가릅니다. 환경변수로 gate 하거나, 아예 빌드에서 제외하거나, 스테이징 전용 도메인으로 분리하세요. 제 케이스는 이게 유일한 결정적 차이였어요.

2. robots.txt 설계

Disallow: /로 전체 차단하는 건 자주 쓰이지만 신뢰 신호로는 약간 마이너스예요. 이거 하나만으로 플래그 원인이 되진 않긴 해요. 다만 일반 페이지는 허용하고 민감 경로만 차단하는 게 깔끔하긴 합니다.

User-agent: *
Allow: /
Disallow: /api/
Disallow: /mypage
Disallow: /order
Disallow: /payment/

Sitemap: https://your-domain.com/sitemap.xml

3. 테스트 계정 하드코딩은 defense-in-depth 차원에서

서버 라우트에 테스트 계정을 박아두는 건 Safe Browsing 플래그의 직접 원인은 아니에요. 크롤러가 서버 코드를 못 읽거든요. 근데 소스맵 유출이나 번들 인라인으로 클라이언트에 노출되면 얘기가 달라지니까 환경변수로 빼는 게 좋아요.

4. 도메인 이메일 설정

SPF, DKIM, DMARC가 걸려있는 상태에서 Email Routing의 catch-all이 활성화되어 있으면 스푸핑 남용 공간이 열려요. 존재하지 않는 서브도메인이 피싱으로 플래그되는 이유 중 하나가 이거예요. Drop이나 특정 주소로 고정하세요.

5. Footer에 사업자 정보

신뢰 신호예요. 상호, 대표자, 사업자등록번호, 주소, 이용약관·개인정보처리방침 링크. 피싱 사이트는 보통 이게 없거든요. 이걸 명확히 넣어두는 게 피싱 오인 방지에 은근히 큰 영향을 미쳐요.

마무리

억울한 일이에요. "새 도메인에 결제 폼 올린 것 = 피싱 가능성 있음"이라는 휴리스틱에 걸린 거고, 사전 예방 기회 없이 차단 당한 다음에 구제 신청을 해야 해요. 풀릴 때도 통보 없이 조용히 풀려요. 다 끝나고도 "뭐가 원인이었는지" Google이 안 알려주니까, 제가 /service 페이지 때문이었다고 짐작할 뿐이에요. 실제로 그게 맞았는지도 확실하지 않아요.

그래도 실제 피싱이 이 정도로 많으니까 Google도 이 기준을 돌리는 거긴 할 거예요. 이해는 가요. 근데 피해자가 저 같은 인디 해커 + 신규 도메인 결제 사이트라는 게 구조의 함정이죠. 대기업은 법무팀이 대응하고, 저는 4시간 동안 DNS 뒤지고 코드 감사하고 있었고요.

교훈 하나만 챙겨가시면 돼요. 사용자에게 HTML로 보이는 공개 페이지에 테스트 계정이나 결제 유도 튜토리얼을 넣지 마세요. 그거 하나만 지켰어도 저는 이 글 안 썼을 거예요.

이 글 쓰고 난 뒤에 또 플래그 당하면 이 문장 추가해서 올릴게요. 솔직히 이 시스템 믿기 어려워요. 여러분도 비슷한 경험 있으시면 댓글이나 공유 부탁드려요. 이런 케이스 데이터 쌓이는 것만으로도 의미 있다고 생각해요.

참고 자료: Safe Browsing FAQs — Google / False Positive on Firebase — Google Cloud Community / 사기성 사이트 경고 해결 — kamilake / Safe Browsing flagged my site — dev.to / Netlify false positive thread