Show Cover Slide

MSA는 비용이 증가하지 않는다. 단지 불편할 뿐이다.

서문

많은 이들이 MSA에 대해 이야기합니다.
서비스를 분리하라고 말하고, 계약을 명확히 하라고 강조합니다.
책임을 나누고, 장애를 국지화하라는 조언도 빠지지 않습니다.

그러나 이러한 대화를 계속 이어가다 보면,
그 구조를 실제로 실행해 본 경험이 없는 경우가 적지 않다는 사실을 발견하게 됩니다.

이 글은 MSA를 직접 구조화하고 운영해 오면서,
실제 팀을 구성하고, 실패를 경험하며, 시스템을 분리하고 다시 통합하는 과정을 통해
얻게 된 몇 가지 작은 깨달음과 해석들을 정리한 것입니다.

MSA가 어렵다는 인식,
초기 도입 비용이 크다는 주장,
그리고 조직에 부담이 된다는 우려.

이러한 주장들이 어디에서 비롯되었는지를,
그리고 그 이면에 어떤 두려움과 회피가 숨어 있는지를
경험자의 관점에서 차분히 살펴보고자 합니다.

MSA는 어렵지 않습니다. 다만 지나치게 투명하기 때문에, 불편할 뿐입니다.

정말 MSA가 어려운 걸까?

많은 조직이 MSA 도입을 망설입니다.
“비용이 많이 든다”, “구조가 복잡하다”, “초기 스타트업에는 적합하지 않다”는 이야기도 종종 들려옵니다.

하지만 제가 경험했던 사례들을 돌아보면,
이러한 판단이 MSA 자체의 구조적 한계에서 비롯된 것만은 아니었던 것 같습니다.

제가 관찰한 바로는

• 책임이 명확히 나뉘지 않는 문화,
• 불분명한 계약 관계,
• 문제를 감추기 쉬운 코드 구조,
• 실험을 꺼리는 의사결정 분위기 등이
  오히려 더 많은 비용을 유발하는 경우가 많았습니다.

MSA가 비용이 크다고 느껴지는 것은, 구조가 투명하기 때문일 수 있습니다.
그동안 잘 보이지 않았던 비효율이 드러난 결과일지도 모릅니다.

처음부터 모듈화된 구조를 염두에 두고 출발했다면,
작은 실패는 쉽게 고칠 수 있었을 것이고,
새로운 시도도 부담 없이 반복될 수 있었을 거라는 생각이 듭니다.

결국 문제는 구조 그 자체라기보다는,
그 구조가 드러내는 투명함을 받아들이는 자세와 태도에 가까웠습니다.

모듈로 시작했기에 두렵지 않았다

처음부터 완벽한 구조를 설계하는 일은 어렵습니다.
하지만 삭제가 가능한 구조, 경계가 분리된 설계,
그리고 언제든 다시 만들 수 있다는 마음가짐은 충분히 마련할 수 있었습니다.

초기 개발 단계에서는 기능을 모듈 단위로 나누는 방식을 택했습니다.
각 기능을 독립된 파일로 분리하고, 실행 단위 또한 작게 유지하려고 노력하였습니다.
그 결과, 전체 시스템을 버리지 않고도 문제가 발생한 모듈만 교체하거나 제거하는 방식으로 대응할 수 있었습니다.

이러한 접근은 결과적으로 실패를 크게 두려워하지 않아도 되는 구조를 가능하게 했습니다.

• 리팩터링은 자유롭게 이루어졌고,
• A/B 테스트도 비교적 부담 없이 시도할 수 있었으며,
• 코드의 책임 범위가 점차 명확해졌고,
• 반복적인 실험을 통해 구조가 서서히 정제되어 갔습니다.

이러한 결과의 출발점에는 ‘모듈적 사고’가 자리하고 있었습니다.

사실 모듈 단위로 나누는 사고방식은 특별한 것이 아니었습니다.
윈도우 운영체제의 DLL, 자바의 클래스로더, 파이썬의 importlib 등
이미 오래전부터 존재해온 방식들 역시 같은 원리를 따르고 있었습니다.
약 15년 전, 개인적으로 직접 구현했던 모듈로더 또한 그 흐름 속에 있었다고 생각합니다.

동적으로 로딩 가능한 구조는 단지 기술적인 편의만을 의미하지 않습니다.
그것은 실패를 허용하는, 구조적 여유를 만들어주는 접근이었습니다.

MSA 역시 처음부터 거창한 프레임워크를 기반으로 시작한 것은 아니었습니다.
오히려 다소 낡았지만 유연한 방법에서 출발하였고,
결과적으로는 더 적은 비용으로 더 높은 탄력성을 확보할 수 있었다고 느꼈습니다.

기술보다 태도가 어렵다

MSA가 어렵다고 말하는 분들이 종종 있습니다.
API 게이트웨이, 서비스 간 인증, 메시지 브로커, CI/CD, 컨테이너 오케스트레이션 등
익혀야 할 기술 요소가 많기 때문입니다.

물론 학습해야 할 부분이 많은 것은 사실입니다.
하지만 시간이 지나면서 깨닫게 됩니다.
이러한 기술들은 잘 정리된 문서가 있고, 예제가 있으며, 커뮤니티도 활발하게 형성되어 있습니다.
결국 시간을 들이면 익힐 수 있는 영역입니다.

그보다 더 어려운 것은 기술이 아니라 태도입니다.

MSA는 기술적인 구조이기도 하지만,
그보다 먼저 책임을 분산하고, 경계를 존중하며, 계약을 지키는 태도를 전제로 합니다.
그리고 이 책임은 불편함을 수반합니다.

• 책임이 명확해지면 회피가 어렵습니다.
• 인터페이스가 정리되면 핑계를 댈 여지가 줄어듭니다.
• 모니터링 체계가 구성되면 “몰랐다”는 말이 설득력을 잃게 됩니다.

MSA가 어렵다고 느껴지는 이유는,
기술 자체의 난이도라기보다는
그 구조가 요구하는 태도와 마주해야 하기 때문이라는 생각이 들었습니다.

구조는 책임을 드러내는 장치이며, MSA는 그것을 감추지 않습니다.

필요한 것은 기술이 아니라, 필요하다는 인식이다

구조를 나누는 일 자체는 어렵지 않습니다.
API를 설계하고, 서비스를 분리하며, 컨테이너로 배포하는 일은
숙련된 개발자라면 충분히 수행할 수 있는 범위에 있습니다.

그러나 구조를 지속적으로 운영하고, 유지하며, 확장 가능하게 만드는 일은
기술만으로는 이루어지지 않습니다.
그 핵심에는 문화가 자리하고 있었습니다.

MSA는 구조를 통해 사람에게 묻습니다.

• 자신의 책임이 무엇인지 알고 있는가?
• 호출하지 않아도 될 서비스를 호출하고 있는 것은 아닌가?
• 계약이 변경되었을 때, 누구와 어떻게 소통해야 하는가?

결국 MSA는 단순한 기술 도입이나 구조 설계의 문제가 아니라,
책임을 나누고, 신뢰를 전제로 움직이며, 자율을 훈련하는 문화의 문제라는 생각이 들었습니다.

이러한 문화가 형성되지 않은 채 구조만 도입된다면,
MSA는 오히려 더 큰 복잡성을 유발하고,
문제의 원인을 파악하기 어려우며,
팀 내 피로도는 높아질 수 있습니다.

그래서 중요한 것은 기술 도입 자체보다,
그 구조가 왜 필요한지를 이해하고
모두가 공유할 수 있는 문화적 인식이라고 느꼈습니다.

MSA는 구조 설계 이전에, 함께 살아갈 방식을 합의하는 과정입니다.
그 안에서 사람들은 책임을 배우고, 협업을 반복하며, 신뢰를 쌓아갑니다.

커뮤니케이션 비용이 늘어나는 진짜 이유

MSA는 원래 커뮤니케이션 비용을 줄이기 위한 구조로 제안되었습니다.
각 서비스가 명확한 경계를 가지고, 팀이 자율적으로 책임을 지며,
불필요한 협의 없이도 독립적으로 개발·배포할 수 있도록 하자는 철학이었습니다.

하지만 현실에서는,
오히려 커뮤니케이션 비용이 증가했다는 반응을 자주 듣게 됩니다.

왜 그럴까요?

저는 이 원인이 두 가지라고 생각합니다.

1. 경계를 책임이 아니라 기능 중심으로 나누었기 때문

많은 경우, 서비스 경계를 다음과 같은 기준으로 나눕니다:

• 트래픽이 많으니 따로 빼자
• 인증은 공통 기능이니까 모듈로 만들자
• 프론트와 백을 나누듯 API도 분리하자

하지만 이런 기준은 ‘책임’의 단위가 아니라 ‘기능’의 단위입니다.
그 결과, 실제 장애나 변경이 발생했을 때
“이건 누가 책임지지?”라는 질문에 명확히 답하지 못하는 상황이 발생합니다.

서비스는 책임 기준으로 경계가 세워져야 합니다.
기능적 분리는 도와주는 수단일 뿐, 책임을 나누는 기준이 되어선 안 됩니다.

• 서비스는 나뉘었지만,
• 책임은 흐려지고,
• 호출 흐름은 중첩되며,

서비스 간 협의는 오히려 더 많아집니다.

결국, 경계가 잘못 그어진 서비스 구조는
커뮤니케이션 비용을 줄이기는커녕 폭증시킬 수 있습니다.

2. ‘왜 나누는가’에 대한 목적이 잊혔기 때문

MSA는 ‘작게 나누는 것’이 목적이 아니라,
‘독립적으로 움직일 수 있도록 만드는 것’이 목적이었습니다.

하지만 구현 과정에서 이 목적이 희미해지면,
그저 ‘작은 서비스들이 나열된 구조’만 남게 됩니다.

• 작지만 서로 강하게 얽힌 서비스
• 작은 변경에도 여러 팀이 조율해야 하는 구조
• 테스트와 배포는 독립되지 않고, 오히려 순서를 맞추기 어려운 흐름

이러한 결과는 “Micro”라는 단어에 집착하고,
“왜 나누는가”를 놓쳤을 때 나타납니다.

결국 커뮤니케이션 비용이 늘어났다는 경험은,
구조가 실패한 것이 아니라 구조를 수립하는 방식에서 책임과 목적이 함께 고려되지 않았기 때문입니다.

교육은 피할 수 없는 비용이다

MSA 도입과 관련된 이야기 속에는 종종 같은 우려가 등장합니다.
바로 “교육 비용이 너무 크다”는 주장입니다.

구조를 바꾸면 팀을 다시 교육해야 하고,
사람들의 사고방식에도 변화가 필요하며,
익숙했던 도구 대신 새로운 툴을 익혀야 한다는 점이 부담스럽게 느껴질 수 있습니다.

이러한 우려는 충분히 이해할 만합니다.
하지만 한 가지 질문을 던져볼 필요가 있습니다.

과연, 모놀리식 시스템은 별도의 교육 없이 운영되었을까요?

실제로는 그렇지 않았다고 생각합니다.
모놀리식 시스템 역시 다음과 같은 형태로 많은 비공식 교육을 전제로 운영되고 있었습니다.

• 명문화되지 않은 규칙,
• 구두로 전달되는 정보,
• 문서화되지 않은 의존 관계,
• 분명하지 않은 책임 구분

이런 방식은 눈에 보이지는 않았지만,
개발자 간의 설명, 신입의 암묵적 추측, 반복적인 질문과 답변 속에서
계속해서 시간과 에너지를 소비하게 만들었습니다.

단지 그 비용이 구조적으로 보이지 않았을 뿐,
실제로는 계속 존재해왔던 것입니다.

MSA는 이러한 학습 비용을 공식화하고, 문서화하며, 체계화하려는 시도입니다.
그래서 비용이 드러나 보이지만,
그것은 새로운 부담이 아니라 기존에 숨어 있던 비용이 명확해진 것이라고 생각합니다.

더 나아가 이런 비용은 결국 어느 시점에서는 반드시 발생합니다.
그렇다면 구조를 전환해야 하는 시점에 급히 교육을 시작하기보다는,
처음부터 교육을 전제로 한 구조 위에서 출발하는 편이
더 안정적이고 지속 가능한 선택이 될 수 있다고 느꼈습니다.

교육은 피할 수 없는 비용입니다.
다만, 그것을 미루느냐,
아니면 처음부터 구조 속에 포함시키느냐의 차이일 뿐입니다.

투명한 구조는 빠른 구조다

MSA는 종종 불편하게 느껴집니다.
책임이 명확히 드러나고, 경계가 고정되며, 의존성이 구조 안에서 적나라하게 드러나기 때문입니다.
이러한 특성은 부담으로 작용할 수 있습니다.

하지만 역설적으로, 이러한 투명함이
오히려 더 빠른 의사결정과 실행을 가능하게 한다는 점을 경험을 통해 알게 되었습니다.

구조가 투명하면 회피할 수 있는 여지가 줄어듭니다.

• 병목이 발생하는 위치를 금방 파악할 수 있고,
• 응답이 지연되는 지점을 쉽게 추적할 수 있으며,
• 계약이 깨진 부분도 명확하게 드러납니다.

이러한 구조에서는

• 커뮤니케이션 횟수가 줄고,
• 협의에 소요되는 시간이 짧아지며,
• 의사결정이 자연스럽게 분산됩니다.

MSA는 구조적으로 투명성을 내포하고 있습니다.
그리고 이 투명성은 관리 항목을 늘리는 것이 아니라,
책임을 적절히 분산시킴으로써 운영의 부담을 오히려 경감시켜 줍니다.

모놀리식 구조는 문제를 감추는 경향이 있고,
MSA는 문제를 드러내는 구조입니다.

문제가 드러나야 해결이 가능하며,
그러한 드러남이 반복될수록 구조는 점점 더 강인해지는 방향으로 정제됩니다.

따라서 “MSA는 불편하다”는 인식은 이렇게 전환할 수 있다고 생각합니다.

“MSA는 지나치게 투명해서 불편하게 느껴질 수 있다.”
그러나 그 투명함이야말로,
결국 더 빠른 조직을 만들어 가는 기반이 됩니다.

정말 어려운 건 구조가 아니다

MSA는 구조적으로 어렵다고 평가되곤 합니다.
하지만 실제로는 대부분의 기술은 문서와 예제를 통해 학습할 수 있고,
필요한 도구 역시 기존의 오픈소스나 클라우드 서비스를 차용하여 사용할 수 있습니다.

구조적인 설계 역시 반복적인 피드백을 통해 충분히 개선될 수 있으며,
모듈화는 일정한 기준을 세우고 나면 그리 어려운 작업이 아닙니다.

제가 경험한 바로는,
정말 어려운 지점은 구조 자체가 만들어내는 투명함을 감당하는 일이었습니다.

투명한 구조는 책임을 명확하게 드러내고,
모호함을 줄이며, 각자의 역할을 분명히 나누게 만듭니다.
이 과정에서 개인 혹은 팀은
자신의 결정과 결과에 대해 더 직접적으로 마주하게 됩니다.

그 마주침이 때로는 불편하게 느껴지기도 하고,
그 불편함을 피하려는 움직임이 구조적 저항으로 나타날 수도 있습니다.

그래서 결국,
정말 어려운 것은 기술적인 난이도나 설계 복잡성이 아니라,
그 구조를 통해 드러나는 문화적 긴장과 개인의 태도 변화였습니다.

정리하며

MSA는 단순히 구조를 나누는 기술이 아닙니다.
그보다는 책임을 명확히 하고, 협업의 방식을 재정의하며,
조직이 스스로의 일에 투명하게 마주할 수 있도록 하는 문화적 변화입니다.

이러한 투명함은 불편할 수 있지만,
그 불편함을 넘어설 때,
더 빠르고 건강한 시스템을 만들어갈 수 있다고 믿습니다.

MSA는 어렵지 않습니다.
단지 그 투명함이 낯설고, 아직 익숙하지 않을 뿐입니다.

첨부 1: 흔한 오해들 – 쿠버네티스, Compose, FaaS는 MSA인가?

실무에서 자주 마주치는 몇 가지 기술적 오해에 대해 간단히 정리해두려 합니다.
MSA의 철학이 어떻게 도구 선택과 엮여 해석되는지를 돌아보는 데 도움이 될 수 있습니다.

쿠버네티스를 써야 하나요?
Docker Compose면 안 되나요?
FaaS도 MSA인가요?

이 질문들은 모두, MSA를 기술적 도구의 선택 문제로 오해한 결과입니다.
하지만 도구는 단지 실현 수단일 뿐이며,
MSA의 본질은 도구가 아니라 철학입니다.

MSA는 경계를 나누는 방식이 아니라, 경계를 받아들이는 태도입니다.

아래에서는 흔히 발생하는 세 가지 오해를 중심으로,
도구와 철학의 관계를 조금 더 자세히 짚어보고자 합니다.

1. 쿠버네티스를 쓰면 MSA가 되는가?

쿠버네티스는 훌륭한 도구입니다.
다수의 서비스를 배포하고, 스케일링하고, 상태를 관리하기에 적합한 플랫폼입니다.

그래서 많은 팀들이 “MSA를 하려면 Kubernetes부터 도입해야 한다”고 생각합니다.
하지만 실상은 그 반대일 수 있습니다.

쿠버네티스를 도입했지만, 서비스 간 경계는 여전히 모호하고

배포는 여전히 전체 단위로 묶여 있으며

운영은 여전히 중앙집중식으로 관리되고 있다면

그건 쿠버네티스를 사용한 모놀리식일 뿐입니다.

Kubernetes는 MSA를 실현할 수 있는 여건을 만들어주는 도구이지,
MSA 그 자체가 아닙니다.

쿠버네티스를 도입했다고 해서
자동으로 팀의 책임이 나뉘거나
계약이 정리되거나
조직이 자율적으로 움직이게 되는 것은 아닙니다.

도구를 먼저 도입한 후,
철학을 뒤늦게 이해하는 방식은 구조적으로 위험합니다.

2. Docker Compose를 쓰면 MSA가 아닌가?

반대로, 어떤 분들은 “우리는 아직 쿠버네티스를 쓰지 못해서 MSA는 무리입니다”라고 말합니다.
하지만 정말 그럴까요?

실제로 Docker Compose 환경에서도 다음과 같은 조건이 충족된다면,
MSA의 철학은 충분히 실현 가능합니다.

각 서비스가 독립된 코드베이스와 책임을 갖고 있고

API를 통해 느슨하게 연결되어 있으며

배포나 실험이 서비스 단위로 수행된다면

기술적으로는 단순한 도구를 사용하더라도
조직적으로는 MSA에 가까운 구조를 만들 수 있습니다.

Compose는 실험을 시작하기에 오히려 좋은 환경입니다.

작은 단위로 나누고, 실패해보고, 교체해보는
모듈적 사고의 훈련장으로써 Compose 환경은 충분히 의미가 있습니다.

MSA의 출발점은 반드시 쿠버네티스가 아니라, 경계에 대한 감각입니다.

3. FaaS를 쓰면 MSA인가?

또 다른 오해는,
“FaaS(Lambda, Cloud Function 등)를 쓰니까 우리는 마이크로서비스 구조다”라는 주장입니다.

FaaS는 작고 빠른 단위로 서비스를 실행할 수 있으며,
스케일링과 비용 측면에서 많은 장점을 제공합니다.
그러나 그것이 곧 MSA라는 뜻은 아닙니다.

Lambda를 여러 개 만들었지만,

기능이 단절되지 않고 순차 호출에 의존하고 있으며

호출 흐름을 파악하기 어렵고

책임과 소유가 흐릿하다면

그것은 단지 잘게 쪼개진 스파게티일 수 있습니다.

FaaS는 실행 단위일 뿐,
도메인과 책임, 인터페이스, 장애 범위를 어떻게 정의할 것인지에 대한 답은 제공하지 않습니다.

FaaS를 사용하는 이유가

시스템을 작게 나누기 위함이 아니라

비용을 줄이고, 빠르게 배포하려는 목적만 있다면

그 구조는 오히려 더 복잡하고 추적하기 어려운 형태로 발전할 수 있습니다.

정리하며
도구는 철학을 대신할 수 없습니다.
도구는 철학을 실현할 수 있는 기반이 되어줄 수는 있지만,
그 자체로 철학이 되지는 못합니다.

쿠버네티스를 써도, 책임이 나뉘지 않으면 MSA가 아닙니다.

Compose 환경이어도, 경계와 책임이 명확하다면 MSA입니다.

FaaS를 쓰더라도, 호출 흐름이 얽히고 책임이 불명확하다면 MSA는 아닙니다.

MSA는 기술의 문제가 아니라, 관점의 문제입니다.
MSA는 시스템을 어떻게 나눌 것인가보다,
사람과 책임이 어떻게 나뉘어야 하는가에 대한 질문에서 출발합니다.

첨부 2: 스타트업으로서 MSA를 지향하여 일한다는 것의 의미

MSA를 지향한다는 것은
“우리는 구조부터 나눴다”는 선언이 아닙니다.

오히려 그 말은,
“우리는 언제든 나눌 수 있도록 일하고 있다”는 의미를 전달하기 위함입니다.

구조를 나눈다는 것은 결과이고,
그 결과가 가능하도록 일의 방식부터 설계하는 것이 진짜 MSA의 출발점입니다.

이는 다음과 같은 태도를 포함합니다:

1. 워크플로우를 인식하고
   • 요청이 어떻게 생성되고,
   • 누가 응답하며,
   • 어떤 결정이 어떤 조건에서 이루어지는지를 흐름으로 정리합니다.
2. 계약을 정리하고
   • 데이터 구조, 요청 조건, 실패 처리 등
   • 넘길 수 있고 자동화 가능한 계약의 형태를 갖춥니다.
3. 탬플릿을 만들며 일하고
   • 반복되는 요청과 응답 과정을 표준화하고,
   • 구조 안에 명확한 책임과 인터페이스를 심어둡니다.
4. 기술보다 언어와 구조를 먼저 설계합니다
   • 코드보다 앞서 협업의 단위를 정의하고,
   • 역할과 책임의 경계를 문서화합니다.

산업화 시대의 관료제와 동일한 질문

사실 이런 사고방식은 새로운 것이 아닙니다.
산업화 이후 조직이 대규모로 성장하면서 정립된 관료제의 기본 원칙 역시 유사한 질문에서 출발했습니다:

• 이 일은 어떤 기능에서 처리해야 하는가?
• 누가 승인하고, 누가 실행하며, 누가 책임지는가?
• 어떤 절차와 문서가 흐름을 보장하는가?

즉, 조직의 역할과 기능, 권한과 책임, 절차와 흐름을 분리하는 설계는
이미 오래전부터 복잡한 시스템을 운영하는 데 필요한 기본 조건이었습니다.

MSA는 단지 그것을 소프트웨어적 방식으로 표현한 것일 뿐입니다.
따라서 스타트업이 MSA를 지향한다는 것은
‘엔터프라이즈처럼 일하겠다’는 선언이 아니라,
확장을 견딜 수 있는 구조적 언어와 흐름을 갖추겠다는 실용적 선택입니다.

함께 만들고, 먼저 준비해야 할 일

그리고 이 방향은,
개발자 개인의 습관이나 기술 선택의 문제가 아니라
조직이 함께 만들어가야 할 일의 방식이며,
그 여정을 리더십이 먼저 준비하고 열어두는 책임이 따릅니다.

리더가 준비하지 않은 조직에서 구조를 요구하면,
실행은 개인에게 맡기고 책임은 흐려지기 마련입니다.
MSA를 지향한다면, 그 언어와 기준, 흐름을 먼저 제안하는 구조 설계자가 필요합니다.

스타트업에서 MSA를 지향한다는 것은
단지 시스템을 설계하는 일이 아니라,
조직 전체가 함께 성장할 수 있는 방식으로 일하는 문화를 설계하는 일입니다.

MSA는 거창한 구조가 아니라,
나중에 분리 가능한 방식으로 함께 일하려는 태도 그 자체입니다.

첨부3: MSA 설계를 위한 철학적 기반 문헌 요약 (연도순 정리)

1. “Domain-Driven Design: Tackling Complexity in the Heart of Software” – Eric Evans (2003)

English Summary

This book introduces the concept of bounded context — a clearly defined boundary within which a particular domain model is valid. It emphasizes domain modeling, strategic design, and the importance of aligning software structure with business concepts. These ideas are foundational to defining microservice boundaries that map cleanly to business capabilities.

Contribution to MSA Design:

• Encourages services to be built around business domains.
• Promotes clear ownership, isolation, and internal consistency of models.
• Introduces the idea that each service has its own ubiquitous language within its context.

Korean Translation

이 책은 특정 도메인 모델이 유효한 범위인 경계된 컨텍스트(bounded context) 개념을 도입합니다. 또한 도메인 모델링, 전략적 설계, 비즈니스 개념과 소프트웨어 구조 간의 정렬을 강조합니다. 이 개념들은 마이크로서비스가 비즈니스 기능에 대응되도록 경계를 정의하는 데 핵심적인 기반이 됩니다.

MSA 설계에의 기여:

• 서비스가 비즈니스 도메인을 기준으로 나뉘어야 함을 강조
• 명확한 책임 분리와 모델의 일관성을 보장
• 각 서비스 내부에서 독립적인 언어 체계(ubiquitous language) 유지

2. “Service-Oriented Architecture: Concepts, Technology, and Design” – Thomas Erl (2005)

English Summary

This book defines core SOA principles including service contract, autonomy, reusability, composability, and statelessness. It offers a technological and conceptual foundation for thinking in services, encouraging interoperability and abstraction from implementation details.

Contribution to MSA Design:

• Lays groundwork for service modularity and separation of concerns
• Promotes loose coupling through standardized interfaces
• Advocates service granularity and orchestration

Korean Translation

이 책은 서비스 계약, 자율성, 재사용성, 조합성, 무상태성 등의 SOA 핵심 원칙을 정의합니다. 서비스 중심 사고의 기술적·개념적 기반을 제공하며, 구현 세부 사항으로부터의 추상화와 상호 운용성을 장려합니다.

MSA 설계에의 기여:

• 서비스 모듈화 및 관심사 분리를 위한 기초 제공
• 표준화된 인터페이스를 통한 느슨한 결합 구현
• 적절한 서비스 크기(granularity)와 오케스트레이션 개념 도입

3. “SOA Manifesto” (2009)

English Summary

The manifesto outlines the philosophical stance of SOA, prioritizing business goals over technical implementation. It embraces flexibility, modularity, and contract standardization. These principles philosophically anticipate many of MSA’s later values.

Contribution to MSA Design:

• Frames service architecture as a response to business change
• Values adaptability and governance over rigid implementation
• Advocates contract-first design, later adopted in MSA APIs

Korean Translation

SOA 선언문은 기술 구현보다 비즈니스 목표 달성을 우선시하는 철학적 관점을 담고 있으며, 유연성, 모듈성, 서비스 계약의 표준화를 강조합니다. 이는 이후 MSA가 받아들인 주요 가치들의 철학적 토대를 형성합니다.

MSA 설계에의 기여:

• 서비스 구조를 변화에 대응하는 프레임으로 설정
• 고정된 구조보다 유연성과 거버넌스를 강조
• 계약 기반 설계(contract-first)를 강조, 이는 이후 MSA의 API 설계로 이어짐

4. “Microservices” – James Lewis & Martin Fowler (2014)

English Summary

This influential article synthesizes industry practice into a clear set of microservice characteristics: decentralized governance, independent deployability, smart endpoints and dumb pipes, and organization-aligned architecture. It became the conceptual launchpad for MSA in practice.

Contribution to MSA Design:

• Defines microservices as independent, business-aligned units
• Encourages teams to own the full lifecycle of services
• Highlights operational concerns like deployment automation and observability

Korean Translation

이 글은 분산 거버넌스, 독립 배포 가능성, 스마트 엔드포인트와 단순 파이프, 조직 구조와 정렬된 설계 등 마이크로서비스의 핵심 특징들을 명확히 정의하며, 실제 실무에서의 MSA 출발점을 제시합니다.

MSA 설계에의 기여:

• 마이크로서비스를 독립적이며 비즈니스에 정렬된 단위로 정의
• 서비스 수명 주기 전체에 대한 팀의 책임 강조
• 배포 자동화와 관찰 가능성(observability) 등 운영 측면 강조

1. “Microservices: A Systematic Mapping Study” – Pires & Pereira (2018)

English Summary

This paper surveys the academic landscape of microservices, classifying literature into categories like architecture, implementation, deployment, and monitoring. It presents challenges such as service granularity, data consistency, and orchestration vs. choreography.

Contribution to MSA Design:

• Offers taxonomy of MSA-related concerns in research
• Highlights open challenges (e.g., how fine-grained is “too fine”?)
• Bridges gap between theory and real-world implementation

Korean Translation

이 논문은 마이크로서비스 관련 연구들을 아키텍처, 구현, 배포, 모니터링 등으로 분류하며 체계화합니다. 서비스의 적절한 크기, 데이터 일관성, 오케스트레이션과 코레오그래피 간의 선택 등 실질적인 과제들을 제시합니다.

MSA 설계에의 기여:

• MSA 관련 기술/운영 이슈들을 분류하고 구조화
• 해결되지 않은 과제들(예: 과도한 분리의 위험)을 밝힘
• 이론과 실무 간의 간극을 메우는 중간자 역할 수행

6. “Microservices: Yesterday, Today, and Tomorrow” – Fritzsch et al. (2019)

English Summary

This historical review explores the evolution of service-based systems, analyzing how microservices emerged from SOA, component-based design, and agile delivery practices. It identifies common adoption patterns and anti-patterns from empirical studies.

Contribution to MSA Design:

• Tracks historical context that shaped MSA
• Informs how organizations transitioned from monoliths
• Describes pitfalls like over-fragmentation and distributed complexity

Korean Translation

이 논문은 SOA와 구성요소 기반 설계, 애자일 등에서 마이크로서비스가 어떻게 진화했는지를 역사적으로 조망합니다. 또한 마이크로서비스 도입 시 흔히 나타나는 성공 패턴과 실패 패턴을 분석합니다.

MSA 설계에의 기여:

• MSA가 어떤 시대적 배경 속에서 등장했는지 설명
• 조직이 모놀리식에서 어떻게 전환해왔는지를 실증적으로 분석=
• 과도한 분리, 분산 시스템 복잡도 등의 위험 요인을 정리

실무 적용 시 인사이트 요약

Revision History

• 2025-07-01: ‘첨부 3: MSA 설계를 위한 철학적 기반 문헌 요약 (연도순 정리)’ 색션 추가
• 2025-06-30: ‘첨부 2: 스타트업으로서 MSA를 지향하여 일한다는 것의 의미’ 색션 추가
• 2025-06-30: ‘첨부 1: 흔한 오해들 – 쿠버네티스, Compose, FaaS는 MSA인가?’ 섹션 추가
• 2025-06-30: ‘커뮤니케이션 비용 증가’ 섹션 추가
• 2025-06-30: “서비스는 책임 기준으로 경계가 세워져야 한다” 문장 보완
• 2025-06-30: 최초 게시