RPA 도입, 때로는 악몽이 될 수 있다

데브옵스 파이프라인 자동화, 로보틱 프로세스 자동화(RPA)를 도입했거나 검토하는 기업이 늘고 있다. 그러나 자칫 결함을 내포한 상태로 이를 도입하면 끝없는 골칫거리로 이어질 수 있다.

여기 현실 속 사례에서 확인할 수 있는 교훈을 함께 살펴봅시다.

자동화 지옥에 빠지지 않는 6가지 방법

​ 2015년, 수석 소프트웨어 엔지니어 벤자민 윌렌브링은 소속 기업 오토데스크가 소프트웨어 테스트에 자동화를 도입하자 흥분의 도가니에 빠졌다. 그러나 흥분은 그리 오래가지 않았다. 소규모 자동화팀은 그의 부서와 제대로 소통하지 않았으며, 업무 현장에 도입된 자동화 테스트는 원하던 결과물을 산출하지 못했다. ​ 윌런브링은 “팀원들이 테스트가 실패했다고 입을 모았다. 실제로 테스트를 실시하기가 매우 어려웠으며 문서화되어 있지 않았고 누군가와 상의를 해야 했다. 그리고 파일의 양이 엄청났으며 그 이유를 알 수 없었다”라고 말했다. ​ 자동화를 통해 윌렌브링의 업무 부담이 감소했어야 했다. 결과는 오히려 반대였다. 이로 인한 문제 때문에 많은 에너지를 쏟아 부어야 했다. ​ 애석하게도 윌렌브링과 같은 사례는 꽤 흔하다. 자동화가 빠르게 확산되면서 늘어나고 있는 사례이기도 하다. ​ 데브옵스 워크플로우 자동화에서부터 RPA까지 자동화된 프로세스의 목표는 쓸모 없는 작업을 줄여 숙련된 직원들이 더 높은 수준의 업무를 처리할 수 있도록 하는 것이다. 하지만 결함이 있는 부분 또는 잘못된 롤아웃 때문에 자동화에 대한 꿈이 악몽이 될 수 있다. 여러 IT전문가로부터 자동화 실패 이야기를 들어봤다. 또 이런 자동화 이니셔티브의 결말을 피하는데 도움이 되는 6가지 방법을 추려봤다. ​ 1. 자동화는 모두의 작업이어야 한다 ​ 윌렌브링의 자동화된 시험 지옥은 한 가지 중요한 문제가 있었다. 자동화된 시험에 대해 이해하는 사람들이라고는 이를 구축한 사람들 밖에 없었으며 그들은 윌렌브링의 부서와 다른 도시에 거주하고 있었다. ​ 윌렌브링은 “테스트 프레임워크의 어려움 중 하나는 실패가 발생했을 때 제대로 된 피드백을 제공하지 못했다는 것이다. 무엇인가 실패하면 우선 슬랙을 이용해 책임자에게 ‘왜 실패했나?’라고 질문해야 했다. 이 과정에서 우리는 결과를 볼 수 있는 특수 버전의 프레임워크를 다시 수동으로 실시한 후 어떤 일이 발생했는지 알려줘야 했다”라고 말했다. ​ DXC 테크놀로지스의 글로벌 데브옵스 제품 관리자 로버트 하스에 따르면 모든 자동화 체계가 준수해야 하는 2가지 기본적인 규칙이 있다. 그리고 오토데스크의 테스트 프레임워크는 이 두 규칙을 모두 어겼다. ​ 첫 번째는 자동화 코드를 문서화해야 한다는 것이다. 하스는 “코드형 문서화 같은 현대적인 접근방식을 사용하거나 비지오(Visio) 다이어그램에 주석을 달 때 처음에 무엇을 했는지 설명하는 문서가 있다면 문제 해결이 더 쉬워진다”라고 말했다. ​ 윌렌브링의 팀은 문서의 부재로 인해 자동화된 테스트를 이해할 수 없었다. 결과는 당연히 실패로 이어졌고 테스트와 개발 팀에 대한 신뢰를 잃었다. 윌렌브링은 “한 개발자는 ‘실패할 리가 없다’라고 말했다. 그러나 테스트 프레임워크에 실질적인 문제가 있었다. 이는 신뢰의 문제로 이어졌다”라고 말했다. ​ 두번째 규칙은 “제공하는 비즈니스 가치에 기초하여 자동화해야 하는 활동의 우선순위를 결정하라”다. 하지만 오토데스크의 시험팀은 개발팀과 완전히 분리되어 있었으며, 윌렌브링은 테스트를 위해 선택된 자신의 코드베이스의 많은 부분이 상식에 반하고 있었다는 사실을 발견했다. ​ 윌렌브링은 “무엇이 중요한지 이해하는 해당 주제의 전문가가 시험 대상을 선택할 수 있도록 허용해야 한다. 여러 가지 버그 티켓만 살펴본다면 시험 자체가 무엇인가 유의미한 것을 정확하게 반영하고 있다는 보장이 없다”라고 말했다. ​ 새로운 엔지니어링 책임자가 윌렌브링과 그의 팀을 이 악순환으로부터 빼내야 했다. 새로운 책임자는 테스트 자동화를 포함하여 “모두가 품질에 책임져야 한다”라고 지시했다. 중앙집중식 시험은 무산되었으며 각 부서는 자체적으로 개발한 코드에 대한 시험을 개발할 책임이 주어졌다. ​ 윌렌브링과 그의 팀은 이제 필요에 따라 시험을 조정하고 해당 프로세스를 일상 생활에 통합할 수 있게 되었다. 그는 “궁극적으로 ‘그것은 내 일이 아니다’라는 태도를 절대로 허용하지 않는 정책을 수립해야 한다”라고 말했다. ​ (대화를 나눈 후 영감을 얻은 윌렌브링은 자신의 자동화 여정에 대한 자세한 설명을 작성했으며, 여기에는 그가 처리했던 셀레니움(Selenium)과 싸이프레스(Cypress) 시험 프레임워크 등에 대한 심도 깊은 자료가 포함되어 있다.)

2. 복잡성에 대비하라

보안 및 준수성 자동화 벤더 트립와이어는 최근 대형 금융 고객사 중 한 곳에서 이상한 조짐을 발견했다.

트립와이어의 캐나다 관리자 이르판 킴지는 “우리의 솔루션이 자동화된 방식으로 배치됨에 있어 지나치게 오랜 시간이 걸렸다. 라이선스 사용률이 크게 증가하지 않는 이유가 무엇일까? 당초 예상대로라면 정말로 빠르게 보급되어야 했다”라고 말했다.

결국 대부분 자동화된 CI/CD 파이프라인에 대한 지연 현상은 금융조직의 여러 사업부가 각각 자체적인 맞춤형 소프트웨어 구성요소에 의존하고 있다는 현실 때문인 것으로 확인됐다.

킴지는 “30개 이상의 앱을 통합하려 했으며 이런 앱의 각 변종, 즉 다양한 라이브러리 등에 필요한 모듈의 상품화 문제에 직면했다. 이 모든 변종을 처리하기 위해 파이프라인을 조정하는 과정에서 자동화 프로세스의 속도가 크게 저하됐다. 단순히 한 번의 클릭으로 끝나는 것이 아니라 몇 번의 클릭을 거쳐 다양한 기술이 각각 서로 호환되며 배치될 수 있는지 확인해야 했다”라고 말했다.

이 문제를 해결할 마법의 탄환은 없다. 그럼에도 불구하고 자동화된 프로세스의 구성요소의 수가 증가하면서 이런 구성요소를 연결해야 하는 배관의 양이 기하급수적으로 훨씬 복잡하게 증가한다는 사실은 알 필요가 있다. 이런 복잡성으로 인해 자동화된 프로세스로 이행하면서 시간과 자원이 추가된다.

연결하는 구성요소가 몇 개인지 뿐만이 아니라 어디에서부터 오는지에 대한 요소도 복잡성을 증가시킨다. 대부분의 파이프라인 또는 RPA 주도적인 환경에는 이질적인 자체 및 제3자 구성요소가 포함되기 마련이며, 후자의 요소에서 무엇인가 잘못되었을 때 정말로 문제가 될 수 있다.

DXC 테크놀로지의 하스는 “CI/CD 파이프라인 또는 자동화된 프로세스의 모든 구성요소에 대해 소프트웨어 제공자와 유지보수 계약을 체결해야 한다. 오픈소스 구성요소가 있다면 위험 평가를 수행해야 한다. 오픈소스 커뮤니티의 웹 기반 지원에 의존하는 대신에 해당 제품의 관리형 버전 사용을 고려해야 하는지 판단할 필요가 있다”라고 말했다.

3. ‘블랙박스’를 인지하라

오늘날 금융기관은 열심히 RPA 및 챗봇을 배치하고 있다. 아이세라(Aisera)의 공동 설립자인 무두 수다카르는 자신이 목격한 흔한 실패 시나리오가 있다고 경고했다. 프로세스가 하나의 단일 기능 단위로 인식되고 문제해결을 위해 내부 활동을 분리하기 어려운 ‘블랙박스’가 되는 현상이다.

그는 “단일 기능 구조에서 고객은 자신의 계정의 상태를 확인하고 돈을 인출하여 옮기고 싶은 상황을 상정해보자. 무엇인가 잘못되고 그 단계를 감시하지 않으면 문제가 발생할 때 돈을 되찾을 수 있는 유일한 방법은 고객 서비스를 요청하는 것이다. 이를 위해 은행에 직접 방문해야 할 수도 있다”라고 말했다.

수다카르는 이런 종류의 디자인이 조직의 초기 자동화 이니셔티브의 결과물인 경우가 많다고 전했다. 모든 것이 계획대로 되는 한 좋은 결과를 낼 수 있다. 하지만 그렇지 않은 경우 조직은 일반적으로 설계 단계로 되돌아가 이런 블랙박스를 분리시켜야 하게 된다.

그는 “각 프로세스를 감사 및 모니터링이 가능한 구성 요소로 분리하라”라고 말했다.

4. 확인과 균형을 내재하라

아리 메이즐은 레스 두잉(Less Doing)의 설립자이며 생산성 코치로, 힘들고 단조로운 일을 자동화하는데 관심이 많다. 그는 자신의 기업에도 자동화를 구축하는 경우가 많다. 하지만 그는 주차 위반 딱지를 피하려다가 중요한 교훈을 얻었다.

메이즐의 회사에는 픽업 트럭(영업용 차량)이 있었고 그가 거주하는 뉴욕시에서는 이런 차량의 소유자가 위반 딱지에 대한 이의를 쉽게 제기할 수 있다. 이를테면 “나는 배달을 하고 있었다”라는 서신을 보냄으로써 위반 딱지를 철회시킬 수 있다.

그는 자신의 생각이 ‘완전히 합법적’이지는 않다는 사실을 인정했다. 그는 서신을 생성해 재무부에 자신의 위반 딱지에 대한 이의를 제기하도록 하는 자동화를 개발했다.

그는 “처음에는 효과가 있었다. 그러나 같은 서신과 청구서를 수백 번 전송함에 따라 주차관리 당국에서 그것을 파악했다. 나는 변호사를 선임해야 했고 그들은 내가 감옥에 갈 것이라고 협박했다. 나는 결국 관리는 하지 않은 대가로 3만 6,000달러를 지불해야 했다”라고 말했다.

그는 자신의 자동화된 프로세스에 오류 방지(poka-yoke)가 필요하다는 사실을 깨달았다고 전했다. ‘오류 방지’라는 뜻의 이 용어는 일본어에서 차용한 것이다. 도요타의 생산 시스템에서는 2개의 단계로 분리되어 있고 두 번째 단계가 첫 번째 단계에 의존하는 공정의 한 단계를 지정했다. 영향이 전이될 수 있는 생산 라인에 문제를 발생시키지 않기 때문에 이런 단계 증가는 효율성을 증대시킬 수 있다.

메이즐은 “위반 딱지 회피 자동화 체계에서 이전의 청구서와 같은지 비교하는 것을 자동으로 실행할 수 있었다. 그리 어렵지 않은 작업이다. 이것만 적용했더라도 벌금은 피할 수 있었을 것이다”라고 말했다.

이는 아이세라의 수다카르의 조언에도 적용된다. 각각의 자동화된 단계는 감사가 가능할 뿐 아니라 지속적으로 다른 자동화된 단계에 의한 감사를 받아야 한다. 이것은 자동화된 플랫폼이 인간 엔지니어의 IT 관리 부담을 덜어주는 AIOps의 영역에 속한다.

수다카르는 “나는 이것을 NASA 접근방식이라 부른다. NASA는 실패할 것이라고 가정한다. 확인 및 균형을 통한 AIOps 솔루션은 매우 중요하다”라고 말했다.

하지만 직접 자동화 실패를 경험한 적이 없다면 이 접근법의 가치를 알아보기 어렵다고 메이즐이 말했다. 그는 “실제로 아무런 이득이 없는 이런 자동화를 개발하느라 3일을 쏟도록 결정하기란 쉽지 않다. 그러나 나중에 이것이 필요하다는 사실을 깨닫는다”라고 말했다.

5. 보안을 도외시하지 말라

자동화된 CI/CD 파이프라인의 확산에는 어두운 비밀이 하나 있다. 상당수가 처음에는 보안 의무를 우회하기 위해 셰도우 IT로 추진되곤 했다는 것이다. 트립와이어의 킴지는 “개발자는 개발을 하고 싶어한다. 그들은 계속 진행하고 [그들의 코드의] 다음 버전으로 이행하고 싶어한다. 그래서 엄격한 IT 및 보안 프로세스가 방해가 되면 ‘이 이미지를 클라우드에서 구동하여 회피할 수 있다’라고 생각하곤 한다”라고 말했다.

물론 이렇게 한다고 해서 파이프라인이 내재적으로 안전하지 못하다는 뜻으로 귀결되는 것은 아니다. 그러나 적어도 자동화된 효율성을 위해 어떤 보안 활동을 포기했는지 조사해야 한다. 또한 어느 자동화된 프로세스나 또 하나의 공격 벡터가 될 수 있다는 사실을 기억해야 한다. 자율적으로 운영되는 프로세스는 권한을 상승시켜 구미가 당기는 표적이 될 수 있기 때문이다.

아이세라의 수다카르는 기업 내 앙심을 품은 관계자가 데브옵스 파이프라인을 이용해 코드베이스에 맬웨어를 주입한 경우를 본 적이 있다고 전했다. 그는 “그 맬웨어는 생산 환경까지 확산되었고 시스템을 운영할 수 없게 되었다”라고 말했다.

6. 본질을 잊은 자동화를 시도하지 말라

광고 때문에 오해가 발생한다. 테절츠(Tesults)의 책임 개발자 겸 설립자 아지트 달리왈은 많은 조직들이 ‘자동화된 테스트’와 관련해 다소 오해를 지곤 한다고 전했다. 특히, 기술적 배경이 없는 소규모 조직의 경우 자동화된 테스트가 인간의 개입 없이 이루어질 수 있는 수동 시험의 한 버전이라고 이해하곤 한다.

달리왈은 “그 결과 수동 테스트를 수행하는 전통적인 QA 시험자에게 테스트 자동화를 이용해보라고 지시한다. 이로 인해 단순히 수동 UI 시험을 녹화하는 툴을 사용한다는 결론으로 이어지기도 한다. 이런 접근방식은 테스트 자체를 무의미하게 만든다. 개발자가 자동화와 관련하여 달성해야 말 목표와 어울리지 않는다”라고 말했다.

달리왈은 이어 “테스트를 자동화하려면 이를 개발한 소프트웨어 엔지니어가 이를 시도해야 한다. 하급 QA담당자가 가 참여하면 엉뚱한 결론으로 이어질 수 있다”라고 덧붙였다.