비즈니스에 적합한 아키텍처 찾기 
#MSA #Monolithic #웹개발 #INFCON #인프콘

개발자들이 함께 모여 서로의 경험과 인사이트를 나누는 축제, 인프콘! 8월 15일, 드디어 많은 분들이 기다려 주신 두 번째 인프콘이 개최됩니다. 인프콘을 기다리는 인프러너 여러분들을 위해 인프런이 준비한 <Tech Series>! 인프콘에서 만날 수 있는 여러 기술에 대해 미리 알아볼 수 있도록 소개해 드릴게요.

<INFCON Tech Series> 마지막 이야기는 아키텍처(Architecture)에 대해 다룹니다. 소프트웨어 개발에서 아키텍처는 서비스의 구성과 동작에 대한 대응 방식을 구조적으로 표현하고 결정한 것을 뜻하는데요. 전통적인 모놀리식 아키텍처에 비해 2010년대 들어서 본격적으로 주목받기 시작한 마이크로서비스 아키텍처가 어떻게 다른지 알기 쉽게 비교해보았습니다.

단순하고 간결하게, 하나의 앱으로 
모놀리식 아키텍처

_{맥가이버 칼이 여러 공구를 몸통 하나에 갖춘 것처럼, 모놀리식 아키텍처 역시 단일 서비스에 여러 기능이 들어가 있어요. 단, 어느 한 부분에 문제가 생기면 전체 서비스에 악영향을 미칠 수 있죠.}

모놀리식 아키텍처(Monolithic Architecture, MA)는 하나의 통합된 코드 베이스로 여러 비즈니스 기능을 수행하는 전통적인 소프트웨어 개발 모델입니다. 단일 애플리케이션 내에 서비스의 모든 로직이 통으로 들어가 있는 구조죠. 

이렇게 서비스를 애플리케이션 하나로만 처리할 때의 가장 큰 장점은 뭐니뭐니해도 간결하다는 점입니다. 중앙 집중된 구조이기 때문에 분산된 애플리케이션에 비해 엔드 투 엔드 테스트(End-to-End, E2E: 사용자 관점에서 애플리케이션의 흐름을 처음부터 끝까지 테스트하는 것)를 더 빠르게 수행할 수 있어요. 단일 애플리케이션에 비즈니스 로직부터 UI, 콘텐츠 등 모든 구성 요소를 이루는 코드가 들어있기 때문에 디버깅하기도 간편합니다. 소규모 애플리케이션이라면 단순하면서도 견고한 구조를 만들기 좋아요.

하지만 서비스 규모가 커짐에 따라 모놀리식 아키텍처의 단점도 제기되기 시작했습니다. 단일 애플리케이션이 커지면 자연히 구동부터 빌드, 배포에 드는 시간이 오래 걸리죠. 더욱이 하나로 된 거대한 시스템 구조를 제대로 파악하지 않으면 특정 컴포넌트나 모듈에서 발생하는 성능 문제나 장애가 다른 영역에까지 영향을 주게 됩니다. 아무리 작은 부분만 수정하더라도 전체 애플리케이션을 통째로 컴파일해서 배포해야 하는 만큼 배포가 잦은 환경에서는 번거롭죠. 기능별로 알맞은 기술이나 언어, 프레임워크를 따로 선택하기도 까다롭고요.

한눈에 보는 모놀리식 아키텍처의 특징

쪼갤수록 더 명확해져요 
마이크로서비스 아키텍처

_{넷플릭스(Netflix)의 아키텍처를 도식화한 그림. MSA는 『리팩터링』으로 잘 알려진 마틴 파울러(Martin Fowler) 등 유명 개발자들의 지지와 넷플릭스, 우버, 아마존 같은 성공 사례로 점점 더 주목받고 있어요.}

IT 기술은 나날이 고도화되어가고 있습니다. 개발자 수십, 수백 명이 투입되는 대규모의 복잡한 서비스도 폭발적으로 늘고 있죠. 상황이 이렇다보니 기존 모놀리식 서비스가 비대해지며 생긴 불편함을 개선할 필요성이 부쩍 늘었습니다. 2000년대 후반 이후 클라우드 컴퓨팅 및 가상화 기술이 발전하며 대규모 분산 시스템을 구축하기도 쉬워졌고요.

그렇게 등장한 마이크로서비스 아키텍처(MicroService Architecture, MSA)는 단일 애플리케이션으로 이루어진 모놀리식 아키텍처와 달리 서비스를 아주 작은 서비스(Microservice) 단위로 나눠 각 서비스에서 독립적으로 서비스를 구성하는 모델입니다. 중앙 집중적인 관리 체계 대신 경량화된 API나 메시지로 직접 통신하며 접근하는 방식을 취하고 있어요.

MSA의 장점은 서비스를 잘게 쪼개면서 개발 구조가 민첩하고 유연해졌다는 점입니다. 각 서비스를 독립적으로 개발하고 배포할 수 있어서 작업 시간이 단축되고 확장성도 높죠. 배포가 빠르고 잦은 만큼 애자일 작업 방식을 취하기도 편리하고요. 더욱이 일부분에 문제가 생기면 시스템 전체가 다운될 수 있는 모놀리식 아키텍처와 달리, 한 서비스가 다운되더라도 다른 서비스는 문제없이 작동할 수 있습니다. 서비스에 적합한 언어나 프레임워크 등 기술을 독립적으로 선택할 수 있고, 자체 DB를 서비스마다 가지고 있어서 데이터 무결성을 유지하는 데도 도움이 되죠.

물론 단점도 있습니다. 분산된 서비스가 서로 API를 호출하는 과정에서 통신 비용과 지연 시간이 들고, 큰 인프라 비용이 발생할 수 있죠. 장애 추적이나 디버깅, E2E 테스트 역시 쉽지 않죠. DB가 분리되면서 데이터를 조회하기 어렵고 DB간 데이터 중복이 발생할 수도 있고요. 무엇보다 서비스가 커지는 만큼 복잡해지기 때문에 적절하게 관리하지 않으면 오히려 개발 속도나 운영 성능이 나빠질 수 있어요. 모놀리식 아키텍처에서 마이크로서비스로 전환하는 서비스가 늘어나고 있지만, 반대로 되돌아갔다는 소식 역시 종종 들려오는 이유죠.

한눈에 보는 마이크로서비스 아키텍처의 특징

비즈니스, 팀 그리고 기술에 대한 고민 
인프콘 2023에서 만나보세요!

마이크로서비스 아키텍처와 모놀리식 아키텍처는 서로 다른 특성과 장점을 가지고 있어요. 때문에 아키텍처를 선택할 때는 프로젝트의 규모나 팀의 여건, 비즈니스 요구사항 등 여러 요인을 고려해야 해요. 우리 비즈니스에 가장 적절한 아키텍처가 무엇인지 판단하고 적용하는 게 가장 중요하다고 할 수 있겠죠.

비즈니스에 적합한 아키텍처를 선택하고 이를 구축하는 과정은 어떻게 이루어질까요? 그 과정에선 어떤 고민을 하고, 또 어떤 어려움이 있었을까요? 다가올 인프콘 2023에서 기존 모놀리식 아키텍처를 MSA로 전환하게 된 이유와 생생한 경험담을 소개해드립니다.

절반의 성공, 마이크로 서비스 아키텍처 도입과 조직 구조

서주은 | 버즈빌

서비스와 조직이 성장하면 그에 맞춰 아키텍처도 변화해야 합니다. 버즈빌도 지난 5년간 MSA를 도입하며 변화를 시도했습니다. 지금 와서 보니 분명 잘 한 점도 있지만 그만큼 아쉬운 점도 있었습니다. 버즈빌에서의 경험을 바탕으로 MSA를 도입한 과정에서 기술과 조직 측면에서 배운 점 10가지를 소개합니다.

세션 소개 바로가기 >>

패션 이커머스 서비스의 아키텍처 성장 기록

이희창 | 29CM

MA 기반 레거시 시스템을 마이크로서비스로 전환하는 실제 사례가 궁금하신가요? 2020년 이후 29CM 아키텍처를 MSA로 전환하기로 결정한 이유와 그 과정에서 세운 원칙을 소개합니다. 팀과 서비스의 규모가 점차 커져가며 겪게 된 다양한 이슈 상황과 해결 과정, 그리고 앞으로의 로드맵까지 함께 공유합니다.

세션 소개 바로가기 >>

인프런 아키텍처 2023 ~ 2024

이동욱 (향로) | 인프랩

지난 인프콘 2022 발표 “인프런 아키텍처의 과거와 현재, 그리고 미래”에 이어 이후 1년간 인프런 아키텍처가 어떻게 개선되었는지 소개합니다. 거대한 단일 레거시 시스템을 점진적으로 개선해나가는 과정과 조직이 프로젝트의 퀄리티를 최소한으로 보장하기 위해 마련한 시스템과 프로세스에 대해 이야기합니다.

세션 소개 바로가기 >>

소프트웨어 아키텍처를 좀 더 알고 싶다면?