복잡한 기술 스택이 경영진에게 주는 시사점

* 이 글은 ThoughtWorks 블로그에 올라온 Implications of Tech Stack Complexity for Executives를 번역한 글로 저자는 Jim Highsmith, Mike Mason, Neal Ford입니다.

디지털 환경에서 성공하려면, 다양한 기술 변화가 여러분의 조직에 시사하는 바를 알아야 한다. 이 기사는 새로 연재하는 Technology Radar Echoes 시리즈 1편으로 비즈니스 차별화를 이끄는 기술 문제와 솔루션에 대해 저자들이 가진 직관과 경험을 기업 리더들과 공유한다. 6년째 접어든 ThoughtWorks Technology Radar는 소프트웨어 개발과 사업 전략에 현저히 영향을 미치는 트렌드에 대한 평가서로 ThoughtWorks의 다국적 기술 자문 위원회에서 작성한다.

소셜 미디어와 스마트폰, IoT, 클라우드, 빅데이터로 기술환경이 바뀐 것은 불과 몇 년 전부터다. 그 이전의 기술 스택(응용 프로그램 구현에 쓰이는 서로 다른  기술 계층)은 단순했고 대부분 벤더 제품을 썼다. 대표적인 예가 마이크로소프트 스택인데, 프로그램 언어는 닷넷을 쓰고, 웹 응용 서버는 IIS, 데이터베이스는 SQL Server 제품을 쓰는 식이다.

오늘날 기술 스택은 폭발적으로 늘었다. 우리는 마이크로소프트의 Nano Server를 비롯해 Deis, Fastly, 아파치의 Spark 그리고 Kubernetes 같은 플랫폼을 쓰고 있다. Docker Toolbox, Gitrob, Polly, Prometheus, Sleepy Puppy와 같은 새로운 도구가 매주 등장한다. 프로그래밍 언어나 프레임워크에 있어서도 Nancy, Axon, Frege, Traveling Ruby 같은 언어들이 새롭게 소개되었다. Data Lake, Gitflow, Flux, NoPSD 같은 고급 기법도 성숙해졌고, 이런 행렬은 계속된다.

ThoughtWorks Technology Radar를 발표할 때마다 대략 120개 항목이 포함되고, 동시에 비슷한 숫자가 배열할 자리가 모자라 제외된다. 지난 5년간 우리가 심각하게 고려한 2,000건 정도의 기술이 레이더에 잡혔다. 추천 기술의 부분집합을 특정 프로그램에 적용하는 것까지 감안하면, 지난 5년간 기술스택의 복잡도는 지수적 증가세를 보이고 있다.

그런데 당신이 경영진의 일원이나 관리자 심지어 대표이사로서 기술스택 문제를 다뤄야 하는 이유는 무엇인가? 기술스택 문제는 기술자들이 다루면 될 일 아닌가? 그렇지 않다! 소프트웨어와 소프트웨어 개발은 디지털 미래를 여는 열쇠이다. 따라서, 구체적인 사항까지는 아니더라도 전반적 추이가 여러분 조직에 의미하는 바를 반드시 이해해야 한다.

기술은 다양한 형태로 차별화와 혁신을 주도한다. 경영진과 관리자는 다양한 기술이 시사하는 바를 반드시 이해해야 한다. 그래야만 올바른 의사결정을 할 수 있다.

시사점

기술 조경은 역동적인 균형 상태로 존재한다. 새로운 기술과 접근법이 나타나면, 기술 생태계가 이를 수용하고 새로운 평형 상태를 만든다.

최근 기술 조경 변화를 추리면 다음과 같다.

과거의 유물이 되어 버린 단일 벤더 솔루션

불과 얼마전까지만 해도 일부 대기업조차 단일 벤더 솔루션으로 기술 스택을 유지하곤 했다. 2000년 중반 Jim의 한 친구는 데이터웨어하우스 프로젝트를 할 때, 완전히 IBM 제품에만 의존해서 작업했다. 그 프로젝트에서 의뢰인은 IBM의 데이터웨어하우스 기술  스택을 고집했고, 오래된 AS/400 하드웨어를 사용했다. 개발팀은 마이크로소프트의 기술 스택이 당시 상황에서 더 효과를 낼 수 있다고 의뢰인 설득을 시도했다. IBM 하드웨어와 기술 스택을 사용하여 납기일을 수 차례 넘기고 난 후에야 비로소 윈도 서버에서 구동하는 마이크로소프트 스택을  이용해 프로토타입을 구축했고, 수차례 회의를 거친 뒤, 관리자는 기술 스택 변경을 받아들였다. 진전은 극적으로 이루어졌다. 그 회사가 새로운 응용분야로 진입할 때, 단일 벤더를 고수하는 해법은 실패로 끝난 것이다.

이러한 추세는 점점 더 추진력을 얻고 있다. 너무 많은 일들이, 너무도 빨리 벌어진 나머지 마이크로소프트나 오라클 같은 규모의 회사조차 따라잡기 버거울 정도다. 급속도로 쏟아지는 변화의 규모와 더불어, 상당수 변화에 내재된 파괴력은 기존 제품을 진부하게 만든다. 문제는 어떤 회사든지 자신들이 보물로 생각하던 것을 버리고 떠나기가 어렵다는 점이다.

오픈소스 도구가 부상 하면서 이러한 현상은 증가 추세에 있다. 오픈소스 도구는 회사를 넘나드는 협업을 촉진하여 벤더로 하여금 수많은 다른 기술을 활용할 때, 라이선스 취득 문제를 벗어나서 새로운 도구를 만들 수 있게 한다. 단일 기술 분야 전문기업으로 작고 특화된 회사를 촉진시킨다. 이제 대규모 벤더로 역량을 모아서 얻는 이점은 거의 사라졌고, 기술이 퇴조하는 상황에서는 도리어 퇴로가 막히는 아이러니에 놓인다.

“효율을 중시하는 경영자에게 표준화는 강조하고 또 강조하는 금언이다. 하지만, 오늘날의 세상에서 표준화는 조직을 경직시켜 자칫 괴멸로 이끄는 지름길이 될 수 있다.”

모바일 개발은 다양한 기기에서 구동하는 많은 운영체제 제작 벤더를 다뤄야 함을 뜻한다. 빅 데이터 개발이란 이기종 데이터베이스 관리 시스템(DBMS)을 다뤄야 함을 의미하며, DBMS 상당수가 오픈소스이거나 실적이 많지 않은 신규 벤더 제품이다. 하나의 DBMS를 쓰던 시대는 끝났다.

디지털 기업이 되고자 한다면 기술 스택 복잡성은 증가한다. 자연히 벤더 복잡성도 증가하여 골치 아픈 일이 많아지겠지만 그만큼 기회도 많아진다.

팀 구성과 조직 구조 변화의 필요성

기술 스택이 복잡해지면 기술 계층에 맞춰 팀을 꾸리는 것이 점점 효과를 잃는다. 인터넷 초기 기술 계층은 비즈니스 로직, 미들웨어, 표현 계층 정도로 고정되어 있었고, 기술 계층에 맞춰 팀을 조직하는 일이 매력적이진 않아도 그럭저럭 통했다. 이제는 불가능해졌다. 현대적인 애플리케이션 구축에 필요한 기술의 다양성으로 기능별 분업보다 협력하는 팀워크가 절실하다. 한 두명이 설계, 구축, 배포에 필요한 모든 기술을 갖고 있는 경우는 점차 자취를 감추고 있다. 게다가 필요한 기술 획득을 위해 팀의 규모가 커지면서, 다채로운 팀의 긴밀한 협력이 성공의 필수요소가 되고 있다.

과거에는 운영 비용과 복잡성 탓에 개발, QA, 운영 각각을 회사 내 독립 기술 조직으로 만들었다. 그러나, 클라우드와 DevOps 문화에 집중하면 자동화된 서버 개통과 제품 신기능 일일 배포가 가능하다. 이러한 역량은 아키텍처 측면에서 새로운 기회를 제공한다. 아키텍처를 기술 계층에 맞춰 구분하는 대신에 고객Customer, 주문Order과 같은 식으로 업무 영역의 개념 중심으로 팀을 조직해 나갈 수 있고, 기술 계층을 드러내지 않고, 각 서비스에 내포시킬 수 있다. 기술 계층에 따른 조직 대신 이러한 업무 영역 혹은 제품 기준으로 조직하는 추세는 디지털 기업화에 발맞춰 증가하고 있다. 만일 기술에 따라 나뉜 조직을 고수한다면, 특정 팀별로 나뉜 기능 탓에 상호작용 급증과 통합 문제가 심각하게 야기될 것이다.

협력적인 팀이란 절대 요소

팀이 복잡해지면서 협력의 중요성은 높아진다. 앞서 말한대로 오늘날 팀은 넓은 기술 범위를 요구한다. 순수 기술 스택 전문성은 물론이고, 운영부터 제품 설계와 제품 관리까지를 아우른다. 이러한 다양성에 대한 필요는 갈수록 증대되는 반면에 효과적 협력은 더욱 어려워지게 된다. 애자일agile과 린lean 운동을 통해 얻는 대표적인 혜택이 충분한 권한을 부여 받은 협력적인 교차기능 팀cross-functional teams의 장려이다.

더욱 어려워진 소프트웨어 전달 역량 구축

엔지니어링이 중요하다. 점차 많은 회사들이 글로벌 수준의 소프트웨어 전달 역량 없는 디지털 전략은 공염불이란 사실을 깨달아가고 있다.“디지털 기술이 경쟁 양상을 끊임없이 변모 시키면서, 제품과 서비스 차별화와 성능 개선이 갈수록 소프트웨어에 의존하고 있다. 소프트웨어의 치명적 중요성에 비해, 최고위 임원들이 보이는 무관심 수준은 놀라울 정도다. 최근 연구에 따르면, 훌륭한 소프트웨어 생산이 갖는 전략적 중요성을 제대로 평가하지 못하는 회사들은 대가를 치루지 않을 수 없을 것이라고 한다.” [소프트웨어 개발을 무시한 재앙, 2015년 매킨지 분기 보고]

글로벌 수준 소프트웨어 전달 역량 확보에  영향을 주는 다섯 가지 핵심 요소가 있다. 기술의 넓이와 깊이, 빠른 학습, 혁신 그리고 의사결정이 그것이다.

오늘날 애플리케이션을 구축할 때 필요한 기술의 폭은 기술 스택의 복잡도 증가에 비례하여 획기적으로 넓어지고 있다. 이를 따라 잡으려면 소프트웨어 배포 기술과 함께 IoT(Internet of Things) 기술 개발까지 병행해야 할 경우도 생긴다.

기술의 폭이 넓어졌을 뿐만 아니라 필요로 하는 기술의 깊이(기초 ~ 고급) 또한 증가하고 있다. 최신 애플리케이션에는 최신 기술이 필요하다. 마치 난이도 등급 5.10 암벽 등반자는 5.13 루트에 등정하는 기회를 얻을 수 없듯이, 평균 수준의 소프트웨어 팀이 깜짝 놀랄 만한 애플리케이션을 배포할 가능성은 매우 희박하다.

앞서 살펴본대로 기술 스택 변화 속도가 워낙 빠르기 때문에 내일 필요한 기술과 지식은 변할 것이다. 따라서, 당신이 필요로 하는 사람은 현재 필요한 기술을 보유하고 있을 뿐 아니라 미래의 기술도 빨리 습득할 수 있는 사람이어야 한다.

“적응하고 학습하는 문화를 뿌리내리는 일은 특정 기술을 구축하는 일 만큼이나 중요하다.”

길게 인용된 관찰기록에서 한 경영자는 개발자가 이직할까 두려워 훈련 보내기를 꺼려온 일을 후회한다고 했다. 그에 대한 대답은 "당신이 그들을 훈련은 시키지 않으면서 회사만 다니게 한다면 어떻게 되지요?”

기술적으로는 최신 유행을 따라가야 하지만 개발자들도 기술을 혁신적 방법으로 사용할 필요가 있다. 그러자면 모험심과 탐구 정신이 조직문화에 내재해 있어야 한다.

마지막으로, 조직에서 특히 중요한 것은 역량과 기술을 둘러싼 의사결정 개선이다. 다음과 같은 질문에 대해 결정할 수 있어야 한다. 필요한 기술이 무엇인가? 각 기술을 내부적으로 구축할 수 있는가? 각 기술세트skill set는 어느 정도 깊이로 필요한가? 공식적인 교육 훈련과 경험을 통한 기술 획득 사이에서 균형은 어떻게 맞추는가? 기술을 지속적으로 갱신하는 방법은 무엇인가? 내부적으로 기술을 구축할 것인가 아니면 외부에서 사오거나 빌릴 것인가?

외주개발, 내부개발, 공동개발 선택은 더 이상 비용 위주로 판단할 정도로 단순한 문제가 아니다

오늘날 많은 조직이 요구 수준에 맞추어, 기술과 소프트웨어 전달 역량을 구축하고 유지할 수 없음을 깨닫고 있다. 회사에서 필요한 인재를 유치하지 못하는 이유는, 먼저 최고의 개발자들의 높은 요구 수준에 비해 많은 회사의 IT 부서 급여수준이 낮은 탓이다. 또한, 최고의 개발자가 뉴욕이나 런던처럼 세계적인 글로벌 도시에 살기를 원하는데 반해, 회사 위치도 매력적이지 않기 때문이다. 또 일부 회사는 재능있는 이들을 장기 채용할 일 자체가 없다. 꾸준히 디지털 비즈니스 프로젝트를 만들어낼 수 없기 때문이다. 지난 10년간 비용 절감과 효율중심 전략을 구사하던 기간에 많은 회사들은 너무나 많은 역량을 외주 개발에 맡겼다. 현재 필요한 수준에 맞춰 다시 구축할 때는 기간이 오래 걸리게 되고 그 기간 만큼 경쟁에서 뒤쳐지는 상태에 놓이게 된다. 오늘날 디지털 비즈니스 구축 전략은 비용 절약이 아니라 혁신, 전달 주기, 그리고 가치 생성에 중점을 둬야 한다. 

오늘날 외주 기술 개발은 비용 절감이 아닌 역량 획득 관점으로 주도해야 하다. 나아가 여러분이 찾아야 할 대상은 단지 현재 필요한 기능 제공 뿐만 아니라 빠르게 새로운 기능을 구축해서 시연해 줄 수 있는 파트너이다.

외주 역량을 활용하여 긴급히 발생한 기회를 처리할 수는 있겠으나, 비용 절감 목적의 외주와 똑같은 문제를 야기하고, 증상은 오히려 증폭되어 나타난다. 예를 들어 외주 개발한 애플리케이션을 나중에 내부에서 자체 처리로 옮기려하면, 외주 개발 당시 드러나지 않았던 기술 전수 문제가 그제서야 드러난다. 기술 스택이 복잡해져서 기술 전수 문제는 더욱 확대되었다. 벤더 수가 늘어나고 새로운 형태의 계약이 등장한 탓에 추가적인 도전거리가 생겨난다. 일례로 계약의 어려움을 들 수 있다. 비용 통제 지향 계약은 그다지 어렵지 않던 일이었으나 혁신 중심의 가치 지향 계약은 상대적으로 난해한 일이다.

최신 기술 조직을 만들려면 비용이 든다

우리가 의뢰인을 통해 듣는 소식은, Hadoop 같은 최신 기술 스택을 수용하기가 두렵다는 것이다. 그 이유는, 직원들이 기술력을 충분히 갖출거라고 믿지 못하기 때문이라는 것이다. 동시에 그들은 젊고 유능한 인재를 유치하고자 하는데 그러자면 인재들이 신나게 일할 수 있도록 신기술을 수용해야 하는 것도 알고 있다. 이러한 역설은 기술 조직 수준에서 해결될 수 있는 문제가 아니다. 최고위 리더십이 요구되는 일이다.

달리 방도가 없다. 비용 절감 정신으로는 디지털에 정통한 기업이 될 수 없다. 복잡해지는 기술 스택에 따라 기술은 물론이고, 비즈니스 모델과 제품 수준 그리고 인재 영입 전쟁을 아우르는 혁신을 요구한다. 최신 기술 조직을 구축하는 전략 수행은 결코 가볍게 다뤄질 사안이 아니다. 선두를 지향하는 의사결정으로 비즈니스 전략 전체가 기업가 정신으로 무장하고 디지털 비즈니스를 창조하게 해야 한다. 그리고, 비용 중심으로 흘러가지 않도록 가치에 무게를 둬야 한다. 비용은 중요한 제약사항은 될 수 있겠으나 목표는 아니다.

기술 변화가 압도적이지만 뒤쳐지지 말고 선두로 가야 한다

오늘날의 경쟁환경에서 성공하기 위해서는 네 가지 핵심 역량이 필요하다. 효과적인 디지털 전략 수립, 역동적인 가치 주도 포트폴리오 관리 프로세스 구현, 빠르게 반복할 수 있는 소프트웨어 전달 역량 구축, 그리고 적응하고 혁신하는 조직 문화 확산이 그것이다.

“소프트웨어 엔지니어링은 단지 기술자에게만 중요한 것이 아니라 최고위 임원에게도 중요하다”

결론을 말한다면, 기술 변화는 비즈니스 변화를 규정하며, 장기적으로 사업의 생존 가능성도 높여줄 것이다. 최근 몇 년간 디지털 비즈니스 애플리케이션이 요구하는 기술 스택이 급격히 복잡해지면서 기업들은 곤경에 빠졌다. 디지털 비즈니스에 도전해야 하는 필요성이 제기 되는 상황에서, 다른 한편으론 이러한 도전에 걸맞는 기술 역량을 구축하면서 미처 예상 못한 어려움에 직면하고 있다. 기술 변화의 속도가 빨라질수록 기술 전략은 필히 비즈니스 전략을 지원해야 한다. 그 일을 의미있게 하는 유일한 방법은 신기술을 평가하고 채택하고, 적응할 수 있는 조직을 육성하는 일이다.