사이트가 열리고 결제가 끝나면 프로젝트가 끝난 것 같습니다. 그런데 인수는 별도의 절차입니다. 인수가 제대로 되지 않은 사이트는 겉으로는 멀쩡하고, 문제는 몇 달 뒤 다른 사람이 손을 대야 할 때 드러납니다. 그때 “코드가 어디 있는지 모른다” 는 상태이면 사실상 처음부터 다시 만들어야 합니다.
인수받을 것은 세 묶음입니다. 파일, 계정, 문서. 각 묶음마다 목록을 만들어 하나씩 체크하면 30분이면 끝납니다.
묶음 1 — 파일
전체 백업이 가장 중요합니다. 파일과 데이터베이스가 같은 시점으로 함께 있어야 하고, 받은 뒤에는 한 번 복구해 봐야 합니다. 복구해 본 적 없는 백업은 백업이 아닙니다. 복구 테스트까지가 인수 절차라고 생각하세요.
커스텀 코드는 별도로 확인합니다. 구매한 테마를 그대로 쓴 경우가 아니라면, 제작 과정에서 작성된 코드가 어딘가에 있습니다. 그 코드가 어느 파일에 있는지, 저장소에 올라가 있는지를 묻습니다. 저장소 소유권은 앞 회차에서 다룬 그대로입니다.
원본 자산은 나중에 반드시 필요해집니다. 로고를 명함이나 인쇄물에 써야 할 때, 웹용으로 줄인 이미지만 있으면 다시 만들어야 합니다. 벡터 원본과 편집 가능한 파일을 받아 두세요.
묶음 2 — 계정
계정은 비밀번호를 받는 것이 아니라 소유자가 되는 것이 목적입니다. 인수 시점에 모든 계정을 우리 이름으로 정리하고, 그다음 비밀번호를 전부 변경합니다. 제작 과정에서 여러 사람이 공유했을 가능성이 높기 때문입니다.
인수 후에는 제작사 계정을 삭제하거나 권한을 낮춥니다. 유지보수 계약이 이어진다면 필요한 만큼의 권한만 남기고, 이어지지 않는다면 정리합니다. 이것은 신뢰의 문제가 아니라 관리의 문제입니다 — 쓰지 않는 관리자 계정이 남아 있는 것 자체가 위험입니다.
묶음 3 — 문서
가장 자주 빠지고, 가장 늦게 아쉬워지는 묶음입니다. 문서라고 해서 두꺼울 필요는 없습니다. A4 두세 장이면 충분하고, 다음 사람이 읽고 이어받을 수 있으면 됩니다.
들어갈 내용은 이렇습니다. 어떤 테마와 플러그인을 왜 썼는지, 특별히 손댄 부분이 어디인지, 서버 환경이 어떻게 구성되어 있는지, 정기적으로 해야 하는 일이 있다면 무엇인지. 마지막으로 주의사항 — “이 플러그인은 업데이트하면 이 부분이 깨진다” 같은 것들입니다. 이런 정보는 그 사람의 머릿속에만 있고, 인수 때 묻지 않으면 영영 사라집니다.
우리가 인수인계에 넣는 것
이 사이트가 작업을 맡을 때도 같은 원칙을 씁니다. 작업 전후 측정 결과, 무엇을 왜 바꿨는지의 기록, 그리고 이후 운영에서 주의할 점을 함께 전달합니다. 업그레이드 작업의 가치는 “지금 빨라진 것” 이 아니라 “다음에 또 안 깨지는 것” 에 있고, 그것을 만드는 것이 문서이기 때문입니다.
어떤 순서로 작업하고 무엇을 기록으로 남기는지는 작업 과정에 공개돼 있습니다. 사이트를 스스로 점검해 보고 싶다면 무료 도구 페이지의 진단 플러그인으로 현재 상태를 먼저 볼 수도 있습니다.
다음 회차
인수가 끝나면 운영이 시작됩니다. 다음 회차는 유지보수 계약 — 응답 시간과 범위를 어떻게 적어야 실제로 작동하는지 다룹니다.