brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Feb 03. 2023

Cloud Native가 만드는 규모의 경제

베터코드 인사이트의 시작 15편

지난 글에서 Cloud Native 환경에서는 응용의 집적에 대해 관심을 가질 필요가 있다고 주장했다. 왜 그런가?


소프트웨어 개발의 경쟁력

우선 나는 관심을 갖고 있다. 소프트웨어 개발을 업으로 하는 기업을 운영하고 있기 때문이다. Cloud Native 환경에서 한번 만들고 반복해서 쓸 수 있는 소프트웨어 구성이 가능하다. 사실 그렇게 해야만 Cloud Native 환경에 들어가는 노력이 경제성을 갖기 때문이다. 앞서 규모의 경제 실현 방법이 두 가치 차원으로 나뉘어서 벌어진다고 주장했다.


각각은 별도의 노력이 필요하지만, 규모의 경제는 인프라의 집적과 응용의 집적이 함께 만날 때 극대화된다. 나의 관심은 이런 상상에 기초한 관심이다. 한번 만들어서 반복해서 쓸 수 있다면 경쟁력을 갖게 되기 때문이다. 이는 관점에 따라 가격 경쟁력일 수도 있고, 생산력 증가일 수도 있다. 상상에 따라 전혀 다른 성격의 경쟁력이 될 수도 있다.


Cloud Native 환경에서의 재사용이란?

재사용(reuse)이라는 단어를 쓰자 대학원에서 연구했던 주제가 떠오른다. 호기심이 인터넷에 흔적이 있는지 찾아보니 놀랍게도 Business Component 활용 방식을 제안했던 발표 흔적과 통신 분야에 적용하여 파일럿으로 해보고 쓴 사례 논문 정도를 찾을 수 있었다.


다만, 거의 20년의 시간이 흘렀고 재사용 양상이 많이 바뀌었다. 이론적인 어휘들로 채우는 대신에 다시 오라클의 웹 문서의 내용을 차용하여 상상을 실용적으로 만들어 보자. 지난 글에서 인용한 그림에서 컨테이너 내부 구성만 따로 보자.

Docker 나 Kubernetes 등의 기술 덕분에 우리는 컨테이너(Container)라는 산업 표준을 갖게 되었다. 19년 전 필자가 재사용을 논할 때에는 J2EE 컨테이너와 같은 식의 기술이 존재했다. 언어 제약이 있었다는 뜻이다. 그런데 위 그림을 보면 괄호 안에 다양한 프로그래밍 언어와 요소 기술이 쓰여 있다. 이들은 제약 사항을 뜻하는 것이 아니라 개발자 혹은 개발 조직이 자유롭게 선택해서 사용할 수 있다는 뜻이다.


Cloud Native 환경에서의 재사용 극대화

인프라의 발전에 대해서는 클라우드 인프라 시장의 승자에게 맡기고, 응용의 집적에 초점을 맞춰 보자.[1] 응용의 집적이라는 말은 달리 표현하면 응집력 있는 프로그래밍 자산을 오래 쓸 수 있게 만들어야 하는 일이다. 이제 상상이 허상이 되지 않으려면 응집력이 무엇인가에 대해 의미 있게 정의할 수 있어야 한다.


이전에 Kent Beck의 글을 소개하며 다음 질문에 대한 측정이 응집력이라고 주장했다.

안전한 변경을 가능하게 하는가?


시장의 승자는 규모의 경제에서 승리하는 자이고, 이는 한번 만들고 반복해서 쓰는 역량을 갖춘 개발 조직에게 돌아갈 것이다. 물론, 사업성이 있고 쓰기에 편해야 하겠지만, 여기서는 비즈니스 영향도는 배제한다. 지극히 개발 역량에 대해서만 초점을 맞추기로 한다.[1]


이렇게 생각을 골똘히 해 보면 결국 쉽게 수정을 하는 역량을 갖춰야 한다는 결론에 도달할 수 있다. 그리고, 그렇게 되려면 마치 인수분해하듯 명확하게 나눠진 모듈이 힘을 발휘할 수 있다. 더불어 'loosely-coupled' 즉 빠르게 재구성하는 구성 역량도 갖고 있어야 한다.


적응력 혹은 발전 속도의 문제

이때 규모의 경제를 활용하는 방법은 모듈 입장에서는 재사용을 극대화하는 일이다. 재사용의 축은 크게 두 가지다. 하나는 시간의 축이고, 두 번째는 연결의 축이다.


시간의 축은 지난 글에서 인용한 표에서 개발 프로세스가 빈도(frequency)를 높이는 방향으로 발전한다는 점에서 추이를 읽을 수 있다. 복제 비용이 0에 수령하는 소프트웨어의 특성을 고려하면 수정을 통해 더 많이 쓰이는 방식이 바로 규모의 경제에서 승자가 되는 비결이다.


두 번째 축은 바로 Open API가 만들어 내는 혁신이고, Cloud Native가 산업 표준 형태로 발전하는 동력이기도 하다. 경쟁사로 볼 수 있는 오라클과 아마존(그리도 더 많은 회사들)이 Cloud Native에 대한 설명을 하는 이유는 무엇일까? 둘 다 함께 얻는 이득이 있기 때문이다.


글이 길어졌으니 응용의 집적에 대해 논하기 위해 앞서 인용한 그림을 다시 보자. 응용의 집적은 일과 클라우드 인프라의 집적을 이루는 일은 다른 차원이지만 둘은 규모의 경제란 측면에서 시너지를 낸다고 말했다.

예시로 제시한 모듈 형태의 소프트웨어가 수많은 조합으로 집적을 이뤄내면 클라우드 인프라를 구축하는 기업 입장에서도 반사 이익을 얻을 수 있다. 이러한 상호 이익의 기반이 산업 표준을 만드는 동기가 된다.


맺음말

<Cloud Native가 무슨 말인가?>편에 이어 Cloud Native란 주제를 따라왔다. 그랬더니 규모의 경제가 만드는 힘이 강력하게 느껴졌다. 자본시장이 주도하는 기술 발전임을 고려하면 당연한 일이라 하겠지만, 글을 쓰며 생각해 보기 전에는 몰랐던 사실이다. 다음 글에서는 조금 더 소프트웨어 개발 조직 입장에 초점을 맞춰 생각해 보기로 하겠다.


주석

[1] 미래를 정교하게 예측하는 일은 확실한 시간 낭비다. 다만, 전략적으로 행동하기 위해서는 다른 것은 무시하고 가장 중요한 요인에 집중하기 위한 분석이 필요하다. 무엇이 가장 중요할까 생각해 보는 것이다.


지난 베터코드 인사이트의 시작 연재

1. 추적성(Traceability)과 그 쓰임새

2. 베터 어드민의 아기 발걸음 그리고 작명

3. Funnel을 마케팅 말고 engagement 분석에?

4. 디지털 대전환기란 나에게 무엇인가?

5. 기술 부채는 무엇인가?

6. 폭포수 방식 설계는 기술 부채를 남긴다

7. 기술 부채는 낮은 코드 품질에 대한 것이 아니다

8. loosely-coupled: 빠르게 재구성하는 힘

9. 건강한 조직이 만들어지는 배경

10. 구축 사업 관리에 가려진 기술 부채

11. 기술은 쓰임새(use case)에 따라 고르고 조합한다

12. Ubiquitous Language 만들 결심

13. 회사 대표가 엔지니어에게 충분한 권한을 주는가?

14. Cloud Native가 무슨 말인가?

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari