원인결과 그래프란 복잡한 조건 로직을 「도표」로 정리하여 테스트 케이스로 변환하는 테스트 설계 기법입니다. 디시전 테이블에서는 정리할 수 없는 다조건·복잡한 AND/OR/NOT 로직을 시각화함으로써 빠짐없는 테스트 설계를 실현할 수 있습니다.
이 글에서는 원인결과 그래프（Cause-Effect Graph）의 작성법과 구체적인 예시를 알기 쉽게 해설합니다.
👉 디시전 테이블과의 차이：조건을 직접 표로 만들지, 도표로 정리한 후 표로 만들지——이 차이가 복잡한 로직에서 큰 차이를 만들어냅니다.
💡 한 마디로 말하면
원인결과 그래프 ＝ 「어떤 일이 일어나면 어떤 결과가 나오는가」를 도표로 만들어, 테스트 케이스를 기계적으로 도출하는 기법
📌 결론（30초로 이해）
원인결과 그래프란 「원인（조건）과 결과（동작）의 관계를 도표로 정리하고 디시전 테이블로 변환하여 테스트 케이스를 만드는 기법」입니다.
- ✔ 조건이 많다（6개 이상）
- ✔ AND / OR / NOT이 복잡하게 얽힌다
- ✔ 디시전 테이블이 파탄났다
→ 이런 때에 사용하는 테스트 설계 기법입니다.
📊 원인결과 그래프 이미지（로그인 처리 예시）
👉 왼쪽이 원인（입력 조건）, 오른쪽이 결과（동작）. 위가 정상계, 아래가 이상계의 전형적인 패턴입니다.
👉 각 조건의 조합에 따라 어떤 결과（정상 or 이상）가 발화하는지를 나타내고 있습니다.
| C1（ID가 올바름） | ──┐ | AND ∧ | ──→ | E1 로그인 성공 | ← 정상 전이 |
| C2（PW가 올바름） | ──┘ | ||||
| ¬C1（ID가 틀림） | ──┐ | OR ∨ | ──→ | E2 에러 표시 | ← 이상계 |
| ¬C2（PW가 틀림） | ──┘ | ||||
C＝원인（Cause） E＝결과（Effect） ¬＝NOT ∧＝AND ∨＝OR →＝전이
원인결과 그래프를 사용하면 복잡한 조건의 조합을 「도표→디시전 테이블」의 흐름으로 기계적으로 테스트 케이스에 변환할 수 있어 누락이나 중복 없는 고품질 테스트 설계가 실현됩니다.
📌 이런 분께 추천합니다
- 원인결과 그래프를 처음 배우는 QA 엔지니어·개발자
- 디시전 테이블에서는 조건이 너무 많아 정리할 수 없는 상황에 직면한 분
- 복잡한 업무 로직의 테스트 설계를 체계화하고 싶은 분
- ISTQB 학습에서 원인결과 그래프를 이해하고 싶은 분
✅ 이 글을 읽으면 얻을 수 있는 것
- 원인결과 그래프의 개념·논리 기호·작성법을 알 수 있다
- 그래프에서 디시전 테이블을 도출하는 순서를 알 수 있다
- 디시전 테이블과의 사용 구분 판단 기준을 알 수 있다
👤 이 글을 쓴 사람
QA 엔지니어·테스트 자동화 엔지니어로서 15년 이상의 실무 경험을 가진 Yoshi가 집필. 원인결과 그래프는 복잡한 업무 로직 검증에서 활용하고 있는 기법입니다. 구현 코드는 GitHub에 공개 중입니다: github.com/YOSHITSUGU728/automated-testing-portfolio
「조건이 6개 이상 있어서 디시전 테이블이 거대해져버린다」「조건 간에 복잡한 OR·AND·NOT의 관계가 있어서 정리할 수 없다」——이런 문제에 직면한 적이 있으신가요？
- 조건이 늘어날수록 디시전 테이블의 열이 지수적으로 증가한다
- AND·OR·NOT이 혼재한 복잡한 로직을 표로 표현하기 어렵다
- 어떤 조건의 조합이 「어떤 결과」에 대응하는지 추적할 수 없게 된다
원인결과 그래프는 이런 문제를 해결하는 기법입니다. 먼저 그래프로 인과 관계를 시각화한 후 디시전 테이블로 변환하기 때문에 복잡한 로직도 체계적으로 정리할 수 있습니다.
📌 원인결과 그래프의 포인트
- 「원인（입력 조건）→논리 연산（AND/OR/NOT）→결과（기대 동작）」를 그래프로 표현하는 테스트 설계 기법
- 그래프를 디시전 테이블로 변환함으로써 망라적인 테스트 케이스를 기계적으로 도출할 수 있다
- 디시전 테이블의 전단으로 사용함으로써 조건 6개 이상의 복잡한 로직도 정리할 수 있다
원인결과 그래프란？
원인결과 그래프（Cause-Effect Graph）란 「입력 조건（원인）과 기대 동작（결과）의 논리적 관계를 그래프 형식으로 표현하고 그 그래프에서 디시전 테이블을 도출하는 테스트 설계 기법」입니다.
1970년대에 IBM이 개발한 기법으로 ISTQB에서도 테스트 설계 기법으로 정의되어 있습니다. 디시전 테이블은 「조건의 조합을 직접 표 형식으로 정리한다」는 것에 반해 원인결과 그래프는 「먼저 인과 관계를 도표로 정리한 후 디시전 테이블로 변환한다」는 2단계 접근을 취합니다.
| 비교 항목 | 디시전 테이블 | 원인결과 그래프 |
|---|---|---|
| 접근 방식 | 조건을 직접 표로 정리 | 그래프→테이블의 2단계 |
| 조건 수의 기준 | 2〜5개 정도 | 6개 이상도 대응 가능 |
| 논리 관계의 표현 | 암묵적（행에 조건을 나열） | 명시적（AND/OR/NOT을 도표로 표현） |
| 시각적 파악 | 열이 많아지면 보기 어렵다 | 그래프로 전체상을 파악하기 쉽다 |
| 학습 비용 | 낮다（직관적） | 약간 높다（기호 습득이 필요） |
원인결과 그래프의 기본 요소란？
원인결과 그래프는 「노드（절점）」과 「링크（변）」로 구성됩니다. 논리 연산을 나타내는 기호를 익히는 것이 그래프 작성의 첫걸음입니다.
노드의 종류
| 노드 종별 | 기호 | 의미 | 예시 |
|---|---|---|---|
| 원인（Cause） | C1〜Cn | 입력 조건·전제 조건 | ID가 올바름 / 나이가 18세 이상 |
| 결과（Effect） | E1〜En | 기대되는 동작·출력 | 로그인 성공 / 에러 메시지 표시 |
| 중간 노드 | I1〜In | 복수의 원인을 논리 연산으로 묶은 중간 상태 | 「ID와 PW가 모두 올바름」등 |
논리 연산 기호의 종류
📊 원인결과 그래프의 논리 연산 기호
| 기호 | 명칭 | 의미 | 예시 |
|---|---|---|---|
| → | 항등（Identity） | 원인이 참이면 결과도 참 | C1이 참 → E1이 참 |
| ∧ | AND | 모든 원인이 참일 때만 결과가 참 | C1이면서 C2가 참 → E1이 참 |
| ∨ | OR | 어느 하나의 원인이 참이면 결과가 참 | C1 또는 C2가 참 → E1이 참 |
| ¬ | NOT | 원인이 거짓일 때만 결과가 참 | C1이 거짓 → E1이 참 |
※ 이 기호들을 조합하여 복잡한 조건 관계를 표현한다
제약 기호（Constraint）
원인 간·결과 간의 「있어서는 안 되는 조합」을 나타내는 제약 기호도 있습니다.
| 기호 | 명칭 | 의미 |
|---|---|---|
| E | 배타（Exclusive） | 동시에 참이 될 수 없다（최대 1개만 참） |
| I | 포함（Inclusive） | 적어도 1개는 참이어야 한다 |
| O | 배타적 논리합（One and only one） | 반드시 어느 하나만이 참 |
| R | 필요（Requires） | C1이 참일 때 C2도 반드시 참이어야 한다 |
| M | 마스크（Mask） | E1이 참일 때 E2는 반드시 거짓이 된다 |
원인결과 그래프의 작성법：4단계
| 스텝 | 내용 |
|---|---|
| STEP 1 | 사양서에서 「원인（입력 조건）」과 「결과（기대 동작）」를 추출한다 |
| STEP 2 | 원인과 결과를 AND/OR/NOT의 논리 연산으로 연결한 그래프를 그린다 |
| STEP 3 | 원인 간·결과 간에 제약 기호（E/I/O/R/M）를 추가한다 |
| STEP 4 | 그래프의 각 패턴을 역방향으로 읽어 디시전 테이블로 변환한다 |
실례：원인결과 그래프의 작성법과 예시（회원 할인 시스템）
EC 사이트의 할인 적용 로직을 예시로 원인결과 그래프의 작성법을 해설합니다.
사양（원인과 결과 추출）
| 종별 | 번호 | 내용 |
|---|---|---|
| 원인 | C1 | 프리미엄 회원이다 |
| 원인 | C2 | 쿠폰을 보유하고 있다 |
| 원인 | C3 | 구매 금액이 50,000원 이상이다 |
| 결과 | E1 | 프리미엄 할인（10% 할인）이 적용된다 |
| 결과 | E2 | 쿠폰 할인（5% 할인）이 적용된다 |
| 결과 | E3 | 대량 구매 할인（3% 할인）이 적용된다 |
논리 관계（그래프의 내용）
| 규칙 | 논리식 |
|---|---|
| 프리미엄 회원이면 → 프리미엄 할인 적용 | C1 → E1（항등） |
| 쿠폰 보유 AND 프리미엄 아님 → 쿠폰 할인 적용 | C2 AND ¬C1 → E2 |
| 50,000원 이상 AND 프리미엄 아님 AND 쿠폰 없음 → 대량 구매 할인 | C3 AND ¬C1 AND ¬C2 → E3 |
그래프에서 디시전 테이블로의 변환
그래프를 작성했으면 각 결과가 「True（발화）」가 되는 조건의 조합을 역방향으로 읽어 디시전 테이블로 변환합니다.
| 조건 / 결과 | C1 | C2 | C3 | C4 | C5 | C6 |
|---|---|---|---|---|---|---|
| 프리미엄 회원（C1） | Y | Y | N | N | N | N |
| 쿠폰 보유（C2） | Y | N | Y | Y | N | N |
| 50,000원 이상（C3） | – | – | Y | N | Y | N |
| → E1：프리미엄 할인 | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ |
| → E2：쿠폰 할인 | ❌ | ❌ | ✅ | ✅ | ❌ | ❌ |
| → E3：대량 구매 할인 | ❌ | ❌ | ❌ | ❌ | ✅ | ❌ |
원인결과 그래프와 디시전 테이블의 차이와 사용 구분이란？
원인결과 그래프와 디시전 테이블은 목적이 가까우므로 실무에서의 사용 구분이 중요합니다. 한 마디로 말하면 원인결과 그래프와 디시전 테이블의 차이는 「조건을 직접 표로 만드는가, 도표로 정리한 후 표로 만드는가」의 차이입니다.
| 판단 기준 | → 디시전 테이블 | → 원인결과 그래프 |
|---|---|---|
| 조건 수 | 2〜5개 | 6개 이상 |
| 논리 관계의 복잡성 | 단순한 Yes/No 조건 | AND/OR/NOT이 복잡하게 혼재 |
| 조건 간 제약 | 제약이 거의 없다 | 배타·포함 등의 제약이 많다 |
| 팀 설명 | 표로 충분히 전달된다 | 도표로 시각화하는 편이 전달하기 쉽다 |
💡 실무에서의 사용 구분 흐름
- 조건이 2〜5개 → 디시전 테이블로 직접 설계
- 조건이 6개 이상 or AND/OR/NOT이 복잡하게 혼재 → 원인결과 그래프로 그래프를 만든 후 디시전 테이블로 변환
- 최종적으로는 양쪽 기법 모두 디시전 테이블에 반영하여 테스트 케이스를 도출한다
💡 실무 예시：디시전 테이블이 파탄난 케이스
권한 관리 로직（관리자·일반 사용자·게스트 × 조작 권한 5종 × 상태 3종）을 직접 디시전 테이블로 설계하려 했더니 열이 50패턴 이상이 되어 관리 불능에.
원인결과 그래프로 로직을 정리했더니 불필요한 조건과 배타 제약의 누락이 명확해져 최종적으로 20패턴 정도까지 삭감할 수 있었습니다. 「뒤죽박죽인 조건을 그래프로 정리한 후 표에 반영한다」——이 프로세스가 있는 것만으로 설계 품질이 한 단계 올라갑니다.
적합한 케이스 / 적합하지 않은 케이스
✅ 적합한 케이스
| ✖ 적합하지 않은 케이스
|
원인결과 그래프를 그리는 도구
| 도구 | 특징 | 비용 |
|---|---|---|
| draw.io | 브라우저에서 사용 가능·VS Code 플러그인 있음·도표 내보내기 간단 | 무료 |
| Lucidchart | 팀 공유·실시간 편집·Confluence 연동 | 유료（무료 플랜 있음） |
| Miro | 화이트보드형·브레인스토밍 감각으로 그릴 수 있음·팀 향 | 유료（무료 플랜 있음） |
| Microsoft Visio | 기업 환경의 표준 도구·풍부한 도형 템플릿 | 유료 |
⚠️ 원인결과 그래프에서 자주 있는 실패 패턴 4선
실무에서 원인결과 그래프를 사용할 때 빠지기 쉬운 실패를 소개합니다.
① 조건이 적은데 원인결과 그래프를 사용하려 한다
조건이 2〜4개 정도라면 디시전 테이블로 직접 설계하는 편이 심플하고 빠릅니다. 원인결과 그래프는 「복잡한 논리 관계를 시각화하기 위한 도구」이므로 심플한 케이스에 사용하면 오히려 수고가 늘어납니다. 조건 수와 논리의 복잡성으로 사용 구분하세요.
② 제약 기호를 붙이는 것을 잊어 불가능한 테스트 케이스가 생성된다
「결제 방법：신용카드」와 「결제 방법：착불」처럼 동시에 선택할 수 없는 원인 간에 배타 제약（E）을 붙이는 것을 잊으면 실제로는 발생할 수 없는 테스트 케이스가 디시전 테이블에 혼입됩니다. 테이블로 변환한 후에는 반드시 「이 조합은 현실에서 발생하는가？」를 확인하세요.
③ 그래프만 만들고 디시전 테이블로의 변환을 생략한다
원인결과 그래프는 어디까지나 「디시전 테이블을 도출하기 위한 중간 산출물」입니다. 그래프를 만들고 만족해버려 테스트 케이스로의 변환까지 완료하지 않으면 의미가 없습니다. 그래프→디시전 테이블→테스트 케이스라는 흐름을 반드시 마지막까지 완수하세요.
④ 중간 노드를 사용하지 않아 그래프가 너무 복잡해진다
복수의 원인을 그룹화하는 「중간 노드（I）」를 사용하지 않으면 원인에서 결과로의 선이 뒤얽혀 읽기 어려운 그래프가 됩니다. 「C1이면서 C2」라는 조건을 중간 노드 I1로 묶어 I1에서 결과 E로 선을 그으면 그래프가 깔끔해집니다.
FAQ
Q. 원인결과 그래프는 언제 사용해야 하나요？
조건이 6개 이상 있다·AND/OR/NOT이 복잡하게 혼재하고 있다·조건 간에 배타나 포함 등의 제약이 있는 경우에 사용합니다. 조건이 적고 심플한 로직에는 디시전 테이블이 더 적합합니다. 「디시전 테이블을 만들려고 했더니 열이 너무 많아 정리할 수 없었다」는 때가 원인결과 그래프의 출번입니다.
Q. 원인결과 그래프와 디시전 테이블은 어느 쪽이 우수한가요？
우열은 없으며 보완 관계에 있습니다. 디시전 테이블은 심플하고 직관적·조건이 적은 경우에 적합합니다. 원인결과 그래프는 복잡한 논리 관계의 시각화·조건이 많은 경우에 적합합니다. 실무에서는 「원인결과 그래프로 정리한 후 디시전 테이블로 변환한다」는 조합이 일반적입니다.
Q. ISTQB에서 원인결과 그래프는 어느 정도 출제되나요？
ISTQB Foundation Level에서는 「원인결과 그래프의 개념·목적·디시전 테이블과의 관계」가 출제됩니다. 「원인결과 그래프는 디시전 테이블을 도출하기 위한 기법이며 원인（입력）과 결과（출력）의 논리적 관계를 그래프로 표현한다」는 이해가 있으면 대응할 수 있습니다. Advanced Level에서는 더 상세한 지식이 요구됩니다.
Q. 원인결과 그래프를 그리는 도구는 있나요？
전용 도구로는 「CTE（Classification Tree Editor）」나 「Agora Test Manager」등이 있습니다. 일반적인 다이어그램 도구라면 draw.io（무료）나 Microsoft Visio·Lucidchart에서도 작성할 수 있습니다. 실무에서는 draw.io에서 그래프를 작성하고 그 후 수동으로 디시전 테이블로 변환하는 워크플로우가 비용 대비 효과가 높아 추천합니다.
📖 관련 글
실무에서는 조건이 6개 이상 있는 복잡한 업무 로직（권한 관리·할인 규칙·심사 플로우 등）의 설계 시 원인결과 그래프를 draw.io에서 작성하고 팀 리뷰 후 디시전 테이블로 변환하는 워크플로우를 채택하고 있습니다. 그래프가 「공통 언어」가 되어 개발·QA·비즈니스 측이 같은 로직을 보면서 리뷰할 수 있다는 점이 최대의 이점입니다.
📋 이 글의 정리
- 원인결과 그래프는 「원인→논리 연산（AND/OR/NOT）→결과」의 관계를 그래프로 표현하는 테스트 설계 기법
- 그래프를 디시전 테이블로 변환함으로써 망라적인 테스트 케이스를 기계적으로 도출할 수 있다
- 조건이 6개 이상·AND/OR/NOT이 복잡하게 혼재하는 경우에 디시전 테이블의 전단으로 사용한다
- 제약 기호（E/I/O/R/M）로 「있어서는 안 되는 조합」을 명시함으로써 불가능한 테스트 케이스를 제외할 수 있다
- 최종적으로는 반드시 디시전 테이블로 변환하여 테스트 케이스를 도출하는 데까지 완수한다
원인결과 그래프는 「복잡성을 도표로 정리한 후 테스트 케이스로 변환한다」는 2단계 접근으로 디시전 테이블 단독으로는 정리할 수 없는 복잡한 로직도 체계적으로 테스트 설계할 수 있습니다. 먼저 간단한 3〜4개 조건의 로직으로 원인결과 그래프를 그려보면 이해가 한 번에 깊어집니다. 먼저 간단한 로직으로 그래프를 하나 그려보는 것이 가장 빠르게 이해하는 비결입니다.
