을의 Digital Finance 블로그 (23)
지속가능한 디지털 전환을 위한 기술경영 /팀 경영 (2-2)
<이전글 : 지속가능한 디지털 전환을 위한 기술경영 /팀경영 (2-1) >
이전 블로그에 이어, 본 편에서는 지속적인 디지털 전환을 위한 구체적이 실천적인 접근방법들을 고민해 보았다.
1. 디지털 시대에 맞는 기술경영을 위한 새로운 패러다임을 고민해야 한다.
지속적인 디지털혁신을 위해서는, 새로운 생산수단인 소프트웨어를 이해하고 비즈니스 결과를 만들어내는 새로운 기술경영을 위한 패러다임을 생각해 봐야 한다.
이전 블로그에서 살펴본 대로, 지금까지 제품보다는 프로젝트를, 고객경험과 혁신속도보다는 비용을, 비즈니스 가치전달보다는 개발일정을 우선시하면서, 비즈니스와 IT가 단절되어 왔다. 디지털 전환이 실패하는 주요 원인이었다. 이는 소프트웨어 기술에 대한 이해와 기술경영에 대한 관점이 합의되지 못한 것에 기인한다. 대규모 중장기 디지털 전환 계획 수립, 소프트웨어 개발에 대한 이해 부족, 프로젝트 중심 관리, IT의 비즈니스 가시성 부족, 전통적 IT인사관리 측면에서 새로운 기술경영 패러다임의 필요성을 살펴본다.
새로운 관점으로 디지털 전환계획을 수립해야 한다. 역량 있는 리더조차도, 소프트웨어 시대의 위험을 평가하고, 비즈니스 기회를 실현시키는 완벽한 통찰력을 갖출 수는 없다. 기술의 불확실성을 인정하고, 예측의 어려움을 인정하는 것부터 시작해야 한다. 불확실성의 상황에서는 경영학에서 이야기하는 리얼옵션(Real Option)처럼, 복수의 대안에 대해 소규모로 투자하면서, 최적의 경로를 선택해 나가는 방식이 더 적합하다. 과거에는 벤치마킹을 통해 따라 할 수 있는 증명된 길이 많았지만, 이제는 새로운 길을 모색해야 하고, 이를 위해서는 경영과 기술의 가능성에 대한 폭넓은 시각을 요구한다. 현실에서는 역량의 부족과 과거 관성에 따라, 대규모 중장기 디지털 전환계획을 수립하고는 실제 실행에는 실패하고 있다. 같은 맥락에서, 국내 금융기관의 차세대 시스템 개발은, 과거 경제개발 5개년 계획과 유사하게 대규모 빅뱅 프로젝트로 추진되면서 종종 효과를 내지 못하고 있다. 내부역량을 고려하지 않은, 중장기 시스템 개발 계획은 필수적으로 외부 SI사업자를 필요로 하며, 주기적으로 대규모 업그레이드를 다시 추진해야 되는 상황을 맞게 된다.
소프트웨어 개발 과정에 대한 이해를 높여야 한다. 전통 기업들은 소프트웨어 개발이 가장 복잡한 지적작업이라는 사실을 간과한다. 복잡한 금융 업무의 경우, 숙련된 시니어 개발자가 생산성을 내는 데 6개월 ~1년이 걸리기도 한다는 사실을 외면한다. SI개발에서 외부 개발자 대부분은 전통 금융기관의 개발 플랫폼을 이해하는 데 초기 2~3개월의 시간을 보낸다. (요건정의, 분석 단계부터 외부 개발자가 미리 투입되어야 하는 숨은 이유 중 하나이다.) 개별인력의 생산성에 추가하여, 팀의 생산성이 일정 수준으로 올라가는 데에도 시간이 소요된다. 정기적인 조직개편으로 인한 개발자들의 변동이, 팀 생산성에 미치는 악영소향을 상상해 볼 수 있다.
소프트웨어 프로젝트는 개발이 종료되면 끝이라고 생각하고, 적정한 운영비용을 감안하지 않는 경우가 많은데, 경제적 관점에서 완전히 잘못됐다. 일반적으로 소프트웨어 개발 과정에 누적된 기술부채가 문제를 유발한다는 것은 잘 알려져 있다. 기술부채를 줄여나가지 않으면, 새로운 기능을 추가하고 수정하는 데 엄두를 못 낼 만큼 비용과 시간이 소요된다. 개발만 완료하면 종료되는 프로젝트 관리에서는, 기술부채를 줄이려는 유인가가 존재하지 않는다. 기술부채는 프로젝트가 종료될 때까지 보이지 않기 때문이다. 반면 보잉은 유지보수 30년 동안의 생산과 30년 동안의 유지보수를 전제로 소프트웨어 개발한다고 한다. 보잉에서의 소프트웨어는 안전과 직결된 핵심 자산으로 간주된다. 제품 중심 기술경영의 대표적인 성공 사례이다.
일회성 프로젝트보다는 프로덕트, 제품 지향의 관점을 견지해야 한다. 프로덕트가 아닌 프로젝트 중심의 관리는 대마불사 프로젝트를 만든다. 계획과정에서 모든 리스크를 사전에 미리 예상하고, 미래에 필요할 지도 모르는 자원까지 감안하며, 지나치게 보수적으로 소요기간과 예산을 추정하는 경향이 생긴다. 대마불사일 수 록, 담당 임원의 재임기간이 보장되는 효과도 있다고 보인다. 하지만 대규모 프로젝트는, 변화하는 디지털 환경에서 중요한 지속적 학습을 오히려 방해하는 결과를 초래한다. 종종 최소기능의 MVP(Minimum Viable Product) 기능을 개발하고 시장의 반응을 살펴보는 것이 바람직하지만, 프로젝트 예산편성과 승인 절차에 소요되는 노력 때문에 채택되지 못한다. 작게 여러 번 프로젝트를 기안하고 승인을 받는 것은, 종국적으로 총시간의 지연과 총비용의 증가를 초래할 것으로 예상되기 때문이다. (수직적 계층구조는 프로젝트 수만 큼 많은 리뷰와 체크포인트를 요구한다) 반면 조직변경 후, 매년 초에는 부서별로 대규모 프로젝트 계획들이 수립된다. 변화하는 디지털 환경에서는 일회적 프로젝트 관리보다, 프러덕트 중심으로 지속적인 개발과 운영을 해 나가는 방식이 더 적합하다.
IT의 비즈니스 가시성을 높여야 한다. 비즈니스와 IT 간의 간극을 줄이기 위한 공통언어인 가치흐름지표 등을 합의하는 것이 중요하다. 소프트웨어 전달의 복잡성과 역동성을 반영하여, 실제 비즈니스 가치 흐름이 보이도록 하는 것이 중요하다. 과거 방식대로 경영진이 중점을 두는 일정과 비용에 중점을 두어 관리하려면, 소프트웨어 전달의 복잡하고 역동적인 특성을 전통적인 프로젝트 관리 기법의 정적 특성과 매핑해야 한다. 이 결과 소위 수박 현상이 목격된다. ( 겉은 초록색이지만 실제는 빨간색인 진행상황이다.) 관리자는 프로젝트가 잘 진행되는지 묻지만, 질문이 모호하므로 대답은 항상 예스이다. IT의 가시성을 높여서, 공통언어인 가치흐름지표로 의사소통하지 않기 때문이다.
전문성을 기반으로 IT 조직을 설계하고 관리해야 한다. 종종 대형금융기관의 CIO는 기술과 무관한 부행장이 담당하기도 하였고, 외부 기술 전문가를 영입도 하지만 기술경영 수준으로는 활용하지 않았다. IT부서의 인력규모가 많다는 점에서, 인사관리 역량도 중요하지만, 격변하는 디지털 환경에서 기술에 대한 전문성이 있어야, 진정한 오너십, 자율과 책임의 문화를 만들어 갈 수 있다. 전문성이 있어야, 바람직한 소프트웨어를 위한 조직을 설계할 수 있다.(콘웨이 법칙에 따르면, 기술전문리더 없이 조직을 설계하는 것은 비효율적이다.) 전문성이 있어야, 소위 숟가락을 얻는 활동을 감지할 수 있다. IT는 소수의 스타플레이어만 있으면 된다는 엘리트주의, 기술 전문가를 좁은 기술차원으로만 활용하는 것은, 모두 새로운 기술경영에 대한 패러다임 전환이 되지 않아서 발생한 현상이다.
2. 사람중심의 새로운 경영원칙을 수립하고, 오너십의 원, 자율과 책임의 원칙을 적용해가야 한다.
현실적으로 대규모 계층적인 조직구조를 가진 전통금융기관에서, 사람중심의 자율과 책임이 작동하는 수평적인 문화를 만들어가는 것은 쉬운 일이 아니다. 눈에 보이는 조직구조, 프로세스, 절차나 IT시스템이 아니라 눈에 보이지 않는 경영원칙을 다시 살펴보는 것이 우선일 것이다. 오래된 세계관, 구식 경영모델을 버리고, 단순하고 더 나은 현실모델인 팀 경영을 고려해야 한다. 오너십의 경영원칙, 자율과 책임의 경영원칙들이 더 중요해진다.
먼저 오너십의 경영원칙을 가장 우선해서 적용해야 한다. 컨설턴트에서 기업의 CIO로 신발을 바꿔 신었을 때, 가장 먼저 눈에 띈 불합리함은 오너십의 문제였다. 가장 먼저 남의 밥그릇에 숟가락을 얻는 행동들이 눈에 띄었는데, 실제 업무 수행자가 오너십을 갖지 못하는 주요 원인이었다. 긴급한 장애 문제를 실제는 아웃소싱 직원이 해결했는데, 직원이 해결했다고 보고받는 경우도 있었다. 외부 컨설팅 회사의 자료를 기반으로, 문구만 몇 개 바꾸어 단순히 취합하고 기획서로 포장해서 보고하는 관행도 많았다. 리더가 전문성을 가지고 현장과 문제해결의 과정을 속속들이 알지 못하면, 발견하기 어렵다.
IT조직원들은 대부분 본인들이 일은 다하는데, 종종 공은 현업이 가져간다고 생각하고 있다. 당연히 주도성과 열정이 떨어지는 직원도 많다. 수처작주(내가 있는 곳에서 주인이 되자)를 외쳤지만, 실제 자신이 오너십을 가졌다고 느끼게 만드는 문화가 절실했다. 보고서를 작성한 직원, 실제 일을 하는 직원이 보고하게 하고, 일을 투명하게 드러나게 하는 것이 우선이었다. 현업부서별 릴레이션쉽 매니저를 정의하고, 현업부서에 주요 추진과제와 진척사항을 직접 메일로 매월 공유하게 하였다. 임원의 일, 관리자의 일이 아닌 자신의 일이 되면 결과가 달라진다. 우리나라의 놀라운 경제성장도, 6.25 직전 전격 시행한 토지개혁으로 증가한 자영농이 거둔 생산성 향상이 마중물이었다고 한다. 우골탑이라도 가능한 최소한의 부를 전후 단시간 내에 확보할 수 있었던 비결은, 6.25 직전 소작농에서 자영농으로 전환하면서 향상된 생산성이 주요 원인이었다는 글을 읽으면서, 오너십을 명확히 하는 것의 중요성을 다시 깨닫게 되었다.
모든 단계에서 오너십을 확립하면, 자연스럽게 자율과 책임의 문화가 만들어진다. 직원들이 스스로 결정하고, 실행할 수 있는 환경을 만들어 주는 것이 리더가 할 일이다. 현장에서 일하는 직원이 선수라면, 리더는 감독이다. 급변하는 디지털 환경에서, 현장에서 실행하는 직원들이 결정하게 하고, 결과는 리더가 책임지는 경험을 확산해야 한다. 현장에서 의사결정을 함으로써, 의사결정의 속도 또한 빨라진다. 리더는 팀을 넘나는 협업의 속도를 높이면서, 팀이 결과를 낼 수 있도록 지원한다. 리더는 장기적인 관점에서 직원들의 학습과 성장을 위한 코칭의 역할에 집중해야 한다.
3. 새로운 디지털 운영모델로서의 팀 경영을 적극적으로 구축해 가야 한다.
모든 일은 사람이 한다. 디지털 전환의 실행력을 담보할 수 있는 조직과 팀을 구성하고 운영하는 일은 무엇보다 제일 중요하다. 새로운 디지털 운영모델은 소규모 자율적인 팀을 전제로 한다.
애자일, 린, 데봅스는 모두 소규모 자율적인 팀, 제품 중심 팀을 강조한다. 팀은 공동의 목적을 달성하기 위해 일하는 단위로, 7~9명으로 구성된 안정된 집단이다. 소프트웨어 개발운영 업무는 개인이 아닌 팀에 할당해야 하고, 성과평가도 개인이 아닌 팀을 대상으로 해야 한다. 팀은 전문성, 자율성, 목적성을 가지고 내적동기를 최대화해야 한다. 장기간 유지되는 소규모팀이 자리를 잡으면, 소프트웨어 오너십을 개선할 수 있다. 시스템의 운영가능성과 목적 적합성을 유지하는 데 소프트웨어 오너십은 필수적이다. 소프트웨어의 모든 부분은 정확히 한 팀이 소유해야 한다. 어떠한 컴포넌트, 라이브러리, 코드도 공동으로 소유해서는 안 된다. 소프트웨어 개발과 운영의 주체도 개인이 아니라 팀이 되어야 한다. 환경에 적응하는 역동적인 팀, 배우고 성장하는 팀이 되어야 한다.
Product 중심 팀 조직은 서비스할 고객이 명확하다. 예를 들면 하나의 디지털 앱은 하나의 Product로 정의될 수 있고, 하나의 팀이 기획, 개발, 운영을 수행할 수 있다. 데이터 분석 조직도 하나의 Product 조직이라고 볼 수 있다. 정보의 수요부서에게, 분석된 정보, 인텔리전스를 제공하는 Product 조직으로 보고 제공할 정보를 수요자에게 유의미한 방식으로 제공해야 한다. 예를 들면, 두리뭉실한 고객정보가 아니라, MZ고객군의 이탈징후 정보와 같이 어떤 정보 Product를 제공해야 할지 명확히 해야 한다.
만들고자 하는 시스템 구조와 실질적 조직 구조가 불일치하면 둘 중 하나를 바꿔야 한다. "컴파일러 하나를 네 그룹이 작성하면, 네 단계로 이루어진 컴파일러를 얻는다." "소프트웨어 아키텍처를 분리해서 설계할 수 있고, 설계 후에는 어떤 그룹이든 이를 구현할 수 있다는 개념은 틀렸다. 이는 시스템 아키텍처와 팀 구조 사이의 격차를 크게 할 뿐이다. " 모두 콘웨이 법칙을 대변하는 말들이고, 소프트웨어의 개발운영방식에 맞는 실질적인 팀 운영의 중요성을 강조하는 말 들이라고 할 수 있다.
전통적인 조직은 통제와 관리의 목적으로 구성되며, 조직도는 수직적 계층구조와 커뮤니케이션 체계를 반영한다. 하지만 실제 업무수행방식은 수직적인 조직도와 같이 움직이지 않는다. 복잡하고 고도의 상호작용을 요구하는 소프트웨어 개발운영의 경우에는, 팀 구성에 실제 업무방식을 반영하는 것이 정말 중요하다. 반면 과거를 보면 대부분 조직은 소프트웨어 개발을, 기능적 전문가 개인이 완료할 수 있는 제조의 한 분야로 여겨왔다. 자연스럽게 팀 내의 개발자가 단순히 올바른 절차를 따르고 올바른 툴을 사용한다면, 또 다른 개발자로 대체가능하다고 보면서, 팀을 단순한 개인의 그룹으로 보는 잘못된 관점을 갖게 되었다. 실제 개발운영과정의 비공식적 커뮤니케이션 구조를 반영하고, 가치가 창출되는 업무방식의 중요성을 인식하면서, 진정한 제품과 팀을 중심으로 하는 조직으로 구성해야 한다. 비즈니스와 기술이 빠르게 변화하는데, 기존 계층조직과 매트릭스 조직 구조에 의존하는 것은 소프트웨어 개발에 비효율적이라는 것이 명확해지고 있다.
팀 간 경계를 분명히 하고, 팀의 인지부하 감소에 주의하여 소규모로 구성한다.
팀은 소프트웨어 개발과 운영의 기본 수단이다. 자체로 학습과 목표, 임무 및 합리적 자율성을 가진 개체이다. 팀은 업무를 수행하는 주체인 동시에, 비즈니스와 연계하여 지속적으로 가치를 전달하기 위한 최선의 수단이다. 시스템의 복잡도가 증가하면서, 팀이 부담해야 하는 인지부하도 함께 증가한다. 명확한 책임과 경계를 가진 팀을 설계하면서 인지 부하에 초점을 두어야 한다. 적절한 범위, 책임경계, 자연스러운 (상대적으로 독립적인) 시스템 구조를 가져야 한다. 팀 간 경계가 명확하면 팀원들이 인지부하가 감소한다. 더 많은 커뮤니케이션이 언제나 좋은 것만은 아니다. 불필요한 팀 간 커뮤니케이션은, 강하게 연결된 상호의존적인 시스템을 만들게 되어, 오히려 빠른 비즈니스 흐름을 방해할 수 있다.
팀우선 접근 방식을 위한 다음의 기본적인 질문과 함께 시작하라는 권고가 유효하다.
- 하나의 효과적인 팀으로 행동하고 운영한다
- 소프트웨어 일부를 효과적으로 소유한다
- 사용자 필요를 만족시키는데 집중한다
- 불필요한 인지 부하를 줄인다
- 다른 팀이 만든 소프트웨어나 정보를 소비하거나, 반대로 다른 팀에게 소프트웨어나 정보를 제공한다.
진정한 팀을 구성하고, 권력거리를 줄여야 한다.
팀은 일시적인 프로젝트 조직이 아니고, 동일한 전문성으로 구성된 기능팀도 아니다. 상호 보완적인 전문성을 기반으로, 의미 있는 목적과 구체적인 목표를 달성하는 접근법을 가지고 있는 것이 진정한 팀이다. 최고 경영자로부터의 물리적인 권력거리를 줄이는 것도 중요하지만, 심리적인 권력거리를 줄이는 것이 중요하다. 무엇보다 가장 중요한 권력을 가진 고객과의 거리를 줄여야 한다.
채용부터 평가까지 팀 경영에 맞는 새로운 HR제도를 고민해야 한다. 기존 연공서열형 HR제도를 보유한 전통금융기관들이 네카라쿠배에 입사할 수 있는 직원을 채용하기는, 처우와 문화매력도 측면에서 쉽지 않다. 공격적으로 별도의 디지털 전담 HR부서를 두어 채용을 시도했던 이유이다. 전통 금융기관들은 빅테크 대비 소위 인재밀도가 낮고, 아웃소싱에 의존하다 보니, 완결된 디지털 팀을 구성하기 어려운 것이 현실이다. 기존 HR 제도에서는 개인을 대상으로 상대평가를 시행하는데, 가능한 중요한 디지털 영역부터 인재밀도가 높은 완결된 디지털 팀을 구성하고, 개인평가보다는 팀 평가를 우선으로 해야 한다.
무엇보다 중요한 것은, 내부승진이 지상과제인 기존 금융기관의 인사문화와 애자일 경영을 조화롭게 운영하는 일이다. 애자일 팀에서는 정형화된 일보다는 비정형적인 일이 더 많고, 수시로 피드백을 받으며 성장해야 하는 압박감이 적지 않다. 실패가능성도 높아서, 인사 경력상에 오점을 남기고 싶어 하지 않는 직원이 많다. 궁극적으로는 금융기관 조직원들이 기능별 전통적인 조직에서 정형적인 일을 하는 것에 만족하는 것이 아니라, 커리어 관리 차원에서 성장하는 것을 선호하도록 문화가 바뀌어야 한다.
4. 맞춤형 애자일 운영과 기법을 찾아나가야 한다.
전통 금융기관들은 애자일 경영과 프랙티스를 조직에 맞게 도입하려 애써왔다. 중요한 것은 이미 이야기한 대로 애자일 경영에 맞는 경영패러다임과 경영원칙을 재정립하고 꾸준히 기업문화를 바꾸는 것이다. 이와 함께 지속적으로 조직에 맞는 애자일 방법론을 찾아나가고, DevOps 프로세스와 툴도 개선해 가야 한다.
소위 아마존의 피자 한판 팀처럼, 애자일 팀으로 구성해야 한다, 핵심 영역에서 만큼은 외주인력 없이 내부인력으로 구성해야, 기획과 개발의 오너쉽뿐만 아니라 운영의 오너쉽도 확보할 수 있다. 즉 개발한 팀이 운영하는 방식이다. 실제 비즈니스 가치는 운영을 통해 창출된다. 디지털 Product는 운영과정을 통해 피드백을 받아 업그레이드된다. 운영의 중요성이 너무 중요하다. 단순히 외주에 맡길 일이 아니다.
현실적으로 모든 조직을 진정한 팀으로 구성하는 것보다, 고객과 가까운 조직부터 진정한 팀, 제품중심 조직으로 만드는 것도 방법이다. 이미 계층화되어 있는 대규모 조직에서 전체적인 변화를 주기는 쉽지 않다. IT조직의 경우에는 디지털 플랫폼 조직과 레거시 플랫폼 조직의 Two Track으로 나누어, 우선 디지털 플랫폼 조직부터 진정한 팀 운영을 도입할 수 있다. ING와 같이 전사조직을 과감하게 애자일 조직으로 변경하기도 하는데, 많은 변화관리 노력이 소요된다. 좁게는 디지털 채널 조직부터, 진정한 디지털 팀 조직으로 전환하는 방법부터 시도해 볼 수 있다.
개발환경인 DevOps, 보안이 사전에 고려된 DevSecOps가 실질적으로 가동되도록 지속적으로 개선해 야한다. 전통 금융기관의 통상적인 개발과정은 ITSM(IT System Management)을 통해 진행되는데, 통상 20여 개 단계의 절차가 있다. 개발을 의뢰하고, 요건을 정의하고, 변경하고, 테스트하고, 보안성 심의, 운영하기까지 현업과 개발자들은 수많은 결재와 승인 단계를 거쳐야 한다. 이러한 개발운영환경을 DevOps를 통해서 자동화하는 노력이 추진되고 있다. DevOps 시스템은 외주나 SI를 통해서, 일회성의 변화 없는 시스템을 만드는 것이 아니라 계속 진화시켜 가야 하는 시스템이므로 처음부터 자체 개발하는 것이 바람직하다. 규제환경변화와 컴플라이언스 보안 규정의 변화도 잦아서 지속적으로 시스템에 변경이 발생하게 된다. 이러한 변경을 지속적으로 관리할 수 있는 자체 DevOps 환경이 중요하다. 좋은 학용품을 쓴다고 해서, 꼭 성적이 좋은 것은 아니다. 하지만 중요한 역량인 IT개발에 있어서 기업용 툴로 몽당연필을 쓰느냐, 명품 워터맨을 쓰느냐에 따라 결과가 달라질 가능성이 높다.
5. 진정한 디지털 팀을 구성하기 위해서는 아웃소싱 정책을 재검토해야 한다.
아웃소싱은 단기적으로 비용절감 효과를 가져오는 듯 하지만, 조직 간의 경계를 넘나드는 피드백 흐름을 방해하여 결정적으로 소프트웨어와 비즈니스의 연결을 끊어버린다. 소프트웨어가 성장하면서 이를 개선하고 관리하는 능력은 오히려 더 감소하게 된다. 종종 소프트웨어는 한번 만들면 수정 없이 사용될 수 있을 거라는 잘 못된 가정하에서 아웃소싱이 이루어지는데, 현실에서는 지속적인 변경과 최신화가 필수적이다. 현실에서 하도급법을 준수하자면, 아웃소싱 직원을 별도의 공간에서 근무하게 해야 하는데, 커뮤니케이션 단절은 불가피한 현상이다.
상대적으로 높은 아웃소싱 비중은, 산업화 시대의 경영철학에 근거하고 있지 않나 싶다. 아웃소싱에 의존하여 개발한 디지털 플랫폼을 지속적으로 개선하기는 힘들다. 주기적으로 대규모 시스템 리뉴얼이 발생하는 이유이다. 아웃소싱에 의존하는 상황에서는, 아마존의 "개발한 사람이 운영한다"는 원칙을 지키는 것은 현실적으로 어렵다. 개발에 참여했던 외부개발자를 일부 내부직원으로 채용하기도 하지만, 오너십과 자율과 책임의 원칙이 문화로 정착되지 않는 이상 쉽지 않다. 전통 금융기관들은 대략적으로 30%대의 인소싱 비중이라고 판단된다. 글로벌 금융기관들도 한때 인도에 비즈니스 프로세스, IT를 대대적으로 아웃소싱했었다. 디지털 전환이 중시되면서 다시 인소싱으로 방향을 전환했고, DBS의 경우 인소싱 비중이 90%를 넘는다. 이제는 AI 기술들을 이용해서 인소싱을 통해서도 생산성과 품질을 높이고 있다. 금융산업만이 아니라, 제조업에서도 유턴 현상이 속속 목격되고 있다. IT영역 중 경쟁우위를 점하려는 영역만이라도 더 인소싱 비중을 높여야 한다.
내부 정규직을 급격하게 증가시키기 어려운 이유 등으로, 아웃소싱을 활용한다 하더라도 SLA계약 등을 통해 경계선을 분명히 해서, 사업자에게도 영역에 대한 오너십과 책임을 부여하고, 소위 갑을병 문제가 고착화되지 않도록 계약관행을 고도화하는 것이 필요하다. 반복되는 디지털 프로젝트를 위해, 외부 SI 사업자와 T&M(Time & Material) 방식의 Agile 계약을 시도하기도 했었다. 내부적으로 Agile 계약을 위한 룰과 규정을 정비하는데 시간이 소요되기도 했지만, 실제 계약을 해도 준수해야 하는 상세한 산출물 검수 프로세스 때문에, 결국 수요부서에서 Agile 계약 기피하는 아이러니도 있었다. 그럼에도 불구하고 실질적인 T&M 방식의 Agile 계약방식이 더 많이 수행되기를 기대해 본다.
6. 해커톤을 통해 관료제, 외부규제와 내부규정에 도전하라
내부규정, 복잡한 룰에 대해서 더 과감하게 도전해야 한다. 관료제는 문제를 풀어가는, 조직화된 집단지성의 방식이기도 하다. 하지만 과거 관행과 사례로만 풀 수 없는 문제가 많이 발생하는 새로운 디지털 환경에서는 잘 작동하지 않는다는 데 문제가 있다. 지시와 통제의 수직적 위계구조가 만연한 전통 금융기관에서는, 새로운 경영원칙에 반하는 관행이 많이 목격되게 된다. 이러한 관행을 개인 그리고 조직적 차원에서 개선하려는 노력을 시도해야 한다.
관료제는 개인의 권력추구의 결과물이라고도 한다. 어떤 측면에서 관료적 위계문화는 조직문제라기보다는 인간 개인의 문제이다. 개인이 스스로 관료제하에서 이득을 얻기 위해, 비인간적인 행동을 했었는지 자각할 수 있도록, 항상 깨어있을 수 있도록 노력해야 한다. 과도한 룰과 절차를 해체하는 과제를 도출하는 조직차원의 해커톤도 방법이다. 개인 차원이든 팀 차원이든, 문제를 정의해 보고, 현재의 프로세스와 방침, 규제, 관행을 오너십과 자율과 책임이라는 새로운 경영원칙하에 어떻게 바꾸어야 하는지 고민해 보면 많은 과제들이 도출될 것이다.
외부 규제에 대해서도 과감히 도전해야 한다. 감독당국도 자율규제, 자율보안을 원칙으로 천명하고 있다. 개인적으로 "미래는 기술을 규제할 수 없다"는 카피를 좋아한다. 전통적으로 금융산업은 규제산업이고, 규제기관과의 관계가 중요하다. 하지만 기술 관련 규제의 상당 부분은 과거 기술 기반에서 발생한 경험과 사례를 기반으로 만들어져 있다. 소위 전자금융감독규정에 포함되어 있는 규정을 살펴보면, 과거 메인프레임과 전용선으로 연결되어 있던 시대에 발생하였던 사건사고에 기반하여, 이를 재발하지 않도록 규제하는 방식들이 많이 있다. 기술은 빨리 변한다. 기술 자체보다, 규제의 개별 문구 하나 보다 근본적으로 규제의 원래 의도, 즉 어떤 위험을 줄이려고 했는지를 파악하고 대응하는 것이 중요하다. 규제기관에 대한 설득도, 규제의 근본취지를 파악하고 새로운 기술과 환경에서 이를 어떻게 대응해 가겠다는 방식으로, 적극적으로 설득해야 한다. 규제기관이 허용해 주는 금융규제 샌드박스 제도 등을 잘 활용하는 것도 방법이다.
7. 전통적 하향식(Top Down) 변화관리 방식을 대체하는 새로운 변화관리 방식을 모색해야 한다
전통적인 리더십을 다시 생각해 봐야 한다. 관리자란 말을 종종 리더라고 용어만 바꾼다고 문제가 해결되지 않는다. 종종 디지털 시대의 리더의 자격조건으로 하드스킬을 강조하여, AI, 블록체인, 클라우드 등 신기술 습득을 강제하기도 하고, 소프트 스킬로는 진정성을 강조하지만, 실상은 관료제하에서 자격조건을 전제로 하고 있는 것 같다. 지시와 통제의 계층조직에서 리더십을 분해해 내는 것은 쉬운 과제가 아니다.
새로운 변화관리 모델을 만들고 실험해야 한다. 전통적인 변화관리 방법론이 실패하는 이유는 여전히 경영진 중심, 소규모 팀 중심으로 Top Down으로 진행하기 때문이다. Top Down 적인 변화는 지연을 초래한다. 수직적 계층 조직구조에는 모두 바꾸지 않고는 하나도 바꿀 수 없는 복잡성이 있다. 현장의 의견이 잘 반영되기 힘들고, 종종 현장으로부터의 반발을 유도한다. 변화관리를 위한 새로운 매니지먼트 모델이 발견되고 실험되어야 한다. 프랜시스 교황이 모범을 보이며 시행한 변화관리도 Top Down 변화관리의 대표적인 실패 사례 중 하나이다. 스스로 "스핑크스를 칫솔로 닦는 것과 같았다"라고 표현하기도 했다.
IT조직을 코스트 센터 관점으로 성과를 측정하는 수준을 넘어, 비즈니스 가치흐름과 비즈니스 가치 전달 방식을 측정하기 위한 방안을 고민해야 한다. IT조직이 비즈니스에서 분리되어 사일로에 갇혀있고 기능적으로 전문화되어 서로 단절되어 있으면 안 된다.
IT기술을 통해 확보한 투명성을 통제와 지시를 강화하기보다, 자율과 책임의 문화를 강화하는 데 사용해야 한다. 좋은 시스템은 투명성을 높여서 자율과 책임의 문화를 강화시킨다. 협업 툴을 확대했을 때, 입사한 지 얼마 되지 않은 시니어개발자가 퇴사한 적이 있었다. 사유를 들어보니, 투명하게 관리되는 DevOps체제에서 본인이 기여하는 것이, 명백히 적게 보이는 것에 대한 압박감을 견디기 힘들었다고 한다. 성과평가도 DevOps 시스템에 있는 일상적인 활동기록에 근거하여 수행 수 있으니, 개발자에겐 극단적인 투명성으로 느껴지기도 했을 것이다. 신뢰를 기반으로 하는 진정한 팀은 이러한 극단적인 투명성이 폭력으로 느껴지지 않게 한다. 중국이 권위적인 통치를 강화하는 데 IT기술을 활용하는 것처럼, 기술은 세밀한 부분까지 트래킹 할 수 있게 하며, 지시와 통제를 강화하기도 한다. 반면 잘 사용하면 투명성을 통해, 오너십과 자율과 책임의 문화를 정착시키는 데 도움을 준다.
8. Re-skill, Up-Skill을 위한 지속적인 투자와 지원이 중요하다. 시니어, 주니어 개발자뿐만 아니라, 현업과 리더들도 디지털 전 영역에 지속적인 학습이 필요하다. 외부 커리큘럼을 활용하든, 내부적으로 과정을 만들든 배움이 멈춘 곳에서는 성장은 없다. 이를 위해 외부 파트너와 협력하는 것도 좋은 방법이다. 파트너별로 좋은 코스도 있고, 자격증제도도 있다. 필요하면 금융기관에 맞게 커스터마이즈도 해 주기도 한다.
한 가지 하드스킬만이 아니라, 디지털 시대에는 문제해결능력, 소프트 스킬도 중요하다. 잠재력을 활용하지 못하고 있는 시니어 IT직원에 대한 교육투자도 필요하다. 급격한 기술의 발전은 특히 시니어 IT직원이 제 역할을 찾지 못하게 한다. 그러나 도메인 지식과 강한 근로 윤리로 무장된 50대 중에 학습능력이 뛰어난 사람들도 많다. 정부가 제공하는 내일 배움 카드도 이제는 재직자에게도 오픈되어 있다. 과감하게 일정기간을 할애하여, AI전문가 양성과정, 클라우드 전문가 양성과정에 투입하는 것도 방법이라고 생각된다.
참고
1. Humonocracy , Gary Hamel 지음
2. The Art of Beuraucracy, Mark Schwartz 지음
3. 디지털 초격차 코드 나인, 이상호 지음
4. 프로젝트에서 제품으로, 믹 커스텐 지음 최희경 외 옮김
5. 팀 토폴로지, 매튜 스켈톤 , 마누엘 페이스 지음 김연수 옮김
6. 애자일 컨버세이션, 더글라스 스퀴렐. 제프리 프레데릭 지음, 김모세 옮김
