소프트웨어 QA 외주 비용·공수 산정 가이드

QA 견적을 받을 때 가장 먼저 눈에 들어오는 값은 기간과 인원입니다. 그런데 그 둘은 결과입니다. 원인은 범위입니다. 범위는 다섯 개 숫자로 적힙니다. 대상 빌드 개수, 제품 영역 개수, 핵심 흐름 개수, 합의된 시나리오 개수, 재테스트 횟수입니다. 이 다섯이 적힌 견적끼리는 나란히 비교됩니다. 비어 있는 견적은 비교표에 올라가지 못합니다. 실제로 후보 사이의 값 차이 대부분은 실력 차가 아니라 범위 차입니다. 한 곳은 핵심 흐름 세 개에 시나리오 서른 개를 잡았고 다른 곳은 제품 전체를 잡았다면 값이 다른 것이 당연합니다. 그래서 예산을 세우는 순서는 이 다섯 숫자를 우리 쪽에서 먼저 적어 보는 것입니다. 값은 그다음에 받습니다. 숫자가 어렵다면 반대로 물어도 됩니다. 정해 둔 예산 안에서 이 다섯을 각각 몇으로 잡을 수 있는지 되물으면 같은 값에 담기는 내용의 차이가 드러납니다. 제외 범위도 같은 문서에 적습니다. 보안 인증 적합성이나 코드 품질 평가는 검수의 이름으로 기대되지만 실제로는 다른 일입니다. 이런 항목을 앞에서 잘라 두어야 종료 시점의 다툼과 추가 청구가 사라집니다. 범위 변경 절차도 값의 일부입니다. 누가 요청하고 누가 승인하며 값이 어떻게 바뀌는지가 계약서에 없으면 변경 요청이 구두로 쌓이다가 마지막 달에 한꺼번에 청구됩니다. 예산을 안정시키려면 변경 한 건마다 무엇이 얼마나 늘어나는지 한 줄로 적는 규칙부터 세웁니다. 범위를 정하는 잣대는 제품 리스크입니다. 실패했을 때 매출이 끊기거나 데이터가 어긋나는 흐름을 앞에 놓고 그 아래로 내려가며 자릅니다. 예산이 어디서 끊기든 위쪽은 이미 확보된 상태가 됩니다.

같은 하루치 공수라도 유형에 따라 무엇에 쓰이는지가 다릅니다. 기능 검증은 시나리오 개수에 거의 정비례합니다. 케이스를 쓰는 시간과 실행하는 시간이 함께 늘어나므로 개수를 줄이면 값이 그만큼 내려갑니다. 탐색적 테스트는 개수로 사지 않고 시간으로 삽니다. 명세에 없는 조건을 파고드는 일이라 사전에 셀 수 있는 단위가 없고 대신 몇 시간을 어느 영역에 쓸지로 계약합니다. 회귀는 실행 자체는 단순하지만 대상 폭이 넓고 반복이 잦아 누적 공수가 가장 큽니다. 성능과 부하 검증은 성격이 또 다릅니다. 운영 로그에서 시간대별 유입 분포와 기능별 호출 비율을 꺼내 부하 모델로 옮기는 준비 작업이 실행보다 크고 결과를 병목 위치와 개선 순서로 옮기는 분석에도 시간이 붙습니다. 장애 주입과 복구 검증은 별도 환경과 중단 기준 합의가 선행돼야 하므로 준비 항목이 하나 더 얹힙니다. 견적서에 이 유형들이 한 줄로 묶여 있으면 나눠 달라고 요청합니다. 유형별로 갈라 놓아야 예산이 부족할 때 무엇을 덜어낼지 가려집니다. 유형에 따라 준비 기간의 위치도 다릅니다. 기능 검증은 착수와 거의 동시에 실행이 시작됩니다. 성능과 장애 검증은 환경과 데이터가 갖춰지기 전에는 실행이 시작되지 않습니다. 이 준비 구간을 일정에서 빼놓고 값을 세우면 실행 기간이 뒤로 밀리면서 인력이 대기하는 날이 그대로 비용이 됩니다. 문서가 없는 제품은 유형과 별개로 한 항목이 더 붙습니다. 화면과 코드에서 실제로 구현된 규칙을 뽑아 요구사항을 복원하는 작업입니다. 이 구간을 견적에서 빼면 실행 담당이 무엇을 통과로 볼지 모르는 상태로 시작하게 됩니다.

가장 자주 과소평가되는 변수입니다. 시나리오 서른 개를 확정하고도 브라우저와 운영체제, 단말과 해상도 조합이 넷이면 실행 횟수는 백스무 번입니다. 조합이 여덟이면 이백마흔 번이 됩니다. 시나리오를 줄이는 것보다 조합을 줄이는 쪽이 값을 훨씬 빠르게 내립니다. 조합을 정하는 근거는 실제 사용자 분포입니다. 접속 통계에서 상위 조합을 뽑아 어디까지 자를지 정합니다. 잘라낸 조합은 제외 범위에 이름으로 적습니다. 실기기가 필요한 경우에는 항목이 더 붙습니다. 기기 확보와 보관, 운영체제 버전 관리가 공수로 들어오고 기기가 발주 조직 쪽에 있으면 상주 여부와도 엮입니다. 반대로 클라우드 단말 서비스로 대체할 수 있는 구간이라면 기기 비용이 실행 시간 비용으로 바뀝니다. 여기에 언어와 지역 설정이 더해지면 조합이 다시 곱해지므로, 다국어 서비스라면 검증 대상 지역을 초기에 못 박는 결정이 값을 가장 크게 가릅니다. 조합은 확인 지점을 아래 계층으로 내려도 줄어듭니다. 화면에서만 확인하던 항목 가운데 상당수는 서버 인터페이스 수준에서 같은 결론이 나오고 그 계층은 단말 조합과 무관하게 한 번만 돌면 됩니다. 조합별로 반드시 화면에서 봐야 하는 항목이 무엇인지 가려내면 실행 횟수가 눈에 띄게 줄어듭니다.

한 번 검증하고 끝나는 일과 배포마다 되풀이되는 일은 다른 계약입니다. 출시 전 검수처럼 빌드 하나를 보는 일은 일회성 값으로 끝납니다. 회귀는 배포 주기만큼 곱해져 매달 나가는 비용이 됩니다. 주 1회 배포와 하루 여러 번 배포는 같은 시나리오를 쓰더라도 연간 공수가 크게 갈립니다. 그래서 견적을 읽을 때 총액과 함께 회당 값과 연간 반복 횟수를 나눠 봐야 합니다. 재테스트 조건도 여기에 붙습니다. 합의된 수정분을 한 차례만 다시 보는지, 수정이 나올 때마다 보는지에 따라 실행 횟수가 달라지고 그것이 곧 값입니다. 반복 횟수가 어느 선을 넘으면 자동화 구축비가 회수됩니다. 그 선은 실행 빈도와 화면 변경 주기, 테스트 데이터 준비 난이도, 실패했을 때 원인을 분석하는 시간을 같은 표에 놓고 계산합니다. 실행 빈도만 높고 화면이 자주 바뀌는 영역은 자동화해도 회수되지 않으므로 수동으로 남기는 편이 값이 쌉니다. 회귀 범위를 좁히는 것도 값을 내리는 수단입니다. 수정 한 건이 어떤 기능을 함께 건드리는지 판정해 다시 볼 대상을 골라내면 배포마다 전부 다시 보지 않아도 됩니다. 이 판정이 없는 조직은 안전을 이유로 매번 전체를 돌립니다. 그 선택이 회귀 비용을 가장 크게 키웁니다. 배포 주기가 짧은 조직은 실행 시점도 값에 넣습니다. 야간과 주말에 도는 실행, 긴급 배포에 붙는 즉시 검증은 평시 실행과 다른 조건이므로 대응 시간과 함께 계약에 적어 두어야 나중에 협의로 처리되지 않습니다.

상주는 원격보다 값이 큽니다. 이동과 좌석, 계정 발급과 반출 규정 확인이 실행 외 공수로 붙기 때문입니다. 그래서 상주를 요구하기 전에 이유를 확인합니다. 사내망에서만 열리는 테스트 환경이 이유라면 제한된 계정과 접근 경로로 대체되는지 먼저 봅니다. 반출이 금지된 데이터나 보관 장소가 정해진 실기기가 이유라면 상주가 맞고 이때는 계정 발급 범위와 반출 금지 항목을 먼저 정한 뒤 인원과 기간을 정하는 순서가 값을 안정시킵니다. IXC는 원격을 기본으로 두되 상주도 맡으며 어느 쪽이든 인원과 기간은 앞의 변수들을 보고 정합니다. 자동화는 방향이 둘로 갈립니다. 구축 구간에서는 같은 범위를 수동으로 보는 것보다 값이 큽니다. 스크립트 외에 자동화 전용 식별자 규칙, 화면 단위를 객체로 묶는 계층, 실행 환경과 테스트 데이터 장치까지 함께 만들기 때문입니다. 그다음부터는 반복분이 사라집니다. 유지 공수가 매달 붙는 대신 실행 공수가 빠집니다. 견적서에 자동화가 한 덩어리로 적혀 있으면 구축분과 유지분을 갈라 달라고 요청합니다. 유지분에는 실패 분석이 들어갑니다. 실행이 실패했을 때 제품 결함인지 환경 문제인지 스크립트 노후인지 가르는 시간이 자동화 운영의 실제 공수입니다. 이 절차가 없으면 실패 목록이 쌓이다가 결과를 아무도 읽지 않는 상태가 되어 구축비가 통째로 사라집니다.

같은 범위를 같은 기간에 보더라도 무엇을 남기느냐로 값이 갈립니다. 결과 요약 한 장을 받는 것과 시나리오별 결과에 확인하지 못한 영역과 잔여 리스크를 붙이고 서명한 릴리스 메모까지 받는 것은 다른 일입니다. 결함 대장에 심각도와 재현 조건을 붙이는 작업, 요구사항과 테스트와 결함과 승인 기록을 한 줄로 잇는 추적표, 다음 릴리스에서 다시 쓰는 테스트 케이스와 자동화 자산, 내부 팀이 이어받을 운영 인수서가 각각 공수입니다. 어디까지 필요한지는 이 검증을 한 번만 할지 여러 번 할지에 따라 갈립니다. 한 번이면 판정 문서까지로 충분하고 반복할 것이면 재사용 자산을 남기는 쪽이 두 번째 릴리스부터 값을 낮춥니다. 감사나 사고 조사에 대비해야 하는 조직이라면 추적표가 필수 항목이 됩니다. 견적을 요청할 때 산출물 목록을 먼저 적어 보내면 받은 값들이 왜 다른지를 그 목록 위에서 읽습니다. 인계 항목도 산출물에 넣습니다. 자동화 자산을 저장소 접근 권한과 함께 넘기는지, 인계 뒤 질의 대응 기간이 며칠인지가 적혀 있어야 다음 릴리스의 비용을 미리 셉니다. IXC는 테스트 자산과 운영 방식을 내부 팀에 넘긴 뒤 4주간 질의 대응을 이어가며 이 기간은 산출물과 함께 착수 전에 문서로 정합니다.