처리중입니다. 잠시만 기다려주세요.
TTJ 코딩클래스
정규반 단과 자료실 테크 뉴스 코딩 퀴즈
테크 뉴스
Hacker News 2026.03.25 35

마이크로서비스 도입 전에 꼭 읽어야 할 마틴 파울러의 경고

Hacker News 원문 보기

"분산 객체의 제1법칙: 객체를 분산시키지 마라"

마이크로서비스 아키텍처가 업계 표준처럼 자리 잡은 지 꽤 됐는데요. 그런데 소프트웨어 아키텍처의 대가 마틴 파울러가 2014년에 쓴 글이 지금 다시 주목받고 있어요. 핵심 메시지는 간단해요. "분산 객체의 제1법칙은, 객체를 분산시키지 말라는 것이다." 이 문장은 원래 마틴 파울러의 명저 'Patterns of Enterprise Application Architecture'에 나오는 말인데, 마이크로서비스 열풍 속에서 이 원칙을 다시 꺼내 든 거예요.

왜 이 글이 10년 넘게 유효한가

이 글의 배경을 이해하려면 2014년 당시 상황을 알아야 해요. 넷플릭스와 아마존이 마이크로서비스로 성공한 사례가 알려지면서, 많은 회사들이 "우리도 마이크로서비스를 해야 한다"는 분위기였거든요. 마틴 파울러는 마이크로서비스라는 용어를 정의한 사람 중 하나인데, 정작 본인이 "함부로 쓰지 마라"고 경고한 거예요.

핵심 논지는 이래요. 원격 호출(네트워크를 통한 함수 호출)과 로컬 호출(같은 프로세스 안에서의 함수 호출)은 근본적으로 다르다는 거예요. 이게 뭐냐면, 같은 프로그램 안에서 함수를 호출하면 나노초 단위로 즉시 응답이 오고 실패할 일도 거의 없는데, 네트워크를 통해 다른 서비스를 호출하면 밀리초~초 단위의 지연이 생기고, 네트워크 장애로 실패할 수도 있고, 부분적으로만 성공할 수도 있어요. 이 차이를 무시하고 설계하면 큰 문제가 생긴다는 거죠.

분산 객체가 위험한 이유

파울러가 지적하는 가장 큰 문제는 "분포 투명성(distribution transparency)"이라는 환상이에요. 90년대에 CORBA나 DCOM 같은 기술이 "원격 호출을 로컬 호출처럼 쓸 수 있게 해주겠다"고 약속했는데, 결과적으로 대실패했거든요. 네트워크의 본질적인 문제(지연, 장애, 대역폭 제한)를 추상화로 숨기면, 개발할 때는 편하지만 운영할 때 감당할 수 없는 문제가 터져요.

쉬운 예를 들어볼게요. 모놀리스(하나의 큰 애플리케이션)에서 주문 처리할 때, 재고 확인하고 결제하고 배송 예약하는 걸 하나의 트랜잭션으로 묶을 수 있어요. 그런데 이걸 각각 다른 마이크로서비스로 쪼개면, 결제는 됐는데 재고 차감이 실패하는 상황이 생길 수 있거든요. 이걸 처리하려면 사가 패턴(Saga Pattern)이나 보상 트랜잭션 같은 복잡한 메커니즘이 필요한데, 이 복잡도를 감당할 준비가 안 된 팀이 많아요.

그러면 마이크로서비스는 쓰면 안 되는 건가?

파울러의 결론은 "쓰지 마라"가 아니라 "모놀리스 먼저(MonolithFirst)"예요. 처음에는 잘 구조화된 모놀리스로 시작하고, 정말로 독립적 배포가 필요하거나 팀 규모가 커서 코드베이스를 나눠야 할 때 점진적으로 분리하라는 거예요. 이게 중요한 이유가, 서비스 경계를 어디에 그을지는 도메인을 충분히 이해한 뒤에야 제대로 결정할 수 있거든요. 프로젝트 초기에는 도메인 이해가 부족해서 잘못된 경계를 긋기 쉽고, 한번 나눈 서비스를 다시 합치는 건 엄청나게 비용이 커요.

이 관점은 최근 업계 흐름과도 맞아요. 아마존 프라임 비디오 팀이 2023년에 마이크로서비스에서 모놀리스로 회귀하면서 비용을 90% 절감했다는 사례가 유명한데요. 37signals(Basecamp)의 DHH도 "마제스틱 모놀리스"를 꾸준히 옹호하고 있고요. 마이크로서비스가 만능이 아니라는 인식이 점점 퍼지고 있어요.

한국 개발자에게 주는 시사점

솔직히 한국 스타트업 현장에서도 "마이크로서비스 안 하면 뒤처진다"는 분위기가 있었는데요. 개발자 3~5명인 팀에서 쿠버네티스에 마이크로서비스를 올리는 건, 파울러 식으로 말하면 제1법칙을 정면으로 위반하는 거예요. 물론 규모가 큰 조직에서는 마이크로서비스가 맞을 수 있지만, 중요한 건 기술적 판단이지 트렌드를 따르는 게 아니에요.

실무 팁을 하나 드리자면, 모놀리스 안에서도 모듈 경계를 잘 나눠두면 나중에 필요할 때 분리하기가 훨씬 수월해요. 패키지나 모듈 단위로 의존성을 깔끔하게 관리하는 "모듈러 모놀리스" 접근법이 최근 인기를 끌고 있는데, 이게 대부분의 팀에게 가장 현실적인 선택일 수 있어요.

핵심 한줄

마이크로서비스는 큰 조직의 문제를 푸는 도구이지, 작은 팀의 기술 부채를 해결하는 마법이 아니에요.

여러분 팀에서는 모놀리스와 마이크로서비스 중 어떤 아키텍처를 쓰고 계신가요? 전환 경험이 있다면 어떤 점이 가장 어려웠는지 궁금해요!


🔗 출처: Hacker News

이 뉴스가 유용했나요?

TTJ 코딩클래스 정규반

월급 외 수입,
코딩으로 만들 수 있습니다

17가지 수익 모델을 직접 실습하고, 1,300만원 상당의 자동화 도구와 소스코드를 받아가세요.

144+실전 강의
17개수익 모델
4.9수강생 평점
정규반 자세히 보기

"비전공 직장인인데 반년 만에 수익 파이프라인을 여러 개 만들었습니다"

실제 수강생 후기
  • 비전공자도 6개월이면 첫 수익
  • 20년 경력 개발자 직강
  • 자동화 프로그램 + 소스코드 제공

매일 AI·개발 뉴스를 받아보세요

주요 테크 뉴스를 매일 아침 이메일로 전해드립니다.

스팸 없이, 언제든 구독 취소 가능합니다.