테스트 관점은 '뽑아내는 것'보다 '깎아내는 것'이 더 어렵다.

지난 기사에서 '테스트 관점을 작성하는 방법'을 소개했습니다. 화면 요소를 열거하거나, 사양서에서 명사와 동사를 추출하거나, AI와 대화(Wall-hitting)하는 방법입니다. 이것만으로도 '뽑아내는 것'은 가능해집니다.

하지만, 뽑아낸 관점을 전부 테스트할 수 있습니까?

시험 삼아 Claude에게 "EC 사이트의 결제 기능 테스트 관점을 뽑아줘"라고 던져보세요. 100개 정도는 아무렇지도 않게 나옵니다. 정상계, 이상계, 경계값, 보안, 퍼포먼스, 접근성, 다통화 대응, 타임존…….

전부 테스트하는 것은 불가능합니다. 애초에 전부 테스트할 필요도 없습니다.

요리와 비슷합니다. 냉장고의 식재료를 전부 사용하면 맛있는 요리가 될까요? 그렇지 않습니다. 무엇을 사용하고 무엇을 사용하지 않을 것인가. 그 판단이 요리사의 실력입니다. 테스트 설계도 마찬가지로, AI가 뽑아낸 100개의 관점에서 35개로 압축하는 '뺄셈'이야말로 테스트 설계자의 실력을 보여줄 기회입니다.

Step 1: AI에게 테스트 관점을 뽑게 하기

이 기사에서는 자동 테스트(UT/IT/E2E)와 수동 테스트가 모두 존재하는 프로젝트를 전제로 합니다. 이후 단계에서 "이것은 UT로 커버할 수 있으니 수동 테스트에서는 제외한다"와 같은 판단이 나오기 때문에 미리 말씀드립니다.

먼저 덧셈의 단계입니다. 여기는 AI의 독무대입니다.

전달할 것을 준비하기

AI에게 "테스트 관점을 뽑아줘"라고만 던지면, 일반적이고 얕은 관점만 돌아옵니다. 정밀도를 높이려면 컨텍스트(Context)를 전달하는 것이 중요합니다.

전부를 갖출 필요는 없습니다. 있는 것을 전달하면 됩니다. 다만, 아무것도 전달하지 않고 "테스트 관점을 뽑아줘"라고 던지는 것은 NG입니다. 컨텍스트가 없는 관점은 교과서의 목차와 다를 바 없습니다.

프롬프트 예시

다음은 EC 사이트의 결제 기능 사양입니다.
이 기능의 테스트 관점을 대·중·소 3층 구조로 망라하여 뽑아주세요.
각 관점에는 리스크 레벨(고/중/저)도 붙여주세요.
...

나오는 관점의 예 (발췌)

이렇게 던지면 다음과 같은 관점이 나옵니다.

실제로는 이 3배 정도 나옵니다. 사양을 정성껏 전달하면 80~120개는 거뜬히 나옵니다.

여기서 "오, AI 대단한데"라며 감동하여, 이 100개를 그대로 테스트 케이스로 옮기는 사람이 있습니다. 그것이 가장 큰 함정입니다.

Step 2: 분류하기 (이것도 AI에게 맡기기)

100개의 관점을 그대로 바라봐도 무엇을 깎아내야 할지 알 수 없습니다. 우선 분류가 필요합니다. 이것도 AI의 일입니다.

테스트 레벨로 분류하기

방금 전의 테스트 관점을 다음 테스트 레벨로 분류해 주세요.
- UT(단위 테스트)로 커버할 수 있음
- IT(통합 테스트)에서 확인해야 함
...

분류 결과 예시:

이 분류를 통해 "UT로 커버할 수 있음"이라고 판정된 것은, 단위 테스트가 작성되어 있다면 수동 테스트에서 제외할 수 있습니다. 분류하는 것만으로도 깎아낼 후보가 보입니다.

리스크 × 테스트 레벨 매트릭스 만들기

Step 1에서 붙인 리스크 레벨과 Step 2의 테스트 레벨을 조합하면 우선순위를 한눈에 알 수 있습니다.

여기까지는 AI의 일입니다. 덧셈과 정리는 AI에게 맡기고, 다음 Step 3부터가 인간의 차례입니다.

Step 3: 깎아내기 (이곳이 인간의 일)

100개의 관점을 35개로 깎아낸다. 이 "깎아내는 판단"은 AI가 할 수 없습니다.

왜냐하면, 깎아내는 판단에는 **문맥 (Context)**이 필요하기 때문입니다. 프로덕트의 역사, 팀의 리소스, 비즈니스의 우선순위, 과거에 무엇이 고통스러웠는가. 이것들은 컨텍스트 윈도우 (Context Window)에 담길 수 있는 것이 아니라, 현장에 있는 인간의 머릿속에 있습니다.

깎아내는 4가지 판단 기준

① 다른 테스트 레벨에서 커버됨 → 중복 삭제

단위 테스트 (UT)에서 이미 커버된 관점을 수동 테스트에서 다시 확인할 필요는 없습니다.

예:

• 「카드 번호 자릿수 부족으로 인한 입력 에러」 → 프론트엔드 검증 (Validation)에 UT가 있음 → 깎아냄
• 「XSS 공격 무력화」 → 새니타이즈 (Sanitize) 함수의 UT가 있음 → 깎아냄

단, 「UT가 있을 것이다」와 「UT가 있다」는 다릅니다. 실제로 테스트 코드의 존재를 확인한 뒤에 깎을 것.

② 이번 변경 스코프 외 → 스코프 외

이번 릴리스에서 변경이 들어가지 않은 기능은 풀 테스트 (Full Test) 대상에서 제외합니다.

예:

• 「편의점 결제 지급 기한 표시」 → 이번에는 카드 결제 리팩토링 (Refactoring)만 진행 → 깎아냄
• 「다통화 대응」 → 애초에 일본 엔화 전용 서비스 → 깎아냄

③ 리스크가 낮음 × 영향 범위가 한정적 → 우선순위 낮춤

발생 확률이 낮고, 발생하더라도 영향이 작은 것은 테스트 대상에서 제외하거나 최소한으로 좁힙니다.

예:

• 「Tab 키 조작으로 카드 입력 폼 조작 가능」 → 접근성 (Accessibility)이 중요하지만, 이번 스코프 외 → 깎아냄
• 「해외 접속 시 지급 기한이 올바름」 → 국내용 서비스 → 깎아냄

④ 과거에 한 번도 문제가 발생하지 않음 → 경량화

3년간 한 번도 버그가 나오지 않은 영역은 풀 테스트에서 회귀 테스트 (Regression Test, 자동화)로 전환합니다.

예:

• 「결제 완료 메일 송신 확인」 → 메일 기반 시스템은 안정적임. 자동 테스트로 충분 → 수동 테스트에서는 깎아냄

깎을 수 없는 관점

반면, 절대로 깎아서는 안 되는 관점이 있습니다.

이 3가지에 해당하는 관점은 리스크가 「낮음」으로 분류되어 있더라도 깎지 않습니다. AI의 분류를 맹신하지 않는 것 또한 인간의 일입니다.

Step 4: 깎은 이유를 남기기

깎는 것 자체는 어렵지 않습니다. 어려운 것은 「왜 깎았는가」를 설명하는 것입니다.

팀 리뷰에서 「왜 이 관점을 제외했나요?」라는 질문을 받았을 때, 「그냥 대충」으로는 통하지 않습니다. 깎은 이유를 한 줄로 적어둡니다. 이것이 리스크 판단의 기록이 됩니다.

「삭제」뿐만 아니라 「보류」도 있어도 좋습니다. 이번에는 하지 않지만, 잊지 않도록 기록해 두는 것입니다. 테스트 대상에서 제외하는 것과 존재를 잊어버리는 것은 다릅니다.

실례: 100개 → 35개로 깎은 결과

지금까지의 Step 1~4를 거치면, 100개의 관점이 다음과 같이 변합니다.

깎은 내역

100개 중 65개를 깎아서 35개가 남았습니다. 이 35개가 테스트 케이스 설계의 인풋 (Input)이 됩니다.

Before / After

「전부 테스트한다」로 인해 발생하는 일

100개의 관점을 전부 테스트하는 것은 언뜻 보면 꼼꼼해 보입니다. 하지만 실태는 정반대입니다.

리소스가 한정된 상황에서 전부를 균등하게 테스트하면, 중요한 관점도 흐릿해집니다. 결제의 정상계 (Happy Path)도, 타임존 (Timezone) 대응도 똑같은 1개의 테스트 케이스가 됩니다. 망가지면 매출이 멈추는 곳과, 망가져도 영향이 한정적인 곳이 똑같이 취급됩니다.

「전부 테스트한다」는 사실 전략이 없는 상태와 같습니다. 「무엇을 테스트하지 않을 것인가」를 결정할 수 있는 것이 테스트 전략의 핵심입니다.

이는 테스트 계획과 테스트 전략의 차이에서도 기술했던 「리스크 기반 테스트 배분 (Risk-based Test Allocation)」 그 자체입니다.

AI와의 분업 라인

지금까지의 4단계를 되돌아보면, AI와 인간의 역할 분담이 보입니다.

AI의 역할:
・테스트 관점을 포괄적으로 도출 (덧셈)
・테스트 레벨로 분류 (정리)
...

AI는 '빠짐없이 도출하는 것'에 능합니다. 인간은 '불필요한 것을 간파하는 것'에 능합니다. 100개를 내놓는 작업은 AI가 맡아주게 되었습니다. 하지만, 100개 중에서 35개로 줄이는 판단은 제품의 맥락을 아는 사람만이 할 수 있습니다.

이러한 분업 라인을 이해하고 실천하는 것이 AI를 활용한 테스트 설계의 첫걸음입니다.

요약

테스트 관점을 도출하는 능력은 AI의 등장으로 누구나 가질 수 있게 되었습니다. 명세서를 주면 100개가 나옵니다.

하지만, 100개를 35개로 줄이는 힘은 경험과 판단으로만 익힐 수 있습니다.

• '이 버그는 단위 테스트(unit test)로 막을 수 있다' → 중복 제거
• '이번 변경은 여기뿐이다' → 범위 외 제거
• '여기는 3년간 고장 난 적이 없다' → 경량화
• '여기는 절대로 망가져서는 안 된다' → 유지

이러한 판단을 할 수 있게 되었을 때, 테스트 설계의 풍경이 바뀝니다.

AI가 100개를 내놓고, 인간이 35개로 줄입니다. 덧셈은 AI, 뺄셈은 인간. 이 분업이 현재 테스트 설계에서 가장 생산성이 높은 방식입니다.

우선 AI에게 관점을 도출하게 해보세요. 그리고 '이것은 불필요하다'고 말할 수 있는지 스스로에게 질문해 보세요. 줄일 수 있다면, 당신은 이미 테스트 설계자입니다.

또 한 가지. 제거한 관점과 그 이유 목록을 팀에 공유해 주세요. '왜 이것을 제외했는지'가 보이면, 팀 전체의 리스크 감각이 맞춰집니다. 당신의 '뺄셈'이 팀의 테스트 설계 기준이 됩니다.

이러한 사고방식이 필요한 현장은 분명 아직 많이 있을 것입니다. ❤️ 이 전파하는 힘을 빌려주세요.

관련 기사

• '테스트 관점을 쓸 수 없다'를 해결한다. 3가지 벽과 극복 방법: 관점의 '도출 방식'은 여기에서. 본 기사의 전편
• 이제 와서 듣기 어려운 '테스트 계획'과 '테스트 전략'의 차이: '무엇을 테스트하지 않을지'가 테스트 전략의 핵심
• 테스트 관점을 축으로 한 품질 사이클의 제안: 관점을 활용한 품질 사이클 전체 모습
• AI가 흡수하는 것은 '역할(Role)'이 아니라 '레이어(Layer)'다: AI 시대 QA 엔지니어의 리스킬링

토론