혼자 관리하던 저장소를 넘길 때 코드와 함께 정리할 것

개인 프로젝트를 계속 맡기 어려워져 다른 개발자에게 넘기기로 했습니다. 코드는 저장소에 있고 설치 방법도 적혀 있으니 소유자를 바꾸면 끝날 것 같습니다. 그런데 며칠 뒤 배포 오류 알림은 여전히 이전 담당자에게 오고, 새 담당자는 서버 요금이 누구에게 청구되는지 모릅니다.

이는 설명을 위한 가상 상황입니다. 혼자 만든 서비스에는 코드 밖의 결정이 많이 쌓입니다. 어디서 배포하는지, 어떤 계정으로 결제하는지, 장애가 나면 누구에게 연락하는지를 한 사람이 알고 있으면 평소에는 편하지만 인계할 때 빈틈이 드러납니다.

이 글은 2026년 11월 1일 확인한 GitHub 공식 문서와 인계 절차 제안을 구분해 정리합니다. 실제 저장소 이전이나 배포를 실행한 후기가 아닙니다. 다른 서비스의 소유권 변경 조건까지 같다고 가정하지 않으며, 아래 목록은 자신의 운영 환경에 맞게 줄이거나 보완할 출발점입니다.

저장소 소유자와 운영 담당자를 따로 적습니다

먼저 무엇을 넘기는지 한 문장으로 합의합니다. 코드 유지보수만 맡기는지, 운영 서버와 사용자 문의까지 넘기는지에 따라 필요한 준비가 달라집니다. 저장소에 접근할 수 있다는 사실만으로 서버 비용을 부담하거나 고객에게 답할 책임까지 정해지지는 않습니다.

가상으로 예약 관리 도구를 넘긴다고 해 보겠습니다. 새 담당자는 오류 수정과 정기 배포를 맡고, 기존 담당자는 한 달 동안 과거 설계 질문에만 답하기로 할 수 있습니다. 이때 지원 기간뿐 아니라 문의 경로와 다루지 않는 업무도 적어야 합니다. 아무 때나 호출할 수 있는 관계로 남기면 인계가 끝났는지 판단하기 어렵습니다.

인계 문서 첫 장에는 현재 서비스 주소, 코드 위치, 운영 담당자, 비용 담당자, 사용자 연락 창구를 둡니다. 여러 역할을 같은 사람이 맡더라도 칸은 나누는 편이 좋습니다. 나중에 결제 담당자만 바뀌어도 어떤 항목을 갱신해야 하는지 찾기 쉽기 때문입니다.

문서에는 확정된 내용과 협의 중인 내용을 구분합니다. “앞으로 알아서 관리”보다는 “이번 달 말까지는 기존 담당자가 배포하고, 다음 달부터는 새 담당자가 배포 승인과 실행을 맡음”처럼 경계를 정합니다. 계약이나 개인정보 처리 책임이 관련된다면 기술 인계 문서만으로 합의를 대신하지 않습니다.

이전 뒤에도 남는 연결을 확인합니다

GitHub 저장소 이전 문서에 따르면 이슈와 풀 리퀘스트 등은 저장소와 함께 이전됩니다. 웹훅, 비밀값, 배포 키도 이전 완료 뒤 연결된 상태로 남습니다. 코드가 새 계정 아래 보인다고 기존 연결이 모두 끊어진 것은 아닙니다.

같은 문서는 원래 소유자가 이전된 저장소의 협업자로 추가된다고 설명합니다. 따라서 인계 후 권한 정리를 별도 항목으로 잡아야 합니다. 기존 소유자가 잠시 지원해야 한다면 필요한 역할과 종료 시점을 적고, 지원이 끝난 뒤 접근권한을 다시 확인할 담당자를 정합니다.

비밀값 목록에는 값 자체를 복사하지 않습니다. 이름, 사용 목적, 연결된 서비스, 관리 주체, 교체 여부를 적는 것으로 시작합니다. 예를 들어 배포용 자격 증명과 알림 전송용 자격 증명은 권한과 교체 영향이 다를 수 있습니다. 이름만 보고 같은 방식으로 지워 버리면 운영 중인 연결을 끊을 수 있습니다.

교체가 필요하다면 새 담당자가 사용할 권한을 준비하고, 연결을 확인한 뒤 기존 권한을 정리하는 순서를 계획합니다. 이 글을 읽었다는 이유만으로 운영 자격 증명을 즉시 바꾸라는 뜻은 아닙니다. 변경 시점과 실패 시 되돌릴 방법을 정하고 해당 서비스의 실제 절차를 따릅니다.

받는 계정의 요금제도 확인 대상입니다. GitHub 문서는 비공개 저장소를 Free 계정으로 이전할 때 보호 브랜치나 GitHub Pages 같은 기능을 잃을 수 있다고 안내합니다. 현재 쓰는 기능을 적고 대상 계정에서 유지되는지 확인한 뒤 이전해야 합니다. 다른 조직의 정책이 적용되는 경우도 별도로 검토합니다.

코드 밖의 자원은 연결 목적별로 정리합니다

인계 목록을 계정 이름만으로 만들면 무엇이 빠졌는지 알기 어렵습니다. 사용자가 접속한 뒤 요청이 처리되고, 데이터가 저장되며, 문제가 담당자에게 전달되는 흐름을 따라가 보시면 좋겠습니다. 각 단계에서 사용하는 자원과 관리 화면 위치를 적는 방식입니다.

• 접속: 도메인과 DNS를 누가 관리하고 갱신 비용은 누가 부담하는지 확인합니다.
• 실행: 배포 대상, 배포를 시작하는 경로, 승인자와 되돌리기 절차를 남깁니다.
• 보관: 데이터베이스와 파일 저장소, 백업 위치, 복원 확인 기록을 연결합니다.
• 대응: 오류 알림 수신자, 사용자 문의 주소, 첫 대응 책임자를 적습니다.

이 목록은 모든 서비스를 반드시 갖추라는 요구가 아닙니다. 정적 문서 사이트에는 데이터베이스가 없을 수 있고, 운영하지 않는 예제 저장소에는 사용자 문의 창구가 필요 없을 수 있습니다. 없는 항목은 해당 없음으로 표시하되 모르는 항목과 구분합니다. “없음”과 “아직 찾지 못함”은 인계 판단에서 다른 상태입니다.

GitHub 문서는 저장소 주소의 리디렉션과 GitHub Pages 주소를 구분합니다. 저장소 이전이 Pages 사이트의 리디렉션까지 제공하지는 않습니다. 또한 로컬 복제본은 새 저장소 주소를 가리키도록 갱신할 것을 권장합니다. 공개 서비스 주소가 정상인지와 코드 원격 주소가 정상인지를 각각 확인할 이유입니다.

배포 문서에는 명령만 적지 말고 실행 위치와 필요한 전제, 예상 결과, 실패했을 때 확인할 곳을 붙입니다. “배포 버튼을 누릅니다”라는 설명도 어느 계정의 어떤 프로젝트인지 빠지면 인수자에게는 단서가 부족합니다. 반대로 내부 토큰이나 고객 자료가 담긴 화면을 그대로 캡처해 공개 문서에 넣지는 않습니다.

현재 알려진 문제도 넘길 자료입니다. 반복되는 오류, 수동으로 처리하는 예외, 아직 끝내지 못한 작업을 숨기지 않고 영향과 임시 대응을 적습니다. 해결되지 않은 이슈가 있다는 사실보다 그것을 누가 알고 있는지가 불분명한 상태가 인계를 더 어렵게 만듭니다.

인수자가 혼자 확인할 수 있어야 마무리됩니다

인계 완료를 파일 전송 여부로만 판단하지 않는 편이 좋습니다. 새 담당자가 필요한 문서와 관리 화면을 찾고, 자신의 권한으로 확인할 수 있는지를 기준으로 삼습니다. 실제 배포나 복원 실습이 필요하다면 운영에 미치는 영향을 먼저 협의하고 안전한 환경과 범위를 정합니다.

가상 인수 점검에서는 새 담당자가 설치 전제를 설명하고, 최근 배포 기록을 찾고, 오류 알림의 수신자를 확인해 볼 수 있습니다. 이때 이전 담당자가 옆에서 모든 단계를 대신 누르면 문서의 빈틈을 발견하기 어렵습니다. 막힌 지점을 질문으로 남기고 해당 문단만 보완합니다.

한 번의 정상 접속으로 모든 인계를 완료했다고 하지는 않습니다. 월말 결제나 도메인 갱신처럼 드물게 발생하는 일은 그날 바로 실행해 볼 수 없기 때문입니다. 그런 항목은 다음 발생일과 담당자, 확인 방법을 남깁니다. 아직 검증하지 못한 항목을 검증 완료로 표시하지 않는 것이 중요합니다.

마지막에는 남은 지원 범위, 미해결 문제, 권한 정리 예정일을 함께 확인합니다. 이후 새 기능 요청이 들어오면 기존 인계 지원인지 새로운 작업인지 구분할 기준도 필요합니다. 책임을 선명하게 나누는 것은 관계를 차갑게 만드는 일이 아니라 양쪽이 예상할 수 있는 일을 정하는 과정입니다.

오늘은 저장소 이전 버튼부터 찾기보다 현재 서비스의 다음 배포를 누가 맡을지 한 줄로 적어 보시면 됩니다. 그 사람이 코드 위치, 실행 권한, 실패 시 연락처를 스스로 찾을 수 있는지 확인하면 됩니다. 그 질문에 답하지 못하는 부분이 지금 보완해야 할 인계 문서의 첫 항목입니다.