QA 아웃소싱 업체 선정 가이드 · 2026

QA 외주는 한 가지 일이 아닙니다. 셋으로 갈립니다. 품질 기준과 출시 게이트를 세워 달라는 진단·컨설팅, 합의한 범위를 대신 실행해 달라는 실행 대행, 배포마다 되풀이되는 회귀를 자산으로 옮겨 달라는 자동화입니다. 셋은 고르는 잣대도 계약 형태도 다릅니다. 출시일이 코앞인데 컨설팅 중심의 공급사를 부르면 진단 문서만 남은 채 날짜가 옵니다. 반대로 팀마다 결함 등급이 제각각인 조직이 실행 인력만 받으면 인력이 빠지는 순간 이전 상태로 되돌아갑니다. 제안 요청서를 쓰기 전에 지금 비어 있는 것이 판단 체계인지 실행 손인지 반복 비용인지를 한 줄로 적어야 합니다. 이 구분 없이 받은 견적들은 서로 다른 일을 값매긴 문서라 나란히 놓아도 비교가 성립하지 않습니다. 계약 형태는 업무의 확정 범위와 변경 가능성을 보고 정합니다. 산출물이 정해진 구간은 고정가로, 지속 실행은 기간과 투입 규모로 제안받을 수 있습니다. 자동화는 구축분과 유지분을 나눠 받습니다. 한 계약에 여러 업무를 담더라도 항목별 범위와 금액을 구분하면 변경 이유를 추적할 수 있습니다. 세 갈래 밖에 놓이는 일도 미리 갈라 둡니다. 성능과 부하, 장애 복구 검증은 실행 대행과 이름이 비슷하지만 부하 모델을 만드는 준비가 실행보다 큰 별개의 일입니다. 세 갈래를 한 공급사가 이어서 받을 수 있는지도 함께 봅니다. 진단으로 세운 판정 잣대를 실행이 그대로 쓰고 실행에서 쌓인 케이스가 자동화 대상이 되면 중간마다 생기는 인수인계 손실이 사라집니다.

결과표를 주는 것과 출시 가능 여부를 판정하는 것은 같은 일이 아닙니다. 통과 건수와 실패 건수만 넘겨받으면 그 숫자를 읽어 출시를 결정하는 몫이 다시 발주 조직으로 돌아옵니다. 판정까지 맡기려면 세 가지를 확인합니다. 첫째로 판정 어휘가 문서에 미리 정의돼 있는지 봅니다. 출시 가능·READY WITH CONDITIONS·보류처럼 세 값이 고정돼야 회의에서 해석이 갈리지 않습니다. 둘째로 확인하지 못한 영역을 결과와 같은 문서에 적는지 확인합니다. 검증하지 않은 자리를 적지 않으면 통과율이 실제보다 넓게 읽힙니다. 셋째로 누가 결과를 작성하고 검토하며 출시를 승인하는지 묻습니다. IXC의 출시 전 QA 검수 가운데 릴리스 준비도 리뷰는 신민규 CTO가 검증 결과와 제외 범위, 전제와 잔여 리스크를 검토한 뒤 서명한 메모를 전달합니다. 아웃소싱 계약의 검토와 보고 역할은 해당 범위에 맞춰 정합니다. 내부 QA와 외부 QA 모두 합의한 기준과 추적 가능한 결과를 제공해야 합니다. 외부 검증은 개발과 분리된 관점을 더하며 같은 양식으로 정리한 근거가 출시 회의의 판단을 돕습니다. 판정 문서의 수명도 물어봅니다. 감사나 사고 조사에서 다시 꺼낼 때 요구사항과 테스트, 결함과 조치, 승인 기록이 한 줄로 이어지는 형태여야 근거를 다시 모으지 않습니다. 연기를 권할 때 무엇이 갖춰지면 다시 판단하는지까지 적는지도 같은 축에서 묻습니다.

범위가 열린 계약은 값이 늘어나는 쪽으로만 움직입니다. 착수 전에 문서로 못 박을 항목은 정해져 있습니다. 대상 빌드 개수, 제품 영역 개수, 핵심 흐름 개수, 합의된 시나리오 개수, 재테스트 횟수입니다. 여기에 제외 범위를 같은 문서에 적습니다. 보안 인증 적합성이나 코드 품질 평가처럼 검수의 이름으로 기대되지만 실제로는 다른 일인 항목을 앞에서 잘라 두어야 종료 시점에 다툼이 생기지 않습니다. 범위를 넓히거나 좁히는 절차도 문서에 넣습니다. 누가 요청하고 누가 승인하며 값이 어떻게 바뀌는지가 없으면 변경 요청이 구두로 쌓이다가 마지막에 한꺼번에 청구됩니다. 제안서에 기간과 인원만 적혀 있고 이 다섯 개 숫자가 비어 있다면 그 값은 아직 예상치에 그칩니다. 후보별 숫자와 산출물을 맞추면 견적 차이 가운데 범위 차이가 차지하는 몫을 확인할 수 있습니다. 기간형 계약이라고 범위 고정이 면제되지는 않습니다. 상주 인력을 몇 달 두는 계약에서도 그 기간에 무엇을 어느 깊이로 볼지가 착수 주에 문서로 정해져야 합니다. 그러지 않으면 요청이 들어오는 대로 일이 붙어 계약 후반에 가장 중요한 회귀 구간이 밀립니다. 범위를 좁히는 결정도 같은 무게로 적습니다. 이번 릴리스에서 보지 않기로 한 영역은 다음 릴리스의 첫 후보가 되므로 제외 목록은 버리지 않고 다음 계획의 입력으로 남깁니다.

외주 기간이 끝나면 사람은 나갑니다. 남는 것을 계약서에 적어 두지 않으면 다음 릴리스에서 같은 값을 다시 씁니다. 남길 목록은 넷입니다. 실행한 테스트 케이스와 시나리오 문서, 자동화 스크립트와 실행 환경 설정, 심각도와 재현 조건까지 붙은 결함 대장, 판정 잣대와 출시 게이트 정의입니다. 형식도 함께 정합니다. 문서 파일과 원본 데이터를 같이 받는지, 자동화 자산이 저장소 접근 권한과 함께 넘어오는지가 실제 재사용 여부를 가릅니다. 공급사 전용 도구 안에만 자산이 쌓이는 구조라면 계약이 끝나는 순간 읽을 수 없는 자산이 됩니다. 인계 뒤 질의 대응 기간도 함께 적습니다. IXC는 테스트 자산과 운영 방식을 내부 팀에 넘긴 뒤 4주간 질의 대응을 이어갑니다. 이 기간이 없으면 인계 문서는 받았는데 첫 실패 앞에서 물어볼 곳이 사라집니다. 인계는 종료 주에 몰아서 하는 행사가 아닙니다. 판정 잣대와 보고 양식을 착수 단계에서 내부 팀과 함께 정해 두면 계약 기간 내내 같은 문서가 쌓이고 종료 시점에는 넘길 것이 이미 만들어져 있습니다. 마지막에 인계 문서를 새로 쓰는 공급사는 그 문서를 기억에 기대어 씁니다. 내부에 QA 조직이 이미 있다면 인계보다 분담이 문제입니다. 어느 영역을 내부가 계속 맡고 어느 영역을 넘기는지, 결함 심각도 잣대와 보고 양식을 어느 쪽 것으로 통일하는지를 착수 전에 정합니다.

자동화는 구축 수량과 함께 반복 실행과 유지에 드는 일을 봅니다. 만든 건수만으로 운영 가치를 판단하기는 어렵습니다. 셋을 물어야 합니다. 실패한 실행을 제품 결함과 환경 문제, 스크립트 노후로 나누는 절차가 있는가. 결과가 흔들리는 케이스를 격리해 따로 고치는 담당과 주기가 정해져 있는가. 자동화하지 않기로 한 영역이 이유와 함께 문서에 남는가. 셋이 없으면 아무도 믿지 않는 빨간 실패 목록이 쌓이고 팀은 결국 결과를 보지 않게 됩니다. 도구는 제품 구성에 따라 갈립니다. 웹은 Playwright와 Selenium, 모바일은 Appium, 부하 생성은 JMeter처럼 계층별로 통용되는 선택지가 있고 IXC는 대상 규격에 맞춰 고릅니다. 공급사가 다루는 도구 하나에 제품을 맞추라는 제안이 온다면 순서가 뒤집힌 것입니다. 화면 변경이 잦은 영역을 API 수준으로 내리거나 수동 검증으로 남기는 판단을 함께 내놓는지도 봅니다. 실행 결과가 어디에 쌓이는지도 같은 물음입니다. 파이프라인에 붙어 배포마다 자동으로 돌고 화면 캡처와 로그가 한곳에 묶이면 배포 담당이 별도 요청 없이 통과 여부를 읽습니다. 수동으로 실행하는 자동화도 반복 작업을 줄일 수 있습니다. 필요한 주기로 빠짐없이 실행되는지, 파이프라인이나 예약 실행이 필요한지를 함께 확인합니다. 테스트 데이터를 어떻게 다루는지도 확인합니다. 계정과 상품, 주문 같은 사전 조건을 실행 시점에 만들고 끝나면 되돌리는 장치가 없으면 앞선 실행이 남긴 데이터 때문에 결과가 흔들리고 그 흔들림은 곧 실패 목록을 무시하는 습관이 됩니다.

인원과 기간은 프로젝트마다 다릅니다. 그 값을 무엇이 정했는지가 제안서에 적혀 있어야 합니다. 상주 여부부터 봅니다. 사내망에서만 열리는 테스트 환경, 반출이 금지된 데이터, 보관 장소가 정해진 실기기가 있으면 상주가 필요합니다. 그렇지 않다면 원격이 기본이고 IXC도 원격을 기본으로 두되 필요하면 상주도 맡습니다. 상주를 택하면 계정 발급 범위와 반출 금지 항목을 먼저 정한 뒤 인원과 기간을 정하는 순서가 맞습니다. 규모를 움직이는 변수는 넷입니다. 검증 대상 플랫폼과 단말 조합의 수, 배포와 회귀의 주기, 출시일까지 남은 기간, 자동화 자산의 유무입니다. 조합이 늘면 실행 횟수가 곱으로 늘고 회귀 주기가 짧으면 같은 실행이 매달 반복됩니다. 제안서에 인원과 기간만 있고 이 넷이 없으면 되물어야 합니다. 값을 정한 근거를 설명하지 못하는 공급사는 범위가 바뀔 때도 설명하지 못합니다. 원격을 택했다면 보고 주기와 창구를 계약에 넣습니다. 주 1회 같은 양식으로 결함과 잔여 리스크가 올라오고 긴급 건의 연락 경로가 정해져 있으면 물리적 거리는 문제가 되지 않습니다. 시차가 있는 팀과 나눠 일하는 경우에는 책임 경계를 문서로 갈라 두어야 같은 결함을 양쪽이 동시에 잡거나 아무도 잡지 않는 일이 사라집니다. 마지막으로 규모가 변하는 구간을 미리 표시합니다. 대규모 회귀가 도는 주와 안정화 구간은 필요한 인원이 다르므로 리드 한 명이 계약 기간 내내 고정되고 실행 인력이 구간별로 붙는 형태를 쓰면 인원이 늘거나 줄어도 판정 잣대가 흔들리지 않습니다.