2021.01.28

'열광 이면에는...' RPA의 10가지 그늘

Peter Wayner | CIO
거의 모든 SF 소설과 영화에는 로봇 집사가 등장한다. 순식간에 질문에 답하고 문제를 해결해준다. RPA라는 ‘유행어’를 만든 사람들은 이런 이미지를 이용하려 시도한 것으로 보인다. 플랫폼을 구매하는 고객들은 자질구레한 일을 컴퓨터 집사에게 넘겨, 사람은 더 큰 도전과제에 집중할 수 있을 것으로 기대한다.

반가운 소식은 이 ‘유행어’ 기술이 제법 유용하게 동작하는 사례가 많다는 것이다. RPA 도구는 사람들을 짜증나게 만드는 귀찮은 일 가운데 일부를 컴퓨터가 처리할 수 있도록 만들 수 있다는 것을 입증했다. 기업들은 이를 위해 워크플로우를 단순화하고, 데이터를 수집해 유용한 인포그래픽을 만들어내는 정교한 대시보드를 구축하고 있다. 

RPA는 또 오래된 코드를 지능적으로 조작해 수명을 늘리도록 도움을 주는 새로운 계층을 추가해 구형 시스템에 새 생명을 부여하기도 한다. 프로그래머가 아닌 사람들이 배포할 수 있는 RPA 도구들도 많다. 적합한 도구와 구현 방법을 선택하면 스프레드시트 매크로를 만들 수 있는 사람이라면 누구나 RPA를 활용해 업무 프로세스를 간소화, 능률화할 수 있다.

RPA가 부리는 마법은 명확하다. 최소한 겉보기에는 많은 수고와 고역 가운데 상당 부분을 멋지게 없애준다. 하지만 그 이면에서, RPA는 몇 가지 숨겨진 문제들을 시스템에 초래한다. 시간이 지나면서 큰 문제가 될 수도 있다.
 
Image Credit : Getty Images Bank

‘지연되지 말아야 할 것’들이 지연되는 문제
RPA의 큰 장점 중 하나는 구형 소프트웨어 패키지를 통합할 수 있는 계층을 구축할 수 있다는 점이다. 물론 모든 것을 조화시키기 위해 패키지를 처음부터 다시 쓰는 방법도 있다. 그러나 좋은 RPA 솔루션은 훨씬 더 짧은 시간에 같은 성과를 달성할 수 있다. 무언가를 급하게 고칠 때 임시방편용으로 사용하는 ‘철사’(baling wire)나 ‘씹는 껌’의 디지털 버전이라고 말할 수 있다.

이런 접근법과 방법으로 놀라운 효과를 거둘 수 있다. 생산성 향상은 처음 공개되었을 때 짜릿할 수 있다. 하지만 구형 코드가 사라진 것은 아니다. 더 깊이 숨겨지면서 더 더러워지고, 더 이상해진다.

진짜 문제 해결을 위한 지원이 감소
멋진 RPA 계층이 높은 목소리의 불평거리를 해결하는 것은 큰 성과이다. 그러나 더 깊은 문제가 사라지지 않았다. 이로 인해 또 다른 숨겨진 문제 하나가 발생할 수 있다. 누구도 더 이상 여기에 신경을 쓰거나 관심을 기울이지 않는다는 문제이다.

지금 당장 만족을 준 일시적인 문제 해결이 구형 코드 문제를 한꺼번에 해결하기 위해 예산을 배정받으려는 노력을 방해할 수 있다. 지금 당장은 경영진들의 귀에 불평의 소리가 들리지 않을 것이기 때문이다. 경영진들은 RPA의 ‘겉치장’ 계층이 문제를 해결했기 때문에, 다른 곳에 예산을 지출할 수 있다고 생각한다. 

복잡성 증가
일반 사용자는 RPA 솔루션이 모든 것을 단순화하고 있다고 생각할 수 있지만, RAP 표면 아래에서는 모든 것이 조금 더 복잡해지고 있다. 과거 지저분한 코드 계층이 N이었다면, 지금은 N+1이 된 것이다. 이는 디버깅과 유지관리를 더 어렵게 만든다. 문제가 발생하면 버그가 초래된 한 장소를 찾기 희망하면서 N+1의 계층을 뒤져야 한다.

구형 버그가 지속적으로 존재
RPA 솔루션이 오래된 코드의 추악함을 숨길 수 있을지 모르지만, 깊숙이 위치한 버그나 한계를 해결할 수는 없다. 좋은 소식은 더 스마트한 RPA 계층이 잠재적인 문제들 가운데 일부를 차단할 수 있다는 것이다. 그러나 때론 썩은 베란다에 새로 페인트를 덧칠한 것에 불과할 수도 있다.

데이터 번역 비용이 발생할 수 있음
일부 라이브러리가 요구하는 데이터 형식에 맞춰 비트를 재배열하고, 이후 답이 돌아오면 다른 장소에 다른 형식으로 이를 저장하기 비트를 다시 배열하는 코딩이 좋은 코딩인 경우가 많다. 코드의 일부는 날짜에서 연도를 가장 먼저 표시하기 원하지만, 또 다른 일부는 연도를 가장 마지막에 표시하기 원한다. 과거 악의적인 유머 감각을 지닌 사람이 월이 0부터 시작하도록 자바 유틸리티를 조작했던 바 있다(1월이 ‘0’). 이로 인해, 2월은 ‘1’인 달이 되었다. 그러나 달의 첫 번째 날짜는 1이다. 

많은 RPA 스택은 이런 번역 가운데 일부를 자동으로 처리해줄 수 있다. 즉 더 쉽게 유용한 소프트웨어를 구축할 수 있다. 그러나 이 무한한 번역 작업을 처리하기 위해 필요한 기반이 되는 작업이 없어지지 않는다. 서버가 더 강력해야 하고, 더 비싼 전기료로 이런 데이터 작업에 대한 비용을 지불하게 될 것이다. 

많은 경우 큰 비용이 아닐 것이다. 그러나 대규모로 운영할 경우, 확장에 따른 비용이 아주 커질 수 있다. 어느 시점에는 프로그래머들로 구성된 팀을 채용, 깨끗한 ‘수동’ 코드를 작성하는 것이 가치가 있을 수도 있다.

현업 부문의 ‘슈퍼유저’는 프로그래밍 역량이 없음
C급 경영진부터 파트타임 인턴까지 RPA 도구를 사용, 약간의 수고와 고생만으로 무언가를 성취할 수 있다. 자동화는 정말 효과가 있다. 그러나 이런 초능력이 실제 존재하더라도, 이를 효과적으로 활용하는 방법을 이해하는 지혜는 수반되지 않는다. 

프로그래머는 데이터 구조에 대해 알고 있으며, 잘못된 형식의 날짜 등 컴퓨터의 특이한 동작과 방식을 이해하는 데 이미 많은 시간을 투자했다. 프로그래머는 네트워크를 이해한다. 또 컴퓨터와 시스템 아키텍처의 기본 규칙과 원리를 안다. 이런 모든 ‘직관’들은 RPA를 견인하는 다양한 ‘주술’들을 결합할 때 아주 중요한 역할을 한다.

여전히 최상의 선택은 프로그래머
비즈니스 사용자가 RPA를 구현할 수 있다는 ‘홍보 문구’에도 불구하고, 여전히 RPA 도구를 가장 효과적이고 효율적으로 사용할 수 있는 사람은 프로그래머이다. 각 스택 계층을 작업한 오랜 경험을 갖고 있다. 데이터베이스가 신속하게 답변할 수 있는 종류의 쿼리, 머신을 매우 느리게 만드는 JOIN이 가득한 것이 무엇인지 알고 있다. 오랜 경험 덕분에 프로그래머는 올바른  질문들을 묻는 방법에 대해 잘 알고 있다. 

RPA 도구가 10배의 효과를 낸다고 가정하자. 다시 10배 이상의 역량을 발휘할 수 있는 ‘스타’ 프로그래머에게 RPA 도구를 주면, 100배가 많은 ‘처리량’이 달성될 것이다. 레버리지가 갑절이 될 수 있다는 의미이다.

지원의 ‘광범위함’이 때로는 단점
대부분 RPA 도구 벤더들은 수많은 API 형식과 대화할 수 있으며, 수많은 제품과 상호작용할 수 있다고 강조한다. 대체적으로 옳은 주장이다. 그러나 결과가 완벽한 것과는 거리가 먼 경우가 많다. RPA 벤더들은 광범위한 지원에 대한 요구에 응답하고 있지만, 이런 ‘광범위함’을 유지하고, 지탱하기 힘들다.

연결부를 통해 흐르는 데이터에 버그나 결함이 있는 경우가 아주 많다. 때론 날짜 형식이 이상할 수도 있다. 때론 ‘null’이 초래될 수도 있다. 이런 식의 결함이 아주 많다. 치명적이지 않을 수 있지만, 실수를 정리하거나, 결함을 없애야 할 또 다른 계층이 추가될 수도 있다.

관료적이고 번잡한 절차를 제거하는 데 한계가 있음
RPA 도구는 워크플로우를 단순화시킨다. 그러나 대부분의 프로세스 병목은 컴퓨터나 RPA와 관련이 없다. 사람인 누군가로 인해 워크플로우에 단계들이 추가되었을 수 있다. 이런 문제가 수십년 전에 발생한 문제인 경우가 많다. 가캔자스 사무실의 누군가 포틀랜드 사무실에서 조언을 얻지 못해 100만 달러를 손해볼 수 있다. 인턴 가운데 사기꾼이 있을지 모른다.

우수한 RPA 소프트웨어들은 이런 문제들 가운데 일부를 경감시킬 수 있다. 그러나 제거하지는 못한다. 누군가 홍콩의 팀이 모든 인보이스를 승인해야 한다고 결정했다고 가정하자. RPA 스윗은 홍콩의 팀을 위해 문서들을 조금 더 체계화해 통합할 수 있도록 도움을 줄 수 있을 뿐이다. 소프트웨어가 이런 업무를 없앨 수는 없다. 진짜 복잡한 문제의 원인은 사람이다. RPA를 지나치게 크게 의존하면, 프로세스 간소화와 관련된 진짜 과업을 파악하지 못할 수도 있다.

게이트 키핑의 부실화
이유가 있어 생성된 ‘관료적인 절차’들이 많다. 숨겨진 위험 중 하나는 RPA로 속도를 내면서, 사람인 ‘게이트 키퍼’가 문제를 주시하지 않게 되는 것이다. RPA가 힘든 일을 해줄 것이라고 가정하기 때문이다. 이들은 대시보드에 로그인한 후, TV나 팟캐스트를 보면서 업무를 처리한다. RPA가 이상한 사례를 파악할 것이기에 세부 사항에 지나치게 신경 쓸 이유가 없다고 생각하기 때문이다.

어쩌면 컴플라이언스나 부정행위(사기) 방지와 관련된 힘든 작업들을 제대로 자동화할 방법은 없을지도 모른다. 악당들은 시스템을 탐지, RPA의 작은 약점들을 모두 악용할 것이다. 때론 시스템에 ‘프릭션(마찰점)’을 만들 필요가 있다. 때론 무언가를 너무 쉽게 만드는 것이 실수가 될 수도 있다. ciokr@idg.co.kr



2021.01.28

'열광 이면에는...' RPA의 10가지 그늘

Peter Wayner | CIO
거의 모든 SF 소설과 영화에는 로봇 집사가 등장한다. 순식간에 질문에 답하고 문제를 해결해준다. RPA라는 ‘유행어’를 만든 사람들은 이런 이미지를 이용하려 시도한 것으로 보인다. 플랫폼을 구매하는 고객들은 자질구레한 일을 컴퓨터 집사에게 넘겨, 사람은 더 큰 도전과제에 집중할 수 있을 것으로 기대한다.

반가운 소식은 이 ‘유행어’ 기술이 제법 유용하게 동작하는 사례가 많다는 것이다. RPA 도구는 사람들을 짜증나게 만드는 귀찮은 일 가운데 일부를 컴퓨터가 처리할 수 있도록 만들 수 있다는 것을 입증했다. 기업들은 이를 위해 워크플로우를 단순화하고, 데이터를 수집해 유용한 인포그래픽을 만들어내는 정교한 대시보드를 구축하고 있다. 

RPA는 또 오래된 코드를 지능적으로 조작해 수명을 늘리도록 도움을 주는 새로운 계층을 추가해 구형 시스템에 새 생명을 부여하기도 한다. 프로그래머가 아닌 사람들이 배포할 수 있는 RPA 도구들도 많다. 적합한 도구와 구현 방법을 선택하면 스프레드시트 매크로를 만들 수 있는 사람이라면 누구나 RPA를 활용해 업무 프로세스를 간소화, 능률화할 수 있다.

RPA가 부리는 마법은 명확하다. 최소한 겉보기에는 많은 수고와 고역 가운데 상당 부분을 멋지게 없애준다. 하지만 그 이면에서, RPA는 몇 가지 숨겨진 문제들을 시스템에 초래한다. 시간이 지나면서 큰 문제가 될 수도 있다.
 
Image Credit : Getty Images Bank

‘지연되지 말아야 할 것’들이 지연되는 문제
RPA의 큰 장점 중 하나는 구형 소프트웨어 패키지를 통합할 수 있는 계층을 구축할 수 있다는 점이다. 물론 모든 것을 조화시키기 위해 패키지를 처음부터 다시 쓰는 방법도 있다. 그러나 좋은 RPA 솔루션은 훨씬 더 짧은 시간에 같은 성과를 달성할 수 있다. 무언가를 급하게 고칠 때 임시방편용으로 사용하는 ‘철사’(baling wire)나 ‘씹는 껌’의 디지털 버전이라고 말할 수 있다.

이런 접근법과 방법으로 놀라운 효과를 거둘 수 있다. 생산성 향상은 처음 공개되었을 때 짜릿할 수 있다. 하지만 구형 코드가 사라진 것은 아니다. 더 깊이 숨겨지면서 더 더러워지고, 더 이상해진다.

진짜 문제 해결을 위한 지원이 감소
멋진 RPA 계층이 높은 목소리의 불평거리를 해결하는 것은 큰 성과이다. 그러나 더 깊은 문제가 사라지지 않았다. 이로 인해 또 다른 숨겨진 문제 하나가 발생할 수 있다. 누구도 더 이상 여기에 신경을 쓰거나 관심을 기울이지 않는다는 문제이다.

지금 당장 만족을 준 일시적인 문제 해결이 구형 코드 문제를 한꺼번에 해결하기 위해 예산을 배정받으려는 노력을 방해할 수 있다. 지금 당장은 경영진들의 귀에 불평의 소리가 들리지 않을 것이기 때문이다. 경영진들은 RPA의 ‘겉치장’ 계층이 문제를 해결했기 때문에, 다른 곳에 예산을 지출할 수 있다고 생각한다. 

복잡성 증가
일반 사용자는 RPA 솔루션이 모든 것을 단순화하고 있다고 생각할 수 있지만, RAP 표면 아래에서는 모든 것이 조금 더 복잡해지고 있다. 과거 지저분한 코드 계층이 N이었다면, 지금은 N+1이 된 것이다. 이는 디버깅과 유지관리를 더 어렵게 만든다. 문제가 발생하면 버그가 초래된 한 장소를 찾기 희망하면서 N+1의 계층을 뒤져야 한다.

구형 버그가 지속적으로 존재
RPA 솔루션이 오래된 코드의 추악함을 숨길 수 있을지 모르지만, 깊숙이 위치한 버그나 한계를 해결할 수는 없다. 좋은 소식은 더 스마트한 RPA 계층이 잠재적인 문제들 가운데 일부를 차단할 수 있다는 것이다. 그러나 때론 썩은 베란다에 새로 페인트를 덧칠한 것에 불과할 수도 있다.

데이터 번역 비용이 발생할 수 있음
일부 라이브러리가 요구하는 데이터 형식에 맞춰 비트를 재배열하고, 이후 답이 돌아오면 다른 장소에 다른 형식으로 이를 저장하기 비트를 다시 배열하는 코딩이 좋은 코딩인 경우가 많다. 코드의 일부는 날짜에서 연도를 가장 먼저 표시하기 원하지만, 또 다른 일부는 연도를 가장 마지막에 표시하기 원한다. 과거 악의적인 유머 감각을 지닌 사람이 월이 0부터 시작하도록 자바 유틸리티를 조작했던 바 있다(1월이 ‘0’). 이로 인해, 2월은 ‘1’인 달이 되었다. 그러나 달의 첫 번째 날짜는 1이다. 

많은 RPA 스택은 이런 번역 가운데 일부를 자동으로 처리해줄 수 있다. 즉 더 쉽게 유용한 소프트웨어를 구축할 수 있다. 그러나 이 무한한 번역 작업을 처리하기 위해 필요한 기반이 되는 작업이 없어지지 않는다. 서버가 더 강력해야 하고, 더 비싼 전기료로 이런 데이터 작업에 대한 비용을 지불하게 될 것이다. 

많은 경우 큰 비용이 아닐 것이다. 그러나 대규모로 운영할 경우, 확장에 따른 비용이 아주 커질 수 있다. 어느 시점에는 프로그래머들로 구성된 팀을 채용, 깨끗한 ‘수동’ 코드를 작성하는 것이 가치가 있을 수도 있다.

현업 부문의 ‘슈퍼유저’는 프로그래밍 역량이 없음
C급 경영진부터 파트타임 인턴까지 RPA 도구를 사용, 약간의 수고와 고생만으로 무언가를 성취할 수 있다. 자동화는 정말 효과가 있다. 그러나 이런 초능력이 실제 존재하더라도, 이를 효과적으로 활용하는 방법을 이해하는 지혜는 수반되지 않는다. 

프로그래머는 데이터 구조에 대해 알고 있으며, 잘못된 형식의 날짜 등 컴퓨터의 특이한 동작과 방식을 이해하는 데 이미 많은 시간을 투자했다. 프로그래머는 네트워크를 이해한다. 또 컴퓨터와 시스템 아키텍처의 기본 규칙과 원리를 안다. 이런 모든 ‘직관’들은 RPA를 견인하는 다양한 ‘주술’들을 결합할 때 아주 중요한 역할을 한다.

여전히 최상의 선택은 프로그래머
비즈니스 사용자가 RPA를 구현할 수 있다는 ‘홍보 문구’에도 불구하고, 여전히 RPA 도구를 가장 효과적이고 효율적으로 사용할 수 있는 사람은 프로그래머이다. 각 스택 계층을 작업한 오랜 경험을 갖고 있다. 데이터베이스가 신속하게 답변할 수 있는 종류의 쿼리, 머신을 매우 느리게 만드는 JOIN이 가득한 것이 무엇인지 알고 있다. 오랜 경험 덕분에 프로그래머는 올바른  질문들을 묻는 방법에 대해 잘 알고 있다. 

RPA 도구가 10배의 효과를 낸다고 가정하자. 다시 10배 이상의 역량을 발휘할 수 있는 ‘스타’ 프로그래머에게 RPA 도구를 주면, 100배가 많은 ‘처리량’이 달성될 것이다. 레버리지가 갑절이 될 수 있다는 의미이다.

지원의 ‘광범위함’이 때로는 단점
대부분 RPA 도구 벤더들은 수많은 API 형식과 대화할 수 있으며, 수많은 제품과 상호작용할 수 있다고 강조한다. 대체적으로 옳은 주장이다. 그러나 결과가 완벽한 것과는 거리가 먼 경우가 많다. RPA 벤더들은 광범위한 지원에 대한 요구에 응답하고 있지만, 이런 ‘광범위함’을 유지하고, 지탱하기 힘들다.

연결부를 통해 흐르는 데이터에 버그나 결함이 있는 경우가 아주 많다. 때론 날짜 형식이 이상할 수도 있다. 때론 ‘null’이 초래될 수도 있다. 이런 식의 결함이 아주 많다. 치명적이지 않을 수 있지만, 실수를 정리하거나, 결함을 없애야 할 또 다른 계층이 추가될 수도 있다.

관료적이고 번잡한 절차를 제거하는 데 한계가 있음
RPA 도구는 워크플로우를 단순화시킨다. 그러나 대부분의 프로세스 병목은 컴퓨터나 RPA와 관련이 없다. 사람인 누군가로 인해 워크플로우에 단계들이 추가되었을 수 있다. 이런 문제가 수십년 전에 발생한 문제인 경우가 많다. 가캔자스 사무실의 누군가 포틀랜드 사무실에서 조언을 얻지 못해 100만 달러를 손해볼 수 있다. 인턴 가운데 사기꾼이 있을지 모른다.

우수한 RPA 소프트웨어들은 이런 문제들 가운데 일부를 경감시킬 수 있다. 그러나 제거하지는 못한다. 누군가 홍콩의 팀이 모든 인보이스를 승인해야 한다고 결정했다고 가정하자. RPA 스윗은 홍콩의 팀을 위해 문서들을 조금 더 체계화해 통합할 수 있도록 도움을 줄 수 있을 뿐이다. 소프트웨어가 이런 업무를 없앨 수는 없다. 진짜 복잡한 문제의 원인은 사람이다. RPA를 지나치게 크게 의존하면, 프로세스 간소화와 관련된 진짜 과업을 파악하지 못할 수도 있다.

게이트 키핑의 부실화
이유가 있어 생성된 ‘관료적인 절차’들이 많다. 숨겨진 위험 중 하나는 RPA로 속도를 내면서, 사람인 ‘게이트 키퍼’가 문제를 주시하지 않게 되는 것이다. RPA가 힘든 일을 해줄 것이라고 가정하기 때문이다. 이들은 대시보드에 로그인한 후, TV나 팟캐스트를 보면서 업무를 처리한다. RPA가 이상한 사례를 파악할 것이기에 세부 사항에 지나치게 신경 쓸 이유가 없다고 생각하기 때문이다.

어쩌면 컴플라이언스나 부정행위(사기) 방지와 관련된 힘든 작업들을 제대로 자동화할 방법은 없을지도 모른다. 악당들은 시스템을 탐지, RPA의 작은 약점들을 모두 악용할 것이다. 때론 시스템에 ‘프릭션(마찰점)’을 만들 필요가 있다. 때론 무언가를 너무 쉽게 만드는 것이 실수가 될 수도 있다. ciokr@idg.co.kr

X