183. 마이크로서비스 샤시 (Microservice Chassis) 패턴

⚠️ 이 문서는 MSA 환경에서 수십~수백 개의 서비스를 개발할 때, 개발자가 매번 로깅, 메트릭 수집, 분산 추적, 외부 설정 연동 같은 '인프라 연결 코드'를 짜느라 시간을 낭비하지 않도록, 자동으로 공통 뼈대가 세팅된 빈 껍데기 프레임워크를 제공하는 '마이크로서비스 샤시' 패턴을 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 자동차 산업에서 엔진과 바퀴가 달린 기본 차대(Chassis, 섀시)를 만들어두고 그 위에 껍데기만 바꿔 끼우듯, 마이크로서비스 개발의 60%를 차지하는 비기능적 요구사항(횡단 관심사)이 이미 구현된 '스타터 템플릿'이다.
  2. 가치: 회사의 100번째 마이크로서비스를 만들 때, 개발자는 데이터베이스 연결이나 ELK 로깅 세팅, 헬스 체크 API를 0부터 짤 필요 없이 오직 '비즈니스 핵심 로직'만 바로 타이핑하면 되므로 개발 생산성이 10배 이상 폭발한다.
  3. 기술 체계: Java 진영의 Spring Boot Starter(예: spring-boot-starter-actuator, sleuth), Go 언어의 Micro, Go kit 등이 언어별 샤시 프레임워크의 대표적인 형태다.

Ⅰ. 수백 개의 서비스: 바퀴의 중복 발명과 기술 부채

MSA는 코드가 작아지는 대신 프로젝트 생성이 기하급수적으로 많아진다.

  1. 횡단 관심사 (Cross-cutting Concerns)의 압박:
    • 아무리 작은 '결제 서비스' 하나를 띄우려 해도 반드시 포함되어야 하는 기본 기능들이 있다. (로깅, 모니터링용 /health API, 데이터베이스 커넥션 풀, 인증 토큰 파싱, 중앙 설정 서버 연동 등)
  2. 사일로화된 개발의 문제:
    • A팀은 로깅을 파일로 남기고, B팀은 Logstash로 쏘는 등 개발팀마다 인프라 코드를 다르게 짜면, 중앙 운영팀(Ops)은 일관된 모니터링을 할 수 없다.
  3. 샤시 패턴의 도입:
    • 플랫폼/아키텍처 팀에서 "우리 회사 표준 DB, 표준 로깅, 표준 보안 모듈이 몽땅 들어가 있는 뼈대 코드"를 찍어내는 템플릿(Chassis)을 만들어 전사에 배포하여 표준화를 강제한다.

📢 섹션 요약 비유: 건물을 하나 지을 때마다 개발자가 직접 시멘트 배합법(로깅)을 연구하고 상하수도 파이프(모니터링) 규격을 고민하는 대신, 회사가 제공하는 '골조와 배관이 이미 다 깔려있는 모듈형 조립식 컨테이너(샤시)' 안에 들어가 인테리어(비즈니스 로직)만 꾸미게 만드는 것입니다.

Ⅱ. 샤시(Chassis) 프레임워크의 핵심 구성 요소

샤시는 서비스가 클라우드 인프라와 즉시 대화할 수 있는 플러그 앤 플레이 구조다.

  1. 관측 가능성 (Observability) 자동화:
    • 분산 추적 (Distributed Tracing): 클라이언트의 요청이 들어오면 모든 로그에 자동으로 고유 ID(Trace ID)를 찍어 여러 서비스를 건너뛰어도 한눈에 로그를 추적할 수 있게 해준다. (Zipkin, Jaeger 연동)
    • 메트릭 (Metrics): 메모리 사용량, API 응답 속도 등을 프로메테우스(Prometheus)가 긁어갈 수 있게 표준 포맷으로 실시간 노출한다.
  2. 복원력 (Resiliency):
    • 외부 API를 호출할 때 타임아웃, 재시도(Retry), 서킷 브레이커(Circuit Breaker) 패턴을 코드가 아닌 간단한 설정(Annotation 등)으로 즉시 적용할 수 있게 뼈대에 내장되어 있다.
  3. 외부화된 설정 (Externalized Configuration):
    • 소스코드 안에 암호를 넣지 않고, 부팅 시점에 AWS Parameter Store나 Spring Cloud Config에서 자동으로 환경 설정(DB 접속 정보 등)을 주입받는 로직이 구현되어 있다.

📢 섹션 요약 비유: 자동차의 뼈대(샤시)에는 바퀴뿐만 아니라, 엔진 온도 계기판(메트릭 측정), 브레이크 잠김 방지 장치(서킷 브레이커), 그리고 정비소 컴퓨터와 무선으로 연결되는 진단 포트(분산 추적)가 공장 출고 시부터 이미 깔려 나오는 것과 같습니다.

Ⅲ. 서비스 메시(Service Mesh)와의 충돌과 조화

샤시 패턴은 최근 등장한 '서비스 메시(Istio 등)'와 종종 역할을 다투게 된다.

  1. 샤시(코드) vs 메시(인프라):
    • 샤시 패턴은 Java나 Go 같은 특정 프로그래밍 언어의 라이브러리(코드) 형태로 앱 안에 컴파일되어 들어간다 (In-Process). 언어가 다르면 샤시도 새로 만들어야 한다.
    • 반면 서비스 메시(사이드카)는 언어에 상관없이 앱 밖에서 네트워크를 가로채어 통제한다 (Out-of-Process).
  2. 역할의 분배 (Trend):
    • 최근에는 서킷 브레이커, 타임아웃, 암호화 통신 등 네트워크 관련 횡단 관심사는 무거운 코드 샤시에서 빼내어 '서비스 메시'에게 넘겨버리는 추세다.
    • 반면 애플리케이션 내부의 헬스체크, 로그 포맷팅, DB 커넥션 관리 같은 코드 결합성이 높은 기능만 샤시(Spring Boot 등)에 남겨 가볍게 만드는 하이브리드 아키텍처가 대세가 되고 있다.

📢 섹션 요약 비유: 과거에는 뼈대(샤시)에 복잡한 통신 장비까지 다 우겨 넣었는데, 통신 방식이 바뀔 때마다 차를 리콜해야 해서 피곤해졌습니다. 그래서 요즘은 통신 장비는 오토바이 옆의 '사이드카(메시)'로 떼어내고, 샤시에는 엔진과 배터리(앱 핵심 인프라)만 남겨 날렵하게 만드는 추세입니다.