개념
비용이 줄고 정보가 끊긴다
테스트를 분산·외주로 보내는 이유는 대개 셋이다 — 비용, 인력 확보, 커버리지 (시간대·기기·언어). 그리고 그 대가로 잃는 것은 하나로 요약된다. 옆자리에서 자연히 전달되던 정보가 끊긴다.
같은 공간에서는 "이 기능 지금 좀 불안해요" 같은 말이 공짜로 전달된다. 분산되면 그 정보는 문서로 적거나, 회의에 올리거나, 아예 전달되지 않는다. 그리고 대부분 세 번째가 된다.
그래서 분산·외주 관리의 본질은 사람 관리가 아니라 공짜였던 정보 전달을 설계로 대체하는 일 이다.
세 가지 간격
| 간격 | 무엇이 끊기는가 | 대표 증상 |
|---|---|---|
| 시간 간격 | 즉시 질문·즉시 확인 | 질문 하나에 하루가 간다 |
| 맥락 간격 | 제품·사용자·우선순위의 암묵적 이해 | 결함 보고가 핵심을 비껴간다 |
| 책임 간격 | 누가 어디까지 판단하는가 | 모두가 상대의 결정을 기다린다 |
세 간격은 다른 장치로 메워야 한다. 하나의 해법으로 묶으려 하면 전부 실패한다.
시간 간격 — 왕복 횟수를 줄인다
시차가 있으면 한 번의 왕복이 하루 다. 그래서 목표는 "빨리 답하기" 가 아니라 왕복이 필요한 상황 자체를 줄이기 다.
| 장치 | 효과 |
|---|---|
| 결함 보고 양식 강제 | 되묻는 왕복을 없앤다 |
| 재현 환경·데이터 사전 제공 | "재현 안 됩니다" 왕복을 없앤다 |
| 판단 기준 사전 문서화 | "이게 결함인가요" 왕복을 없앤다 |
| 겹치는 근무 시간 지정 | 꼭 필요한 대화를 하나로 모은다 |
| 비동기 기본 원칙 | 답을 기다리며 멈추지 않게 한다 |
세 번째 장치가 가장 효과가 크다. "이게 결함인지 아닌지" 를 묻는 왕복이 분산 팀에서 가장 많고, 그것은 판정 기준이 문서에 없기 때문 에 생긴다. 모듈 31 레슨 3 의 판정 기준 선언이 여기서 관리 장치로 쓰인다.
겹치는 근무 시간 은 정하지 않으면 양쪽이 서로를 기다린다. 하루 1~2시간이라도 명시해 두고, 그 시간에 결정이 필요한 것만 다룬다. 공유 사항은 비동기로 보낸다.
맥락 간격 — 결함 보고의 품질로 드러난다
맥락이 없으면 결함 보고가 증상만 적고 영향을 적지 못한다. "버튼이 안 눌립니다" 와 "결제 완료 직전 단계에서 버튼이 안 눌려 주문이 유실됩니다" 의 차이가 맥락이다. 심각도 판정이 어긋나는 것도 같은 원인이다.
메우는 장치는 넷이다.
- 제품 맥락 문서 — 사용자가 누구이고 무엇을 하러 오는지, 어느 흐름이 돈·안전·신뢰에 걸리는지. 기능 명세와 별도로 "왜 중요한가" 를 적은 문서
- 심각도 판정 예시집 — 추상적 기준 대신 실제 사례 20~30건 과 그 판정. 기준 문장보다 예시가 맥락을 전달한다
- 왕복 피드백 — 보고된 결함의 심각도를 조정했을 때 왜 조정했는지 돌려준다. 이것이 가장 빠른 맥락 학습 경로다
- 순환·교차 방문 — 가능하면 초기에 사람을 섞는다. 비용이 들지만 맥락 전달 효율이 다른 어떤 문서보다 높다
세 번째를 생략하는 조직이 많다. 심각도를 조용히 고치면 상대는 같은 판정을 계속 반복한다. 조정 사유를 돌려주면 몇 주 만에 판정이 맞아 간다.
책임 간격 — 결정 권한을 명시한다
분산 환경에서 가장 비싼 낭비는 서로 상대의 결정을 기다리는 시간 이다. 이것은 신뢰 문제가 아니라 권한이 적혀 있지 않은 문제 다.
결정 권한표를 만든다. 축은 이렇다.
| 결정 | 누가 정하는가 | 누구에게 알리는가 |
|---|---|---|
| 결함 심각도 초기 판정 | 수행 팀 | — |
| 심각도 최종 확정 | 발주 측 | 수행 팀 |
| 시험 범위 변경 | 발주 측 | 수행 팀 |
| 시험 순서·일정 내 배치 | 수행 팀 | 발주 측 |
| 환경 문제로 중단 | 수행 팀(기준 내) | 즉시 발주 측 |
| 결함 재현 불가 종결 | 수행 팀(절차 따라) | 발주 측 |
| 통과 기준 예외 적용 | 발주 측 | — |
"수행 팀이 스스로 정할 수 있는 것" 을 넉넉히 두는 것 이 효율의 핵심이다. 모든 결정을 발주 측이 하면 시차만큼 느려진다. 대신 기준을 문서로 주고 사후 보고 를 받는다.
계약에 들어가야 하는 것
외주 계약에서 분쟁이 생기는 지점은 거의 정해져 있다. 계약 단계에 QA·테스트 매니저가 참여해 넣어야 하는 항목이다. 법률 검토는 법무가 하고, 여기서는 품질 쪽 조항만 본다.
1) 범위의 경계 — 무엇을 하고 무엇을 하지 않는가. 특히 "하지 않는 것" 을 적는다. 시험 설계는 누가 하는가, 자동화 코드의 유지는 포함인가, 결함 재현 지원은 어디까지인가.
2) 산출물의 정의와 양식 — 테스트 케이스·실행 기록·결함 보고·보고서의 양식과 최소 기재 항목 을 계약에 붙인다. 양식이 없으면 사업 중간에 협상이 된다.
3) 인수 기준 — 산출물을 받아들이는 기준. 아래에서 따로 다룬다.
4) 환경과 데이터 제공 책임 — 누가 환경을 주고, 언제까지 주고, 장애 시 책임은 누구인가. 환경 지연으로 인한 일정 영향의 처리 를 미리 정하지 않으면 분쟁이 된다.
5) 인력 요건과 교체 통제 — 요구 숙련도, 핵심 인력 지정, 교체 시 사전 통보와 인수인계 기간. 외주에서 가장 흔한 품질 저하 원인이 조용한 인력 교체다.
6) 보안과 데이터 취급 — 접근 권한, 자료 반출, 운영 데이터 사용 가능 여부, 작업 환경 요건. 모듈 63 레슨 6 의 통제 환경 원칙이 여기 적용된다.
7) 지식 이전과 종료 — 계약 종료 시 산출물·계정·자동화 코드·노하우가 어떻게 넘어오는가. 시작할 때 끝나는 조건을 적는다.
8) 변경 처리 — 범위·일정·인력 변경의 절차와 비용 산정 방식.
인수 기준 — 산출물을 "받아들이는" 조건
가장 자주 비어 있는 조항이고, 비어 있으면 보고서를 받고 나서 다투게 된다.
인수 기준은 셀 수 있거나 확인할 수 있는 형태 로 쓴다.
| 대상 | 좋은 기준 | 나쁜 기준 |
|---|---|---|
| 테스트 케이스 | 요구사항 추적이 100% 걸려 있고, 각 케이스에 사전 조건·절차·기대 결과가 있다 | "충분한 케이스" |
| 실행 기록 | 계획 케이스의 실행 상태가 모두 기록되고, 미실행에는 사유가 있다 | "성실히 수행" |
| 결함 보고 | 양식 필수 항목이 모두 채워져 있고, 재현 절차로 재현된다 | "명확한 결함 보고" |
| 보고서 | 범위·환경·판정 기준·결과·미실행·잔여 위험이 모두 있다 | "결과 보고서 제출" |
"재현 절차로 재현된다" 가 실무에서 가장 강한 기준이다. 재현되지 않는 결함 보고는 받아들이지 않는다는 조건이 있으면 보고 품질이 즉시 올라간다. 단, 간헐 결함을 보고하지 못하게 만들면 안 되므로 간헐 결함의 보고 경로를 따로 열어 둔다.
품질 지표를 걸 때의 함정
계약에 지표를 걸면 그 지표가 조작된다. 이것은 상대의 성실성 문제가 아니라 구조의 문제다. 모듈 48 레슨 5 의 지표 오염과 같다.
| 걸면 안 되는 지표 | 어떻게 왜곡되는가 |
|---|---|
| 결함 발견 건수 | 사소한 결함을 쪼개 올린다 |
| 케이스 작성 수 | 잘게 쪼갠 케이스가 늘어난다 |
| 실행 건수 | 빠른 케이스만 실행한다 |
| 자동화 커버리지 % | 단언 없는 테스트가 늘어난다 |
대신 쓸 수 있는 것은 반려율·재현율·양식 충족률·결함 유출 같은 품질 쪽 지표 다. 그리고 지표 하나만 걸지 않고 짝 으로 건다 — 예컨대 결함 건수가 아니라 "유효 결함 비율(반려되지 않은 비율)" 과 "출시 후 유출" 을 함께 본다.
가장 중요한 원칙 — 지표를 벌칙이 아니라 대화의 근거 로 쓴다. 벌칙에 묶이면 숨기게 되고, 숨기면 지표가 쓸모없어진다.
전환 기간을 일정에 넣는다
분산·외주 체제가 처음부터 제 속도를 내지 않는다. 맥락이 쌓이는 데 시간이 걸리고, 그 기간에 발주 측의 부담이 오히려 늘어난다(교육, 리뷰, 되묻기).
일정과 비용 산정에서 이 구간을 빼놓으면 두 가지가 생긴다 — 초기 산출물 품질이 낮게 나와 신뢰가 깨지고, 발주 측 인력이 예상보다 묶여 다른 일이 밀린다.
전환 기간을 명시하고, 그 기간의 기대 수준을 낮게 적는다. 그리고 전환 종료의 판정 기준을 둔다(반려율이 N% 이하로 안정, 양식 충족률 N% 이상 등). 모듈 44 레슨 1 의 자원 산정에 이 구간을 포함한다.
실무에서 왜 필요한가
국내 QA 조직에서 외주·분산은 예외가 아니라 보편이다. SI 사업의 시험 인력, 해외 개발 조직과의 협업, 기기·언어 커버리지를 위한 외부 팀. 테스트 매니저가 이것을 설계할 수 없으면 비용은 줄었는데 품질이 떨어지고 관리 부담이 늘어난 결과가 나온다.
그리고 실패의 원인은 거의 항상 문서로 적지 않은 것 이다. 판정 기준을 적지 않아 왕복이 늘고, 결정 권한을 적지 않아 서로를 기다리고, 인수 기준을 적지 않아 보고서를 받고 다툰다. 사람의 성실성 문제로 보이는 현상의 대부분이 설계 공백이다.
가장 비싼 실패는 조용한 인력 교체 다. 숙련된 인력이 빠지고 신규가 들어왔는데 통보가 없으면, 몇 주 뒤 산출물 품질이 떨어진 이유를 찾지 못한다. 계약에 사전 통보와 인수인계 조항 한 줄이 이것을 막는다.
채용시장에서의 위치
테스트 매니저·Head of QA 공고의 "벤더 관리", "외주 관리", "글로벌 협업", "SLA 관리" 가 이 영역이다. 국내에서는 SI·금융·제조 쪽에 수요가 많다.
면접에서 가르는 질문은 "외주 산출물 품질이 떨어질 때 어떻게 하십니까" 다. "교육을 강화한다" 는 약한 답이고, 인수 기준·반려 절차·심각도 조정 피드백· 인력 교체 조항 을 들어 답하면 설계할 수 있는 사람으로 읽힌다. ISTQB CTAL-TM 의 분산 팀·외주 관리 범위와 겹친다.