핵심 요약 (Key Takeaways)

• 대부분의 CoE는 IT 톨게이트(tollbooths)처럼 작동하여 혁신을 늦추고 프로젝트 요청을 사장시키기 때문에 실패합니다.
• 효과적인 자동화 CoE(Center of Excellence)는 사전 승인된 컴포넌트(components)를 제공하는 내부 앱 스토어(App Store)처럼 운영되어야 합니다.
• 하이퍼오토메이션 (Hyperautomation) 거버넌스에는 엄격한 게이트키핑 (gatekeeping)이 아닌 엄격한 가드레일 (guardrails)이 필요합니다.
• 비즈니스 사용자에게 안전하고 즉시 사용 가능한 도구의 샌드박스 (sandbox)를 제공함으로써 시민 개발자 (citizen developer) 리스크를 제거할 수 있습니다.

실제로 작동하는 자동화 CoE (Center of Excellence)를 어떻게 구축할 수 있을까요? 그것은 CoE를 톨게이트처럼 취급하는 것을 멈추고, 내부 앱 스토어 (App Store)처럼 운영하기 시작하는 것입니다. 대부분의 기업은 자동화를 관리하기 위해 CoE를 설정하지만, 이는 프로젝트 요청이 죽어가는 느린 IT 병목 현상 (bottleneck)으로 빠르게 변질됩니다. 비결은 '허가(permission)의 문화'에서 '제공(provision)의 문화'로 전환하는 것입니다. 비즈니스 사용자에게 엄격한 가드레일 (guardrails) 내에서 자신만의 솔루션을 구축할 수 있도록 사전 승인된 안전한 컴포넌트 (components)를 제공함으로써, 하이퍼오토메이션 (hyperautomation) 거버넌스를 가속화하는 동시에 시민 개발자 (citizen developer) 리스크를 제거할 수 있습니다.

IT 톨게이트 문제 (The IT Tollbooth Problem)
저는 엔터프라이즈 기술 (enterprise tech)의 최전선에서 거의 20년을 보냈습니다. CIO가 저에게 자동화 CoE (Center of Excellence)를 구축할 예정이라고 말할 때면, 저는 보통 움찔하곤 합니다. 의도는 항상 좋습니다. 회사가 하이퍼오토메이션 (hyperautomation) 거버넌스가 필요하다고 결정한 것입니다. 그들은 비즈니스 사용자가 ERP 시스템을 망가뜨리거나 민감한 고객 데이터를 노출할까 봐 공포를 느낍니다. 그래서 그들은 무엇을 할까요? CoE를 구축합니다.

하지만 혁신의 엔진 대신, 그들은 실수로 DMV(차량등록국)를 만들어 버립니다.

그들은 아무리 작은 자동화 요청이라도 방대한 요구사항 문서, 3단계의 관리자 승인, 그리고 6개월의 대기 시간이 필요한 시스템을 만듭니다. 이는 마치 6차선 고속도로를 15분마다 점심시간을 가지러 떠나는 한 명의 직원이 지키고 있는 단 하나의 톨게이트로 통하게 만드는 것과 같습니다.

IT 부서가 압도당하고, 백로그(backlog)는 쌓여갑니다. 비즈니스 사용자는 오류가 발생하기 쉬운 인보이스 처리 과정을 자동화하려는 간단한 요청이 내년 4분기로 밀리자 좌절합니다.

그렇다면 다음에는 무슨 일이 벌어질까요? 비즈니스 사용자들이 독단적으로 움직입니다(go rogue). 그들은 회사 카드로 저렴한 SaaS 도구를 구매하고, 형편없는 VBA 매크로를 작성하며, 흔들리는 테이블 위에 쌓은 카드 집처럼 작동하는 취약한 API 연결을 만듭니다. 이러한 섀도우 IT(Shadow IT)는 CoE가 막으려고 했던 정확한 보안 악몽을 만들어냅니다.

'아하!'의 순간: 내부 앱 스토어로 전환하기
전통적인 CoE 모델의 근본적인 결함은 게이트키핑(gatekeeping)입니다. 성공적인 CoE는 톨게이트가 아니라 내부 앱 스토어처럼 작동해야 합니다.

사용자들에게 티켓을 제출하고 엔지니어가 자동화를 처음부터 구축하기를 기다리도록 강요하는 대신, CoE는 재사용 가능하고 안전하며 사전에 승인된 컴포넌트(components)를 구축하는 데 집중해야 합니다. 팀에게 레고 블록을 주는 것과 같다고 생각해보세요. 벽돌은 주지만, 못의 모양은 통제하는 것입니다.

앱 스토어 모델이 게임을 바꾸는 방법은 다음과 같습니다:

셀프 서비스 검색(Self-Service Discovery): 비즈니스 사용자는 내부 포털에 로그인하여 데이터 추출을 위한 사전 구축된 봇, CRM용 승인된 API 커넥터, 라우팅 승인을 위한 표준화된 로직 블록 등을 찾습니다.

즉시 배포(Instant Deployment): 만약 컴포넌트가 스토어에 있다면, 이미 보안 검증을 거쳤다는 의미입니다. 사용자는 이 조각들을 드래그 앤 드롭하여 내년이 아닌 오늘 자신 부서의 문제를 해결할 수 있습니다.

중앙 집중식 모니터링(Centralized Monitoring): CoE가 특정 워크플로우를 구축하는 것이 아니라 인프라를 모니터링합니다. 어떤 컴포넌트가 실행되고 있는지, 얼마나 많은 컴퓨팅 자원을 소비하는지, 누가 소유하고 있는지를 정확히 파악할 수 있습니다.

이 모델은 IT와 비즈니스 간의 관계를 변화시킵니다. IT는 "안 됩니다, 줄을 서서 기다리세요"라고 말하는 대신 "네, 이 도구들을 사용하세요"라고 말하는 역할로 전환됩니다. 분산되어 있으면서도 거버넌스(Governance)가 갖춰진 시스템을 구축하는 것이야말로, 미국 기업들이 직원들을 소외시키지 않으면서 하이퍼오토메이션 (Hyperautomation)을 성공적으로 배포하는 방식입니다.

엄격한 가드레일(Guardrails)을 통한 시민 개발자(Citizen Developer) 리스크 제어
여러분은 이렇게 생각할지도 모릅니다. "마케팅이나 재무 부서가 직접 자동화 도구를 만들게 내버려 두면, 모든 것을 망가뜨릴 것이다."

이는 타당한 두려움입니다. 시민 개발자(Citizen Developer)는 혁신을 확장하는 데 매우 훌륭하지만, 비밀번호를 하드코딩하거나, 서버를 다운시키는 무한 루프를 생성하거나, 민감한 데이터를 보안되지 않은 스프레드시트로 옮기는 것으로도 악명이 높습니다. 가트너(Gartner)의 연구에 따르면, 활발하게 활동하는 시민 개발자의 수는 전문 개발자보다 최소 4배 더 많아질 것으로 예측됩니다. 여러분은 이 파도를 막을 수는 없지만, 파도가 어디로 몰아칠지는 통제할 수 있습니다.

시민 개발자의 리스크를 제거하려면 환경에 직접 내장된 엄격한 가드레일(Guardrails)이 필요합니다.

1. 환경 분리 (Environment Separation)
시민 개발자가 운영 환경(Production)에서 직접 구축하게 해서는 절대 안 됩니다. 모든 고객 배포 환경에서 엄격하게 시행되는 저의 시스템은 비즈니스 사용자가 샌드박스(Sandbox)에서 구축하도록 요구합니다. 그들은 더미 데이터(Dummy data)를 사용하여 자동화 프로세스를 테스트할 수 있습니다. 로직이 작동함을 증명하면, IT 관리자가 코드를 검토합니다. 컴포넌트들이 이미 사전 승인된 상태이기 때문에 이 과정은 매우 빠르며, 검토가 끝나면 운영 환경으로 배포합니다.

2. 역할 기반 액세스 제어 (RBAC, Role-Based Access Control)
모든 레고 블록이 모든 사람의 손에 쥐어져서는 안 됩니다. 주니어 인사(HR) 담당자는 직원 교육 기록을 업데이트하는 자동화 컴포넌트에 접근할 수 있어야 하지만, 급여 조정을 위한 API 커넥터는 절대로 볼 수 없어야 합니다. CoE는 이러한 권한을 컴포넌트 수준에서 관리합니다.

3. 자동화 킬 스위치 (Automated Kill Switches)
사용자가 구축한 자동화가 잘못 작성된 루프 (loop)로 인해 분당 10,000번씩 데이터베이스에 요청을 보내기 시작한다면, 시스템은 자동으로 봇을 일시 중지하고 CoE에 알림을 보내야 합니다. 여러분이 경계 (perimeter)를 관리함으로써, 사용자들이 내부에서 안전하게 활동할 수 있도록 하는 것입니다.

아키텍처 고려 사항: 클라우드 (Cloud) vs. 온프레미스 (On-Premises)
App Store 인프라를 구축할 때, 여러분은 필연적으로 배포 방식에 대한 논쟁에 직면하게 됩니다. CoE는 이러한 도구들을 클라우드에 호스팅해야 할까요, 아니면 엄격하게 온프레미스에 두어야 할까요?

은행이나 의료와 같이 규제가 엄격한 산업의 경우, 핵심 트랜잭션 데이터 (transactional data)를 처리하기 위해 온프레미스 배포가 협상의 여지 없이 필수적인 경우가 많습니다. 자동화를 약간 더 빠르게 실행하기 위해 컴플라이언스 (compliance) 위반의 위험을 감수해서는 안 됩니다. 하지만 하이브리드 (hybrid) 접근 방식이 가장 효과적인 경우가 많습니다. 민감한 데이터 처리는 온프레미스에 유지하면서, 사용자 인터페이스 (user interface)와 비핵심 로직 블록 (logic blocks)은 프라이빗 클라우드 (private cloud) 환경에 호스팅하는 방식입니다.

어떤 아키텍처를 선택하든 사용자 경험 (user experience)은 균일하게 유지되어야 합니다. 비즈니스 사용자는 서버가 어디에 있는지 알 필요가 없어야 하며, 단지 자신들의 드래그 앤 드롭 (drag-and-drop) 도구가 작동한다는 사실만 알면 됩니다.

ROI 및 용량 관리 (Capacity Management)의 재고
ROI (투자 대비 수익)에 대해 솔직하게 이야기해 봅시다. 기술 산업은 자동화를 통한 폭발적인 하키 스틱 (hockey-stick) 성장의 개념을 파는 것을 좋아합니다. 하지만 실용주의자로서 저는 ROI를 다르게 바라봅니다.

자동화 CoE의 성공을 얼마나 많은 봇을 배포했느냐로 측정해서는 안 됩니다. 여러분은 이를 용량 관리 (capacity management)로 측정해야 합니다.

수동 데이터 입력은 인간을 값비싼 라우터 (router)처럼 사용하는 것과 같습니다. 이는 느리고, 오타가 발생하기 쉬우며, 귀중한 인지적 에너지를 낭비합니다. App Store 모델을 채택함으로써, 여러분은 직원들의 운영 부담을 줄일 수 있습니다.

ROI (투자 수익률)를 계산할 때, 고정된 비용 (flat fixed costs)과 가변적인 인적 비용 (variable human costs)을 비교해 보십시오. 만약 자동화된 프로세스가 10,000건의 송장을 처리하는 데 매월 500달러의 고정적인 컴퓨팅 파워 비용이 들고, 다음 분기에 그 물량이 두 배로 늘어난다면, 비용은 그대로 유지됩니다. 반면 사람이 이를 처리한다면 비용은 두 배로 늘어납니다. 거버넌스(governed)가 갖춰진 CoE (Center of Excellence)는 기반 기술이 자체적인 무게를 견디지 못하고 무너지지 않도록 보장하는 동시에, 이러한 고정된 비용을 고정시킵니다.

핵심 요약 (The Bottom Line)
자동화 CoE (Center of Excellence)는 결코 좋은 아이디어들이 사장되는 곳이 되어서는 안 됩니다. 사고방식을 문지기 (gatekeeper)에서 플랫폼 제공자 (platform provider)로 전환함으로써, 여러분은 직원들이 스스로 운영상의 골칫거리를 해결할 수 있도록 권한을 부여하게 됩니다. 여러분은 그들에게 도구를 제공하고, 경계(boundaries)를 설정하며, 그들이 직접 구축할 수 있도록 허용하십시오. 그것이 바로 관료주의적 악몽 없이 진정한 확장성 (scale)을 달성하는 방법입니다.

다음은 제가 관료주의 없이 확장 가능한 자동화 CoE를 구축하기 위해 구조화하는 정확한 방법입니다.