동등 분할 (Equivalence Partitioning) 및 경계값 분석 (BVA)

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

본질: 동등 분할(Equivalence Partitioning)과 경계값 분석(Boundary Value Analysis, BVA)은 소프트웨어 내부 구조를 보지 않고 요구사항 명세서만으로 테스트 케이스를 도출하는 블랙박스 테스트(Black-box Testing)의 가장 대표적이고 기초적인 설계 기법이다.

가치: 무한대에 가까운 모든 입력값을 일일이 테스트하는 것(Exhaustive Testing)은 불가능하므로, 수학적/논리적으로 "같은 결과를 낼 것으로 예상되는 그룹(동등 클래스)"을 묶어 각 그룹에서 대푯값 하나만 추출하여 최소한의 테스트 케이스로 최대의 결함 발견율(Coverage)을 확보하는 극강의 가성비 기법이다.

융합: 동등 분할이 '넓은 숲'을 대충 훑어본다면, 경계값 분석은 결함이 가장 자주 숨어있는 '그룹과 그룹 사이의 경계선(Edge)'을 현미경으로 파고드는 상호 보완적 융합 기법이며, 이 두 기법은 TDD(테스트 주도 개발) 작성 시 Assert 문을 짤 때 개발자의 본능적인 사고 회로로 작용해야 한다.

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

개념: 동등 분할은 입력값의 도메인을 유효한 값(Valid)과 유효하지 않은 값(Invalid)의 여러 덩어리(클래스)로 나눈 뒤, 각 덩어리에서 딱 1개의 대푯값만 뽑아 테스트하는 기법이다. 경계값 분석은 동등 분할의 맹점을 보완하여, 덩어리가 나뉘는 '경계선(Boundary)'에 위치한 값들(최대값, 최소값, 바로 옆값)을 콕 집어서 추가로 테스트하는 기법이다.
필요성: 비밀번호를 8~12자리로 입력해야 하는 가입 창이 있다. 8자리, 9자리, 10자리, 11자리, 12자리, 그리고 1~7자리, 13~100자리까지 모든 경우의 수(문자열 조합)를 테스트하려면 우주가 멸망할 때까지 테스트해도 모자란다(완벽한 테스팅의 불가능성). 테스터는 "9자리나 10자리나 어차피 로직이 똑같이 동작할 텐데 굳이 두 번 다 테스트할 필요가 있나?"라는 철학적 질문을 던졌고, 그 결과 수학의 '동치류(Equivalence Class)' 개념을 차용하여 똑똑하게 1개의 값만 솎아내는 설계법을 발명했다.
💡 비유: 당신이 놀이공원 매표소 알바생입니다. 키가 120cm 이상~150cm 이하인 아이만 청룡열차를 탈 수 있습니다.
- 무식한 테스팅: 키 120cm인 아이부터 150cm인 아이까지 31명을 1cm 단위로 다 데려와서 탑승이 되는지 한 명씩 표를 찍어봅니다. (불가능)
- 동등 분할 (숲): "안 되는 그룹(100cm), 되는 그룹(135cm), 안 되는 그룹(160cm)" 딱 3명만 뽑아서 검사합니다.
- 경계값 분석 (나무): "경계에 있는 애들이 헷갈리지! 119cm(안됨), 120cm(됨), 150cm(됨), 151cm(안됨)" 딱 4명을 추가로 검사하여 알바생이 <= 기호를 <로 잘못 썼는지(버그) 찾아냅니다.
등장 배경 및 발전 과정:
1. 주먹구구식 테스팅 시대: 개발자가 그냥 자기가 좋아하는 숫자나 글자 몇 개 넣어보고 "돌아가네!" 하고 배포하던 시절, 운영에서 치명적 에러(Index Out of Bounds 등)가 속출했다.
2. 명세 기반 (블랙박스) 기법의 체계화: 1970년대 마이어스(Glenford J. Myers) 등의 학자들이 소프트웨어 테스팅을 공학의 반열에 올리며, 수학적 집합론을 기반으로 입력 도메인을 분할하는 이론을 정립했다.
3. 자동화와의 결합: 현대에는 이 두 기법의 논리를 기반으로, 속성 기반 테스트(Property-based Testing) 도구들이 스스로 경계값과 동등 분할 대푯값을 수백 개 자동 생성하여(Fuzzing) 코드를 폭격하는 수준으로 발전했다.
📢 섹션 요약 비유: 지뢰밭(결함)을 건널 때, 온 땅을 바늘로 다 찔러보는 대신 "이 구역은 흙 색깔이 같으니 여기 한 번만 찌르고, 지뢰가 제일 많이 묻혀있는 색깔이 바뀌는 경계선 주변은 촘촘하게 세 번 찌른다"는 생존 확률이 가장 높은 효율적인 지뢰 탐지 전술입니다.

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

기법 1: 동등 분할 (Equivalence Partitioning) 원리

**"하나가 성공/실패하면 그 그룹의 나머지도 다 똑같이 성공/실패할 것이다"**라는 가정을 전제로 한다.

예제: 회원 나이는 1살 ~ 100살 사이만 입력받는다.
유효 동등 클래스 (Valid): [1 ~ 100] ─▶ 대푯값: 35 (테스트 1번)
무효 동등 클래스 (Invalid): [0 이하] ─▶ 대푯값: -5 (테스트 1번)
무효 동등 클래스 (Invalid): [101 이상] ─▶ 대푯값: 150 (테스트 1번)
결론: 무한대의 숫자 중 딱 3개의 테스트 케이스만으로 나이 입력 폼 검증 완료.

기법 2: 경계값 분석 (Boundary Value Analysis, BVA) 원리

경험상 프로그래머들이 > 와 >= 를 헷갈리거나 루프를 한 번 더/덜 도는 오프-바이-원(Off-by-one) 에러를 가장 많이 내는 곳이 바로 '경계선'이다. 경계값 분석은 동등 분할로 찾은 경계의 최소값(Min), 최대값(Max), 그리고 그 **바로 바깥값(Min-1, Max+1)**을 집요하게 테스트한다.

예제: 위 나이 조건(1~100살)에 대한 2-Value(경계당 2개 값) 경계값 분석.
하한 경계 (Lower Boundary):
- 0 (Invalid: 최소값 바로 아래)
- 1 (Valid: 최소값)
상한 경계 (Upper Boundary):
- 100 (Valid: 최대값)
- 101 (Invalid: 최대값 바로 위)
결론: 총 4개의 케이스가 추가되며, 동등 분할의 맹점(개발자가 코드를 if (age > 1 && age < 100) 으로 잘못 짠 경우)을 완벽하게 잡아낸다.

  ┌───────────────────────────────────────────────────────────────┐
  │        동등 분할과 경계값 분석의 시각적 맵핑 (1~100 입력 조건)        │
  ├───────────────────────────────────────────────────────────────┤
  │                                                               │
  │        Invalid (무효)   │      Valid (유효)     │  Invalid (무효)  │
  │  ──────────────────────┼───────────────────────┼───────────────── │
  │                        │                       │                  │
  │              [ 0 ] ◀──┼─▶ [ 1 ]             [ 100 ] ◀──┼─▶ [ 101 ]│
  │   (경계값)              │                       │                  │
  │                        │                       │                  │
  │         (-5)           │         (35)          │       (150)      │
  │      동등분할(대푯값)      │      동등분할(대푯값)      │    동등분할(대푯값)   │
  │                        │                       │                  │
  └───────────────────────────────────────────────────────────────┘

[다이어그램 해설] 하나의 입력 폼에 대해, 동등 분할은 집합의 '중앙'에 있는 아무 숫자(-5, 35, 150)를 뽑아 뼈대를 잡는다. 반면 경계값 분석은 개발자의 실수가 가장 잦은 집합의 '테두리'에 해당하는 숫자(0, 1, 100, 101)를 핀셋으로 집어낸다. ISTQB 표준 실무에서는 이 두 기법을 독립적으로 쓰지 않고 항상 "동등 분할을 먼저 해서 구역을 나누고 ─▶ 그 구역의 테두리를 경계값 분석으로 마무리하는" 결합형(Hybrid) 설계를 기본 문법으로 삼는다.

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

실무 시나리오

시나리오 — 오프-바이-원(Off-by-one) 에러와 대형 장애: 이커머스에서 "10만 원 이상 구매 시 1만 원 쿠폰 지급" 이벤트를 걸었다. 그런데 딱 100,000원 치를 산 고객 수만 명이 쿠폰을 못 받았다고 고객센터에 불을 지른 상황.
- 판단: QA가 동등 분할만 맹신한 탓이다. QA는 "5만 원(Invalid), 15만 원(Valid)"으로 2건만 테스트하고 통과시켰다. 하지만 개발자는 if (price > 100000) 이라고 코딩해버린 치명적 버그가 숨어 있었다.
- 해결책: 기획서의 "이상(>=)"이라는 단어는 철저한 경계값 분석의 대상이다. 99,999원(Invalid)과 100,000원(Valid) 두 가지 케이스를 단위 테스트(JUnit) Assert 문으로 강제 추가하여, 경계선에서 발생하는 논리적 연산자 오류를 배포 전에 완벽히 틀어막아야 한다.
시나리오 — 다중 파라미터 조합 폭발(Combinatorial Explosion)의 함정: 비밀번호 조건이 "① 8~12자리, ② 특수문자 포함, ③ 영문 대소문자 혼용" 3가지다. 이 3가지 조건을 동등 분할과 경계값 분석으로 조합했더니 테스트 케이스가 500개로 폭증하여 QA 일정이 일주일 밀려버렸다.
- 판단: 각 변수의 유효/무효 케이스를 기계적으로 모두 곱(N x M)하면 테스트 폭발이 일어난다. 이는 테스트의 "효율성(가성비)"을 추구하는 기법의 원래 목적에 위배된다.
- 해결책: 페어와이즈 테스팅(Pairwise Testing / 직교 배열) 같은 조합 최적화 기법을 도입해야 한다. 또한 무효 값(Invalid)을 조합할 때는 "여러 개의 조건을 동시에 어긴 값(예: 7자리면서 특수문자 없음)" 1개로 뭉뚱그려 치는 것이 아니라, "나머지는 다 유효하게 두고 오직 하나의 조건만 무효(Invalid)로 둔 채" 검사하는 Single Fault Assumption (단일 결함 가정) 원칙을 지켜야만 500개의 스크립트를 20개 이내로 예쁘게 가지치기(Pruning)할 수 있다.

도입 체크리스트

요구사항 리뷰적: 기획 문서에 "10명까지 허용", "0 이상의 정수" 같은 제약 조건이 텍스트로 명시되어 있는가? (기획서에 숫자와 제약이 없다면 동등 분할과 경계값 분석은 시작조차 할 수 없다. 즉, 블랙박스 테스트 설계의 어려움은 90% 이상 '기획서의 모호함'에서 기인한다.)
코드 기반 검증: 블랙박스 기법으로 짠 테스트 케이스가 실제 소스 코드의 **분기 커버리지(Branch Coverage)**를 100% 덮었는가? (JaCoCo 등으로 확인해 보면, 경계값 2개만 넣어도 코드의 if-else 분기 커버리지가 거의 100%에 도달하는 마법을 볼 수 있다.)

Ⅳ. 기대효과 및 결론

정량/정성 기대효과

구분	짐작/직관 기반 애드혹(Ad-hoc) 테스트	동등 분할 + 경계값 분석 (체계적 설계)	개선 효과
정량 (케이스 수)	막연한 두려움에 무의미한 중복 케이스 100개 양산	수학적으로 걸러낸 핵심 정예 케이스 10개 도출	무의미한 테스트 시간 및 코드 작성량 90% 절감
정량 (결함 탐지율)	정작 경계선에 있는 치명적 버그는 못 잡음	`>` 와 `>=` 의 오프바이원 에러 집중 타격	조건문/루프문 관련 심각한 운영 버그 원천 차단
정성 (테스트 자산화)	"이 값을 왜 넣었어?" 설명 불가 (휘발성 지식)	"무효 동등 분할의 하한 경계값입니다" 증명	테스터의 행동에 논리적 근거를 부여하는 전문성 획득

동등 분할과 경계값 분석은 소프트웨어 테스팅의 구구단이다. 너무 기초적이라 무시당하기 일쑤지만, 실리콘밸리 천재 개발자들의 서버를 다운시키는 가장 치명적인 버그의 절반 이상은 if (index <= length)를 if (index < length)로 잘못 쓴 사소한 1바이트짜리 경계값 버그들이다. 기술사는 아무리 AI가 코드를 짜고 오토스케일링이 돌아가는 클라우드 시대라 하더라도, 데이터 도메인의 경계를 찢고 분석하는 이 고전적이고 수학적인 사고방식을 TDD(테스트 주도 개발)의 근간으로 강력하게 훈련시켜야 한다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
블랙박스 테스트 (Black-box Testing)	소스 코드 내부(if, for 문)를 까보지 않고, 오직 요구사항 명세서의 입출력 제약 조건만 보고 테스트 케이스를 짜는 기법으로, 동등 분할과 경계값 분석의 모체다.
화이트박스 테스트 (White-box Testing)	반대로 소스 코드를 까보고 짠다. 하지만 블랙박스(동등/경계값)로 짠 10개의 테스트가 화이트박스의 '분기 커버리지' 100%를 달성하는 상호 보완적 시너지가 발생한다.
오프-바이-원 에러 (Off-by-one Error)	반복문이나 배열 인덱스 등에서 딱 '1'만큼 크게 하거나 작게 해서 시스템이 터지는 가장 흔한 논리 버그. 경계값 분석이 잡아내야 할 1순위 타겟이다.
페어와이즈 (Pairwise Testing)	동등 분할 덩어리들을 막 조합하다가 수백 개의 테스트가 나오는 것을 막기 위해, "모든 쌍(Pair)은 최소한 1번씩 테스트한다"는 직교 배열 수학을 쓴 최적화 기법이다.
결정 테이블 (Decision Table Testing)	동등 분할은 입력 변수가 1~2개일 때 유용하지만, 입력 변수가 여러 개이고 꼬여있을 때 진리표(Truth Table)를 그려 규칙을 묶어내는 한 차원 높은 블랙박스 기법이다.

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

선생님이 "이번 소풍은 8살부터 12살까지만 올 수 있어!"라고 했어요. 어떤 아이가 갈 수 있는지 1부터 100살까지 100번 다 검사하려면 너무 힘들겠죠?
그래서 똑똑한 친구가 반을 3개로 나눴어요(동등 분할). "너무 어린 반(5살), 딱 맞는 반(10살), 너무 많은 반(20살)에서 한 명씩만 뽑아서 검사하자!"
그런데 "어? 7살이랑 8살, 12살이랑 13살은 엄청 헷갈리는데?" 싶어서 그 경계에 있는 4명의 나이(7, 8, 12, 13살)만 추가로 딱 찝어서 검사하는(경계값 분석) 엄청나게 효율적이고 완벽한 검사 방법이랍니다!