본문 바로가기

블로그

LG CNS 기술블로그 DX Lounge에서 최신 IT 소식을 만나보세요!

CNS Tech

실패하지 않는 MSA 전환, 두 가지만 기억하세요! 1편

2022.10.17

최근 기업의 인프라 영역에서 가장 주목받는 기술은 단연 마이크로서비스 아키텍처(MicroService Architecture, MSA)입니다. 컨설팅 기업 딜로이트는 기업의 91%가 신규 시스템 도입 시 MSA를 검토하고 있으며, 2023년에는 MSA가 기본 아키텍처가 될 것으로 예측했습니다. 가트너의 기술 동향 보고서도 마찬가지입니다. 가트너 하이프 사이클은 MSA 기술이 거품기, 침체기를 거쳐 성장기에 접어들었고, 2~5년 내 시장 확장 가능성이 높은 것으로 전망했습니다.

MSA를 도입하는 해외 기업 사례를 보면 산업군을 가리지 않습니다. 국내에서는 B2C 접점에 있는 쇼핑몰 등 유통 업종을 중심으로 MSA를 활발하게 구축하고 있는데요. 최근 금융, 공공, 통신 업종에서도 MSA에 대한 관심이 높아지고 있습니다. 특히 은행, 보험 등은 비금융 채널을 중심으로 스몰 애자일 기반의 MSA 적용에 집중하고 있죠. 영업, 물류 등은 백엔드 코어 영역으로 MSA를 확장하고 있습니다. 통신 업종도 전 시스템 영역으로 MSA를 확대하는 경향이 뚜렷하게 나타나고 있습니다.

유명 미디어 기업인 오라일리 등의 설문조사 결과를 보면, MSA를 도입한 기업 중 상당수가 그 결과에 만족한다고 답했습니다. 단, MSA 기술 특성상 편차가 큰데요. 기업마다 직면한 비즈니스 조건과 IT 환경이 다르고 MSA를 적용하고자 하는 목적, 지향점에 따라 구축하는 MSA의 수준과 범위가 천차만별입니다.

예를 들어 경쟁사가 MSA를 도입하니 기술적으로 뒤처지지 않기 위해 급하게 MSA를 도입하면, 조직 구성원이 그 목적과 방향성을 이해하지 못하고 공감대를 만들지 못해 실행 단계에서 많은 혼란을 겪을 수 있습니다. 프로세스, 정책, 조직에 대한 변경 없이 MSA를 기술로만 생각해 도입하는 경우에도 투자 대비 만족할 만한 효과를 기대하기 어렵습니다.

성공적인 MSA 구축을 위한 전략과 전술

그렇다면 MSA 전환을 어떻게 준비해야 할까요? 일단 MSA 성공을 위한 거시적인 전략과 세부적인 전술로 고민을 나눌 필요가 있습니다. 먼저 거시적인 관점에서는 빅뱅(Big Bang) 방식을 택할지, 스트랭글러(Strangler) 방식으로 추진할지 정해야 합니다.

전자는 기존 대규모 모놀리틱 시스템을 MSA로 전환하는 것으로, 프로젝트 규모에 따라 1~2년이 소요됩니다. 이 기간에 요구사항이 추가, 변경되면 처음 계획보다 시간이 더 걸릴 수도 있죠. 하지만 전체 업무 영역을 MSA로 구축하고 아키텍처 플랫폼을 한 번에 변경하기 때문에 IT 인프라 전체를 단번에 혁신할 수 있는 장점이 있습니다. 반면 경험과 준비 없이 진행하면 오히려 혼란만 가중될 수 있습니다.

후자는 레거시 시스템을 조금씩 떼어내 점진적으로 MSA로 이행하는 방식입니다. 하나의 큰 애플리케이션을 작은 서비스로 쪼개는 방법으로, 시간이 지나면서 서서히 모놀리틱 시스템이 사라지게 됩니다. 더디게 진행되는 것 같지만 프로세스, 조직, 교육, 아키텍처 등을 내재화하면서 도입할 수 있고, 기업이 생각하는 우선순위에 따라 시급한 서비스를 먼저 MSA로 전환할 수 있어 효율적입니다.

빅뱅과 스트랭글러 두 방식은 각각 장단점이 있기에 업무 특성과 시스템 목적 등을 종합적으로 고려해 결정해야 합니다. 하지만 최근에는 대부분 기업이 스트랭글러 방식으로 MSA를 도입합니다.

빅뱅 혹은 스트랭글러에 대한 판단을 마쳤다면 이제 더 구체적으로 어떻게 MSA를 구현할 것인지 세부적인 전술을 고민해야 합니다. 성공적인 MSA 기반 시스템을 구현할 때 핵심은 결국 2가지 물음으로 압축됩니다. 하나는 ‘서비스를 어떤 기준과 절차에 따라 쪼개고 검증할 것인가’이고, 다른 하나는 ‘쪼갠 서비스를 구현할 때 어떤 기술과 아키텍처를 적용할 것인가’하는 질문이죠. 하나씩 살펴보겠습니다.

MSA 성공의 핵심 요소 1. 서비스 쪼개기

서비스 쪼개기 즉, 마이크로서비스를 정의하는 것은 MSA 성공에 있어 핵심적인 작업으로, 기업이 만들고자 하는 시스템 목표에 부합하기 위해 서비스의 크기를 결정하고 검증하는 과정입니다. 목표 설정 → 서비스 분리 → 평가 검증 → 서비스 설계의 4단계로 구성되는데요. 각 단계를 거치면서 마이크로서비스로 구체화됩니다.

먼저 ‘목표 설정’ 단계에서는 MSA 도입이 비즈니스의 빠른 변화에 대응하기 위한 것인지, 서비스 독립성 우선 확보를 위한 것인지 고민합니다. 의사결정권자는 물론 담당 실무자의 적극적인 참여가 중요하죠. 이어 서비스를 분리하고 검증해야 합니다. 이는 실제 업무를 어떤 기준, 어떤 수준으로 쪼갤지 논의하고 평가하는 단계인데요. 서비스 분리를 위해서는 이벤트 스토밍, 후보 서비스 식별, 서비스 관계 정의 등의 작업을 거쳐야 합니다.

이벤트 스토밍은 주로 워크숍 형태로 업무 이벤트를 도출하고 이벤트 흐름에 따라 스토리텔링을 진행합니다. 가장 큰 특징은 현업 IT 담당자, 즉 제3자가 아닌 시스템 오너가 스스로 토론하고 개선 방향을 만들어 가면서 적합한 크기로 서비스를 추출한다는 점입니다. 워크숍을 통해 상호 합의점을 만들어갈 수 있어 합리적입니다.

이벤트를 도출한 후에는 스토리텔링으로 그룹핑하며 후보 서비스를 골라냅니다. 신규로 추가되거나 변경이 잦은 업무를 별도 서비스로 분리하고, 부하, 장애 등의 이유로 최우선으로 독립성을 확보해야 하는 서비스를 식별합니다. 인프라 전반에 적용된 기술이 아니라 특정 서비스에 적합한 다른 기술을 적용하기 위해 서비스를 분리하는 경우도 있습니다. 후보 서비스를 추출했다면 이제 서비스 관계를 도식화합니다. 이 과정에서 서비스 간 통합, 분리를 재정의하거나 특정 서비스를 중심으로 API, Pub/Sub 등의 통신 방식을 적용할 수 있습니다.

서비스 쪼개기 과정에서는 서비스 디자인 툴의 역할이 중요합니다. 이벤트 스토밍을 프로세스화하고 서비스 워크숍 보드와 MSA 특성을 반영해 협업이 가능하도록 서비스를 설계할 수 있다면 이상적입니다. 이런 툴은 현장에서 발생하는 다양한 문제점을 해결하고 개발 효율성을 높이는 데도 큰 도움이 됩니다.

기존의 다양한 기업 사례를 분석해 보면 마이크로서비스 정의 단계에서 내실 있는 결과를 내기 위한 조건을 몇 가지로 정리할 수 있습니다. 무엇보다 현업 주요 직원의 적극적인 참여와 경험이 풍부한 MSA 전문가의 리더십이 중요합니다. 워크숍을 통해 MSA의 목표와 수준에 대한 합의점을 찾는 것이 좋은데요. 마이크로서비스를 이벤트 중심으로 정의하되, 성공 사례를 활용해 스토리텔링하는 것을 추천합니다.

이해관계자 간의 상호 검증을 통해 서비스 분리, 통합 방안을 다시 확인하는 것도 중요합니다. 프로젝트 참여자 전체가 MSA 기술에 대한 이해 수준을 높이기 위해 노력하는 태도를 가질 필요가 있습니다.

MSA 성공의 핵심 요소 2. 서비스 아키텍처 설계

서비스 쪼개기에 이어 성공적인 MSA 기반 시스템을 구현하기 위해 고민해야 할 두 번째 전술적 요소는 바로 아키텍처 설계입니다. 마이크로서비스가 독립성을 가질 수 있도록 아키텍처를 정의하고 구상하는 작업입니다.

아래 그림을 보면, 왼쪽은 모놀리틱 방식으로 구성된 시스템입니다. 서비스가 복잡하게 호출되고 하나의 데이터베이스를 사용하죠. 반면 오른쪽에 있는 MSA는 서비스 단위로 패키징되고 독립된 저장소를 가집니다. 개별 마이크로서비스가 프로세스와 데이터 측면에서 독립성을 확보하기 위해 별도의 저장소를 갖고, 각 서비스는 API를 통해 상호작용합니다.

[그림 1] 모놀리틱 시스템(왼쪽)과 마이크로서비스 아키텍처(오른쪽)

여기서 등장하는 매우 중요한 개념이 바로 ‘API 우선 설계(API First Design)’입니다. 문자 그대로 모든 개발 프로세스에서 API를 첫 번째 우선순위로 두는 것을 의미하는데요. 즉, 개별 서비스의 내부를 설계하기 전에 API를 우선 정의해 마이크로서비스 간의 원활한 호출과 독립적인 작동을 보장하는 것입니다.

그런데 실제 현장에서 MSA에 API 우선 설계를 적용하려면 몇 가지 문제에 부딪히게 됩니다. 대표적인 것이 여러 서비스를 포괄하는 조회성 업무입니다. 다양한 서비스에 걸친 데이터를 보여주는 화면을 만들면, 클라이언트의 빈번한 호출과 데이터 조합 작업으로 성능 이슈가 발생할 수 있기 때문입니다.

이때는 API 컴포지션(API Composition), CQRS(Command and Query Responsibility Segregation) 패턴을 활용하는 것이 효과적입니다. 서버 사이드에서 API 컴포지션으로 다수의 마이크로서비스를 호출하고, 이 데이터를 클라이언트에 돌려주는 방식으로 처리 시간을 단축하고 성능을 개선할 수 있습니다. ‘저장’이라는 커맨드와 ‘조회’라는 쿼리에서 책임을 분리하고 Pub/Sub을 통해 데이터를 전달하게 되는데요. 단, 개별 기업의 환경과 특성을 고려해 API 컴포지션과 CQRS를 적용하는 노하우가 필요합니다.

이제 기업이 MSA 성공을 위해 아키텍처 설계 측면에서 중요하게 고려해야 할 요소를 정리해 보겠습니다. 무엇보다 API 우선 설계를 원칙으로 서비스 간 API, Pub/Sub, 데이터 인터페이스를 먼저 정의해야 합니다. 비동기 이벤트 방식으로 설계해 독립성을 확보하고, 서비스 간 연계를 통한 데이터 조회는 구축하는 시스템의 성능과 특성을 고려해 API 컴포지션, CQRS 등을 활용하면 됩니다.

또한, 서비스는 가능한 한 하나의 마이크로서비스에서 완결성 있게 트랜잭션을 처리하도록 하는 것이 좋습니다. 최종 사용자 입장에서 데이터 복제는 허용하되 정합성 원칙에 따라 데이터 무결성을 보장할 수 있도록 설계해야 합니다.

지금까지 성공적인 MSA 전환을 위한 전략과 MSA 성공의 핵심 요소를 살펴봤습니다. 다음 글에서는 MSA 전환의 모든 단계를 지원하는 LG CNS ‘데브온 MSA 스위트’에 관해 알아보겠습니다.

글 ㅣ LG CNS DevOn MSA팀 안정수 책임

챗봇과 대화를 할 수 있어요