홈페이지 도메인 소유권 이전과 소스 인수인계, 무엇을 받아야 끝날까요?

"관리자 계정이랑 소스 파일은 다 받았는데, 이제 저희가 알아서 운영해도 되는 건가요?" 제작사를 바꿀 때 확인해야 할 질문입니다. 답은 받은 파일의 개수가 아니라, 새 운영 주체가 적법한 권한으로 사이트를 다시 실행하고 고치고 복원할 수 있는지에 달려 있습니다. 관리자 로그인, 도메인 등록인, 등록대행자 계정, 호스팅 계정, 소스 이용권은 전부 다른 것이라서 하나를 받았다고 나머지가 따라오지 않아요. 기존 사이트를 유지하면서 업체만 바꿀 수 있는지 자체가 아직 불확실하다면 유지보수 비용 가이드의 업체 변경 항목을 먼저 보고 오시는 편이 순서에 맞습니다.

1. 도메인 소유권 이전, 기관이전, 서버 이전은 다른 일입니다

검색창에 "도메인 이전"이라고 치는 분들이 실제로 원하는 일은 넷 중 하나예요. 이름이 비슷해서 섞이지만 바꾸는 대상, 그대로 남는 대상, 확인해야 할 곳이 각각 다릅니다.

.kr과 .한국 도메인은 KRNIC 절차를 따릅니다. 등록인 주소·책임자·네임서버 같은 정보 변경은 현재 등록대행자를 통해 하고, 등록대행자 자체를 바꾸는 일은 별도의 "등록대행자 이전신청"으로만 가능하다고 명시돼 있어요(KRNIC 등록정보 변경). 등록대행자 이전은 인수 등록대행자에 신청한 뒤 등록자가 인증 메일을 승인하고, 기존 등록대행자의 동의 확인을 거쳐 완료 안내를 받는 흐름이며 신청 시 사용기간 1년 연장이 붙습니다(KRNIC 등록대행자 이전). 중요한 건 이 절차 어디에도 "등록인이 바뀐다"는 단계가 없다는 점입니다. 기관이전은 관리 업체를 바꾸는 일이지 소유자를 바꾸는 일이 아니에요.

.com 같은 일반 도메인은 ICANN 인가 등록대행자 사이의 이전 규칙을 따릅니다. ICANN FAQ는 등록대행자 간 이전을 등록인의 권리로 두면서도, 신규 등록 60일 이내이거나 등록인 이름·기관·이메일을 바꾼 뒤 60일 동안은 이전이 거부될 수 있다고 적고 있어요. 같은 문서가 "등록대행자를 옮기지 않고 호스팅 업체나 네임서버만 바꾸는 선택지도 있다"고 안내합니다(ICANN 등록자 FAQ). 이 제한은 ICANN 규칙이 적용되는 도메인 이야기이고, 국가도메인에 그대로 복사하면 안 됩니다. 어느 쪽이든 지금 도메인이 어느 등록대행자에 있는지부터 확인하는 게 첫 단계예요.

주소 자체가 바뀌는 인계라면 검색 노출 문제가 따로 붙습니다. 그 부분은 검색 노출·검색 등록 가이드의 도메인 변경 항목에 정리돼 있어서 여기서는 반복하지 않겠습니다.

2. 인수물은 파일명이 아니라 확인 가능한 증거로 받습니다

실제 공개 질문 중에 "쇼핑몰 관리업체를 바꾸는데 기존 업체에서 소스 등 무엇을 받아야 하나요"라는 글이 있습니다(네이버 지식iN 477418137). 자료 목록만으로는 실제 실행 여부나 계정 명의를 확인할 수 없습니다. 그래서 아래 표는 "받았다"가 아니라 "인수자가 직접 확인했다"를 기준으로 짰어요. 이 표는 저희가 실무용으로 제안하는 양식이지 법적 표준이나 공식 서식이 아닙니다.

가상 작성 예(실제 회사·값 아님)

한 가지는 꼭 지켜 주세요. 이 표에 실제 비밀번호, API 키, 고객 개인정보를 적지 않습니다. 표에는 상태와 담당자, 보관 위치만 적고, 민감한 자료는 어떤 경로로 넘길지 따로 합의하세요. 회사 홈페이지의 일반 문의폼에 계정 정보를 올려 달라고 요구하는 곳이 있다면 그 방식 자체를 거절하셔도 됩니다.

3. "파일을 받음"과 "인수 완료"를 가르는 시험 3개

받은 자료가 진짜 쓸 수 있는 것인지는 세 가지 시험으로 갈립니다. 첫째, 새 담당자가 합의된 환경에서 사이트를 실행합니다. 둘째, 시험용 문구 하나를 바꿔서 배포하고 실제 주소에서 바뀐 걸 확인합니다. 셋째, 받은 백업으로 시험 환경을 복원해 봅니다. 합의한 인수 범위인데도 기존 업체만 수행할 수 있다면 해당 항목은 미완료로 기록합니다. 관리형 서비스처럼 운영 업무를 계속 맡기는 계약은 그 역할을 따로 구분해야 해요.

워드프레스처럼 DB를 쓰는 사이트는 복원 시험이 특히 중요합니다. WordPress 공식 문서는 사이트를 온전히 복원하려면 데이터베이스와 파일 두 가지가 모두 필요하다고 못 박고 있어요(WordPress Backups). 파일만 받고 DB를 못 받았다면 게시글과 설정이 빠진 껍데기입니다. 정적 사이트에는 별도 DB가 없을 수 있고, 빌더는 고객에게 DB 덤프 대신 자체 내보내기 기능만 제공할 수 있습니다. 인수물은 실제 구조와 지원 범위에 맞춰 정해야 합니다. 무엇이 있어야 하는지는 사이트 구조에 따라 다르고, 그걸 먼저 물어야 해요.

GitHub 저장소를 넘겨받는 경우엔 이전 뒤에도 할 일이 남습니다. GitHub 문서에 따르면 저장소를 이전하면 원 소유자가 이전된 저장소의 협업자로 추가되고, 기존 협업자도 그대로 유지되며, webhook·secrets·deploy keys도 이전 후에 계속 연결된 상태로 남습니다(GitHub 저장소 이전). 저장소가 우리 조직으로 왔다고 기존 업체의 접근이 자동으로 끊긴 게 아니라는 뜻이에요. 이전 직후에 협업자 목록, 연결된 secrets, 배포 키를 한 번 훑고 정리하는 것까지가 인수입니다. 이 정리를 안 하면 "우리 저장소인데 남이 배포할 수 있는" 상태가 유지됩니다.

플랫폼 자체를 바꿔야 실행이 가능한 상황이라면 이 글의 범위를 넘어갑니다. 그때는 노코드에서 Next.js로 옮기는 절차가 별도 환경 검증과 전환 순서를 다루고 있어요.

4. 기존 업체가 연락되지 않으면 어디서 멈춰야 하나요?

연락이 안 되는 상황은 급하지만, 급하다고 권한 없는 계정에 들어가거나 명의를 임의로 바꾸는 방법을 안내하지는 않습니다. 대신 지금 우리 손에 무엇이 있는지로 갈래를 나누세요.

어느 줄에 해당하든 회수나 복구가 반드시 된다고, 또는 며칠 안에 끝난다고는 말씀드릴 수 없습니다. 등록대행자마다 확인 절차가 다르고 계약 내용에 따라 결과가 달라지거든요. 확실한 건 한 가지, 어느 줄에 있는지 모른 채 새 업체에 "일단 옮겨 주세요"라고 하면 두 번 일하게 된다는 점입니다.

5. 인수 확인서를 닫는 기준

인수 확인서에는 자산별 인수 담당자, 확인 날짜, 시험 결과, 누락 자료, 누락에 대한 처리 합의, 그리고 기존 계정의 잔존 권한 검토 결과가 들어가야 합니다. 이 여섯 가지가 채워지면 닫고, 하나라도 비면 그 자산은 열어 둡니다.

누락이 하나라도 있으면 전체가 실패라는 법적 기준을 말하는 건 아니에요. 이 양식에서 제안하는 기준은 "합의한 필수 자산이 확인되지 않으면 기술적 인수는 보류"입니다. 예를 들어 폰트 라이선스 하나가 미확인이면 그 항목만 보류하고 나머지는 닫을 수 있지만, 도메인 관리 권한이 미확인이면 사이트 전체의 인수를 보류하는 식입니다. 무엇이 필수인지는 사이트마다 다르니 표를 만들 때 미리 표시해 두세요.

상담을 요청하실 때는 현재 사이트 주소와 위 표에서 어느 항목의 권한을 갖고 있는지만 알려 주시면 됩니다(상담 신청). 비밀번호나 인증 키는 일반 문의폼에 적지 말고, 필요한 자료의 안전한 전달 방법부터 합의하세요.

돈을 다 지급했으니 소스와 저작권이 자동으로 우리 것이라고 단정하는 분들이 계신데, 그건 계약서가 정하는 문제라 이 글에서 결론을 내릴 수 없습니다. 이 글이 확실하게 말할 수 있는 범위는 하나뿐이에요. 받은 파일의 개수보다 합의된 담당자가 정해진 운영 방식으로 실행·수정·복원을 확인했는지가 인수 완료의 기준입니다.