서비스 입도 설계 — Gartner 네 단계로 MSA 비용 따져보기

TL;DR — MSA 비용은 데이터·통신·배포·운영·조직의 다섯 축에서 동시에 청구되고, 그중 가장 무거운 것은 서비스마다 데이터베이스를 나누는 일입니다. Gartner의 네 단계 입도에서 기본값은 굵은 쪽이므로, 저장소를 서비스별로 나눌 준비가 되었는지가 출발 단계를 정합니다.

2026년 프로덕션 운영 환경에서 마이크로서비스 도입을 앞두고 서비스를 더 잘게 쪼갤지 고민하는 의사결정자와 담당 아키텍트라면, 왜 MSA 비용을 먼저 확인해야 하고 어떤 방식으로 도입 단계를 고를지를 정리해 두는 편이 안전합니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘마이크로서비스, 정말 지금 필요할까 (1부) 비용과 전환 단계'(약 17분)를 캡처 8장과 함께 주장 단위로 풀어, 영상을 보지 않은 독자도 판단 근거를 얻어 가도록 정리했습니다. 영상은 두 편으로 나뉘며, 1부는 마이크로서비스가 요구하는 비용과 Gartner의 네 단계 입도 분류까지를 다룹니다. 담당자가 먼저 점검해야 할 질문도 함께 짚습니다.

영상은 서비스를 얼마나 잘게 쪼갤 수 있는가가 기술 문제가 아니라 조직 문제라는 결론으로 시작합니다. 이어서 마이크로서비스가 실제로 요구하는 비용 다섯 축, 서비스 입도 네 단계, 그 단계를 가르는 일곱 축, 미니서비스의 현행 이름을 차례로 보여 줍니다.

영상에서 다루는 순서는 다음과 같습니다.

• 결론과 두 편 구성, 인용 범위 안내 (0:00)
• 오늘 다루는 네 가지 이야기 (3:45)
• 마이크로서비스가 요구하는 다섯 축의 비용 (4:35)
• 데이터베이스를 기준으로 본 네 단계 (7:30)
• Uber·Netflix·서비스 메시 수치 (8:58)
• 네 단계 입도 분류 (11:13)
• 미니서비스의 다른 이름 (12:52)
• 입도를 가르는 일곱 축과 마이크로서비스의 다섯 조건 (14:26)

영상의 설명을 질문으로 바꾸면 여덟 가지입니다. 아래 여덟 개 절이 이 순서대로 답합니다.

1. 영상은 왜 입도 선택을 기술이 아닌 조직 문제로 보는가?
2. MSA 비용은 어떤 다섯 축에서 청구되는가?
3. 난이도를 가르는 것은 왜 서비스 개수가 아닌 데이터베이스인가?
4. 세 가지 수치는 MSA 비용에 대해 무엇을 말해 주는가?
5. Gartner는 입도를 어떤 네 단계로 나누는가?
6. 미니서비스는 왜 서비스 기반 아키텍처라고도 불리는가?
7. 일곱 개 축 가운데 데이터 저장소가 가장 결정적인 이유는 무엇인가?
8. 마이크로서비스가 되기 위한 다섯 조건에서 미니서비스는 어디에 서는가?

영상의 첫 결론은 단호합니다. 서비스를 얼마나 잘게 쪼갤 수 있는가는 기술 문제가 아니라 조직 성숙도 문제라는 것입니다. 쪼개는 기술은 이미 널리 알려져 있지만, 쪼갠 서비스를 각자 배포하고 밤새 지켜보고 데이터를 맞춰 주는 일은 사람과 조직이 감당해야 하기 때문입니다. 영상은 이 말을 Gartner의 권고와 연결합니다. 기본값은 굵게 가고, 잘게 쪼개는 것은 정말 필요한 곳에만 쓰라는 권고입니다.

▲ 오늘 다루는 네 가지 이야기 (영상 3:45)

캡처는 영상 전체의 목차입니다. 첫째가 마이크로서비스 도입 비용, 둘째가 Gartner 서비스 입도 네 단계, 셋째가 미니서비스의 제약 완화와 위험, 넷째가 도입 판단과 적용 로드맵입니다. 1부는 앞의 두 부분만 다루고, 미니서비스가 무엇을 풀어 주고 무엇을 대가로 치르는지와 전환 경로는 이어지는 영상으로 넘어갑니다. 영상은 이 1부만 보아도 우리 시스템이 어느 단계에서 출발해야 하는지 감을 잡을 수 있게 구성했다고 밝힙니다.

영상은 이 판단을 집 고치는 일에 빗댑니다. 집을 고칠 때 벽을 다 허물지 않고 손볼 곳만 정확히 여는 편이 낫듯, 서비스도 필요한 자리만 잘게 쪼개라는 뜻입니다. 인용 범위에 대한 안내도 빠뜨리지 않습니다. Gartner 연구노트 본문은 유료 구독 자료여서 공개된 요약과 애널리스트 기고문 범위만 다루고, 이 틀이 2017년에서 2019년 사이에 정리된 것이라 최근 자료로도 맞는지 함께 확인하겠다고 말합니다.

따라서 이 절의 결론은 분명합니다. 입도를 고르는 질문은 기술 스택이 아니라 조직의 준비 상태를 먼저 묻는 것이어야 합니다. MSA 비용을 따지는 첫 질문이 이것입니다. 이어지는 절에서 그 준비 상태가 구체적으로 어떤 MSA 비용으로 청구되는지를 살펴봅니다.

영상은 먼저 오해를 막습니다. 마이크로서비스가 나쁘다는 이야기가 아니라, 결제하기 전에 청구서를 먼저 펼쳐 보자는 이야기라는 것입니다. 식당에서도 가격을 보고 주문하는 것이 자연스럽다는 비유가 따라옵니다. 그 청구서에 적힌 마이크로서비스 비용, 곧 MSA 비용이 데이터, 통신, 배포, 운영, 조직의 다섯 축입니다.

▲ 마이크로서비스가 요구하는 다섯 축의 비용 (영상 4:35)

첫째는 데이터입니다. 서비스마다 자기 저장소를 따로 가져야 하고, 그 순간 한 번에 처리하던 거래를 포기해야 합니다. 대신 나중에 맞춰지는 방식, 곧 결과적 일관성을 받아들여야 합니다. 영상은 이것을 다섯 가지 중 가장 무거운 MSA 비용으로 꼽습니다.

둘째는 통신입니다. 진짜로 느슨하게 이으려면 메시지를 주고받는 통로가 필요합니다. 서로를 직접 부르면 결국 서로를 알아야 하기 때문입니다. 셋째와 넷째는 배포와 운영입니다. 서비스마다 배포 통로를 따로 만들어야 하고, 어디에 무엇이 있는지 찾고 추적하는 기반도 갖춰야 합니다.

다섯째는 조직입니다. 영상은 Gartner가 2019년 연구노트에서 이것을 상당한 문화적 파괴라고 표현했다고 전합니다. 백 명이 한 팀이던 곳이 다섯 명씩 스무 팀으로 바뀐다는 뜻이며, 보고 체계도 야간 대기 체계도 전부 다시 짜야 합니다.

이 절에서 가장 중요한 대목은 마지막 경고입니다. 다섯 가지는 골라 담는 항목이 아니라서, 하나라도 준비가 안 되면 나머지 넷에 들인 돈도 회수되지 않습니다. 영상은 바퀴가 세 개만 달린 자동차는 나머지 부품이 아무리 좋아도 굴러가지 않는다고 비유합니다. 그래서 담당자는 도입 전에 다섯 축을 한 번에 점검해야 하고, 한 축이라도 비어 있으면 그 축부터 준비하는 것이 순서입니다. 결국 MSA 비용은 합계가 아니라 동시에 지불해야 하는 묶음입니다. 다섯 축 중 어느 한 곳의 MSA 비용만 줄여서는 전체 MSA 비용이 줄지 않습니다.

영상은 네 단계를 데이터베이스 기준으로 나란히 놓고 봅니다. 그림 보는 법부터 짚습니다. 네모는 배포 단위이고 원통은 데이터 저장소입니다. 이 장에서 세어 볼 것은 네모가 아니라 원통의 개수입니다.

▲ 네 단계를 가르는 것은 데이터베이스 개수 (영상 7:30)

첫 단계인 모놀리스는 애플리케이션 하나에 데이터베이스 하나입니다. 한 줄만 고쳐도 전체를 다시 배포하고, 늘릴 때도 통째로 늘립니다. 두 번째 매크로서비스는 코드를 큰 덩어리로 나누지만, 원통은 여전히 하나입니다. 영상은 코드는 나뉘었는데 데이터베이스에서 다시 붙어 있는 상태라고 설명합니다.

세 번째 미니서비스에서 원통이 처음으로 나뉩니다. 다만 나누는 기준이 서비스가 아니라 도메인입니다. 주문 도메인 안에 주문과 결제가 있고 이 둘이 주문 저장소를 함께 씁니다. 회원 도메인도 회원과 인증이 회원 저장소를 함께 씁니다. 함께 쓰는 것이 허용되는 범위는 어디까지나 도메인 안입니다. 주문 쪽 서비스가 회원 저장소를 직접 읽는 순간 매크로서비스로 되돌아간 것이라고 영상은 못 박습니다. 같은 집 식구끼리 냉장고를 함께 쓰는 것은 자연스럽지만 옆집 냉장고를 열기 시작하면 다른 이야기가 된다는 비유입니다.

마지막 마이크로서비스는 서비스마다 원통을 하나씩 가집니다. 저장소까지 완전히 나뉘고 데이터의 맞춤은 이벤트로 합니다. 정리하면 저장소를 쪼개기 전까지는 결합이 남아 있고, 쪼개는 순간부터 정합성을 맞추는 MSA 비용이 시작됩니다. 그래서 이 전환은 단계를 건너뛰지 않는 것을 전제로 합니다. 서비스 개수를 늘리는 일보다 저장소 경계를 어디에 긋는가가 난이도를 정하는 이유가 여기에 있습니다. 저장소 분리가 MSA 비용의 출발점이라는 말도 같은 뜻입니다.

영상은 비용이 이론이 아니라는 점을 숫자 세 개로 보여 줍니다. 첫째는 Uber입니다. 2020년에 공개한 자료를 보면 서비스가 2,200개였습니다. 눈여겨볼 점은 Uber가 이 숫자를 줄이지 않았다는 것입니다. 2,200개를 그대로 둔 채 일흔 개 도메인으로 묶고, 도메인마다 앞에 관문을 하나씩 세웠습니다. 그 결과 새로 온 개발자가 적응하는 시간이 4분의 1에서 절반까지 줄었다고 합니다. 서랍은 그대로 두고 서랍장에 이름표만 붙인 셈이라는 비유가 이어집니다.

▲ 대규모 운영에서 확인된 세 가지 수치 (영상 8:58)

둘째는 Netflix입니다. 공개 자료가 제각각이라 공식 숫자는 없고 보통 천 개 규모로 본다고 영상은 말합니다. 확장성을 끝까지 증명한 사례이면서, 그것을 감당하려면 무엇이 필요한지도 함께 보여 준 사례라는 평가입니다.

셋째가 영상이 가장 중요하게 꼽는 숫자입니다. CNCF 연례조사에서 서비스 메시를 실제 운영에 쓰는 비율이 2023년 50%에서 2024년 42%로 내려갔습니다. 도입 계획이 없다는 응답은 두 배로 늘었고, 보고서가 밝힌 이유는 복잡함과 비용, 성능입니다. 바깥 기반을 대표하는 도구가 실제로 뒷걸음질하고 있다는 일차 자료입니다.

캡처 아래쪽에는 서비스가 늘 때 같이 쌓이는 두 가지 찌꺼기가 있습니다. 담당자가 떠나 아무도 고치지 못하는 죽은 서비스, 그리고 운영 비용에 비해 너무 잘게 쪼갠 나노서비스입니다. 둘 다 빚으로 남습니다.

영상의 정리는 이렇습니다. Uber는 도메인을 서비스 위의 단위로 올렸고, 업계는 바깥 도구에 대한 투자를 줄이고 있습니다. 두 흐름이 가리키는 자리가 미니서비스의 자리입니다. 다만 Uber의 방식은 서비스마다 전용 저장소를 그대로 두므로 미니서비스와 같은 구조는 아니라고 영상은 선을 긋습니다. 요컨대 MSA 비용은 서비스 수만큼이 아니라 그것을 관리하는 기반과 조직만큼 늘어납니다. 세 수치 모두 MSA 비용이 실재한다는 증거로 읽힙니다.

그러면 중간 지점이 정확히 무엇인지 Gartner의 분류로 확인합니다. 영상에 따르면 Gartner는 2017년 연구노트에서 서비스 입도를 네 단계로 정리했습니다.

▲ 모놀리스에서 마이크로서비스까지 네 단계 (영상 11:13)

매크로서비스는 모놀리스에 가장 가까운 서비스화 단계입니다. 세 번째 미니서비스는 영상이 오늘의 주인공이라고 부르는 단계로, 서비스 도메인 하나가 단위이고 서로 직접 부르는 통신도 허용하며 도메인 안에서는 저장소를 같이 써도 됩니다. 마지막 마이크로서비스는 도메인 안의 기능 하나가 단위이고, 서비스마다 전용 저장소를 반드시 가집니다.

캡처 아래 막대 두 개는 오른쪽으로 갈수록 무엇이 달라지는지 보여 줍니다. 한쪽은 배포와 확장이 빨라지는 이점이고, 다른 쪽은 바깥 기반의 부담과 조직을 다시 짜야 하는 요구입니다. 영상은 저울의 양쪽이 함께 올라가는 셈이라고 말합니다. 그래서 입도 선택의 기준은 분명합니다. 얻는 것보다 치르는 것이 커지는 지점에서 멈추는 것이 입도 선택입니다. 치르는 쪽에 올라가는 것이 바로 MSA 비용입니다.

네 단계를 본 뒤 영상은 한 가지를 솔직하게 짚습니다. 미니서비스라는 말은 2026년 현재 활발히 쓰이는 용어가 아닙니다. Gartner가 2017년에 정의한 뒤로 이어지는 갱신이 거의 없기 때문입니다. 그래서 영상은 같은 자리를 가리키는 이름을 한 표에 모아 보여 줍니다.

▲ 같은 자리를 부르는 세 가지 이름 (영상 12:52)

표의 왼쪽 두 열은 미니서비스와 서비스 기반 아키텍처입니다. 따라 내려가 보면 서비스 범위가 도메인 하나로 같고, 배포 단위가 도메인별로 나뉘는 것도, 데이터를 같이 쓰는 것도 같습니다. 영상의 판단은 사실상 같은 구조이며 차이는 족보뿐이라는 것입니다. 미니서비스는 Gartner 쪽 이름이고, 서비스 기반 아키텍처는 교재에서 온 이름입니다. 그 교재는 2025년에 두 번째 판이 나왔으니, 같은 자리를 가리키는 현행 표준 이름이 따로 있는 셈입니다.

세 번째 열의 모듈러 모놀리스는 사촌쯤 됩니다. 나머지는 모두 비슷한데 배포 단위만 하나로 합쳐 둔 형태이고, 경계를 사람의 규율이 아니라 빌드 도구로 지킨다는 점이 다릅니다. 같은 음식을 지역마다 다른 이름으로 부르는 것과 비슷하다는 비유가 붙습니다.

실무에 주는 안내는 이렇습니다. 영상의 자료는 Gartner 계보를 따라가므로 미니서비스라는 이름을 쓰지만, 나중에 찾아보거나 다른 팀과 이야기할 때는 서비스 기반 아키텍처가 더 잘 통합니다. 두 이름이 같은 것을 가리킨다는 점만 기억하면 됩니다. 이름이 달라도 치르는 MSA 비용의 구조는 같습니다.

영상은 네 단계를 일곱 개 축으로 나란히 놓고 비교하며, 오늘 자료에서 딱 한 장만 가져간다면 이 장이라고 말합니다.

▲ 네 입도를 가르는 일곱 축 비교 (영상 14:26)

노란 테두리로 묶은 두 열, 매크로서비스와 미니서비스가 Gartner가 말한 기본 선택지입니다. 원문의 뜻은 기본은 굵게 두라는 것이고, 오래된 기능은 매크로로 감싸고 자주 바뀌는 기능만 미니로 잘라 내라는 의미라고 영상은 풀이합니다.

위에서부터 보면 서비스 범위가 점점 좁아집니다. 애플리케이션 전체에서 도메인으로, 다시 기능 하나로 좁아집니다. 배포는 전체를 한꺼번에 하던 것에서 완전히 따로 하는 쪽으로 가고, 조직은 큰 팀 하나에서 도메인을 맡은 자율팀으로 바뀝니다. 이 가운데 가장 결정적인 것은 두 번째 축인 데이터 저장소입니다. 나머지 여섯 개는 정도의 문제인데 저장소만은 성격이 다릅니다. 저장소를 나누는 순간 여러 곳에 걸친 거래 문제가 생기고, 데이터를 관리하는 조직의 승인도 받아야 하며, 조직 개편까지 따라오기 때문입니다. 한 집에서 살림을 합쳐 쓰다가 각자 살림을 내는 것과 같다는 비유입니다.

그래서 영상은 실무에서 던질 질문을 하나로 줄여 줍니다. 우리가 지금 저장소를 서비스별로 나눌 준비가 되었는가. 답이 아니오라면 미니서비스 열이 우리 자리입니다. MSA 비용을 감당할 수 있는지는 이 질문의 답에 달려 있습니다. 도입 담당자는 이 질문에 답하기 전에 데이터 관리 조직과 먼저 이야기해야 한다는 점이 이 절의 실무적 결론입니다.

영상의 마지막 대목은 마이크로서비스라고 부르려면 무엇을 갖춰야 하는지 Gartner 용어집의 정의로 확인합니다. 조건은 다섯 개입니다. 좁게 한정된 범위, 강한 캡슐화, 느슨한 결합, 독립 배포, 독립 확장입니다.

▲ Gartner가 정의한 마이크로서비스 다섯 조건 (영상 16:50)

중요한 것은 이것이 골라 담는 목록이 아니라는 점입니다. 다섯 가지를 모두 만족해야 하고, 하나라도 못 지키면 마이크로서비스가 아닙니다. 그런데 현장에서는 API만 붙으면 마이크로서비스라고 부르는 경우가 많다고 영상은 지적합니다.

캡처 아래 띠를 보면 미니서비스가 온전히 지키는 것은 하나뿐입니다. 다섯째, 독립 확장입니다.

다섯 중 넷을 느슨하게 한다는 것은 대가가 그만큼 분명하다는 뜻이고, 그 대가를 어떻게 관리하는지가 2부의 핵심입니다. 영상은 이 지킴과 느슨함의 짝짓기가 발표자가 정리한 해석이며 원문에 이런 형태의 표가 있는 것은 아니라고 밝혀 둡니다. 따라서 이 표는 MSA 비용을 가늠하는 판단의 출발점으로 쓰되 Gartner 원문의 표로 인용하지 않아야 한다는 점을 함께 기억하면 됩니다.

MSA 비용은 다섯 축에서 동시에 청구되는 묶음이고, MSA 비용의 핵심은 저장소 분리이며, 입도 선택은 얻는 것보다 치르는 것이 커지는 지점에서 멈추는 일입니다.

MSA 비용은 어떤 항목으로 구성되나요?

데이터, 통신, 배포, 운영, 조직의 다섯 축에서 동시에 청구되며 하나라도 빠지면 나머지 투자도 회수되지 않습니다. 영상은 서비스별 저장소와 결과적 일관성을 받아들이는 데이터 비용을 가장 무거운 것으로 꼽고, 조직 비용은 백 명 한 팀이 다섯 명씩 스무 팀으로 바뀌는 문화적 파괴에 빗댑니다.

서비스 입도의 네 단계는 무엇인가요?

모놀리스, 매크로서비스, 미니서비스, 마이크로서비스의 네 단계입니다. Gartner가 2017년 연구노트에서 정리한 분류로, 오른쪽으로 갈수록 배포와 확장은 빨라지지만 바깥 기반의 부담과 조직을 다시 짜야 하는 요구도 함께 오릅니다.

서비스 개수보다 데이터베이스가 중요한 이유는 무엇인가요?

저장소를 쪼개기 전까지는 결합이 남고, 쪼개는 순간부터 정합성을 맞추는 비용이 시작되기 때문입니다. 영상은 매크로서비스가 코드는 나눴어도 데이터베이스에서 다시 붙어 있는 상태라고 설명하며, 그래서 이 전환은 단계를 건너뛰지 않는 것을 전제로 합니다.

미니서비스는 지금도 쓰는 용어인가요?

요즘은 활발히 쓰이지 않으며, 현행 표준 이름은 서비스 기반 아키텍처입니다. 영상은 미니서비스가 Gartner 쪽 이름이고 서비스 기반 아키텍처는 교재에서 온 이름이라 구조는 사실상 같다고 설명하며, 다른 팀과 이야기할 때는 후자가 더 잘 통한다고 안내합니다.

어느 입도 단계에서 출발해야 하나요?

저장소를 서비스별로 나눌 준비가 되었는지가 기준이며, 아니라면 미니서비스 열이 출발점입니다. 영상은 Gartner가 기본 선택지로 둔 매크로서비스와 미니서비스 두 열을 강조하고, 오래된 기능은 매크로로 감싸고 자주 바뀌는 기능만 미니로 잘라 내라는 뜻이라고 풀이합니다.

미니서비스를 마이크로서비스라고 불러도 되나요?

아닙니다. Gartner의 다섯 조건 중 미니서비스가 온전히 지키는 것은 독립 확장 하나뿐입니다. 범위, 캡슐화, 결합, 배포는 느슨해집니다. 다만 이 짝짓기는 영상 발표자가 정리한 해석이며 Gartner 원문에 같은 표가 있는 것은 아닙니다.

MSA 비용과 서비스 입도를 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 개념 문서를 모았습니다.

• MSA란 무엇인가 — 마이크로서비스 아키텍처 완벽 가이드 — MSA 개념을 처음부터 정리한 가이드
• 마이크로서비스, 정말 지금 필요할까 (1부) 비용과 전환 단계 — 클라우드네이티브TV, 이 글이 정리한 원 영상
• 클라우드 네이티브 전환 사전 진단 컨설팅 백서 — 전환 전 진단 기준
• AI와 MSA 시너지 — 인프라를 넘어 지능형 애플리케이션으로 — MSA와 인프라의 관계
• 클라우드 네이티브 도입 효과와 공공·AI 인프라 사례 — 도입 사례
• MSAP COP 클라우드 네이티브 가이드 — 플랫폼 안내서
• 프라이빗 PaaS로 실현하는 클라우드 네이티브 — 기반 전략
• MSAP.ai 솔루션 문의 — 도입 검토 상담
• Microservices — Martin Fowler — 마이크로서비스 정의의 고전
• Microservices — Wikipedia — 일반 개념
• Eventual consistency — Wikipedia — 결과적 일관성
• CNCF Annual Survey — 서비스 메시 사용률 조사 보고서 모음