개념
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 로봇도 결국 테스트가 필요하다"처럼 정확한 조언을 할 수 있다.