노노니 | 실전 서비스 기획자의 인사이트 블로그

외주로 받은 결과물이 기대에 못 미치는 상황은 발주사에게 큰 스트레스입니다. 더 큰 문제는 품질에 대한 불만을 최종 단계에서 제기했을 때 외주사와의 분쟁으로 이어진다는 점입니다. 품질 관리는 마지막이 아니라 처음부터 시작되어야 합니다.

 

최종 테스트 시 품질 문제 제기가 분쟁을 만든다

프로젝트가 거의 끝나고 최종 테스트를 할 때 품질 문제를 제기하면 외주사와 분쟁이 발생하게 됩니다.

왜 분쟁이 발생하는가

최종 단계에서 품질 문제를 처음 제기하면 외주사는 방어적인 태도를 취합니다. "지금까지 아무 말씀이 없으셨는데 갑자기 왜 그러시나요?", "이미 작업이 다 끝났는데 이제 와서 바꾸려면 추가 비용이 필요합니다"같은 반응이 나옵니다. 외주사 입장에서는 프로젝트 내내 발주사가 아무 문제를 제기하지 않았기 때문에, 지금의 품질에 만족한다고 생각했던 것입니다.

시비로 받아들여지는 이유

외주사는 최종 단계의 품질 지적을 시비 걸려고 하는 것으로 받아들입니다. 특히 계약금과 중도금을 이미 받은 상태에서 잔금을 주지 않으려고 트집을 잡는다고 오해하기도 합니다. 이런 상황에서는 정당한 품질 요구도 감정 싸움이 되고, 결과적으로 발주사는 만족스럽지 않은 결과물을 받거나 추가 비용을 지불하게 됩니다.

 

기획과 디자인 단계에서 마음에 들지 않으면 받아들이지 말 것

품질 관리는 개발이 시작되기 전, 서비스 기획과 디자인 단계에서부터 시작되어야 합니다.

기획 단계 검수

서비스 기획서를 받았을 때 내용이 마음에 들지 않는다면 그 자리에서 수정을 요구해야 합니다. "대충 이해는 되니까 넘어가자"는 안 됩니다. 기획서에 빠진 기능이 있거나, 사용자 흐름이 이상하거나, 설명이 불명확한 부분이 있다면 즉시 지적하고 수정본을 받아야 합니다. 기획 단계에서 제대로 정리되지 않은 내용은 디자인과 개발 단계에서 더 큰 문제가 됩니다.

디자인 단계 검수

디자인 시안을 받았을 때도 마찬가지입니다. 색상이 마음에 들지 않거나, 레이아웃이 복잡하거나, 버튼의 위치가 어색하다면 즉시 피드백해야 합니다. "나중에 개발하면서 조정하면 되겠지"라고 생각하면 안 됩니다. 디자인이 확정되면 개발이 그대로 진행되기 때문에, 디자인 단계가 마지막 수정 기회입니다. 마음에 들지 않는 디자인을 받아들이면, 결국 마음에 들지 않는 서비스를 받게 됩니다.

단계별 승인의 중요성

각 단계를 명확히 승인하고 다음 단계로 넘어가야 합니다. "기획서 승인", "디자인 승인"처럼 문서로 남기고, 이후에는 해당 단계로 되돌아가지 않는다는 원칙을 정해야 합니다. 이렇게 하면 외주사도 각 단계에서 최선을 다하게 되고, 발주사도 확실하게 검토하게 됩니다.

 

개발 중에도 3주마다 테스트로 확인

서비스 기획과 디자인이 마음에 들었다면, 이를 구현하는 개발 단계를 최소 3주에 한 번씩은 사용해보는 테스트로 확인해야 합니다.

3주 주기의 의미

개발은 몇 주 또는 몇 달에 걸쳐 진행되는데, 이 기간 동안 아무것도 확인하지 않으면 위험합니다. 3주마다 한 번씩 테스트하면, 문제가 생겨도 3주 치 작업만 되돌리면 되지만, 3개월 후에 테스트하면 3개월 치 작업을 다시 해야 할 수도 있습니다. 3주 주기는 너무 자주 확인해서 외주사를 방해하지 않으면서도, 충분히 진행 상황을 파악할 수 있는 적절한 간격입니다.

직접 사용해보는 테스트

보고서나 스크린샷만 보지 말고, 발주사가 직접 개발 중인 서비스에 접속해서 사용해봐야 합니다. 로그인을 해보고, 메뉴를 눌러보고, 데이터를 입력하고 저장하고 불러오는 전체 과정을 실제 사용자처럼 테스트합니다. 이 과정에서 디자인과 다르게 구현된 부분, 작동하지 않는 기능, 사용하기 불편한 부분을 발견할 수 있습니다.

 

일정 중 문제 제기하지 않으면 만족한 것으로 이해된다

프로젝트가 진행되는 동안 문제를 제기하지 않으면, 외주사는 발주사가 마음에 들어서 아무 말도 하지 않는 것으로 이해합니다.

침묵은 동의가 아니다

발주사가 바쁘거나 귀찮아서 피드백을 미루면, 외주사는 이를 승인으로 받아들입니다. "3주 전에 보여드렸는데 아무 말씀이 없으셔서 괜찮은 줄 알았습니다"라는 변명이 나옵니다. 발주사 입장에서는 나중에 한꺼번에 정리해서 말하려고 했을 뿐인데, 외주사는 침묵을 동의로 해석한 것입니다. 이런 오해를 막으려면 확인할 때마다 즉시 피드백을 주어야 합니다.

최종 테스트 시 품질 문제 제기의 한계

프로젝트 내내 아무 문제를 제기하지 않다가 최종 테스트에서 갑자기 여러 가지를 지적하면, 외주사는 시비를 걸려고 한다고 받아들입니다. "지금까지 괜찮다고 하셨잖아요", "이제 와서 바꾸려면 처음부터 다시 해야 합니다"같은 반응이 나오고, 수정을 거부하거나 추가 비용을 요구합니다. 결국 발주사는 제대로 된 품질을 얻지 못하고 분쟁만 남게 됩니다.

 

좋은 게 좋다고 넘어가지 않는 것이 품질 관리다

품질을 제대로 관리하려면 적당히 타협하지 말아야 합니다. 좋은 게 좋다고 넘어가지 않는 것이 품질을 관리하는 유일한 방식입니다.

작은 불만도 즉시 제기

"이 정도면 괜찮겠지", "사소한 거니까 참자"같은 생각은 품질 저하로 이어집니다. 작은 불만이라도 그때그때 제기해야 합니다. 버튼 색상이 약간 어색하거나, 글자 크기가 조금 작거나, 메뉴 이름이 애매하다면 즉시 수정을 요청합니다. 작은 문제들이 쌓이면 전체적으로 완성도 낮은 서비스가 됩니다.

외주사와의 관계를 걱정하지 말 것

발주사 중에는 외주사와의 관계를 의식해서 피드백을 주저하는 경우가 있습니다. "너무 많이 지적하면 외주사가 기분 나빠하지 않을까", "이미 여러 번 수정 요청했는데 또 하기 미안하다"같은 걱정입니다. 하지만 외주 관계는 비즈니스이고, 발주사는 돈을 지불하는 고객입니다. 정당한 품질 요구는 외주사에게도 명확한 가이드가 되며, 오히려 결과물의 완성도를 높입니다.

 

품질 분쟁 예방을 위한 문서화

모든 피드백과 수정 요청을 문서로 남겨야 합니다.

이메일 기록

구두로만 피드백하지 말고, 이메일로 기록을 남겨야 합니다. 구체적으로 작성하고 외주사의 확인 답변을 받습니다. 나중에 분쟁이 생겼을 때 이런 기록이 증거가 됩니다.

테스트 결과 정리

3주마다 테스트할 때 발견한 문제를 문서로 정리해서 공유합니다. 스크린샷과 함께 "어떤 상황에서 어떤 문제가 발생했는지" 상세히 기록하면 외주사도 재현하기 쉽고, 발주사도 나중에 제대로 수정됐는지 확인할 수 있습니다.

외주 품질 관리는 최종 테스트가 아니라 프로젝트 전체 과정에서 이루어져야 합니다. 기획과 디자인 단계에서 마음에 들지 않으면 즉시 수정을 요구하고, 개발 중에는 3주마다 직접 사용해보며, 작은 문제도 그때그때 제기하는 것이 분쟁을 예방하고 품질을 확보하는 유일한 방법입니다.