페어 테스팅과 몹(앙상블) 테스팅 — 역할 교대로 운영하고, 언제 쓰지 않을지 판단하기

개념

이 기법의 정체는 "비용이 N배인 테스트"다

모듈 5(레슨 13)에서 짝 탐험을 짧게 봤다 — 두 사람이 함께 보면 혼자보다 많이 본다는 이야기였다. 이 레슨은 그 한 문단을 운영 절차 로 펼치되, 출발점을 반대쪽에 둔다.

혼자 탐색 90분        = 1.5 사람-시간
페어 테스팅 90분      = 3.0 사람-시간   (2배)
몹 테스팅 90분 (5인)  = 7.5 사람-시간   (5배)

같은 90분이 회계상으로는 5배다. 판단 기준은 "협업이 좋은가"가 아니라 "이 90분이 혼자 하는 7시간 30분보다 나은 결과를 내는가" 다. 회귀 확인과 케이스 실행에서는 답이 거의 언제나 "아니오"다. 답이 "예"가 되는 조건은 좁고, 그 조건을 아는 것이 이 레슨의 전부 다.

페어와 몹 — 인원이 바뀌면 다른 기법이 된다

3인 이상이 되는 순간 성질이 달라진다. 페어는 깊이 를 위한 도구이고, 몹은 정렬(alignment) 을 위한 도구다.

몹의 산출물 칸이 중요하다. 다섯 명이 90분에 결함 세 건이면 결함 단가로는 최악이다. 하지만 그동안 개발자 셋이 "쿠폰 규칙이 이렇게 동작하는 줄 몰랐다"를 동시에 알게 됐다면 그다음 스프린트 내내 생기지 않을 결함 이 값어치다. 몹은 결함 발견 도구가 아니라 지식 전파 도구이고, 결함 수로 평가하면 언제나 실패로 보인다.

용어 — 2020년 전후로 "몹(mob)"을 앙상블(ensemble) 로 바꿔 부르는 흐름이 생겼다. Maaret Pyhäjärvi는 가이드북 제목을 『Ensemble Programming Guidebook』으로 바꿨고, 테스트에 적용한 형태를 앙상블 테스팅 으로 부른다. 국내에서는 아직 "몹"이 통용되므로 이 레슨은 두 용어를 함께 쓴다.

역할 — 손과 머리를 분리한다

Woody Zuill 팀이 Hunter Industries에서 정리한 구조를 쓴다. 뿌리는 Llewellyn Falco의 강한 스타일 페어링(strong-style pairing) 이다.

강한 스타일의 규칙은 한 문장이다. "아이디어가 내 머리에서 컴퓨터로 가려면 반드시 다른 사람의 손을 거쳐야 한다." 이 규칙이 하는 일은 하나다 — 가장 잘 아는 사람이 키보드를 잡지 못하게 막는 것 . 제품을 제일 잘 아는 QA가 드라이버를 잡으면 나머지는 구경꾼이 되고 세션은 시연으로 변한다. 반대로 그 영역을 가장 모르는 사람을 드라이버로 세우면 그 사람이 헤매는 지점이 그대로 사용성 결함 후보 가 된다.

교대 주기는 짧을수록 참여가 유지되지만, 짧을수록 전환 비용이 든다. 아래 값은 출발점이고, 첫 세션 회고에서 조정한다.

Hunter Industries 팀은 15분 교대를 공개했고, 이후 커뮤니티에서는 4~10분 관행이 퍼졌다. 타이머가 돌아간다는 사실 자체 가 주기 값보다 중요하다.

90분 몹 테스팅 세션 대본

시간이 배분되지 않은 몹은 90분짜리 잡담이 된다. 5인 기준 대본이다.

00:00 ~ 00:05  시작 (5분)
               · 차터 한 문장을 소리 내어 읽는다
                 "결제 수단 3종 × 쿠폰/포인트 조합에서 금액 계산이 깨지는 지점을 찾는다"
               · 범위 밖 선언: "이번 세션에서 안 보는 것 — 성능, 관리자 화면"
               · 교대 순서와 주기 공지, 타이머 시작
               · 규칙 3줄 낭독: 드라이버는 손, 내비게이터는 입, 결함은 멈추지 말고 적는다
 
00:05 ~ 00:20  워밍업 (15분, 2교대)
               · 가장 모르는 사람이 첫 드라이버
               · 정상 경로 1회 — 모두가 같은 화면을 보게 만드는 것이 목적
 
00:20 ~ 01:05  본 세션 (45분, 6교대)
               · 내비게이터가 아이디어를 하나씩 소진
               · 결함 후보가 나오면 서기가 적고 즉시 다시 진행 (티켓 작성은 세션 후에)
               · 15분마다 "지금 어디까지 왔나" 한 줄 확인
 
01:05 ~ 01:15  정리 (10분)
               · 발견 목록을 셋으로 분류
                 [바로 등록] [확인 필요] [제품이 아니라 우리가 몰랐던 것]
               · 티켓 작성 담당자 지정
 
01:15 ~ 01:30  회고 (15분)
               1. 오늘 새로 알게 된 것 중 팀 전체가 알아야 할 것은?
               2. 교대 주기는 적절했나?
               3. 다음에 이 조합(사람·주제)으로 또 할 가치가 있나?  ← "아니오"면 안 한다

마지막 질문이 대본의 핵심이다. 세션마다 "다음에도 할 것인가"를 묻지 않으면 몹은 관성으로 이어지다 어느 날 모두가 싫어하는 정례 회의가 된다.

페어는 같은 구조를 45분으로 줄인다 — 시작 3분(차터·교대 주기), 진행 35분(10분 교대), 마무리 7분(발견 분류 + "또 할 가치가 있나"). 마무리를 생략하면 페어의 산출물은 대화 속에서 증발한다.

조합별로 무엇이 잡히는가

같은 기법이어도 누구와 짝을 짓느냐 에 따라 나오는 결함의 종류가 다르다. 페어를 설계할 때 가장 실용적인 지식이다.

한 줄로 쓰면 이렇다. QA×개발은 "어떻게 만들어졌는가"를 열고, QA×QA는 "어떻게 보는가"를 옮기고, QA×기획은 "무엇이 정해지지 않았는가"를 드러낸다.

실패 모드 칸은 셋 다 같은 함정을 가리킨다 — 세션이 다른 활동으로 변질되는 것 . 그래서 시작 5분에 "이번 세션에서 안 하는 것"을 선언한다. 수정도, 사양 변경도, 티켓 작성도 세션 중에는 하지 않는다. 몹에서 한 명이 코드를 고치기 시작하면 나머지 네 명은 그 순간부터 대기 인력이다.

언제 쓰지 말아야 하는가

먼저 쓸 조건 이다. 네 개 중 둘 이상이 해당할 때만 비용이 정당화된다.

1. 아무도 전체를 모른다 — 여러 팀이 나눠 만든 기능, 처음 통합되는 흐름
2. 판정 기준이 사람마다 다르다 — "이게 결함인가"를 합의해야 하는 영역
3. 지식이 한 사람에게 몰려 있다 — 버스 팩터가 1인 영역
4. 위험이 크고 되돌릴 수 없다 — 결제·정산·개인정보처럼 운영 사고 비용이 압도적인 곳

이제 쓰지 말아야 할 조건 이다. 하나라도 해당하면 그 세션은 낭비다.

마지막 두 줄이 가장 자주 어겨진다. 정례화와 마감 직전 투입 — 이 둘이 페어·몹을 "해봤는데 별로였다"로 만드는 주범이다. 원인은 기법이 아니라 배치다.

원격에서 운영하기

원격은 같은 기법을 더 비싸게 만든다. 마찰이 셋 추가된다.

• 입력권 이전 — 제어권 넘기기는 승인 대기·해상도 차이·단축키 충돌로 매번 20~60초를 먹는다. 교대 8회면 그것만 5분이다. 대안은 드라이버가 매번 자기 화면을 공유 하는 방식이다. 이전 비용이 거의 없는 대신 테스트 계정·데이터가 인원수만큼 준비돼 있어야 한다. 공유 계정으로 동시 로그인하면 세션 충돌이 결함처럼 보인다.
• 참여 신호의 소멸 — 대면이면 몸이 앞으로 기우는 것이 보이지만 원격은 안 보인다. 그래서 말 없는 사람을 내비게이터 순번으로 명시 호명 한다. "다음 내비게이터는 OO님"이 원격 몹의 기본 문장이다.
• 피로 — 화면 공유 응시는 대면보다 빨리 지친다. 원격은 60분 상한, 45분 지점에 10분 휴식을 고정한다. 90분이 필요하면 45분씩 두 세션으로 나누고 사이에 각자 자리를 뜬다.

추가로 타이머를 모두가 보는 화면 에 띄우고, 결함 후보를 적는 공동 문서 링크 를 시작 전에 올리고, 드라이버와 내비게이터는 카메라를 켠다 — 조작이 막혔는지 생각 중인지가 구분돼야 한다.

심리적 안전 줄은 부연이 필요하다. 페어·몹은 모르는 상태를 공개하는 기법 이고, 헤매는 자리가 곧 결함이 나오는 자리다. 그 노출이 평가로 돌아오는 팀에서는 같은 구조가 독이 된다 — 아는 것만 조작하고, 세션은 무사히 끝나고, 아무것도 발견되지 않는다. 그래서 사회자는 "여기서 막히는 건 그 사람이 아니라 제품 때문이다" 를 소리 내어 말하고, 노트에는 누가 못 했는지가 아니라 무엇이 막혔는지만 남긴다.

실무에서 왜 필요한가

QA 한 명이 여러 스쿼드를 지원하는 조직에서 병목은 테스트 실행량이 아니라 지식의 위치 다. 제품 전체를 아는 사람이 QA 한 명뿐이면 그 사람이 휴가를 가는 주에 팀의 판단력이 사라진다. 자동화는 실행을 옮겨 주지만 판단을 옮기지는 못한다. 판단을 옮기는 수단은 사실상 둘뿐이다 — 문서와 함께 보는 시간 . 그리고 "이 정도 깜빡임은 결함이 아니고 저 정도는 결함이다" 같은 판정 기준은 문서로 잘 써지지 않는다.

두 번째 값어치는 논쟁의 종료 다. 사양 해석이 갈려 메신저에서 사흘째 오가는 건은 세 사람이 30분 같은 화면을 보면 대개 끝난다. 글로 주고받는 동안 각자 머릿속의 화면이 달라서 안 끝나는 것이다.

채용시장에서의 위치

경력 QA 면접의 "팀에 품질 문화를 어떻게 정착시켰나"에는 대개 추상적인 답이 돌아온다. 페어·몹 사례는 여기에 절차가 있는 답 을 준다. "결제 영역 버스 팩터가 1이어서 격주 90분 몹 세션을 넉 달 돌렸고, 그 뒤 개발자 두 명이 결제 결함을 직접 재현해 오기 시작했다"는 검증 가능한 형태다. "도입했다가 두 달 만에 접었고 이유는 정례화였다"도 좋은 답이다 — 기법을 평가할 줄 안다는 뜻이다.

실습 과제

과제 1 — 조합 설계와 비용 계산 (15분)

최근 3개월 안에 판단이 갈렸던 사안 세 건을 적는다(사양 해석 충돌, 결함/스펙 논쟁, 아무도 확신 못 한 동작). 각 사안에 대해 아래를 채운다.

[사안]         쿠폰+포인트 동시 사용 시 부가세 계산 기준
[적합 조합]    QA × 기획 (사양 공백이 원인)
[인원·시간]    2인 × 45분 = 1.5 사람-시간
[대안 비용]    메신저 논쟁 3일 × 관련자 4명 (추정 4~6 사람-시간)
[쓸 조건 해당] 2번(판정 기준 불일치), 4번(정산 영역)  → 2개 해당, 진행

세 건 중 "쓰지 말아야 할 조건"에 걸리는 것 을 찾아 이유를 적는다. 세 건 모두 적합하다고 나왔다면 기준을 너그럽게 적용한 것이니 다시 본다.

과제 2 — 90분 세션 대본 작성 (20분)

과제 1에서 고른 사안 하나로 실제 세션 대본을 쓴다. 본문 대본을 베끼지 말고 자기 팀 조건 으로 바꾼다.

• 차터 한 문장, 범위 밖 선언 두 줄, 세션 중 하지 않을 것 세 가지
• 참가자와 교대 순서 — 첫 드라이버는 그 영역을 가장 모르는 사람 으로 지정하고 이유를 한 줄
• 시간 배분 (시작 / 워밍업 / 본 세션 / 정리 / 회고)
• 원격이라면 입력권 방식(제어권 이전 vs 각자 공유)과 그 선택의 이유

과제 3 — 중단 판정 기준 만들기 (10분)

도입 시점에 언제 그만둘지 를 먼저 정한다. 아래 형식으로 중단 신호 세 개를 쓴다. 중단선을 숫자로 쓰지 않으면 중단은 일어나지 않는다는 것이 이 과제의 요지다.

[신호]     세션 후반에 노트북을 따로 여는 사람이 2명 이상
[확인]     회고 질문 2번(교대 주기 적절성) 답변 + 사회자 관찰
[조치]     교대 주기 단축 → 반복되면 인원 축소(몹 → 페어)
[중단선]   3회 연속 동일 신호면 이 조합의 세션을 중단한다

자가 체크리스트

• 페어와 몹의 목적 차이(깊이 대 정렬)를 설명하고 산출물이 어떻게 다른지 말할 수 있다
• 드라이버·내비게이터·관찰자의 역할과 강한 스타일 페어링의 규칙을 설명할 수 있고, 가장 잘 아는 사람이 드라이버를 잡으면 안 되는 이유를 말할 수 있다
• 인원·숙련도·원격 여부에 따라 교대 주기를 정하고 근거를 댈 수 있다
• 시작 5분부터 회고까지 시간이 배분된 세션 대본을 쓸 수 있다
• QA×개발, QA×QA, QA×기획 조합이 각각 무엇을 잡아내는지 구분할 수 있다
• 이 기법의 사람-시간 비용을 계산하고 대안과 비교해 투입 여부를 판정할 수 있다
• 쓰지 말아야 할 조건을 다섯 가지 이상 들고, 각각의 대안을 말할 수 있다
• 원격 세션의 입력권 방식·피로 관리·참여 신호 문제를 다룰 수 있다
• 세션을 중단할 신호와 중단선을 미리 정의할 수 있다

흔한 실수

• 정례로 박아 둔다. "격주 수요일 오후 2시 몹"은 두 달이면 목적 없는 회의가 된다. 차터가 있을 때 소집하고, 없으면 안 한다.
• 가장 잘 아는 사람이 키보드를 잡는다. 세션이 시연으로 변하고 나머지는 구경꾼이 된다. 손과 머리를 분리하는 것이 이 기법의 유일한 장치다.
• 타이머 없이 "적당히" 교대한다. 30분쯤 지나면 처음 잡은 사람이 계속 잡고 있다. 주기보다 타이머의 존재가 중요하다.
• 세션 중에 고치거나 사양을 바꾼다. 한 명이 디버깅에 들어가는 순간 나머지 전원이 대기 인력이 된다. 발견은 적고, 처리는 세션 후에.
• 몹을 결함 수로 평가한다. 결함 단가로 보면 몹은 언제나 최악이다. 몹의 산출물은 팀 공통 이해이고, 그 값은 다음 스프린트에 생기지 않은 결함으로 나타난다.
• 마감 직전에 투입한다. 처리량이 필요한 시점에 처리량을 떨어뜨리는 기법을 쓰는 것이다. 페어·몹은 모호함이 남아 있을 때 쓰는 도구다.
• 회고를 생략한다. "다음에도 이 조합으로 할 가치가 있나"를 묻지 않으면 중단 결정이 영원히 오지 않고, 세션은 관성으로 이어지다 모두가 싫어하는 정례가 된다.

참고 자료

• Mob Programming Basics (mobprogramming.org) — 드라이버·내비게이터 구조와 15분 교대를 공개한 Woody Zuill 팀의 원문
• Mob Programming — A Whole Team Approach (Agile Alliance, Agile2014 경험 보고서) — Hunter Industries 사례의 1차 보고
• Ensemble Programming Guidebook — Maaret Pyhäjärvi — 앙상블(몹) 진행 규칙과 역할 정의. 앙상블 테스팅으로의 확장은 저자 글에서 원문 확인
• Llewellyn Falco, 강한 스타일 페어링(strong-style pairing) — "아이디어가 머리에서 컴퓨터로 가려면 다른 사람의 손을 거쳐야 한다"의 출처. 저자 블로그 원문 확인
• Elisabeth Hendrickson, 『Explore It!』 — 짝 탐험을 다룬 장
• 레슨 s2-m05-l13 — 짝 탐험·탐험 추정·종료 기준 (이 레슨은 그 짝 탐험을 세션 운영 절차로 확장한다)
• 레슨 s2-m05-l02 — 탐색 차터 쓰기 (세션 시작 5분의 재료)
• 레슨 s2-m43-l03 — 피드백과 코칭, 심리적 안전 (페어·몹의 전제 조건)