탐색적 테스팅과 도메인 지식 부채
"Explore It!" (Elisabeth Hendrickson, 2013) 읽기 대화에서 정리한 생각들.
탐색적 테스팅의 정의
"시스템에 대해 학습하기 위해 테스트를 동시에 설계하고 실행하며, 마지막 실험에서 얻은 통찰을 다음 실험에 반영하는 것"
네 가지 요소: 설계(Design) → 실행(Execute) → 학습(Learn) → 조향(Steer)
Tested = Checked + Explored
- Checking — "의도한 대로 동작하는가?" → TDD, 단위 테스트
- Exploring — "우리가 모르는 리스크는 없는가?" → 탐색적 테스팅
TDD는 "내가 아는 것"을 코드로 확인하는 데 탁월하지만, 떠올리지 못한 건 테스트도 작성하지 못한다.
책의 핵심 가치: 휴리스틱 체크리스트
책은 "위험한 가능성이 떠오르게 만드는 법"을 가르친다. 체크리스트 예시:
| 휴리스틱 | 설명 |
|---|---|
| Zero, One, Many | 개수를 변형 |
| Some, None, All | 집합에서 일부/없음/전부 선택 |
| Beginning, Middle, End | 위치를 변형 |
| Goldilocks | 너무 작게, 딱 맞게, 너무 크게 |
| CRUD | 생성·조회·수정·삭제 각각 탐색 |
| Follow the Data | 데이터 흐름 전체를 추적 |
| Interrupt | 도중에 끊기 |
| Starve | 자원 고갈 |
직관만으로도 탐색은 가능하지만, 자기가 익숙한 영역만 반복 탐색하게 된다. 체크리스트는 사각지대를 찔러주는 보조 도구.
조향(Steering)은 책의 가장 약한 부분
"잘 안 되는 쪽을 더 파라"는 원칙만 제시할 뿐, 구체적 방법론은 없다. 조향 능력은 결국 경험과 도메인 지식에서 온다.
탐색의 한계
탐색도 떠올린 것만 테스트할 수 있다. Checking이 코드 작성 시점의 상상력이라면, Exploring은 실행하면서 추가로 떠올린 것일 뿐 — 본질적 한계는 동일하다.
가장 강력한 탐색은 실제 사용자다. 사용자는 떠올리려고 노력하지 않아도 개발자가 상상 못한 일을 한다.
Checking → Exploring → 배포 → 사용자 피드백 — 각 단계가 이전 단계의 상상력 한계를 보완하는 구조. 가장 강력한 건 마지막 단계.
Ward Cunningham과 기술 부채
Ward가 서문을 쓴 이유: 그의 평생 관심사는 "소프트웨어의 본질적 불확실성"이다.
"프로그램이라는 논리적 산물에 수많은 결정을 묶어 넣음으로써 소수가 다수에게 영향을 미칠 수 있다. 그 영향의 본질은 사전 평가를 거부한다(defies a priori assessment)."
Ward의 기술 부채 원래 의미는 코드 퀄리티가 아니라 도메인 지식 부채:
- 도메인 이해 부족 → 코드가 현실을 제대로 반영 못함
- 배우면서 코드를 고쳐나가는 건 자연스러운 과정
- 부채는 학습의 부산물이지, 게으름의 결과가 아님
탐색적 테스팅은 Ward에게 도메인 지식 부채를 발견하는 도구였다. "배포하고 사용자 이야기에 귀 기울이기"는 도메인 지식 부채를 상환하는 가장 직접적인 방법.
에이전트 시대에의 시사점
에이전트가 만든 코드를 배포할 수 있는가? — Ward의 세 질문의 2025년 버전:
- 에이전트가 생성한 코드가 정말 맞는지 어떻게 아는가?
- 테스트가 통과하면 배포해도 되는가?
- "에이전트가 만들었지만 괜찮다"고 어떻게 납득시키는가?
에이전트도 자기가 아는 범위 안에서만 검증한다. 핵심 질문: "에이전트가 모르는 것을 내가 알 수 있는가?"