복잡성이 SW 개발자를 죽인다··· ‘패러다임의 전환’ 올까?

“복잡성은 살인적이다(Complexity kills). 개발자의 수명을 단축시킨다. 제품을 구상하고 제작하고 테스트하는 일을 어렵게 만든다. 보안 문제를 끌어들인다. 그리고 이용자와 관리자를 좌절시킨다.”

당시의 소프트웨어 개발 작업이 심각하게 복잡했다면, 클라우드 네이티브 시대에 소프트웨어 개발자가 마주치는 복잡성에 대해 그가 어떻게 말할 것인지 궁금하지 않을 수 없다. 

이제 직접 다룰 수 있는 서버에서 동작하는 모놀리식 아키텍처의 애플리케이션을 제작하는 시대가 끝나가고 있다. 다수의 마이크로서비스로 분해하고, 컨테이너 안으로 패키징하고, 쿠버네티스로 오케스트레이션 하고, 분산 클라우드 환경에서 호스팅해야 하는 상황이다. 그리고 이러한 전환은 소프트웨어 복잡성을 다른 차원으로 격상시킨다. 

여기에 안전하고 복원력을 확보해야 하는 요구사항과, 풍부한 기능의 소비자 등급의 경험에 대한 기대를 더해보라. 개발자는 지금까지 이런 수준의 부담에 시달려본 적이 없다고 표현해도 과언이 아니다.

아마존의 CIO인 워너 보겔스는 2019년 AWS 서밋 행사 중에 “마이크로서비스가 보편화된 환경으로 이동하면 복잡성이 확연히 증가한다”면서 “모든 것이 모놀리식 아키텍처였던 시절에는 더 단순했을까? 일정 부분에서는 분명히 그랬다”라고 말했다. 

반면, 복합적 기술을 API를 통해 기성품처럼 소비하기가 이처럼 쉬운 적이 없었다. 기본적인 라이브러리 및 프레임워크로부터 이미지 인식 기능, 또는 심지어 전체 지불 스택에 이르기까지 그렇다. 단순히 조립해서 비즈니스 로직을 덧씌우면 그만이다. 

그러나 이게 진짜 그렇게 단순할까? 월트 디즈니의 기업 기술 전략 총괄이었으며 현재 컨설턴트인 나이젤 심슨은 “소프트웨어 개발자가 되기가 오늘날처럼 어려운 적이 없었다”라고 말했다.

그는 “개발자들이 애플리케이션 개발과 머신러닝을 위한 고차원적 프레임워크를 이용해 더욱 많은 일을 할 수 있게 되었지만, 반대급부가 나타났다. 선택지의 폭발과 개발 속도의 가속화는 개발자가 시대와 보조를 맞추는 일을 어렵게 만든다. 그러면서 수많은 개발자가 곤경에 처한다”라고 말했다. 

기본적 복잡성과 우발적 복잡성 
소프트웨어 에이전시인 심플 스레드(Simple Thread)의 공동 설립자인 저스틴 에더리지는 기본적 및 우발적 복잡성(essential and accidental complexity)을 구분했다. 그는 “기본적 복잡성은 사업 영역 안에 있다. 기업의 환경은 극도로 복합적이고 따라서 기업이 해결하려고 하는 문제는 본질적으로 복합적일 수밖에 업다. 그리고 우발적 복잡성이 있다. 이는 우리의 여러 도구와 관련이 있다. 또 우리가 문제를 해결함에 있어 다루는 계층과도 관련이 있다”라고 말했다. 

클라우드 네이티브 시대는 우발적 복잡성의 가능성이 어느 때보다도 더 높다. 개발자는 이용할 수 있는 툴킷을 최대한 활용하려 하고, 개발자의 상사는 개발자가 고객에게 가치를 전하는 데 전념하기를 원하면서, 서로 충돌한다. 

에더리지는 “오늘날의 소프트웨어 개발자 부족 현상을 감안하면, 개발자가 우선적으로 고객에게 가치를 전달하도록 압박할 여지가 별로 없다”면서 “엔지니어가 이런 식으로 생각하도록 만드는 일은 쉽지 않다”라고 말했다. 

풍부한 선택지의 부작용 
클라우드 컴퓨팅과 오픈소스 소프트웨어 운동의 인기에 힘입어 개발자가 한층 확장적이면서 한층 복원력 있고, 모듈식이고, 업데이트가 가능한 애플리케이션을 제작하고 실행하는 데 이용할 수 있는 선택지들이 무서운 속도로 증가했다.

휴머니텍(Humanitec)의 설립자인 카스파 본 그런버그는 “모든 것이 과거에는 훨씬 더 단순했다. 그러나 복잡성 문제가 출현한 배경은 업계가 실수를 했기 때문이 아니다. 여러 시스템에 대한 수요가 극적으로 증가해 더 빠르게 출하해야 했기 때문이다”라고 말했다. 휴머니텍은 기업이 자체 개발자 플랫폼을 제작하는 데 도움을 주는 신생 기업이다.

CNCF는 클라우드 네이티브 생태계를 구성하는 1,000여 개의 각기 다른 서비스에 대한 인터랙티브 도표를 관리한다. 이들 가운데 많은 수가 무료이고 오픈소스이다. 아울러 3대 클라우드 사업자인 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드는 각각 200가지 가량의 독창적 서비스를 고객에게 제공하고 있다. 이러한 서비스는 컴퓨트, 스토리지, 데이터베이스, 애널리틱스, 네트워킹, 모바일, 개발자 툴, 관리 툴, 사물인터넷(IoT), 보안, 기업용 애플리케이션을 망라한다. 

레드몽크(RedMonk)의 애널리스트인 스티븐 오’그래디는 2020년의 한 블로그 게시물에서 “애플리케이션 개발 과정이 현재 지나치게 파편화되어 있다. 모든 기업 아키텍처가 3계층으로 이루어지고, 모든 데이터베이스가 관계형이고, 모든 비즈니스 애플리케이션이 자바로 쓰여져 애플리케이션 서버에서 배포되던 시절은 지났다”라고 적었다. 

그러면서 “오늘날의 인프라의 한가지 가장 명확한 특징은 하나의 명확한 특징 같은 것은 없다는 것이다. 지나치리만큼 다양하다”라고 덧붙였다.

텀블러(Tumblr)의 CTO를 역임한 마르코 아먼트도 비슷하게 표현했다. 그는 2015 “웹 개발이 지금처럼 복합적이거나 뒤얽힌 적이 없었다. 대다수 현대 웹 개발 환경에 연관된 툴의 수 때문이다(게다가 이들은 급속히 변화한다)”라고 밝혔다.

소규모 독립적 팀이 고객 요구에 대응해 서비스를 제작하려는 움직임이 늘고 있다. 이를 위해 클라우드 업체는 시도-및-시험 기법(tried-and-tested approach)을 다수 선보였다. 이로 인한 영향 가운데 하나는 개발자가 비즈니스 가치를 전달할 수 있도록 무수한 구성 요소를 조합하는 방식을 선택하는 데 있어 재량이 매우 커졌다는 것이다.

금융서비스 회사인 투 시그마(Two Sigma)의 플랫폼 엔지니어링 책임자인 카밀 포니어는 “마치 캔디 상점에 있는 어린이 같다. 더욱이 무언가를 결합하려고 시도할 때 복잡성은 필연적으로 배가된다”라고 말했다.

그렇다면 평균적인 소프트웨어 개발자에게 이러한 선택 수준이 과연 긍정적인가라는 의문이 생긴다. 오’그래디가 위의 2020년 블로그 게시물에서 결론 지은 것처럼 “수많은 서비스를 이용할 수 있다는 사실에 내재된 복잡성은, 특정한 환경에서, 강점이라기 보다는 오히려 부담으로 작용할 수 있다.”

내부 플랫폼을 구축한다면?
이렇듯 증가 중인 복잡성 문제는 여러 조직이 중앙 플랫폼 모델을 도입하도록 유도했다. 여기서는 내부 플랫폼 팀이 엔지니어에게 필요한 툴을 검토하고 템플릿을 제작하고 이들이 실무에 쉽게 유입될 수 있는 골든 패스(golden paths)를 계획하는 일을 담당한다. 한편으로는 재무 업무, 보안, 거버넌스 등의 기능을 중앙화해 개발자의 부담을 완화한다.

음악 스트리밍 대기업인 스포티파이(Spotify)의 예를 들어본다. 스포티파이의 제품 매니저인 게리 니먼은 2020년의 블로그 게시물에서 “6년 정도 전부터 스포티파이는 자율적 팀을 바탕으로 애자일 엔지니어링 문화에 전념했다”면서 “온갖 장점이 있었지만, 복잡성도 발생했다. 예를 들어 개발자 툴링 생태계의 파편화이다. 여기서는 무언가를 하는 방법을 알려면 동료에게 물어보는 수밖에 없었다”라고 말했다.

물론 이 방식은 스포티파이의 급속한 성장을 이끌었다. 그러나 이제는 오히려 혁신 속도를 늦추고 있음이 드러났다. 통합과 단순화가 필요했다. 니먼은 “권고된 툴링은 쉽게 발견할 수 있어야 한다. 전체 툴링의 여정은 명확해야 한다. 양질의 이용자 설명서가 있어야 한다. 그리고 일을 하다 막혔을 때 지원받을 곳이 분명해야 한다”라고 말했다.

휴머니텍의 본 그런버그는 우수한 내부 개발자 플랫폼의 핵심을 논했다. 그는 2021년 게시물에서 “개발자가 당면한 일을 진척시키기 위한 셀프 서비스, 그리고 가치가 적은 작업을 제거하는 것 사이의 균형을 발견하는 것이고, 이때 개발자가 제약이 있다는 느낌을 받지 않아야 한다”라고 말했다.

스포티파이 제품 매니저인 니먼은 “골든 패스의 배경이 되는 생각은 엔지니어를 제한하거나 억압하지 않는 것이고, 또는 이를 위해 표준을 정립하지 않는 것이다. 골든 패스가 정착하면 팀은 바퀴를 재발명 할 필요가 없고, 내려야 할 결정의 수가 줄고, 자신의 생산성과 창의성을 고차원적 목적을 위해 사용할 수 있다. 이들은 신속한 움직임으로 돌아갈 수 있다”라고 말했다.

컨설턴트인 심슨은 “개발자가 툴을 재발명하고 싶어하는 것”이 문제라면서 “더 나은 쥐덫을 만드는 것만큼 개인적으로 만족스러운 일도 드물다”라고 말했다. 그러나 스택 오버플로우 사이트에 수많은 해답이 이미 있는 세계에서 이게 개발자의 시간을 가장 효과적으로 사용하는 것일까? 

마이크로소프트의 개발자 사업부의 제품 CVP인 아만다 실버는 “개발자를 억압하려 하는 조직이 있는가 하면 개발자에게 재량권을 주려는 조직이 있게 마련이다. 핵심은 개발자 속도라는 개념이다. 개발자가 자신이 코딩할 수 있는 것만 코딩하고, 전문성이 없는 영역을 배워야 하는 부담을 지거나 산만해지지 않는 체계를 구축하는 것이 좋다”라고 말했다.

1987년에 설립된 여행 기술 회사인 아마데우스(Amadeus)는 이들 기술 변화의 흐름을 몸소 경험했다. 메인프레임 상에서 원래의 애플리케이션을 구축했다가 2000년대 초반에 오픈 리눅스 플랫폼으로 이동했고 이제는 쿠버네티스에 의해 오케스트레이션 되는 컨테이터화된 애플리케이션으로 대거 전향하고 있다.

아마데우스 인프라 및 클라우드 책임자인 에도드 허빈은 “개발자들이 회사가 제공하는 핵심 위에서 개발할 수 있어야 한다. 따라서 플랫폼 접근법에 의해 이들에게 기능을 제공한다”라고 말했다.

그는 이어 “신기술은 보안과 안정성 때문에 보다 많은 복잡성을 가져온다. 이런 시스템을 가동하는 데는 안정성이 중요하다. 데이터 주도형 애플리케이션의 출현은 우리에게 차원이 다른 복잡성이다. 이는 애플리케이션을 코딩하고 피드백 루프를 구축하는 새로운 방식이다. 이들은 모두 새로운 것이고 복잡성을 가져온다”라고 지적했다.

그 결과 허빈은 내부 팀이 솔루션을 설계하거나, 합당한 경우 매니지드 서비스를 이용하며 복잡성을 완화하려 한다. 데이터베이스가 한 사례다. 아마데우스는 몽고DB 인스턴스를 자체적으로 운영했지만, 이제 벤더가 관리하는 몽고DB 아틀라스를 이용한다. 회사는 관리형 쿠버네티스에도 비슷한 관점을 취하고 있다.

이는 엔지니어가 생태계에 새 툴을 도입하는 일을 추진하지 않는다는 것이 아니다. 허빈은 “간혹 거부해야 할 때가 있다”면서 “최근 사람들이 새 데이터베이스를 도입하려고 했다. 이들의 생각은 타당했다. 그러나 선택지가 아주 우수한 것이 아니라면 회사가 사용하는 데이터베이스의 수를 통제하는 것이 더 좋다”라고 말했다. 

대형 조직에는 다양한 유형의 엔지니어가 있다. 탄력적 시스템을 구축하는 일에 전념하는 엔지니어, 고객에게 신속히 기능을 전달하는 데 전념하는 엔지니어가 있는가 하면, 최신 기술을 어떻게든 고쳐 쓰려고 애쓰는 엔지니어도 있다. 두 유형 모두 가치가 있지만 이들을 주의 깊게 관리해야 한다고 투 시그마의 포니어는 말했다.

이어서 그는 “새로운 것의 내부를 살피면서 이를 이해하는 일을 좋아하는 사람이 필요하다. 베어메탈 쿠버네티스를 운영할 사람이 있어야 하기 때문이다. 한편 새로운 것을 살펴보면서 작용 방식을 이해하고, 유용한 분야, 같이 일할 수 있는 파트너를 식별하고, 투자할 가치가 있는지 판단하는 것을 좋아하는 사람도 필요하다”라고 말했다.

벤더가 복잡성에 대처하는 방식 
구글 클라우드의 수석 디벨로퍼 애드보킷인 켈시 하이타워는 클라우드 소프트웨어 업계의 여러 동료와 마찬가지로 현재 개발자에게 주어진 선택의 풍부함이 ‘선물이자 저주’라고 생각한다.

선물이란 거의 무제한적인 수의 기술을 개발에 사용할 수 있다는 것이다. 저주란 개발자가 개발자의 워크플로우까지 인프라가 흘러나오는 상황에 빠지고 있다는 것이다. 이제 매니지드 서비스와 추상화에 집중하는 벤더가 많기 때문에 상황은 반대로 향하는 듯하다. 대대적인 파편화 이후는 대대적인 통합의 차례인 것일까?

하이타워는 “어쩌면 이제 충분히 개발했으니 새로운 것의 개발을 멈출 수 있다고 말할 수 있을지 모른다. 이제 우리가 가진 것을 성숙시키면서 기술을 소비하는 각자의 역할로 돌아가는 것이다. 어쩌면 이는 우리가 지난 10년간 목격한 데브옵스 및 협업 움직임의 행복한 결말일지 모른다”라고 말했다.

시장은 별도의 서비스, 관리형 선택지, 프레임워크, 라이브러리, 플랫폼을 계속 증가시키면서 복잡성에 대응하고 있다. 그러면서 개발자가 자신의 환경이 가진 복잡성에 맞서는 데 도움을 주려 한다.  

오’그레디는 2020년 블로그 게시물에서 “물론, 필수적인 조각을 모두 제공할 수 있는 벤더는 없고, 앞으로도 그럴 것이다. 심지어 가장 다양한 애플리케이션 포트폴리오를 보유하고 있고 역사적으로 전례가 없는 배포 속도를 가진 AWS조차 모든 개발자 니즈를 충족시킬 수 없고, 모든 연관 개발자 커뮤니티를 소유할 수 없다”라고 말했다.

오’그레디는 또 다른 게시물에서 다음과 같이 밝혔다.

“우리는 구매자와 개발자를 모두 미로 안으로 보내는 일로부터 탈피하고 있음을 시사하는 증거가 풍부하다. 우리는 이들이 원시적인 것을 선택해 처음부터 조립하도록 하는 작업으로 부담을 주었다. 최초의 클라우드 시대를 원시적인 것으로 정의한다면 이는 끝나가고 있다. 컴퓨팅 산업이 처음부터 그랬던 것처럼, 후속의 클라우드 시대는 우리가 이들 원시적인 것 위에 구축하는 추상화로 정의될 것이다.”

이들 원시적인 것을 일관성 있는 내부 플랫폼으로 조립하는 일은 여러 엔지니어링 위주의 조직에게 성공적 우회 수단인 것으로 이미 증명되었지만 전통적 기업이라면 복잡성을 완화하는 데 이들의 공급 업체에 전적으로 의존할 가능성이 높다.

쿠버네티스의 공동 제작자이자 현재 VM웨어 R&D 부사장인 크레이그 맥루키는 “일정 환경에서 복잡성은 불일치보다 덜 중요하다”라고 말했다. 그는 개발자가 증가하는 복잡성에 더 편안히 대처할 수 있는 방법을 찾는 것이 자신의 역할이라고 생각한다. 복잡성은 툴 체인의 파편화에 의해, 고도의 확장성을 가진 시스템의 본질에 의해 견인되고 있다는 설명이다.

몽고DB 에반젤리스트 매트 아세이는 최근 기고문에서 “오늘날 클라우드의 진짜 담론 중 하나는 ‘다양한 클라우드 서비스를 누가 가장 우수하게 통합할 수 있는가’이다. 클라우드는 더 지루해짐으로써 훨씬 더 흥미로워질 것이다”라고 말했다.

기계에 대한 공감이 필요 
위대한 단순화가 임박했다면 소프트웨어 개발자란 존재의 근본적인 무언가를 사라질 가능성도 있을까?

전설적인 영국인 자동차 경주 선수인 재키 스튜어트는 “자동차 경주 선수가 되기 위해 엔지니어가 될 필요는 없지만, 기계에 대한 공감은 있어야 한다”라고 말했다. 다른 말로 하자면 진정으로 위대하기 위해서는 자신이 가동하는 기기에 대해 알고 있어야 한다.

즉, 현대의 소프트웨어 개발자는 복잡하고 확장성 있고 분산된 시스템에 대해 전적인 기계적 공감을 가질 수는 없겠지만 최대한 이해하려고 할 필요가 있다.

마이크로소프트의 실버는 “개발자는 시스템 사람들이다. 우리는 시스템이 어떻게 작용하는 지를 베어 메탈에 이르기까지 이해하고 싶어한다. 그러나 동시에 깊이 파고들 필요까지는 없는 온갖 종류의 영역이 있다”라고 말했다.

여러 개발자 및 그의 팀이 해야 할 일은 자신의 전문성이 가장 가치 있는 분야, 바퀴를 재발명 하면서 낭비되고 있는 분야를 식별하는 것이다. 

컨설턴트 심슨은 “우리가 가진 바램은 기업들이 이 문제를 인식하고, 기계가 어떻게 작용하는 지에 관해 우려하는 일로부터 개발자를 탈피시키는 것이다. 그리고 그들이 가장 잘하는 소프트웨어 제작으로 돌아가게 하는 것이다”라고 말했다. 

소프트웨어 개발자가 이용할 수 있는 선택과 복잡성이 오늘날보다 더 풍부한 적은 없었다. 동시에 추상화의 선택지 또한 이렇게 많은 적이 없었다. 결국 문제는 개발자와 개발자의 조직이 목표를 추구해가면서 어느 정도까지 복잡성을 소화할 수 있는가로 귀결된다.dl-ciokorea@foundryco.com