QA와 검수는 어떻게 다를까?

개발 프로젝트가 마무리 단계에 들어가면 “이제 QA만 하면 됩니다” 또는 “클라이언트 검수 후 출시합니다”라는 말을 자주 듣습니다. 두 과정 모두 완성된 결과를 확인한다는 점에서 비슷해 보이지만 목적과 담당자, 확인 기준에는 분명한 차이가 있습니다.

QA는 제품이 의도한 품질로 작동하도록 개발 과정 전반에서 문제를 예방하고 발견하는 활동입니다. 검수는 클라이언트가 합의된 요구사항과 계약 범위를 기준으로 결과물을 확인하고 인수 여부를 결정하는 과정입니다.

QA와 검수를 같은 과정으로 생각하면 책임과 완료 기준이 모호해집니다. 개발사는 “내부 테스트를 통과했으니 완료됐다”고 생각하지만 클라이언트는 “원했던 업무 방식과 다르다”고 판단할 수 있습니다. 반대로 검수 과정에서 기존 범위에 없던 요청까지 모두 오류로 분류하면 일정과 비용을 둘러싼 갈등이 발생합니다.

QA란 무엇일까?

QA는 Quality Assurance의 약자로 일반적으로 품질 보증을 의미합니다. 단순히 완성된 서비스에서 버그를 찾는 작업만을 뜻하지 않습니다. 요구사항을 검토하고, 테스트 기준을 만들고, 기능과 화면을 확인하며, 발견된 문제를 수정한 뒤 다시 검증하는 전체 활동을 포함합니다.

QA의 핵심 목적은 사용자가 서비스를 이용할 때 발생할 수 있는 문제를 출시 전에 발견하고, 동일한 문제가 반복되지 않도록 품질을 관리하는 것입니다.

• 요구사항이 테스트 가능한 형태인지 확인
• 기능별 정상 흐름과 예외 상황 정의
• 사용자 역할별 권한 확인
• 화면과 반응형 동작 확인
• 브라우저와 기기별 호환성 확인
• 오류 등록, 수정과 재검증
• 기존 기능에 문제가 생기지 않았는지 회귀 테스트

전문 QA 담당자가 없는 작은 프로젝트에서는 기획자나 개발자, 프로젝트 매니저가 테스트 업무를 나누어 수행할 수 있습니다. 담당자의 직책보다 중요한 것은 테스트 범위와 기준, 결과가 명확하게 관리되는지입니다.

검수란 무엇일까?

검수는 개발사가 전달한 결과물이 사전에 합의된 요구사항, 기능 범위와 완료 기준을 충족하는지 클라이언트가 확인하는 과정입니다. 영어로는 acceptance testing, user acceptance testing 또는 client acceptance라고 표현할 수 있습니다.

검수에서는 단순히 버튼이 작동하는지만 확인하지 않습니다. 실제 업무 담당자가 서비스 목적에 맞게 사용할 수 있는지, 승인된 정책과 데이터 흐름이 반영되어 있는지, 운영에 필요한 관리자 기능과 자료가 제공되었는지도 확인합니다.

• 합의된 기능이 모두 제공되었는가?
• 승인된 화면과 사용자 흐름이 반영되었는가?
• 실제 운영 시나리오를 수행할 수 있는가?
• 관리자 기능과 권한이 업무 방식에 맞는가?
• 필요한 계정, 문서와 산출물이 전달되었는가?
• 계약상 완료 조건을 충족했는가?

검수 결과 문제가 없다면 클라이언트는 결과물을 승인하고 출시 또는 인수 단계로 이동합니다. 문제가 있다면 수정이 필요한 항목과 승인에 영향을 주지 않는 후속 개선 항목을 구분해야 합니다.

QA와 검수의 가장 큰 차이

QA와 검수의 핵심 차이는 무엇을 기준으로 누가 확인하는가에 있습니다.

• QA의 목적: 제품의 오류와 품질 위험을 발견하고 안정성을 높이는 것
• 검수의 목적: 합의된 요구사항과 계약 범위가 충족되었는지 확인하는 것
• QA 담당자: QA 담당자, 개발자, 기획자 또는 프로젝트 내부 팀
• 검수 담당자: 클라이언트 담당자, 실제 운영자와 최종 승인자
• QA 기준: 기능 명세, 테스트 케이스, 품질 기준과 기술 조건
• 검수 기준: 승인된 요구사항, 화면 설계, 계약 범위와 인수 조건
• QA 시점: 개발 중간부터 출시 전까지 반복적으로 수행
• 검수 시점: 검수 가능한 결과물이 준비된 후 최종 단계에서 수행

QA가 제품을 만드는 팀의 품질 확인 과정이라면, 검수는 제품을 인수하는 쪽의 최종 확인 과정에 가깝습니다. 어느 하나가 다른 하나를 완전히 대신할 수 없습니다.

QA는 개발이 끝난 뒤 시작하는 일이 아니다

QA를 프로젝트 마지막에만 배치하면 문제를 수정할 시간이 부족해집니다. 요구사항이나 화면 설계 단계에서 발견할 수 있었던 문제도 이미 개발이 끝난 뒤 수정해야 하므로 비용이 커집니다.

예를 들어 회원 탈퇴 기능을 개발한 뒤에야 “탈퇴한 회원의 주문 내역은 어떻게 보관할 것인가?”라는 질문이 나오면 데이터 구조와 관리자 화면을 함께 변경해야 할 수 있습니다. 요구사항 검토 단계에서 이 조건을 발견했다면 훨씬 적은 비용으로 해결할 수 있습니다.

QA는 다음과 같이 프로젝트 단계별로 진행할 수 있습니다.

1. 요구사항 단계: 모호하거나 테스트할 수 없는 조건을 찾습니다.
2. 화면 설계 단계: 빠진 상태, 이동 경로와 오류 안내를 확인합니다.
3. 개발 단계: 완료된 기능 단위로 테스트하고 문제를 조기에 발견합니다.
4. 통합 단계: 기능 사이의 연결과 데이터 흐름을 확인합니다.
5. 출시 전: 핵심 사용자 흐름과 운영 환경을 종합적으로 검증합니다.

검수는 무엇을 기준으로 진행해야 할까?

검수를 시작하기 전에 기준 문서가 확정되어 있어야 합니다. 기준이 없으면 담당자의 기억이나 개인적인 선호에 따라 의견이 달라질 수 있습니다.

• 최종 승인된 요구사항 정의서
• 기능 정의서와 화면 설계서
• 프로젝트 범위와 제외 항목
• 변경 요청과 승인 이력
• 기능별 완료 조건
• 지원 브라우저, 기기와 운영 환경
• 전달해야 할 산출물 목록

검수 담당자는 문서의 각 요구사항과 실제 결과를 비교해야 합니다. “느낌이 다르다”는 의견보다 “승인된 화면에서는 이 조건에 버튼이 표시되지만 현재 결과에서는 표시되지 않는다”처럼 기준과 현상을 함께 기록해야 빠르게 판단할 수 있습니다.

오류와 신규 요청을 구분해야 한다

검수에서 가장 많은 갈등이 발생하는 부분은 오류와 신규 요청의 구분입니다. 클라이언트 입장에서는 원하는 대로 동작하지 않는 모든 상황이 문제로 느껴질 수 있습니다. 그러나 개발 범위 관점에서는 합의된 기능이 잘못 구현된 경우와 새로운 기능을 추가하는 경우가 다릅니다.

오류로 볼 수 있는 경우

• 승인된 요구사항과 다르게 동작하는 경우
• 정상적인 입력에서도 기능이 실패하는 경우
• 합의된 브라우저나 기기에서 사용할 수 없는 경우
• 사용 권한이 잘못 적용된 경우
• 저장된 데이터가 사라지거나 잘못 계산되는 경우

신규 요청 또는 범위 변경으로 볼 수 있는 경우

• 기존 문서에 없던 기능을 추가하는 경우
• 승인된 화면 구성이나 업무 흐름을 변경하는 경우
• 합의하지 않은 외부 서비스를 새로 연동하는 경우
• 완료된 기능에 새로운 사용자 역할이나 조건을 추가하는 경우
• 계약 범위에 없던 운영 도구와 통계를 요청하는 경우

모호한 항목은 요구사항, 회의 결정사항과 변경 승인 기록을 확인해 판단해야 합니다. 합의 기록이 잘 관리되어 있을수록 검수 과정의 불필요한 논쟁을 줄일 수 있습니다.

QA에서 확인해야 하는 주요 테스트 유형

기능 테스트

각 기능이 정의된 조건에 따라 올바른 결과를 제공하는지 확인합니다. 입력, 저장, 수정, 삭제, 검색과 상태 변경을 점검합니다.

예외 테스트

필수값 누락, 잘못된 형식, 중복 요청, 이용할 수 없는 상태와 외부 서비스 실패처럼 정상 흐름에서 벗어나는 상황을 확인합니다.

권한 테스트

사용자 역할에 따라 접근 가능한 화면과 데이터가 올바르게 제한되는지 확인합니다. 화면에서 버튼을 숨기는 것뿐 아니라 직접적인 요청도 차단되는지 검증해야 합니다.

사용성 테스트

사용자가 기능의 의미를 이해하고 목표를 완료할 수 있는지 확인합니다. 버튼 이름, 오류 안내, 화면 이동과 정보 배치가 주요 대상입니다.

호환성 테스트

지원하기로 합의한 브라우저, 운영체제와 기기에서 화면과 기능이 정상적으로 작동하는지 확인합니다.

회귀 테스트

오류 수정이나 기능 변경 이후 기존에 정상적으로 작동하던 영역에 새로운 문제가 발생하지 않았는지 다시 확인합니다.

좋은 QA 이슈에는 무엇이 들어가야 할까?

“안 됩니다” 또는 “이상합니다”만으로는 개발자가 문제를 재현하기 어렵습니다. QA 이슈에는 문제를 동일하게 확인할 수 있는 정보가 필요합니다.

• 문제가 발생한 화면과 기능
• 사용한 계정과 권한
• 발생 환경과 기기
• 재현 순서
• 입력한 데이터
• 실제 발생한 결과
• 기대했던 결과
• 화면 캡처 또는 영상
• 심각도와 우선순위

심각도는 문제의 영향 범위를 나타내고 우선순위는 언제 처리할지를 나타냅니다. 결제가 불가능한 문제는 일반적으로 심각도와 우선순위가 모두 높습니다. 반면 일부 문구의 간격 문제는 심각도가 낮더라도 출시 전에 빠르게 처리할 수 있습니다.

검수 기간과 절차는 미리 합의해야 한다

검수를 시작한 뒤 기간과 방법을 정하면 프로젝트 종료가 계속 미뤄질 수 있습니다. 계약이나 킥오프 단계에서 검수 절차를 합의하는 것이 좋습니다.

1. 개발사가 검수 가능한 환경과 안내를 전달합니다.
2. 클라이언트가 정해진 기간에 통합 의견을 작성합니다.
3. 양측이 오류, 확인 필요 사항과 신규 요청을 분류합니다.
4. 개발사가 오류를 수정하고 반영 상태를 기록합니다.
5. 클라이언트가 수정된 항목을 재확인합니다.
6. 잔여 항목과 후속 개선 범위를 분리합니다.
7. 최종 승인자가 검수 완료를 확인합니다.

검수 담당자가 여러 명이라면 클라이언트 측에서 의견을 취합할 담당자 한 명을 지정하는 것이 좋습니다. 서로 반대되는 요청이 개별적으로 전달되면 개발사는 어떤 기준을 따라야 하는지 판단하기 어렵습니다.

QA 완료와 검수 완료의 기준

오류가 하나도 없는 소프트웨어를 보장하기는 현실적으로 어렵습니다. 따라서 QA와 검수의 완료 기준을 사전에 정해야 합니다.

QA 완료 기준에는 핵심 기능 테스트 통과, 치명적 오류 해결, 주요 오류의 허용 수준, 지원 환경 테스트 완료와 회귀 테스트 결과가 포함될 수 있습니다.

검수 완료 기준에는 계약 범위의 기능 제공, 승인된 주요 시나리오 수행 가능, 필수 산출물 전달, 치명적 오류 부재와 잔여 이슈 처리 계획 합의가 포함될 수 있습니다.

서비스 이용을 막지 않는 경미한 이슈는 출시 이후 유지보수 일정으로 분리할 수 있습니다. 다만 어떤 항목을 후속 처리할지, 담당자와 완료 예정일을 명확하게 기록해야 합니다.

QA와 검수를 위한 실무 체크리스트

• 최신 요구사항과 화면 설계가 확정되어 있는가?
• 기능별 테스트 항목과 완료 조건이 있는가?
• QA 환경과 검수 환경이 준비되어 있는가?
• 테스트 계정과 사용자 권한이 구분되어 있는가?
• 오류의 심각도와 우선순위 기준이 있는가?
• 오류와 신규 요청의 분류 기준이 있는가?
• 이슈의 담당자와 처리 상태를 확인할 수 있는가?
• 수정 후 재검증 절차가 있는가?
• 클라이언트 검수 기간과 의견 취합 담당자가 정해져 있는가?
• 최종 승인자와 검수 완료 기준이 명확한가?

QA는 품질을 만들고 검수는 합의된 결과를 확인한다

QA와 검수는 모두 프로젝트의 품질과 성공적인 완료를 위해 필요하지만 같은 과정은 아닙니다. QA는 개발 과정 전반에서 오류와 위험을 줄이는 활동이고, 검수는 클라이언트가 합의된 결과를 받았는지 확인하는 인수 과정입니다.

두 과정이 효과적으로 운영되려면 요구사항, 기능 정의, 화면 설계와 변경 이력이 최신 상태로 연결되어 있어야 합니다. 어떤 기준으로 테스트했고, 어떤 문제가 발견되었으며, 누가 수정하고 승인했는지 추적할 수 있어야 합니다.

Pronika는 요구사항과 테스트 이슈, 담당자, 상태, 결정사항과 변경 이력을 하나의 프로젝트 흐름에서 관리할 수 있도록 돕습니다. QA와 검수의 역할을 명확히 구분하고 동일한 기준 문서를 사용하면 출시 직전의 혼란과 불필요한 검수 분쟁을 줄일 수 있습니다.