데스크톱 RPA는 자동화 세계의 현실주의자입니다. API가 없는 프로그램, 웹으로 열리지 않는 업무는 결국 화면 위에서 자동화해야 합니다. 문제는 데스크톱 RPA가 태생적으로 깨지기 쉬운 환경 위에 서 있다는 점입니다. 창 위치, 프로그램 업데이트, OS 팝업, 메모리 누수까지 전부 변수입니다. 한 번 돌리고 끝나는 RPA와 24시간 상주하는 RPA는 완전히 다른 공학입니다. 후자를 실제로 굴리며 정착시킨 운영 구조를 정리합니다.
데스크톱 RPA 운영의 첫 원칙: 죽는다는 전제
상주 RPA 운영 설계는 "안 죽게 만들기"가 아니라 "죽어도 이어지게 만들기"에서 출발합니다. 우리 시스템의 계층은 이렇습니다.
- 프로세스 계층: RPA 상주 프로세스는 슈퍼바이저 아래에서 돕니다. 크래시하면 몇 초 뒤 자동 재기동됩니다. 처리 기록에 멱등키가 있어 재기동 후 중복 처리가 생기지 않습니다.
- 대상 프로그램 계층: 자동화 대상 앱이 얼거나 예외 화면에 빠지면 워치독이 감지해 재시작하고 정상 흐름으로 복귀시킵니다. 유휴 상태가 길어지면 선제적으로 재시작해 누적 열화를 방지합니다.
- 입력 채널 계층: 주문이 들어오는 메신저 통로가 끊기면 자가치유 루틴이 메신저를 재기동하고 연결을 복구합니다.
계층마다 복구 장치가 따로 있는 이유는 실패의 단위가 다르기 때문입니다. 메신저가 죽었는데 RPA 프로세스를 재시작하면 엉뚱한 수리이고 그 반대도 마찬가지입니다. 어디가 죽었는지 구분해 좁게 고치는 것이 복구 시간을 줄입니다.
원격 운영: 현장에 가지 않는다
상주 RPA는 보통 전용 PC에서 돕니다. 그 PC 앞에 사람이 앉아 있어야 한다면 무인이 아닙니다. 우리는 RPA 엔진에 웹 운영 콘솔을 붙여, 서비스 시작·중지, 실시간 로그, 처리 기록 조회, 감시 대상 방 설정, 동작 파라미터 조정까지 브라우저에서 처리하게 했습니다.
콘솔에서 특히 가치가 컸던 것은 설정의 셀프서비스입니다. 감시할 방을 추가하거나 복구 동작의 임계를 조정하는 일이 코드 배포가 아니라 화면 조작이 되면, 운영자가 개발자를 기다리지 않습니다. 자동화 시스템의 유지 비용은 이런 소소한 조정의 왕복 횟수에서 갈립니다.
원격 콘솔과 별개로, 알림 채널(텔레그램)이 상황 인지를 담당합니다. 오류·복구·승인 요청이 모바일로 오므로 운영자는 시스템을 들여다보는 대신 알림에 반응하면 됩니다. 관측의 기본값을 "사람이 확인하러 간다"에서 "시스템이 알려 온다"로 뒤집는 것이 무인 운영의 핵심 전환입니다.
처리량이 늘면: 역할 분리와 분산
데스크톱 RPA의 확장은 서버 스케일아웃처럼 매끄럽지 않습니다. 화면과 입력 장치를 점유하는 특성상 한 PC에서 동시에 돌릴 수 있는 작업에 한계가 있기 때문입니다.
우리는 역할 분리로 접근했습니다. 주문 감지·파싱을 담당하는 코디네이터 PC와 실제 처리를 담당하는 워커 PC를 나누고 코디네이터가 서명된 원격 호출로 워커에 작업을 배정합니다. 워커의 생존은 헬스 모니터가 감시합니다. 이 구조의 장점은 두 가지입니다. 확장이 "워커 PC 추가"라는 단순한 연산이 되고, 감지 채널(메신저 세션)과 처리 부하가 서로를 방해하지 않습니다.
| 운영 요소 | 장치 | 없을 때 생기는 일 |
|---|---|---|
| 프로세스 생존 | 슈퍼바이저 자동 재기동 | 새벽 크래시가 아침까지 방치 |
| 대상 앱 상태 | 워치독 · 유휴 재시작 | 얼어붙은 화면에 입력만 반복 |
| 입력 채널 | 자가치유 재연결 | 주문이 조용히 끊김 |
| 운영 개입 | 웹 콘솔 · 모바일 알림 | 조정할 때마다 현장 출동 |
| 확장 | 코디네이터·워커 분리 | 처리량 한계에서 전면 재설계 |
운영에서만 배울 수 있는 것들
상주 RPA의 함정은 코드 밖에 많았습니다. 몇 가지만 기록하면, 터미널 창의 텍스트 선택(QuickEdit)이 프로세스를 멈추게 하는 윈도우 특성 때문에 실행 안내에 해당 설정 해제를 포함해야 했고 시스템 프록시 설정이 백그라운드 통신에 끼어들어 전송 실패를 만든 사례도 있었습니다. 이런 항목은 어떤 프레임워크 문서에도 없고 운영 안내 문서에 축적해 두는 것이 다음 장애의 복구 시간을 줄입니다.
이 운영 구조 위에서 도는 시스템의 전체 그림은 카카오톡 주문 자동화 사례에서 볼 수 있습니다. 기록을 지키는 전송·멱등 설계는 무인 자동화 안전장치 설계와 중복 없는 멱등성 설계에서 이어집니다.
자주 묻는 질문
데스크톱 RPA는 서버 자동화보다 열등한 선택인가요?
용도가 다릅니다. API가 있는 시스템은 서버 자동화가 당연히 낫지만 API 없는 데스크톱 프로그램·화면 전용 업무는 RPA가 유일한 현실적 수단입니다. 중요한 것은 RPA를 선택했을 때 상주 운영에 필요한 복구·관측 장치를 함께 견적에 넣는 일입니다.
상주 RPA 전용 PC는 어떻게 관리하나요?
사람이 안 가도 되게 만드는 것이 목표입니다. 서비스 제어와 설정은 웹 콘솔로, 상황 인지는 모바일 알림으로 옮기고 프로세스·대상 앱·입력 채널 각각에 자동 복구를 둡니다. 원격 접속은 최후 수단으로 남기되, 일상 운영이 원격 접속에 의존하면 설계를 다시 봐야 합니다.
처리량을 늘리려면 PC를 계속 추가해야 하나요?
역할 분리가 먼저입니다. 감지·조율과 실제 처리를 나누면 처리 워커만 늘리는 구조가 되고 확장이 단순해집니다. 한 PC에 모든 역할이 뭉쳐 있으면 처리량 한계가 곧 전면 재설계로 이어집니다.
RPA가 조작하는 프로그램이 업데이트되면 어떻게 되나요?
깨질 수 있고 그것을 전제로 운영합니다. 화면 인식이 실패하면 시스템이 진행을 멈추고 알림을 보내므로 잘못된 조작으로 이어지지 않습니다. 업데이트 대응은 인식 기준(템플릿·좌표) 갱신 수준의 유지보수 작업으로 관리하며 이 비용은 상주 RPA의 고정 운영비로 계획에 넣어야 합니다.