약 6분 읽기
“로봇이 멈췄어요!”
이 한마디는 RPA 엔지니어에게 마치 ‘비상벨’과도 같습니다. 특히 UI 변경으로 인해 로봇이 멈추는 상황은 정말이지, 씁쓸하다 못해 허탈하기까지 하죠. 오늘은 제가 겪었던, 그리고 아마 많은 RPA 엔지니어들이 공감할 만한 ‘UI 변경으로 인한 RPA 장애와 유지보수’의 현실에 대해 이야기해보려 합니다.
‘순식간에’ 멈춰버린 로봇들
몇 주 전, 아주 평화로운 오후였습니다. 평소처럼 제 개인 서버를 관리하고, n8n 워크플로우를 조정하며 여유를 즐기고 있었죠. 그때, 제 휴대폰으로 알림이 띠링 울렸습니다. 담당자에게서 온 긴급 메시지였습니다.
“황민님, 지금 3개 프로세스가 동시에 멈췄어요. 확인 부탁드립니다.”
순간적으로 머릿속이 하얘졌습니다. 3개라니요. 그것도 동시에? 보통은 하나 정도의 오류가 발생해도 당황스러운데, 3개라니. 빠르게 상황 파악에 나섰습니다. 로그를 확인해보니, 예상했던 대로 특정 애플리케이션의 UI 요소들을 찾지 못해 발생하는 오류였습니다. 클라이언트 측에서 해당 애플리케이션에 대한 시스템 업데이트를 진행한 것이 원인이었습니다.
“아… 또 UI 변경이구나.”
이런 상황은 사실 처음이 아닙니다. RPA, 특히 UI 자동화에 의존하는 로봇들에게 UI 변경은 치명적입니다. 마치 사람이 살던 집의 구조가 갑자기 바뀌어버린 것처럼, 로봇은 더 이상 자신이 찾던 버튼이나 입력창을 발견하지 못하고 길을 잃어버리는 셈이죠.
이번에도 마찬가지였습니다. 업데이트된 UI에서 이전과 달라진 속성값 때문에 로봇이 요소를 인식하지 못하고 멈춰버린 것이죠. 해당 애플리케이션은 여러 부서에서 핵심적으로 사용하고 있었기에, 3개의 프로세스가 동시에 멈춘 것은 업무에 상당한 차질을 빚을 수 있는 상황이었습니다.
긴급 소방수, 그리고 ‘삽질’의 시작
시간은 금이었습니다. 저는 곧바로 담당자에게 연락을 취해 상황을 설명하고, 긴급 수정을 위한 준비에 들어갔습니다.
가장 먼저 해야 할 일은 어떤 UI 요소가 변경되었는지 정확히 파악하는 것이었습니다. RPA 툴의 ‘UI 탐색기’ 같은 기능을 사용해 변경된 화면을 캡처하고, 이전 버전과 비교해가며 달라진 셀렉터(Selector) 값을 찾아야 했습니다. 마치 돋보기로 숨은 그림을 찾듯, 미세한 변화 하나하나를 집어내야 하는 작업이죠.
이 과정에서 또 다른 어려움에 봉착했습니다. 업데이트된 UI는 이전보다 더 동적으로 변하는 속성을 가지고 있었습니다. 단순히 텍스트만 바뀐 것이 아니라, 클래스 이름이나 ID 등이 매번 달라지는 경우도 있었죠. 이런 경우, 고정된 셀렉터로는 더 이상 요소를 찾아내는 것이 불가능합니다.
결국, 변경된 UI 요소들을 일일이 찾아내고, 기존 셀렉터를 수정하는 작업에 착수했습니다. 3개의 프로세스 모두에 대해 이 작업을 반복해야 했죠. 때로는 예상치 못한 다른 오류까지 함께 발생하기도 해서, 문제 해결의 난이도는 더욱 높아졌습니다.
점심시간도 반납한 채, 몇 시간 동안 로봇과 씨름한 끝에 겨우 오류를 수정하고 각 프로세스를 재배포했습니다. 다행히 더 이상의 문제는 발생하지 않았고, 업무는 정상화되었습니다. 하지만 마음 한편에는 씁쓸함이 가시질 않았습니다.
‘UI 변경 탐지’, 왜 이렇게 어려울까?
이런 경험을 할 때마다 드는 생각은 ‘어떻게 하면 UI 변경을 사전에 탐지하거나, 변경되었을 때 더 빠르고 효율적으로 대응할 수 있을까?’ 하는 것입니다.
현재 제가 사용하는 RPA 툴은 기본적인 UI 요소 감지 기능을 제공하지만, 이것만으로는 충분하지 않습니다. 특히 클라이언트 측에서 시스템 업데이트를 진행할 때, RPA 팀에 사전에 공유해주지 않는 경우가 많습니다. ‘이런 작은 업데이트가 로봇에 영향을 줄까?’ 하는 안일한 생각 때문일 수도 있고, 단순히 RPA 팀의 존재 자체를 잊고 있을 수도 있습니다.
제가 생각하는 이상적인 시나리오는 다음과 같습니다.
- 사전 공유 시스템 구축: 시스템 업데이트를 진행하기 전에 RPA 팀과 협의하여, 업데이트 내용이 로봇에 미칠 영향을 미리 검토하고 필요한 조치를 취할 수 있도록 하는 것입니다.
- UI 변경 감지 솔루션 도입: RPA 툴 자체의 기능 외에, 독립적으로 UI 변경을 감지하고 알림을 주는 솔루션을 도입하는 것을 고려해볼 수 있습니다. 예를 들어, 특정 애플리케이션의 UI 구조 변화를 주기적으로 모니터링하고, 변경 사항이 감지되면 담당자에게 알림을 보내는 방식입니다.
- 강건한 셀렉터 전략: 동적으로 변하는 UI 속성에도 흔들리지 않는, 좀 더 유연하고 강건한 셀렉터 작성 전략을 연구하고 적용하는 것입니다. 예를 들어, 특정 ID나 클래스 이름에만 의존하기보다는, 여러 속성을 조합하거나, 특정 텍스트를 포함하는 요소를 찾는 방식으로 변경하는 것이죠.
하지만 현실은 그리 녹록지 않습니다. 특히 제가 경험했던 제조업이나 금융업 고객사의 경우, IT 인프라가 복잡하고 레거시 시스템이 많은 경우가 많아 이러한 시스템적인 개선이 쉽지 않습니다. 때로는 ‘왜 이렇게까지 해야 하나?’ 하는 회의감이 들기도 합니다.
RPA, ‘유지보수’라는 현실의 무게
RPA 도입 초기에는 ‘로봇이 알아서 일을 다 해줄 거야!’ 하는 기대감에 부풀어 있습니다. 하지만 막상 운영 단계에 접어들면, ‘유지보수’라는 현실의 무게를 체감하게 됩니다. 특히 UI 자동화에 크게 의존하는 로봇일수록, 그 유지보수의 중요성과 어려움은 배가 됩니다.
UI 변경은 마치 예측 불가능한 지뢰와 같습니다. 언제 어디서 터질지 모르고, 터지는 순간 업무 전체가 마비될 수 있습니다. 그렇기에 RPA 엔지니어는 끊임없이 변화하는 환경 속에서 로봇이 제 역할을 다할 수 있도록, 마치 ‘집을 지키는 파수꾼’처럼 늘 깨어 있어야 합니다.
물론, n8n과 같은 워크플로우 자동화 툴을 활용하여 API 기반의 자동화를 구축하거나, 웹 스크래핑 시에도 좀 더 안정적인 방법을 모색하는 등 UI 변경의 영향을 최소화하려는 노력도 계속하고 있습니다. 하지만 아직까지 많은 업무 프로세스가 GUI 기반의 자동화를 요구하고 있기에, UI 변경과의 싸움은 RPA 엔지니어의 숙명과도 같습니다.
오늘 제가 들려드린 이야기가 RPA를 도입하셨거나, 도입을 고려하고 계신 분들께 조금이나마 현실적인 도움과 공감을 드릴 수 있었기를 바랍니다. RPA는 분명 강력한 도구이지만, 그 힘을 제대로 발휘하기 위해서는 ‘유지보수’라는 현실적인 측면에 대한 충분한 이해와 대비가 필요하다는 점, 잊지 말아야 할 것입니다.
