개념
RPA와 QA 자동화, 이름은 비슷해도 목적이 다르다
모듈 11~14에서 배운 자동화는 전부 **"소프트웨어가 올바르게 동작하는지 검증"**하는 것이 목적이었다. RPA(Robotic Process Automation)는 다르다 — 사람이 반복적으로 하던 실제 업무 자체를 소프트웨어 로봇이 대신 수행하는 것이 목적이다.
QA 자동화: "이 시스템이 제대로 동작하는지 검증한다" (검증이 목적)
RPA: "사람이 하던 반복 업무를 로봇이 대신한다" (업무 수행이 목적)예시: 매일 아침 회계 담당자가 여러 시스템에서 데이터를 뽑아 엑셀로 취합해 보고서를 만든다고 하자. RPA 로봇은 이 담당자가 하던 클릭과 복사·붙여넣기를 그대로 흉내 내어, 매일 아침 자동으로 같은 보고서를 만들어낸다.
UiPath 같은 도구의 접근 방식
UiPath는 대표적인 RPA 도구다. 코드를 직접 짜지 않고, 화면의 흐름을 시각적으로 기록하거나 조립해서 자동화를 만든다 — "이 버튼을 클릭하고, 이 필드에 값을 입력하고, 이 데이터를 복사해서 다른 프로그램에 붙여넣는다"는 과정을 순서도처럼 구성한다.
이 접근은 모듈 13에서 배운 Playwright의 코드 기반 방식과 대조된다.
| QA 자동화(Playwright 등) | RPA(UiPath 등) | |
|---|---|---|
| 사용자 | 주로 QA·개발자(코드 작성) | 주로 현업 담당자(코드 없이 구성) |
| 목적 | 소프트웨어 품질 검증 | 반복 업무 대행 |
| 대상 | 우리가 만드는 서비스 화면 | 여러 시스템에 걸친 업무 흐름(우리가 안 만든 시스템 포함) |
왜 QA가 RPA를 알아야 하는가
QA가 RPA 프로젝트를 직접 만들 일은 많지 않지만, 다음과 같은 상황에서 RPA 지식이 필요해진다.
- RPA로 만든 자동화 로봇 자체를 테스트해야 할 때 — RPA 프로세스도 결국 소프트웨어이므로, 모듈 1~10에서 배운 테스트 원칙(경계값, 예외 처리 등)이 그대로 적용된다
- RPA와 QA 자동화의 경계를 판단해야 할 때 — "이건 RPA로 업무를 자동화할 문제인가, 아니면 애초에 시스템 자체를 수정해야 할 문제인가"를 구분하는 시야가 필요하다
RPA의 한계
RPA는 화면 구조가 조금만 바뀌어도 깨지기 쉽다는 점에서, 모듈 13(레슨 3)에서 배운 "불안정한 로케이터" 문제를 그대로 안고 있다 — 오히려 QA 자동화보다 이 문제가 더 심할 수 있다. RPA로 자동화된 업무는 근본적인 시스템 개선(API 연동 등)의 대안이 아니라, 시스템을 못 바꾸는 상황에서의 임시방편인 경우가 많다는 점을 QA는 인식하고 있어야 한다.
실무에서 왜 필요한가
"이 반복 업무, RPA로 자동화하면 어떨까요?"라는 논의에 QA가 참여하게 되는 경우가 있다. 이때 RPA와 QA 자동화의 목적 차이를 정확히 아는 QA는, "이건 RPA가 아니라 시스템 자체의 API를 만들어서 해결하는 게 근본적"이라거나 "이 RPA 로봇도 결국 테스트가 필요하다"처럼 정확한 조언을 할 수 있다.
실습 과제
과제 1 — RPA vs QA 자동화 구분하기 (10분)
다음 두 상황이 RPA와 QA 자동화 중 어느 쪽에 해당하는지 판단하고 이유를 적는다.
- "매주 월요일, 세 개의 사내 시스템에서 데이터를 뽑아 엑셀로 합쳐 이메일로 발송하는 작업을 자동화하고 싶다"
- "결제 API가 할인율을 정확히 계산하는지 매 배포마다 자동으로 확인하고 싶다"
과제 2 — RPA 로봇의 테스트 필요성 (10분)
"청구서 데이터를 회계 시스템에 자동 입력하는 RPA 로봇"이 있다고 하자. 이 로봇 자체를 검증하려면 어떤 경계값이나 예외 상황을 테스트해야 할지, 모듈 3에서 배운 개념을 참고해 2가지 이상 적는다.
자가 체크리스트
- RPA와 QA 자동화의 목적 차이를 설명할 수 있다
- UiPath 같은 도구가 코드 기반 자동화와 어떻게 다른 방식으로 동작하는지 설명할 수 있다
- RPA 로봇도 테스트가 필요한 이유를 설명할 수 있다
- RPA가 근본적 해결책이 아니라 임시방편일 수 있는 이유를 설명할 수 있다
흔한 실수
- RPA를 QA 자동화의 다른 이름이라고 착각한다. 목적과 대상이 근본적으로 다르다.
- RPA로 자동화된 업무는 검증이 필요 없다고 생각한다. RPA 로봇도 소프트웨어이므로 결함이 있을 수 있다.
- RPA가 시스템 개선을 대체할 완전한 해결책이라고 생각한다. 대부분은 시스템을 바꿀 수 없는 상황의 임시방편이다.
참고 자료
- UiPath 공식 문서 — RPA 개요 — RPA 개념과 UiPath의 공식 소개
- ISTQB Glossary — Robotic Process Automation — RPA의 공식 용어 정의