개발자 / 애플리케이션

이점이 훨씬 많은 마이크로서비스 아키텍처 "관건은 복잡성 관리"

Lee Atchison  | InfoWorld 2021.12.08
개발자 생산성과 삶의 질을 떨어뜨리는 요인으로 애플리케이션 복잡성을 꼽은 주장이 최근 눈에 띈다. Infoworld 기사에서도 표준화된 서드파티 서비스와 기타 방법을 사용해 복잡성을 억제하는 여러 좋은 아이디어를 제안했다. 필자는 이 전략이 많은 조직에 가치를 제공한다는 데 동의한다.

그런데 이 기사는 동일한 애플리케이션을 상정할 때 마이크로서비스 아키텍처가 모놀리식 아키텍처로 된 함수형 애플리케이션보다 복잡하다고 언급하면서“죽음에 비할 만한 복잡성”의 이유로 들었다. 필자는 그 주장에 동의하지 않는다.
 
ⓒ Gettty Images Bank

필자가 생각하기에 이 시각에 내포된 메시지는 마이크로서비스 아키텍처가 개발자 효율성을 떨어트리는 복잡성을 유발한다는 것이다. 이 주장은 사실이 아니다. 마이크로서비스 아키텍처를 사용할 경우 모놀리식으로 구축되는 동급 애플리케이션에 비해 전체적으로 더 복잡한 애플리케이션이 만들어진다는 것은 사실이다. 다만 그 결과로 개발자 또는 설계자의 일이 더 복잡해지는 것은 아니다.
 

마이크로서비스 아키텍처의 복잡성

대규모 모놀리식 애플리케이션을 구축한 결과로 복잡성에 짓눌리는 상황에 처한 기업이 많다. 하나의 코드 베이스를 붙잡고 작업하면 독립적으로 기능을 추가하거나 결함을 수정하기가 어려워 고민하는 개발자가 너무 많다. 개발자가 한 애플리케이션에서 동시에 작업할 수 있는 프로젝트의 수가 제한된다. 또한 개별 프로젝트에서 수행한 변경이 코드 베이스에 광범위한 영향을 미치는데, 애플리케이션 규모가 커지고 복잡성이 높아지면 이 영향을 파악하기가 어려워진다. 이렇듯 다양한 문제가 결합할수록 복잡성은 계속 높아지고, 결함이 늘어나며 품질은 낮아지고 기술 부채는 증가할 수밖에 없다.

애플리케이션을 개별적인 모듈 또는 부분으로 쪼개면 이 복잡성도 분할할 수 있고, 단일 코드 베이스에서 작업하는 개발자의 수도 줄어들 수 있다. 또한, 변경의 영향 범위도 축소된다. 이는 대체로 더 안정적인 코드, 더 지원하기 용이한 코드, 더 적은 기술 부채, 전체적으로 더 높은 애플리케이션 품질과 개발자 생산성으로 이어진다.
 
애플리케이션 품질, 안정성과 개발자 생산성이 높아지면 개발자 경험이 개선되어 피로도, 번아웃이 줄어들고 궁극적으로는 개발 팀의 이직률이 낮아진다.
 
애플리케이션을 모듈화하는 방법은 많지만 그 중에서도 더 효과적인 방법이 있다. 애플리케이션 모듈화를 위한 최선의 방법은 마이크로서비스 기반 애플리케이션 아키텍처를 사용하는 것이다.
 
마이크로서비스 아키텍처와 개발 팀 및 소유권과 책임을 체계화하는 견고한 모델을 결합하면 개별 개발자가 더 작은 코드 베이스에 집중할 수 있는 조직을 구축할 수 있다. 개발자는 효율성과 생산성을 높이고, 기술 부채가 적은 상황에서 더 높은 품질의 코드를 만들게 된다. 업무 만족도가 높아지고 번아웃도 줄어드는 선순환이다.
 
전체적인 애플리케이션은 더 복잡할 수 있지만, 한 명의 개발자가 집중해야 하는 각각의 조각은 훨씬 덜 복잡하다. 따라서 마이크로서비스 모델은 개발자의 경험을 개선한다.
 

마이크로서비스마다 제각기 다른 특징 

그러나 단순히 서비스 또는 마이크로서비스 기반 아키텍처로 전환한다고 해서 이러한 이점을 저절로 얻을 수는 없다. 애플리케이션을 합리적으로 설계하고 팀을 적절하게 구성해야 한다. 특히 서비스 규모와 팀 조직, 두 가지에 초점을 맞춰야 한다.
 

서비스 규모

서비스의 규모는 개발자가 경험하는 복잡성에 큰 영향을 미친다. 서비스 규모를 너무 작게 설정하면 상호 연결된 서비스가 너무 많은 형태가 된다. 서비스 간 연결은 본질적인 복잡성을 현저히 높이는 요인이다. 애플리케이션이 전체적으로 더 복잡해지고 개발자는 그 복잡성을 감당해야 한다. 애초에 서비스로 전환한 목적이 무의미해진다.
 
반대로 서비스의 규모가 너무 크면 마이크로서비스 아키텍처가 제공하는 장점을 잃게 된다. 각각의 서비스가 미니 모놀리스가 되며 큰 모놀리스가 가진 복잡성 측면의 모든 단점을 그대로 갖는다. 이번에도 각 개발자는 증가한 복잡성에 대처해야 한다. 차이는 하나의 복잡한 애플리케이션이 아니라 여러 개의 복잡한 애플리케이션이라는 것뿐이다. 미니 모놀리스는 단기적으로는 개발자가 짊어지는 복잡성을 줄일 수 있지만 효과가 장기적으로 이어지지는 않는다.
 
따라서 서비스의 규모를 적절하게 설정할 때만 개별 개발자의 복잡성과 인지 부하를 효과적으로 낮추는 균형을 달성할 수 있다.
 

팀 조직

팀 규모, 구조, 소유권 책임, 영향 라인 역시 애플리케이션을 구축하는 데 있어 코드 자체 못지않게 중요하다. 서비스 아키텍처를 효율적으로 다루기 위해서는 애플리케이션 설계자를 중심으로 적절히 개발 팀을 조직해야 한다. 또한 팀이 소유한 서비스를 완전하게 관리하기 위해서는 이들에게 책임과 권위, 소유권을 부여하고 지원해야 한다.
 
이와 같은 조직 구성과 지원에 실패할 경우 또 다른 종류의 복잡성이 늘어난다. 그리고 이러한 복잡성 역시 조직에는 피해가 된다. 팀 조직(적절한 팀 배치, 책임 및 소유권 설정)은 개별 개발자가 애플리케이션에 대해 받는 인지 부하를 낮추는 데 매우 중요하다.
 
서비스 기반 애플리케이션 아키텍처에서 조직을 구성하고 팀 수준 책임을 부여하기 위한 모델을 기술하는 표준 STOSA 조직 모델을 추천한다. STOSA 모델에 대한 폭넓은 내용은 오라일리 미디어(O’Reilly Media)에서 출판된 필자의 책 “규모를 위한 설계(Architecting for Scale)”에서 볼 수 있다.
 

코딩 복잡성을 낮추는 도구

개발자가 직면하는 복잡성을 낮추는 데 초점을 둔, 원래 기사 이야기로 돌아가 보자. 마이크로서비스와 STOSA 조직을 활용하는 것 외에도 이 복잡성을 낮추는 여러 방법이 있다.
 
미래에 개발자 복잡성 감소 측면에서 큰 혜택을 줄 기술적인 방향 중 하나는 소프트웨어 보조 개발이다. 인공 지능(AI) 및 머신러닝 기술이 지원되는 도구가 개발자가 코드를 쓰고 문제를 진단하며 전체적인 코드 복잡성을 관리하는 데 도움을 준다.
 
많은 기업이 프로그래머를 위한 소프트웨어 보조 개발 도구에 집중하고 있다. 깃허브의 비주얼 스튜디오 코드용 코파일럿 AI 어시스턴트(Copilot AI assistant for Visual Studio Code)는 AI를 사용해서 개발자가 결함이 적고 안정적인 코드를 쓸 수 있게 해준다. 데이터독(Datadog), 뉴 렐릭(New Relic)과 같은 성능 모니터링 업체는 최근 개발자의 코드 내 문제 진단을 위한 높은 수준의 지원을 제공하는 도구를 발표했다. 마지막으로 아웃시스템즈(OutSystems)의 앱 디벨롭먼트 플랫폼(App Development Platform)과 같은 노코드 및 로우코드 도구는 개별 서비스와 애플리케이션을 구축하고 배포하는 데 필요한 인지 부하를 낮춰주는 고수준 서비스 생성 보조 기능을 제공한다.
 
애플리케이션 복잡성은 대부분의 조직이 대처해야 하는 문제이며, 어떻게 대처하는지에 따라 애플리케이션과 개발 조직의 건강 및 안정성, 비즈니스의 미래에 영향을 미치게 된다. 그러나 애플리케이션 복잡성에 대처하기 위한 방법은 많다. 내부 플랫폼을 구축하고 조직 전반을 외부 서비스에 맞춰 표준화하는 방법을 포함한 스콧 캐리가 말한 접근 방법은 좋은 전략이다.
 
그러나 마이크로서비스 아키텍처도 진지하게 고려해야 한다. 마이크로서비스는 전체적인 애플리케이션 복잡성을 높일 위험이 있지만, 각 개발자가 겪는 인지 부하와 가시적인 복잡성을 줄인다. 따라서 코드의 품질은 높아지고, 가용성과 개발자 사기는 늘어나며, 기술 부채는 줄어드는 긍정적인 영향을 미칠 것이다. editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.