외주 개발이 틀어지는 다섯 순간

문제는 대개 개발 중간이 아니라 끝날 무렵에 터집니다. 그리고 그때 터지는 것들은 거의 전부, 시작할 때 한 줄로 물어봤으면 없었을 것들입니다.

1. 소스코드를 못 받는다 “납품 완료”가 무엇을 뜻하는지 정하지 않으면, 결과물이 도는 것만 확인하고 코드는 개발사 쪽에 남습니다. 나중에 다른 곳에 맡기려 할 때 처음부터 다시 만들어야 한다는 답을 듣게 됩니다. 서버 계정, 도메인 관리 권한, 외부 서비스 계정 명의도 같은 문제입니다. 계약 전에 — 소스코드와 서버·도메인 계정은 언제, 어떤 형태로 넘겨받습니까?
2. “다 됐다”의 기준이 없다 만든 쪽은 됐다고 하고 받는 쪽은 아니라고 합니다. 둘 다 거짓말이 아닙니다. 기준을 안 정했을 뿐입니다. 완료 기준은 기능 이름이 아니라 동작 문장이어야 합니다. “신청 폼”이 아니라 “방문자가 폼을 채우고 보내면 담당자 메일함에 도착한다”처럼. 계약 전에 — 무엇이 되면 완료입니까? 항목으로 적어주실 수 있습니까?
3. 수정이 끝나지 않는다 수정 횟수만 적고 ‘수정’이 무엇인지 안 적으면, 문구 하나 바꾸는 것과 화면을 다시 만드는 것이 같은 한 번으로 세어집니다. 결국 한쪽은 손해를 보고 그 손해가 품질로 돌아옵니다. 범위 안의 수정과 범위를 벗어나는 변경을 나누고, 후자는 별도 견적이라고 적어두는 편이 서로에게 낫습니다. 계약 전에 — 어디까지가 포함된 수정이고, 어디부터가 추가 견적입니까?
4. 잔금 시점이 모호하다 “완료 후 지급”은 2번과 묶여서 분쟁이 됩니다. 잔금 조건은 확인 가능한 사건이어야 합니다. 배포된 주소에서 완료 기준 항목이 전부 동작하는 것을 함께 확인한 날처럼. 선금 없이 전액 후불을 요구하면 개발사가 다른 일을 먼저 처리하게 되고, 전액 선불이면 반대쪽 위험이 생깁니다. 절반씩이 대체로 무난합니다. 계약 전에 — 무엇을 확인하면 잔금을 지급합니까?
5. 끝난 뒤에 아무도 없다 납품 다음 날 오류가 나면 누가 봅니까. 유지보수가 포함이 아니면 포함이 아니라고 적혀 있어야 하고, 포함이면 몇 개월간 무엇까지인지 적혀 있어야 합니다. ‘하자 보수’와 ‘기능 추가’는 다른 것이고, 이 둘을 안 나누면 끝난 뒤에 다시 1~3번을 반복합니다. 계약 전에 — 납품 후 오류는 며칠까지, 어떤 범위로 봐주십니까?

다섯 줄로 줄이면

저희는 이렇게 합니다

자랑하려고 적는 게 아니라, 위 다섯을 막는 형태가 어떤 모습인지 보여드리려고 적습니다.

• 착수금 절반으로 시작하고, 배포된 걸 직접 확인하신 뒤 잔금을 받습니다. 잔금 조건이 “완료”가 아니라 “확인”입니다.
• 소스코드는 전부 넘겨드립니다. 이후에 다른 곳에 맡기셔도 그대로 이어집니다.
• 범위를 벗어나는 규모면 그렇다고 먼저 말씀드립니다. 억지로 범위 안에 넣으면 결국 어느 쪽이든 손해입니다.
• 만든 것은 전부 지금 눌러서 확인할 수 있습니다. 캡처가 아니라 도는 링크입니다.