개발사를 바꾸기로 했습니다 — 다음 업체가 이어받으려면 무엇을 받아야 하나

인수인계가 실패하는 이유는 대부분 코드가 아니라 계정입니다.

소스코드는 설계도입니다. 그런데 서비스가 실제로 돌아가는 곳은 서버이고, 그 서버에 들어가려면 계정이 필요합니다. 도메인도, 결제도, 문자 발송도 각각 계정에 묶여 있습니다.

코드는 있는데 이것들이 없으면 벌어지는 일:

서버에 접속을 못 해 배포를 할 수 없습니다

도메인을 못 옮겨 새 서버로 주소를 돌릴 수 없습니다

결제·문자 연동을 다시 신청해야 하고, 심사에 다시 시간이 걸립니다

데이터베이스에 못 들어가 기존 데이터를 옮길 수 없습니다

이 상태에서 다음 개발사가 할 수 있는 말은 하나입니다. "새로 만드는 게 빠릅니다."

개발사 명의로 되어 있기 쉬운 것:

클라우드 계정 (AWS, 네이버클라우드 등)

도메인 등록 계정

결제 대행사 가맹점

문자·알림톡 발송 계정

앱스토어 개발자 계정

가급적 계약 시점부터 발주사 명의로 만드는 편이 낫습니다. 나중에 옮기는 것보다 처음부터 우리 것으로 시작하는 쪽이 훨씬 쉽습니다.

아래를 하나씩 짚어 요청하십시오. "인수인계 부탁드립니다" 로는 절반만 옵니다.

코드와 문서

계정과 권한

데이터

커밋 이력이 없으면 곤란해집니다. 코드를 압축 파일로만 받으면 왜 그렇게 짰는지 알 길이 없습니다. 저장소를 통째로 받으십시오.

무엇을 받느냐만큼 언제 받느냐가 중요합니다.

잔금을 치르기 전에 받으십시오.

정산이 끝나면 개발사가 협조할 이유가 사라집니다. 나쁜 뜻이 아니라 다음 일이 밀려 있기 때문입니다. 관계가 좋게 끝나도 응답은 느려집니다.

권장 순서:

1. 인수인계 목록을 문서로 합의 — 위 목록을 보내고 무엇을 언제 줄지 회신받습니다

2. 받은 것으로 실제 동작을 확인 — 다음 개발사(또는 아는 개발자)가 받은 자료만으로 서버를 띄워봅니다

3. 부족한 것을 요청 — 이 단계에서 빠진 게 반드시 나옵니다

4. 확인이 끝난 뒤 잔금

2번을 건너뛰면 자료가 다 온 줄 알았는데 안 돌아가는 상황이 됩니다. 압축 파일을 받았다고 인수인계가 끝난 게 아닙니다.

관계를 상하지 않게 하려면: 개발사 잘못이 아니어도 이 절차는 밟는 게 좋습니다. "다음 담당자가 확인해야 해서요" 라고 말하면 대부분 이해합니다.

업체를 정하기 전에 인수 가능한지부터 검토받으십시오. 받고 나서 알면 되돌릴 수 없습니다.

검토 요청할 때 보낼 것:

소스코드 (또는 저장소 읽기 권한)

어떤 기술로 만들어졌는지

서버 구성

지금 겪고 있는 문제

돌아올 답은 대개 셋 중 하나입니다:

"이어받을 수 있습니다" — 구조가 표준적이고 문서가 있는 경우입니다.

"파악에 시간이 필요합니다" — 가장 흔합니다. 남의 코드를 읽는 데는 원래 시간이 듭니다. 이 파악 기간을 견적에 포함해 달라고 요청하십시오. 나중에 추가 비용으로 나오는 것보다 낫습니다.

"새로 만드는 게 낫습니다" — 이 말이 나오면 근거를 물으십시오. 정말 그럴 수도 있고, 남의 코드를 만지기 싫어서일 수도 있습니다. "어느 부분이 문제인지" 를 구체적으로 답하지 못하면 후자일 가능성이 있습니다. 두 곳 이상에 물어보면 판단이 섭니다.

주의: 기존 개발사에 대한 불만을 길게 설명하지 마십시오. 새 개발사는 그 얘기로 현재 상태를 판단하지 못하고, 견적만 방어적으로 올라갑니다. 코드와 사실만 보내는 편이 정확한 답을 받습니다.