개발자가 떠올린 정상·예외 입력만으로는 깨진 인코딩·극단적으로 긴 문자열·공격성 입력 같은 미지의 경우를 다 검증할 수 없다는 한계에서 fuzz testing을 소개한다. 무작정 랜덤이 아니라 커버리지 피드백으로 입력을 진화시키는 coverage-guided fuzzing이 핵심이며, JVM에서 직접 돌려본 경험까지 담는다.
핵심 포인트- 사람이 가능한 입력을 다 열거할 수 없고, 완전 랜덤만으로는 깊은 조건을 통과할 확률이 낮아 핵심 코드에 도달하지 못하므로 실행 결과로 다음 입력을 개선해야 함
- coverage-guided fuzzing은 새 코드 경로를 연 입력을 유의미하다고 보고 corpus에 저장한 뒤 변형해, 실행·커버리지 확인·저장·변형을 반복하며 랜덤이 만나기 어려운 조합에 점진 접근
- JVM용 fuzzer Jazzer를 JUnit 유사 문법·데이터 provider로 기존 테스트에 결합해 블랙잭 이름 검증을 7,400만 건 실행 — 입력 수가 많아도 대상 분기가 적으면 유의미 corpus 수는 작을 수 있음을 확인
- Google OSS-Fuzz가 OpenSSL 취약점을 찾은 사례로 실전 가치를 보이며, 좋은 퍼징은 corpus 개수가 아니라 대상 코드 규모 대비 탐색한 범위와 기존 테스트가 놓친 실패 발견으로 평가해야 함
왜 읽나예제 기반 단위 테스트의 사각지대가 불안한 개발자에게, coverage-guided fuzzing의 원리와 JVM 적용법, 그리고 '커버리지로 평가하라'는 판단 기준을 준다.