저희도 일이 몰릴 때는 외부에 맡깁니다. 그때 무엇을 보는지 적어보면, 앱이나 어플 개발사를 고르시는 데 도움이 될 것 같습니다.
1. 안 되는 걸 안 된다고 하는가
가장 크게 봅니다. 요구사항을 다 듣고 “네, 다 됩니다”라고만 하는 곳은 걸러냅니다.
실제로 만들어 본 사람은 압니다. 어떤 요구는 예산 대비 무리고, 어떤 요구는 기간이 두 배가 됩니다. 그걸 처음에 말해주는 곳이 결국 일정을 지킵니다.
전부 된다고 한 뒤에 “그건 추가입니다”가 반복되면, 처음 견적이 싼 게 아무 의미가 없어집니다.
2. 자기가 만든 걸 직접 굴려봤는가
만들기만 하고 손 떼는 것과, 몇 년째 운영하는 건 다릅니다. 운영해 본 사람은 처음부터 다르게 만듭니다.
- 오류가 나면 어디를 봐야 하는지 미리 심어둡니다.
- 급할 때 기능을 끌 수 있게 만들어 둡니다.
- 데이터를 나중에 찾을 수 있게 남깁니다.
이런 건 운영해 보기 전에는 필요성을 못 느낍니다. 포트폴리오를 볼 때 “만든 것”뿐 아니라 “지금도 굴리고 있는 것”이 있는지 보시면 좋습니다.
만든 경험보다 굴려본 경험이 결과물을 더 크게 바꿉니다.
3. 소통 방식이 정해져 있는가
일이 틀어지는 원인은 대부분 기술이 아니라 소통입니다.
- 얼마나 자주 진행 상황을 공유하나요?
- 어떤 채널로 이야기하나요?
- 중간에 확인할 수 있는 화면을 언제 볼 수 있나요?
“다 만들고 보여드리겠습니다”라는 방식은 위험합니다. 두 달 뒤에 받은 결과물이 생각과 다르면 되돌릴 방법이 없습니다. 저희는 작업 중인 화면을 계속 열어두고 보시게 합니다.
4. 코드를 넘겨주는가
계약서에 소스코드 소유가 명시되어 있는지 꼭 보세요. 이게 없으면 나중에 다른 곳으로 옮길 수가 없습니다.
서버 계정, 도메인, 스토어 계정도 마찬가지입니다. 개발사 명의로 되어 있으면 관계가 끝났을 때 곤란해집니다. 처음부터 고객 명의로 만드는 게 맞습니다.
5. 출시 후를 설명하는가
앱은 만들면 끝이 아닙니다. 출시 후에 무슨 일이 생기는지, 그때 어떻게 대응하는지 설명해 주는 곳을 고르세요.
무상 유지보수 기간이 있는지, 그 뒤에는 얼마인지, 급한 장애가 나면 얼마 만에 대응하는지. 이걸 안 물어보면 나중에 서로 얼굴 붉힐 일이 생깁니다.
피하는 경우
솔직하게 적으면 이렇습니다.
- 요구사항을 자세히 안 듣고 바로 금액부터 말하는 곳
- 계약서에 범위가 안 적힌 곳
- 담당자가 계속 바뀌는 곳
- 다른 회사 포트폴리오를 자기 것처럼 보여주는 곳
마지막은 실제로 있는 일입니다. 궁금하면 “이 프로젝트에서 어느 부분을 맡으셨나요?”라고 구체적으로 물어보세요. 직접 한 일이면 바로 답이 나옵니다.
정리
기술력을 판단하기는 어렵습니다. 대신 위의 다섯 가지는 비전문가도 확인할 수 있습니다. 저희도 이 기준으로 고릅니다.
광주에서 개발사를 찾고 계시다면 이 다섯 가지로 저희도 한번 재 보세요. 만든 것들에 실제로 굴러가는 서비스 8개를 적어 두었고, 비용도 공개해 두었습니다. 둘 다 확인 가능한 것들입니다.