약 8분 읽기
안녕하세요, 황민입니다. 오늘은 제가 RPA 엔지니어로서 처음 UiPath RE Framework를 마주했을 때, 가장 어렵게 느껴졌던 ‘트랜잭션’ 개념에 대해 이야기해보려고 합니다. 솔직히 말해서, 처음에는 이 프레임워크의 구조 자체가 좀 낯설었어요. 특히 Get Transaction Data와 Process Transaction의 역할 분담이 왜 이렇게 나뉘어 있는지, 실제 업무에 어떻게 적용해야 하는지 감이 잘 잡히지 않았죠. 오늘은 제가 이 개념을 이해하기까지 겪었던 시행착오와 그 과정에서 얻은 인사이트를 솔직하게 공유해 드릴게요.
처음 RE Framework를 만났을 때의 막막함
RPA 엔지니어로서 다양한 업무 자동화를 진행하면서, 저는 반복적인 패턴을 가진 프로세스를 효율적으로 관리하는 것이 중요하다는 것을 깨달았습니다. 그러던 중 UiPath RE Framework를 접하게 되었어요. 처음에는 ‘와, 이렇게 체계적으로 관리할 수 있다니!’라는 기대감에 부풀었죠. 하지만 프레임워크 구조를 살펴보니, Initialize All Applications, Set Transaction Status, Log Out 등 익숙한 단어들 사이로 Get Transaction Data와 Process Transaction이라는 낯선 녀석들이 눈에 띄었습니다.
이 두 가지 활동이 정확히 어떤 역할을 하는지, 왜 분리되어야 하는지가 제게는 큰 의문이었어요. 마치 잘 짜여진 오케스트라처럼 각자의 역할이 명확해야 하는데, 저는 그 악기들의 소리가 왜 그렇게 나뉘어야 하는지 이해하지 못했던 거죠. 마치 요리사가 재료를 다듬는 과정과 실제로 요리하는 과정을 왜 분리해야 하는지 묻는 것과 같았습니다. 아니, 그 이상이었을지도 몰라요. 제 머릿속에서는 모든 과정이 하나로 쭉 이어져야 한다고 생각했거든요.
Get Transaction Data와 Process Transaction, 무엇이 다른가?
처음에는 Get Transaction Data가 단순히 다음 처리할 데이터를 가져오는 역할이라고만 생각했습니다. 그리고 Process Transaction은 가져온 데이터를 가지고 실제 업무 로직을 수행하는 것이라고요. 그런데 막상 실제 프로세스를 만들어보니, 이게 전부가 아니더군요.
예를 들어, 특정 시스템에서 여러 건의 데이터를 처리해야 하는 상황을 가정해 볼게요. 만약 Process Transaction 안에서 데이터를 가져오고, 처리하고, 상태를 업데이트하는 모든 것을 한 번에 해결한다면 어떻게 될까요? 데이터 처리 중 오류가 발생했을 때, 어디서 문제가 생겼는지 정확히 파악하기가 어려워집니다. 또한, 동일한 데이터를 여러 번 다시 가져와 처리하려 할 수도 있고요. 이는 비효율을 넘어 데이터의 무결성을 해칠 수도 있는 심각한 문제입니다.
여기서 Get Transaction Data의 진정한 역할이 드러납니다. 이 활동은 ‘처리할 다음 트랜잭션(데이터 묶음)을 식별하고 준비하는 역할’을 합니다. 단순히 데이터를 가져오는 것을 넘어, ‘이 데이터는 아직 처리되지 않았는가?’, ‘이 데이터는 현재 처리 가능한 상태인가?’ 등을 판단하여 다음 단계로 넘겨줄 준비를 하는 것이죠. 마치 물류창고에서 다음 배송할 물건을 분류하고 포장하는 작업과 비슷하다고 할 수 있습니다.
반면에 Process Transaction은 Get Transaction Data로부터 받은 ‘준비된’ 트랜잭션을 가지고 실제 비즈니스 로직을 수행합니다. 여기서 중요한 것은, Process Transaction은 자신이 처리할 데이터 외의 다른 트랜잭션에 대해서는 신경 쓰지 않는다는 점입니다. 오로지 주어진 트랜잭션 하나에 집중하는 것이죠. 마치 조립 라인에서 각 작업자는 자신이 맡은 부품 조립에만 집중하는 것처럼 말입니다.
실제 경험으로 이해한 트랜잭션의 중요성
이 개념을 확실히 이해하게 된 계기는 특정 금융사의 고객 정보 업데이트 자동화 프로젝트였습니다. 수만 건의 고객 데이터를 특정 시스템에 입력하고, 그 결과를 다른 시스템에 반영하는 복잡한 프로세스였죠. 처음에는 모든 로직을 하나의 큰 프로세스로 묶어서 개발하려고 했습니다. 하지만 데이터 처리 중간에 시스템 오류가 발생하거나, 특정 데이터의 형식이 잘못되어 예외 처리가 필요한 경우가 빈번하게 발생했어요.
문제가 생길 때마다 전체 프로세스를 처음부터 다시 실행해야 했고, 어느 부분에서 문제가 발생했는지 추적하는 데만 엄청난 시간을 쏟아야 했습니다. 마치 꼬리에 꼬리를 무는 오류의 늪에 빠진 기분이었죠. 그때서야 저는 RE Framework의 트랜잭션 기반 구조의 필요성을 절감했습니다.
저는 이 프로젝트를 RE Framework로 재설계했습니다. Get Transaction Data에서는 아직 처리되지 않은 고객 데이터를 순차적으로 가져오고, 데이터 유효성 검사를 수행했습니다. 유효성 검사를 통과한 데이터만 Process Transaction으로 넘겨주었죠. Process Transaction에서는 실제 시스템에 데이터를 입력하고, 처리 결과를 기록했습니다. 만약 Process Transaction에서 오류가 발생하면, Set Transaction Status 활동을 통해 해당 트랜잭션을 ‘실패’로 표시하고, 오류 로그를 기록했습니다. 이렇게 함으로써, 실패한 트랜잭션은 다음 실행 시 Get Transaction Data 단계에서 다시 걸러져 재처리되거나, 관리자가 직접 확인하여 조치할 수 있게 되었습니다.
이 경험을 통해 저는 트랜잭션 개념이 단순히 데이터를 나누는 것을 넘어, 오류 관리, 재처리 메커니즘, 그리고 프로세스의 안정성을 확보하는 핵심 요소라는 것을 확실히 깨달았습니다. 마치 건물을 지을 때 각 층을 구분하고, 각 층마다 필요한 설비를 갖추는 것처럼, 트랜잭션 단위로 업무를 분리하면 전체 시스템이 훨씬 견고해진다는 것을 몸소 체험한 것이죠.
언제 RE Framework와 트랜잭션을 써야 할까?
그렇다면 모든 RPA 프로젝트에 RE Framework와 트랜잭션 개념을 적용해야 할까요? 제 경험상, 반복적으로 처리해야 할 데이터가 많고, 각 데이터 처리 과정에서 발생할 수 있는 다양한 예외 상황을 관리해야 하는 경우에 RE Framework가 매우 유용합니다.
- 대량의 데이터 처리: 수백, 수천 건 이상의 데이터를 처리해야 할 때, 트랜잭션 단위로 관리하면 효율성을 높이고 오류 발생 시 영향을 최소화할 수 있습니다.
- 복잡한 비즈니스 로직: 각 데이터마다 다른 처리 로직이 적용되거나, 여러 시스템을 거쳐야 하는 복잡한 프로세스에 적합합니다.
- 안정적인 재처리 메커니즘 필요: 시스템 불안정, 네트워크 오류 등으로 인해 중간에 프로세스가 중단될 가능성이 있는 환경에서, 실패한 트랜잭션을 재처리할 수 있는 기능이 중요할 때 사용합니다.
- 로깅 및 모니터링 중요: 각 트랜잭션의 처리 상태를 상세하게 기록하고 모니터링해야 하는 경우, RE Framework의 트랜잭션 상태 관리 기능이 빛을 발합니다.
반면에, 단순히 하나의 파일을 복사하거나, 몇 개의 고정된 값을 입력하는 등 매우 단순하고 예외 발생 가능성이 낮은 프로세스라면, 굳이 RE Framework를 도입하기보다는 더 간단한 구조로 개발하는 것이 효율적일 수 있습니다. 복잡성을 더하는 것 자체가 오히려 개발 및 유지보수 비용을 증가시킬 수 있기 때문입니다.
마무리하며: 삽질은 성장의 밑거름
RE Framework의 트랜잭션 개념을 완전히 이해하기까지 저는 꽤 많은 시간을 투자했습니다. 처음에는 왜 이렇게 복잡하게 만들어야 하는지 의문을 품었지만, 실제 프로젝트를 통해 그 가치를 깨닫고 나니 이제는 어떤 복잡한 업무 자동화 프로젝트를 만나더라도 자신감을 가질 수 있게 되었습니다.
여러분도 혹시 RE Framework를 처음 접하고 막막함을 느끼고 계신가요? 괜찮습니다. 저도 그랬으니까요. 중요한 것은 포기하지 않고 직접 부딪혀보면서, 실패를 통해 배우고 성장하는 과정입니다. 제가 겪었던 시행착오가 여러분의 RPA 여정에 작은 도움이 되기를 바랍니다. 앞으로도 RPA 엔지니어로서의 다양한 경험과 인사이트를 꾸준히 공유하도록 하겠습니다. 감사합니다!
