결정 테이블 (Decision Table) 논리 조합 테스트 설계

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

본질: 결정 테이블(Decision Table) 테스팅은 소프트웨어의 입력 조건(Condition)들이 서로 논리적으로 복잡하게 얽혀 있을 때, 모든 가능한 입력의 조합(조합의 수 = 2^N)과 그에 따른 결과(Action)를 표(Table) 형태인 진리표(Truth Table)로 그려서 누락 없는 테스트 케이스를 도출하는 블랙박스(Black-box) 기법이다.

가치: 동등 분할(Equivalence Partitioning)이나 경계값 분석(BVA)이 단일 변수(1개의 입력창)의 유효성을 쪼개는 데 그친다면, 결정 테이블은 **"나이가 65세 이상이고(AND), 국가유공자이거나(OR), 평일에 방문했을 때"**처럼 비즈니스 규칙(Business Rule)이 꼬여있는 다중 변수의 상호작용(Interaction) 버그를 100% 빈틈없이 색출해 낸다.

융합: 실무에서는 복잡한 요구사항 명세서의 논리적 모순(불가능한 조합)을 찾아내는 정적 분석(Static Analysis)의 역할도 겸하며, 너무 많은 조건(Condition 폭발)이 발생할 경우 직교 배열(Orthogonal Array)을 쓰는 페어와이즈(Pairwise) 테스팅과 융합하여 케이스를 최적화하는 방향으로 발전한다.

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

개념: 논리 회로에서 사용하는 진리표(Truth Table)를 소프트웨어 테스팅에 그대로 가져온 것이다. 위쪽에는 입력 조건(Condition)들을 적고, 아래쪽에는 그 조건들의 T/F(True/False) 조합에 따라 시스템이 뱉어내야 할 결과(Action)를 매핑한다. 세로로 내려오는 1개의 열(Column)이 곧 1개의 완벽한 테스트 케이스(Test Case)가 된다.
필요성: 개발자들은 흔히 if-else 문을 중첩해서 짠다. if (A && B) { ... } else if (C || D) { ... } 같이 복잡한 룰이 섞여 있을 때, 요구사항 기획서 자체가 모호하거나 서로 충돌하는 경우(모순)가 비일비재하다. 개발자의 머릿속 직관(Ad-hoc)만으로 테스트 코드를 짜면, "A는 참인데 B는 거짓이고 C가 참인" 숨겨진 엣지 케이스(Edge Case)를 100% 빼먹게 된다. 인간의 뇌는 3개 이상의 논리 조합을 한 번에 검증하지 못하기 때문에, 기계적이고 시각적인 테이블(표)이라는 수학적 도구가 필요했다.
💡 비유: 복잡한 약국의 '할인 룰'을 상상해 봅시다. "회원입니까?(A)", "신용카드 결제입니까?(B)", "주말입니까?(C)"라는 3가지 질문이 있습니다.
- 직관적 테스트: 알바생이 대충 "회원이 주말에 카드 내면 10% 할인!" 1개만 기억합니다.
- 결정 테이블 테스트: "A, B, C가 가질 수 있는 경우의 수는 2 × 2 × 2 = 총 8가지야. 이 8가지 조합을 엑셀로 다 적어놓고, 상황별로 10% 할인인지, 5% 할인인지, 할인 없음인지 빈칸 없이 꽉 채워서 표를 완성하자." 이 표를 보고 그대로 8번 계산기를 두드려보는 것이 결정 테이블 기법입니다.
등장 배경 및 발전 과정:
1. 요구사항 모순의 재앙: 폭포수(Waterfall) 모델에서 기획서의 비즈니스 룰이 너무 복잡해, 개발자가 자기 마음대로 해석해서 코딩하다가 치명적 버그가 터짐.
2. Cause-Effect Graphing의 한계: 원인-결과 그래프 기법이 나왔으나, 그리기 너무 복잡하고 시간이 오래 걸려 테스터들이 기피함.
3. 결정 테이블의 표준화: 표 형태로 단순화된 결정 테이블이 ISTQB(국제 테스팅 자격)의 블랙박스 기법 핵심으로 자리 잡으며 금융, 통신 등 룰이 복잡한 엔터프라이즈 시스템 검증의 바이블이 됨.
📢 섹션 요약 비유: 복잡한 미로(비즈니스 로직)에 갇혔을 때 감으로 길을 찾는 게 아니라, 출발지부터 목적지까지 갈 수 있는 모든 교차로의 우회전/좌회전 경우의 수(조합)를 지도에 싹 다 그려놓고, 안 가본 길이 1곳도 없도록 완벽하게 훑어내는 전술입니다.

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

결정 테이블(Decision Table)의 구성 요소 및 작성법

결정 테이블은 크게 조건(Condition) 부분과 행동(Action) 부분으로 나뉜다.

구조 (Structure)	설명	예시
조건 스터브 (Condition Stub)	시스템에 주어지는 입력 조건들의 리스트 (왼쪽 위)	1. 65세 이상인가? 2. 국가유공자인가?
조건 항목 (Condition Entry)	조건들의 참/거짓(T/F) 조합 (오른쪽 위)	T/T, T/F, F/T, F/F (총 4개)
행동 스터브 (Action Stub)	조합의 결과로 시스템이 취해야 할 행동 리스트 (왼쪽 아래)	1. 무임승차 발권 2. 일반요금 발권
행동 항목 (Action Entry)	각 조건 조합에 대해 발생해야 하는 구체적 행동 (오른쪽 아래)	X 표시 (해당 행동 수행)

실전 결정 테이블 작성 및 최적화(Don't Care) 매커니즘

"쇼핑몰 무통장 입금 시나리오"를 결정 테이블로 그려보자. 조건 1: 회원인가? / 조건 2: 쿠폰이 있는가? / 조건 3: 무통장 입금을 선택했는가? 원래 경우의 수는 $2^3 = 8$개(Rule 1~8)지만, 논리적 최적화를 통해 가성비를 극대화할 수 있다.

  ┌─────────────────────────────────────────────────────────────────┐
  │         쇼핑몰 할인 및 결제 룰의 결정 테이블 (최적화 적용 전/후)           │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │ [ 조건(Condition) ]         R1   R2   R3   R4   R5   R6   R7   R8 │
  │ 1. 회원인가? (Member)        T    T    T    T    F    F    F    F │
  │ 2. 쿠폰 보유? (Coupon)       T    T    F    F    T    T    F    F │
  │ 3. 무통장 입금? (Cash)       T    F    T    F    T    F    T    F │
  │ ─────────────────────────────────────────────────────────────── │
  │ [ 행동(Action) ]                                                │
  │ 1. 10% 추가 할인 적용        X    X                                 │
  │ 2. 현금 영수증 발행 창 노출   X         X         X         X         │
  │ 3. 정상 결제 진행            X    X    X    X    X    X    X    X │
  │                                                                 │
  │                                                                 │
  │ ▶ [ 최적화 1: "Don't Care (상관없음)" 기호 적용 ]                    │
  │ 비회원(F)은 애초에 쿠폰(T/F)을 가질 수 없다는 요구사항이 숨겨져 있다면?      │
  │ R5, R6처럼 비회원(F)인데 쿠폰이 있는(T) 논리적 불가능 조합이 발견됨!        │
  │                                                                 │
  │ ▶ [ 최적화 2: 룰 압축 (Rule Contraction) ]                        │
  │ 비회원(F)인 R5~R8을 하나로 묶어서 `F, -, -` (회원 아니면 뒤엔 따지지도 마!)│
  │ 로 뭉뚱그려버리면, 8개의 테스트 케이스를 5개로 줄이면서도 커버리지는 100%!   │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 결정 테이블의 진정한 힘은 단순히 표를 그리는 것이 아니라, 표를 그리다가 **"어? 비회원인데 쿠폰을 가진 조합(R5)은 시스템에서 발생할 수가 없는데 기획서에 예외 처리 내용이 없네?"**라는 요구사항의 결함(Ambiguity)을 코드 짜기 전에 즉각 잡아낸다는 점이다. 불가능한 논리나, 결과에 영향을 미치지 않는 조건(무통장 입금 여부는 할인율에 영향을 안 줌)은 기호 - (Don't care)로 표시하여 세로 열(Rule)들을 병합(Contraction)한다. 이를 통해 쓸데없는 테스트 스크립트 작성 비용을 획기적으로 줄일 수 있다.

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

실무 시나리오

시나리오 — 중첩 if 문의 스파게티 로직 버그: 한 핀테크 스타트업이 대출 한도 승인 로직을 짰다. 신용점수 800 이상, 기대출 없음, 재직 1년 이상이라는 3가지 조건이 얽혀있다. 코드가 if 안에 if가 있고 else가 남발되어 스파게티가 되었다. 출시 첫날, "신용점수 900점인데 기대출이 있고 재직 1년 미만인 고객"이 에러(500) 창을 만나 이탈했다.
- 판단: 전형적인 논리 조합 테스트 누락이다. 개발자는 머릿속에 가장 뚜렷한 Happy Path(전부 다 True)와 Worst Path(전부 다 False)만 상상하고 테스트했다. 중간에 섞여 있는 회색 지대(True-False-False)의 분기 로직 처리를 아예 빼먹은 것이다.
- 해결책: 백엔드 개발자(또는 QA)는 대출 심사 모듈을 짜기 전에 무조건 결정 테이블을 화이트보드에 그려야 한다. 3가지 조건의 $2^3=8$가지 규칙표를 그리고, 기획자에게 표를 가져가서 "이 조합일 때 결과가 거절입니까, 재심사입니까?"라고 확답을 받은 뒤에, 표의 세로줄 1개를 단위 테스트(JUnit) 1개로 완벽히 1:1 매핑하여 8개의 TDD 테스트 코드를 촘촘하게 박아 넣어야 한다.
시나리오 — 조합 폭발(Combinatorial Explosion)과 페어와이즈(Pairwise)의 융합: 자동차 보험료 산정 시스템의 테스트를 설계한다. 변수가 '연령(5종류)', '사고 이력(3종류)', '배기량(4종류)', '성별(2종류)', '가입 기간(4종류)' 이다. 이를 결정 테이블로 모두 곱하면 $5 \times 3 \times 4 \times 2 \times 4 = 480$개의 룰(테스트 케이스)이 튀어나온다. 사람이 표를 그릴 수 있는 한계를 넘어섰다.
- 판단: 결정 테이블은 조건이 4~5개를 넘어가면 규칙의 수가 지수 함수적으로 폭발하는 치명적인 단점이 있다.
- 해결책: 100% 완전 조합(All-combinations)을 과감히 포기한다. 대신 "소프트웨어 결함의 90% 이상은 단일 변수 혹은 두 변수의 상호작용(Pair)에서 터진다"는 통계적 사실에 기반한 페어와이즈 테스팅(Pairwise Testing) 아키텍처로 융합 전환한다. 직교 배열(Orthogonal Array) 수학을 이용해 480개의 케이스를 20개 내외로 압축(모든 변수의 쌍이 최소 1번씩은 만나도록)하여, 테스트 가성비(ROI)를 극한으로 끌어올리는 결단이 필요하다.

도입 체크리스트

요구사항 리뷰적: 기획서에 AND, OR, NOT, ~할 경우, ~를 제외하고 등의 논리 접속사가 난무하고 있는가? (이 단어들이 기획서에 3개 이상 보인다면, 그 즉시 코딩을 멈추고 엑셀을 켜서 결정 테이블부터 그려야 대참사를 막을 수 있다.)
코드 기반 커버리지: 블랙박스 기법인 결정 테이블로 짠 테스트를 실행했을 때, 실제 소스 코드의 **다중 조건 커버리지(Multiple Condition Coverage, MCC)**가 100% 달성되었는가? (결정 테이블의 세로줄을 다 돌렸다면 논리 회로상의 모든 T/F 조합을 타본 것이므로 MCC 100%가 달성되는 것이 수학적 정상이다.)

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

구분	감에 의존한 조건(If) 테스트	결정 테이블 (Decision Table) 적용	개선 효과
정량 (결함 탐지)	엣지 케이스(복합 조건) 버그 유출률 30%	2^N 개의 모든 조합 강제화로 사각지대 제로	논리 분기(Branch) 관련 치명적 버그 100% 원천 차단
정량 (기획 검증)	개발 막바지에 요구사항 모순 발견, 수 일 지연	표를 그리는 순간 빈칸(모순) 발견	기획 결함 조기(Shift-Left) 발견으로 재작업 비용 90% 절감
정성 (명세화)	"이 조건에선 어떻게 되죠?" 기획자에게 계속 물어봄	진리표 자체가 완벽한 비즈니스 룰 문서가 됨	코드보다 명확한 살아있는 문서(Living Documentation) 확보

결정 테이블은 테스트 기법이라는 외피를 쓴 '비즈니스 로직 검증의 해부학 메스'다. 기술사는 복잡한 금융, 보험, 의료 시스템을 설계할 때 겉모습(UI)이나 인프라(Cloud)에만 신경 쓸 것이 아니라, 그 시스템의 심장인 비즈니스 룰 엔진(Rule Engine)이 얼마나 허술한 모순 덩어리인지를 결정 테이블이라는 수학적 칼날로 도려내어 증명해야 한다. 테스트를 위해 표를 그리는 과정 자체가 사실상 가장 위대한 "요구사항 리뷰(Requirements Review)" 행위임을 팀에 주입해야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
블랙박스 테스트 (Black-box Testing)	동등 분할, 경계값 분석과 함께 코드 내부를 보지 않고 요구사항 명세서의 논리 구조만으로 테스트를 설계하는 3대 대표 기법이다.
상태 전이 테스트 (State Transition)	결정 테이블이 '정적인 논리 조합'을 본다면, 상태 전이 기법은 시간에 따른 상태 변화(예: 로그인 → 잠금 → 해제)라는 '동적인 흐름'의 결함을 잡는 보완 기법이다.
페어와이즈 (Pairwise / OATS)	결정 테이블의 조건이 너무 많아져 $2^{10}$ 같이 폭발할 때, 100% 조합 대신 "모든 짝(Pair)만 한 번씩 맞추자"고 수학적으로 압축해 주는 테스트 최적화 기법이다.
MCC (다중 조건 커버리지)	화이트박스 테스트 지표 중 하나로, `if (A && B)`에서 A와 B의 모든 T/F 조합을 다 타보았는지를 재는 지표. 결정 테이블이 이를 100% 충족시켜 준다.
BDD (행위 주도 개발)	Cucumber 등을 쓸 때 `Scenario Outline`의 `Examples` 표에 결정 테이블을 그대로 복붙(Copy & Paste)하면, 10초 만에 완벽한 자동화 테스트 코드가 완성되는 마법의 궁합이다.

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

게임에서 '불 마법'과 '얼음 마법' 그리고 '독 마법' 3가지를 동시에 쓸 수 있다고 해봐요. 이걸 섞었을 때 어떤 폭발이 일어날지 헷갈리잖아요?
그래서 도화지에 [불+얼음], [불+독], [얼음+독], [셋 다 섞음] 등 나올 수 있는 모든 마법의 짝꿍(경우의 수 8가지)을 빙고판(표)처럼 쫙 그려놓고 하나씩 빈칸을 채워보는 거예요.
머릿속으로 대충 "이런 마법이 나가겠지~" 하고 상상만 하다가 엉뚱한 마법이 나가서 내 캐릭터가 죽는 걸 막기 위해, 모든 짝꿍을 표로 그려서 한 번씩 다 실험해 보는 안전한 방법이랍니다!