미니서비스 설계 — 도메인 기준으로 MSA 전환 판단하기

TL;DR — 대부분의 조직에는 마이크로서비스보다 미니서비스가 먼저 맞습니다. 미니서비스는 도메인 단위로 서비스를 자르고 도메인 안의 저장소 공유를 허용해 비용을 낮추는 단계이며, 성숙도 네 문항에서 하나라도 아니오가 나오면 여기서 시작하고 신호 네 가지를 채운 도메인만 다음 단계로 올립니다.

2026년 프로덕션 운영 환경에서 MSA 전환을 맡은 아키텍트와 IT 담당자가 마이크로서비스로 바로 갈지, 미니서비스에서 시작할지를 왜 그리고 어떻게 정해야 하는지 막막하다면 이 글이 판단의 순서를 잡아 줍니다. 이 글은 클라우드네이티브TV가 공개한 영상 ‘MSA 전환, 다 쪼개야 할까 — 미니서비스부터 시작하는 이유 (2부)’를 정리한 것으로, 미니서비스가 무엇을 풀어 주고 무엇을 대가로 치르는지, 어디서 출발하고 언제 다음 단계로 올라서는지를 장면별로 풀었습니다. 영상이 근거로 삼은 가트너 연구는 2017년에서 2019년 기준이라는 점을 먼저 밝혀 둡니다.

영상은 지난 편에서 본 마이크로서비스의 비용과 가트너의 네 단계 입도를 이어받아, 이번 편에서 미니서비스의 완화와 대가, 출발 단계의 판단 기준, 다음 단계로 넘어가는 신호를 차례로 다룹니다. 지난 편을 보지 않아도 따라갈 수 있도록 필요한 배경을 중간중간 짚어 줍니다.

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

• 미니서비스가 느슨하게 풀어 주는 네 가지 제약 (2:21)
• 확산 위험과 네 가지 방어 규율 (4:26)
• 도입 전에 확인하는 성숙도 네 문항 (7:00)
• 이너 아키텍처와 아우터 아키텍처 (8:29)
• 2026년 아우터 아키텍처의 비용 변화 (10:22)
• 도메인 정의부터 선택적 마이크로서비스까지 네 단계 (12:32)
• 다음 단계로 올라서는 네 가지 신호 (14:57)
• 도입 검토 전에 먼저 정할 세 가지 (17:20)

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

1. 미니서비스는 마이크로서비스의 어떤 부담을 덜어 주는가?
2. 미니서비스가 다시 모놀리스로 돌아가는 길은 어떻게 막는가?
3. 어떤 조직이 미니서비스에서 시작해야 하는가?
4. 안쪽 구조와 바깥 구조 가운데 무엇을 먼저 갖춰야 하는가?
5. 2026년에도 바깥 기반은 여전히 비싼가?
6. 전환 경로는 몇 단계이고 왜 건너뛰면 안 되는가?
7. 미니서비스는 언제 다음 단계로 올라서는가?
8. 도입을 검토하기 전에 먼저 답할 것은 무엇인가?

영상은 시작하자마자 결론을 말합니다. 이 단계가 느슨하게 풀어 주는 것은 네 가지이고, 데이터, 통신 방식, 입도, 조직입니다. 마이크로서비스가 요구하는 엄격한 원칙을 한꺼번에 지키지 않아도 되도록 문턱을 낮춘 단계라고 보면 됩니다.

첫째는 데이터의 독립입니다. 도메인 경계 안에서는 저장소를 같이 써도 됩니다. 경계를 넘어서까지 같이 쓰는 것이 아니라는 점이 중요합니다. 이것 하나로 여러 곳에 걸친 거래 문제, 이른바 분산 트랜잭션과 사가 패턴의 부담을 대부분 피하고, 중복된 데이터를 서로 맞추는 일도 줄어듭니다. 둘째는 통신 방식입니다. 메시지를 던져 두는 방식을 강요하지 않고, 서로 직접 부르는 방식도 그대로 허용합니다. 팀이 이미 쓰던 방식이라 새로 배울 것이 없다는 점이 장점입니다.

셋째는 입도입니다. 기능이 아니라 도메인 단위로 자르기 때문에 서비스가 수백 개가 아니라 수십 개가 됩니다. 서로 부르는 사슬이 짧아지니 쌓이는 지연도 크게 줄어듭니다. 넷째는 조직입니다. 전면 개편 없이 시작할 수 있고, 가트너가 가장 큰 실패 원인으로 꼽은 문화적 파괴를 피해 갑니다.

▲ 미니서비스가 느슨하게 풀어 주는 네 가지 제약 (영상 3:15)

캡처의 네 칸은 데이터 독립성, 통신 방식, 서비스 입도, 조직 재편으로 나뉘고, 칸마다 효과가 한 줄씩 붙어 있습니다. 데이터 칸의 효과는 분산 트랜잭션과 중복 동기화 문제를 대부분 피하는 것, 입도 칸의 효과는 서비스 수가 수백 개가 아니라 수십 개로 줄고 호출 그래프와 지연의 누적이 작아지는 것입니다. 아래 인용 두 개는 이 장의 요약입니다. 마이크로서비스는 각자 데이터를 가져야 하지만 미니서비스는 공유해도 된다는 지적, 그리고 서비스끼리 아직 직접 부르는 방식을 벗어나지 못했다면 이미 미니서비스라는 지적입니다.

영상은 두 번째 인용에 단서를 답니다. 이 말은 2018년의 특정한 맥락에서 나온 발언이고, 요즘은 직접 부르는 방식을 쓰는 정통 마이크로서비스도 흔합니다. 그래서 엄밀한 판별 기준이 아니라 자가 진단용으로만 쓰라고 권합니다. 이 단계의 장점을 한 문장으로 줄이면 구조의 순수함을 내주고 도입 속도를 받는 맞바꾸기입니다. 영상은 이사할 때 짐을 완벽하게 정리하기보다 일단 옮기고 차차 정리하는 것에 빗댑니다. 이 단계를 고르는 일은 원칙을 포기하는 것이 아니라 어디까지 원칙을 지킬지 단계적으로 정하는 일입니다.

그런데 이 단계에는 뻔히 예상되는 실패 경로가 하나 있다고 영상은 경고합니다. 모르고 시작하면 반드시 밟게 되는 길입니다. 시작은 저장소를 같이 쓰는 것을 한 번 허용하는 것입니다. 그러면 다음 서비스도 같은 이유를 대며 붙고, 예외가 규칙이 됩니다. 둘째로 기존 서비스에 기능을 계속 덧붙이게 됩니다. 새로 만드는 것보다 붙이는 편이 언제나 빠르기 때문입니다. 그 결과 서비스가 비대해지고 매크로서비스와 구분이 사라져, 결국 사실상 모놀리스로 되돌아갑니다. 영상은 방 하나만 창고로 쓰자고 했다가 온 집이 창고가 되는 것에 빗댑니다.

▲ 확산 위험과 네 가지 방어 규율 (영상 5:49)

캡처 왼쪽은 확산 위험 세 단계이고 맨 아래 결과 칸은 미니서비스에서 매크로서비스를 거쳐 사실상 모놀리스로 회귀한다고 적습니다. 오른쪽은 방어 네 가지입니다. 저장소 공유는 도메인 경계 안에서만 허용하고, 서비스 하나가 맡는 도메인을 하나로 제한하고, 표마다 쓰기 주인을 하나로 정하고, 서비스 크기와 기능 개수와 같이 쓰는 표의 수를 주기적으로 세는 것입니다. 영상은 네 가지 모두 도구가 아니라 규율이라고 강조합니다.

이 가운데 셋째 규율이 가장 중요하다고 영상은 말합니다. 저장소를 같이 쓰더라도 표마다 쓰기 주인을 딱 하나로 정하는 것입니다. 읽기는 같이 하더라도 쓰기 주인이 하나로 유지되면 나중에 정확히 그 선을 따라 저장소를 자를 수 있기 때문입니다. 마이크로서비스로 넘어갈 때 새로 만드는 일이 아니라 선을 따라 자르는 일이 됩니다. 이 구조가 앞 단계로 성립하는 기술적 이유가 바로 이것이고, 이 규율을 놓친 조직에는 앞으로 가는 길 자체가 없다고 영상은 못 박습니다. 넷째 규율에서는 숫자 자체보다 늘어나는 흐름이 경보라고 덧붙입니다.

이제 마지막 이야기, 곧 우리가 어디서 출발해야 하는지입니다. 영상은 여행으로 치면 출발지와 경로, 그리고 갈아탈 시점을 정하는 순서라고 소개합니다. 출발지를 정하는 도구가 가트너의 게리 올리프 연구 부사장이 제시한 네 개의 질문이고, 영상은 이 네 문항을 오늘 자료에서 가장 실용적인 부분이라고 부릅니다.

▲ 도입 전에 확인하는 성숙도 네 문항 (영상 7:35)

네 문항은 다음과 같습니다. 첫째, 아키텍처를 제대로 실천하는 조직이 있는가. 서비스 경계를 긋고 지켜 낼 사람이 없으면 나누는 일은 곧 혼선이 됩니다. 둘째, 애자일과 데브옵스, CI/CD 관행이 성숙한가. 서비스마다 배포 통로를 따로 돌릴 수 있어야 독립 배포라는 말이 성립합니다. 셋째, 데이터를 관리하는 조직이 서비스별 데이터 분리를 지원하는가. 이 항목이 자주 빠지는데, 전용 저장소 분리는 그 승인 없이 한 발도 못 나갑니다. 넷째, 이 시스템에 정말로 그만한 민첩성과 확장 요구가 있는가. 요구가 없으면 들인 비용을 회수할 근거도 없습니다.

캡처 아래의 판단 규칙은 세 줄입니다. 기본값은 미니서비스와 매크로서비스이고, 마이크로서비스는 요구가 실제로 증명된 영역에만 골라서 쓰며, 네 문항 중 하나라도 아니오가 나오면 미니서비스에서 시작합니다. 영상이 옮긴 올리프의 말은 대부분의 조직이 마이크로서비스가 너무 복잡하고 비싸서 투자 회수가 되지 않는다는 것을 알게 될 것이라는 내용입니다. 이 문항은 회사 전체가 아니라 시스템과 도메인 단위로 적용할 수 있고, 뒤에서 보듯 같은 문항이 승격 판정에도 다시 쓰입니다. 다만 영상이 거듭 밝히듯 이 근거는 2017년에서 2019년의 연구 기준입니다.

영상은 이 장이 오늘 이야기와 우리 아키텍처 과제를 잇는 지점이라고 말하며, 먼저 용어를 짚습니다. 서비스 바깥의 운영 기반을 가리키는 말이 아우터 아키텍처이고, 이 용어 자체가 가트너 용어입니다. 방금 인용한 올리프가 정의했고 같은 글에서 미니서비스를 권하고 있으니, 두 주제는 원래 한 논의였다는 설명입니다.

▲ 이너 아키텍처와 아우터 아키텍처 (영상 8:31)

캡처 위쪽에는 가트너가 지목한 아우터 구성요소 여섯 개가 있습니다. API 게이트웨이, 서비스 디스커버리, 모니터링과 텔레메트리, 빌드와 테스트 자동화, 메시징, 데이터 영속성입니다. 컨테이너 플랫폼을 중심에 두고 이 여섯 가지를 갖춰야 한다고 가트너는 보았습니다. 여기서 미니서비스의 전략적 의미가 나옵니다. 서비스 수도, 여러 곳에 걸친 거래도, 지켜볼 대상도 줄어드니 바깥에 요구되는 수준 자체가 내려갑니다. 서비스 메시와 분산 추적을 첫날부터 갖추지 않아도 됩니다.

반면 이너 아키텍처, 곧 서비스 안쪽 구조는 입도와 상관이 없습니다. 도메인 모델과 계층을 나누는 규율은 미니서비스에서도 그대로 지킬 수 있고, 지켜야 합니다. 그래서 영상의 권고는 한 줄입니다. 안쪽을 먼저, 바깥을 나중에. 집을 지을 때 골조를 제대로 세워 두면 나중에 방을 나누기 쉬운 것과 같습니다. 이 단계로 출발하되 내부 경계를 엄격히 그어 두면, 나중에 쪼갤 때 새로 만드는 일이 아니라 선을 따라 자르는 일이 됩니다. 방어 규율의 쓰기 주인 한 곳 원칙과 이너 아키텍처의 내부 경계가 같은 목적을 향한다는 점도 눈여겨볼 만합니다.

영상은 듣는 사람이 속으로 던질 질문을 먼저 꺼냅니다. 2017년 이야기 아니냐, 지금도 바깥 기반이 그렇게 비싸냐는 질문입니다. 답은 정직합니다. 절반은 맞습니다.

▲ 2026년 아우터 아키텍처, 내려간 것과 그대로인 것 (영상 11:17)

내려간 것은 관측입니다. 오픈텔레메트리가 올해 5월 CNCF 졸업 등급에 올라 사실상 관측의 표준이 됐고, 예거도 두 번째 판부터 오픈텔레메트리를 기반으로 갈아탔으며, 자바스크립트와 파이썬 쪽 라이브러리는 각각 한 해에 13억 회 넘게 내려받아집니다. 2017년에는 분산 추적을 붙이려면 무엇을 고를지부터 고민해야 했지만 지금은 그 고민 자체가 사라졌습니다. 반대로 서비스 메시는 뒷걸음질하고 있습니다. 실제 운영 사용률이 2023년 50퍼센트에서 2024년 42퍼센트로 내려갔고, 도입 계획이 없다는 응답은 두 배로 늘었으며, 이유는 복잡함과 비용과 성능입니다.

가트너가 지목한 여섯 가운데 값이 내려간 것은 감시와 빌드 자동화 둘뿐이고 나머지 넷은 그대로입니다. 영상은 이렇게 권고를 다듬습니다. 바깥 기반을 전부 미루라는 것이 아닙니다. 관측은 싸졌으니 입도와 상관없이 지금 바로 도입하고, 미루라는 것은 서비스 메시와 데이터 관리 승인입니다. 오픈텔레메트리가 졸업했다고 해서 데이터 관리 조직이 저장소 분리를 승인해 주지는 않기 때문입니다. 표의 마지막 행은 이 대목을 정리한 것이며, 요구 수준과 비용 변화는 영상이 인용한 조사 시점 기준입니다.

영상은 실제 전환 경로를 네 단계로 정리합니다. 첫 단계는 도메인 경계를 정하는 일입니다. 모놀리스를 바운디드 컨텍스트라는 의미 있는 경계로 나누되 코드는 아직 나누지 않고, 산출물은 도메인 지도와 데이터 주인을 적은 표입니다. 두 번째는 매크로서비스로 떼어 내는 일로, 가장 자주 바뀌는 영역부터 큰 덩어리로 분리하며 독립 배포 단위가 두세 개에서 다섯 개쯤 나옵니다. 세 번째가 미니서비스 단계이고, 영상은 대부분의 조직에게 여기까지가 적정선이라고 말합니다. 네 번째는 확장이나 변경이 유난히 잦은 기능만 전용 저장소로 분리하는 선택적 마이크로서비스 단계입니다.

▲ 도메인 경계에서 선택적 분해까지 네 단계 (영상 14:02)

한 가지 덧붙임이 있습니다. 매크로와 미니가 반드시 순서대로 밟아야 하는 계단은 아닙니다. 오래된 기능은 매크로로 감싸 과하게 쪼개는 것을 막고, 자주 바뀌는 기능만 미니로 잘라 내면 되므로 자산 성격에 따라 두 가지를 나란히 진행해도 좋다고 영상은 말합니다. 캡처 오른쪽에는 어느 입도에서도 필요한 공통 전제 세 가지가 있습니다. 첫째, API 관리는 어느 입도에서도 필수입니다. 마이크로서비스면 관리가 필요 없다는 말이 있지만 정확히 반대이고, 서비스가 늘수록 일관된 보안이 중요해지며 팀마다 각자 보안을 만드는 것이 최악의 결과입니다. 둘째, 도구를 팀 사이에 하나로 맞춥니다. 셋째, 두 개 팀으로 먼저 해 보고 배운 뒤에 넓힙니다.

가장 중요한 것은 단계를 건너뛰지 않는 것입니다. 경계를 정하지 않고 곧장 세 번째로 가면 미니서비스가 아니라 경계 없는 분산 모놀리스가 됩니다. 조직과 역할을 다시 정하지 않고 도입하면 실패하는데, 그때 원인을 구조 탓으로 돌리기 쉽지만 진짜 원인은 대개 문화라고 영상은 지적합니다.

그런데 반드시 짚어야 할 질문이 하나 남습니다. 이 단계가 대부분의 적정선이라면 영원히 거기 머무르는 것인가. 영상의 답은 미니서비스는 종착역이 아니라 정류장이라는 것입니다. 다만 언제 넘어갈지를 취향이나 분위기로 정하면 안 되고 신호로 판정해야 합니다.

▲ 다음 단계로 넘어갈 때를 가리는 네 가지 신호 (영상 16:44)

네 신호는 이렇습니다. 첫째, 이 도메인의 배포 빈도와 확장 요구가 다른 도메인을 크게 웃도는가. 앞서 주기적으로 세어 둔 값을 판정 근거로 그대로 씁니다. 둘째, 이 도메인의 표마다 쓰기 주인이 하나로 고정되어 있는가. 가장 중요한 신호이고, 쓰기 주인이 여러 서비스로 갈려 있으면 그 도메인은 아직 올라갈 수 없습니다. 셋째, 성숙도 네 문항이 이 도메인에서 모두 예로 바뀌었는가. 회사 전체가 아니라 이 도메인 하나에만 다시 적용해 봅니다. 넷째, 관문과 관측 기반이 이미 돌아가고 있는가. 바깥 기반 없이 쪼개면 장애가 나도 어디서 났는지 알 수 없습니다.

캡처 아래 규칙은 세 가지입니다. 네 신호가 모두 예인 도메인만 올리고, 회사 전체를 한꺼번에 바꾸는 것이 아니라 도메인 하나씩 하며, 쓰기 주인이 갈려 있는 도메인은 대상이 아닙니다. 여기서 영상이 말하는 논리가 닫힙니다. 이 구간에서 쓰기 주인을 하나로 정해 두었기 때문에 올라서는 일이 새로 만드는 일이 아니라 선을 따라 자르는 일이 되고, 그 규율을 지킨 조직에게만 앞으로 가는 길이 열려 있습니다. 영상은 이 네 가지 신호가 가트너 원문에 있는 목록이 아니라 앞서 본 방어 규율과 점검 항목을 판정 기준으로 다시 짠 제안이라는 점을 분명히 밝힙니다.

영상은 정리 대목에서 실제로 쓰려면 세 가지에 먼저 답해야 한다고 말합니다. 하나씩 따져 보면 앞의 내용이 그대로 체크리스트가 됩니다.

▲ 도입 검토 때 먼저 정할 세 가지 (영상 17:20)

첫째는 도메인 경계입니다. 우리 시스템의 의미 있는 경계가 몇 개인지 세어 보십시오. 이것이 없으면 나머지는 진행되지 않습니다. 둘째는 데이터 주인입니다. 표마다 쓰기 주인을 단 하나로 정할 수 있는지 확인해야 하며, 정할 수 없다면 그 영역은 아직 나눌 준비가 안 된 것입니다. 셋째는 출발 단계입니다. 성숙도 네 문항의 결과를 놓고 매크로에서 시작할지 미니에서 시작할지 정합니다. 영상의 결론은 한 문장입니다. 마이크로서비스는 목표가 아니라 선택지 가운데 하나이고, 대부분의 조직에게 정답은 미니서비스입니다.

실무에서는 이 세 질문을 도입 회의의 첫 안건으로 올리는 편이 좋습니다. 도메인 경계 목록과 표별 쓰기 주인 표가 비어 있다면 도구나 플랫폼 이야기로 넘어가기 전에 그 표부터 채워야 한다고 이 영상은 말하는 셈입니다. 그 표가 있으면 미니서비스로 안전하게 출발할 수 있고, 나중에 마이크로서비스로 올라설지도 같은 표로 판정할 수 있습니다.

미니서비스는 도메인 안의 저장소 공유를 허용해 비용을 낮추는 단계이고, 표마다 쓰기 주인을 하나로 고정하는 규율이 이후의 분리를 가능하게 합니다.

미니서비스는 마이크로서비스와 무엇이 다른가요?

도메인 경계 안에서 저장소 공유와 직접 호출을 허용해 분산 비용을 낮춘 단계입니다. 영상은 미니서비스가 데이터 독립, 통신 방식, 입도, 조직의 네 가지 제약을 느슨하게 풀어 준다고 설명하며, 서비스가 수백 개가 아니라 수십 개가 되고 전면적인 조직 개편 없이 시작할 수 있다는 점을 장점으로 꼽습니다.

미니서비스가 다시 모놀리스로 돌아가는 것은 어떻게 막나요?

저장소 공유 범위 제한, 도메인 하나 제한, 표별 쓰기 주인 하나, 주기적 계측의 네 규율로 막습니다. 영상은 저장소 공유의 예외가 규칙이 되고 기존 서비스에 기능이 덧붙으며 서비스가 비대해지는 경로를 경고하고, 네 가지 모두 도구가 아니라 규율이라고 강조합니다. 그중 표마다 쓰기 주인을 하나로 정하는 것이 가장 중요합니다.

어떤 조직이 미니서비스에서 시작해야 하나요?

성숙도 네 문항 가운데 하나라도 아니오가 나오는 조직입니다. 문항은 아키텍처 실천 조직, 애자일·데브옵스·CI/CD 성숙도, 서비스별 데이터 분리에 대한 데이터 관리 조직의 지원, 실제 민첩성과 확장 요구입니다. 영상은 기본값이 미니서비스와 매크로서비스이고 마이크로서비스는 요구가 증명된 영역에만 고른다고 설명합니다.

이너 아키텍처와 아우터 아키텍처는 무엇이 다른가요?

이너는 서비스 안쪽 구조이고 아우터는 서비스 바깥의 운영 기반입니다. 이너 아키텍처의 도메인 모델과 계층 규율은 입도와 상관없이 미니서비스에서도 지켜야 하고, 아우터 아키텍처는 서비스 수가 줄면 요구 수준도 내려갑니다. 그래서 영상은 안쪽을 먼저, 바깥을 나중에 갖추라고 권합니다.

2026년에는 서비스 메시와 관측 비용이 어떻게 달라졌나요?

관측 비용은 내려갔고 서비스 메시는 사용률이 50퍼센트에서 42퍼센트로 줄었습니다. 오픈텔레메트리가 올해 5월 CNCF 졸업 등급에 올라 관측은 입도와 상관없이 지금 도입해도 되지만, 서비스 메시와 데이터 관리 승인은 요구 수준이 그대로라 나중으로 미루라고 영상은 정리합니다.

미니서비스에서 마이크로서비스로 언제 올라가야 하나요?

배포 빈도, 쓰기 주인, 성숙도, 관문·관측 기반의 네 신호가 모두 예인 도메인만 올립니다. 회사 전체가 아니라 도메인 하나씩 판정하고, 쓰기 주인이 여러 서비스로 갈려 있으면 아직 대상이 아닙니다. 영상은 이 신호가 가트너 원문의 목록이 아니라 앞의 규율을 판정 기준으로 다시 짠 제안이라고 밝힙니다.

가트너의 근거는 지금도 유효한가요?

영상이 쓴 가트너 근거는 2017년에서 2019년 연구 기준이므로 자사 환경에 맞게 확인해야 합니다. 직접 호출이 미니서비스라는 지적도 2018년의 특정한 맥락에서 나온 말이라 자가 진단용으로만 쓰라고 영상은 단서를 답니다. 2026년 기준 변화는 관측 도구처럼 일부 구성요소에서만 확인된다고 설명합니다.

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

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