테스트 조직과 사람: 스킬 매트릭스, 팀 배치, 아웃소싱 판단

개념

프로세스가 좋아도 사람이 없으면 안 돈다

이 모듈에서 도구(레슨 1), 데이터(레슨 2), 환경(레슨 3), 방법론(레슨 4), 프로세스 개선(레슨 6)을 다뤘다. 전부 시스템 에 대한 이야기였다.

그런데 실제 조직에서 테스트가 잘 안 돌아가는 이유는 프로세스 설계보다 사람 쪽에 있는 경우가 많다.

• 자동화를 도입했는데 유지보수할 사람이 한 명뿐 이다
• 그 한 명이 퇴사하면 자동화가 통째로 멈춘다
• 도메인을 아는 사람과 기술을 아는 사람이 서로 다른 팀 에 있다
• 외주 인력이 매번 바뀌어 같은 설명을 반복 한다
• QA가 조직도에서 개발팀 아래 있어 "안 된다"고 말하기 어렵다

이 레슨은 그 영역을 다룬다. 테스트 매니저 자격 체계(ISTQB CTAL-TM)가 4일 과정의 한 축을 통째로 인력 관리 에 쓰는 이유이기도 하다.

시니어 QA나 리드로 갈수록 이 영역의 비중이 커진다. 그리고 리드가 아니어도 알아둘 값이 있다 — 내 팀에 무엇이 없는지 보이면 커리어 방향이 잡힌다.

스킬 매트릭스 — 팀의 역량을 눈에 보이게

가장 먼저 할 일은 지금 팀이 무엇을 할 수 있는지 를 표로 만드는 것이다.

                도메인  탐색적  자동화  API   성능  보안  CI/CD  AI검증
  김OO            3      3      1      2     0     0     1      0
  이OO            1      2      3      3     2     1     3      1
  박OO            3      2      0      1     0     0     0      0
  최OO(신입)      0      1      1      1     0     0     0      1
  ──────────────────────────────────────────────────────────────
  팀 최고치        3      3      3      3     2     1     3      1
  2명 이상 보유    ✓      ✓      ✗      ✓     ✗     ✗     ✗      ✗
 
  (0 = 없음, 1 = 도움받으면, 2 = 혼자 가능, 3 = 남을 가르칠 수 있음)

읽어야 할 줄은 맨 아래 두 줄이다.

• 팀 최고치 — 우리가 할 수 없는 영역이 어디인가. 위 예시에서 보안은 최고가 1이므로 사실상 못 하는 영역이다
• 2명 이상 보유 — 버스 팩터(bus factor). 한 명만 아는 영역은 그 사람이 휴가만 가도 멈춘다

두 번째 줄이 실무에서 더 급하다. 위 예시에서 자동화·성능·CI/CD가 전부 1명 의존이다. 이건 역량 문제가 아니라 리스크 다.

QA 팀에 필요한 역량 축 을 정리하면 대략 이렇다. 조직에 맞게 조정한다.

마지막 줄을 기술 역량과 같은 무게로 두는 것이 중요하다. 결함을 발견하는 능력과 그것을 고쳐지게 만드는 능력은 다른 기술이다. 모듈 6(레슨 2·3)에서 다룬 리포트와 소통이 그 기술이다.

스킬 갭을 메우는 세 가지 경로

빈칸을 발견했다면 채우는 방법은 셋이고, 각각 비용과 시간이 다르다.

보안 침투 테스트가 외부 조달의 전형 이다. 1년에 한두 번 필요하고, 전문성이 높고, 내부에 두면 놀린다. 반면 회귀 자동화는 상시 필요하므로 외부에 맡기면 지식이 조직에 남지 않는다.

육성 계획을 세울 때 요령이 하나 있다 — 한 사람에게 한 축씩 맡긴다. "팀 전체가 자동화를 배우자"는 대개 실패하고, "김OO이 이번 분기에 API 자동화를 2까지 올린다"는 성공 확률이 높다. 그리고 그 사람이 팀에 전파하는 구조를 만든다(스터디, 페어링, 문서).

테스팅을 조직 어디에 둘 것인가

QA가 조직도의 어디에 있느냐가 실제 업무에 큰 영향을 준다. 대표적인 형태 셋이다.

임베디드의 약점을 짚어둘 필요가 있다. QA가 개발팀장에게 평가받는 구조에서는 릴리즈를 막는 의견을 내기 어렵다. 이 구조를 쓴다면 평가 라인을 분리하거나, 품질 기준을 팀 밖에서 정하는 장치 가 필요하다. 모듈 4(레슨 5)에서 Go/No-Go 의견을 낼 때 QA의 독립성이 왜 중요한지 다룬 것과 연결된다.

혼합형이 실무에서 가장 자주 채택된다. QA는 각 팀에 들어가 일하되, 전사 QA 길드에서 기준·도구·교육을 공유하는 형태다. 이 구조에서 길드가 하는 일 은 대체로 이렇다.

• 공통 테스트 기준·체크리스트 유지
• 도구 선정과 라이선스 관리(모듈 22 레슨 12)
• 교육과 온보딩
• 팀 간 사례 공유(어느 팀에서 터진 결함이 다른 팀에도 있을 수 있다)
• 품질 지표의 정의 통일(모듈 6 레슨 5)

마지막 항목이 의외로 중요하다. 팀마다 "심각도 1"의 정의가 다르면 전사 지표를 합칠 수 없다.

아웃소싱·인소싱 판단

외주를 쓸지 말지는 감이 아니라 기준으로 판단한다.

"지식의 축적 필요성"이 첫 번째 축인 이유 가 있다. 외주로 회귀 테스트를 3년 돌리면, 그 3년치 제품 지식이 외부에 쌓이고 계약이 끝나면 함께 사라진다. 비용은 아꼈는데 조직의 역량은 그대로 인 상태가 된다.

실무에서 잘 작동하는 절충안은 "설계는 내부, 실행은 분담" 이다. 테스트 케이스 설계와 리스크 판단은 내부가 하고, 반복 실행은 외부와 나눈다. 그러면 지식은 남고 인력 탄력성은 얻는다.

외주를 쓰기로 했다면 QA가 준비할 것들이다.

• 인수인계 자료(제품 개요, 환경 접근, 도메인 용어집)
• 판정 기준 — 무엇을 결함으로 볼지 명시하지 않으면 리포트 품질이 들쭉날쭉해진다(모듈 6 레슨 1의 심각도 기준)
• 리포트 형식과 예시(모듈 6 레슨 2)
• 질문 창구와 응답 SLA
• 인력 교체 시의 온보딩 절차

품질 비용 — 테스팅의 가치를 숫자로 말하기

"테스트에 왜 이만큼 쓰는가"라는 질문을 받으면 답할 언어가 필요하다. 전통적으로 쓰는 틀이 품질 비용(Cost of Quality) 이다.

품질 비용 = 적합 비용(Conformance) + 비적합 비용(Non-conformance)
 
  적합 비용 — 문제를 막기 위해 쓰는 돈
    · 예방 비용:  교육, 프로세스 개선, 코드 리뷰, 설계 리뷰
    · 평가 비용:  테스트 설계·실행, 자동화, 도구, 인력
 
  비적합 비용 — 문제가 생겨서 쓰는 돈
    · 내부 실패:  출시 전 발견된 결함의 수정 비용, 재작업
    · 외부 실패:  출시 후 장애, 고객 이탈, 환불, 평판, 대응 인건비

논증의 핵심은 이것이다 — 적합 비용은 눈에 보이고(예산 항목이 있다), 비적합 비용은 흩어져 있어 안 보인다. 그래서 테스트 예산이 먼저 깎인다.

QA가 할 일은 비적합 비용을 보이게 만드는 것 이다.

이 숫자들이 있으면 대화가 바뀐다. "테스트 인력이 더 필요합니다" 가 아니라 "지난 분기 외부 실패 대응에 약 40인일이 들었고, 그중 절반은 출시 전에 잡을 수 있었던 유형입니다" 가 된다.

주의: 정확한 금액을 계산하려 하면 시작도 못 한다. 추정과 범위 로 충분하다. "정확히 얼마"가 아니라 "이 정도 규모"를 보이는 것이 목적이다.

동기와 이탈 — QA 팀에서 사람이 떠나는 이유

마지막으로 다루기 불편하지만 실재하는 주제다. QA 직군의 이탈 사유는 대체로 몇 가지로 수렴한다.

두 번째가 가장 구조적이다. QA는 잘하면 아무 일도 일어나지 않는 직군이라(모듈 22 레슨 8에서 다룬 그 비대칭), 기여가 자동으로는 보이지 않는다. 이걸 보이게 만드는 장치 — 대시보드, 회고 데이터, 예방한 결함의 기록 — 이 팀 유지에도 기여한다.

사례 — 증원 요청이 세 번 거절된 뒤

QA 3명으로 제품 4개를 보던 팀이다. 증원 요청이 세 번 거절됐고, 매번 같은 말로 요청했다 — "일이 너무 많습니다."

네 번째에 QA 리드가 세 가지를 만들어 갔다.

① 스킬 매트릭스로 본 구조적 위험

② 비적합 비용 집계(지난 6개월)

③ 요청

"증원 1명을 요청합니다. 결제 도메인의 버스 팩터가 1이고, 담당자가 2주 휴가를 가면 그 기간 결제 변경은 검증 없이 나갑니다. 그리고 지난 6개월 비적합 비용이 320시간인데, 이 중 상당 부분이 사전 확인 범위를 줄인 결과입니다."

승인됐다. 달라진 것은 요청 내용이 아니라 말하는 방식이었다.

여기서 남는 교훈이 둘이다. 첫째, "바쁘다" 는 거절하기 쉽고 "위험하다" 는 거절하기 어렵다. 바쁜 것은 조정의 문제로 들리지만, 위험은 누군가 책임을 져야 하는 문제가 된다.

둘째, 증원이 아닌 결론도 가능했다. 실제로 그 논의에서 성능은 계속 외부 조달로 두기로 했고, 모바일은 웹 담당자 한 명을 교차 교육하는 것으로 정했다. 매트릭스가 있으면 증원 말고도 쓸 수 있는 수단이 보인다.

실무에서 왜 필요한가

QA로 5년쯤 일하면 반드시 "팀을 어떻게 굴릴 것인가"라는 질문이 온다. 리드가 되어서일 수도 있고, 리드가 없어서일 수도 있다. 그때 프로세스 지식만으로는 부족하다.

당장 리드가 아니어도 이 레슨의 도구들은 쓸 데가 있다. 스킬 매트릭스를 그려보면 내 팀에 무엇이 없는지, 그리고 내가 어느 축을 맡으면 팀에 기여하면서 나도 성장하는지가 보인다. 커리어 방향을 정하는 데 이만한 도구가 드물다.

품질 비용 언어도 실질적이다. 예산이나 인력 논의에서 QA가 밀리는 이유는 대개 비용은 보이고 이득은 안 보이기 때문 이다. 비적합 비용을 대략이라도 집계해 가져가는 QA는 그 대화에서 다른 위치에 선다.

채용시장에서의 위치

이 레슨의 내용은 QA 리드·매니저 공고의 본문 그 자체다. 그리고 실무자 면접에서도 "앞으로 어떻게 성장하고 싶나" 류의 질문에 쓰인다.

두 번째와 다섯 번째가 리드 역량을 가른다. 둘 다 QA의 가치를 조직의 언어로 번역해 본 경험을 묻는 질문이고, 해 본 사람은 구체적인 숫자를 말한다.

세 번째는 함정이다. "독립 조직이 좋다" 처럼 정답이 있는 것처럼 답하면 맥락을 못 보는 사람으로 읽힌다. 조직 배치는 트레이드오프이고, 양쪽의 대가를 말할 수 있어야 한다.

실무자 단계에서도 쓸 데가 있다. "스킬 매트릭스에서 우리 팀에 비어 있는 축을 보고 그쪽을 맡았습니다" 는 커리어 질문에 대한 좋은 답이다 — 팀에 기여하면서 자기 희소성도 올리는 선택이기 때문이다.

공고 표현으로는 "QA 조직 운영", "테스트 팀 리드", "품질 전략 수립", "협력사 관리", "QA 채용·육성" 이 이 레슨에 걸린다.

실습 과제

과제 1 — 팀 스킬 매트릭스 그리기 (20분)

본문의 역량 축(또는 우리 조직에 맞게 조정한 축)으로 팀 매트릭스를 만든다.

작성 후 답한다.

• 우리가 사실상 못 하는 영역은?
• 한 명에게만 의존 하는 영역은?
• 그중 가장 급한 것 하나는?

과제 2 — 스킬 갭 메우기 계획 (15분)

과제 1에서 고른 가장 급한 항목에 대해 계획을 세운다.

과제 3 — 아웃소싱 판단해보기 (15분)

지금 팀의 업무 중 외주를 검토할 만한 것을 하나 고르고, 본문의 여섯 축으로 판정한다.

"설계는 내부, 실행은 분담" 으로 절충할 수 있는지도 함께 검토한다.

과제 4 — 비적합 비용 추정하기 (20분)

지난 분기의 외부 실패 비용 을 대략 추정한다. 정확할 필요 없다.

그리고 그중 출시 전에 잡을 수 있었던 유형 의 비율을 추정한다.

자가 체크리스트

• 스킬 매트릭스에서 '팀 최고치'와 '2명 이상 보유' 두 줄이 무엇을 말하는지 설명할 수 있다
• 버스 팩터가 역량 문제가 아니라 리스크인 이유를 말할 수 있다
• QA 팀에 필요한 역량 축을 여섯 가지 이상 들 수 있다
• 커뮤니케이션을 기술 역량과 같은 무게로 두어야 하는 이유를 설명할 수 있다
• 스킬 갭을 메우는 세 경로를 비용·시간·적합 상황으로 구분할 수 있다
• 독립·임베디드·혼합 조직 형태의 강약점을 말할 수 있다
• 임베디드 구조에서 QA의 독립성을 지키는 장치를 설명할 수 있다
• QA 길드가 하는 일을 다섯 가지 이상 들 수 있다
• 아웃소싱 판단의 여섯 축을 열거하고, 지식 축적이 왜 첫 축인지 말할 수 있다
• "설계는 내부, 실행은 분담"이라는 절충안의 이점을 설명할 수 있다
• 품질 비용을 적합·비적합으로 나누고 각각의 하위 항목을 들 수 있다
• 테스트 예산이 먼저 깎이는 구조적 이유를 설명할 수 있다
• 비적합 비용을 어디서 뽑을 수 있는지 다섯 가지 이상 말할 수 있다
• QA 이탈 사유와 각각에 대한 구조적 대응을 연결할 수 있다

흔한 실수

• 역량을 개인 문제로 본다. 한 명 의존은 그 사람의 문제가 아니라 팀의 리스크다.
• 스킬 매트릭스를 평가 도구로 쓴다. 사람들이 점수를 부풀리고 표가 무용해진다.
• 팀 전체가 새 기술을 배우게 한다. 한 사람이 한 축을 맡고 전파하는 편이 성공 확률이 높다.
• 임베디드 구조에서 평가 라인을 분리하지 않는다. 릴리즈를 막는 의견을 내기 어려워진다.
• 팀마다 심각도 정의가 다른 채로 둔다. 전사 지표를 합칠 수 없다.
• 상시 업무를 외주에 맡긴다. 제품 지식이 외부에 쌓이고 계약이 끝나면 함께 사라진다.
• 외주에 판정 기준을 주지 않는다. 리포트 품질이 사람마다 들쭉날쭉해진다.
• 품질 비용을 정확히 계산하려 한다. 추정과 범위로 충분하다. 정확성을 추구하다 시작도 못 한다.
• 비적합 비용을 집계하지 않는다. 그러면 예산 논의에서 테스트가 먼저 깎인다.
• QA의 기여를 자동으로 보일 것이라 기대한다. 잘하면 아무 일도 안 일어나는 직군이다. 보이게 만드는 장치가 필요하다.

참고 자료

• ISTQB Advanced Level — Test Management — 테스트 관리자 자격 체계의 인력·조직 영역
• ISTQB Glossary — Cost of Quality — 품질 비용 용어 정의
• Google — Software Engineering at Google, 3장 지식 공유 — 팀에 지식이 남게 하는 방법
• Atlassian — 팀 구조와 QA — 임베디드 QA 논의
• Testing Guild — QA 경력 경로 논의 — 전문가·리드 트랙 사례

이 커리큘럼 안에서

• 모듈 7 레슨 6 — 프로세스 성숙도. 이 레슨은 그 사람 쪽 짝이다
• 모듈 7 레슨 7 — 문서화. 버스 팩터를 낮추는 가장 값싼 수단
• 모듈 7 레슨 8 — 애자일. QA 작업을 백로그에 올려 기여를 보이게
• 모듈 7 레슨 1~3 — 도구·데이터·환경. 역량 축의 실제 내용
• 모듈 4 레슨 4~5 — 종료 조건·Go/No-Go. QA 발언이 공식 절차가 되는 자리
• 모듈 6 레슨 5 — 지표. 비적합 비용을 집계할 재료
• 모듈 10 — 결함 분석. 비적합 비용의 원인을 유형으로 나누는 방법
• 스테이지 4 — 자동화. 반복을 줄여 설계·분석 비중을 늘리는 경로

한 줄 정리 — 프로세스가 좋아도 사람이 없으면 돌지 않는다. 역량은 스킬 매트릭스로 눈에 보이게 만들고, 가장 먼저 볼 것은 평균이 아니라 버스 팩터 1인 영역이다. 조직 배치와 아웃소싱은 정답이 없는 트레이드오프 이고, 판단 기준은 도메인 지식이 축적되어야 하는가다. 그리고 QA의 가치는 비적합 비용으로 말한다 — "바쁘다" 는 거절하기 쉽고 "위험하다" 는 거절하기 어렵다.

모듈 7 마무리 — 이 모듈은 테스트를 개인의 솜씨에서 팀의 체계로 옮기는 방법을 다뤘다. 케이스와 실행 기록(레슨 1), 데이터와 환경(레슨 23), 리듬과 방법론(레슨 45), 성숙도 진단(레슨 6), 결정을 남기는 문서(레슨 7), 애자일 실전(레슨 8), 그리고 사람과 조직(레슨 9). 마지막 레슨이 첫 레슨의 전제이기도 하다 — 사람이 없으면 어떤 도구도 돌지 않는다.