전략적 모놀리스와 마이크로서비스: 목적 있는 아키텍처를 통한 혁신

게시 2026/01/10 업데이트 2026/01/10

By BLUEBUG

128 분읽는 시간

서문: 2025년 12월, 한 고백이 촉발한 성찰

2025년 12월 28일, “Microservices Killed Our Startup. Monoliths Would’ve Saved Us” 라는 제목의 Medium 글이 개발자 커뮤니티를 강타했다. 시드 투자 250만 달러를 유치하고 월 40% 성장세를 보이던 스타트업이 마이크로서비스 도입 6개월 만에 거의 파산 직전까지 갔다가, 다시 모놀리스로 회귀하여 살아난 이야기였다. 이 고백록은 단순한 기술적 실패담이 아니었다. 그것은 소프트웨어 업계 전체가 직면한 근본적인 질문을 던졌다. “우리는 왜 작동하는 것을 고치려 하는가?”

반 버논과 토마스 야스쿨라의 “Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture” (2021년 출간, 국내 “전략적 모놀리스와 마이크로서비스” 2025년 4월)는 이 질문에 대한 성숙한 답변을 제시한다. 이 책은 아키텍처 선택이 단순히 기술적 결정이 아니라 전략적 비즈니스 결정임을 강조한다. 2026년 1월 현재, 우리는 기술 트렌드의 과대광고에서 벗어나 실용적 지혜로 회귀하는 시점에 있다.

이 문서는 최근의 실패 사례, 업계 트렌드, 그리고 전략적 아키텍처에 대한 학술적 통찰을 통합하여, 2026년 현재 아키텍처 선택에 대한 균형 잡힌 가이드를 제공한다.

1장: 비즈니스 목표와 디지털 전환 - 근본으로 돌아가기

1.1 혁신의 본질: 필요성의 어머니

“가장 뛰어난 비즈니스 성과는 많은 소비자가 필요로 하고, 완전히 독특하며, 최적으로 가격이 책정된 제품을 만드는 것이다.” 플라톤의 “필요는 발명의 어머니”라는 격언은 오늘날에도 여전히 유효하다. 하지만 가장 심오한 혁신가들은 소비자가 필요하다는 것을 깨닫기도 전에 독창적인 제품을 발명한 사람들이다.

SpaceX가 보여준 혁신의 본질을 생각해보자. 1970년에서 2000년 사이, 우주로 1킬로그램을 발사하는 비용은 평균 18,500달러였다. SpaceX Falcon 9의 경우, 그 비용은 단지 2,720달러다. 7:1의 개선, 그것도 엄청난 비밀이 있어서가 아니다. 그들이 하지 않은 것은 정부 계약 하에 일하는 것이었다.

그들의 목표는 우주로 물건을 발사하는 비용을 극적으로 줄이는 것이었다. 주요 하위 목표는 부스터 로켓을 회수하고 재사용하는 것이었다. 그들이 목표를 달성하기 위해 추락시킨 부스터들의 영상이 YouTube에 있다. 이벤트 통합 전략(이 경우 테스트 부스터 발사)은 여러 엔지니어링 팀이 최신 버전을 다른 모든 팀과 함께 빠르게 시도하는 방법이다. 정부 계약은 SpaceX가 겪은 충돌을 절대 용인하지 않았을 것이다.

핵심 통찰: SpaceX 팀은 위험을 감수하기보다는 미지의 미지를 발견하기 위해 시도하면서, 영원히 기다리는 대신 상세하게 모든 것을 생각하려 하지 않음으로써 신뢰할 수 있고 저렴한 부스터 로켓 개발을 아마도 5배 빠르게 만들었다고 말했다. 이것은 매우 고전적인 엔지니어링 접근법이지만, 계약 모델에서는 절대 허용되지 않을 것이다. SpaceX 팀은 충돌해서 문제를 찾는 것이 위험이 없을 때까지 영원히 기다리려고 하는 것보다 훨씬 저렴하다고 말했다.

1.2 디지털 전환: 목표가 무엇인가?

마이크로소프트 오피스가 처음부터 노동자 생산성 혁신으로 간주되었는지 여부와 관계없이, 그것은 확실히 그 시장에서 가장 성공적인 제품군이었다. Office 365로 마이크로소프트는 워드 프로세서와 스프레드시트를 재발명할 필요가 없었다. 그러나 새로운 전달 메커니즘과 전체 팀이 협업할 수 있는 기능 등을 추가했다. 마이크로소프트는 디지털 전환을 통한 혁신으로 다시 승리했는가?

디지털 전환은 비즈니스 혁신가의 눈에 달려 있다. 일반적으로 기업들은 전환의 혁신 부분을 놓친다. 변혁적 혁신은 비즈니스가 인프라 플랫폼을 변경하는 것과 새로운 제품 가치를 구축하는 것의 차이를 이해해야 한다. 예를 들어, 비즈니스 디지털 자산을 온프레미스 데이터센터에서 클라우드로 가져가는 것은 중요한 IT 이니셔티브일 수 있지만, 그 자체로는 혁신에 있어 비즈니스 이니셔티브가 아니다.

소프트웨어를 클라우드로 마이그레이션하는 것이 디지털 전환으로 자격이 있는가? 아마도 그렇지만, 그 이동이 미래의 차별화를 지원한다면 더욱 그렇다. 클라우드가 혁신할 새로운 기회를 제공하거나, 최소한 디지털 자산 운영의 극도로 높은 비용을 완화하고 그 자금을 새로운 제품으로 전환한다면 가장 잘 자격이 된다. 클라우드를 대부분의 전통적인 데이터센터 책임에서 해방시켜주는 기회를 창출하는 것으로 생각하라.

그러나 클라우드로의 전환이 한 세트의 비용을 다른 세트의 비용과 교환하는 것에 불과하다면 변혁적이지 않을 것이다. 이미 성공적인 컴퓨팅 인프라를 외부 세계에 제공하는 아마존의 경우, 클라우드 혁신으로 이어진 회사의 디지털 전환이었다. 아마존 클라우드를 사용하기 위해 구독료를 지불하는 것은 가입자에게 변혁적 혁신이 아니다. 교훈은 명확하다: 혁신하거나 혁신당하라.

클라우드로 마이그레이션하는 것이 혁신이 아닌 것처럼, 새로운 분산 컴퓨팅 아키텍처를 만드는 것도 혁신이 아니다. 사용자들은 분산 컴퓨팅, 마이크로서비스, 모놀리스, 또는 심지어 기능에 대해 신경 쓰지 않는다. 사용자들은 결과에 관심을 둔다. 개선된 사용자 결과는 워크플로우에 부정적인 영향을 주지 않으면서 빠르게 필요하다. 소프트웨어가 의미 있는 변환의 기회를 갖기 위해서는, 그 아키텍처와 설계가 가능한 한 빠르게 더 나은 사용자 결과의 전달을 지원해야 한다.

1.3 실패 사례로 돌아가기: “넷플릭스처럼”의 함정

2025년 12월의 실패 사례로 돌아가 보자. Rails 모놀리스로 완벽하게 작동하던 스타트업이 왜 갑자기 마이크로서비스로 전환하려 했는가? 답은 명확하다: 비즈니스 목표가 아니라 기술적 유행을 따랐기 때문이다.

그들의 실제 비즈니스 목표는 무엇이었는가?

일일 활성 사용자 5만 명 서비스 (달성 중)
월 40% 매출 성장 (달성 중)
새로운 기능을 빠르게 출시 (주 단위로 달성 중)
버그를 신속하게 수정 (시간 단위로 달성 중)

그들에게 필요했던 것은 무엇인가? 아무것도 바꿀 필요가 없었다. 하지만 “확장성”이라는 추상적인 미래의 문제를 위해, 현재 완벽하게 작동하는 시스템을 해체했다. 이것이 바로 책이 경고하는 “목적 없는 아키텍처”다.

책의 저자들이 강조하듯이: “복잡도가 A에서 Z에 도달하는 것이 아무리 복잡하더라도, A에서 시작할 때 B에 도착하기 위한 실험의 과학을 수행하는 것이 현실적인 기대다. 그 후 C에 도달할 수 있으며, 이는 D로 이어진다. 실험실 코트와 주머니 보호대를 계속 착용하고, 새로운 시장을 포착할 수 있는 독특한 제품이 항상 우리 앞에 있을 가능성이 있다는 것을 인정하면서 이러한 단계 중 어느 것에서든 반복할 의지를 가져라.”

A에서 J로 가기 전에 K에 도달하기 위해 G로 돌아가는 것은 예상되며, Z가 결코 일어나지 않을 필요가 있다는 것은 해방적이다. 팀은 혁신할 수 있지만, 이러한 변혁적 단계 중 어느 것도 긴 주기를 용납할 수 없다.

2장: 소프트웨어는 왜 잘못되는가 - Big Ball of Mud의 해부

2.1 엔터프라이즈 소프트웨어의 참담한 현실

우리는 엔터프라이즈 소프트웨어 개발의 열악한 상태의 심각성을 과장하고 싶지 않으며, 과장될 수 있다고 생각하지도 않는다.

Fortune지와 글로벌 기업들과 엔터프라이즈 소프트웨어 시스템 상태에 대해 논의할 때, 우리는 빠르게 그들의 주요 문제점에 대해 알게 된다. 이것들은 항상 혁신이 일어난 후 수십 년 동안 유지보수를 거친 노화된 소프트웨어와 관련이 있다. 대부분의 논의는 소프트웨어 개발이 비즈니스에 대한 비용 센터로 간주된다는 것을 식별하며, 이는 개선에 투자하는 것을 훨씬 더 어렵게 만든다.

그러나 오늘날 소프트웨어는 이익 센터여야 한다. 불행히도 집단적 기업 마인드셋은 소프트웨어가 수동 노동보다 일부 작업을 더 빠르게 작동하도록 만들어졌던 30년 이상 전에 갇혀 있다.

특정 애플리케이션(또는 하위 시스템)은 구축되어야 할 핵심 비즈니스 이유로 시작한다. 시간이 지나면서, 그 핵심 목적은 향상되거나 심지어 상당히 변경될 것이다. 기능의 지속적인 추가는 애플리케이션의 원래 목적이 상실되고 다른 비즈니스 기능에 대해 다른 것을 의미할 가능성이 있으며, 그러한 이해의 전체 다양성이 쉽게 알려지지 않는 정도로 광범위해질 수 있다.

이것은 종종 냄비를 휘젓는 많은 손으로 이어진다. 결국 긴급한 개발은 전략에서 소프트웨어를 계속 실행하도록 유지하는 것으로 전환되는데, 긴급한 버그를 수정하고 실패를 보상하기 위해 데이터베이스에 직접 데이터를 패치한다. 새로운 기능은 일반적으로 더 많은 버그를 생산하지 않으려는 시도로 천천히 그리고 조심스럽게 추가된다. 그럼에도 불구하고 새로운 버그를 주입하는 것은 불가피하다. 시스템 무질서와 역사적 관점 상실의 지속적으로 증가하는 수준으로, 주어진 단일 변경이 더 큰 소프트웨어 본체에 미칠 전체 영향을 결정하는 것은 불가능하다.

2.2 Big Ball of Mud: Unarchitecture의 정의

아키텍처 측면에서 명확하고 의도적인 표현이 없는 애플리케이션이나 시스템은 Big Ball of Mud로 알려지게 되었다. 그것은 다음과 같이 더 설명되었다: 우연히 구조화됨; 퍼짐; 엉성함; 덕트 테이프로 연결되고 철사로 묶임; 정글; 규제되지 않은 성장; 반복되고 신속한 수리. “정보는 시스템의 먼 요소들 사이에서 무분별하게 공유되며, 종종 거의 모든 중요한 정보가 전역이 되거나 복제되는 지점까지 이른다. 시스템의 전체 구조는 결코 잘 정의되지 않았을 수 있다. 만약 그랬다면, 인식할 수 없을 정도로 침식되었을 수 있다.”

Big Ball of Mud “아키텍처”를 unarchitecture로 설명하는 것이 적절해 보인다.

이러한 혼란스러운 상태는 연간 몇 번의 소프트웨어 릴리스 이상을 방해하며, 이는 이전 연도의 소프트웨어 릴리스보다 훨씬 더 나쁜 문제를 야기한다. 개인과 그들이 속한 팀은 필요하다고 보는 변화를 일으키기 위해 사물을 바꿀 수 없다는 것을 알기에 무관심하고 자기만족적이 되는 경향이 있다. 그 다음 단계는 환멸을 느끼고 사기가 저하되는 것이다. 이러한 상황에 직면한 비즈니스는 소프트웨어에서 혁신하고 그러한 조건 하에서 계속 경쟁할 수 없다.

2.3 실패 사례의 Big Ball of Mud

2025년 12월 사례의 스타트업은 흥미롭게도 마이크로서비스를 도입하면서 새로운 형태의 Big Ball of Mud를 만들었다. 6개월 후 그들이 직면한 것은:

분산된 Big Ball of Mud:

6개의 서비스, 6개의 리포지토리, 6개의 데이터베이스
비즈니스 액티비티가 얽힌 소프트웨어 컴포넌트들
깊은 부채와 최대에 가까운 엔트로피
결제, 재고, 주문이 모두 서로 엉켜 있음

이것이 바로 책에서 경고하는 것이다. “마이크로서비스 아키텍처와 쿠버네티스 같은 도구들이 적절한 컨텍스트에서 제대로 적용되지만, 불행하게도 그러한 채택은 비즈니스 필요에 대한 통찰력보다는 자격 없는 채택에 의해 드문하게 주도된다.”

2.4 기술 부채 (Technical Debt Metaphor)

수십 년 전, 매우 영리한 소프트웨어 개발자인 Ward Cunningham은 당시 금융 소프트웨어를 작업하고 있었는데, 현재 소프트웨어 변경에 대한 노력이 왜 필요한지 상사에게 설명해야 했다. 변경되고 있는 사항은 어떤 식으로도 임시적이지 않았다; 사실 그것들은 정반대였다. 변경의 종류는 소프트웨어 개발자들이 자신들이 하고 있는 일을 알고 있는 것처럼 보이도록 할 것이며, 하기 쉽게 만들도록 봉사했다. 그들이 사용한 특정 기술은 이제 소프트웨어 리팩토링으로 알려져 있다. 이 경우 리팩토링은 의도된 방식으로 수행되었다 - 즉, 비즈니스 지식의 새로운 습득을 소프트웨어 모델에 반영하기 위해.

이 작업을 정당화하기 위해, Cunningham은 팀이 비즈니스 요구 사항에 대한 증가된 학습과 일치하도록 소프트웨어를 조정하지 않으면, 소프트웨어가 존재했던 것과 현재의 정제된 이해 사이의 불일치로 인해 계속 비틀거릴 것이라고 설명해야 했다. 차례로 계속되는 비틀거림은 지속적인 개발에 대한 팀의 진행을 늦출 것이며, 이는 대출에 대한 이자를 지불하는 것과 같다. 따라서 부채 메타포가 탄생했다.

누구나 돈을 빌려 그들이 돈을 얻지 못했다면 더 빨리 일을 할 수 있게 할 수 있다. 물론 대출이 존재하는 한, 차용자는 이자를 지불할 것이다. 소프트웨어에서 부채를 지는 주요 아이디어는 더 빨리 릴리스할 수 있지만, 나중보다는 더 빨리 부채를 갚아야 한다는 아이디어와 함께 릴리스하는 것이다. 부채는 팀이 새로 습득한 비즈니스 요구 사항에 대한 지식을 반영하도록 소프트웨어를 리팩토링함으로써 지불된다.

부채 메타포에 대한 현대의 이해의 주요 문제 중 하나는 많은 개발자들이 이 메타포가 의도적으로 설계가 불량하고 구현된 소프트웨어를 제공하여 더 빨리 제공하는 것을 지원한다고 생각한다는 것이다. 그러나 메타포는 그러한 관행을 지원하지 않는다. 그 묘기를 시도하는 것은 상환 가능한 조정 가능한 상향 금리를 가진 서브프라임 대출에서 차용하는 것과 더 유사하며, 이는 종종 차용자가 재정적으로 과도하게 연장되어 채무 불이행에 이르게 한다. 부채는 제어되는 한에만 유용하다; 그렇지 않으면 전체 시스템 내에서 불안정성을 만든다.

실패 사례에서의 부채: 원래 스타트업의 자동 보험 애플리케이션은 빠르게 구축되었지만 압박 하에, 빠르게 Big Ball of Mud 모놀리스로 이어졌다. 20년 이상의 변경과 깊은 미지불 부채로 인해, 개인 보험 라인을 위한 시스템의 지속적인 개발과 함께, 팀은 계획되지 않은 복잡성의 질식 지점에 도달했다. 기존 소프트웨어는 현재 비즈니스 목표를 절대적으로 지원하지 않을 것이다. 모두 동일하게, 개발은 부름에 응답해야 한다.

2.5 소프트웨어 엔트로피 (Software Entropy)

소프트웨어 엔트로피는 부채 메타포와 밀접하게 관련된 다른 메타포지만, 그것이 설명하는 소프트웨어 시스템 상태 측면에서 다르다. 엔트로피라는 단어는 통계 역학 분야에서 시스템의 무질서를 측정하는 데 사용된다. 이 주제에 너무 깊이 들어가려고 시도하지 않고: “열역학 제2법칙은 고립된 시스템의 엔트로피는 시간이 지남에 따라 절대 감소하지 않는다고 말한다. 고립된 시스템은 자발적으로 열역학적 평형, 즉 최대 엔트로피를 가진 상태로 진화한다.”

소프트웨어 엔트로피 메타포는 변화가 불가피한 소프트웨어 시스템의 상태를 명명하며, 그 변화는 강력한 노력이 그것을 방지하기 위해 이루어지지 않는 한 증가하는 제어되지 않은 복잡성을 초래할 것이다.

엔트로피 외에 다른 유사어들도 문제에 대한 생생한 그림을 그린다: 소프트웨어 부패, 소프트웨어 침식, 소프트웨어 부식, 소프트웨어 붕괴. 저자들은 주로 엔트로피를 사용한다.

소프트웨어 시스템 내에서 변화가 불가피하고, 그 변화가 강력한 노력이 그것을 방지하기 위해 이루어지지 않는 한 증가하는 제어되지 않은 복잡성을 초래할 것이라는 조건을 소프트웨어 엔트로피 메타포는 명명한다.

실패 사례에서의 엔트로피: 마이크로서비스를 도입한 6개월 동안, 엔트로피는 기하급수적으로 증가했다:

한 서비스의 메모리 누수가 전체 시스템 연쇄 장애를 유발
서비스 간 의존성이 얽히면서 배포 조율이 불가능해짐
간단한 필드 하나 추가하는데 6개 서비스를 수정해야 함
개발자들이 시스템의 전체 그림을 잃어버림

3장: Conway’s Law - 조직이 시스템을 결정한다

3.1 피할 수 없는 현실

1967년, 우리 은하계에서 멀지 않은 곳(우리 자신)에서, 또 다른 정말 영리한 소프트웨어 개발자 Mel Conway가 시스템 개발의 피할 수 없는 현실을 제시했다. 그것은 너무나 피할 수 없어서 법칙으로 알려지게 되었다. 정말 영리한 개발자는 Mel Conway이고, 피할 수 없는 현실은 Conway’s Law로 알려져 있다.

Conway’s Law: “시스템을 설계하는 조직은 이러한 조직의 커뮤니케이션 구조의 사본인 설계를 생산하도록 제한된다.”

앞서 설명한 Big Ball of Mud와의 상관관계는 상당히 명백하다. 일반적으로 “우연히 구조화됨; 규제되지 않은 성장; 반복되고 신속한 수리”를 야기하는 것은 깨진 커뮤니케이션이다.

여전히 거의 항상 누락되는 또 다른 큰 커뮤니케이션 구성 요소가 있다: 비즈니스 이해관계자와 기술 이해관계자가 깊은 학습으로 이어지는 생산적인 커뮤니케이션을 갖는 것이며, 이는 차례로 혁신으로 이어진다.

주장: 좋은 소프트웨어를 구축하여 혁신하고자 하는 사람들은 다른 것을 시도하기 전에 이 커뮤니케이션-학습-혁신 경로를 올바르게 해야 한다.

3.2 커뮤니케이션은 지식에 관한 것이다

지식은 모든 회사에서 가장 중요한 자산이다. 조직은 모든 것에 뛰어날 수 없으므로 핵심 역량을 선택해야 한다. 회사가 전문 분야 내에서 습득하는 특정 지식은 경쟁 우위를 구축할 수 있게 한다.

회사의 지식은 문서화, 모델, 소스 코드 구현을 통한 알고리즘과 같은 물리적 아티팩트로 구체화될 수 있지만, 이것들은 노동자들의 집단 지식과 비교할 수 없다. 지식의 더 큰 부분은 개인의 마음에 의해 운반된다. 외부화되지 않은 지식은 암묵적 지식(tacit knowledge)으로 알려져 있다. 그것은 비즈니스 내 기록되지 않은 절차의 루틴과 같이 집단적일 수 있거나, 모든 개인이 소유한 작업의 선호하는 개인적 방식일 수 있다. 개인적 지식은 기술과 공예에 관한 것이다 - 회사가 설립된 이래 수집한 문서화되지 않은 무역 비밀과 역사적이고 맥락적인 지식.

조직 내 사람들은 효과적인 커뮤니케이션을 통해 지식을 교환한다. 그들의 커뮤니케이션이 더 나을수록, 회사의 지식 공유가 더 나아질 것이다. 그러나 지식은 물리적 객체가 교환되는 것과 같은 방식으로 한 사람에서 다른 사람으로 전달되는 것이 아니기 때문에, 지식 전달은 sense-giving(의미 부여)과 sense-reading(의미 읽기)의 조합으로 일어난다.

의미 부여는 사람이 지식을 전달할 때 발생한다. 지식은 정보로 구조화되고 외부화된다. 수신 측에 있는 사람은 의미 읽기 과정을 거친다. 이 개인은 수신한 정보에서 데이터를 추출하여 개인적 지식을 만들고 내재화한다.

두 사람이 동일한 정보에 동일한 의미를 부여할 확률은 발생한 커뮤니케이션의 정확성뿐만 아니라 과거 경험과 수신자가 그것을 배치하는 특정 맥락에 의해서도 결정된다.

3.3 전화 게임 (The Telephone Game)

전화 게임은 특정 커뮤니케이션 구조의 문제를 설명한다. 사람들이 줄을 형성하고, 줄의 한쪽 끝에서 한 사람이 줄의 다음 사람에게 메시지를 속삭이고, 이것은 다음 사람에게 반복되며, 메시지가 줄의 마지막 사람에게 도달할 때까지 계속된다. 마지막으로 마지막 메시지 수신자는 모든 사람에게 그들이 받은 메시지를 말하고, 줄의 시작에 있는 사람은 원래 메시지를 공개한다. 물론, 재미는 끝에 도달할 때까지 메시지가 심하게 왜곡되는 반복된 메시지에서 나온다.

이 게임과 커뮤니케이션에 미치는 영향에서 가장 흥미로운 것은 왜곡이 모든 별도의 커뮤니케이션 지점에서 발생한다는 것이다. 메시지의 출처에 가장 가까운 사람들조차도 정확하게 반복할 수 없는 것을 들을 것이다. 릴레이 지점이 많을수록 메시지는 더 왜곡된다.

본질적으로, 릴레이된 커뮤니케이션의 모든 지점은 새로운 번역을 만든다. 이것은 단지 두 사람 사이의 커뮤니케이션도 어렵다는 현실을 강조한다. 명확성과 합의에 도달하는 것은 불가능하지 않지만, 거기에 도달하는 것은 도전적일 수 있다.

비즈니스에서 이것이 발생할 때, 그것은 게임이 아니며 재미있지 않다. 물론 메시지가 복잡할수록, 부정확성이 발생할 가능성이 더 크다. 매우 큰 조직에서는 20개 이상의 레벨이 있을 수 있다. 저자들은 계층의 너무 많은 것이 조직에서 어떤 정도의 정확성으로 달성되는 것이 극복할 수 없을 정도로 어려워 보이며, 소프트웨어 개발자들이 라인 끝에서 그것에 놀란다는 이야기를 자주 듣는다.

3.4 합의에 도달하기는 어렵다

팀 구성원의 부정적인 감정, 즉 무관심, 자기만족, 환멸, 사기 저하는 극복될 수 있다. 그것은 팀이 도달 가능한 목표를 만들고 새롭고 가벼운 기술을 제공함으로써 이루어진다. 예를 들어 더 나은 커뮤니케이션을 위해 팀을 형성하고, 소프트웨어의 단계별 가치 주도 재구조화에 참여하는 것과 같은 것들이다.

그러나 커뮤니케이션 지점 사이의 분리와 계층의 각 레벨에서의 커뮤니케이션 스타일조차도 비즈니스와 기술 이해관계자 사이에 넓은 격차를 야기할 수 있다. 큰 변화에 직면하여 커뮤니케이션 격차가 넓을 때, 합의를 달성하기는 어렵다.

해로운 문제는 기술 리더십이 자신과 팀을 비판에 위협받는 것으로 보고 큰 변화가 임박했다는 힌트가 있을 때 존재한다. 결국, 들리는 왜곡된 메시지는 오랫동안 존재해온 것이 지속 가능하지 않다고 암시한다. 역사를 통틀어 여러 번 언급되었듯이, 인간은 자아를 가지고 있으며 종종 힘든 노력의 결과로 그들이 생산한 것에 크게 투자되어 있다. 이러한 강한 애착은 종종 “결혼했다”고 불린다. 결혼만큼 긴밀하게 연결된 제도가 깨질 수 있어 보일 때, 관련된 당사자들은 종종 방어적 자세를 취한다.

3.5 실패 사례에서의 Conway’s Law

2025년 12월 사례의 핵심 문제는 기술적인 것이 아니었다. 조직적인 것이었다.

팀 구조:

4명의 백엔드 개발자
2명의 프론트엔드 개발자
1명의 데브옵스 엔지니어
1명의 아키텍트 (코드를 작성하지 않음)

그들이 만든 아키텍처:

6개의 마이크로서비스
서로 깊이 의존적
조율이 필요한 배포
복잡한 분산 시스템

Conway’s Law가 예측하는 것: 7-8명의 팀은 긴밀하게 통합된 시스템을 만들 것이다. 그들이 만든 “마이크로서비스”는 실제로는 네트워크로 분산된 모놀리스였다.

해커뉴스 댓글이 지적했듯이: “4명 팀에 아키텍트? 이것 자체가 이미 문제의 시작이다. 코드를 작성하지 않는 아키텍트가 규칙과 패턴을 정하는 것은 거의 항상 최악이다.”

진짜 문제: 마이크로서비스가 아니라, 결정권은 있지만 책임은 없는 역할 설계였다.

4장: 최적의 커뮤니케이션 - 팀 플레이의 결과

4.1 팀으로 행동하는 것은 팀이 되는 것을 요구한다

협력적 변화는 리더십에서 나와야 하며, 임원 레벨에서 시작된다. 임원 리더십이 계층적 명령과 통제의 지속 불가능한 결과를 볼 수 있을 때, 답은 오래된 통제된 것을 새롭게 통제된 것으로 대체하는 것이 아니다.

모든 노력에서 팀은 개인보다 대규모 사업에서 훨씬 더 성공적이다. 성숙한 스포츠 팀은 혁신적인 플레이북을 만들고 각 플레이를 지루한 정밀도로 전체 팀에 전달함으로써 성공한다.

팀처럼 행동하는 것은 팀이 되는 것을 요구한다. 팀에서는 커뮤니케이션이 일방적이지 않다. 어떤 한 팀 구성원이라도 플레이북에서 뭔가 간과되었거나, 주어진 플레이가 이것 또는 추가 이동의 제거 또는 비효율성의 제거로 더 나아질 수 있다고 제안할 만큼 충분한 경험을 가질 수 있다. 모든 팀 구성원이 그들의 역량과 경험 있는 관점에 대해 존중받을 때, 그것은 그 커뮤니케이션을 훨씬 더 효과적으로 만드는 데 기여한다.

4.2 최적의 커뮤니케이션을 위한 핵심

다음 핵심들을 최적의 커뮤니케이션을 위해 고려하라:

• 우리 대 그들이 아니라, 그냥 우리다. 계층은 “우리 대 그들” 사고방식을 낳는다. 명령이 높은 곳에서 내려오고 부하직원들이 명령을 수행한다. 이 계층이 유지된다면, 임원들은 협력적 변화로 이어지는 결과를 기대해서는 안 된다.

• 종속 리더십은 누구 아래에도 있어서는 안 된다. 모든 사람이 그들의 역량과 경험에 대해 존중받아야 한다.

• 전략적 조직 구조를 구축하는 힘을 깨닫라. 조직은 커뮤니케이션의 필요에 따라 구조화되어야 한다.

• 누구도 그들의 건설적인 관점을 전달하는 것에 대해 위협을 느껴서는 안 된다. 안전한 환경이 혁신을 낳는다.

• 긍정적 영향력은 사람들을 건설적인 행동으로 동기부여하는 데 결정적이다. 명령과 통제가 아닌, 영향력과 동기부여.

• 비즈니스-기술 파트너십을 형성하는 것은 상호 존중에 기반하여 필수적이다. 기술과 비즈니스는 적이 아니다.

• 깊은 커뮤니케이션, 비판적 사고, 그리고 협력은 파괴적이고 변혁적인 소프트웨어 시스템을 달성하는 데 필수불가결하다.

이러한 전략적 행동 패턴은 새롭고 참신한 것이 아니다. 그것들은 수세기 동안 존재해왔으며 성공적인 조직의 관행이다.

Conway’s Law는 조직 커뮤니케이션 구조를 더 큰 이익을 위해 작동하도록 하는 방법에 대해 누구도 추측하게 하지 않는다. Conway의 논문의 결론이 말하듯이:

“우리는 설계 조직의 구조화를 위한 기준을 찾았다: 설계 노력은 커뮤니케이션의 필요에 따라 조직되어야 한다.
처음 발생하는 설계가 거의 최선의 가능한 솔루션이 아니기 때문에, 지배적인 시스템 개념은 변경이 필요할 수 있다. 따라서, 조직의 유연성은 효과적인 설계에 중요하다.
설계 관리자들이 그들의 조직을 날씬하고 유연하게 유지하는 것에 대해 보상하는 방법을 찾아야 한다.”

5장: 전략적 사고와 재사고 - 아키텍처 결정 이전에

5.1 사고 (Thinking)

Bernard Shaw는 사고에 관해 이렇게 말했다:

“나는 사람들이 거의 생각하지 않는다고 생각한다. 소수의 사람들이 1년에 두세 번 이상 생각한다. 나는 일주일에 한두 번 생각함으로써 국제적 명성을 얻었다.”

물론 우리는 모두 매일 생각한다. 삶은 사고 없이는 불가능할 것이다. 그러나 Shaw의 재미있는 진술은 사람들에 대한 흥미로운 사실을 일반적으로 폭로한다. 삶의 많은 부분이 일상적인 기능으로 수행되며 정기적으로 일종의 자동 조종 장치를 사용한다. 사람들이 세부 사항에 대해 생각해야 할 필요가 적을수록, 그들이 하는 일에 대해 의식적으로 생각하는 경향이 적어질 것이다. 이것이 나이든 사람들이 후년에 정신적으로 참여하지 않으면 인지력을 잃는 경향이 있는 이유다. Shaw는 대부분의 저명한 사상가들 사이에서도 깊은 사고가 그렇게 자주 일어나지 않을 수 있음을 보여준다. 정당하게, 깊은 사고의 부족은 지식 노동자들 사이에서도 우려 사항이다.

지식 노동자들이 자동 조종 장치로 가는 문제는 소프트웨어가 실수에 대한 관용이 거의 없다는 것이다. 특히 오랜 기간 동안 해결되지 않은 채로 남겨진 실수들이 그렇다. 개별 소프트웨어 개발자들이 조심하지 않으면, 그들은 소프트웨어에서 부채를 지불하는 데 게으르고 규제되지 않은 성장과 반복되고 신속한 수리의 모드로 전환될 것이다.

개발자들이 자기만족해질 수 있다는 우려도 있다. 제품 회사들이 그들에게 팔고자 하는 것에 점점 더 의존하기 시작하는 것보다는 비즈니스 초점의 맥락에서 스스로 생각하는 것이다. 새로운 기술 버즈와 과대광고는 내부 비즈니스 채널에서 가능한 것보다 훨씬 더 자주 외부에서 펌핑된다. 그러나 끊임없는 북소리는 로컬에서 가장 중요한 것의 맥락을 놓치고 있다. 자기만족해진 개발자들은 문제를 해결하기 위해 기술을 원할 수 있다. 다른 사람들은 단순히 마음을 사로잡기 위해 새로운 장난감을 갈망할 것이다. 마찬가지로, Fear of Missing Out(FOMO)을 주도하는 역학은 깊고 비판적인 사고에 의해 주도되지 않는다.

5.2 생각해야 할 것들 (What Are We Doing?)

시스템 사양에 관련된 모든 것에 대해 많이 생각하는 것이 적절한 비즈니스 결정을 내리고, 나중에 필요한 지원 기술 결정을 내리는 데 필수적이다. 다음은 몇 가지 동기 체커들이다:

• 우리는 무엇을 하고 있는가? 아마도 마감일을 맞추기 위한 수단으로 품질이 낮은 소프트웨어가 출시되고 있을 것이다. 이것은 팀을 나중에 리팩토링하기에 좋은 위치에 두지 않으며, 리팩토링이 계획되지 않을 가능성이 크다. 팀이 해결책으로 더 새롭고 인기 있는 아키텍처를 사용하여 대규모 재구현을 추진하고 있을 가능성이 있다. 관련된 사람들이 이미 기존 시스템에 유용한 아키텍처를 도입하는 데 실패했거나 이미 그곳에 있던 아키텍처를 유지하는 데 실수를 한 사실을 간과하지 마라.

• 우리는 왜 이것을 하고 있는가? 제품을 해결책으로 판매하는 것에 기반한 외부 메시지는 기존 소프트웨어가 운영 가능하게 유지하기 위해 단순히 유지하면서 존재 이유를 잃은 대신 합리적인 단계를 밟아 보강하는 것보다 더 매력적으로 들릴 수 있다. FOMO와 이력서 주도 개발이 좋은 개발 기술을 실천하는 것보다 더 강한 동기가 될 수 있다. 특정 아키텍처나 기술이 실제 비즈니스와 기술적 요구에 의해 정당화되는지 확인하라.

• 모든 것에 대해 생각하라. 시스템 사양에 관련된 모든 것에 대해 많이 생각하는 것은 적절한 비즈니스 결정을 내리고, 나중에 필요한 지원 기술 결정을 내리는 데 필수적이다. 모든 단일 학습은 비판적 사고로, 찬성과 반대 모두를 위해 검토되어야 한다. 강한 의견을 가지고 가장 크게 말하는 것은 아무것도 증명하지 않는다. 정보에 입각하여, 명확하게, 광범위하게, 깊이 있게, 그리고 비판적으로 생각하는 것은 모두 극도로 중요하다. 이것들은 깊은 학습으로 이어질 수 있다.

5.3 실패 사례에서의 사고 부재

2025년 12월 사례에서 가장 뼈아픈 부분은 깊은 사고의 부재였다.

제기되지 않은 질문들:

우리의 실제 문제는 무엇인가? (답: 없었다)
모놀리스가 정말 병목인가? (답: 아니었다)
우리 팀 크기에 마이크로서비스가 적절한가? (답: 전혀)
분산 시스템의 복잡성을 감당할 수 있는가? (답: 없었다)
이것이 비즈니스 목표를 달성하는가? (답: 오히려 방해했다)

대신 무엇이 있었는가:

“넷플릭스가 한다” (Cargo cult programming)
“확장성” (필요하지 않은 미래를 위한)
“현대적” (트렌드를 위한 트렌드)
“아키텍트의 이력서” (개인적 동기)

이것이 바로 책이 경고하는 것이다: “FOMO와 CV-driven development가 좋은 개발 기술을 실천하는 것보다 더 강한 동기가 될 수 있다.”

6장: NuCoverage Insurance 사례 연구 - Big Ball of Mud에서 벗어나기

6.1 사례 소개

책은 허구의 보험 회사 NuCoverage Insurance를 통해 실제 세계의 Big Ball of Mud 상황과 그것을 어떻게 해결할 수 있는지를 보여준다. 이 사례는 2025년 12월 실패 사례와 흥미로운 대조를 이룬다.

NuCoverage의 상황:

2001년 설립, 미국 저비용 자동차 보험 시장의 리더
안전 운전자들에게 저비용 보험료 제공에 집중
거의 20년 후, 미국 전체 시장의 23%를 보험하지만, 특화된 저비용 안전 운전자 시장의 거의 70% 차지
최근 주택 보험을 추가했고 개인 보험 라인 추가 작업 중
하지만: 새로운 보험 제품 추가가 원래 예상보다 더 복잡해짐

현재 비즈니스 맥락: NuCoverage는 자동차 보험의 리더이지만, 다른 종류의 보험 제품으로 비즈니스를 확장하고 싶어한다. 회사는 최근 주택 보험을 추가했고 개인 보험 라인 추가 작업 중이다. 그러나 새로운 보험 제품 추가는 원래 예상보다 더 복잡해졌다.

개인 보험 라인 개발 프로세스가 진행 중인 동안, 경영진은 가장 큰 미국 은행 중 하나인 WellBank와 파트너십을 맺을 기회를 가졌다. 거래는 WellBank가 자체 브랜드 하에 자동차 보험을 판매할 수 있게 하는 것이다. WellBank는 익숙한 자동차 대출과 함께 자동차 보험을 판매하는 데 큰 잠재력을 본다. WellBank 자동차 보험 정책 뒤에는 NuCoverage가 있다.

물론 NuCoverage 자동차 보험 제품과 WellBank에 판매될 제품 사이에는 차이가 있다. 가장 두드러진 차이는 다음 영역과 관련이 있다:

보험료와 커버리지
규칙과 보험료 가격 계산
위험 평가

6.2 비즈니스 기회

NuCoverage의 이사회와 임원들은 WellBank 파트너십보다 훨씬 더 큰 전략적 기회를 인식했다: 그들은 어떤 수의 신생 보험사들을 지원하는 white-label 보험 플랫폼을 도입할 수 있었다. 많은 유형의 비즈니스가 비즈니스 자체 브랜드 하에 보험 제품을 판매하는 것을 잠재적으로 지원할 수 있다. 각 비즈니스는 고객을 가장 잘 알고 어떤 보험 제품이 제공될 수 있는지 파악한다. 최근 체결된 WellBank 파트너십은 단지 한 예다. NuCoverage는 확실히 비전을 공유하는 다른 전향적 사고 파트너들을 식별할 수 있다.

예를 들어, NuCoverage는 자체 금융을 제공하는 자동차 제조업체와 파트너십을 확립할 수 있다. 고객이 자동차를 구매할 때, 딜러는 금융과 제조업체 브랜드 보험 모두를 제공할 수 있다. 가능성은 무한하다. 왜냐하면 어떤 무작위 회사도 쉽게 보험 회사가 될 수 없지만, 보험 판매를 통해 얻은 마진에서 여전히 이익을 얻을 수 있기 때문이다. 장기적으로, NuCoverage는 오토바이, 요트, 심지어 애완동물 보험과 같은 새로운 보험 제품으로 다각화하는 것을 고려했다.

이 가능성은 이사회와 임원들에게 매우 흥미로워 보이지만, 소프트웨어 관리 팀이 계획에 대해 알게 되었을 때, 몇몇은 힘들게 삼켜야 했다.

6.3 Big Ball of Mud의 현실

원래 자동차 보험 애플리케이션은 전달 압박 하에 빠르게 구축되었고, 빠르게 Big Ball of Mud 모놀리스로 이어졌다. 20년 이상의 변경과 깊은 미지불 부채, 그리고 개인 보험 라인을 위한 시스템의 지속적인 개발과 함께, 팀은 계획되지 않은 복잡성의 질식 지점에 도달했다.

기존 소프트웨어는 현재 비즈니스 목표를 절대적으로 지원하지 않을 것이다. 모두 동일하게, 개발은 부름에 응답해야 한다.

NuCoverage가 이해해야 하는 것은 그들의 비즈니스가 더 이상 보험만이 아니라는 것이다. 그것은 항상 제품 회사였지만, 그 제품은 보험 정책이었다. 디지털 전환이 회사를 기술 회사가 되도록 이끌고 있으며, 이제 그 제품에는 소프트웨어가 포함된다. 그 목표를 위해, NuCoverage는 기술 제품 회사처럼 생각하고 그 위치를 지원하는 결정을 내리기 시작해야 한다 - 단지 빠른 패치가 아니라 장기적으로. 이것은 회사 마인드셋의 매우 중요한 변화다. NuCoverage의 디지털 전환은 기술 선택만으로 성공적일 수 없다. 회사 임원들은 조직 구성원들의 마인드셋을 변경하는 데 집중해야 할 것이며, 디지털 도구를 사용하고 사용 방법을 결정하기 전에 조직 문화와 프로세스도 변경해야 한다.

이것이 2025년 12월 실패 사례와의 핵심 차이다. NuCoverage는:

실제 비즈니스 문제가 있었다 (Big Ball of Mud)
명확한 비즈니스 목표가 있었다 (white-label 플랫폼)
조직적 변화의 필요성을 인식했다
마인드셋과 문화부터 바꾸려 했다

반면 2025년 실패 사례는:

실제 비즈니스 문제가 없었다 (모놀리스는 잘 작동했다)
모호한 목표만 있었다 (“확장성”, “현대적”)
조직 구조를 무시했다 (4명에게 6개 서비스)
기술부터 시작했다 (마이크로서비스 먼저)

7장: 균형 잡힌 접근 - 2026년의 실용적 지혜

7.1 아키텍처는 목표가 아니라 도구다

반 버논과 토마스 야스쿨라가 강조하듯이, 아키텍처는 그 자체가 목표가 아니다. 아키텍처는 비즈니스 목표를 달성하기 위한 도구다. 이것이 2026년 1월 현재 우리가 도달한 성숙한 이해다.

좋은 아키텍처의 특징:

비즈니스 목표를 명확히 지원한다
- 사용자에게 가치를 더 빠르게 전달
- 실제 병목을 해결
- 팀 생산성 향상
팀의 현재 역량과 일치한다
- 10명 미만: 모놀리스
- 10-50명: 모듈러 모놀리스
- 50명 이상: 하이브리드 또는 마이크로서비스
조직 구조를 반영한다 (Conway’s Law)
- 커뮤니케이션 구조와 일치
- 팀 경계와 서비스 경계 정렬
- 자율성과 조율의 균형
변화를 수용할 수 있다
- 진화 가능한 설계
- 기술 부채 관리
- 엔트로피 방지 메커니즘

7.2 실패에서 배우는 교훈

2025년 12월 실패 사례의 교훈:

“넷플릭스처럼”은 전략이 아니다
- 넷플릭스는 모놀리스에서 시작했다
- 그들은 실제 문제를 해결하기 위해 진화했다
- 그들의 규모 ≠ 당신의 규모
복잡성은 복리로 증가하는 세금이다
- 각 서비스 = 추가 관리 부담
- N개 서비스 = N(N-1)/2개 통합
- 세금은 매일 지불된다
네트워크 호출은 공짜가 아니다
- 인프로세스: 나노초
- HTTP 호출: 밀리초
- 200ms → 800ms → 2초의 악순환
조직과 아키텍처는 일치해야 한다
- 4명 팀 ≠ 6개 마이크로서비스
- Conway’s Law는 피할 수 없다
- 깨진 커뮤니케이션 = Big Ball of Mud
기술 부채는 실재한다
- 부채는 통제되어야 한다
- 서브프라임 부채는 파산으로 이어진다
- 엔트로피는 지속적인 노력으로만 방지된다

7.3 성공의 원칙

책과 현실 사례에서 도출된 원칙:

비즈니스 목표부터 시작하라
- 기술이 아니라 가치 전달
- 실제 문제 해결
- 사용자 결과 개선
단순하게 시작하라
- 모놀리스 또는 모듈러 모놀리스
- 도메인을 이해할 시간 가지기
- 경계가 자연스럽게 드러날 때까지 기다리기
커뮤니케이션을 최적화하라
- 계층 축소
- 비즈니스-기술 파트너십
- 상호 존중과 학습
깊이 생각하라
- 모든 결정에 비판적 사고
- “왜?”를 물어라
- FOMO와 CV-driven development 피하기
점진적으로 진화하라
- A → B → C → D
- 각 단계에서 학습
- Z가 필요 없을 수도 있다
기술 부채와 엔트로피를 관리하라
- 지속적인 리팩토링
- 아키텍처 경계 강제
- 테스트와 모니터링

7.4 의사결정 프레임워크

새 프로젝트를 시작할 때:

비즈니스 목표를 명확히 하라
- 우리가 해결하려는 실제 문제는 무엇인가?
- 사용자에게 어떤 가치를 전달하는가?
- 성공을 어떻게 측정할 것인가?
팀과 조직을 평가하라
- 우리 팀은 몇 명인가?
- 커뮤니케이션 구조는 어떠한가?
- 어떤 역량과 경험을 가지고 있는가?
현재 상황을 이해하라
- 기존 시스템은 어떤 상태인가?
- 실제 병목은 무엇인가?
- 기술 부채는 얼마나 있는가?
가장 단순한 것부터 시작하라
- 모놀리스 또는 모듈러 모놀리스
- 명확한 모듈 경계
- 진화 가능한 설계
측정하고 학습하라
- 실제 메트릭 추적
- 정기적인 회고
- 필요시 조정

기존 시스템을 개선할 때:

먼저 최적화하라
- 데이터베이스 쿼리
- 캐싱 전략
- 수직 확장
모듈화하라
- 명확한 경계 정의
- 순환 의존성 제거
- 아키텍처 테스트
점진적으로 추출하라
- 실제 필요가 있을 때만
- 명확한 bounded contexts
- 하나씩, 검증하면서
하이브리드를 수용하라
- 핵심은 모놀리스
- 특정 부분만 서비스로
- 실용주의

7.5 2026년의 현실적 권장사항

소규모 팀 (10명 미만):

선택: 잘 구조화된 모놀리스
이유: 단순성, 속도, 낮은 운영 비용
도구: Package-by-feature, 명확한 레이어링
주의: Big Ball of Mud 방지, 지속적 리팩토링

성장 중인 팀 (10-50명):

선택: 모듈러 모놀리스
이유: 확장 가능하면서도 관리 가능
도구: Spring Modulith, 도메인 주도 설계
주의: 모듈 경계 엄격히 유지, 아키텍처 테스트

대규모 조직 (50명 이상):

선택: 하이브리드 접근
이유: 팀 자율성과 시스템 안정성 균형
도구: 모듈러 모놀리스 + 선택적 마이크로서비스
주의: 강력한 플랫폼 팀, 관측성, 거버넌스

7.6 마이크로서비스를 고려할 때

고려해야 할 경우:

50명 이상의 엔지니어가 서로 충돌
진정으로 독립적인 팀 배포 필요
극명하게 다른 확장 요구사항
전담 플랫폼/데브옵스 팀 보유
모놀리스 한계에 실제로 도달

하지 말아야 할 경우:

“확장을 위한 준비” - 아직 필요하지 않음
“넷플릭스가 한다” - 넷플릭스 ≠ 당신
아키텍트가 블로그를 읽었다 - 과대광고 주의
개발이 더 빠를 것 - 실제로는 더 느림
20명 미만의 엔지니어 - 너무 작음
이력서용 - 회사는 실험장이 아님

8부: 네트워크의 거짓말 - 분산 컴퓨팅의 8가지 오류

8.1 Peter Deutsch의 경고

1994년, Sun Microsystems의 Peter Deutsch는 분산 시스템을 설계할 때 사람들이 자주 범하는 잘못된 가정들을 정리했다. 이것은 나중에 “분산 컴퓨팅의 오류 (Fallacies of Distributed Computing)”로 알려지게 되었다. James Gosling을 포함한 다른 엔지니어들이 목록에 기여했고, 최종적으로 8가지 오류가 정리되었다.

2025년 실패 사례를 이해하는 렌즈로서, 이 8가지 오류를 살펴보자.

8.2 첫 번째 오류: 네트워크는 신뢰할 수 있다

거짓말: “HTTP 호출은 함수 호출과 같다”

현실: 네트워크는 실패한다. 항상, 예측할 수 없이.

2025년 스타트업의 월요일 재앙을 기억하는가? 한 서비스의 메모리 누수가 느려짐을 유발했고, 이것이 다른 서비스들의 타임아웃을 일으켰고, 재시도가 모든 것을 다운시켰다. 이것이 바로 첫 번째 오류의 실제 모습이다.

함수 호출 vs HTTP 호출:

// 모놀리스: 함수 호출
User user = userService.getUser(userId);
// 실패 가능성: 거의 없음
// 레이턴시: 나노초
// 처리: 동기적, 예측 가능

// 마이크로서비스: HTTP 호출
User user = userClient.getUser(userId);
// 실패 가능성:
//   - 네트워크 단절
//   - DNS 실패
//   - 서버 다운
//   - 타임아웃
//   - 느린 응답
//   - 직렬화 오류
// 레이턴시: 밀리초 (1,000,000배 느림)
// 처리: 비동기, 예외 처리 필수

실패 사례에서의 증상: Billing Service가 4개의 다른 서비스를 호출해야 했다. 4개 중 하나라도 실패하면? 전체 기능 실패. 4개 모두 성공해야 하는 확률이 각각 99.9%라고 해도, 전체 성공 확률은 99.6%로 떨어진다. 하루에 1000번 호출하면 4번 실패한다.

8.3 두 번째 오류: 레이턴시는 0이다

거짓말: “네트워크 호출은 빠르다”

현실: 물리학을 속일 수 없다.

실제 레이턴시 비교:

작업                           시간
-------------------------------------
L1 캐시 참조                 0.5 ns
분기 예측 실패                5   ns
L2 캐시 참조                 7   ns
뮤텍스 잠금/해제             25  ns
메인 메모리 참조             100 ns
Zippy로 1K 바이트 압축      3,000 ns
1Gbps로 2K 바이트 전송     20,000 ns
메모리에서 1MB 순차 읽기   250,000 ns
같은 데이터센터 라운드트립 500,000 ns
디스크 탐색              10,000,000 ns

서비스 간 호출의 실제 비용:

동일 프로세스 함수 호출: 1 ns
같은 데이터센터 HTTP:     500,000 ns (50만배)
다른 지역 HTTP:          100,000,000 ns (1억배)

실패 사례의 악몽: 스타트업의 응답 시간이 200ms에서 800ms로 증가했다. 단순 계산을 해보자:

모놀리스:
1. 사용자 조회: 0.001ms (메모리 내)
2. 재고 확인: 10ms (DB 쿼리)
3. 주문 생성: 20ms (DB 트랜잭션)
4. 결제 처리: 100ms (외부 API)
5. 알림 발송: 50ms (이메일)
총: 180ms

마이크로서비스:
1. User Service 호출: 50ms (네트워크 + 처리)
2. Inventory Service 호출: 60ms
3. Order Service 호출: 70ms
4. Billing Service 호출: 150ms (+ 외부 API)
5. Notification Service 호출: 100ms
총: 430ms (직렬 호출)

실제로는 더 나쁨:
- 직렬화/역직렬화: +50ms
- API 게이트웨이: +30ms
- 로드 밸런서: +20ms
- 서비스 디스커버리: +10ms
- 재시도 로직: +100ms (실패 시)
실제 총: 640ms+

그리고 이것은 모든 것이 완벽하게 작동할 때의 이야기다.

8.4 세 번째 오류: 대역폭은 무한하다

거짓말: “얼마든지 데이터를 주고받을 수 있다”

현실: 대역폭은 제한적이고 비싸다.

마이크로서비스에서는 데이터가 네트워크를 통해 이동해야 한다. 모놀리스에서는 메모리 내에서 포인터만 전달하면 된다.

실제 비용:

모놀리스:
User 객체 전달: 8 bytes (포인터)
시간: 1 ns
비용: $0

마이크로서비스:
User 객체 JSON 직렬화: 2KB
네트워크 전송: 2KB
시간: 20,000 ns
비용: $0.0001 per request
하루 100만 요청 = $100/day = $3,000/month

작은 차이처럼 보이지만...
6개 서비스 × 서로 통신 = 하루 수백만 요청

실패 사례: 스타트업의 인프라 비용이 $3,000에서 $12,000로 증가했다. 여기에는 증가된 네트워크 트래픽 비용도 포함되어 있었다.

8.5 네 번째에서 여덟 번째 오류

4. 네트워크는 안전하다

실패 사례: 서비스 간 인증이 없었음
내부 네트워크라고 가정
한 서비스 해킹 = 전체 시스템 해킹

5. 토폴로지는 변하지 않는다

실패 사례: 서비스 IP가 변경될 때마다 장애
쿠버네티스 없이 서비스 디스커버리 없음
하드코딩된 엔드포인트

6. 관리자는 한 명이다

실패 사례: 6개 서비스 = 6개 팀
조율 악몽
“내 서비스는 괜찮아, 네 서비스가 문제야”

7. 전송 비용은 0이다

실패 사례: 직렬화/역직렬화 비용 간과
JSON 파싱 CPU 사용
메모리 할당/해제

8. 네트워크는 동질적이다

실패 사례: 서로 다른 언어, 프레임워크
버전 불일치
프로토콜 변경

8.6 이 오류들이 실제로 의미하는 것

2025년 스타트업은 이 8가지 오류를 모두 믿었다. 그들은 네트워크가 함수 호출과 같다고 생각했다. 그래서:

에러 처리를 제대로 하지 않았다 (오류 1)
레이턴시를 무시했다 (오류 2)
데이터 전송 비용을 계산하지 않았다 (오류 3)
보안을 나중으로 미뤘다 (오류 4)
서비스 디스커버리가 없었다 (오류 5)
팀 간 조율이 없었다 (오류 6)
직렬화 비용을 간과했다 (오류 7)
일관되지 않은 기술 스택 (오류 8)

결과: 연쇄 장애, 느린 응답, 높은 비용, 팀 붕괴.

9부: 데이터의 문제 - 분산 시스템의 가장 어려운 도전

9.1 ACID에서 BASE로: 우리가 포기한 것들

모놀리스에서 우리는 ACID를 당연하게 여겼다:

Atomicity (원자성): 모든 것이 성공하거나 모든 것이 실패
Consistency (일관성): 데이터는 항상 유효한 상태
Isolation (고립성): 트랜잭션은 서로 간섭하지 않음
Durability (지속성): 커밋된 데이터는 영구적

마이크로서비스에서 우리는 BASE로 타협한다:

Basically Available (기본적 가용): 대부분의 시간 작동
Soft state (유연한 상태): 상태가 시간에 따라 변할 수 있음
Eventually consistent (최종 일관성): 언젠가는 일관되게 됨

“언젠가”가 문제다.

9.2 5개월 차의 악몽: 분산 트랜잭션

2025년 스타트업의 5개월 차를 다시 보자. 그들이 마주한 시나리오:

사용자가 주문을 생성:

Inventory Service: 재고 확인
Inventory Service: 재고 예약
Billing Service: 결제 처리
Order Service: 주문 생성
Notification Service: 확인 알림

3단계에서 결제가 실패하면?

모놀리스에서:

  
BEGIN TRANSACTION;
  UPDATE inventory SET reserved = reserved + 1 WHERE id = 123;
  INSERT INTO orders ...;
  INSERT INTO payments ...;
  -- 오류 발생!
ROLLBACK; -- 모든 것이 되돌려짐

간단하다. 깔끔하다. 원자적이다.

마이크로서비스에서:

1. POST /inventory/reserve → 성공 ✓
2. POST /billing/charge → 실패 ✗
3. 이제 어떻게 하나?

옵션 A: 재고 예약을 취소하는 보상 트랜잭션 호출
  POST /inventory/unreserve
  - 하지만 이것도 실패할 수 있음
  - 재시도? 언제까지?
  - 재시도 중 다른 주문이 그 재고를 가져가면?

옵션 B: 그냥 놔두기
  - 재고는 예약됨
  - 주문은 없음
  - 데이터 불일치
  - 고객 불만 폭주

옵션 C: Saga 패턴 구현
  - 복잡한 상태 머신
  - 보상 트랜잭션들
  - 여전히 완벽하지 않음

9.3 Saga 패턴: 구원인가 새로운 지옥인가

스타트업은 Saga 패턴을 구현하는 데 한 달을 보냈다. 하지만 여전히 버그가 있었다.

Saga 패턴이란: 긴 트랜잭션을 작은 트랜잭션들의 시퀀스로 나누고, 각 트랜잭션마다 보상 트랜잭션을 정의하는 패턴.

주문 Saga 예시:

주문 생성 Saga:
  1. ReserveInventory
     보상: CancelInventoryReservation
  2. ChargePayment
     보상: RefundPayment
  3. CreateOrder
     보상: CancelOrder
  4. SendNotification
     보상: (없음, 알림은 되돌릴 수 없음)

실행:
  1. ReserveInventory → 성공
  2. ChargePayment → 실패
  3. 보상 실행:
     - CancelInventoryReservation → ???

문제들:
- 보상도 실패할 수 있음
- 부분 실패 상태
- 동시성 문제
- 재시도 로직
- 타임아웃 처리
- 상태 추적

실제 코드의 복잡성:

  
// 모놀리스
public Order createOrder(CreateOrderRequest request) {
    Inventory inventory = inventoryRepo.findById(request.getItemId());
    inventory.reserve(request.getQuantity());
    
    Payment payment = paymentService.charge(request.getPaymentInfo());
    
    Order order = new Order(inventory, payment);
    orderRepo.save(order);
    
    notificationService.sendConfirmation(order);
    
    return order;
}
// 40줄, 이해하기 쉬움, 원자적

// 마이크로서비스 with Saga
public class OrderSaga {
    private SagaOrchestrator orchestrator;
    private InventoryClient inventoryClient;
    private PaymentClient paymentClient;
    private OrderClient orderClient;
    private NotificationClient notificationClient;
    
    public SagaExecution createOrder(CreateOrderRequest request) {
        SagaExecution saga = orchestrator.begin();
        
        try {
            // Step 1: Reserve Inventory
            ReservationResult reservation = 
                inventoryClient.reserve(request.getItemId(), request.getQuantity());
            saga.addCompensation(() -> 
                inventoryClient.cancelReservation(reservation.getId()));
            
            // Step 2: Charge Payment
            PaymentResult payment = 
                paymentClient.charge(request.getPaymentInfo());
            saga.addCompensation(() -> 
                paymentClient.refund(payment.getId()));
            
            // Step 3: Create Order
            OrderResult order = 
                orderClient.create(reservation, payment);
            saga.addCompensation(() -> 
                orderClient.cancel(order.getId()));
            
            // Step 4: Send Notification
            notificationClient.sendConfirmation(order);
            
            saga.complete();
            return saga;
            
        } catch (Exception e) {
            saga.compensate(); // 모든 보상 실행
            throw new SagaFailedException(e);
        }
    }
    
    // 그리고 이것은 단순화된 버전
    // 실제로는:
    // - 재시도 로직
    // - 타임아웃 처리
    // - 멱등성 보장
    // - 상태 지속성
    // - 동시성 제어
    // - 에러 복구
    // 등등 수백 줄이 더 필요
}
// 200+ 줄, 복잡함, 여전히 완벽하지 않음

스타트업이 발견한 것:

주문이 유실됨 (네트워크 타임아웃 중)
재고가 중복 예약됨 (재시도 로직 버그)
고객이 중복 청구됨 (멱등성 실패)
고객 지원 티켓 3배 증가

9.4 CAP 정리: 선택해야 하는 것들

분산 시스템에서는 CAP 정리를 피할 수 없다:

Consistency (일관성)
Availability (가용성)
Partition tolerance (분할 내성)

3가지 중 2가지만 선택할 수 있다.

실패 사례의 선택: 스타트업은 모든 것을 원했다. 그래서 아무것도 제대로 얻지 못했다.

그들이 실제로 필요했던 것: CA (일관성 + 가용성) 그들이 선택한 것: AP (가용성 + 분할 내성) 결과: 데이터 불일치로 인한 비즈니스 문제

모놀리스는 자연스럽게 CA를 제공한다. 단일 데이터베이스, 단일 프로세스. 간단하다.

9.5 데이터 중복의 함정

마이크로서비스의 원칙: “각 서비스는 자신의 데이터를 소유한다.”

이론상 아름답다. 실전에서는 악몽이다.

실패 사례:

User Service가 사용자 정보를 소유:
{
  id: 123,
  name: "John Doe",
  email: "john@example.com"
}

하지만 Order Service도 사용자 정보가 필요:
- 주문한 사람의 이름?
- 배송지 이메일?

옵션 A: 매번 User Service 호출
  - 느림 (네트워크 레이턴시)
  - User Service 다운 = 주문 조회 불가
  - 엄청난 트래픽

옵션 B: 데이터 복제
  Order Service가 사용자 정보 캐시:
  {
    userId: 123,
    cachedName: "John Doe",
    cachedEmail: "john@example.com",
    lastUpdated: "2026-01-10T10:00:00Z"
  }
  
  문제:
  - John이 이메일을 변경하면?
  - 얼마나 자주 동기화?
  - 동기화 실패하면?
  - 결국 일관성 문제

옵션 C: 이벤트 기반 동기화
  User Service가 UserUpdated 이벤트 발행
  Order Service가 구독하고 업데이트
  
  문제:
  - 이벤트 유실 가능
  - 순서 보장 어려움
  - 복잡한 이벤트 처리 로직
  - 결국 최종 일관성 (Eventually Consistent)

스타트업의 현실: 6개 서비스가 서로의 데이터가 필요했다. 그들은 옵션 B와 C를 섞어 사용했다. 결과:

데이터 동기화 버그
캐시 무효화 실패
고객이 잘못된 정보를 봄
디버깅 불가능 (어느 서비스가 진실인가?)

10부: 조직의 현실 - Conway’s Law의 깊은 함의

10.1 1967년의 발견이 2026년에도 유효한 이유

Mel Conway의 논문은 거의 60년 전에 작성되었다. 하지만 2026년에도, 2025년 12월의 실패 사례에서도, 여전히 완벽하게 적용된다. 왜일까?

왜냐하면 그것은 기술이 아니라 인간에 관한 것이기 때문이다.

시스템은 코드로 만들어지지만, 코드는 사람에 의해 작성된다. 그리고 사람들은 커뮤니케이션한다. 아니, 커뮤니케이션하려고 시도한다. 그리고 그 시도의 구조가 시스템의 구조를 결정한다.

10.2 역 Conway 책략 (Inverse Conway Maneuver)

Conway’s Law를 알면, 역으로 활용할 수 있다:

원하는 아키텍처 → 그에 맞는 조직 구조

예:

마이크로서비스를 원한다면:
→ 소규모 자율 팀 조직 (각 서비스당 1팀)
→ 명확한 API 계약
→ 독립적 배포 권한
→ 전담 데이터베이스

모듈러 모놀리스를 원한다면:
→ 기능별 팀 조직
→ 명확한 모듈 경계
→ 공유 코드베이스
→ 조율된 배포

실패 사례의 역 Conway 실패:

스타트업이 원한 것: 6개 마이크로서비스
스타트업의 조직: 7명의 긴밀한 팀

Conway's Law 예측:
7명 팀 → 긴밀하게 결합된 시스템

실제 결과:
6개 서비스이지만 깊이 결합됨
= 분산된 모놀리스
= 최악의 조합

그들이 했어야 할 것:

7명 팀 → 모듈러 모놀리스
명확한 모듈 경계
하지만 단일 배포
일관된 커뮤니케이션

10.3 팀 인지 부하 (Team Cognitive Load)

“Team Topologies” (Matthew Skelton & Manuel Pais, 2019)의 핵심 개념:

각 팀에는 인지 부하 한계가 있다.

한 팀이 관리할 수 있는 것:
- 1-2개 도메인
- 1-3개 서비스 (최대)
- 자신들의 기술 스택
- 자신들의 인프라

한 팀이 관리할 수 없는 것:
- 6개 서비스 (4명 팀이)
- 여러 기술 스택
- 복잡한 분산 시스템
- 전체 플랫폼

실패 사례:

스타트업 팀 부하:
- 6개 마이크로서비스 관리
- 6개 데이터베이스 관리
- 복잡한 서비스 간 통신
- 분산 디버깅
- 배포 조율
- Saga 패턴 구현
- 모니터링과 관측성
- 에러 처리와 재시도
- ...

결과: 인지 과부하 → 생산성 붕괴 → 번아웃

10.4 커뮤니케이션의 실제 비용

Brooks의 법칙: “늦은 소프트웨어 프로젝트에 인력을 추가하는 것은 프로젝트를 더 늦게 만든다.”

왜? 커뮤니케이션 경로가 기하급수적으로 증가하기 때문이다.

커뮤니케이션 경로 = n(n-1)/2

2명: 1개
3명: 3개
4명: 6개
5명: 10개
10명: 45개
50명: 1,225개

이것이 마이크로서비스와 무슨 관계인가?

서비스는 팀과 같다. 서비스 간 통신 = 팀 간 커뮤니케이션.

모놀리스 (1개 서비스):
커뮤니케이션: 팀 내부 (빠르고 쉬움)

6개 마이크로서비스:
서비스 간 통신: 15개 경로
각 경로마다:
- API 계약 협상
- 버전 관리
- 에러 처리
- 모니터링
- 문서화
총: 엄청난 조율 비용

실패 사례: 4명 팀이 6개 서비스를 만들었을 때, 그들은 사실상 15개의 미니 팀을 만든 것이다. 4명이 15개 팀의 역할을 해야 했다. 불가능했다.

10.5 “우리 vs 그들” 문화의 독

마이크로서비스는 종종 “우리 vs 그들” 문화를 만든다:

"우리 서비스는 괜찮아. 
당신 서비스가 우리에게 잘못된 데이터를 보내고 있어."

"아니야, 우리 서비스는 정확한 데이터를 보내.
당신 서비스가 제대로 처리하지 못하는 거야."

"우리는 문서대로 했어.
당신이 API 계약을 위반했어."

"우리가 언제 동의했어?
회의록을 확인해봐."

실패 사례에서: 6개월 차, 팀은 서로를 비난하기 시작했다. 협력 대신 갈등. 문제 해결 대신 책임 회피.

모놀리스에서는:

"이 함수가 왜 이상한 데이터를 반환해?"

"아, 내가 어제 버그를 고쳤는데 
다른 곳에 영향을 미쳤나봐. 
같이 보자."

2분 후: 문제 해결

같은 코드베이스 = 공유된 소유권 = 협력 문화

10.6 조직 재설계의 필요성

마이크로서비스를 진짜로 하려면, 조직 전체를 재설계해야 한다.

필요한 것들:

✓ 소규모 자율 팀 (2-pizza teams)
✓ 각 팀이 서비스를 완전히 소유
✓ DevOps 문화 (You build it, you run it)
✓ 독립적 배포 권한
✓ 명확한 SLA와 API 계약
✓ 플랫폼 팀 (공통 도구와 인프라)
✓ 강력한 관측성 문화
✓ 실험과 실패를 용인하는 문화

실패 사례가 가진 것:

✗ 7명의 단일 팀
✗ 모호한 소유권
✗ 전통적인 배포 프로세스
✗ 조율된 릴리스
✗ 암묵적 계약
✗ 플랫폼 팀 없음
✗ 최소한의 모니터링
✗ 실패에 대한 공포

결과: 조직과 아키텍처의 불일치 → 실패

11부: 비용의 진실 - 숨겨진 세금들

11.1 인프라 비용의 폭발

실패 사례: $3,000/월 → $12,000/월 (4배)

왜?

모놀리스 인프라:
- 앱 서버 2대: $400/월
- PostgreSQL (primary + replica): $600/월
- Redis: $200/월
- 로드 밸런서: $300/월
- CDN: $500/월
- 모니터링: $500/월
- 백업: $500/월
총: $3,000/월

마이크로서비스 인프라:
- 6개 서비스 × 2 인스턴스: $2,400/월
- 6개 데이터베이스: $3,600/월
- API 게이트웨이: $500/월
- 서비스 메시: $800/월
- 메시지 큐: $400/월
- 로그 집계: $1,200/월
- 분산 추적: $800/월
- 메트릭 시스템: $600/월
- 서비스 디스커버리: $300/월
- 추가 네트워크 비용: $600/월
- 백업 × 6: $800/월
총: $12,000/월

이것도 Kubernetes 없이!
Kubernetes 추가하면: +$3,000/월

숨겨진 비용들:

- 개발 환경 복잡도: +$500/월
- 스테이징 환경 × 복잡도: +$2,000/월
- 더 많은 데이터 전송: +$800/월
- 더 많은 API 호출: +$400/월
- 보안 도구들: +$600/월

진짜 총 비용: $19,300/월 (6.4배)

11.2 개발 속도 세금

인프라 비용보다 더 비싼 것: 시간

실패 사례:

월 기능 출시:
모놀리스: 20-25개
마이크로서비스: 4-6개

손실: 15-20개 기능/월
= 180-240개 기능/년

기회 비용 계산:

기능 하나의 가치: $10,000 (평균)
손실된 기능: 180개/년
기회 비용: $1,800,000/년

vs

인프라 비용 증가: $195,600/년

진짜 비용 = $2,000,000/년

그리고 더 나쁜 것: 느린 출시 = 시장 기회 상실 = 계산 불가능한 비용

11.3 인적 비용

개발자 생산성:

모놀리스:
- 새 기능: 100% (기준선)
- 디버깅: 30분
- 온보딩: 2일

마이크로서비스:
- 새 기능: 40% (60% 감소)
- 디버깅: 3시간 (6배)
- 온보딩: 2주 (7배)

팀 사기:

모놀리스 시절:
- 행복한 개발자들
- 빠른 피드백 루프
- 자부심 ("우리가 만들었다")
- 낮은 이직률

마이크로서비스 이후:
- 좌절한 개발자들
- 느린 피드백 루프
- 무력감 ("왜 이렇게 복잡해?")
- 높은 이직률

실패 사례: 6개월 만에 핵심 개발자 3명 퇴사. 재채용 비용: $300,000+ 노하우 손실: 값을 매길 수 없음

11.4 ROI 계산: 마이크로서비스는 언제 정당화되는가?

간단한 공식:

마이크로서비스 ROI = (이득 - 비용) / 비용

이득:
- 더 빠른 확장: +$X
- 독립 배포: +$Y
- 팀 자율성: +$Z
- 장애 격리: +$W

비용:
- 인프라: $200,000/년
- 생산성 손실: $500,000/년
- 복잡도 관리: $300,000/년
- 인적 비용: $500,000/년
총: $1,500,000/년

Break-even:
X + Y + Z + W > $1,500,000/년

현실:
대부분 팀에서 X + Y + Z + W < $500,000/년
ROI = -67% (손실)

언제 양수 ROI가 나오는가?

✓ 엔지니어 100명+ (조율 비용이 실제 문제)
✓ 일 거래 10억+ (독립 확장 필요)
✓ 전담 플랫폼 팀 (복잡도 관리)
✓ 명확한 비즈니스 케이스 (숫자로 입증)

10명 팀의 경우: ROI = -80% (거의 확실함)

12부: 복구 전략 - 실패에서 벗어나기

12.1 인정: 가장 어려운 단계

손실 회피 편향 (Loss Aversion Bias): “우리는 이미 6개월과 $800K를 투자했다. 지금 포기하면 모든 것이 낭비된다. 조금만 더 하면 될 것 같다.”

매몰 비용 오류 (Sunk Cost Fallacy): 더 많이 투자할수록 포기하기 더 어렵다.

실패 사례의 전환점: 창업자가 데이터를 직시했을 때:

Before vs After 비교:
- 기능 출시: 25개/월 → 4개/월
- 응답 시간: 180ms → 1,200ms
- 인프라: $3K → $12K
- 팀 행복도: 높음 → 퇴사 중

결론: "이것은 작동하지 않는다."

인정의 단계:

데이터 수집 (감정 제외)
현실 직시
팀과 공유
투자자와 솔직한 대화
결정: 전진 or 후퇴

12.2 평가: 부분 vs 전체

옵션 평가:

A. 부분 통합 (일부 서비스만 통합)

장점:
- 점진적
- 위험 낮음
- 학습 기회

단점:
- 여전히 복잡
- 중간 상태 오래 지속
- 명확한 개선 안 보일 수 있음

적합한 경우:
- 일부 서비스는 실제로 유용
- 팀이 여전히 희망 있음
- 시간 여유 있음

B. 전체 통합 (완전한 모놀리스 회귀)

장점:
- 명확한 방향
- 빠른 효과
- 단순성 회복

단점:
- 큰 결정
- 대규모 작업
- 실수 시 치명적

적합한 경우:
- 모든 서비스가 문제
- 빠른 개선 필수
- 팀이 탈진 상태

C. 하이브리드 (핵심만 모놀리스)

장점:
- 균형잡힌 접근
- 교훈 활용
- 유연성

단점:
- 여전히 복잡
- 명확한 경계 필요
- 계획 필요

적합한 경우:
- 특정 기능은 정말 분리 필요
- 학습한 것 있음
- 장기 비전 있음

실패 사례의 선택: B (전체 통합) 왜? 생존이 우선. 모든 것이 불타고 있었다.

12.3 실행: 8주 계획

실패 사례의 통합 계획:

Week 1-2: Notification Service 통합

선택 이유:
- 가장 독립적
- 위험 낮음
- 빠른 승리

작업:
- 코드 복사
- 의존성 통합
- 테스트
- 배포
- 서비스 종료

Week 3-4: Billing Service 통합

더 복잡:
- 4개 서비스와 통신
- 데이터베이스 마이그레이션
- 트랜잭션 로직 단순화

이득:
- Saga 패턴 제거
- 단순한 트랜잭션
- 데이터 일관성

Week 5-6: Order + Inventory 통합

가장 복잡:
- 깊은 결합
- 많은 중복 코드
- 데이터 정리 필요

전략:
- 작은 단계로
- 지속적 테스트
- 롤백 준비

Week 7-8: 정리와 최적화

- 중복 코드 제거
- 인터페이스 정리
- 성능 최적화
- 문서화
- 팀 교육

결과:

✓ 8주 만에 완료
✓ 기능 출시 속도 회복
✓ 응답 시간 정상화
✓ 인프라 비용 절감
✓ 팀 사기 회복
✓ 회사 생존

12.4 학습: 다시는 반복하지 않기

회고 (Retrospective):

무엇이 잘못되었나?

문제 오진단 (문제가 없었음)
규모 오판 (넷플릭스 ≠ 우리)
조직 불일치 (7명 vs 6 서비스)
복잡도 과소평가
비용 과소평가
Conway’s Law 무시
분산 시스템 경험 부족

어떤 신호를 놓쳤나?

1개월: 배포 시간 6배 증가 (무시됨)
2개월: 응답 시간 4배 증가 (해결 시도)
3개월: 개발 속도 감소 (정상화 믿음)
4개월: 조율 악몽 (더 많은 도구로 해결)
5개월: 데이터 문제 (Saga로 해결)
6개월: 팀 붕괴 (너무 늦음)

다음에는:

✓ 데이터로 결정
✓ 작은 팀 = 간단한 아키텍처
✓ 실제 문제 해결
✓ 점진적 진화
✓ 조기 경고 신호 주의
✓ 팀 피드백 경청
✓ 실용주의 > 이상주의

12.5 문서화와 공유

그들이 만든 문서:

1. "우리의 마이크로서비스 실패: 타임라인"
   - 객관적 사실들
   - 측정 지표
   - 결정 지점들
   
2. "우리가 배운 것들"
   - 기술적 교훈
   - 조직적 교훈
   - 인간적 교훈
   
3. "모놀리스 통합 가이드"
   - 실제 단계들
   - 마주친 문제들
   - 해결 방법들
   
4. "팀을 위한 의사결정 체크리스트"
   - 다시는 반복하지 않기 위해

그리고 용감하게 공유: 2025년 12월 28일, Medium에 글을 올렸다. “Microservices Killed Our Startup. Monoliths Would’ve Saved Us”

수천 명의 개발자들이 감사했다. “당신이 우리를 구했습니다.”

결론: 목적 있는 아키텍처를 향하여

2025년 12월 28일에 공유된 스타트업 실패 사례와 반 버논·토마스 야스쿨라의 “Strategic Monoliths and Microservices”가 가르치는 교훈은 명확하다. 아키텍처는 비즈니스 목표를 달성하기 위한 전략적 도구여야 하며, 그 자체가 목표가 되어서는 안 된다.

핵심 통찰들

1. 컨텍스트가 모든 것이다 넷플릭스의 500명 엔지니어를 위한 솔루션은 4명 팀의 문제에 대한 답이 아니다. 규모, 팀, 도메인이 다르면 아키텍처도 달라야 한다. “너무 이른 분산”은 “너무 이른 최적화”만큼이나 위험하다.

2. Conway’s Law는 피할 수 없다 조직이 시스템을 설계한다. 4명의 긴밀한 팀은 긴밀한 시스템을 만들 것이다. 마이크로서비스를 원한다면 먼저 조직을 마이크로서비스 구조로 만들어라. 아니면 분산된 Big Ball of Mud를 얻게 될 것이다.

3. 커뮤니케이션이 핵심이다 Big Ball of Mud는 깨진 커뮤니케이션의 결과다. 좋은 소프트웨어는 비즈니스와 기술 이해관계자 사이의 깊은 커뮤니케이션, 학습, 혁신의 경로에서 나온다. 계층을 줄이고, 사일로를 제거하고, 상호 존중을 구축하라.

4. 단순성은 강력한 기능이다 복잡성은 매일 지불해야 하는 세금이다. 그것은 복리로 증가한다. 가장 단순한 아키텍처가 종종 최선이다. 모놀리스는 적이 아니다 - 나쁜 아키텍처가 적이다.

5. 사고가 혁신을 이끈다 깊은 비판적 사고 없이, 우리는 FOMO와 이력서 주도 개발에 빠진다. 모든 결정 전에 멈추고 물어라: “왜?” 새로운 기술 버즈를 따르기보다는 실제 문제를 해결하라.

6. 점진적 진화가 승리한다 A에서 Z로 바로 가려고 하지 마라. A → B → C → D로 가고, 각 단계에서 학습하라. Z가 결코 필요 없을 수도 있다는 것을 인정하라. 모듈러 모놀리스로 시작하고, 경계를 “벌어라”, 필요시만 추출하라.

최종 조언

새로운 프로젝트를 시작한다면: 모듈러 모놀리스로 시작하라. 명확한 모듈 경계를 가지고, package-by-feature를 사용하고, 아키텍처 테스트를 작성하라. 도메인 주도 설계를 적용하고, 지속적으로 리팩토링하라. Spring Modulith나 비슷한 도구를 사용하라. 그리고 무엇보다, 깊이 생각하라.

기존 모놀리스를 가지고 있다면: 먼저 최적화하라. 데이터베이스 쿼리, 캐싱, 수직 확장, 읽기 복제본. 그런 다음 모듈화하라. 명확한 경계, 순환 의존성 제거, 레이어드 아키텍처. 여전히 문제가 있다면, 점진적으로 추출하라. 실제 필요가 있을 때만, 명확한 bounded contexts로, 하나씩 검증하면서.

마이크로서비스를 고려 중이라면: 멈추고 생각하라. 실제 50명 이상의 엔지니어가 있는가? 전담 플랫폼 팀이 있는가? 모놀리스를 먼저 최적화했는가? 명확하게 분리된 bounded contexts가 있는가? 극명하게 다른 확장 요구사항이 있는가? 5개 이상 체크되지 않으면, 모듈러 모놀리스를 고수하라.

마이크로서비스에서 고통받고 있다면: 재통합을 고려하라. 많은 팀이 이미 그렇게 했다. 아마존 프라임 비디오는 비용을 90% 절감했다. 2025년 12월의 스타트업은 생존했다. 부끄러운 일이 아니다 - 실용주의다.

2026년의 성숙한 이해

2026년 1월 현재, 소프트웨어 업계는 마이크로서비스 과대광고의 정점을 지나 현실로 돌아오고 있다. 85-89%의 기업이 마이크로서비스를 사용하지만, 60%가 후회한다. 클라우드 마이크로서비스 시장은 132억 달러로 성장하지만, 많은 기업이 모듈러 모놀리스로 회귀한다.

이것은 마이크로서비스가 나쁘다는 것이 아니다. 마이크로서비스는 적절한 컨텍스트에서 강력하다. 하지만 대부분의 팀에게 대부분의 시간에, 잘 구조화된 모놀리스나 모듈러 모놀리스가 더 나은 선택이다.

가장 중요한 것은: 최고의 아키텍처는 기능을 출시하고 돈을 벌 수 있게 하는 것이다. 나머지는 모두 자존심일 뿐이다.

트렌드를 따르지 마라. 문제를 해결하라. 깊이 생각하라. 단순하게 시작하라. 점진적으로 진화하라. 그리고 무엇보다, 목적 있는 아키텍처를 구축하라 - 비즈니스 목표를 진정으로 지원하는 아키텍처를.

참고 자료

주요 출처:

Vernon, Vaughn & Jaskula, Tomasz. “Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture” (Addison-Wesley Signature Series)
“Microservices Killed Our Startup. Monoliths Would’ve Saved Us” - Engineer in the Dark
해커뉴스 토론: https://news.ycombinator.com/item?id=46469845
한국어 커뮤니티 토론: https://news.hada.io/topic?id=25571

추가 참조:

Conway, Melvin E. “How Do Committees Invent?” (1968)
“Monolith vs Microservices in 2025” - Foojay (2025)
“Why Microservices Are Out and Monoliths Are Making a Comeback” (2025)
Gartner Report on Microservices Adoption (2025)
Spring Modulith Documentation (2025-2026)
Google Research: “Towards Modern Development of Cloud Applications” (2024)
“Modular Monolith: A Primer” - Kamil Grzybek
Fowler, Martin. “MonolithFirst”
Richardson, Chris. “Pattern: Monolithic Architecture”
Evans, Eric. “Domain-Driven Design: Tackling Complexity in the Heart of Software”

작성 일자: 2026-01-10

저자 노트: 이 문서는 2025년 12월 말의 바이럴 스타트업 실패 사례, “Strategic Monoliths and Microservices” 책의 통찰, 그리고 2025-2026년 업계 트렌드를 통합하여 작성되었습니다. 목표는 균형 잡힌 시각을 제공하는 것입니다 - 마이크로서비스를 맹목적으로 비난하거나 모놀리스를 맹목적으로 옹호하는 것이 아니라, 컨텍스트에 기반한 현명한 의사결정을 돕는 것입니다.

TechStack, Software Architecture

서문: 2025년 12월, 한 고백이 촉발한 성찰

1장: 비즈니스 목표와 디지털 전환 - 근본으로 돌아가기

1.1 혁신의 본질: 필요성의 어머니

1.2 디지털 전환: 목표가 무엇인가?

1.3 실패 사례로 돌아가기: “넷플릭스처럼”의 함정

2장: 소프트웨어는 왜 잘못되는가 - Big Ball of Mud의 해부

2.1 엔터프라이즈 소프트웨어의 참담한 현실

2.2 Big Ball of Mud: Unarchitecture의 정의

2.3 실패 사례의 Big Ball of Mud

2.4 기술 부채 (Technical Debt Metaphor)

2.5 소프트웨어 엔트로피 (Software Entropy)

3장: Conway’s Law - 조직이 시스템을 결정한다

3.1 피할 수 없는 현실

3.2 커뮤니케이션은 지식에 관한 것이다

3.3 전화 게임 (The Telephone Game)

3.4 합의에 도달하기는 어렵다

3.5 실패 사례에서의 Conway’s Law

4장: 최적의 커뮤니케이션 - 팀 플레이의 결과

4.1 팀으로 행동하는 것은 팀이 되는 것을 요구한다

4.2 최적의 커뮤니케이션을 위한 핵심

5장: 전략적 사고와 재사고 - 아키텍처 결정 이전에

5.1 사고 (Thinking)

5.2 생각해야 할 것들 (What Are We Doing?)

5.3 실패 사례에서의 사고 부재

6장: NuCoverage Insurance 사례 연구 - Big Ball of Mud에서 벗어나기

6.1 사례 소개

6.2 비즈니스 기회

6.3 Big Ball of Mud의 현실

7장: 균형 잡힌 접근 - 2026년의 실용적 지혜

7.1 아키텍처는 목표가 아니라 도구다

7.2 실패에서 배우는 교훈

7.3 성공의 원칙

7.4 의사결정 프레임워크

7.5 2026년의 현실적 권장사항

7.6 마이크로서비스를 고려할 때

8부: 네트워크의 거짓말 - 분산 컴퓨팅의 8가지 오류

8.1 Peter Deutsch의 경고

8.2 첫 번째 오류: 네트워크는 신뢰할 수 있다

8.3 두 번째 오류: 레이턴시는 0이다

8.4 세 번째 오류: 대역폭은 무한하다

8.5 네 번째에서 여덟 번째 오류

8.6 이 오류들이 실제로 의미하는 것

9부: 데이터의 문제 - 분산 시스템의 가장 어려운 도전

9.1 ACID에서 BASE로: 우리가 포기한 것들

9.2 5개월 차의 악몽: 분산 트랜잭션

9.3 Saga 패턴: 구원인가 새로운 지옥인가

9.4 CAP 정리: 선택해야 하는 것들

9.5 데이터 중복의 함정

10부: 조직의 현실 - Conway’s Law의 깊은 함의

10.1 1967년의 발견이 2026년에도 유효한 이유

10.2 역 Conway 책략 (Inverse Conway Maneuver)

10.3 팀 인지 부하 (Team Cognitive Load)

10.4 커뮤니케이션의 실제 비용

10.5 “우리 vs 그들” 문화의 독

10.6 조직 재설계의 필요성

11부: 비용의 진실 - 숨겨진 세금들

11.1 인프라 비용의 폭발

11.2 개발 속도 세금

11.3 인적 비용

11.4 ROI 계산: 마이크로서비스는 언제 정당화되는가?

12부: 복구 전략 - 실패에서 벗어나기

12.1 인정: 가장 어려운 단계

12.2 평가: 부분 vs 전체

12.3 실행: 8주 계획

12.4 학습: 다시는 반복하지 않기

12.5 문서화와 공유

결론: 목적 있는 아키텍처를 향하여

핵심 통찰들

최종 조언

2026년의 성숙한 이해

참고 자료

인기 태그