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

외주로 서비스를 개발할 때 "QA(품질보증) 테스트는 누가 하나요?"라는 질문을 자주 받습니다. 원칙적으로는 외주사가 담당하지만, 실제로는 프로젝트 규모와 계약 내용에 따라 다릅니다. QA와 검수의 차이를 이해하고, 책임 소재를 명확히 해야 분쟁을 막을 수 있습니다.

 

QA 테스트는 외주사의 책임입니다

QA(Quality Assurance) 테스트는 외주사의 프로젝트 매니저가 주도하여 진행하는 것이 맞습니다. 외주사는 납품 전에 자체적으로 품질을 점검하고, 오류를 수정하고, 일정 수준 이상의 완성도를 갖춘 상태로 발주사에게 전달해야 합니다.

QA는 외주사의 내부 프로세스입니다. 개발자가 작업을 완료하면, 테스터나 PM이 다시 점검하고, 문제가 있으면 개발자에게 돌려보내 수정하게 합니다. 이 과정을 거쳐 "이제 발주사에게 보여줄 수 있는 수준이다"라고 판단되면 그때 검수를 요청합니다.

발주사는 QA 과정에 직접 참여할 필요는 없습니다. 다만 외주사가 "QA를 진행하고 있습니다"라고 할 때, 실제로 하고 있는지 정기 미팅에서 확인하는 것은 필요합니다.

 

중소 규모는 검수로 대체하기도 합니다

하지만 중소 규모의 프로젝트는 별도의 QA 테스트 없이 작업 완료 검수 테스트로 대체하기도 합니다. 프로젝트 규모가 작고 예산이 제한적이면, 전담 QA 인력을 투입하기 어렵기 때문입니다.

개발자가 작업을 완료 후 바로 발주사에게 검수를 요청하고, 발주사가 테스트하면서 발견한 문제를 피드백하는 방식으로 프로젝트를 관리하면 안 됩니다. 오류의 검사를 발주사가 해주면 발견하지 못한 오류에 대하여 발주사 책임을 주장할 수도 있습니다.

 

QA와 검수 테스트의 목적은 다릅니다

QA 테스트의 목적은 일정 품질 이상의 결과물인지 여부를 확인하는 것입니다. 품질 기준에 미치지 못하면 다시 작업해서 품질을 올리는 외주사의 내부 테스트입니다. 발주사에게 보여주기 전에 외주사가 스스로 "이 정도면 괜찮다"고 확신할 수 있는 수준으로 만드는 과정입니다.

검수 테스트의 목적은 작업이 완료되었는지 확인하고, 서비스를 정상적으로 오픈할 수 있는지 오류를 점검하는 것입니다. 기획서와 계약서에 명시된 기능이 모두 구현되었는지, 치명적인 버그는 없는지 확인하는 발주사의 최종 점검입니다.

이상적으로는 QA를 거친 완성도 높은 결과물을 검수하는 것이지만, QA 없이 검수로 대체한다면 검수의 범위가 넓어집니다.

 

검수가 QA를 대체하면 범위가 넓어집니다

QA 테스트를 검수 테스트로 대체하는 경우, 검수는 기능의 오류, 수정 사항뿐만 아니라 기준에 못 미치는 결과물에 대한 지적까지 포함됩니다.

단순히 "로그인이 안 됩니다"(오류) 뿐만 아니라, "로그인 화면의 디자인 완성도가 낮습니다"(품질), "사용자 경험이 불편합니다"(UX), "속도가 너무 느립니다"(성능) 같은 피드백도 검수 단계에서 해야 합니다.

이런 방식으로 진행한다면 검수 기간을 충분히 확보해야 합니다. 검수에 1-2주는 필요하며, 수정 사항이 많으면 더 걸릴 수 있습니다. 계약서에 "검수 기간 2주, 수정 완료 후 재 검수, 검수 통과 후 최종 납품"을 명시하는 것이 좋습니다.

 

미팅 없이 진행하면 원치 않는 결과물이 나옵니다

서비스 제작 과정에서 외주사가 바쁘다는 핑계로 발주사와 미팅을 하지 않고 작업을 진행하는 경우가 있습니다. "지금은 작업에 집중하고 있어서 다음 달에 한 번에 보여드리겠습니다" 같은 식입니다.

이렇게 되면 발주사가 원하는 결과물이 아니라 외주사가 만들고 싶은 대로 만들어놓고 검수를 요청하는 상황이 생깁니다. 한 달 동안 아무 피드백 없이 작업했으니, 방향이 완전히 빗나갈 수 있습니다.

검수 시점에 "이건 제가 원한 게 아닌데요"라고 하면, 이미 많은 작업이 완료된 상태라 수정하기 어렵습니다. 외주사는 "처음부터 이렇게 만들기로 했다"고 주장할 수도 있습니다.

그래서 매주 미팅하고, 결과물을 지속적으로 확인하는 것이 중요합니다. "바쁘니까 나중에 보여주겠다"는 말을 받아들이면 안 됩니다.

 

추가 비용 청구 분쟁이 생길 수 있습니다

더 심각한 문제는 추가 비용 분쟁입니다. 서비스를 인수받아 오픈하자니 품질이 너무 낮고, 원하는 방향대로 수정을 요청하니 외주사가 "발주사가 중간에 확인하지 않아서 그렇다. 이제 와서 수정하려면 추가 작업이므로 추가 비용을 내야 한다"고 주장하는 경우입니다.

외주사 논리는 이렇습니다: "중간에 보여드렸을 때 피드백을 안 주셨으니, 이대로 진행하는 줄 알았습니다. 지금 수정하려면 이미 완료된 작업을 다시 해야 하니 추가 비용이 필요합니다."

발주사 논리는 이렇습니다: "기획서에 명시된 대로 만들지 않았으니, 계약 범위 내에서 다시 만들어야 합니다. 추가 비용을 낼 이유가 없습니다."

이런 분쟁을 막으려면 정기적인 미팅과 확인을 계약서에 명시해야 합니다. "주 1회 미팅을 통해 진행 상황을 점검하며, 발주사의 피드백을 즉시 반영한다" 같은 조항을 넣으세요.

 

검수 기준을 사전에 합의하세요

검수 시 분쟁을 막으려면 검수 기준을 사전에 합의해야 합니다. "무엇을 만족하면 검수 통과인가?"를 명확히 정하는 것입니다.

예를 들어:

• 기획서에 명시된 모든 기능이 작동할 것
• 주요 브라우저(크롬, 사파리, 엣지)에서 정상 작동할 것
• 치명적인 오류(서버 다운, 데이터 손실 등)가 없을 것
• 페이지 로딩 속도가 0.1~2.5초 이내일 것
• 디자인이 시안과 일치할 것

이런 기준을 계약서나 기획서에 체크리스트 형태로 넣어두면, 검수 시 "이것은 통과", "저것은 미달"을 명확히 판단할 수 있습니다.

 

검수 불합격 시 조치를 정하세요

검수 결과 불합격이면 어떻게 하는지도 사전에 정해야 합니다.

일반적인 프로세스는:

1. 발주사가 검수하고 불합격 사항을 문서로 정리해서 전달
2. 외주사가 수정 작업 진행
3. 재검수 진행
4. 합격할 때까지 반복

여기서 중요한 것은 수정 기한입니다. "검수 불합격 시 7일 이내 수정 후 재검수"처럼 명시하세요. 그렇지 않으면 "다음 달에 수정해드리겠습니다" 하며 계속 미룰 수 있습니다.

또한 재검수 횟수 제한도 고려하세요. "3회 재검수 후에도 불합격 시 계약 해지 가능"처럼 정해두면, 외주사도 신중하게 작업할 것입니다.

 

발주사도 검수에 책임을 다해야 합니다

외주사만 책임지는 것이 아닙니다. 발주사도 검수에 성실히 임해야 합니다. 검수를 대충 하고 넘어갔다가, 오픈 후에 문제를 발견하고 "왜 이렇게 만들었냐"고 하면 외주사 입장에서는 억울합니다.

검수 기간 동안:

• 모든 기능을 빠짐없이 테스트하세요
• 발견한 문제는 즉시 문서로 정리해서 전달하세요
• 애매한 것은 물어보고 명확히 하세요
• 추가 요구사항과 계약 범위 내 수정을 구분하세요

검수를 통과했다는 것은 "이 상태로 오픈해도 문제없다"고 발주사가 인정한 것입니다. 검수 통과 후에는 계약 범위 내 수정을 요구하기 어렵습니다.

 

베타 테스트를 활용하세요

외주사의 QA와 발주사의 검수를 거쳤어도, 실제 사용자가 사용하면 예상 못한 문제가 생깁니다. 그래서 정식 오픈 전에 베타 테스트를 하는 것이 좋습니다.

지인, 잠재 고객, 얼리어답터 등 소수의 사용자에게 먼저 공개하고, 피드백을 받아 수정한 후 정식 오픈하세요. 베타 테스트 기간은 1-2주 정도면 충분합니다.

베타 테스트에서 나온 수정 사항은 계약 범위에 포함되는지 외주사와 협의해야 합니다. 사소한 오류 수정은 포함되지만, 새로운 기능 추가는 추가 비용이 발생할 수 있습니다.