도메인 최대한 익명으로 보이게 하기 — 사이드 프로젝트 운영자를 위한 익명화 가이드

익명 커뮤니티 사이드 프로젝트를 운영 중입니다. 유저는 회원가입 없이 익명으로 글을 쓰는데, 정작 도메인을 연결하려고 보니 이런 생각이 들었습니다. "유저는 익명인데 운영자인 나는 WHOIS 한 방에 털리는 거 아닌가?"

도메인을 사기 전에 "운영자가 최대한 드러나지 않는 방법"을 조사했고, 결국 Cloudflare Registrar에서 nogari.org를 사서 Vercel에 연결하는 것까지 마쳤습니다. 조사부터 실제 연결·검증까지의 기록입니다. 미리 말하자면 결론은 이렇습니다:

"일반인이 아무리 파도 못 찾는" 수준은 쉽게 만들 수 있다. 하지만 "법적 절차로도 못 찾는" 완전 익명은 불가능하다.

이 차이를 이해하는 게 이 글의 절반입니다.

WHOIS 프라이버시의 진짜 의미

도메인을 등록하면 이름·이메일·주소·전화번호가 등록 정보로 들어갑니다. 예전에는 이게 WHOIS 조회로 전부 공개됐습니다. 지금은 GDPR 이후 대부분의 등록대행사(registrar)가 WHOIS 프라이버시(privacy protection)를 기본 제공해서, 조회하면 대행사의 프록시 정보가 대신 나옵니다.

여기서 중요한 것 하나:

WHOIS 프라이버시는 **"공개 조회에서 가리는 것"**이지, 대행사가 내 정보를 모르는 게 아니다.

ICANN 규정상 등록대행사는 실제 등록자 정보를 보관할 의무가 있습니다. 그래서 익명의 층위가 이렇게 나뉩니다:

층위	누가 나를 찾을 수 있나	달성 방법
0. 무방비	아무나 (WHOIS 조회)	프라이버시 없이 등록
1. 공개 익명	대행사, 결제사, 법원	WHOIS 프라이버시
2. 강한 익명	대리 등록 업체, (제한적으로) 법원	대리 소유 + 암호화폐 결제
3. 완전 익명	—	불가능 (결제·계정 흔적은 반드시 남음)

사이드 프로젝트 운영자가 현실적으로 목표할 곳은 1층, 예민한 주제라면 2층입니다.

사전 준비 — .kr은 시작부터 탈락

한국 국가 도메인(.kr, .co.kr)은 KISA 실명 기반 등록 체계라서 익명화가 구조적으로 어렵습니다. 익명성이 목표라면 처음부터 gTLD(.com, .net, .xyz, .chat, .club 등)로 가야 합니다.

.kr이 주는 신뢰감을 포기하는 대신, 익명성 외에도 얻는 게 있습니다 — 해외 대행사의 저렴한 가격과 자유로운 이전(transfer)입니다.

Step 1 — 등록대행사 선택: 실용파 vs 익명파

실용파: Cloudflare Registrar / Porkbun (1층)

WHOIS 프라이버시 기본 무료. 조회해도 이름·이메일·주소가 나오지 않습니다.
Cloudflare Registrar는 원가 판매(마진 0)라 갱신비가 업계 최저 수준이고, DNS까지 한 곳에서 관리됩니다.
Porkbun도 프라이버시 무료에 gTLD 선택지가 넓습니다.
한계: 대행사와 카드사에는 실명 기록이 남습니다. 법원 명령이 오면 신원이 나옵니다.

익명파: Njalla (2층)

스웨덴의 프라이버시 특화 서비스인데, 구조가 독특합니다:

Njalla가 자기 명의로 도메인을 등록하고, 나에게는 사용권을 준다.

WHOIS 어디에도 내 정보가 존재하지 않습니다. 프록시로 가린 게 아니라 애초에 등록자가 내가 아니니까요.
암호화폐 결제를 지원해서 결제 흔적도 최소화할 수 있습니다.
트레이드오프가 큽니다: 법적 소유자가 Njalla라서 분쟁이 생기면 도메인 소유권을 주장하기 어렵고, 가격도 일반 대행사의 1.5~2배입니다. 서비스가 커져서 도메인이 자산이 되는 순간 부담스러운 구조가 됩니다.

	Cloudflare / Porkbun	Njalla
WHOIS 공개 정보	프록시로 가림	아예 없음 (대리 소유)
대행사가 내 신원 보유	O	이메일 정도 (크립토 결제 시)
법적 도메인 소유권	나	Njalla
가격	원가~저렴	비쌈 ($15~/년)
추천 대상	대부분의 사이드 프로젝트	신원 노출이 곧 리스크인 경우

저는 개인 사이드 프로젝트 기준으로 Cloudflare Registrar + WHOIS 프라이버시면 충분하다고 결론 냈습니다. 유저·기자·호기심 많은 사람이 못 찾는 게 목표지, 수사기관을 피하려는 게 아니니까요.

Step 2 — 도메인 밖에서 새는 구멍 막기

도메인만 가려놓고 다른 데서 줄줄 새면 의미가 없습니다. 조사하면서 "아 이건 몰랐다" 싶었던 노출면들입니다.

1. 계정 이메일 — 사실 도메인보다 더 큰 구멍

Vercel, Supabase, 등록대행사 계정이 전부 개인 Gmail에 연결돼 있다면, 도메인 WHOIS를 가려봤자 서비스 어딘가에서 이메일이 노출되는 순간 끝입니다. (비밀번호 재설정 화면에서 마스킹된 이메일이 힌트가 되기도 합니다.)

프로젝트 전용 이메일을 새로 만듭니다 — Proton Mail 또는 SimpleLogin 별칭.
도메인 등록, 호스팅, DB 계정을 전부 이 이메일로 통일합니다.

2. DNS 레코드 — 원본 서버 IP 노출

A 레코드가 호스팅 서버 IP를 직접 가리키면, IP 역추적으로 인프라가 드러납니다. Cloudflare DNS의 프록시(주황 구름)를 켜면 외부에는 Cloudflare IP만 보입니다. Vercel 같은 PaaS는 어차피 공유 IP라 노출 부담이 적지만, 프록시를 한 겹 더 두면 추적이 확실히 어려워집니다.

3. GitHub 커밋 author — 저장소 공개하는 순간 실명 노출

이게 의외의 복병입니다. 저장소를 public으로 전환하면 모든 커밋의 author 이름·이메일이 그대로 공개됩니다. git log에 실명과 개인 이메일이 박혀 있다면, 사이트 푸터의 GitHub 링크 하나로 익명이 무너집니다.

# 내 저장소 커밋에 뭐가 박혀 있는지 확인
git log --format='%an <%ae>' | sort -u

공개 예정 저장소라면 GitHub의 noreply 이메일(123456+username@users.noreply.github.com)과 별칭 이름으로 커밋하도록 설정하세요.
이미 실명 커밋이 쌓였다면: 저장소를 비공개로 유지하거나, 히스토리 재작성(git filter-repo)이 필요합니다.

4. 사이트 콘텐츠 자체

푸터·소개 페이지·문의 이메일에 개인 식별 정보가 없는지
OG 메타태그, 에러 페이지, humans.txt 같은 곳에 이름이 없는지
이미지 EXIF (직접 찍은 사진을 올린다면 위치정보가 들어 있을 수 있습니다)

Step 3 — 실전: Cloudflare에서 사서 Vercel에 연결하기

저는 Cloudflare Registrar에서 nogari.org를 샀습니다. 연결은 Vercel CLI로 진행했는데, 실제로 해보니 문서에 없는 함정이 하나 있었습니다.

3-1. Vercel에 도메인 추가

vercel domains add nogari.org           # 계정에 도메인 등록
vercel domains add nogari.org nogari    # 프로젝트에 연결

그런데 두 번째 명령에서 이런 에러가 났습니다:

Your project's latest production deployment has errored.
Therefore, the domain cannot be assigned. (400)

최신 프로덕션 배포가 실패 상태면 도메인을 연결할 수 없습니다. 하필 직전에 푸시한 커밋(시드 스크립트의 타입 오류)이 빌드를 깨뜨려 놓은 상태였어요. 도메인 연결하려다가 빌드 고치기부터 하게 될 줄은 몰랐습니다. 로컬에서 tsc --noEmit을 통과시킨 커밋을 푸시하고, 배포가 Ready로 돌아온 뒤에야 연결이 됐습니다.

3-2. Cloudflare DNS 레코드

vercel domains verify nogari.org를 실행하면 필요한 레코드를 알려줍니다:

Type	Name	Content	Proxy
CNAME	`@`	`xxxx.vercel-dns-017.com` (도메인마다 고유값)	DNS only (회색 구름)
A	`www`	`76.76.21.21`	DNS only (회색 구름)

여기서 앞 섹션의 조언 하나를 정정해야 합니다. 인프라 IP를 가리려고 Cloudflare 프록시(주황 구름)를 켜려 했는데, Vercel은 이 레코드에 프록시를 끄라고 명시합니다(disableProxy: true). 켜면 SSL 인증서 발급이 꼬입니다. Vercel은 어차피 수많은 사이트가 공유하는 IP라서 프록시 없이도 익명성 손해는 사실상 없습니다 — 프록시 조언은 원본 서버 IP가 노출되는 자체 호스팅에 해당하는 이야기였습니다.

또 하나: Vercel이 "네임서버를 Vercel로 바꾸는 것"도 권장 옵션으로 제시하는데, 그러면 Cloudflare에서 DNS를 관리하는 의미가 없어지니 네임서버는 Cloudflare 그대로 두고 레코드만 추가하는 쪽을 택했습니다.

3-3. 검증 — 진짜 익명인지 눈으로 확인

레코드 추가 후 몇 분 안에 검증이 통과했고, HTTPS 인증서는 Vercel이 자동 발급했습니다. 마지막으로 정말 궁금했던 것 — WHOIS에 내가 나오는가:

whois nogari.org | grep -iE "registrant|email|phone|name"

결과: 제 이름·이메일·주소·전화번호는 한 줄도 나오지 않습니다. 보이는 건 Cloudflare(대행사)와 .org 레지스트리의 연락처뿐. Cloudflare Registrar는 WHOIS 편집(redaction)을 기본으로, 무료로, 끌 수도 없게 적용하기 때문에 별도 설정조차 필요 없었습니다. 프라이버시 보호를 유료 옵션으로 파는 대행사들과의 결정적 차이입니다.

덤으로 얻은 것: 기존 프로젝트명.vercel.app 주소는 팀/계정 슬러그가 URL에 노출되는 경우가 있어서(프리뷰 URL에는 계정명이 그대로 들어갑니다), 커스텀 도메인으로 바꾸는 것 자체가 익명성에 한 겹을 더해줍니다.

트러블슈팅 요약

증상	원인	해결
`domain cannot be assigned (400)`	최신 프로덕션 배포가 Error 상태	빌드 고쳐서 Ready로 만든 뒤 재시도
도메인 연결 후 SSL 오류	Cloudflare 프록시(주황 구름) 켜짐	Vercel용 레코드는 DNS only로
WHOIS에 정보가 그대로 노출	프라이버시 보호 미적용 대행사	Cloudflare/Porkbun은 기본 적용 — 조회로 확인

법적 한계 — 이건 알고 시작하자

익명 커뮤니티(특히 실존 인물이 주제인 서비스)는 명예훼손 신고가 들어올 수 있는 성격의 서비스입니다. 그 경우 상대방은 도메인 WHOIS가 아니라 호스팅·DB·결제 기록에 대한 법적 절차로 접근합니다. 즉:

도메인 익명화 = 일반 공개로부터의 익명 (충분히 가치 있음)
도메인 익명화 ≠ 법적 책임으로부터의 익명 (애초에 불가능하고, 목표로 삼아서도 안 됨)

운영자 익명화와 별개로, 신고 처리·모더레이션 같은 운영 장치를 제대로 갖추는 게 서비스를 지키는 진짜 방어막입니다.

정리

체크리스트로 요약합니다:

.kr 대신 gTLD — 실명 등록 체계 회피
WHOIS 프라이버시 기본 제공 대행사 — Cloudflare Registrar 또는 Porkbun (예민한 주제면 Njalla)
연결 전 프로덕션 배포가 Ready인지 확인 — Error 상태면 도메인 연결 자체가 거부됨
Vercel용 DNS 레코드는 프록시 off — 네임서버는 Cloudflare 유지, 레코드만 추가
연결 후 whois로 직접 검증 — 내 눈으로 확인해야 안심
프로젝트 전용 이메일 — 도메인·호스팅·DB 계정 전부 분리
GitHub 커밋 author 점검 — 공개 전 git log --format='%an <%ae>' | sort -u
사이트 콘텐츠 점검 — 푸터, 메타태그, EXIF, 그리고 본문 곳곳의 *.vercel.app 링크
한계 인지 — 결제·계정 흔적은 남는다. 목표는 "일반 공개로부터의 익명"

돌이켜보면 도메인 자체보다 주변 계정과 git 히스토리가 더 큰 구멍이라는 게 가장 큰 수확이었습니다. WHOIS만 가리고 안심하는 건, 현관문만 잠그고 창문을 다 열어둔 셈이더라고요. 그리고 실제로 연결까지 해보니 — 조사 단계의 조언(프록시를 켜라)이 실전에서 뒤집히기도 했으니(Vercel은 끄라고 함), 이런 글은 역시 직접 해본 만큼만 믿을 수 있습니다.