View
한 줄로 정리하면 이렇다
화이트박스와 블랙박스의 차이를 한 문장으로 압축하면, 화이트박스는 박스 안을 들여다보고 코드를 검증하는 방식이고, 블랙박스는 박스를 두드려보고 소리로 판단하는 방식이다. 이 한 문장만 머릿속에 새겨두면 90%는 이해한 것이다.
다만 이것으로 끝일 리 없다. 실무에서는 "그래서 내 프로젝트에서 어떤 것을 써야 하는가", "정보처리기사에 무엇이 출제되는가", "유닛 테스트는 어디에 속하는가", "그레이박스는 또 무엇인가" 같은 질문이 끝없이 나온다. 솔직히 검색해서 나오는 글들은 대부분 2018년경에 작성된 격식체 글이라 답답하다. JUnit만 언급되고 Vitest나 Playwright는 한 줄도 등장하지 않는다.
각설하고, 이 글에서는 화이트박스와 블랙박스 테스트의 차이부터 2026년 기준 최신 도구 매핑, 의사결정 가이드, 그레이박스의 부상, AI 시대의 변화까지 한 번에 정리한다. 신입 QA, 정보처리기사 준비생, 2~5년차 백엔드 개발자가 모두 커버되도록 구성했으므로 자기 위치에서 필요한 부분만 골라 읽어도 된다.
화이트박스 테스트란 무엇인가
출처: testingdocs.com
정의: 코드 내부 구조를 보고 테스트하는 방식이다
화이트박스 테스트는 말 그대로 소스 코드 내부를 모두 들여다보고 테스트 케이스를 작성하는 방식이다. "구조 기반 테스트(Structural Testing)" 또는 "글래스박스(Glass-box) 테스트"라고도 부른다. 어차피 박스가 투명해서 내부가 모두 보인다.
핵심은 단순하다. 코드의 분기문(if, switch), 반복문(for, while), 조건식 하나하나가 모두 의도대로 동작하는지 검증하는 것이다. 함수 하나에 if-else가 5개 있다면 그 5개 분기를 모두 밟아보는 것이 목표이다.
누가 수행하는가: 개발자가 직접 한다
화이트박스는 개발자 본인이 작성하는 것이 정석이다. QA가 코드 내부까지 모두 알 수는 없다. 따라서 단위 테스트(Unit Test), TDD(Test-Driven Development) 같은 개발자 주도 테스트는 모두 화이트박스 카테고리에 속한다.
신입 백엔드 개발자가 입사하자마자 마주하는 것이 "테스트 코드가 없는 PR은 머지되지 않는다"는 룰인데, 이는 사실상 화이트박스 강제이다. JUnit이든 pytest이든 본질은 동일하다.
대표 기법: 커버리지 종류 정리
화이트박스 테스트에서 가장 많이 사용하는 지표는 코드 커버리지(Code Coverage) 인데, 종류별로 깊이가 다르다.
- 문장 커버리지(Statement Coverage): 코드의 모든 라인이 한 번씩은 실행됐는지 확인한다. 가장 약한 기준이다.
- 분기 커버리지(Branch Coverage): 모든 if/else 분기가 모두 밟혔는지 확인한다. 일반적으로 80% 이상이 권장된다.
- 조건 커버리지(Condition Coverage): 복합 조건문(a && b)에서 각 조건이 true/false로 모두 평가됐는지 확인한다.
- 경로 커버리지(Path Coverage): 가능한 모든 실행 경로를 밟는다. 이론적으로 가장 강하지만 경로가 폭발적으로 늘어나기 때문에 현실적으로 100%는 불가능하다.
도구: 2026년 기준 실무 스택
옛날 글들은 JUnit만 언급하지만, 요즘 실무에서는 다음과 같이 사용한다.
| 언어/스택 | 도구 |
| Java | JUnit 5 (`@ParameterizedTest`, `@Nested`), Mockito |
| Python | pytest, pytest-cov, unittest |
| JavaScript/TypeScript | Vitest, Jest, Mocha |
| C/C++ | gcov, lcov, Google Test |
| Go | 내장 `testing` 패키지, testify |
| Rust | 내장 `cargo test`, mockall |
특히 프론트엔드 진영은 Vitest로 거의 모두 갈아탔다. Jest가 느리기 때문에 갈아탄 것이다. Storybook 인터랙션 테스트도 컴포넌트 내부 상태를 모두 들여다보는 것이라 화이트박스 영역에 가깝다.
블랙박스 테스트란 또 무엇인가
출처: techtarget.com
정의: 입력과 출력만 보고 테스트하는 방식이다
블랙박스는 반대로 코드를 한 줄도 보지 않고 입력값과 기대 출력값만 가지고 테스트하는 방식이다. "명세 기반 테스트(Specification-based Testing)" 또는 "행위 기반 테스트(Behavioral Testing)"라고도 부른다.
박스가 검정색이라 내부가 보이지 않으므로 그저 두드려보고 소리로 판단하는 것이다. 입력 X를 넣었더니 Y가 나오는가? 그렇다면 통과이다. 나오지 않는가? 그렇다면 결함이다.
누가 수행하는가: QA 엔지니어가 한다
블랙박스는 QA 엔지니어 영역이다. 다만 실제로는 PM도 하고, CS팀 인원도 하고, 베타 유저도 한다. 코드를 몰라도 수행할 수 있다는 점이 핵심이라 진입 장벽이 낮다.
요즘은 SDET(Software Development Engineer in Test)라는 포지션이 부상하고 있는데, 이쪽은 블랙박스 자동화를 코드로 작성하는 사람들이다. 즉 블랙박스 테스트라고 해서 무조건 사람의 손으로 클릭하는 것은 아니다.
대표 기법: 4대장만 알면 된다
블랙박스 기법은 매우 다양하지만 실무에서 자주 쓰는 것은 4가지이다.
- 동치 분할(Equivalence Partitioning): 입력값을 비슷하게 동작할 그룹으로 묶고 그룹당 1개씩만 테스트한다. 1~100을 입력받는다면 -10, 50, 200 이렇게 3개로 충분하다.
- 경계값 분석(Boundary Value Analysis): 경계 근처에서 버그가 잘 발생하므로 경계값 ± 1을 집중적으로 테스트한다. 0, 1, 99, 100, 101 같은 식이다.
- 의사결정 테이블(Decision Table): 조건 조합이 많을 때 표로 정리해서 누락 없이 커버한다. 보험 계산 같은 비즈니스 로직에 강하다.
- 상태 전이(State Transition): 로그인/로그아웃, 결제 진행 같은 상태 흐름을 테스트한다.
도구: API/UI 자동화 스택
| 영역 | 도구 |
| API 테스트 | Postman, Newman, REST Assured, Bruno |
| 웹 E2E | Playwright, Cypress, Selenium WebDriver |
| 모바일 | Appium, Detox |
| 부하/성능 | k6, JMeter, Locust |
| 시각 회귀 | Percy, Chromatic |
Selenium은 솔직히 한물갔고, Playwright가 진정한 대세이다. Cypress도 쓸만하지만 멀티탭이 되지 않는 점이 치명적이라 신규 프로젝트는 Playwright로 가는 것이 맞다.
화이트박스와 블랙박스의 차이를 한 표로 깔끔하게 정리한다
출처: codment.com
비교표 하나로 정리되니 머릿속에 새겨두면 좋다.
| 비교 항목 | 화이트박스 | 블랙박스 |
| 보는 대상 | 코드 내부 구조 | 입출력 동작 |
| 다른 이름 | 구조 기반, 글래스박스 | 명세 기반, 행위 기반 |
| 주체 | 개발자 | QA 엔지니어, 사용자 |
| 시점 | 단위·통합 단계 (초기) | 시스템·인수 단계 (후기) |
| 필요 지식 | 프로그래밍 | 도메인·요구사항 |
| 비용 | 높음 (시간·기술 인건비) | 낮음 (확장 쉬움) |
| 자동화 | 매우 쉬움 | 도구 의존, 중간 |
| 발견 결함 | 로직·분기 누락, 경계 처리 | 요구사항 미충족, UX 문제 |
| 대표 도구 | JUnit, pytest, Vitest | Playwright, Postman, Cypress |
| V-모델 위치 | 우측 하단 (단위·통합) | 우측 상단 (시스템·인수) |
이 표가 사실상 글의 핵심이다. 면접에서 화이트박스와 블랙박스의 차이를 묻는다면 이 표를 머릿속에서 그려서 5개 항목만 줄줄 읊어도 충분하다.
그래서 언제 어떤 것을 써야 하는가 (의사결정 가이드)
출처: nextstruggle.com
이것이 기존 상위 콘텐츠가 모두 빠뜨린 부분이다. 정의만 줄줄이 늘어놓고 "둘 다 필요하다"로 끝내는데, 그것은 답이 아니다. 상황별로 구체적으로 정리한다.
신규 라이브러리·백엔드 로직이라면 화이트박스가 우선이다
API 서버를 새로 작성하거나 결제 모듈을 새로 만든다면 — 이런 케이스는 화이트박스부터 깔고 가야 한다. 이유는 단순하다. 로직이 복잡하고, 분기가 많으며, 한 번 망가지면 디버깅 비용이 천정부지로 치솟는다.
JUnit이나 pytest로 단위 테스트부터 작성하고, 분기 커버리지 80%를 깔고, 통합 테스트를 추가하는 순서이다.
사용자 시나리오·UI·API 계약이라면 블랙박스가 우선이다
프론트엔드 화면 검증, 결제 플로우 E2E, 외부 API 계약 테스트 — 이는 블랙박스가 압도적으로 효율적이다. 코드를 들여다본다고 해도 사용자 경험은 나오지 않는다.
Playwright로 회원가입부터 결제까지 시나리오를 자동화하고, Postman으로 API 응답 스펙을 검증하는 식이다.
레거시 시스템이라면 블랙박스로 안전망 → 화이트박스로 리팩토링
10년 묵은 코드를 떠안았을 때가 진정한 골칫거리이다. 코드를 모르니 화이트박스를 작성하지 못하고, 그렇다고 고치지 않을 수도 없는 상황이다. 정석은 다음과 같다.
- 블랙박스 회귀 테스트로 현재 동작을 잠가둔다: "지금 이 입력에 이 출력이 나온다"는 케이스를 모두 잡아 자동화한다.
- 그 위에서 천천히 리팩토링한다: 동작이 깨지면 회귀 테스트가 빨간불을 켠다.
- 리팩토링하면서 화이트박스를 추가한다: 이해한 모듈부터 단위 테스트를 깐다.
이는 마이클 페더스의 「레거시 코드 활용 전략(Working Effectively with Legacy Code)」에 등장하는 정석 패턴이다.
CI/CD 통합 관점에서 분리한다
GitHub Actions에서 테스트를 분리할 때는 보통 다음과 같이 작성한다.
jobs:
unit-test: # 화이트박스, 30초 안에 끝남
runs-on: ubuntu-latest
steps:
- run: pytest tests/unit --cov
integration-test: # 그레이박스, 2~3분
runs-on: ubuntu-latest
steps:
- run: pytest tests/integration
e2e-test: # 블랙박스, 5~10분
runs-on: ubuntu-latest
steps:
- run: npx playwright test
빠른 피드백을 위해 화이트박스는 PR을 올릴 때마다 돌리고, 무거운 블랙박스 E2E는 머지 직전이나 nightly로 돌리는 것이 보통이다.
그레이박스 테스트라는 것도 있다 (현대 트렌드)
출처: hypertest.co
정의: 일부 내부 정보만 알고 테스트한다
그레이박스는 이름 그대로 반쯤 투명한 박스이다. 코드 전부는 보지 않고, 일부 내부 정보만 알고 테스트하는 방식이다. 예를 들어 DB 스키마는 알지만 비즈니스 로직 코드는 보지 않는 식이다.
왜 부상했는가: 마이크로서비스·API 시대의 현실
옛날에는 모놀리식 앱이라 화이트박스 vs 블랙박스의 이분법이 깔끔하게 맞아떨어졌지만, 마이크로서비스 시대에 들어서면서 그레이박스가 사실상 표준이 되었다. 왜일까? 다른 팀이 만든 서비스를 호출해야 하는데, 그 코드는 볼 수 없고 API 명세와 DB 스키마만 보기 때문이다. 이것이 정확히 그레이박스 상황이다.
실제 사례: API 호출 + DB 상태 확인
전형적인 그레이박스 통합 테스트는 다음과 같다.
def test_order_creation():
# 블랙박스 영역: API 호출
response = client.post("/orders", json={"item_id": 42, "qty": 2})
assert response.status_code == 201
# 그레이박스 영역: DB 직접 조회로 부수효과 검증
order = db.query("SELECT * FROM orders WHERE id = ?", response.json()["id"])
assert order["status"] == "pending"
assert order["stock_decremented"] is True
API 응답만 본다면 블랙박스이지만, DB까지 들여다보고 부수효과를 확인하므로 그레이박스이다. 요즘 통합 테스트는 거의 모두 이 패턴이다.
AI 시대에 이 구분이 아직 의미가 있는가
이 부분은 다른 한국어 글에 거의 없는 내용이라 좀 더 자세히 다룬다.
GitHub Copilot, Cursor, Codeium 같은 AI 페어 프로그래밍 도구가 일반화되면서 테스트 환경도 많이 바뀌었다. 직접 사용해본 입장에서 정리하면 다음과 같다.
AI가 잘하는 영역 — 화이트박스 자동 생성
함수 하나를 던져주고 "이 함수의 단위 테스트를 작성해달라"고 지시하면 정말로 잘 작성한다. 분기, 경계값, null 처리를 모두 자동으로 잡아준다. 화이트박스 테스트는 사실상 보일러플레이트성 노동인데, 이를 AI가 거의 90%까지 처리한다. 개발자는 검토만 하면 된다.
AI가 약한 영역 — 블랙박스 시나리오 설계
다만 블랙박스는 다소 다르다. "결제 플로우 E2E 테스트를 작성해달라"고 지시하면 일반적인 패턴은 작성해주지만, 도메인 특수성이나 사용자 행동 엣지케이스는 잡지 못한다. 예를 들어 "한국 카드사 3D Secure 인증 도중 새 탭으로 빠져나갔다가 돌아오면 결제는 어떻게 처리되는가" 같은 것이다. 이는 도메인 지식 없이는 시나리오 설계 자체가 불가능하다.
결론: AI는 화이트박스 자동화의 강력한 보조 도구이고, 블랙박스는 여전히 사람의 도메인 지식이 핵심이다. 따라서 신입 개발자에게는 "화이트박스는 AI에게 맡기고, 대신 블랙박스 시나리오를 설계하는 능력을 키워라"가 진정한 실용 조언이다.
자주 받는 질문 정리
정보처리기사에 무엇이 출제되는가
정보처리기사 시험에서 화이트박스와 블랙박스의 차이는 거의 매년 출제된다. 핵심 출제 포인트는 다음과 같다.
- 블랙박스 기법명 암기: 동치 분할, 경계값 분석, 원인-결과 그래프, 의사결정 테이블, 상태 전이.
- 화이트박스 기법명: 기초 경로, 조건 검사, 데이터 흐름, 루프 검사.
- 커버리지 종류 순서: 문장 < 분기 < 조건 < 다중 조건 < 경로.
이 셋만 외워도 객관식은 거의 모두 맞힐 수 있다.
코드 커버리지는 몇 %가 적당한가
업계 일반적인 권장치는 다음과 같다.
- 분기 커버리지 70~80%: 일반적인 비즈니스 로직.
- 80~90%: 결제, 인증 같은 핵심 도메인.
- 90% 이상: 의료·금융 같은 안전 중요 시스템.
100%는 권장하지 않는다. 마지막 10%를 채우려고 의미 없는 테스트를 작성하다가 유지보수 비용만 폭발한다. 구글도 60% 정도면 충분하다고 공식적으로 언급한 바 있다.
유닛 테스트는 화이트박스인가 블랙박스인가
원칙적으로는 화이트박스에 가깝지만, 실무에서는 다소 모호하다.
- 함수 내부 구조를 보고 분기를 모두 커버하면 → 화이트박스
- 함수의 입출력 명세만 보고 작성하면 → 블랙박스
- 보통은 둘이 섞인다 → 그레이박스
TDD로 작성한 단위 테스트는 사실상 명세 기반이라 블랙박스 성격이 강하고, 커버리지를 채우려고 추가하는 단위 테스트는 화이트박스이다. 면접 질문을 받는다면 "둘 다 가능하지만 보통은 화이트박스로 분류한다" 정도가 무난한 답이다.
ISTQB 자격증 준비라면 어디에 더 비중을 두어야 하는가
ISTQB Foundation Level은 블랙박스 기법 비중이 압도적으로 높다. 동치 분할, 경계값 분석, 의사결정 테이블, 상태 전이, 유스케이스 테스트 같은 것들이 모두 블랙박스이다. 화이트박스는 커버리지 종류 정도만 깊이 있게 다룬다.
따라서 ISTQB 준비생은 블랙박스 4대장(동치 분할, 경계값, 의사결정 테이블, 상태 전이)부터 확실히 외우면 된다.
TDD는 어디에 속하는가
TDD는 "실패하는 테스트 먼저 → 통과하는 코드 작성 → 리팩토링" 사이클인데, 테스트를 먼저 작성하는 시점에는 구현 코드가 없으므로 명세 기반이다. 따라서 엄밀히 말하면 블랙박스에 가깝다.
다만 사이클이 돌면서 구현이 생기고 난 뒤에는 화이트박스적 보강이 들어간다. 따라서 TDD = 블랙박스 시작 + 화이트박스 보강의 하이브리드라고 보면 정확하다.
화이트박스와 블랙박스의 차이, 핵심 5포인트로 압축 정리
여기까지 화이트박스와 블랙박스의 차이부터 그레이박스, AI 시대 변화, FAQ까지 모두 다루었다. 핵심만 5포인트로 다시 정리하면 다음과 같다.
- 화이트박스 = 코드 들여다보기, 블랙박스 = 입출력만 보기. 이것이 본질이다.
- 개발자는 화이트박스(JUnit/pytest/Vitest), QA는 블랙박스(Playwright/Postman) 가 정석 분담이다.
- 현실은 그레이박스가 표준이다. 마이크로서비스 시대에 순수 화이트/블랙은 거의 존재하지 않는다.
- 신규는 화이트박스부터, 레거시는 블랙박스부터. 상황별 우선순위가 다르다.
- AI는 화이트박스 자동화에 강하고, 블랙박스 시나리오 설계는 여전히 사람의 몫이다.
실무에서는 보통 단위 테스트 70 : E2E 30 또는 단위 50 : 통합 30 : E2E 20 비율로 섞어 쓴다. 이 비율이 왜 이렇게 도출되는지는 "테스트 피라미드" 개념에서 다루는데, 그것은 다음 글에서 따로 정리하기로 했으므로 궁금하다면 그쪽을 보기 바란다.
그리고 신입 개발자라면 일단 자기 PR에 단위 테스트 하나라도 붙이는 습관부터 들이는 것이 진정으로 중요하다. 화이트박스와 블랙박스 이론을 백날 외워봐야 PR에 테스트 코드가 0줄이라면 의미가 없다. 오늘부터 한 줄이라도 작성해보기 바란다.
'개발 방법론' 카테고리의 다른 글
| Matt Pocock이 TDD 스킬에서 Mock 대신 실제 연결을 좋은 테스트라고 하였을까? (1) | 2026.05.02 |
|---|---|
| 비관적 락 vs 낙관적 락, 언제 어느 것을 써야 하는가 (0) | 2026.04.30 |
| 개발자가 PRD 잘 쓰는 법 정리 (작성하지 않으면 왜 실패하는가) (0) | 2026.04.30 |
| Gartner TIME 모델로 레거시 앱을 어떻게 처리할지 결정하는 방법 (유지·투자·이전·폐기) (0) | 2026.04.23 |
