짝 탐험(Pair Exploration), 탐험 추정, 언제 충분한가

개념

이 레슨은 두 가지 질문에 답한다. "둘이 하면 더 나은가" 와 "그래서 언제 끝나는가" 다. 두 번째가 탐색적 테스팅이 조직에서 자리를 못 잡는 가장 큰 이유다.

차를 처음 몰고 낯선 도시를 지날 때를 떠올려 보자. 혼자면 운전과 길 찾기를 동시에 해야 해서 둘 다 어설프다. 옆자리에 지도 보는 사람이 있으면 운전자는 운전에만 집중한다. 짝 탐험이 정확히 이 구조다.

그리고 여행에는 "언제 도착인가" 라는 질문이 따라붙는다. 목적지가 정해진 길이면 내비게이션이 답하지만, "이 도시를 둘러보자" 는 여행은 스스로 끝을 정해야 한다. 탐색적 테스팅이 바로 후자다. 끝을 정하는 방법이 없으면 관리자는 그 활동을 예산에 넣지 못한다.

짝 탐험 (Pair Exploration)

두 사람이 함께 한 세션을 탐험한다. 한 명이 운전자(Driver) — 키보드와 마우스를 잡고 실제로 조작 — 를 맡고, 다른 한 명이 관찰자(Navigator) — 화면을 보며 아이디어를 제안하고 메모를 남긴다 — 를 맡는다.

혼자 할 때보다 좋은 점이 분명하다.

• 두 사람의 시야가 겹치지 않는다 — 한 명이 놓친 걸 다른 한 명이 본다
• 실시간 토론이 새로운 아이디어를 만든다 — "어, 그거 해보니까 이것도 궁금하네" 식의 연쇄가 혼자서는 잘 안 일어난다
• 지식 전수에 좋다 — 신입 테스터와 경력자를 짝지으면 훈련이 되고, QA와 개발자를 짝지으면 서로 다른 관점(사용자 관점 vs 구현 관점)이 섞인다

두 역할을 20~30분마다 바꾼다. 한 사람이 계속 조작하면 다른 사람은 구경꾼이 되고, 구경꾼은 30분쯤 지나면 집중이 끊긴다. 역할을 바꾸면 둘 다 깨어 있다.

그리고 관찰자가 더 어려운 역할이다. 조작하는 사람은 손이 바빠서 생각할 틈이 적고, 관찰자는 한 발 떨어져 있어 큰 그림이 보인다. 경력자를 관찰자에 두는 편이 대개 낫다.

짝을 어떻게 맺나

누구와 짝을 맺느냐에 따라 나오는 것이 다르다.

세 번째가 가장 효율이 높다. 탐험에서 나오는 질문의 상당수가 "이게 결함인가 정책인가" 인데, 기획자가 옆에 있으면 30초면 답이 난다. 혼자 하면 그 질문이 목록에 쌓였다가 며칠 뒤에 답을 받는다.

두 번째도 특히 값지다. 개발자와 함께 보면 "아 그건 캐시 때문이에요" 같은 설명이 즉석에서 나오고, 그 설명 자체가 다음에 어디를 볼지 알려 준다.

짝 탐험을 돌리는 법

규칙을 몇 개 정해 두지 않으면 한 사람의 독무대가 되거나 수다로 끝난다.

• 시작 전에 차터를 소리 내어 읽는다. 둘이 같은 목표를 보고 있는지 맞춘다
• 관찰자는 조작하지 않는다. 답답해도 손을 뻗지 않는다. 말로 전한다
• "그거 해 보세요" 가 아니라 "왜 그렇게 될까요" 로 묻는다. 지시가 아니라 질문이 아이디어를 만든다
• 메모는 관찰자가 맡는다. 조작하는 사람은 적을 틈이 없다
• 끝나면 5분 정리한다. 둘이 본 것을 합쳐야 세션 노트가 완성된다

세 번째가 분위기를 가른다. 지시하면 짝 탐험이 아니라 지도가 되고, 지도가 되면 한 사람의 시야만 쓰게 된다.

언제 짝으로 하고 언제 혼자 하나

사람이 둘 들어가므로 비용이 두 배다. 아무 때나 하지 않는다.

세 번째가 과소평가된다. 레슨 12에서 본 재현 불가 결함은 혼자 30분보다 둘이 15분이 빠른 전형적인 경우다. 내가 무의식적으로 하던 동작을 옆 사람이 발견하기 때문이다.

원격으로 짝 탐험하기

같은 자리에 앉을 수 없을 때가 더 많다. 화면 공유로도 되지만 규칙을 몇 개 더 둬야 한다.

두 번째가 원격의 핵심이다. 옆에 앉아 있으면 손의 움직임이 보이지만 화면만 보면 왜 그걸 눌렀는지가 안 보인다. "지금 만료된 쿠폰을 넣어 볼게요" 처럼 의도를 말하는 습관이 필요하다.

네 번째는 현실적인 타협이다. 원격에서 20분마다 조작권을 넘기면 연결· 환경 준비에 시간이 샌다. 차터 1개씩 번갈아 맡고, 맡지 않은 쪽이 관찰자를 하는 편이 매끄럽다.

탐험 추정 (Exploration Estimation)

"탐색적 테스팅은 몇 시간 걸릴까요?"라는 질문에 스크립트 테스트처럼 "케이스가 50개니까 몇 시간"이라고 답할 수 없다. 대신 차터(레슨 2) 단위로 추정한다.

"이 기능은 리스크 분석(모듈 4) 결과 차터가 4개 필요하다고 판단했고, 차터당 6090분이 걸리니, 총 46시간 정도로 추정한다."

이 방식은 "몇 개의 버그를 찾을지"나 "얼마나 철저할지"를 예측하려 하지 않는다 — 대신 "얼마나 많은 차터를, 얼마나 깊게 진행할 것인가" 를 계획한다. 이게 탐색적 테스팅을 계획 가능한 활동으로 만드는 핵심이다.

발견 개수를 약속하지 않는 것이 핵심이다. "버그 10개를 찾겠다" 는 약속은 지킬 수도 없고, 지키려 들면 사소한 것을 10개 올리는 쪽으로 사람을 밀어낸다. 반면 "차터 4개를 돌리겠다" 는 약속은 노력의 투입을 약속하는 것이어서 지킬 수 있다.

차터 개수를 정하는 순서

추정이 감으로 흐르지 않게 하는 절차가 있다.

5단계의 여유분이 매번 잊힌다. 탐험은 결함을 만나면 멈춰서 재현하고 기록하는 시간이 들고(레슨 11·12), 그 시간이 세션 시간에 포함되지 않는다. 경험적으로 20% 정도를 더해 두면 실제와 맞는다.

차터당 시간은 어떻게 정하나

세 가지 크기로만 나누면 추정이 빨라진다.

120분을 넘기지 않는다. 집중이 떨어져서 뒤쪽 30분은 앞쪽 30분만큼의 가치를 내지 못한다. 더 필요하면 차터를 쪼갠다.

추정을 말로 전달하는 법

같은 추정이라도 표현에 따라 받아들여지는 정도가 다르다.

오른쪽은 줄일 수 있는 단위를 보여 준다. 일정이 빠듯할 때 관리자는 "차터 12개 중 저위험 3개를 다음 주로 미루자" 처럼 구체적으로 협상할 수 있다. 왼쪽은 "3일을 2일로 줄여라" 외에 할 말이 없다.

추정이 틀렸을 때

처음 몇 번은 반드시 틀린다. 중요한 건 틀린 폭을 기록하는 것이다.

• 차터별 계획 시간과 실제 시간을 세션 노트에 함께 남긴다
• 네다섯 번 쌓이면 우리 팀의 평균 차터 시간이 나온다
• 그 숫자가 다음 추정의 근거가 된다

이게 추정을 경험 데이터로 바꾸는 유일한 방법이다. 기록하지 않으면 10년을 해도 감에 머문다.

언제 충분한가

스크립트 테스트는 "모든 케이스를 실행하면 끝"이라는 자연스러운 종료 지점이 있다. 탐색적 테스팅은 그런 지점이 없다 — 그래서 명시적인 중단 기준이 필요하다. 모듈 4(레슨 4)에서 배운 종료 조건 개념을 탐색적 테스팅에 맞게 적용하면 다음과 같다.

• 계획된 차터를 모두 진행했다
• 수확 체감: 최근 몇 세션에서 새로운 발견(새 결함, 새 질문)이 거의 없고 이미 알던 것만 반복해서 확인되고 있다
• 배정된 시간·리스크 예산(모듈 4)을 다 썼다
• 리스크 매트리스(모듈 4)에서 식별된 고위험 영역을 충분히 다뤘다고 판단된다

이 기준 중 하나라도 명확히 충족되면 "충분하다"고 선언할 근거가 있는 것이다. 근거 없이 "이 정도면 될 것 같다"는 감으로 멈추는 것과는 다르다.

네 기준을 실제로 쓰는 모습

말로만 두면 쓰이지 않는다. 측정할 수 있게 바꿔 둔다.

두 번째가 가장 유용하고 가장 안 쓰인다. "새 발견"에 결함만 넣지 말고 새로운 질문·새로운 궁금증도 센다. 궁금한 게 떨어지는 순간이 진짜 수확 체감이다.

수확 체감을 오해하지 않기

"새 결함이 안 나온다" 와 "볼 곳이 떨어졌다" 는 다르다.

• 같은 차터를 같은 방식으로 반복하면 당연히 안 나온다 → 휴리스틱을 바꿔 본다(레슨 14)
• 한 영역만 계속 보고 있었다면 → 다른 위험 영역으로 옮긴다
• 데이터가 늘 똑같았다면 → 경계·이상 데이터로 바꿔 본다

셋을 다 바꿨는데도 안 나오면 그때가 수확 체감이다. 바꾸기 전에 선언하면 "덜 본 것"을 "충분히 봤다"로 착각한다.

"충분하다"를 보고하는 문장

종료 선언은 근거와 함께 전달해야 받아들여진다.

"차터 12개 중 12개를 진행했습니다. 고위험 4개 영역은 모두 다뤘고, 마지막 3세션에서 새 발견은 1건이었습니다. 다루지 못한 것은 다국어 환경과 저사양 기기이고, 이건 알려진 위험으로 남겨 둡니다."

마지막 문장이 중요하다. 못 한 것을 적는 종료 보고가 신뢰를 만든다. "다 봤습니다" 는 반드시 거짓이고, 한 번 틀리면 다음 보고가 안 믿긴다.

사례 — 쿠폰 기능 2일 추정

쿠폰 발급·사용 기능이 들어왔고 관리자가 "며칠 필요해요" 를 물었다.

추정

"사람 1명 기준 1.5일입니다. 1일로 줄이려면 목록 화면과 발급 차터를 다음으로 미룹니다" 라고 전달했다.

실제

• 금액 계산 차터에서 반올림 문제가 나와 재현에 40분을 더 썼다
• 중복 처리 차터는 예상보다 단순해 80분에 끝났다
• 총 10시간 20분 — 여유분 20%가 거의 정확히 들어맞았다

종료 선언

"차터 5개 완료. 고위험 3개 차터 모두 진행. 마지막 2세션 새 발견 1건 (반올림). 미확인: 해외 통화, 쿠폰 수천 건 동시 사용."

이 보고 덕에 "해외 통화"가 다음 스프린트의 차터로 올라갔다. 못 한 것을 적었기 때문에 잊히지 않았다.

세 사람 이상은 왜 안 되나

"셋이면 더 많이 보지 않나" 를 흔히 묻는다. 실제로는 급격히 나빠진다.

• 조작하는 사람이 하나뿐이라 두 명이 동시에 구경꾼이 된다
• 아이디어가 겹쳐 나와 운전자가 어느 것부터 할지 혼란스러워진다
• 대화가 토론으로 흐르고 손이 멈춘다

셋 이상이 모일 가치가 있는 자리는 탐험 세션이 아니라 차터를 만드는 회의(레슨 2)나 결과를 함께 보는 회고다. 실행은 둘까지다. 셋이 모여 한 시간을 쓰면 사람·시간 3시간이 들지만 발견은 둘이 할 때의 두 배가 되지 않는다.

예외가 하나 있다. 교육 목적의 관람이다. 신입 여럿이 경력자 둘의 짝 탐험을 지켜보는 경우인데, 이때 관람자는 질문을 세션 끝에 모아서 한다. 중간에 끼어들면 세션이 강의로 변한다.

실무에서 왜 필요한가

"탐색적 테스팅은 언제 끝날지 몰라서 관리하기 어렵다"는 게 관리자들이 탐색적 테스팅을 꺼리는 흔한 이유다. 차터 기반 추정과 명시적 중단 기준은 이 오해에 대한 실무적 답이다 — 탐색적 테스팅도 계획하고, 추정하고, 종료를 선언할 수 있는 관리 가능한 활동이라는 걸 보여준다. 짝 탐험은 특히 고위험 영역이나 신입 온보딩에 실무에서 자주 쓰이는 구체적인 실천 방법이다.

추정할 수 없는 활동은 예산을 못 받는다

조직에서 어떤 활동이 살아남는 조건은 효과가 좋은 것이 아니라 계획에 들어갈 수 있는 것이다.

왼쪽 팀의 탐색적 테스팅은 일정이 밀릴 때 가장 먼저 잘린다. 잘라도 얼마가 줄어드는지 아무도 모르니, 자르기도 쉽다. 오른쪽 팀은 무엇을 포기하는지가 보여서 오히려 지켜진다.

신입이 가장 빨리 자라는 방법

문서로 탐색적 테스팅을 가르치는 데는 한계가 있다. "왜 거기를 눌렀는지" 가 문서에 안 적히기 때문이다.

짝 탐험은 그 생각의 과정이 소리로 나온다. 경력자가 관찰자로 앉아 "지금 왜 그 값을 넣으셨어요" 를 물으면 신입은 자기 선택을 말로 설명하게 되고, 설명하는 순간 자기가 감으로 했는지 근거로 했는지 알게 된다. 온보딩 기간이 눈에 띄게 짧아지는 이유다.

직무 사이의 벽을 낮춘다

QA와 개발자가 한 화면을 같이 보면 결함 보고의 품질이 올라간다. 개발자가 "로그는 어디서 보면 되나요" 를 알려 주고, QA는 "이런 상태에서 터져요" 를 그 자리에서 보여 준다. 레슨 11에서 다룬 재현 절차가 훨씬 정확하게 적힌다.

채용시장에서의 위치

면접에서 탐색적 테스팅 경험을 물을 때 거의 반드시 따라오는 질문이 "그럼 그건 언제 끝나요" 와 "일정은 어떻게 잡았어요" 다. 이 레슨의 내용이 그 답이다.

세 번째가 경력자를 가려내는 질문이다. "틀린 적 없다" 는 답은 추정을 해 본 적 없다는 뜻으로 읽힌다. 틀린 폭을 알고 그걸 줄여 온 사람만 구체적으로 말할 수 있다.

직급이 올라갈수록 직접 테스트하는 시간보다 테스트를 계획·추정·보고하는 시간이 길어진다. 리드·매니저 공고의 "테스트 계획 수립" 과 "일정 산정" 요건이 정확히 이 능력을 가리킨다. 짝 탐험 운영 경험은 교육·온보딩 담당 역할에서도 직접 쓰인다.

실습 과제

과제 1 — 차터 기반 추정하기 (12분)

"결제 수단 3종(카드/계좌이체/간편결제) 추가"라는 기능에 대해, 필요한 차터 개수를 추정하고(어떤 차터들이 필요할지 이름만 나열해도 좋다), 차터당 시간을 곱해 전체 예상 소요 시간을 계산한다.

과제 2 — 중단 기준 작성하기 (10분)

과제 1의 기능에 대해, 탐험을 멈춰도 될 근거가 되는 중단 기준을 3개 이상 작성한다.

과제 3 — 짝 탐험 회고 (10분)

익숙한 웹 서비스 하나를 골라 차터 1개를 30분 동안 둘이서(혼자라면 소리 내어 생각하며 녹음하는 방식으로) 탐험한 뒤, 아래를 적는다.

1. 관찰자가 제안해서 운전자가 혼자서는 안 했을 조작 2개
2. 역할을 바꾼 뒤 달라진 점
3. 같은 차터를 혼자 했다면 걸렸을 시간과의 비교

자가 체크리스트

• 짝 탐험에서 운전자와 관찰자의 역할을 구분해 설명할 수 있다
• 짝 탐험이 혼자 탐험하는 것보다 나은 점을 최소 두 가지 설명할 수 있다
• 탐험 추정이 "케이스 개수"가 아니라 "차터 개수 × 시간"으로 이뤄지는 이유를 설명할 수 있다
• 탐색적 테스팅의 종료를 판단하는 네 가지 기준을 나열할 수 있다
• 차터 개수를 정하는 다섯 단계를 순서대로 말할 수 있다
• 추정에 여유분 20% 를 더하는 이유를 설명할 수 있다
• 수확 체감을 선언하기 전에 바꿔 봐야 할 세 가지를 안다
• 종료 보고에 못 한 것을 적어야 하는 이유를 설명할 수 있다
• 짝으로 할 영역과 혼자 할 영역을 구분해 판단할 수 있다

흔한 실수

• 탐험 추정을 "감"으로만 한다. 차터 개수를 먼저 정하지 않고 "하루면 되겠지"라고 어림잡으면, 리스크가 큰 영역이 충분히 안 다뤄질 위험이 있다.
• 종료 기준 없이 "시간이 다 돼서" 그냥 멈춘다. 이러면 정말 중요한 영역을 놓친 채 끝날 수 있다. 최소한 리스크 기준으로 확인은 해야 한다.
• 짝 탐험을 "감시"로 오해한다. 운전자와 관찰자는 상하 관계가 아니라 동등하게 아이디어를 주고받는 협업 관계다.
• 역할을 끝까지 바꾸지 않는다. 한 사람이 2시간을 내내 조작하면 다른 한 사람은 30분 뒤부터 구경꾼이 된다. 20~30분마다 바꾼다.
• 관찰자가 손을 뻗는다. "제가 할게요" 로 키보드를 가져가는 순간 짝 탐험이 아니라 번갈아 혼자 하기가 된다. 말로만 전한다.
• 발견 개수를 추정에 넣는다. "버그 10개 찾겠다" 는 약속은 사소한 것을 10개 올리는 쪽으로 사람을 밀어낸다. 투입할 차터만 약속한다.
• 계획 시간만 적고 실제 시간을 안 적는다. 둘을 나란히 남기지 않으면 추정은 영원히 감에 머문다. 세션 노트에 함께 적는다.
• "다 봤습니다"로 종료 보고한다. 반드시 거짓이고, 한 번 들키면 다음 보고의 신뢰가 사라진다. 미확인 영역을 같이 적는다.
• 휴리스틱을 바꿔 보지 않고 수확 체감을 선언한다. 같은 방식으로 반복하면 당연히 새 발견이 없다. 방식·데이터·영역을 바꿔 본 뒤 판단한다.

참고 자료

• Satisfice — Session-Based Test Management — 차터 단위로 탐색적 테스팅을 계획·추정·보고하는 방법론의 원출처
• Elisabeth Hendrickson, Explore It! — 짝 탐험과 탐험 추정을 다룬 장
• James Bach — Exploratory Testing Explained — 탐험의 책임성과 종료 판단을 다룬 원문

이 커리큘럼 안에서

• 모듈 5 레슨 2 — 차터 작성법. 추정의 단위가 여기서 나온다
• 모듈 5 레슨 11·12 — 세션 노트와 재현. 계획 대비 실제 시간을 남길 곳
• 모듈 5 레슨 14 — 휴리스틱 치트시트. 수확 체감을 선언하기 전에 바꿔 볼 방식
• 모듈 4 레슨 4 — 종료 조건. 네 기준의 바탕이 되는 개념
• 모듈 2 — 테스트 계획. 추정 결과가 들어가는 문서
• 모듈 4 — 리스크 분석. 차터를 위험별로 묶는 근거

한 줄 정리 — 짝 탐험은 같은 시간에 더 많이 보는 기법이고, 차터 기반 추정과 네 가지 종료 기준은 탐색적 테스팅을 계획에 들어갈 수 있는 활동으로 만든다. 못 한 것을 적는 종료 보고가 그 신뢰를 지킨다.