( 글은 클라우드 네이티브 앱을 개발하고 운영하는 팀을 대상으로 하되, [개발 역량] 초점을 두고 작성하였습니다. 따라서, 클라우드 인프라, DevOps 영역에 대한 내용은 없습니다. 참고하시고 읽어주시면 고맙겠습니다.)

클라우드 환경은 지원하는 기술 스택에 따라 IaaS, PaaS, SaaS 세 가지로 분류합니다. 시간의 흐름에 따라 IaaS에서 SaaS를 향해 발전하는데, 2001년 현재 우리는 PaaS 시대에 있습니다. IT 현장에서의 느낌은 변화는 기술 스택으로 나누기 보다는 경량 컨테이너(Docker) 사용 전후로 나눌 수 있습니다. 현장에서는 경량 컨테이너는 클라우드의 역량을 발휘할 수 있는 핵심 요소이며, Cloud Native를 가늠하는 기준이 되었습니다. 그래서 애플리케이션을 설계할 때도, 경량 컨테이너에 맞추어 “마이크로”하게 설계할 수 밖에 없습니다.

IT 기업은 클라우드 네이티브 역량을 목표로 개발과 운영 조직을 다시 정비하고 있습니다. 많은 조직이 개발 보다는 운영에 초점을 두고 조직의 역량을 키우고 있는 것을 볼 수 있습니다. 이 글에서는 운영 보다는 개발 관점에서 클라우드 네이티브 역량에 대한 이야기를 하려 합니다. 훌륭한 클라우드 인프라 위에 훌륭한 클라우드 네이티브 앱이 필요합니다. 클라우드 인프라 구축에 실패하는 경우는 거의 없지만, 클라우드 네이티브 앱 역량을 제대로 갖춘 팀을 찾기는 매우 어렵습니다.

PaaS 기반 운영 환경에서 애플리케이션은 MSA를 주로 채택하고 있습니다. 경량 컨테이너를 사용하기 때문입니다. 기존의 WAS 기반 애플리케이션을 설계할 때와는 달리 인프라의 많은 부분이 캡슐화되므로, 애플리케이션 자체에 집중할 수 있게 되었습니다. 클라우드 발전과 함께 DevOps 영역이 새로 등장하면서 Dev, DevOps, Ops의 경계가 애매한 상태입니다. 팀은 역량을 갖추어야 할 곳, 즉 구체적인 역량 목표를 설정하기 위해 영역과 활동에 대한 명확한 정의가 필요합니다.

[ Dev와 DevOps의 경계]

DevOps 영역은 팀이 선택한 솔루션과 관계가 있으며, 주로 솔루션을 사용하는 영역입니다. 반면 Dev 영역은 마이크로서비스 개념을 적용한 애플리케이션 개발을 잘하는 것이 중요한 영역입니다. 이 개발에서 중요한 점은 애플리케이션을 네이티브 클라우드 앱으로 개발하여야 한다는 사실입니다. MSA를 선택한다고 가정할 때 다음과 같은 생소하고 다양한 설계 주제를 갖게 됩니다.

  • 마이크로서비스 구조
  • 마이크로앱 구조
  • 마이크로서비스 협업 구조
  • 협업(이벤트, API 콜) Observability
  • 멀티-테넌트 지원
  • 서비스 저장소와 구독
  • 이벤트 처리와 분석 체계
  • 도메인 드리븐 모델 적용
  • 바운디드 컨텍스트 정의와 구조, 그리고 매핑

마이크로서비스, 마이크로앱, 서비스 협업, 서비스 추적, 멀티-태넌트, 서비스 구독 등의 개념은 WAS 기반 시스템에서는 볼 수 없었던 기술 요소들입니다. 이들을 포함하는 클라우드 네이티브 애플리케이션 설계에 필요한 기술을 정리할 필요가 있습니다. 물론 기술 요소 중에는 팀별 선택에 따라 달라지는 것도 있습니다. 어떤 팀은 SPA 라이브러리로 React를 사용하지 않고 Vue나 Angular를 사용하기도 합니다. Kafka 대신에 NATS나 Redis Stream을 사용하기 합니다. 선택에 따른 차이를 고려하여 보시기 좋겠습니다. 프로그래밍 언어, 라이브러리, 모델링 기법, 디자인 도구, 이벤트 플랫폼 등을 정리하였습니다.

한 사람이 모든 기술을 알고 다룰 수 없으므로, 우리는 역할을 정의합니다. 역할 담당자가 활동에 기술에 집중하는 방식으로 일을 하므로 팀은 전문성을 가질 수 있습니다. MSA 기반 클라우드 네이티브 앱을 개발에 참여하는 역할은 7 개 정도로 요약할 수 있습니다. 클라우드 네이티브 앱 개발에 필요한 22개의 기술 요소는 7개의 역할 담당자들이 역할 수행에 필요한 기술을 갖추는 방식으로 해결합니다. 조직의 클라우드 네이티브 앱 개발 역량을 평가할 때 위의 22개 기술 요소를 조직의 역할 담당자들이 충분히 갖추었는지 따져보아야 합니다. 필요한 역할을 다음과 같습니다.

  • 애플리케이션 아키텍트
  • 프론트 엔지니어
  • 백엔드 엔지니어
  • UI/UX 전문가 (디자이너 포함)
  • 테스트 엔지니어
  • DevOps 엔지니어
  • 도메인/데이터 모델러

프론트와 백엔드 역량을 모두 갖춘 엔지니어를 풀스택 엔지니어라고 하는데, 이 글의 분류에서는 제외합니다. 기본적으로 한 사람은 여러 역할을 수행할 수 있기 때문입니다. 22 가지 기술 요소에는 각 역할 담당자 별로 책임져야 하는 기술 요소가 있습니다. 다양한 중첩이 발생할 수 있지만, 개략적으로 범위를 정해보면 아래 그림과 같습니다. 어떤 팀의 네이티브 앱 역량을 평가할 때, 22가지 기술 요소를 7가지 역할 담당자가 충분히 감당할 수 있는지 여부를 확인하면 됩니다.

물론 위의 기술 요소는 대표성을 갖는 이름이므로 그 아래 놓여 있는 다양한 기술들이 있습니다. 조직의 역량을 상세하게 진단하고 평가하려 할 때는 상세 기술을 나열하고 각 기술에 대한 역할 담당자의 역량을 확인하여야 합니다. 각 기술 영역 별로 세부 기술을 정리해봅니다. 마찬가지 세부 기술에도 팀별 선호도가 있으므로 감안하고 보시면 좋겠습니다.

대략 80여 개의 세부 기술이 있습니다. 휴… 클라우드 네이티브 팀이 되기 위해서는 위의 역할 담당자들이 이 기술들에 대한 충분한 지식과 경험을 갖추어야 합니다. 팀평가 결과 부족한 부분을 확인한다면 그 기술 역량을 갖추기 위한 다양한 교육 훈련, 또는 파일럿 프로젝트 등 후속 조치가 필요합니다.

그런데 이 많은 기술에 대한 역량 평가를 어떻게 해야 할까요? 기업의 역량 개발 담당자들의 오랜 숙제이기도 합니다.
모든 기술에 대해 시험을 볼 수도 없고, 인터뷰를 할 수도 없고, 동료나 상급자가 평가할 수도 없고. 평가 방법에 대한 이야기는 다음 글로 미루겠습니다.

클라우드 네이티브 앱 개발 또는 MSA 기반 앱 개발 역량은 Digital Transformation 시대에 가장 중요한 기업의 IT 역량이 되었습니다. 많은 기업들이 이런 역량을 갖추기 위해 DevOps 영역에 집중하는 경향이 있습니다. 실제로 중요한 역량은 클라우드 네이티브 앱 설계와 개발 역량입니다. 이번 글에서는 바로 이 앱 설계와 개발 역량에 필요한 기술과 역할에 대해 살펴보았습니다.

고맙습니다.
송태국(tsong@nextree.io)
namoosori
안녕하세요. 나무소리 입니다. 나무소리는 넥스트리(주)의 교육 브랜드 입니다.넥스트리가 지난 20년 동안 쌓아온 개발 및 교육 경험들을 나무소리를 통해 많은 분들과 공유 하려고 합니다.앞으로 저희 나무소리를 통해 보다 나은 교육을 경험 하실 수 있도록 구성원 모두 최선을 다하겠습니다.