운영 인수인계
완성해서 넘겨받으면 끝이라고 생각하기 쉽습니다. 그런데 서비스는 만든 뒤에도 계속 돕니다. 도메인이 갱신되고 인증서가 만료되고 백업이 돌아야 합니다. 그리고 그것들이 누구 계정에 매여 있는지가 정해져 있지 않으면, 나중에 옮기려 할 때 그 자체가 협상 대상이 됩니다.
한 문장으로
인수인계는 만들어진 것을 넘기는 일이 아니라, 만든 사람 없이도 운영이 이어지게 만드는 일입니다.
하는 일
- 계정 소유권 — 도메인 · 클라우드 · 코드 저장소가 누구 이름으로 되어 있는가
- 접근 권한 — 누가 무엇에 들어갈 수 있고, 필요할 때 뺄 수 있는가
- 계속 도는 것 — 도메인 갱신, 인증서 갱신, 백업, 모니터링
- 운영 문서 — 배포 방법, 장애 시 확인 순서, 외부 서비스 연락처
- 코드와 산출물 — 어디에 있고 어떤 조건으로 쓸 수 있는가
- 비용 구조 — 매달 무엇에 얼마가, 누구 카드로 나가는가
하지 않는 일
- 유지보수 계약 자체 — 인계는 계약의 조건이지 계약이 아닙니다
- 교육 — 문서로 남기는 것과 사람을 가르치는 것은 다른 일입니다
- 데이터 이관 — 시스템을 바꿀 때 따로 잡아야 하는 작업입니다
이웃 개념과 헷갈리는 지점
- 유지보수 계약만든 뒤에도 손봐 주는 관계
- 인계가 끝나 있으면 계약을 끊어도 서비스가 멈추지 않습니다. 끝나 있지 않으면 그건 계약이 아니라 인질입니다.
- 벤더 종속다른 곳으로 옮기기 어려운 상태
- 종속은 기술로만 생기지 않습니다. 코드가 아무리 표준이어도 도메인이 남의 계정에 있으면 옮길 수 없습니다.
- 문서화적어 두는 일
- 문서는 인계의 일부지 전부가 아닙니다. 권한이 없으면 문서를 읽어도 아무것도 못 합니다. 계정과 문서는 함께 넘어와야 합니다.
- 백업잃었을 때 되살리는 것
- 백업이 돌고 있어도 그 백업에 접근할 계정이 없으면 소용이 없습니다. 인계 목록에 백업 위치와 접근 경로가 들어가야 합니다.
언제 필요한가
이럴 때 필요합니다
- 도메인이 누구 계정으로 등록돼 있는지 모를 때
- 개발사가 바뀌었는데 서버나 저장소에 들어갈 방법이 없을 때
- 담당자가 퇴사한 뒤 배포하는 방법을 아무도 모를 때
- 매달 결제되는 항목이 무엇인지 정리가 안 될 때
아직 아니어도 됩니다
- 아직 만드는 중이라면 완성 시점에 맞춰 정하면 됩니다. 다만 계약서에 항목은 미리 적어 두는 편이 좋습니다
- 사내 인력이 처음부터 함께 만들고 있다면 자연스럽게 이어집니다
- 이미 모든 계정이 회사 이름으로 있고 배포 문서가 있다면 더 할 것이 없습니다
여기서부터는 갈립니다
어디까지가 인계인지는 계약마다 다르고, 분쟁이 나는 자리도 대개 여기입니다. 소스 코드까지인지 서버 설정까지인지, 문서를 어느 수준으로 쓸지가 정해져 있지 않으면 서로 다른 것을 기대한 채 끝납니다. 그리고 받는 쪽에 그것을 이어받을 사람이 있는지는 또 다른 문제입니다. 문서를 아무리 잘 써도 읽을 사람이 없으면 인계는 형식으로 끝납니다.
자주 묻는 질문
회사 이름으로, 회사가 관리하는 계정에 두시는 것을 권합니다. 대행사 계정으로 사 두면 나중에 옮길 때마다 부탁해야 하고, 관계가 틀어지면 그 자체가 협상 카드가 됩니다. 관리를 맡기시더라도 소유는 회사에 두는 편이 안전합니다.
계약서에 적힌 대로입니다. 명시가 없으면 나중에 해석이 갈립니다. 코드 자체뿐 아니라 저장소 접근 권한과 외부 라이브러리 사용 조건까지 함께 확인해 두시는 것이 좋습니다.
계정과 권한, 배포 방법, 그리고 계속 돌고 있는 것들의 목록입니다. 코드만 받으면 대개 배포가 안 됩니다. 설정값과 외부 서비스 연결이 서버 안에만 있는 경우가 흔해서요.
새 담당자가 그것만 읽고 배포와 복구를 할 수 있으면 충분합니다. 반대로 그게 안 되면 분량과 상관없이 부족합니다. 실제로 다른 사람이 문서만 보고 한 번 해 보는 것이 가장 확실한 점검입니다.
오히려 그때 더 필요합니다. 맡기는 동안에도 계정은 회사 것이어야 하고, 언제든 회수할 수 있어야 합니다. 인계가 되어 있는 상태에서 맡기는 것과, 맡길 수밖에 없는 상태는 다릅니다.
범위가 애매해도 괜찮습니다
지금 상황만 알려 주시면 필요한 범위와 대략의 규모를 짚어 드립니다.