홈페이지 소유권 확인: 도메인·소스코드·호스팅 명의는 누구 앞으로 되어 있습니까

도메인 명의가 제작사로 되어 있으면 주소는 우리 것이 아닙니다

도메인은 사이트의 주소이자 회사 메일 주소의 뿌리입니다. 이것이 제작사 명의로 등록되어 있다면, 사이트를 다시 만들더라도 같은 주소를 계속 쓸 수 있다는 보장이 없습니다. 관계가 정리되지 않은 상태에서 갱신 시점이 오면 상황은 더 나빠집니다.

먼저 등록 정보를 확인해야 합니다. 등록인이 회사 이름으로 되어 있는지, 관리 연락처가 회사 담당자의 메일인지가 핵심입니다. 관리 연락처가 제작사 메일이면 갱신 안내와 인증 메일이 전부 그쪽으로 갑니다. .kr 계열 도메인의 등록과 관리 절차는 한국인터넷정보센터의 안내를 통해 확인할 수 있고, 일반 최상위 도메인은 등록기관의 안내를 따릅니다.

명의를 바로잡을 때 주의할 점이 있습니다. 등록인 정보를 변경하면 일정 기간 다른 등록기관으로의 이전이 제한될 수 있습니다. .com 같은 일반 최상위 도메인은 ICANN 이전 정책과 각 등록기관 규정을 따르고, .kr 계열은 한국인터넷정보센터의 도메인이름 관리준칙·관리세칙을 따릅니다. 적용되는 규정이 서로 다르므로, 이전 일정을 잡기 전에 해당 도메인에 적용되는 순서와 대기 기간을 먼저 확인해야 합니다.

• ●등록인 명의가 회사인지, 담당자 개인이나 제작사인지 확인합니다
• ●관리 연락처 메일 주소를 회사가 실제로 받아 볼 수 있는 주소로 바꿉니다
• ●자동 갱신 설정과 만료일을 달력에 등록합니다
• ●명의 변경 후 이전 제한 기간이 있을 수 있으므로 일정을 먼저 확인합니다

소스코드를 받았다는 말과 실제로 다시 만들 수 있다는 말은 다릅니다

압축 파일 하나를 받았다고 해서 인수인계가 끝난 것은 아닙니다. 화면에 보이는 결과물만 있고 그것을 만들어 내는 원본이 없으면, 다음 개발자는 수정할 때마다 추측해야 합니다. 확인해야 할 것은 완성된 파일이 아니라 작업 이력이 남아 있는 저장소, 그리고 그것을 실제 서버에 올리는 절차입니다.

환경 설정도 함께 넘어와야 합니다. 결제 연동 키, 메일 발송 설정, 외부 서비스 인증 정보 같은 값은 코드 안이 아니라 서버 설정에 들어 있는 경우가 많습니다. 이 값들이 없으면 코드가 있어도 사이트는 동작하지 않습니다. 인계받은 뒤에는 이 값들을 전부 새로 발급해 이전 담당자가 계속 접근할 수 없도록 정리해야 합니다.

데이터베이스도 마찬가지입니다. 화면에 보이는 게시물과 신청 내역은 코드가 아니라 데이터에 있습니다. 전체 데이터를 받아 실제로 열어 보고, 첨부 파일과 이미지가 함께 넘어왔는지까지 확인해야 합니다. 파일이 외부 저장소에 있다면 그 저장소 계정도 인계 대상입니다.

• ●완성 파일이 아니라 작업 이력이 있는 저장소 접근 권한을 요구합니다
• ●배포 절차와 서버 설정 값이 문서로 함께 넘어와야 합니다
• ●인계 후 모든 연동 키와 비밀번호를 새로 발급합니다
• ●데이터베이스와 첨부 파일, 이미지 저장소까지 포함해 확인합니다

실제로 이전 대상이 되는 계정 목록

막상 정리해 보면 사이트 하나에 연결된 계정이 생각보다 많습니다. 목록을 만들어 두지 않으면 이전 도중에 하나씩 튀어나와 일정을 흔듭니다. 아래 항목을 표로 만들어 각각 명의자, 접속 계정, 결제 수단, 만료일을 채워 두시기 바랍니다.

여기서 자주 빠지는 것이 메일입니다. 도메인을 옮기는 과정에서 메일 설정을 함께 신경 쓰지 않으면 회사 메일이 조용히 끊깁니다. 사이트가 잠깐 안 열리는 것보다 메일이 며칠 사라지는 쪽이 훨씬 큰 사고입니다.

검색·분석 도구 계정도 챙겨야 합니다. 그동안 쌓인 방문 기록과 검색 관련 설정을 제작사 계정에서만 관리하고 있었다면, 회사 계정을 소유자로 추가하는 작업이 필요합니다. 새로 만들면 과거 기록은 돌아오지 않습니다.

• ●도메인 등록기관 계정과 DNS 관리 위치
• ●호스팅 또는 서버 계정과 결제 수단
• ●코드 저장소와 배포 도구 접근 권한
• ●결제 연동 계정, 메일 발송 서비스, 문자 발송 서비스
• ●방문 분석 도구와 검색 관련 도구의 소유자 권한
• ●외부 지도·채널·개발자 콘솔 계정

사이트와 메일이 멈추지 않게 하는 이전 순서

이전 작업에서 가장 흔한 사고는 준비가 끝나기 전에 주소 연결을 먼저 바꿔 버리는 것입니다. 순서는 반대여야 합니다. 새 서버에 사이트를 완전히 올려 동작을 확인하고, 데이터를 최신 상태로 맞춘 뒤, 마지막에 연결을 바꾸는 것이 원칙입니다.

연결을 바꾸기 며칠 전에는 DNS 기록의 유효 시간을 짧게 줄여 두면 전환이 빨라집니다. 전환 직후에는 옛 서버를 바로 내리지 말고 일정 기간 유지합니다. 일부 방문자와 시스템이 한동안 옛 주소를 계속 바라볼 수 있기 때문입니다.

주소 체계가 바뀐다면 옛 주소와 새 주소의 대응표를 만들어 자동으로 연결되도록 처리해야 합니다. 이 작업을 건너뛰면 그동안 쌓아 온 페이지들이 한꺼번에 끊깁니다. 보안 인증서도 새 서버에서 미리 발급해 두어야 전환 직후 경고 화면이 뜨지 않습니다. 메일 관련 기록은 사이트 기록과 분리해 다루고, 옮기지 않을 것이라면 건드리지 않는 편이 안전합니다.

• ●새 환경에서 사이트가 완전히 동작하는 것을 확인한 뒤 연결을 바꿉니다
• ●전환 며칠 전 DNS 유효 시간을 짧게 조정합니다
• ●옛 서버는 전환 직후 바로 내리지 않고 일정 기간 유지합니다
• ●옛 주소와 새 주소의 대응표를 만들어 자동 연결을 설정합니다
• ●인증서를 미리 준비하고 메일 관련 기록은 별도로 취급합니다

지금 업체를 바꾸지 않는 편이 나은 경우

모든 불만이 업체 교체로 해결되지는 않습니다. 요청 대응이 느린 것이 문제라면 계약 조건을 다시 정하는 편이 빠를 수 있습니다. 이전에는 비용과 시간이 들고, 그동안 쌓인 구조를 새로 파악하는 기간도 필요합니다.

성수기를 앞두고 있거나 결제·신청이 활발히 돌아가는 시점이라면 이전 자체가 위험 요소가 됩니다. 이럴 때는 먼저 명의와 접근 권한만 회수해 두고, 실제 이전은 한산한 시기로 미루는 편이 현실적입니다. 명의만 확보해도 협상 위치는 크게 달라집니다.

반대로 미룰 수 없는 경우도 있습니다. 연락이 닿지 않는 상태, 보안 업데이트가 오래 방치된 상태, 사고가 나도 복구할 사람이 없는 상태는 시간이 갈수록 위험이 커집니다. 이 경우에는 이전 비용보다 방치 비용이 큽니다.

• ●대응 속도가 문제라면 계약 조건 재협상이 먼저일 수 있습니다
• ●성수기에는 명의·권한 회수만 먼저 진행하고 이전은 미룹니다
• ●연락 두절이나 장기 방치 상태라면 미루는 쪽이 더 위험합니다
• ●이전 여부와 관계없이 명의 정리는 지금 해 두는 편이 좋습니다

자주 묻는 질문