05강: [QA] 복잡한 데이터 흐름 분석 및 경계값 테스트 시나리오 도출

SECTION 1. IT 실무 최적화: 왜 클로드인가? (입문)
 
• 01강: 챗GPT 대신 클로드를 선택해야 하는 이유 (아티팩트 & 20만 컨텍스트)
• 02강: IT 현업을 위한 초기 세팅: 프로젝트(Projects) 기능을 통한 도메인 지식 주입
• 03강: 프롬프트 엔지니어링 기초: IT 논리 구조를 반영한 지시 기법

SECTION 2. QA & 테스터를 위한 AI 전략 (심화)
 
• 04강: [QA] 요구사항 명세서 기반 완벽한 테스트 케이스(TC) 자동 생성
• 05강: [QA] 복잡한 데이터 흐름 분석 및 경계값 테스트 시나리오 도출
• 06강: [QA] 셀레늄/플레이라이트(Playwright) 자동화 스크립트 작성 및 오류 수정

SECTION 3. 개발 & 시스템 설계를 위한 AI 활용 (심화)
 
• 07강: [Dev] 레거시 코드 리팩토링 및 신규 라이브러리 마이그레이션 가이드
• 08강: [Dev] 에러 로그 분석을 통한 근본 원인(Root Cause) 파악 및 디버깅
• 09강: [Design] 머메이드(Mermaid)를 활용한 시퀀스 다이어그램 및 DB 설계도 그리기


SECTION 4. MCP와 자동화 에이전트로 가는 길 (실전)
 
• 10강: MCP(Model Context Protocol) 개념과 IT 도구(Notion/GitHub/Jira) 연동
• 11강: Sequential Thinking(심층 사고) 모드로 복잡한 비즈니스 로직 검증하기
• 12강: 클로드 코드(Claude Code) 입문: 터미널에서 제어하는 AI 주도 개발(ADC)

 

---

 

지난 4강에서 명세서 기반으로 테스트 케이스를 뽑아냈다면, 이번엔 그 표에서 가장 위험한 자리를 찾습니다. 버그가 가장 즐겨 숨는 두 곳, 경계와 문틈을 파고드는 법입니다.

 

4강에서 뽑아낸 테스트 케이스 표를 다시 펼쳐 보겠습니다.

 

정상 흐름, 예외 상황, 경계값, 잘못된 입력. 이렇게 네 갈래로 나누라고 했는데, 이 중에서 실제 사고가 가장 많이 숨어 있는 곳은 어딜까요.

 

짧게 대답하면, '경계값'과 '데이터가 한 상태에서 다른 상태로 넘어가는 문틈'입니다.

 

오늘은 이 두 지점을 클로드와 함께 체계적으로 캐내는 방법을 다룹니다.

 

버그는 '명백한 중간'이 아니라 '딱 그 선' 위에 숨어 있다

놀이공원에 롤러코스터를 타러 갔다고 해 보겠습니다.

 

안내판엔 "140cm 이상만 탑승 가능"이라 쓰여 있습니다.

 

180cm인 사람이 탈 수 있는지는 굳이 확인할 필요가 없습니다.

 

120cm인 아이가 못 탄다는 것도 마찬가지입니다.

 

진짜 문제는 139.9cm와 140.0cm, 140.1cm 사이에 있습니다.

 

그 선 바로 위아래에서 시스템이 올바르게 판단하는지가 핵심입니다.

 

소프트웨어 버그도 정확히 이 자리에 숨습니다.

 

개발자가 조건을 코드로 옮길 때 가장 헷갈리는 지점이기 때문입니다.

 

'이상'인지 '초과'인지, 기호 하나로 결과가 뒤집힙니다.

 

 

구역을 나누면, 경계가 어디인지 보인다

경계값 테스트를 잘 짜려면 먼저 '구역'부터 나눠야 합니다.

 

같은 결과가 나오는 값의 묶음을 동치 구역이라 부릅니다.

 

구역마다 대표 값 하나씩만 골라도 되는데, 정작 중요한 건 그 구역들이 만나는 '경계'입니다.

 

예를 들어 비밀번호를 8자 이상 20자 이하로 받는 기능이라면 세 구역이 생깁니다.

 

'너무 짧음(1~7자)',

 

'적합(8~20자)',

 

'너무 김(21자~)'.

 

이 세 구역의 경계가 7·8·9와 19·20·21, 여섯 개의 값입니다.

 

180이나 3처럼 한가운데 값은 굳이 모두 테스트할 필요가 없습니다.

 

경계 바로 안과 바로 밖, 딱 그 선을 두드리면 됩니다.

 

클로드에게 경계를 찾게 하는 프롬프트

이 작업을 손으로 하면 입력 조건이 많아질수록 빠뜨립니다.

 

클로드에게 통째로 넘기면, 조건마다 구역을 나누고 경계값을 표로 정리해 줍니다.

너는 경험 많은 QA 엔지니어야.
아래 입력 조건들을 분석해서, 각 조건의 동치 구역과 경계값을 표로 뽑아 줘.
표에는 조건명, 구역 설명, 반드시 테스트해야 할 값 목록, 예상 결과(통과/실패)를 넣어 줘.

<입력 조건>
- 비밀번호: 8자 이상 20자 이하, 특수문자 1개 이상 포함
- 나이: 만 14세 이상만 가입 가능
- 구매 수량: 1개 이상 99개 이하
</입력 조건>

 

이렇게 조건 세 개를 던지면, 각각의 경계값과 테스트해야 할 값 목록이 표 한 장으로 떨어집니다.

 

조건이 열 개, 스무 개로 늘어나도 같은 방식입니다.

 

데이터가 여러 문을 통과할 때, 문틈에서 버그가 생긴다

경계값이 '하나의 입력'에서 버그를 찾는다면, 데이터 흐름 분석은 '이동 중인 데이터'에서 버그를 찾습니다.

 

우체국에서 소포를 보내는 장면을 떠올려 보겠습니다.

 

소포는 우체국 접수 → 분류 센터 → 집배원 → 수령인 순서로 이동합니다.

 

각 단계마다 소포의 '상태'가 바뀝니다. 접수 완료, 분류 중, 배송 중, 배달 완료.

 

쇼핑몰 주문도 똑같습니다. 장바구니 → 주문 완료 → 결제 → 배송 중 → 수령. 각 문을 통과할 때마다 데이터의 상태가 바뀝니다.

 

그리고 버그는 그 문틈에 숨습니다.

 

소포가 분류 센터로 가는 도중 취소 요청이 들어오면.

 

결제가 진행되는 0.3초 사이에 환불 버튼을 누르면. 배달 완료로 처리됐는데 고객이 수령 못 했다고 신고하면.

 

 

상태 전이의 위험 지점을 클로드에게 찾게 한다

흐름이 복잡할수록 사람이 모든 문틈을 기억하기 어렵습니다.

 

클로드에게 흐름을 설명하면, 각 전환 지점에서 예외가 발생할 시나리오를 도출해 줍니다.

 

너는 꼼꼼한 QA 엔지니어야.
아래 주문 처리 흐름에서 상태가 전이되는 각 지점을 찾고,
예외·오류·충돌이 발생할 가능성이 높은 시나리오를 우선순위 높은 순서대로 도출해 줘.
각 시나리오마다 어떤 상태에서 어떤 상태로 넘어갈 때 발생하는지 명시해 줘.

<주문 흐름>
장바구니 → 주문 요청 → 재고 확인 → 결제 승인 → 배송 준비 → 배송 중 → 배달 완료
(취소는 배송 준비 전까지만 가능, 환불은 배달 완료 후 7일 이내)
</주문 흐름>

 

그러면 "결제 승인이 완료된 순간 재고가 품절로 바뀌면", "취소 요청과 배송 시작이 동시에 발생하면", "환불 7일 기한이 자정에 만료될 때 시간대가 다른 서버와 충돌하면" 같은 시나리오가 목록으로 나옵니다.

 

사람이 흐름도를 보며 직접 떠올리면 빠뜨리기 쉬운 것들입니다.

 

 

조건이 여러 개 겹칠 때, 위험한 조합을 먼저 골라낸다

실무에서는 조건이 하나인 경우가 드뭅니다.

 

VIP 등급이면서 첫 구매이고 동시에 50% 할인 쿠폰을 쓴다면, 세 조건이 한꺼번에 맞물립니다.

 

조건이 세 개면 조합은 여덟 가지, 다섯 개면 서른두 가지입니다.

 

이걸 전부 테스트하는 건 현실적으로 불가능합니다. 그래서 '가장 위험한 조합'을 먼저 골라내는 게 핵심입니다.

 

클로드에게 적용 조건과 규칙을 주고 "충돌하거나 예상치 못한 결과가 나올 조합을 우선순위 높은 순서대로 뽑아줘"라고 하면, 리스크 높은 조합부터 정렬된 목록이 나옵니다.

 

 

검증 순서를 전략적으로 잡을 수 있게 됩니다.

 

 

 

클로드는 경우의 수를 계산하고, 어디가 진짜 위험한지는 QA가 읽는다

경계값과 데이터 흐름, 두 가지를 함께 쓰면 어떻게 됩니까.

 

단순한 숫자 조건 몇 개도, 복잡한 주문 흐름도, 클로드에게 구조적으로 분석을 맡기는 순간 빠뜨리기 쉬운 지점이 목록으로 떠오릅니다.

 

그렇다고 그 목록이 정답은 아닙니다.

 

클로드는 시스템이 어떻게 만들어졌는지 모르고, 우리 서비스에서 어떤 실수가 실제로 돈이 되고 고객이 되는지도 모릅니다.

 

그래서 QA의 일은 줄어드는 게 아니라 달라집니다.

 

경우의 수를 계산하는 손에서, 어느 지점이 우리 서비스에서 진짜 위험한지 판단하는 눈으로 무게 중심이 옮겨 갑니다.

 

그 눈은 여전히 사람의 것입니다.

 

다음 6강 예고

케이스를 만들고 위험 지점을 찾아냈다면, 이제 그걸 직접 실행하는 단계입니다.

 

다음 6강 「셀레늄/플레이라이트(Playwright) 자동화 스크립트 작성 및 오류 수정」에서는, 손으로 반복 클릭하던 검증 작업을 자동화 스크립트로 넘기는 법을 다룹니다.

 

처음 작성하는 것뿐 아니라, 스크립트가 틀렸을 때 에러 메시지를 클로드에게 넘겨 원인을 파악하고 고치는 흐름까지 함께 보겠습니다.

 

※ 본 강좌는 매일 1강씩 무료로 연재됩니다. 요금제별 기능과 한도는 모델·플랜에 따라 달라질 수 있으니, 실제 적용 시 최신 안내를 확인하시기 바랍니다.