APP DEVELOPMENT TERM
QA·UAT
품질 확인·사용자 인수 테스트
QA는 앱이 정한 기능과 품질 기준대로 동작하는지 확인하는 과정이고, UAT는 실제 사용자와 운영자가 자기 업무를 끝까지 수행할 수 있는지 확인해 출시·인수 가능 여부를 판단하는 과정입니다.
30초 이해
QA는 약속대로 동작하는지, UAT는 실제로 사용할 수 있는지를 확인합니다
예약 버튼이 눌리고 정보가 저장된다고 해서 서비스가 바로 출시 가능한 것은 아닙니다. 중복 예약이 생기지 않는지, 정원이 찼을 때 올바르게 막히는지, 취소 결과가 고객과 관리자에게 같은 상태로 보이는지처럼 기능과 오류를 확인해야 합니다. 이 과정이 QA에 가깝습니다.
기능이 모두 동작해도 운영자가 새 예약을 찾기 어렵거나 고객이 취소 조건을 이해하지 못하면 실제 업무에는 쓰기 어렵습니다. UAT는 실제 사용자와 운영자가 현실적인 상황을 따라 해보며 서비스가 목적에 맞게 준비됐는지 확인하는 인수 테스트입니다.
언제 사용하는 개념인가요?
주요 기능이 연결됐을 때
화면·서버·관리자·알림이 같은 결과로 이어지는지 기능별 완료 기준에 따라 확인합니다.
실제 운영을 준비할 때
사용자와 운영자가 테스트 계정으로 예약·주문·취소·문의 같은 실제 업무를 끝까지 수행합니다.
출시·인수 여부를 결정할 때
남은 문제의 영향과 대응 계획을 확인하고 지금 출시할지, 보완 후 다시 확인할지 결정합니다.
왜 중요한가요?
동작 확인과 업무 확인을 나눌 수 있습니다
개발 규칙을 통과했는지와 고객·운영자가 실제 목적을 달성하는지를 서로 다른 기준으로 분명하게 확인합니다.
누가 무엇을 확인할지 분명해집니다
개발·QA 담당자만 테스트하지 않고 기획자, 최종 확인자와 운영 담당자가 자기 역할의 결과를 확인합니다.
출시 결정을 기록으로 남길 수 있습니다
오류의 심각도, 수정 여부와 재확인 결과를 남겨 막연한 불안이나 구두 확인이 아니라 근거로 출시를 결정합니다.
실제 상황 예시
동네 클래스 예약 서비스를 출시한다면
같은 예약 흐름을 QA에서는 기능과 예외 조건으로, UAT에서는 수강생·강사·운영자의 실제 사용 과정으로 확인합니다.
QA에서 확인할 기능·오류 조건
- 예약이 한 번만 저장되고 정원이 정확히 줄어드는지
- 마감된 수업과 중복 시간 예약이 올바르게 차단되는지
- 취소·환불 상태가 고객 앱과 관리자 화면에 같게 보이는지
- 권한 없는 사람이 다른 강사의 수업을 바꿀 수 없는지
UAT에서 확인할 실제 업무
- 수강생이 원하는 수업을 찾고 예약 결과를 이해할 수 있는지
- 강사가 오늘의 신청과 취소 내역을 빠르게 처리할 수 있는지
- 운영자가 예외 요청의 담당자와 다음 행동을 판단할 수 있는지
- 처음 사용하는 사람도 별도 설명 없이 핵심 흐름을 끝낼 수 있는지
QA에서 오류가 없더라도 UAT에서 실제 업무를 끝내기 어렵다면 출시 준비가 끝난 것이 아닙니다. 반대로 사용하기 편해 보여도 저장·권한·중복 처리에 문제가 있으면 먼저 품질 보완과 재확인이 필요합니다.
자주 하는 오해
“QA와 UAT는 이름만 다른 같은 테스트다”
QA는 정한 기능·품질 기준의 동작을 주로 확인하고, UAT는 실제 역할과 업무 목적을 끝까지 달성할 수 있는지 확인합니다. 담당자와 질문이 다릅니다.
“개발자가 테스트했으면 고객 검수는 필요 없다”
개발자는 구현 규칙을 잘 알지만 실제 운영 순서와 표현의 이해 여부는 놓칠 수 있습니다. 서비스 담당자와 운영자가 현실적인 시나리오를 직접 확인해야 합니다.
“버그가 하나라도 있으면 출시할 수 없다”
모든 문제의 영향이 같지는 않습니다. 결제·개인정보·핵심 흐름을 막는 문제는 먼저 해결하고, 영향이 낮은 문제는 일정과 대응 방법을 기록해 출시 판단에 반영합니다.
“마지막 날 한 번 시연하면 UAT가 끝난다”
실제 역할별 계정과 데이터로 업무를 수행하고, 발견한 문제를 수정한 버전에서 다시 확인해야 인수 판단의 근거가 남습니다.
우리 서비스에 적용할 때 확인하세요
- 1기능마다 입력·행동·예상 결과로 된 완료 기준이 있나요?
- 2일반 사용자·파트너·운영자처럼 역할별 테스트 계정과 샘플 데이터가 준비됐나요?
- 3정상 상황뿐 아니라 빈 상태·권한 제한·실패·중복 요청도 확인하나요?
- 4발견한 문제의 재현 방법, 영향도, 담당자와 확인할 앱 버전을 함께 기록하나요?
- 5수정 후 재확인 담당자와 최종 출시·인수 결정자가 정해져 있나요?
다음 자료
이해한 내용을 바로 적용해보세요
개발 중간부터 확인할 기준을 읽고, 출시 준비 항목을 직접 점검한 뒤 고객과 운영 흐름을 실제로 연결한 사례를 확인할 수 있습니다.
출시 전에 빠진 준비 항목을 직접 확인해보세요
기능 확인뿐 아니라 계정·스토어 자료·운영 대응과 출시 후 확인 항목까지 순서대로 점검할 수 있습니다.