YEYETILCraftsPostsAbout

[TIL] 아키텍처 스타일 기초 (9장)

2026. 09. 10.Yeji Kim
Architecture

스타일과 패턴은 다르다

책이 제일 먼저 하는 건 단어 정리다. 마이크로서비스는 스타일이고, 사가나 API 게이트웨이는 패턴이다.

무슨 차이일까. 되돌리는 값이 다르다.

패턴은 필요한 곳에만 골라 쓰고, 아니다 싶으면 걷어내면 된다. 스타일은 시스템 전체가 그 위에 올라타 있어서 바꾸려면 거의 다시 만들어야 한다. 그래서 스타일 선택은 훨씬 신중해야 한다는 이야기다.

스타일을 재는 축 두 개

앞으로 나올 모든 스타일은 이 두 가지로 설명된다.

첫째, 무엇을 기준으로 쪼갤 것인가.

text
기술로 쪼개기     화면 / 로직 / 데이터 저장
도메인으로 쪼개기  주문 / 배송 / 결제 / 고객

8장에서 컴포넌트 나눌 때 봤던 그 두 갈래가, 시스템 전체 구조를 정할 때도 똑같이 나온다.

둘째, 배포하는 덩어리가 몇 개인가. 7장에서 나왔던 아키텍처 퀀텀, 그러니까 혼자 따로 배포할 수 있는 최소 단위가 몇 개냐는 이야기다.

text
덩어리 하나   레이어드, 모듈러 모놀리스, 파이프라인, 마이크로커널
덩어리 여럿   서비스 기반, 이벤트 기반, 공간 기반, SOA, 마이크로서비스

여럿으로 쪼개면 확장도 잘 되고, 일부가 죽어도 버티고, 배포도 따로따로 할 수 있다. 그래서 좋아 보인다. 책은 여기서 바로 브레이크를 건다.

쪼개면 꼭 겪는 여덟 가지 착각

여러 덩어리로 나눠서 서로 네트워크로 부르게 만들면, 개발자들이 은근히 맞다고 치고 코드를 짜는 가정들이 있다.

text
1. 네트워크는 안 끊긴다
2. 호출은 즉시 도착한다
3. 대역폭은 얼마든지 써도 된다
4. 네트워크는 안전하다
5. 서버 구성은 안 바뀐다
6. 관리하는 사람은 한 명이다
7. 데이터 주고받는 건 공짜다
8. 모든 네트워크 장비가 똑같다

하나씩 떼어놓고 보면 전부 틀린 말인데, 막상 코드 짤 때는 이렇게 짜게 된다.

특히 2번이 무섭다. 같은 프로그램 안에서 함수를 부르면 거의 0에 가깝지만, 네트워크 건너서 부르면 밀리초 단위다. 그리고 여기서 봐야 할 건 평균이 아니다. 평균 30밀리초짜리 호출도 요청 하나에 열 번 일어나면 300밀리초고, 그중 하나가 가끔 2초씩 걸리면 사용자는 그냥 2초를 기다린다. 잘게 쪼갤수록 이 곱셈이 커진다.

쪼개면 딸려 오는 일들

나누는 순간 없던 일이 생긴다.

로그가 흩어진다. 하나로 붙어 있을 땐 파일 하나 열면 됐는데, 이제는 요청 하나가 어디를 거쳐 갔는지 따라가려면 요청마다 고유 번호를 달고 로그를 한곳에 모아야 한다.

되돌리기가 어려워진다. 하나로 붙어 있을 땐 중간에 실패하면 데이터베이스가 알아서 전부 취소해줬다. 여러 덩어리에 걸친 작업은 그게 안 된다. 잠깐 데이터가 안 맞는 상태를 견디면서, 실패했을 때 되돌리는 로직을 직접 짜야 한다.

약속을 관리해야 한다. A와 B를 동시에 배포할 수 없으니, 주고받는 형식이 바뀌어도 당분간은 예전 형식도 받아줘야 한다.

덩어리를 쪼개는 것 자체는 어렵지 않다. 비싼 건 쪼갠 다음이다.

팀 이야기

2판에서 무게가 실린 부분이다. 8장에서 콘웨이의 법칙으로 짧게 나왔던 이야기가 좀 더 구체적인 팀 모델로 이어진다.

text
스트림 정렬팀      하나의 기능 흐름을 처음부터 끝까지 책임진다
플랫폼팀           다른 팀이 쓸 공통 기반을 만들어준다
인에이블링팀       다른 팀의 실력을 끌어올려준다
복잡 서브시스템팀  전문 지식이 필요한 영역을 맡는다

핵심은 한 팀이 머리에 담을 수 있는 양에 한계가 있다는 것이다. 아키텍처 경계는 그 한계를 넘지 않게 그어야 한다.

팀이 다섯 명인데 서비스가 서른 개면, 아무리 좋은 스타일도 소용없다.

프론트엔드에서 생각해보면

여덟 가지 착각을 읽는 내내 마이크로 프론트엔드가 떠올랐다. 브라우저 안에서 도는 코드라 감이 잘 안 왔는데, 네트워크를 건너는 순간 똑같은 문제를 겪는 거였다.

  • 호출이 즉시 도착한다는 착각 - 원격 모듈을 그때그때 받아오면 첫 화면이 느려진다
  • 대역폭이 공짜라는 착각 - 조각마다 리액트를 따로 물고 오면 중복이 쌓인다
  • 구성이 안 바뀐다는 착각 - 조각 하나가 죽었을 때 껍데기 앱은 어떻게 되는가

약속 관리 문제도 똑같다. 껍데기와 조각이 주고받는 props 형태가 바뀌는데 둘을 같이 배포할 수 없다면, 그게 딱 서비스끼리 약속 맞추는 문제다.

팀 이야기도 남는다. 에디터 하나를 여러 팀이 나눈다면, 그 선을 기술(렌더링/상태/UI)로 긋느냐 기능(문서/협업/내보내기)으로 긋느냐에 따라 완전히 다른 제품이 나올 것 같다.

정리

9장은 답을 주는 장이 아니라 질문을 정리해주는 장이었다.

기술로 쪼갤지 도메인으로 쪼갤지, 배포 덩어리를 하나로 둘지 여럿으로 나눌지. 그리고 여럿으로 갈 거면 네트워크와 되돌리기와 약속 관리에 드는 값을 미리 계산해보라는 것.

10장부터는 이 자 위에 실제 스타일을 하나씩 올려놓는다. 시작은 기술로 쪼갠 덩어리 하나, 레이어드다.

레퍼런스

  • Mark Richards, Neal Ford, Fundamentals of Software Architecture, 2nd Edition - Chapter 9, Foundations