페어와이즈 (Pairwise) 테스팅과 직교 배열 (Orthogonal Array) 조합 최적화

핵심 인사이트 (3줄 요약)

본질: 페어와이즈(Pairwise) 테스팅은 다중 입력 변수를 가진 시스템을 테스트할 때, 모든 변수의 전체 조합(Exhaustive Combination)을 테스트하는 대신, **"시스템의 결함 대부분은 단일 변수 또는 2개의 변수가 상호작용(Pair)할 때 발생한다"**는 통계적 경험칙에 기반하여 테스트 케이스 수를 획기적으로 줄이는 블랙박스(Black-box) 설계 기법이다.

가치: 변수가 많아질수록 테스트 케이스가 기하급수적으로 폭발하는 조합 폭발(Combinatorial Explosion) 문제를 해결해 준다. 직교 배열(Orthogonal Array) 등의 수학적 도구를 사용해 "모든 변수들의 가능한 짝(Pair)이 최소한 1번씩은 조합되도록" 압축함으로써, 테스트 가성비(결함 발견율 대비 노력)를 극대화한다.

융합: 실무에서는 엑셀로 사람이 계산할 수 없으므로 PICT, Allpairs 같은 자동화 도구와 융합되어 사용되며, 설정값(Configuration)이나 브라우저 호환성 등 다양한 조합 환경에서 동작을 보장해야 하는 **크로스 플랫폼 테스트(Cross-platform Testing)**의 표준 아키텍처 설계로 자리 잡고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 'Pairwise'는 '쌍으로, 둘씩 짝지어'라는 뜻이다. 소프트웨어에 입력 변수 A, B, C가 있을 때, A-B-C 세 가지가 동시에 어떻게 조합되는지 100% 다 보지 않고, A-B의 짝꿍, B-C의 짝꿍, C-A의 짝꿍만 각각 최소한 한 번씩 나오게 섞어주면 충분하다는 실용주의적 테스팅 철학이다. (All-Pairs Testing이라고도 부른다.)
필요성: 웹 브라우저 호환성 테스트를 해야 한다고 치자.
- OS 3종 (Windows, Mac, Linux)
- 브라우저 4종 (Chrome, Edge, Safari, Firefox)
- 해상도 3종 (FHD, 2K, 4K)
- 이걸 다 곱하면 $3 \times 4 \times 3 = 36$번의 테스트를 해야 한다. 만약 변수가 10개, 20개가 넘어가면 테스트 케이스는 수백만 개로 폭발한다. 시간이 생명인 애자일(Agile) 환경에서 36번을 다 돌릴 수는 없다. 그렇다고 직관에 의존해 5개만 대충 뽑아서 테스트하면 호환성 버그가 운영(Production)에서 터진다. **"놓치는 쌍(Pair)이 없으면서도 가장 적게 테스트하는 수학적 공식"**이 절실하게 필요했다.
💡 비유: 반 친구 10명끼리 서로 모두 친해지게(상호작용) 하려면 어떻게 해야 할까요?
- 전체 조합 (비효율): 10명이 다 같이 모여서 피자를 1번씩 먹게 하는 수백 번의 파티를 엽니다. (돈과 시간이 너무 듭니다).
- 페어와이즈 (효율): "어차피 두 명씩 대화(Pair)만 한 번씩 섞어주면 다 친해져!"라는 원리에 따라, 4명씩 앉는 테이블 자리를 똑똑하게 수학적으로 이리저리 바꿔주면 단 3~4번의 피자 파티만으로 10명이 서로 '최소 1번씩은 1:1로 짝꿍'이 되도록 완벽하게 섞을 수 있습니다.
등장 배경 및 발전 과정:
1. 직교 배열(OATS)의 도입: 원래 제조업(품질 관리)에서 다구치 겐이치(Genichi Taguchi) 박사가 공장 실험 횟수를 줄이기 위해 고안한 '직교 배열(Orthogonal Array)' 수학이 근간이다.
2. 소프트웨어 공학의 수용: 1990년대 후반, 리차드 쿤(Richard Kuhn) 등의 연구진이 "S/W 버그의 70~80%는 1개나 2개의 변수 꼬임에서 발생하고, 3~4개 이상이 꼬여서 터지는 버그는 극히 드물다"는 통계를 발표하며 S/W 테스팅에 정식 도입되었다.
3. 자동화 도구 생태계: 현재는 마이크로소프트의 PICT 도구 등 알고리즘 기반 생성기가 발전하여, 개발자가 변수 목록만 던져주면 최적화된 엑셀 시트(Test Suite)를 1초 만에 뽑아준다.
📢 섹션 요약 비유: 수백 가지의 옷(바지, 티셔츠, 모자)을 사서 어떻게 코디해야 가장 예쁠지 알아볼 때, 모든 옷을 다 섞어 입어보려면 1년이 걸리지만, 적어도 "이 바지와 이 모자의 조합"을 한 번씩은 다 입어보도록 옷을 영리하게 섞어주는 인공지능 스타일리스트와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

페어와이즈 압축(Compression) 수학적 메커니즘

$2 \times 2 \times 2$ 조합의 변수를 가진 시스템을 예로 들어보자. (글꼴 크기: 크다/작다, 글꼴 색상: 검정/빨강, 배경: 흰색/회색) 원래 모든 경우의 수(전체 조합)는 $2 \times 2 \times 2 = 8$개다. 이를 페어와이즈로 압축해 본다.

  ┌───────────────────────────────────────────────────────────────┐
  │         전체 조합 (Exhaustive) vs 페어와이즈 (Pairwise) 비교        │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │  [ 1. 전체 조합 (All Combinations) - 8개 ]                       │
  │    1. 크다-검정-흰색    5. 작다-검정-흰색                            │
  │    2. 크다-검정-회색    6. 작다-검정-회색                            │
  │    3. 크다-빨강-흰색    7. 작다-빨강-흰색                            │
  │    4. 크다-빨강-회색    8. 작다-빨강-회색                            │
  │                                                               │
  │  [ 2. 페어와이즈 조합 (Pairwise) - 4개로 압축! ]                   │
  │    1. 크다 - 검정 - 흰색  ▶ Pair확인: (크다,검정), (크다,흰색), (검정,흰색) │
  │    2. 크다 - 빨강 - 회색  ▶ Pair확인: (크다,빨강), (크다,회색), (빨강,회색) │
  │    3. 작다 - 검정 - 회색  ▶ Pair확인: (작다,검정), (작다,회색), (검정,회색) │
  │    4. 작다 - 빨강 - 흰색  ▶ Pair확인: (작다,빨강), (작다,흰색), (빨강,흰색) │
  │                                                               │
  │  ▶ 결론 검증: 4개의 케이스만 테스트해도, 모든 "크기+색상", "크기+배경",       │
  │              "색상+배경"의 2개짜리 짝(Pair)들이 단 하나도 빠짐없이 100%    │
  │              등장했음을 알 수 있다! 즉, 8번 할 것을 4번으로 반토막 냈다!   │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 변수가 늘어날수록 이 압축의 위력은 기하급수적으로 폭발한다. 만약 10개의 변수가 각각 10개의 값을 가진다면 전체 조합은 $10^{10}$ (100억 개)이다. 그러나 페어와이즈 알고리즘을 돌리면 단 100~200개의 테스트 케이스만으로 "모든 2개의 쌍(Pair)"을 100% 검사할 수 있다. 버그는 보통 글씨가 빨간색일 때 + 배경이 회색이면 글자가 안 보인다는 식의 두 변수 충돌에서 생기지, 세 가지, 네 가지 변수가 기가 막히게 얽혀야만 나타나는 버그는 매우 드물다는 통계적 확신이 이 기법의 심장이다.

직교 배열 (Orthogonal Array Testing, OATS)

페어와이즈를 수학적으로 구현하는 가장 대표적인 방법이 직교 배열이다. 직교 배열은 L_N(S^K) 기호로 표시된다. (N: 총 실험 횟수, S: 변수가 가지는 상태 수, K: 변수의 개수). 배열의 어떤 두 열(Column)을 골라도 그 열의 값들의 조합이 모두 같은 횟수로 나타난다는(직교성, Orthogonality) 수학적 성질을 이용해 테스트 케이스의 밸런스를 완벽하게 맞춰준다.

Ⅲ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 모바일 앱 파편화 호환성 테스트 (Device Matrix): A 회사가 안드로이드 앱을 출시하려는데, 테스트해야 할 환경이 너무 많다. [OS 버전: 10, 11, 12, 13, 14], [해상도: HD, FHD, WQHD], [제조사: 삼성, 모토로라, 샤오미], [램 크기: 4GB, 8GB, 12GB]. 총 $5 \times 3 \times 3 \times 3 = 135$ 대의 스마트폰을 사 와서 일일이 깔아봐야 할까?
- 판단: 전형적인 호환성 매트릭스의 조합 폭발(Combinatorial Explosion) 문제다.
- 해결책: PICT(Pairwise Independent Combinatorial Testing) 도구에 변수들을 입력하여 페어와이즈 조합을 돌려 뽑아낸다. 알고리즘은 약 15개의 최적화된 조합(예: OS 13 + FHD + 삼성 + 8GB 등)을 토해낸다. 회사는 이 15대의 기기만 대여해서(또는 클라우드 테스트 팜에서) 테스트하면, 호환성 버그의 95% 이상을 잡아내면서도 테스트 비용과 시간을 1/10로 줄이는 마법을 경험하게 된다.
시나리오 — 단일 결함 가정(Single Fault Assumption)의 무시로 인한 예외 처리 마비: 페어와이즈를 배운 신입 테스터가 회원가입 창을 테스트한다. 유효값(Valid)과 무효값(Invalid)을 잔뜩 섞어서 페어와이즈 배열을 짰다. [이름 없음(Invalid), 비밀번호 짧음(Invalid), 이메일 정상(Valid)] 이라는 케이스가 생성되었고, 폼 제출 시 "이름을 입력하세요"라는 에러가 떴다. 테스터는 테스트 성공(Pass) 처리했다.
- 판단: 페어와이즈와 네거티브 테스팅(무효값 조합)을 잘못 섞은 전형적 안티패턴이다. 위 케이스에서는 비밀번호가 짧다는 버그(에러 메시지)가 이름 에러 메시지에 가려져서 영원히 검증되지 않는 마스킹(Masking) 효과가 발생했다.
- 해결책: 무효값(Invalid/Error)을 테스트할 때는 단일 결함 가정(Single Fault Assumption) 원칙을 반드시 지켜야 한다. 페어와이즈 조합 엔진에 변수를 넣을 때는 '유효한 값(Valid)'들끼리만 섞어서 배열을 뽑아내야 한다. 무효값은 한 번의 테스트 케이스에 오직 1개만 들어가게 고정(나머지는 전부 Valid)하여 개별적으로 테스트해야만, 특정 에러 코드가 정상적으로 튀어나오는지 정확히 검증할 수 있다.

도입 체크리스트

비즈니스적 리스크 한계: "정말로 3개 변수가 꼬여서 터지는 버그는 무시해도 되는가?" 만약 그 시스템이 항공기 제어 시스템이나 원자력 발전소 제어기라면, 3개 변수의 상호작용 버그(확률 2%)도 대참사를 부른다. 페어와이즈(2-way)는 시간 대비 가성비의 영역이지 무결점 영역이 아니다. 생명이 달린 곳에서는 3-way (모든 3개의 쌍 조합) 또는 전체 조합(Exhaustive)을 써야 한다.

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

구분	전체 조합 (Exhaustive Testing)	페어와이즈 튜닝 (Pairwise Testing)	개선 효과
정량 (케이스 수)	변수가 늘어날수록 케이스 $2^N$ 기하급수 폭증	알고리즘 압축으로 수십 개 내외 유지	테스트 스크립트 작성 및 실행 비용 90% 이상 극단적 감축
정량 (결함 커버리지)	시간 부족으로 5%만 임의 검사하고 배포	변수 2개짜리 상호작용의 100% 촘촘한 커버	가성비(ROI) 최고: 적은 비용으로 전체 결함의 80~90% 색출
정성 (설계 의존성)	"개발자가 알아서 중요한 거 몇 개 골라서 테스트함"	수학적으로 누락 없는 상호작용 교차 검증 보장	직관과 편향(Bias)에 흔들리지 않는 체계적 품질 확신(Confidence) 제공

결정 테이블이 깊이(Depth) 있는 복잡한 비즈니스 로직의 결함을 도려내는 메스라면, 페어와이즈 테스팅은 넓은 표면(Width)에 흩뿌려진 환경 변수와 설정값들의 조합 폭발을 압축해 주는 수학적 필터다. 기술사는 무턱대고 "모든 경우의 수를 다 테스트하라"는 무책임한 지시를 내리는 것이 아니라, 통계적 확률(결함은 두 변수의 충돌에서 80%가 발생한다)에 기대어 품질(Quality)과 납기(Time-to-Market) 사이의 완벽한 밸런스를 찾아주는 도구로 페어와이즈 아키텍처를 도입해야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
결정 테이블 (Decision Table)	페어와이즈의 경쟁자이자 짝꿍. 입력 변수의 룰이 `if-else`로 복잡하게 얽혀 있다면 결정 테이블을 써야 하고, 그저 환경 설정(OS, 브라우저)처럼 서로 독립적인 변수들이라면 페어와이즈를 쓰는 것이 맞다.
블랙박스 테스트 (Black-box Testing)	소스 코드 내부 로직을 보지 않고 입력과 출력만 보고 쪼개는 기법. 동등 분할, 경계값 분석, 결정 테이블, 상태 전이, 페어와이즈(직교 배열)가 모두 이 가문에 속한다.
단일 결함 가정 (Single Fault Assumption)	무효값(에러)을 페어와이즈로 섞으면 한 에러가 다른 에러를 가려버리는 마스킹 효과가 발생하므로, "한 번의 테스트에는 한 가지의 고의적 결함만 넣는다"는 중요한 테스팅 철학이다.
마스킹 효과 (Masking Effect)	버그 1번과 버그 2번이 동시에 발생했을 때, 버그 1번이 프로그램을 멈춰버려서 버그 2번은 영원히 발견되지 않고 숨어버리는 치명적 현상이다.
PICT (Pairwise Independent Combinatorial Testing)	마이크로소프트가 오픈소스로 푼 가장 유명한 페어와이즈 자동 생성 CLI 도구. 텍스트 파일로 변수만 던져주면 알아서 압축된 조합 테이블을 뱉어낸다.

👶 어린이를 위한 3줄 비유 설명

뷔페에 갔는데 고기 10종류, 빵 10종류, 소스 10종류가 있어요. 이걸 다 섞어서 먹어보려면 $10 \times 10 \times 10 = 1000$번이나 먹어야 해서 배가 터질 거예요.
하지만 맛이 없는(상한) 요리는 보통 "이상한 고기와 이상한 소스" 두 개가 만났을 때 생기는 법이죠. 빵까지 세 가지가 다 모여야만 맛이 없어지는 경우는 거의 없어요!
그래서 똑똑한 인공지능 요리사에게 "적어도 고기-소스 짝꿍, 고기-빵 짝꿍은 한 번씩 다 먹어볼 수 있게 최소한으로만 섞어줘!"라고 부탁하면, 단 20접시만 먹고도 뷔페의 모든 맛(조합)을 다 평가할 수 있는 효율적인 마법이 '페어와이즈'랍니다!