2020.02.26

"자동화, 때로는 악몽이 되더라"··· 현실 전문가들이 전하는 교훈

Josh Fruhlinger | CIO
데브옵스 파이프라인 자동화, 로보틱 프로세스 자동화(RPA)를 도입했거나 검토하는 기업이 늘고 있다. 그러나 자칫 결함을 내포한 상태로 이를 도입하면 끝없는 골칫거리로 이어질 수 있다. 여기 현실 속 사례에서 확인할 수 있는 교훈들을 살펴본다. 
 
ⓒ Image Credit : Getty Images Bank



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)의 설립자이며 생산성 코치로, 힘들고 단조로운 일을 자동화하는데 관심이 많다. 그는 자신의 기업에도 자동화를 구축하는 경우가 많다. 하지만 그는 주차 위반 딱지를 피하려다가 중요한 교훈을 얻었다.

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




2020.02.26

"자동화, 때로는 악몽이 되더라"··· 현실 전문가들이 전하는 교훈

Josh Fruhlinger | CIO
데브옵스 파이프라인 자동화, 로보틱 프로세스 자동화(RPA)를 도입했거나 검토하는 기업이 늘고 있다. 그러나 자칫 결함을 내포한 상태로 이를 도입하면 끝없는 골칫거리로 이어질 수 있다. 여기 현실 속 사례에서 확인할 수 있는 교훈들을 살펴본다. 
 
ⓒ Image Credit : Getty Images Bank



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)의 설립자이며 생산성 코치로, 힘들고 단조로운 일을 자동화하는데 관심이 많다. 그는 자신의 기업에도 자동화를 구축하는 경우가 많다. 하지만 그는 주차 위반 딱지를 피하려다가 중요한 교훈을 얻었다.

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


X