이 도구들이 유효한 도메인 판단하기: 스테이지 4 도구 지도 종합

개념

스테이지 4에서 만난 도구들

모듈 11부터 지금까지 여러 자동화 도구를 배웠다. 이 레슨은 이 전체를 하나의 판단 지도로 정리한다.

모듈 12 — Postman, 코드 기반 API 테스트, Pact  (API 계층)
모듈 13 — Playwright(웹), Appium(모바일)         (UI 계층, 접근성 정보 있음)
모듈 15 — UiPath(업무 자동화), Tosca/UFT(코드리스),
          이미지·OCR 기반(접근성 정보 없음)

판단 기준 1 — 무엇을 검증/수행하려 하는가

소프트웨어 품질을 검증하고 싶다  → QA 자동화(모듈 12, 13)
반복 업무 자체를 대신하고 싶다   → RPA(모듈 15 레슨 1)

이건 모듈 15(레슨 1)에서 배운 RPA와 QA 자동화의 근본적인 목적 차이를 다시 확인하는 것이다.

판단 기준 2 — 어느 계층을 검증하려 하는가

모듈 11(레슨 1)에서 배운 피라미드를 떠올리면, API 테스트(모듈 12)가 UI 자동화(모듈 13)보다 우선이다. "이걸 API 레벨에서 검증할 수 있는가?" 를 먼저 묻고, 안 된다면 그때 UI 자동화로 내려간다.

판단 기준 3 — 화면에 접근성 정보가 있는가

있다(일반적인 웹·모바일 앱)      → Playwright / Appium (모듈 13)
없다(레거시 데스크톱, 임베디드)  → 이미지·OCR 기반 (모듈 15 레슨 3)

판단 기준 4 — 누가 자동화를 만들고 유지보수하는가

개발·QA 인력이 코드를 다룰 수 있다  → 코드 기반(Playwright, 코드 기반 API 테스트)
비개발 도메인 전문가가 참여해야 한다 → 코드리스(Tosca, UFT, UiPath)

이건 모듈 15(레슨 2)에서 배운 "조직의 인력 구성에 맞는 도구 선택"이다.

하나의 흐름도로 정리하기

Q1. 목적이 업무 대행인가, 품질 검증인가?
    → 업무 대행 → RPA(UiPath)
    → 품질 검증 → Q2로
 
Q2. API 레벨에서 검증 가능한가?
    → 가능 → API 테스트(Postman, 코드 기반, 계약 테스트)
    → 불가능(화면까지 확인 필요) → Q3으로
 
Q3. 화면에 접근성 정보가 있는가?
    → 있다 → Playwright / Appium
    → 없다 → 이미지·OCR 기반, 또는 코드리스 엔터프라이즈 도구

도구는 계속 바뀌지만 판단 기준은 오래간다

지금 배운 구체적인 도구 이름(Playwright, UiPath 등)은 몇 년 뒤 다른 이름으로 대체될 수 있다. 하지만 이 레슨에서 정리한 판단 기준(목적, 계층, 접근성 정보 유무, 인력 구성) 은 새로운 도구가 등장해도 계속 유효하다 — 모듈 11(레슨 5)에서 배운 "전략이 도구보다 오래간다"는 원칙이 스테이지 4 전체를 통해 증명된 셈이다.

스테이지 4를 마무리하며

모듈 11에서 세운 전략(피라미드, 판단 기준, ROI, 부채 관리)을 기반으로, 모듈 12(API)·13(UI)·14(CI/CD)·15(RPA·레거시)라는 구체적인 실행 방법을 쌓아왔다. 이제 어떤 자동화 요구가 오더라도, "이건 무슨 목적이고, 어느 계층이고, 어떤 도구가 맞는가"를 스스로 판단할 수 있는 기반이 마련됐다.

실무에서 왜 필요한가

"이거 자동화해주세요"라는 요청을 받았을 때, 무작정 익숙한 도구 하나로 다 해결하려는 QA와, 이 레슨의 판단 기준으로 "이건 사실 RPA가 맞고, 이건 API 테스트로 충분하다"고 정확히 짚어내는 QA는 결과물의 질이 완전히 다르다. 이런 판단력은 특정 도구 경력보다 오래가는, QA 시니어십의 핵심 역량이다.

실습 과제

과제 1 — 흐름도 적용하기 (15분)

다음 세 요청에 이 레슨의 흐름도(Q1~Q3)를 적용해 어떤 도구가 적합할지 판단한다.

1. "매일 세 시스템의 재고 데이터를 취합해 보고서를 만드는 반복 작업을 자동화하고 싶다"
2. "새로 만든 결제 API가 다양한 카드사 조합에서 정확히 동작하는지 확인하고 싶다"
3. "20년 된 창구 단말 프로그램에서, 계좌 조회 화면이 여전히 정상적으로 뜨는지 매일 확인하고 싶다(API 없음, 접근성 정보 없음)"

과제 2 — 스테이지 4 되돌아보기 (10분)

모듈 11~15 중 가장 인상 깊었던 원칙 하나를 골라, 왜 그 원칙이 다른 모듈들과 연결되는지 두세 문장으로 정리한다.

자가 체크리스트

• 스테이지 4에서 배운 도구들을 목적·계층별로 분류할 수 있다
• 이 레슨의 판단 흐름도(Q1~Q3)를 실제 상황에 적용할 수 있다
• 도구는 바뀌어도 판단 기준은 오래간다는 것을 설명할 수 있다
• 모듈 11의 전략이 12~15의 구체적 실행으로 어떻게 이어지는지 설명할 수 있다

흔한 실수

• 익숙한 도구 하나로 모든 자동화 요구를 해결하려 한다. 목적과 계층에 맞는 도구를 판단하는 과정을 생략하면 비효율이 커진다.
• 도구 이름을 외우는 데 집중하고 판단 기준은 소홀히 한다. 도구는 계속 바뀌지만 판단 기준은 훨씬 오래 쓸 수 있는 자산이다.
• RPA·코드리스 도구를 구식이라고 무시한다. 조직과 상황에 따라 여전히 가장 합리적인 선택일 수 있다.

참고 자료

• Dorothy Graham & Mark Fewster, Experiences of Test Automation — 다양한 자동화 도구 선택 사례를 폭넓게 다룬 실무서(모듈 11에서도 참고)
• ISTQB CTFL — Test Automation 관련 개념의 공식 정의(모듈 11~15 전체와 연결)
• 이어지는 레슨: 이 모듈 레슨 6 「크로스플랫폼 자동화 도구 선택 가이드」 — 모바일·데스크톱 통합, API·네트워크 도구 계층, 언어 로드맵, RPA와 오픈소스 비교