익명으로 사이트 운영하기 — 신원은 글이 아니라 인프라에서 샌다

한 줄 요약

필명을 정하고 사이트를 띄우는 사이에 신원이 새는 곳을 네 군데 찾았다. 네 번 다 글 내용은 깨끗했다.

본문

왜 익명으로 시작했나

회사를 다니면서 공개 글을 쓰려면 결정할 게 하나 있다. 이름을 걸지 말지.

실명으로 쓰면 글이 커리어 자산으로 쌓인다. 대신 소속이 드러난 글은 사실상 회사 입장으로 읽히고, 그러면 “이건 우리 환경에 안 맞는다”를 못 쓰게 된다. 그게 내 사이트의 유일한 자산이다 — 요약은 AI도 하지만 안 맞다고 본 지점만 남이 못 쓴다.

결정적인 건 방향의 비대칭이었다. 익명에서 실명으로 가는 건 쉽고 역방향은 불가능하다. 되돌릴 수 있는 쪽을 먼저 골랐다. 공개하는 건 필명과 직무 분야까지다.

구멍 1 — 커밋에 박히는 이름

필명을 정하고 흐뭇해하다가 커밋 로그를 봤다. 이미 쌓인 커밋 세 개가 내 실명 로마자 ID와 개인 메일로 작성돼 있었다.

.gitignore 도, 내가 짠 검사 스크립트도 파일 내용만 본다. 커밋에 박히는 author·committer 는 그 어느 것도 보지 않는다. 글은 한 글자도 안 올렸는데 push 한 번이면 신원이 나가는 구조였다.

remote 를 아직 안 붙인 상태라 재작성 비용은 0이었다. 다만 두 가지를 몰랐으면 “고쳤는데 아직 보인다”가 됐을 것이다.

  • filter-branch 는 refs/original/ 에 백업을 남긴다. 지워야 한다
  • reflog에도 옛 커밋이 남는다. 만료시키고 gc 를 돌려야 실제로 사라진다

그리고 이건 push 전에만 공짜다. 올라간 뒤에는 포크와 캐시에 남아서 회수할 수 없다.

구멍 2 — 레포 주소에 박히는 계정명

커밋을 다 고치고 백업하려고 레포를 만들려는 순간 두 번째 구멍이 보였다.

커밋 이름은 재작성할 수 있어도 레포 소유 계정명은 재작성할 수 없다. 공개 레포로 올리면 주소에 계정명이 그대로 박히고, 내 계정명은 실명 로마자 표기다. 커밋을 필명으로 바꾼 작업이 전부 무의미해지는 상황이었다.

필명으로 새 계정을 만들 수도 있었지만, 계정 두 개를 나눠 운영하면 SSH 키·2단계 인증· 배포 연결이 다 갈라진다. 그렇게 얻는 건 “소스 공개” 하나뿐이었다.

그래서 레포를 비공개로 두고 사이트만 공개했다. 정적 호스팅은 비공개 레포도 무료로 빌드해주니 push 가 배포라는 구조는 그대로 남는다. 부수 효과로 커밋 이메일도 공개되지 않게 되어, 전용 이메일을 급히 만들 이유가 사라졌다.

구멍 3 — 차단 키워드 목록 자체

이건 내가 만들려던 구멍이다. 차단 키워드 목록에 실명을 적으려다 멈췄다. 그 목록 파일은 레포에 올라간다. 가리려는 것을 가리려고 적는 행위 자체가 발행이 되는 구조였다. 목록을 공개용과 로컬용으로 쪼갰다.

그리고 바로 그 검사에 내가 걸렸다. 결정 기록 문서에 계정명을 그대로 적었다가 커밋이 막혔다. 그 뒤로도 두 번 더 걸렸다. 만들어놓고 자기가 세 번 걸리는 장치라면, 적어도 작동은 한다.

구멍 4 — 배포 주소

여기까지 하고 배포했다. 성공했고, 주소를 봤다.

https://personal-site.<내가-옛날에-쓰던-핸들>.workers.dev

Worker 주소는 <프로젝트>.<계정-서브도메인>.workers.dev 꼴이고, 그 계정 서브도메인이 오래 전에 실명과 같이 쓴 적 있는 핸들이었다. 글은 한 글자도 안 바꿨는데 주소 한 줄로 끝날 상황이었다.

해결은 호스팅 방식을 바꾸는 것이었다. 같은 Cloudflare의 Pages 는 주소가 <프로젝트>.pages.dev 라서 계정 서브도메인이 아예 들어가지 않는다. Worker 를 유지하려면 계정 서브도메인을 바꿔야 하는데, 그러면 그 계정의 다른 프로젝트 주소까지 전부 바뀐다 — 부작용이 사이트 하나 범위를 넘는다.

그래서 알게 된 것

커밋 작성자, 레포 계정명, 차단 키워드 목록, 배포 주소. 네 군데 다 글 내용은 깨끗했다. 신원은 내가 쓴 글에서 새지 않았다.

생각해보면 당연하다. 글은 쓸 때마다 읽어보지만 커밋 작성자나 호스팅 주소는 한 번 정해지면 다시 안 본다. 게다가 그것들은 내가 고른 게 아니라 도구가 기본값으로 채워준 것이고, 기본값은 익명을 고려하지 않는다.

익명으로 시작할 거면 글쓰기 규칙보다 이름이 자동으로 채워지는 자리 목록을 먼저 만드는 게 맞다.

독자가 가져갈 것

익명으로 시작할 거면 글을 쓰기 전에 이름이 자동으로 채워지는 자리를 확인하라.

  1. 커밋 신원 — git log --format='%an <%ae>' remote 붙이기 전에 고쳐라. refs/original 과 reflog 까지 지워야 실제로 사라진다
  2. 레포 소유 계정명 — 공개 레포면 주소에 박힌다. 비공개로 두거나 계정을 나눠라
  3. 배포 주소 — 호스팅 방식에 따라 계정 식별자가 들어간다. 주소 형태를 고르기 전에 확인하라. 배포 후에 바꾸면 링크가 죽는다
  4. 차단 키워드 목록의 위치 — 그 파일이 공개되는지 확인하라
  5. 연락용 이메일 — 주소에 이름·소속 약어가 들어 있으면 거기서 끝난다

안 맞다고 본 지점

  • 가장 큰 구멍은 기계가 못 막는다. 문체, 드는 사례, 쓰는 도구 조합이 신원을 흘린다. 이 글조차 그렇다 — 내가 쓰는 도구 조합을 아는 사람이면 범위를 좁힐 수 있다. 키워드 검사로는 전혀 안 걸리고, 여기에 대한 답은 아직 없다.
  • 네 군데를 찾았다는 말은 다섯 번째를 못 찾았다는 뜻이기도 하다. 네 개 다 “하려던 다음 작업을 하다가” 우연히 보였다. 체계적으로 찾은 게 아니다.
  • 업무 밖 관심사 글이 제일 위험하다고 본다. 취미나 읽은 책 이야기는 본인도 모르게 지역·생활 패턴을 흘린다.
  • 익명의 대가는 분명하다. 글이 쌓여도 내 이름으로 귀속되지 않는다. “나중에 실명으로 전환할 수 있다”를 근거로 삼았지만, 그 나중이 오지 않으면 아무에게도 안 쌓인 글이 된다.

참고


체크리스트 (발행 전)

  • publish: true 로 변경했는가
  • tags 를 태그 체계에서 골랐는가 — ai tooling automation workstyle career personal 중 최대 2개
  • description 을 한 문장으로 채웠는가 (목록 페이지에 노출됨)
  • 회사·부서·동료·내부 자료 관련 내용이 섞이지 않았는가
  • scripts/check-publish.sh 를 통과하는가