초록
홈페이지 프로젝트에서 발주자의 협상력이 가장 높은 시점은 계약할 때가 아니라 잔금을 치르기 직전입니다. 그런데 이 시점에 대부분 화면만 확인하고 넘어갑니다. 몇 달 뒤 업체를 바꾸거나 연락이 끊겼을 때, 사이트는 살아 있는데 손댈 방법이 없다는 것을 그제야 알게 됩니다. 이 글은 인수 대상을 도메인 · 서버 · 소스 · 계정 · 원본 · 문서 여섯 묶음으로 나누고, 각 묶음에서 "받은 것처럼 보이지만 실제로는 아닌 상태" 를 구분합니다. 핵심은 하나입니다. 접근 권한과 소유는 다릅니다. 아이디를 받은 것과 명의가 우리 앞으로 되어 있는 것은 완전히 다른 상태이고, 관계가 나빠지는 순간 그 차이가 전부입니다.
1. 잔금 전에 해야 하는 이유
인수인계는 오픈 후에 하는 행정 절차처럼 느껴지지만, 실제로는 대금 지급과 순서를 맞춰야 하는 협상 항목입니다.
잔금을 치른 뒤에는 이런 일이 생깁니다. 업체 입장에서 인수 작업은 추가 매출이 없는 일이고, 다음 프로젝트가 이미 시작됐습니다. 악의가 없어도 우선순위에서 밀립니다. "다음 주에 정리해서 드릴게요"가 두어 번 반복되면 그대로 잊힙니다.
그래서 순서는 이렇게 잡습니다.
계약서에 이 순서가 적혀 있으면 가장 좋고, 없더라도 잔금 요청을 받았을 때 "인수 목록부터 확인하겠습니다"라고 말하는 것만으로 충분히 통합니다. 정상적인 업체는 거부할 이유가 없습니다. 거부한다면 그 자체가 확인해야 할 신호입니다.
2. 접근 권한과 소유는 다르다
인수 확인에서 가장 자주 속는 지점입니다. 아래 두 상태는 겉으로 똑같아 보입니다.
| 접근 권한만 있는 상태 | 소유한 상태 | |
|---|---|---|
| 로그인 | 된다 | 된다 |
| 내용 수정 | 된다 | 된다 |
| 업체가 권한을 빼면 | 못 들어간다 | 못 뺀다 |
| 결제 수단 | 업체 카드 | 우리 카드 |
| 명의 | 업체 사업자 | 우리 사업자 |
| 업체 폐업 시 | 복구 수단 없음 | 그대로 유지 |
"관리자 아이디 드렸습니다"는 왼쪽 상태입니다. 평소에는 아무 차이가 없다가, 관계가 끝나는 순간에만 차이가 드러납니다. 그리고 그때는 이미 늦습니다.
갈림길로 그리면 이렇게 됩니다.
확인 질문은 하나면 됩니다.
"이 계정에서 업체 쪽 계정을 삭제해도 저희가 계속 쓸 수 있나요?"
이 질문에 "네"가 나오는 항목만 인수된 것입니다.
인수 대상 여섯 묶음
아래가 이어질 3~8장의 지도입니다. 위쪽일수록 잃었을 때 되돌리기 어렵습니다.
3. 묶음 하나 — 도메인
여섯 묶음 중 하나만 챙길 수 있다면 이것입니다. 도메인만 우리 것이면 최악의 경우에도 다른 곳에서 사이트를 새로 띄워 원래 주소로 서비스할 수 있습니다. 반대로 도메인이 남의 것이면 나머지를 다 가져도 주소를 잃습니다.
확인할 것은 세 가지입니다.
- 등록자(소유자) 정보가 우리 회사·담당자로 되어 있는가 — 등록 대행 업체 이름이 아니라
- 등록 대행사 계정에 우리가 직접 로그인할 수 있는가 — 업체 계정 안의 하위 관리 권한이 아니라
- 소유자 이메일이 우리가 받는 메일함인가 — 만료 안내와 소유권 변경 승인 메일이 여기로 옵니다
세 번째가 특히 중요합니다. 도메인 관련 중요한 절차는 대부분 등록 정보에 적힌 이메일로 확인 메일을 보내는 방식으로 진행됩니다. 그 메일함이 업체 것이면 실질적인 통제권도 업체에 있습니다.
이전이 필요하다면
이미 업체 계정에 등록돼 있다면 등록 대행사를 옮기거나(기관 이전) 같은 대행사 안에서 계정 간 이동을 요청하게 됩니다. 절차와 제한은 대행사마다, 도메인 종류(.com / .co.kr 등)마다 다릅니다. 대체로 인증 코드 발급과 소유자 확인 메일이 필요하고, 등록·이전 직후 일정 기간은 이전이 막히는 경우가 있습니다.
그래서 실무적으로는 이렇게 처리합니다. 정확한 절차는 해당 대행사 고객센터에 직접 확인하고, 업체에는 "인증 코드 발급"과 "소유자 이메일 변경"만 요청하세요. 업체 설명만 믿고 기다리다 만료일이 지나는 사고가 실제로 있습니다.
만료일은 캘린더에 넣어 두세요. 자동 갱신이 걸려 있어도 결제 카드가 업체 것이면 어느 시점에 끊깁니다.
4. 묶음 둘 — 서버와 호스팅
사이트가 실제로 돌아가는 곳입니다. 형태에 따라 확인할 것이 다릅니다.
| 형태 | 확인할 것 |
|---|---|
| 웹호스팅·임대형 서비스 | 계정 명의, 결제 수단, 관리 콘솔 로그인 |
| 클라우드 서버 | 계정 명의, 결제 수단, 서버 접속 키, 어느 리전에 무엇이 떠 있는지 |
| 배포 플랫폼 | 조직(팀) 소유자가 누구인지, 우리가 소유자 권한을 갖고 있는지 |
여기서 자주 놓치는 것이 결제 수단입니다. 업체 카드로 결제되고 있으면 매달 비용을 청구받는 형태가 되고, 관계가 끝나면 결제가 끊기면서 서비스가 정지됩니다. 인수 시점에 우리 카드로 바꿔 두는 것이 가장 확실합니다.
또 하나, 어디에 무엇이 있는지 목록을 받아야 합니다. 서버 한 대만 있는 줄 알았는데 이미지 저장소·데이터베이스·메일 발송 서비스가 각각 다른 곳에 있는 경우가 흔합니다. 목록이 없으면 나중에 하나씩 사고로 발견하게 됩니다. 매달 나가는 비용 항목 전체는 웹서비스 월 운영비 항목표에 정리해 두었습니다.
5. 묶음 셋 — 소스 코드와 빌드
"소스 코드를 받았다"는 말이 실제로는 세 가지 다른 상태를 뜻합니다.
상태 A — 압축 파일 하나를 받았다. 최소한입니다. 문제는 이게 최신 버전인지 확인할 방법이 없다는 것과, 이후 수정 이력이 없다는 것입니다.
상태 B — 저장소(GitHub 등) 접근 권한을 받았다. 낫지만 여전히 업체 계정 안입니다. 권한을 빼면 끝입니다.
상태 C — 우리 계정의 저장소로 옮겨졌고, 우리가 소유자다. 이게 인수된 상태입니다.
C로 만드는 것이 어렵지 않습니다. 우리 이름으로 계정을 하나 만들고 그쪽으로 옮겨 달라고 요청하면 됩니다. 이력까지 통째로 넘어옵니다.
그리고 소스보다 더 자주 빠지는 것이 있습니다.
- 환경 변수와 접속 정보 — 데이터베이스 주소, 외부 서비스 키. 소스에는 없고 서버에만 있습니다
- 빌드·배포 방법 — 소스를 받아도 띄우는 방법을 모르면 다른 업체가 견적을 높게 부릅니다
- 데이터베이스 백업 파일 — 소스는 껍데기고 내용은 여기 있습니다
"다른 개발자가 이 자료만 보고 로컬에서 띄울 수 있나요" 가 판정 기준입니다. 인수 시점에 실제로 한 번 띄워 보는 것이 가장 확실하고, 이걸 다음 유지보수 업체 후보에게 검토 의뢰하는 방법도 있습니다.
6. 묶음 넷 — 각종 계정
수가 많아서 목록으로 관리하지 않으면 반드시 빠집니다. 아래를 표로 만들어 명의 / 로그인 가능 여부 / 결제 수단을 채우게 하세요.
□ 도메인 등록 대행사
□ 서버·호스팅·배포 플랫폼
□ 데이터베이스 (별도 서비스인 경우)
□ 관리자 페이지 최고 관리자
□ Google Analytics / Search Console
□ 네이버 서치어드바이저
□ 결제사(PG) 상점 관리자
□ 문자·알림톡 발송 서비스
□ 메일 발송 서비스
□ 지도·주소 검색 등 외부 API 키
□ SNS 연동 앱 (로그인·공유용)
□ SSL 인증서 (자동 갱신이 아닌 경우)
이 중 결제사와 문자 발송사는 원래 사업자 명의로만 가입되는 경우가 많아 대체로 안전합니다. 반대로 분석 도구와 API 키는 개발자가 자기 계정으로 만들어 두는 일이 매우 흔합니다. 나쁜 의도가 아니라 그게 빠르기 때문입니다. 초기에 요청하면 대부분 그대로 해 줍니다.
Google Analytics를 놓치면 그동안 쌓인 방문 데이터를 통째로 잃습니다. 이건 복구가 안 됩니다.
7. 묶음 다섯 — 디자인 원본과 콘텐츠
화면에 보이는 이미지 파일이 아니라 수정할 수 있는 원본을 말합니다.
- 디자인 원본 파일 (Figma 파일 또는 그에 준하는 편집 가능 파일)
- 로고 원본 — 확대해도 깨지지 않는 형식으로
- 사용한 폰트 이름과 라이선스 범위
- 사용한 사진의 출처와 라이선스
뒤의 두 항목이 실무에서 문제가 됩니다. 업체가 자기 회사 라이선스로 구매한 폰트나 유료 사진을 쓴 경우, 그 라이선스는 우리에게 넘어오지 않습니다. 계약이 끝난 뒤에 사용 중지 요청을 받을 수 있습니다. 인수 시점에 "이 사이트에 쓰인 폰트와 사진의 라이선스가 저희 앞으로 유효한가요"를 한 번 물어보고 답을 기록으로 남겨 두세요.
8. 묶음 여섯 — 문서
가장 안 챙기고 가장 아쉬운 묶음입니다. 화려할 필요 없이 아래 정도면 충분합니다.
- 계정·서비스 목록 (6번의 표)
- 서버 구성 한 장 — 무엇이 어디서 돌고 무엇에 연결되는지
- 관리자 사용법 — 자주 하는 작업 다섯 개만 캡처와 함께
- 장애 시 연락처 — 호스팅·결제사·도메인 대행사
- 정기 작업 — 갱신해야 하는 것과 그 시점 (도메인 만료, 인증서, 결제사 심사)
특히 마지막 항목이 실질적입니다. 1년 뒤에 무엇이 만료되는지를 아는 것만으로 대부분의 갑작스러운 사고를 피합니다.
9. 이미 늦었다면 — 최소 방어선
오픈한 지 한참 됐고 인수를 안 했다면, 그리고 업체와 관계가 애매하다면 우선순위는 이렇습니다.
1순위 · 도메인. 소유자 정보와 이메일을 우리 것으로 바꾸는 것부터. 이것만 되면 최악의 상황에서도 새로 만들어 같은 주소로 서비스할 수 있습니다.
2순위 · 데이터. 회원·주문·게시글을 지금 내려받아 두세요. 관리자에 엑셀 내려받기가 있으면 그걸로 충분합니다. 없으면 요청하세요. 데이터는 복구가 안 되는 유일한 항목입니다.
3순위 · 분석 계정. 소유자 권한을 우리 계정에 추가해 달라고 요청. 데이터 이력이 걸려 있습니다.
4순위 · 소스와 서버. 가장 늦게 해도 됩니다. 최악의 경우 다시 만들 수 있는 항목이기 때문입니다. 비용은 들지만 되돌릴 수 없는 종류의 손실은 아닙니다.
요청할 때는 분쟁 프레임을 만들지 않는 편이 실제로 잘 통합니다. "혹시 담당자가 바뀔 때를 대비해 저희 쪽 명의로 정리해 두려고 합니다" 정도면 대부분 협조합니다. AI로 만든 사이트를 넘겨받는 경우처럼 애초에 만든 주체가 회사 밖에 있는 상황은 AI로 뽑은 홈페이지를 회사 사이트로 쓸 때에서 따로 다뤘습니다.
10. 인수 확인표
잔금 전에 이 표를 채워서 업체에 보내면 됩니다. 빈칸이 남으면 그게 협의할 항목입니다.
□ 도메인
□ 등록자 명의 우리 회사 □ 소유자 이메일 우리 메일함
□ 대행사 계정 직접 로그인 가능 □ 만료일 확인: ____년 __월 __일
□ 서버·호스팅
□ 계정 명의 우리 □ 결제 수단 우리 카드
□ 구성 목록 수령 (무엇이 어디에)
□ 소스·데이터
□ 우리 계정 저장소로 이전 완료
□ 환경 변수·접속 정보 전달
□ 데이터베이스 백업 파일 수령
□ 빌드·배포 방법 문서 수령
□ (권장) 제3자가 실제로 띄워 보는 확인
□ 계정
□ 12개 항목 표 작성 완료 (명의/로그인/결제)
□ 업체 계정을 빼도 우리가 계속 쓸 수 있는지 확인
□ 원본·라이선스
□ 디자인 원본, 로고 원본
□ 폰트·사진 라이선스가 우리 앞으로 유효한지 확인
□ 문서
□ 관리자 사용법 □ 장애 연락처 □ 1년 내 만료 목록
11. 마지막으로
이 목록의 목적은 업체를 의심하는 것이 아닙니다. 좋은 업체와 일해도 담당자는 바뀌고 회사는 없어질 수 있기 때문입니다. 인수 확인은 관계가 좋을 때 해야 쉽고, 관계가 나빠진 뒤에는 하나하나가 협상이 됩니다.
계약 전 단계에서 미리 명의를 지정해 두는 방법은 업체를 검증하는 7가지 확인에, 오픈 이후 매달의 범위를 문장으로 고정하는 방법은 홈페이지 유지보수, 월 얼마가 정상인가에 있습니다. 새로 맡길 곳을 찾는 중이라면 외주 개발 비용 계산기에서 범위를 먼저 잡아 보셔도 됩니다.