개념
레슨 5의 지도를 넓히는 이유
레슨 5에서 스테이지 4의 도구들을 네 가지 판단 기준 — 무엇을 하려는가, 어느 계층인가, 접근성 정보가 있는가, 누가 유지보수하는가 — 으로 묶었다. 실무에서는 그 지도 밖의 질문이 곧바로 나온다.
- "웹은 Playwright로 하는데, 같은 팀이 모바일 앱과 Windows 설치형 프로그램 도 자동화해야 한다. 도구를 몇 개나 써야 하나?"
- "API는 Postman으로 보는데, 앱이 실제로 뭘 보내는지 는 어떻게 보나? Wireshark까지 배워야 하나?"
- "자동화를 처음 배우는데 Python, TypeScript, Java 중 무엇 부터?"
- "회사에 UiPath 라이선스가 있는데 그걸로 테스트 자동화 하면 안 되나?"
이 레슨은 이 네 질문에 대한 판단 기준을 준다. 도구는 계속 바뀌므로, 레슨 5에서처럼 도구 이름보다 선택 기준 에 집중하고, 도구의 현재 상태(유지보수 여부)는 참고 자료의 1차 출처로 주기적으로 확인한다.
질문 1 — 모바일과 데스크톱을 함께 자동화해야 할 때
세 갈래의 선택지가 있다.
| 갈래 | 대표 | 원리 | 강점 | 약점 |
|---|---|---|---|---|
| 표준 통합 | Appium (+ 플랫폼별 드라이버) | WebDriver 프로토콜로 각 OS의 자동화 프레임워크를 감싼다 | 모바일·데스크톱을 같은 API·같은 언어·같은 CI 로 | 드라이버마다 성숙도·유지보수 상태가 다르다 |
| 경량 GUI 라이브러리 | PyAutoGUI, SikuliX | 화면 좌표·이미지 인식으로 마우스·키보드를 조작 | 설치가 쉽고 접근성 정보가 없는 화면 에서도 동작 | 해상도·테마·화면 배율에 취약, 요소 속성을 읽지 못함 |
| 엔터프라이즈 조합 | Robot Framework (+ 라이브러리) | 키워드 기반 테스트 위에 웹·모바일·데스크톱·API 라이브러리를 조합 | 비개발자도 읽는 테스트, 보고서, 여러 기술을 한 실행기로 | 키워드 계층이 두꺼워지면 디버깅이 어렵고, 결국 파이썬 라이브러리 작성 역량이 필요 |
Appium — 모바일과 데스크톱을 하나의 표준으로
모듈 13 레슨 7에서 Appium을 모바일 자동화로 봤다. Appium의 구조는 서버 + 플랫폼별 드라이버 이고, 드라이버를 바꾸면 같은 클라이언트 코드 스타일로 다른 플랫폼을 자동화할 수 있다.
| 플랫폼 | 드라이버 | 밑에서 쓰는 것 | 상태 확인 포인트 |
|---|---|---|---|
| Android | UiAutomator2 드라이버 | Google UiAutomator | 활발 |
| iOS | XCUITest 드라이버 | Apple XCTest | 활발 |
| Windows 데스크톱 | Windows 드라이버 | Microsoft WinAppDriver 서버 | WinAppDriver 서버는 2022년 이후 유지보수되지 않고, Appium 쪽 Node.js 드라이버만 유지된다. 대안으로 NovaWindows 같은 커뮤니티 드라이버가 나왔다 |
| macOS 데스크톱 | Mac2 드라이버 | Apple XCTest | Appium 조직이 유지, 릴리스가 이어지고 있다 |
# 같은 스타일의 코드로 모바일과 데스크톱을 다룬다 — Appium Python 클라이언트
from appium import webdriver
from appium.options.android import UiAutomator2Options
from appium.options.windows import WindowsOptions
from appium.webdriver.common.appiumby import AppiumBy
# Android 앱
android = webdriver.Remote("http://127.0.0.1:4723", options=UiAutomator2Options().load_capabilities({
"platformName": "Android",
"appium:app": "/builds/app-release.apk",
}))
android.find_element(AppiumBy.ACCESSIBILITY_ID, "login_button").click()
# Windows 데스크톱 앱 — 드라이버와 capability 만 바뀐다
windows = webdriver.Remote("http://127.0.0.1:4723", options=WindowsOptions().load_capabilities({
"platformName": "Windows",
"appium:app": r"C:\Program Files\Acme\Acme.exe",
}))
windows.find_element(AppiumBy.ACCESSIBILITY_ID, "LoginButton").click()Appium을 표준으로 고를 때의 판단: 모바일 자동화가 이미 Appium이고 데스크톱 앱이 접근성 정보(UI Automation·Accessibility API)를 제대로 노출 한다면, 같은 팀·같은 언어·같은 CI로 묶는 이득이 크다. 반대로 Windows 쪽 비중이 크고 장기 운영해야 한다면, WinAppDriver 서버의 유지보수 중단을 도구 선정 위험으로 명시 하고 대안 드라이버나 다른 도구를 함께 평가한다. "표준이니까 안전하다"가 아니라 "표준의 어느 부품이 살아 있는가" 를 본다.
파이썬 경량 GUI 라이브러리 — PyAutoGUI, SikuliX
모듈 15 레슨 3의 이미지·좌표 기반 자동화가 코드로 구현된 형태다.
# PyAutoGUI — 좌표·이미지 기반. 요소 속성을 읽지 못한다
import pyautogui
pyautogui.FAILSAFE = True # 마우스를 화면 모서리로 밀면 중단 — 필수 안전장치
button = pyautogui.locateCenterOnScreen("img/save_button.png", confidence=0.9) # confidence 는 OpenCV 필요
if button is None:
raise AssertionError("저장 버튼 이미지를 찾지 못함 — 해상도·테마·배율 확인")
pyautogui.click(button)
pyautogui.write("report-2026-09.xlsx", interval=0.05)
pyautogui.press("enter")| 도구 | 성격 | 현재 상태 확인 포인트 |
|---|---|---|
| PyAutoGUI | 마우스·키보드·스크린샷·간단한 이미지 매칭을 파이썬으로 | 원 저장소의 릴리스가 오래 멈춰 있고, 포크가 개발을 이어가려는 움직임이 있다 |
| SikuliX | 이미지 인식(OpenCV)과 OCR 중심 자동화, 스크립트 IDE | 원 개발자가 개발을 멈추고 OculiX 로 관리가 이관되었다는 공지가 있다 |
두 도구의 공통된 자리는 "다른 방법이 없을 때" 다. 접근성 정보가 없는 레거시 화면, 원격 데스크톱·가상화 화면, 게임·캔버스 기반 UI. 레슨 3의 안정성 위계(접근성 기반 → 이미지 → 좌표)를 기억하자. 경량 라이브러리는 설치가 쉬워 첫 자동화로 고르기 쉽지만, 해상도·테마·화면 배율이 바뀌면 전부 깨지므로 회귀 스위트의 주력으로 쓰기 어렵다. 유지보수 상태도 주기적으로 확인해야 하는 도구들이다.
엔터프라이즈 조합 — Robot Framework
Robot Framework는 키워드 기반 테스트 실행기다. 모듈 11 레슨 6의 키워드 주도 프레임워크를 오픈소스로 구현한 대표 사례이고, 7.x 계열로 활발히 릴리스되고 있다. 핵심은 라이브러리 조합 이다.
| 대상 | 라이브러리 (예) |
|---|---|
| 웹 | SeleniumLibrary, Browser 라이브러리(Playwright 기반) |
| 모바일 | AppiumLibrary |
| 데스크톱·RPA | RPA Framework 계열 라이브러리 |
| API | RequestsLibrary |
| DB | DatabaseLibrary |
*** Settings ***
Library Browser
Library RequestsLibrary
*** Test Cases ***
주문 생성 후 웹에서 주문 상세 확인
${resp}= POST ${API}/orders json={"sku": "SKU-QA-001", "qty": 1} expected_status=201
${order_id}= Set Variable ${resp.json()}[orderId]
New Page ${WEB}/orders/${order_id}
Get Text h1 == 주문 ${order_id}조합을 고를 때의 판단: 테스트를 읽는 사람이 개발자만이 아니고(현업·감사·수동 테스터), 웹·모바일·데스크톱·API가 한 보고서 로 나와야 하며, 조직에 파이썬 라이브러리를 작성할 사람이 있을 때 강하다. 키워드만으로 모든 것을 해결하려 하면 키워드가 수백 개로 불어나 디버깅이 어려워진다. 복잡한 로직은 파이썬 라이브러리로, 시나리오는 키워드로 나누는 것이 운영의 핵심이다.
판단 요약
데스크톱·모바일 자동화 대상이 있다
├─ 앱이 접근성 정보를 노출한다
│ ├─ 모바일 자동화가 이미 Appium → Appium 드라이버로 통합 (Windows 드라이버 유지보수 위험 평가 포함)
│ └─ 비개발자 가독성·통합 보고서가 중요 → Robot Framework + 해당 라이브러리
└─ 접근성 정보가 없다 (레거시·원격 화면·캔버스)
└─ 이미지·좌표 기반 (SikuliX·PyAutoGUI 계열) — 범위를 최소화하고, 레슨 3 안정성 위계를 따른다질문 2 — API·네트워크 도구는 어디까지 알아야 하나
API·네트워크 도구는 보는 범위 가 다른 세 계층으로 나뉜다. 모듈 12 레슨 2(Postman), 모듈 19 레슨 4(Charles·mitmproxy), 레슨 5(Wireshark·tcpdump)에서 각각 실습했다. 여기서는 언제 어느 계층이 필요한가 로 묶는다.
| 계층 | 대표 도구 | 보는 것 | 할 수 있는 것 | 못 하는 것 |
|---|---|---|---|---|
| 1. API 클라이언트 | Postman, Insomnia, Bruno 류 | 내가 보낸 요청과 그 응답 | 의도한 요청을 만들어 보내고 응답 확인·단언·컬렉션 자동화 | 앱이 실제로 보내는 요청은 안 보인다 |
| 2. HTTP(S) 프록시 | Charles, Fiddler, mitmproxy | 기기·브라우저·앱이 주고받는 전체 HTTP(S) 트래픽 | 모바일 앱 트래픽 확인, 요청·응답 중간 조작(브레이크포인트·Map Local·Rewrite), 네트워크 스로틀링 | HTTP가 아닌 프로토콜, TCP·TLS 연결 수준 문제 |
| 3. 패킷 분석 | Wireshark, tcpdump | 네트워크 패킷 레벨 전체 | MQTT·WebSocket 프레임·gRPC 같은 비HTTP·저수준 확인, 연결 재설정·재전송·TLS 핸드셰이크 실패, 서버 측 tcpdump 캡처 | 암호화된 내용은 키 없이 해독 불가, 학습 비용이 크다 |
같은 "결제 요청이 실패한다"는 문제가 계층마다 다르게 보인다.
1계층 (Postman) : 같은 요청을 직접 보내면 200 성공 → "서버는 정상"
2계층 (Charles) : 앱이 보낸 요청을 보니 amount 필드가 문자열 "10,000" → 앱의 요청 형식 결함 발견
응답을 Rewrite 로 500 으로 바꿔 앱의 오류 처리 화면도 확인
3계층 (Wireshark) : 요청이 서버에 도달하기 전 TLS 핸드셰이크에서 연결 재설정 → 프록시·인증서·네트워크 장비 문제도구 상태도 한 가지 짚자. Fiddler는 Windows 전용 Fiddler Classic 과 크로스플랫폼 Fiddler Everywhere 로 나뉘어 있고, Classic은 활발히 개발되지 않으며 상업적 사용 조건이 바뀌었다. mitmproxy는 11 버전부터 HTTP/3를 폭넓게 지원한다. 조직에서 표준 도구를 정할 때 라이선스와 지원 프로토콜을 확인한다.
매뉴얼 테스터의 학습 우선순위
수동 테스트 경력자가 기술 역량을 넓힐 때 가장 흔한 질문이 "무엇부터"다. 권장 순서는 Postman → Charles/Fiddler → Wireshark/tcpdump 다.
| 순서 | 도구 | 이유 | 투자 대비 효과 |
|---|---|---|---|
| 1 | Postman | API 요청·응답 구조, 상태 코드, 인증 헤더 개념을 가장 빨리 익힌다. 결함 리포트에 재현 가능한 요청 을 붙일 수 있게 된다 | 매우 큼 — 거의 모든 서비스에서 바로 쓴다 |
| 2 | Charles/Fiddler | 앱이 실제로 무엇을 보내는지 본다. 모바일 앱 검증, 서버 없이 예외 상황 만들기, 느린 네트워크 재현 | 큼 — 모바일·웹 서비스라면 결함 원인 파악 속도가 달라진다 |
| 3 | Wireshark/tcpdump | 프록시로 보이지 않는 연결·프로토콜 문제 | 도메인에 따라 다름 |
Wireshark는 급하지 않을 수 있다. 일반 웹·모바일 서비스 QA에서는 1·2계층으로 대부분의 문제를 좁힐 수 있고, 연결 수준 문제는 인프라·네트워크 담당과 협업하는 편이 효율적이다. 반대로 모빌리티·IoT·실시간 서비스(차량 통신, 센서 기기, MQTT 기반 메시징, 게임·스트리밍, WebSocket 중심 서비스)라면 3계층이 일찍 필요하다. 모듈 19 레슨 5의 "어디까지가 QA의 일인가"와 같은 판단이다.
질문 3 — 언어 선택 로드맵
"어떤 언어가 가장 좋은가"에는 답이 없다. 어떤 조직에서 어떤 도구로 일할 것인가 에 따라 출발점이 갈린다. 세 갈래로 정리한다.
┌─ Python 시작 ─── Selenium / Appium 입문 ─── pytest 체계 ─── Playwright(Python)로 확장
│ (데이터·ML 조직, 모바일·데스크톱 혼합, Robot Framework 조직)
자동화 첫 언어 ────┼─ TypeScript 시작 ─ Playwright 중심 ─── API 테스트(Playwright request) ─── 프런트엔드 컴포넌트 테스트
│ (웹 서비스 스타트업·프런트엔드 비중이 큰 조직)
└─ Java 시작 ─────── Selenium + TestNG/JUnit ─── REST Assured ─── 대형 회귀 스위트·Appium(Java)
(대기업·금융·SI, 개발 스택이 Java 인 대형 회귀 조직)| 갈래 | 시작하기 좋은 사람 | 강점 | 주의 |
|---|---|---|---|
| Python | 프로그래밍이 처음, 모바일·데스크톱·데이터 검증을 함께 할 사람 | 문법이 쉽고 Appium·Robot Framework·PyAutoGUI·데이터 도구와 연결이 넓다 | 웹 프런트엔드 조직에서는 개발팀과 언어가 달라 협업이 약해질 수 있다 |
| TypeScript | 웹 서비스 조직, 프런트엔드 개발자와 같은 저장소에서 일할 사람 | Playwright의 1차 지원 언어, 개발팀과 코드·리뷰·CI 공유 | 타입 시스템과 비동기(async/await)에 초반 학습 비용 |
| Java | 대기업·금융·SI, 백엔드가 Java인 조직 | 대형 회귀 스위트 운영 경험·도구 생태계가 두텁고, 채용 공고가 많다 | 코드량이 많고 시작이 무겁다 |
판단 기준은 셋이다. ① 들어가려는 조직의 개발 스택 (개발팀과 같은 언어면 코드 리뷰·유지보수를 함께 할 수 있다), ② 주력 도구의 1차 지원 언어, ③ 두 번째 언어로 넘어가기 쉬운가. 어느 갈래로 시작해도 모듈 11~13의 개념(피라미드·POM·대기 전략·플래키 대응)은 그대로 옮겨 간다. 언어보다 개념이 오래간다.
질문 4 — RPA로 테스트 자동화를 하면 안 되나
레슨 1에서 RPA와 QA 자동화의 목적 이 다르다는 것을 봤다. 이번에는 도구 특성 으로 비교한다. UiPath 같은 RPA 플랫폼과 Selenium·Playwright·Appium 같은 개발자용 오픈소스를 나란히 놓으면 이렇다.
| 기준 | RPA (UiPath 등) | 개발자용 오픈소스 (Selenium·Playwright·Appium) |
|---|---|---|
| 시스템 호환성 | 최강 — 웹·데스크톱·SAP·메인프레임 터미널·Citrix·이미지 인식까지 한 도구로 | 도구별로 대상이 나뉜다 (웹은 Playwright, 모바일은 Appium …) |
| 실행 속도 | 사람의 조작을 흉내 내는 구조라 상대적으로 느림, 로봇 기동 오버헤드 | 브라우저 프로토콜 직접 제어, 병렬 실행에 최적화 |
| UI 변화 취약성 | 화면 기록 기반 셀렉터·이미지 인식이 UI 변경에 약함 | 역할·테스트 ID 기반 로케이터 설계로 유지보수 가능 (모듈 13 레슨 3) |
| CI/CD 연동 | 오케스트레이터·로봇 라이선스·실행 머신 구성이 필요, 파이프라인에 넣기 무거움 | 컨테이너에서 바로 실행, PR마다 돌리기 쉬움 |
| 버전 관리·리뷰 | 워크플로 파일 비교·코드 리뷰가 어렵다 | 일반 코드로 Git·PR 리뷰 |
| 비용 | 로봇·개발 도구·오케스트레이터 라이선스 비용 | 도구 무료, 인력·인프라 비용 |
| 작성자 | 비개발자·현업이 만들기 쉬움 | 코드 작성 역량 필요 |
그래서 RPA는 QA 자동화의 주류로 쓰이지 않는다. QA 자동화의 핵심 요구 — 매 변경마다 빠르게, 병렬로, CI에서, 코드로 리뷰하며 — 에 도구 구조가 맞지 않기 때문이다. 대신 RPA가 합리적인 자리 는 분명히 있다.
- 개발자용 도구로 접근할 수 없는 시스템이 섞인 종단 업무 흐름(SAP → 메인프레임 터미널 → 웹 포털)의 인수 시험
- 이미 RPA 플랫폼·라이선스·운영 조직이 있는 기업에서 업무 자동화 로봇 자체를 검증 하는 일(레슨 1)
- RPA 벤더가 테스트 전용 제품군을 함께 제공하는 경우, 그 조직의 표준을 따르는 선택
"회사에 UiPath 라이선스가 있다"는 이유만으로 웹 회귀 스위트를 RPA로 짜면, 몇 달 뒤 실행 시간·유지보수·CI 연동에서 비용이 드러난다. 레슨 5의 판단 기준 4(누가 만들고 유지보수하는가)와 함께 실행 빈도 를 기준에 넣는다. 매 PR마다 돌아야 하면 오픈소스, 분기마다 한 번 도는 종단 인수 시나리오면 RPA도 선택지다.
실무에서 왜 필요한가
도구 선택은 한 번 잘못하면 몇 년 동안 비용을 낸다. 수백 개의 테스트를 쓴 뒤에 도구를 바꾸는 것은 새로 쓰는 것과 비슷한 일이기 때문이다(모듈 22 레슨 12의 "이사 비용"). 그런데 도구 선택 회의는 대개 데모 인상과 "다른 회사가 쓰더라"로 결정된다.
이 레슨의 판단 기준 — 표준의 어느 부품이 살아 있는가, 어느 계층까지 봐야 하는가, 조직의 개발 스택과 맞는가, 실행 빈도와 CI 구조에 맞는가 — 을 말할 수 있는 QA는 도구 선택 회의에서 근거를 제시하는 사람이 된다. 매뉴얼 테스터에게는 막연한 "자동화 공부"를 순서가 있는 학습 계획 으로 바꿔 주고, 시니어에게는 도구 도입 제안서(자동화 전환 트랙의 공백)의 뼈대가 된다.