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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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