이전이 실제로 바꾸는 것
GitHub 저장소 이전은 저장소를 다른 소유자 계정으로 옮기는 작업입니다. 프로필 사용자 이름을 바꾸는 것과는 다른 작업입니다. 사용자 이름을 바꾸면 계정의 공개 정체성과 그에 기반한 URL이 달라지고, 저장소를 이전하면 해당 프로젝트 하나의 소유자가 달라집니다. 프로젝트를 다른 사람에게 넘기는 것이 아니라 프로필 이름만 깔끔하게 정리하려는 것이라면 아래 이전 절차는 맞는 도구가 아닙니다.
이 구분은 계획에 중요합니다. 원래 소유자 계정이 정리되고 나면 아무도 로그인해 초대를 수락하거나 후속 조치를 승인하거나 놓친 링크를 바로잡을 수 없습니다. 옛 계정에 의존하는 모든 일은 그 시점 이후가 아니라 그 전에 끝내야 합니다.
시작 전에 확인할 사전 조건
이전이 가능한지 자체를 결정하는 두 가지 조건이 있습니다.
저장소 이전에는 관리자 권한과, 이름이나 포크 네트워크가 충돌하지 않는 호환되는 수신 계정이 필요합니다. 출처
실제로는 요청을 보내기 전에 소유자 쪽에서 세 가지, 수신자 쪽에서 한 가지를 확인해야 합니다.
| 확인 항목 | 확인하는 사람 | 이전을 막는 이유 |
|---|---|---|
| 소유자 계정이 저장소에 대한 관리자 권한을 가짐 | 소유자 | 관리자 권한이 없으면 이전을 시작할 수 없음 |
| 수신 계정이 호환됨 | 수신자 | 호환되지 않는 수신 계정은 이전을 중단시킴 |
| 수신자에게 같은 이름의 저장소가 이미 없음 | 수신자 | 이름이 충돌하면 이전이 차단됨 |
| 충돌하는 포크 네트워크가 없음 | 수신자 | 포크 네트워크가 충돌하면 이전이 차단됨 |
어느 항목이든 실패하면 요청을 보내기 전에 해결하세요. 수신자 쪽에서 저장소 이름을 바꾸거나 다른 대상 계정을 고르는 것은 수신자의 결정이므로, 이전 도중에 충돌을 발견하는 대신 미리 합의하세요.
수락 단계의 기한은 짧습니다
개인 계정 간 이전에서는 수신자가 수동적인 당사자가 아닙니다. 수신자가 직접 행동해야 합니다.
다른 개인 계정으로 이전할 때는 수신자가 하루 후 만료되는 이메일 초대를 수락합니다. 출처
하루 만료는 이 절차의 주요 운영 리스크입니다. 수신자가 다른 시간대에 있거나 휴가 중이거나 단순히 이메일을 확인하지 않으면 초대가 만료되어 이전을 처음부터 다시 해야 합니다. 수신자가 연락 가능한 시점을 보내는 시간으로 정하고, 메시지가 읽히지 않은 채 방치되지 않도록 수신자에게 미리 알리세요.
간단한 소유자/수신자 수락 체크리스트:
- 소유자: 관리자 권한, 이전할 정확한 저장소, 수신자 계정에 이름이나 포크 네트워크 충돌이 없음을 확인합니다.
- 수신자: 대상 계정을 확인하고 같은 충돌이 없는지 자기 쪽에서 점검합니다.
- 양측: 수신자가 하루 안에 응답할 수 있는 전송 시간대를 합의합니다.
- 소유자: 이전 요청을 보냅니다.
- 수신자: 이메일 초대를 신속히 수락하고 결과를 알립니다.
- 소유자: 옛 계정에 어떤 조치도 하기 전에 저장소가 이제 수신자 계정 아래에 나타나는지 확인합니다.
6단계가 확인되기 전에는 소유자 계정을 정리하지 마세요. 실패하거나 만료된 이전을 다시 보낼 수 있는 곳은 옛 계정뿐입니다.
이후 공개 링크는 어떻게 되는가
링크 동작은 사람들이 이전에서 놀라는 지점입니다. 두 종류의 링크가 다르게 동작하기 때문입니다.
저장소 링크는 이전 후 리디렉션되지만 연결된 GitHub Pages 웹사이트는 리디렉션되지 않으며, 이전 저장소 위치를 다시 사용하면 저장소 리디렉션이 제거됩니다. 출처
이전 후 링크 점검을 위한 명확한 구분이 생깁니다.
| 링크 유형 | 이전 후 | 필요한 조치 |
|---|---|---|
| 옛 위치를 가리키는 저장소 링크 | 새 소유자로 리디렉션됨 | 보통 없음. 일부를 표본 확인 |
| 저장소로 만든 GitHub Pages 사이트 | 리디렉션되지 않음 | Pages 사이트로 가는 모든 공개 링크 업데이트 |
| 다른 사람이 옛 저장소 위치를 다시 사용 | 리디렉션 제거됨 | 옛 위치가 비지 않도록 유지하고 링크를 최신으로 유지 |
세 번째 항목이 가장 놓치기 쉽습니다. 옛 저장소 경로가 나중에 다시 사용되면 옛 링크를 조용히 덮어주던 리디렉션이 사라집니다. 리디렉션은 마이그레이션 중의 편의일 뿐 영구 보장이 아니라고 보고, 리디렉션에 의존하기보다 직접 관리하는 링크를 업데이트하세요.
이전 후 공개 링크 체크리스트
수신자가 소유권을 확인한 뒤, 소유자 계정을 정리하기 전에 실행하세요.
- 문서, README, 프로젝트를 참조하는 사이트에서 저장소 링크 일부를 열어 새 소유자로 연결되는지 확인합니다.
- 리디렉션되지 않는 GitHub Pages 사이트를 모두 찾아 그곳으로 가는 공개 링크를 업데이트합니다.
- 옛 저장소 위치가 리디렉션을 제거하는 방식으로 다시 사용되지 않도록 어떻게 할지 정합니다.
- 외부 글, 공유 북마크처럼 직접 관리하지 않는 곳의 링크를 점검하고, 업데이트할 수 있는 것과 없는 것을 기록합니다.
- 위 작업이 모두 끝날 때까지 소유자 계정을 활성 상태로 유지합니다.
소유권 이전과 사용자 이름 변경의 차이
저장소 이전과 프로필 사용자 이름 변경은 위험 요소가 각각 다른 별개의 작업입니다. 이전은 프로젝트의 소유자가 누구인지에 관한 것이고, 사용자 이름 변경은 계정 자체의 공개 정체성에 관한 것입니다. 저장소를 넘기는 것이 아니라 프로필이 보이는 방식을 정리하려는 것이라면 사용자 이름 가이드부터 시작하세요. 깨진 프로필 링크 없이 GitHub 사용자 이름 바꾸기.
둘 다 한다면 순서를 의도적으로 정하세요. 먼저 저장소 소유권을 정리하고, 새 소유자가 독립적으로 행동할 수 있는지 확인한 다음에야 옛 계정을 변경하거나 정리하세요. 순서를 반대로 하면 이미 포기한 계정에 이전이 의존하게 됩니다.
사용자 이름 검색이 맞는 곳과 맞지 않는 곳
계정을 정리하기 전에 사람들은 옛 사용자 이름의 공개 흔적이 다른 곳에 얼마나 남아 있는지 알고 싶어 합니다. 사용자 이름 조회는 다른 플랫폼의 공개 프로필 일치를 보여줄 수 있어, 업데이트해야 할 링크의 후보 목록으로 유용합니다. 그러나 계정 목록이 아니며, 일치가 두 계정이 같은 사람 소유라는 증거도 아닙니다. 결과는 직접 확인할 곳으로 취급하고, 링크가 살아 있거나 계정이 본인 것이라는 확인으로 보지 마세요.
TraceSeek는 3,000+ 플랫폼을 다루며 첫 스캔을 20-30초 안에 무료로 제공합니다. 검토할 공개 프로필 체크리스트를 만드는 데 도움이 될 수 있지만, 소유권을 검증하지도 않고 위의 이전 및 링크 점검을 대체하지도 않습니다. 저장소 이전 자체는 조회 도구가 아니라 GitHub에서 이루어집니다.
현실적인 작업 순서
- 저장소 이전이 필요한지, 사용자 이름 변경이 필요한지, 아니면 둘 다인지 정합니다.
- 관리자 권한, 수신자 호환성, 이름이나 포크 네트워크 충돌이 없음을 확인합니다.
- 수신자가 하루 안에 수락할 수 있을 때 이전을 보냅니다.
- 저장소가 새 소유자 아래에 있는지 확인합니다.
- 저장소 링크와 GitHub Pages 링크를 각각 점검합니다.
- 옛 저장소 위치가 다시 사용되지 않도록 보호합니다.
- 그다음에야 소유자 계정을 정리합니다.