소프트웨어 인수인계 체크리스트: 외주사가 떠날 때 무엇을 갖고 있어야 하나

기존 제품을 넘겨받아 달라며 회사들이 저희를 찾아올 때 반복되는 패턴이 있습니다. 법적으로는 코드를 소유하고 있는데도 배포를 못 합니다. 저장소는 있습니다. 배포 계정은 퇴사한 사람의 것입니다. 도메인은 외주사 명의로 등록되어 있습니다. 프로덕션에 어떤 환경 변수가 필요한지 아무도 모릅니다.

악의인 경우는 드뭅니다. 대개는 누군가의 머릿속에 있던 것을 아무도 적어 두지 않았을 뿐입니다. 그러나 결과는 같고, 막아야 할 시점은 프로젝트 시작 전이지 끝날 때가 아닙니다.

소유란 실제로 무엇인가

소프트웨어를 소유한다는 건 다섯 가지이고, 코드는 그중 첫 번째일 뿐입니다.

1. 코드를 이력과 함께 갖고 있다.
2. 깨끗한 기계에서 빌드하고 실행할 수 있다.
3. 누구에게도 묻지 않고 배포할 수 있다.
4. 의존하는 계정과 도메인을 통제한다.
5. 바꿀 수 있을 만큼 결정 사항을 이해한다.

하나라도 빠지면 갖고 있는 건 제품이 아니라 의존 관계입니다.

체크리스트

코드

• 저장소가 여러분 조직에 있다. 개인 계정도, 외주사 것도 아니다.
• 온전한 이력이 있다. 하나로 뭉갠 커밋이 아니다. 이력은 문서입니다.
• 모든 브랜치와 태그. 현재 프로덕션에서 도는 태그 포함.
• 디자인 원본 파일(피그마 등)이 여러분 워크스페이스에 있고, 폰트와 라이선스가 기록되어 있다.

빌드와 실행

• 깨끗한 기계에서 통하는 README. 이 시험은 말 그대로입니다. 프로젝트를 본 적 없는 사람이 그대로 따라 해서 앱을 띄웁니다. 4단계에서 막히면 아직 안 된 것입니다.
• 의존성 버전이 고정되고 잠금 파일이 커밋되어 있다.
• .env.example에 모든 변수, 용도, 어디서 얻는지가 적혀 있다.
• 테스트 실행 방법과, 통과했을 때의 모습.

배포

• 직접 프로덕션에 배포할 수 있고, 인수인계 전에 실제로 한 번 해 봤다. "필요하면 할 수 있다"가 아니라 해 봤다.
• 파이프라인 설정이 저장소에 있다. 아무도 볼 수 없는 대시보드에서 클릭한 것이 아니다.
• 롤백 방법을 알고 있고 시도해 봤다.
• DB 마이그레이션이 문서화되어 있고 프로덕션 적용 방법도 포함한다.

계정과 도메인

가장 큰 고통을 만드는 항목군입니다. 하나하나가 작고 잊기 쉽기 때문이죠.

• 도메인 등록기관이 여러분 명의이고, 갱신 카드가 누군가의 재직 여부로 만료되지 않는다.
• DNS와 각 레코드의 용도 기록.
• 호스팅, 클라우드, CDN.
• 앱스토어와 플레이 콘솔이 여러분 조직에 있고 서명 키와 인증서도. 안드로이드 서명 키를 잃으면 그 앱을 다시는 업데이트할 수 없습니다.
• 이메일, 트랜잭션 메일 업체, 그리고 이를 인증하는 DNS 레코드.
• 오류 추적, 분석, 결제 업체.
• 모든 서드파티 API 키와, 어느 계정에 과금되는지.

항목마다 확인하세요. 소유자가 회사가 통제하는 주소입니까? 개인의 업무 메일이 아니라, 퇴사해도 남는 공용 주소나 역할 주소여야 합니다.

이해

• 짧은 아키텍처 메모: 구성 요소가 무엇이고 요청이 어떻게 흐르는지.
• 적어 두지 않으면 다음 엔지니어가 어리둥절할 선택에 대한 결정 기록. 왜 이 DB인지. 왜 저 프레임워크가 아닌지. 왜 이 이상한 우회가 있는지.
• 운영 지침서: 무엇이 고장 나는지, 알림이 무슨 뜻인지, 새벽 두 시에 무엇을 해야 하는지.
• 알려진 문제와 의도적인 지름길을 정직하게 적은 것.

결정 기록은 아무도 쓰지 않는데 가치가 가장 높은 문서입니다. 코드는 무엇을 했는지 보여 줍니다. 무엇이 기각되었고 왜인지를 보여 주는 건 적어 둔 결정뿐이고, 그것이야말로 여러분이 이미 수업료를 낸 실수를 다음 팀이 되풀이하지 않게 막아 줍니다.

관계가 끝나기 전에 검증하세요

인수인계 문서는 주장일 뿐입니다. 그것을 쓴 사람들과 아직 연락이 될 때 검증하세요.

둘 다 한나절을 들일 가치가 있는 연습입니다.

• 깨끗한 기계 시험. 그 프로젝트를 해 본 적 없는 사람이 새 노트북으로 README를 따라 로컬에서 띄웁니다. 막히는 지점 하나하나가 문서의 결함입니다. 그 자리에서 고치세요.
• 배포 시험. 여러분 팀이 사소한 변경을 프로덕션에 올리고, 확인하고, 롤백합니다. 어느 한 단계라도 외주사가 필요하면 인수인계는 끝나지 않은 것입니다.

이것들은 최종 지급 전에 하세요. 이후가 아니라. 불신이 아니라, 모두가 아직 자리에 있고 동기도 있는 유일한 순간이기 때문입니다.

시작할 때 세팅해 두세요

위의 거의 전부가 첫날에는 사소하고 아홉 달째에는 비쌉니다. 킥오프 때:

• 여러분 조직에 계정을 만들고 거기로 외주사를 초대하세요. 반대가 아니라.
• 도메인은 직접 등록하세요.
• 계정 소유에는 처음부터 역할 주소를 쓰세요.
• 문서는 "완료"의 일부이지 마무리 작업이 아니라고 합의하세요.

이렇게 세팅하면 인수인계는 사건이 아니게 됩니다. 모든 것이 애초에 여러분 것이었으므로, 접근 권한 몇 개를 회수하는 일이 됩니다.

계약 전에 물어볼 것

저희를 포함해 어떤 외주사에게든 던져 볼 가치가 있는 세 가지 질문.

• 계정은 누구 명의가 됩니까? 처음부터 귀사 명의, 가 유일하게 좋은 답입니다.
• 여러분 없이 저희가 배포할 수 있습니까? 그리고 끝난 뒤가 아니라 프로젝트 진행 중에 그걸 증명할 수 있습니까?
• 3개월 차에 협업을 멈추면 어떻게 됩니까? 정직한 답은 절차를 설명합니다. 모호한 답은 경고입니다.

자기 일에 자신 있는 외주사가 무언가를 붙들고 있을 이유는 없습니다. 이 답들이 불편하게 느껴진다면, 그것이 영업 대화 전체에서 얻을 수 있는 가장 유용한 정보입니다.