클라이언트가 "알아서 해주세요"라고 하면 프로젝트가 망하는 이유
목차(6)
한줄 요약
"알아서 해주세요"는 외주 개발 실패의 가장 흔한 시작점이다.
외주 개발에서 가장 위험한 말은 "대충 좋게 만들어 주세요"다. 개발 업체 입장에서 이 말은 사실상 '기준 없이 일하라'는 뜻이다. 결과물이 나왔을 때 클라이언트가 "이게 아닌데요"라고 하면, 업체도 클라이언트도 서로 억울하다. 문제는 처음부터 판단 기준이 없었다는 것이다.
왜 기준이 없으면 결과물도 없는가
개발 프로젝트에는 반드시 '무엇이 완성이고, 무엇이 실패인가'를 정의하는 기준이 필요하다. 이걸 명확히 하지 않으면 개발자는 자기 기준으로 판단한다. 기능이 동작하면 완성이다. 버튼이 눌리면 통과다. 오류 메시지가 없으면 정상이다.
그런데 클라이언트가 원한 건 그게 아니다. 특정 흐름에서 사용자가 막히지 않아야 하고, 데이터가 정확하게 처리되어야 하고, 예외 상황에서도 서비스가 멈추지 않아야 한다. 이런 기준은 말하지 않으면 전달되지 않는다.
결국 기능은 다 구현됐는데 쓸 수 없는 서비스가 나온다. 양쪽 다 열심히 했는데 결과가 이렇게 되는 건, 기준이 없어서다.
"그건 업체가 알아서 해야 하는 거 아닌가요"
맡기는 사람 입장에서 흔히 이런 생각을 한다. '전문가한테 맡겼으니 알아서 잘하겠지.' 앱 개발 외주나 웹 개발 외주를 처음 맡겨보는 클라이언트일수록 이 함정에 빠진다.
개발 업체는 기술을 실행하는 전문가다. 그러나 '이 서비스가 어떤 상황에서 어떻게 작동해야 하는지'는 클라이언트가 가장 잘 안다. 내 비즈니스 로직, 내 고객의 행동 패턴, 내 운영 방식. 이건 외주 개발사가 알 수 없다.
기준을 만드는 건 개발 업체의 일이 아니다. 기준에 맞게 구현하는 게 개발 업체의 일이다. 이 두 가지를 섞으면 프로젝트 전체가 흔들린다.
클라이언트가 가져와야 할 것들
그렇다면 클라이언트는 무엇을 준비해야 하는가. 거창한 기획서나 전문 문서가 필요한 게 아니다. 다음 세 가지면 충분하다.
첫째, 이 기능이 왜 필요한가. 사용자가 어떤 문제를 겪고 있어서, 이 기능으로 무엇을 해결하려 하는지. 이걸 알면 개발사는 구현 방향을 올바르게 잡는다.
둘째, 어떤 상황에서 실패로 볼 것인가. 성공 기준보다 실패 기준이 더 중요하다. 어떤 경우에 "이건 안 된다"고 말할 수 있는지를 미리 정의해 두면, 검수 단계에서 분쟁이 줄어든다.
셋째, 이미 존재하는 기록. 서비스 기획안, 경쟁사 앱을 쓰며 적어 둔 메모, 고객 인터뷰 내용, 내부 운영 규정. 이런 자료들은 개발사에 맥락을 준다. 새로 정리하지 않아도 된다. 있는 것을 주면 된다.
이런 자료들이 쌓여 있는 회사는 외주 개발 결과물의 품질이 눈에 띄게 다르다. 같은 개발사, 같은 예산이어도 결과가 다른 건 대부분 이 차이에서 온다.
개발사가 기준을 함께 만들어야 할 때
클라이언트가 처음 서비스를 만드는 경우, 또는 업무 경험은 있어도 그걸 기술 요구사항으로 옮겨 본 적이 없는 경우에는 개발사가 기준을 함께 도출해 주는 역할을 해야 한다.
좋은 개발 외주사는 단순히 시키는 것만 만들지 않는다. 클라이언트가 말하지 못한 것을 질문으로 끌어내고, 모호한 요구사항을 구체적인 기능 정의로 바꾼다. "로그인 기능이 필요해요"라는 말에서 "어떤 방식으로 인증할 것인지, 비밀번호 분실 처리는 어떻게 할 것인지, 소셜 로그인은 포함인지"를 묻는 것. 이게 진짜 협업이다.
프로젝트 초반에 이 대화를 제대로 하는지 여부가 최종 결과물의 품질을 결정한다고 해도 과언이 아니다.
"확인해 드릴게요"가 아니라 "같이 확인합시다"
외주 개발이 끝나고 납품됐을 때, 클라이언트가 할 일이 하나 있다. 직접 써보는 것이다. 개발사가 테스트했다고 끝이 아니다. 실제 사용자가 겪는 흐름을 클라이언트가 직접 경험해야 한다.
개발사의 테스트는 기능이 동작하는지를 확인한다. 클라이언트의 검수는 서비스가 의도대로 작동하는지를 확인한다. 이 두 가지는 다르다. 둘 다 해야 한다.
검수를 대충 넘기고 오픈한 뒤 문제가 터지면, 그건 개발사만의 문제가 아니다. 기준을 주지 않았고, 확인도 하지 않은 클라이언트도 그 결과를 함께 감당한다.
자주 묻는 질문
Q.요구사항 정리를 잘 못하는 클라이언트라면 외주 개발을 맡기면 안 되는 건가요?
그렇지 않다. 요구사항 정리를 돕는 것도 좋은 개발 외주사의 역할 중 하나다. 처음부터 완벽한 기획서를 가져올 수 있는 클라이언트는 많지 않다. 다만 '왜 이 서비스를 만드는지', '누가 쓸 것인지', '가장 중요한 기능이 무엇인지' 정도는 클라이언트 스스로 답할 수 있어야 한다. 이 세 가지가 있으면 나머지는 함께 만들 수 있다.
Q.기준을 명확하게 줬는데도 결과물이 기대와 다를 때는 어떻게 해야 하나요?
기준이 있었다면 어디서 어긋났는지 추적이 가능하다. 중간 점검 없이 처음부터 끝까지 내달리면 후반에 방향 수정 비용이 커진다. 2~3주 단위로 중간 결과물을 확인하고, 기준과 비교하며 방향을 조정하는 방식이 손실을 줄인다. 외주 개발은 한 번에 완성되는 게 아니라 함께 수렴해 가는 과정이다.
Q.이미 만들어진 서비스를 개편할 때도 같은 원칙이 적용되나요?
오히려 더 중요하다. 기존 서비스에는 이미 사용하는 유저가 있고, 건드리면 안 되는 흐름이 있다. 어떤 부분을 바꾸고 어떤 부분은 반드시 유지해야 하는지, 이 기준이 없으면 개편이 아니라 파괴가 된다. 기존 서비스의 운영 방식이 담긴 문서나 로그가 있다면, 개편 전에 반드시 개발사에 공유해야 한다.
관련 아티클
관련 사례
이 글의 키워드와 맞닿은 실제 개발 사례를 함께 보세요.
