저장소 비공개 전환 + 실명 제거 — 사이트 공개 전 마지막 점검

이 글은 이런 분께

• 사이트를 만들다가, “이거 원본 저장소도 남들이 다 보는 거 아냐?”가 뒤늦게 걱정되는 분
• 개인 기록(일지)이랑 공개용 글이 같은 저장소에 섞여 있는 분
• 저장소를 비공개로 바꾸면 배포된 사이트도 같이 사라지는 건 아닌지 헷갈리는 분

Before — 공개 저장소에 개인정보가 섞여 있었다

사이트는 1주차에 GitHub·Vercel로 배포하면서 처음엔 Public(공개)으로 만들었다. 그땐 “사이트를 보여줄 거니까 공개가 맞다”고 생각했는데, 시간이 지나며 두 가지가 마음에 걸렸다.

• GitHub 저장소를 공개로 두면, 사이트 화면엔 안 보여도 저장소 원본 파일은 누구나 볼 수 있다 — 학습일지(journal) 폴더처럼 진짜 개인 기록까지.
• 공개 글 본문 여기저기에 실명·가족 관련 닉네임이 그대로 적혀 있었다.

어떻게 — 실제 쓴 프롬프트 그대로

세 가지 요구사항을 한 번에 담아서, 되묻지 말고 바로 실행해달라고 부탁했다.

내 학습허브 저장소가 GitHub에서 공개(public)로 돼 있는지 확인해줘. 공개면 비공개(private)로 바꿔줘.
나는 명령어를 직접 못 치니 네가 대신 실행해줘. "바꿀까요?"라고 되묻지 말고 바로 진행해줘.
- 내 학습일지(journal 폴더)는 개인 기록이라 남이 보면 안 돼.
- 비공개로 바꾼 뒤에도 배포한 내 사이트 주소가 그대로 열리는지 확인해줘.

이 한 프롬프트에 확인 → 실행 → 안전장치 → 검증까지 다 들어있는 게 포인트였다. “바꿔줘” 한 마디만 하면 AI가 매번 “정말요?”라고 되물어서 오히려 번거로웠는데, 처음부터 “되묻지 말고 진행해줘”를 넣으니 한 번에 끝났다.

실제로 진행된 순서

1. 저장소 공개 여부 확인 — GitHub CLI로 지금 상태를 먼저 확인
2. 비공개로 전환 — 공개 상태였다면 아래 명령어로 바로 전환

   gh repo edit --visibility private --accept-visibility-change-consequences
   

   (--accept-visibility-change-consequences가 없으면 GitHub CLI가 실행을 막는다. “공개 상태를 바꾸면 스타·워치 수가 사라질 수 있다”는 경고를 사전에 확인했다는 뜻으로 붙여야 하는 옵션.)
3. 학습일지 별도 보호 — journal 폴더를 .gitignore에 추가해서, 혹시라도 나중에 실수로 다시 공개해도 학습일지만큼은 저장소에 안 올라가게 이중 안전장치를 걸어둠
4. 실명 검색 후 제거 — 공개 글 전체에서 실명·애칭·가족 관련 닉네임 같은 표현을 찾아서, 1인칭(“저는”)으로 자연스럽게 바꾸거나 통째로 뺌
5. 배포 주소 재확인 — 비공개로 바꿔도 Vercel 배포 주소는 그대로 열리는지 재확인 (저장소 비공개 ≠ 사이트 비공개. GitHub 저장소랑 Vercel 배포 사이트는 완전히 별개라, 저장소를 잠가도 이미 배포된 사이트는 그대로 인터넷에 공개돼 있다.)

After — 결과

• GitHub에서 저장소 상태를 다시 확인해보니 정상적으로 Private로 바뀌어 있었다.
• 공개 글에서 실명 표현을 찾아보니 남아있던 6곳이 전부 1인칭이나 무표현으로 바뀌어 있었다. 예를 들면:

• 저장소는 잠갔지만, 배포된 사이트 주소는 그대로 열려서 계속 보여줄 수 있는 상태를 유지했다.

2차 점검 — 저장소 전체에 개인정보·비밀번호가 더 있는지

실명은 지웠지만 “혹시 다른 데 또 있지 않을까” 싶어서 저장소 전체를 훑어달라고 부탁했다.

내 저장소에 남한테 보이면 안 되는 내용이 들어간 게 있는지 찾아줘.
개인정보(이름·연락처·주소), 회사 내부 내용, 비밀번호나 API 키 같은 것.
찾으면 어느 파일에 뭐가 있는지 알려주고, 어떻게 정리하면 좋을지도 알려줘.

이번엔 사이트에 보이는 글(src/content/)만이 아니라 저장소에 커밋된 파일 전체를 뒤졌다. 결과는 이랬다.

USER.md·SOUL.md를 어떻게 할지 물어봤는데(“실명만 빼기” vs “저장소에서 아예 빼고 로컬에만 두기”), 곰곰이 생각해보니 저장소가 이미 비공개라 지금 상태로 충분하다고 판단했다. 굳이 커밋 기록까지 새로 정리하는 건(git filter-repo 같은) 되돌리기 어려운 작업이라 지금은 안 건드리기로 했다.

3차 점검 — 예전에 배포됐던 주소들도 살아있는지

Vercel은 새로 배포할 때마다 예전 주소를 지우지 않고 계속 쌓아둔다는 걸 알게 돼서, 예전 실명 노출 버전을 담고 있을 옛날 배포 주소가 아직 열리는지 확인해달라고 했다.

• Vercel에 예전 배포 주소가 13개 남아있었다 (지난 며칠간 배포될 때마다 하나씩 생김).
• 하나씩 직접 열어봤더니, 지금 쓰는 대표 주소(my-learning-hub-omega.vercel.app) 말고는 전부 Vercel 로그인 화면으로 튕겼다. Vercel이 기본으로 낱개 배포 주소는 로그인 없인 못 열게 막아두고 있었던 것.
• 즉 예전 버전이 서버에 남아있긴 해도, 로그인 벽에 막혀서 남이 못 보는 상태라 따로 지울 필요는 없었다.

배운 것 / 재사용 자산

“저장소 비공개 = 사이트도 안 보임”이 아니다. GitHub 저장소(원본 코드 창고)와 Vercel 배포 사이트(실제 인터넷 주소)는 별개다. 저장소를 잠가도 이미 배포된 사이트 주소는 그대로 살아있다. 그래서 “사이트는 계속 보여주되, 원본 코드·개인 기록만 숨기고 싶다”는 목적에 딱 맞는 방법이었다.

“삭제”에도 층이 있다는 걸 알게 됐다. 화면에서 지운다고 다 지워지는 게 아니었다.

1. 사이트에 보이는 글 → 파일 내용만 고치면 바로 해결
2. 저장소에 커밋된 다른 파일(USER.md 등) → 화면엔 안 보여도 저장소 접근 권한이 있으면 보임
3. 과거 커밋 기록 → 지금 파일을 고쳐도 예전 버전은 히스토리에 남음
4. 예전 배포 서버 → 새로 배포해도 예전 주소가 따로 계속 살아있음

한 번에 다 지워지는 게 아니라서, “지웠다”고 안심하기 전에 이 네 층을 하나씩 확인해야 한다는 걸 배웠다. (다행히 3·4번은 로그인 벽이나 비공개 설정으로 이미 막혀 있어서 지금 단계에선 추가 조치 없이 넘어가기로 했다.)

되묻지 말고 진행해달라는 프롬프트 패턴

[하고 싶은 것]을 확인해줘. [조건]이면 [원하는 조치]로 바꿔줘.
나는 명령어를 직접 못 쳐, 네가 대신 실행해줘. "할까요?"라고 되묻지 말고 바로 진행해줘.
- [지켜야 할 안전장치 1]
- [완료 후 확인해야 할 것]

막히면 이렇게 물어보기

• 뭔가 바뀐 것 같은데 확실치 않을 때 → “지금 [내가 원한 상태]로 잘 바뀌었는지 확인해줄 수 있어?”
• 공개 글에 개인정보가 있을까 걱정될 때 → “공개되는 글들 중에 실명이나 개인정보 있는지 찾아서 정리해줘”
• 저장소 전체가 걱정될 때 → “내 저장소에 남한테 보이면 안 되는 내용(개인정보·비밀번호·API 키)이 있는지 찾아줘”
• 예전에 올렸던 것들이 마음에 걸릴 때 → “예전에 배포한 주소 중에 아직 살아있는 게 있는지 확인해줘”

공개하는 사이트는 “보여줄 것만 보여주고, 감출 것은 확실히 감추는” 균형이 중요하다는 걸 이번에 몸으로 배웠다.