납품 끝난 뒤 개발사와 연락이 끊겼다 — 도메인·서버 되찾는 순서

사이트는 오늘도 잘 열립니다. 주문도 들어오고 관리자 화면도 로그인됩니다. 그런데 지난달부터 개발사 담당자가 메시지를 읽지 않고, 대표 번호는 없는 번호가 됐습니다. 지금 멈춘 곳은 없습니다. 문제는 멈췄을 때 손댈 사람이 없다는 것입니다.

이 상태에서 먼저 확인할 것은 날짜 세 개입니다. 소스코드를 찾는 일은 그다음에 해도 늦지 않습니다. 이 셋은 예고 없이, 정해진 날짜에 서비스를 멈춥니다.

도메인 만료일

SSL 인증서 유효기간 만료일

클라우드·도메인 요금이 빠져나가는 카드의 명의와 유효기간

도메인 만료일은 후이즈나 가비아의 도메인 검색창에 주소를 넣으면 나옵니다. 터미널이 익숙하면 whois 명령 한 줄로도 Expiration Date를 볼 수 있습니다. 도메인이 만료되면 사이트만 멈추지 않습니다. 그 도메인을 쓰는 회사 메일도 같이 끊깁니다. 발주 확인 메일, 세금계산서 알림, 다른 서비스의 비밀번호 재설정 메일이 전부 그 주소로 오고 있었다면 복구 창구까지 함께 막힙니다. .com 같은 gTLD는 만료 직후 바로 사라지지 않습니다. ICANN이 정한 수명주기에 따라 상환유예 30일, 삭제대기 5일이 이어집니다. 이 기간에 되살릴 수는 있지만 별도의 복구 수수료가 붙습니다. 수수료 금액과 남은 날짜는 등록기관마다 정책이 다르니 등록기관에 직접 확인하세요.

SSL 인증서는 브라우저 주소창의 자물쇠를 눌러 인증서 정보를 열면 유효기간이 보입니다. 무료 인증서(Let's Encrypt)는 유효기간이 90일이라 서버 안에서 자동 갱신이 계속 돌고 있어야 유지됩니다. 그 갱신이 개발사가 만든 스크립트나 개발사 계정에 걸려 있으면 어느 날 갱신이 멈춥니다. 인증서가 만료되면 전 페이지에 경고 화면이 떠서 방문자가 그 자리에서 이탈합니다. 사람이 클릭으로 넘길 수 없는 서버 간 통신(결제 승인 요청, 소셜 로그인 콜백, 외부 시스템이 보내는 웹훅)은 경고를 무시할 방법이 없어 그대로 실패합니다.

카드는 클라우드 요금과 도메인 갱신비가 누구 명의로 결제되는지를 봅니다. 매달 오는 결제 영수증 메일이 우리 메일함에 한 건도 없다면 결제 주체가 우리가 아닐 수 있습니다. 클라우드 콘솔의 청구 화면이나 등록기관 고객센터에서 청구 대상 계정을 확인하세요. 개발사 카드로 빠져나가고 있었다면 폐업과 동시에 결제가 실패하고, 미납이 이어지면 계정이 정지되면서 데이터 접근까지 막힙니다. 이 경우 도메인이나 인증서 만료일보다 먼저 서비스가 멈출 수 있습니다.

세 날짜 중 가장 가까운 날이 실질적인 마감입니다. 달력에 적어두고 그 안에 아래 명의 확인과 회수 절차를 끝낸다는 계획으로 움직이세요. 연락이 끊긴 지 얼마 되지 않았고 계약 기간이 아직 남아 있다면 외주 개발자가 잠수/지연될 때 대응 방법의 내용증명과 해지·정산 절차가 먼저입니다. 이 글은 그 단계가 지나 계약으로 붙잡을 것이 남지 않은 뒤를 다룹니다.

"우리 사이트니까 우리 것"이라는 감각과 실제 명의는 따로 놉니다. 도메인은 우리 이름으로 되어 있는데 서버는 개발사 계정이거나, 서버는 우리 계정인데 앱은 개발사의 개발자 계정으로 출시돼 있기도 합니다. 한 군데가 우리 것이어도 나머지가 개발사 명의면 서비스는 그대로 못 움직입니다. 다섯 곳을 각각 조회하세요.

난이도 열은 회수에 상대의 동의가 필요한지를 기준으로 매긴 구분입니다. 조사 표본이 있는 수치가 아니니 우리 상황에 맞춰 다시 판단하세요.

gTLD는 GDPR 이후 등록자 개인정보가 가려진 채로 표시되지만, 등록기관 이름과 네임서버는 그대로 보입니다. 이 둘만 알아도 어느 회사에 문의해야 하는지는 정해집니다. 그다음 판별은 직접 해보는 편이 빠릅니다. 그 등록기관이나 클라우드에 회사 이메일 주소로 로그인 또는 비밀번호 재설정을 시도해 보세요. 재설정 메일이 우리 메일함으로 오면 명의는 이쪽이고, 가입 이력이 없다고 나오면 개발사 쪽입니다. 개발사가 만들어 준 회사 메일 계정이 따로 있었다면 그 메일함도 함께 열어보세요. 가입 확인 메일과 청구서가 그 안에 쌓여 있기도 하고, 그 계정은 서버가 살아 있는 동안에만 열립니다.

코드 저장소는 조직 계정 소유인지 개인 계정 소유인지부터 봅니다. 조직 소유라면 소유자 목록에 우리 쪽 계정을 추가해 달라고 요청할 대상이 분명합니다. 개인 계정 아래에 있으면 플랫폼이 대신 넘겨주지 않으므로, 계약서에 저작재산권 이전 조항이 있는지부터 확인해야 합니다. 조항이 있다면 그 조항이 청구의 근거가 됩니다. 판단 기준은 소스코드 소유권은 누구에게에 정리해 두었습니다.

결제 관련 계정은 조회 창구가 하나 더 있습니다. PG 정산 계좌가 우리 사업자 계좌로 되어 있다면 PG사 고객센터에 사업자등록번호를 대고 가맹점 명의를 조회하세요. 우리 명의로 확인되면 연동 키 재발급 절차와 필요한 서류를 그 자리에서 물어보면 됩니다. 재발급을 받으면 기존 키로 동작하던 결제가 멈출 수 있으니, 새 키를 넣을 개발자를 먼저 확보한 뒤 신청하세요.

아래 순서로 움직입니다.

1. 서면으로 인수인계를 요청하고 기록을 남긴다

2. 폐업인지 잠수인지 가른다

3. 소유권 증명 자료를 한 묶음으로 만든다

4. 도메인은 등록기관에, 서버는 클라우드에 각각 신청한다

5. 회수를 기다리는 동안 이전 준비를 병행한다

답이 없을 걸 알면서도 메일과 문자로 인수인계 요청을 보냅니다. 등록기관이나 클라우드 지원팀에 신청을 넣을 때, 연락을 시도했으나 응답이 없었다는 기록 자체가 증빙이 되기 때문입니다. 보낸 날짜와 내용이 남는 수단을 쓰세요. 요청 문구에는 도메인 주소, 서버 계정 이메일, 저장소 주소처럼 넘겨받을 대상을 하나씩 적고 회신 기한을 함께 씁니다. 계약서에 산출물 인계 조항이 있다면 조항 번호를 인용해 두세요. 나중에 내용증명으로 올릴 때 그대로 쓸 수 있습니다.

다음은 폐업인지 잠수인지 가르는 일입니다. 국세청 홈택스의 사업자등록상태 조회에 사업자등록번호를 넣으면 계속사업자·휴업자·폐업자가 바로 나옵니다. 번호는 계약서나 세금계산서에 적혀 있습니다. 법인이면 대법원 인터넷등기소에서 법인등기부등본을 떼어 해산·청산 등기가 올라와 있는지 확인합니다. 폐업이 확인되면 협의할 상대가 사라진 것이므로 답장을 더 기다릴 이유가 없습니다. 각 플랫폼의 절차로 바로 넘어가세요. 계속사업자로 나오는데 연락만 닿지 않는 경우라면 내용증명이 아직 효력을 갖습니다. 등기부에 적힌 본점 주소로 보내면 수령 여부가 기록에 남습니다.

그다음 소유권 증명 자료를 한 묶음으로 만듭니다. 요구 서류는 사업자마다 다릅니다. 신청 전에 각 창구에 목록을 물어보되, 아래 자료는 미리 한 폴더에 모아두면 왕복이 줄어듭니다.

계약서와 견적서

대금을 보낸 이체 내역과 세금계산서

도메인·서버 요금을 결제한 카드 명세

사업자등록증

개발사와 주고받은 메일·메신저 기록 (요청과 무응답이 함께 보이도록 날짜순으로)

홈택스 사업자등록상태 조회 결과 화면

상표등록증 (등록해 둔 경우)

상표등록증을 목록에 넣은 이유가 있습니다. 도메인을 상표권으로 되찾는 UDRP 절차는 상표에 대한 권리를 전제로 합니다. 등록상표가 없어도 상호를 오래 써서 인지도가 쌓였다면 미등록 상표로 제기할 수 있지만, 그때는 그 인지도 자체를 따로 소명해야 해서 등록상표가 있을 때보다 훨씬 어렵습니다. 등록상표가 있어도 도메인과 상표의 유사성, 상대에게 정당한 이익이 없을 것, 부정한 목적으로 등록·사용했을 것을 모두 소명해야 합니다. 개발사가 우리 요청으로 대신 등록해 준 도메인이라면 마지막 요건을 어떻게 소명할지가 쟁점이 됩니다.

도메인과 서버는 창구가 다르므로 따로 신청합니다. 도메인은 등록기관 고객센터에 등록자 변경이나 계정 복구를 신청합니다. 우리 상표를 그대로 쓴 도메인이 개발사 명의로 잡혀 있다면 위의 분쟁 절차도 검토 대상입니다. 이때는 분쟁 절차에 드는 비용과 기간을, 새 도메인으로 옮길 때 드는 비용과 기간과 나란히 적어 비교해 결정하세요. 비교표에 들어갈 항목은 그 도메인으로 들어오던 검색 유입, 이미 인쇄된 명함·간판·차량 스티커, 거래처와 고객이 알고 있는 메일 주소, 그리고 포털과 지도 서비스에 등록해 둔 사업장 정보입니다. 바꿔야 할 것이 적으면 새 도메인 쪽 기간이 짧습니다.

클라우드 계정을 통째로 넘겨받으려면 원칙적으로 상대의 동의가 필요합니다. 계정 이전은 루트 계정 이메일과 결제수단을 바꾸는 일이고, 그 통제권은 루트 자격증명을 쥔 쪽에 있기 때문입니다. 그래서 현실적인 목표를 데이터 반출로 잡습니다. 관리자 화면이나 서버에 접속이 되는 동안 데이터베이스 덤프, 업로드된 파일, 환경설정 값을 우리 저장소로 내려받아 두면, 계정 회수가 끝내 안 되더라도 새 서버에서 서비스를 다시 세울 수 있습니다.

마지막으로, 회수를 기다리는 동안 이전 준비를 같이 합니다. 만료일이 촉박하면 순서를 지킬 여유가 없습니다. 등록기관 계정이 열렸다면 우선 우리 카드로 갱신부터 걸어 시간을 벌고, 계정이 안 열리는 동안에는 새 도메인과 새 서버 준비를 병행하세요. 먼저 열리는 쪽을 씁니다. 회수와 재구축 중 하나를 미리 정해둘 필요는 없습니다. 새 서버 준비는 계정 개설과 결제수단 등록까지만 해두어도 충분합니다. 이전 작업 자체는 데이터가 손에 들어온 다음에 시작하면 됩니다.

계정도 코드도 없고 화면만 남았다면, 무엇이 회수되고 무엇이 재구축인지 선이 분명합니다.

브라우저에 보이는 화면은 그대로 건집니다. 지금 보고 있는 페이지는 이미 내 컴퓨터로 내려받아진 결과물입니다. 전 페이지를 스크롤 캡처로 남기고, 관리자 화면까지 포함해 화면 이름과 버튼이 하는 일을 옆에 적어두면 새 개발사에 넘길 기획서가 됩니다. 다만 고쳐 쓸 수 있는 원본 소스코드는 이 캡처에 들어 있지 않습니다.

데이터는 지금 빼둬야 합니다. 관리자 화면에 엑셀 내려받기 기능이 있으면 오늘 회원·주문·게시물을 전부 받으세요. 서비스가 살아 있는 동안에만 되는 일입니다. 내려받기 기능이 없으면 화면을 한 장씩 옮겨 적는 방법이 남습니다. 이때 개인정보가 그대로 딸려 나오므로 저장 위치와 접근 권한을 정해 두고 작업하고, 옮긴 파일에는 암호를 걸어두세요. 비밀번호 항목은 애초에 가져올 수 없습니다. 정상적으로 만들어진 시스템이라면 해시로 저장되어 원문이 남아 있지 않기 때문입니다. 회원 쪽은 새 시스템에서 비밀번호 재설정 안내를 보내거나 재가입으로 넘기는 방식이 현실적입니다.

문서는 흩어진 채로 이미 갖고 있습니다. 처음 받은 견적서, 메신저와 메일에 남은 기능 설명, 검수 때 주고받은 수정 요청이 사실상 유일한 요구사항 명세입니다. 날짜순으로 모아 한 파일로 만들어 새 개발사에 넘기면 견적 정확도가 올라갑니다. 화면 캡처와 이 파일을 함께 주면 상대가 물어볼 것이 줄어듭니다.

여기서부터는 재개발입니다. 소스코드가 남아 있는 경우에도 문서 없는 코드를 분석하는 데 2~4주가 걸릴 수 있습니다. 소스가 아예 없으면 분석 단계는 없고 전부 새로 만듭니다. 다만 유리한 점이 하나 있습니다. 이미 돌아가는 화면이 있어서 무엇을 만들지가 확정돼 있고, 그만큼 기획 왕복이 줄어듭니다. 그러니 서비스가 아직 살아 있을 때 시작하세요. 멈춘 다음에는 화면도 데이터도 볼 수 없습니다. 기존 시스템을 이어받을 때의 견적 구조는 레거시 개선/리팩토링 외주 견적 산정 기준에 정리해 두었습니다.

다음 개발사와 시작할 때는 돈이 빠져나가는 계정을 전부 우리 명의로 둡니다. 개발사에는 권한만 줍니다. 권한은 언제든 회수할 수 있고, 소유권은 회수하려면 상대의 동의가 필요합니다. 연락이 끊긴 순간 그 동의를 받을 방법이 사라지는 것이 이 사고의 구조입니다.

아래 항목은 개발이 시작되기 전에 계약서에 넣거나 최소한 메일로 합의해 두세요. 다 만들어진 뒤에 요구하면 이미 개발사 명의로 만들어진 계정을 옮기는 작업이 되어 일정과 비용이 따로 붙습니다.

서버·클라우드 요금을 어느 명의로 결제해야 하는지, 운영 단계에서 매달 무엇이 나가는지는 서버/클라우드 비용은 누가 내나에 더 자세히 정리해 두었습니다.

기존 시스템을 인수하거나 다시 세워야 하는 상황이라면, 남아 있는 화면과 데이터만 있어도 범위 산정은 시작할 수 있습니다. 현재 상태를 정리해 알려주시면 프리시에서 인수 가능한 범위와 재구축이 필요한 범위를 나눠 정리해 드립니다.