[TIL] 클라우드 네이티브와 MSA의 구조·설계 원칙

About this offer

1. 오늘의 한 줄 요약 MSA는 단순히 애플리케이션을 잘게 나누는 기술이 아니라, 비즈니스 경계에 따라 독립 배포 가능한 서비스를 만들고 게이트웨이·서비스 디스커버리·설정 관리·메시징·관측·CI/CD 같은 외부 지원 체계로 운영 복잡성을 감당하는 아키텍처다. 2. 배운 내용 핵심 개념: 모놀리식 아키텍처는 UI, 비즈니스 로직, 데이터 접근과 배포 단위를 하나로 묶는다. 구현·탐색·디버깅·배포가 단순하고 내부 함수 호출이라 빠르지만, 결합도가 높고 일부 변경도 전체 빌드·테스트·배포가 필요하며 기술 선택과 선택적 확장에 제약이 있다. MSA는 사용자·상품·주문·결제·배송처럼 비즈니스 능력과 경계가 분명한 단위로 서비스를 분리한다. 각 서비스는 독립적으로 개발·배포·확장하고 전용 데이터 저장소와 적합한 언어를 선택할 수 있지만, 네트워크 지연·분산 추적·배포 자동화·장애 격리·데이터 일관성이라는 새 문제가 생긴다. 클라우드 네이티브 애플리케이션의 핵심 축은 마이크로서비스, CI/CD, DevOps, 컨테이너다. 자동 확장, 회복 탄력성, 카오스 엔지니어링, 지속적 배포가 변화에 강한 시스템을 만든다. 12-Factor는 코드베이스, 명시적 의존성, 설정 분리, 외부 backing service, 빌드·릴리스·실행 분리, stateless 프로세스, 포트 바인딩, 동시성, 빠른 시작·종료, 환경 동등성, 로그 스트림, 관리 프로세스를 강조한다. API First·Telemetry·인증/인가, Observability·Containerization·Automation도 보완 원칙으로 소개됐다. MSA 표준 구성은 비즈니스 로직인 이너 아키텍처와 이를 지원하는 아우터 아키텍처로 나뉜다. 아우터에는 API Gateway, Service Mesh/Discovery, Config Store, Runtime/Container, Backing Service, Telemetry, CI/CD가 포함된다. API Gateway는 단일 진입점에서 라우팅·로드 밸런싱·정책·인증을 처리한다. Service Discovery(Eureka)는 서비스의 IP와 포트를 등록·탐색·갱신해 주소 하드코딩을 없앤다. 동기 통신은 REST API처럼 응답을 기다리고, 비동기 통신은 Kafka/RabbitMQ 같은 메시지 브로커에 발행(Publish)하고 구독(Subscribe)한다. 서비스별 DB 때문에 단일 트랜잭션을 걸기 어려워 Saga와 보상 트랜잭션으로 실패한 앞 단계의 작업을 되돌리고 최종적 일관성을 허용한다. REST API는 URI에 복수형 명사로 리소스를 표현하고 HTTP 메서드로 행위를 표현한다. GET은 조회, POST는 생성, PUT은 전체 수정, PATCH는 일부 수정, DELETE는 삭제이며, 적절한 상태 코드와 일관된 엔드포인트를 사용하고 민감정보를 URI에 넣지 않는다. 새롭게 알게 된 점: MSA 도입 여부는 유행이 아니라 변화 빈도, 독립 생명주기, 독립 확장성, 장애 격리, 외부 의존성 단순화, polyglot 기술 선택이 실제로 필요한지로 판단해야 한다. 스케일 아웃은 같은 서비스 인스턴스 수를 늘려 요청량을 분산하고, 스케일 업은 한 인스턴스의 CPU·메모리 사양을 높인다. MSA의 장점은 부하가 몰린 서비스만 선택적으로 스케일 아웃할 수 있다는 점이다. VM은 하이퍼바이저 위에 게스트 OS까지 가지지만 컨테이너는 호스트 커널을 공유하고 실행 영역만 격리하므로 더 가볍고 빠르게 확장된다. Docker 이미지는 설계도, 실행된 결과는 컨테이너에 대응한다. 프레임워크와 라이브러리의 핵심 차이는 제어의 주체다. 라이브러리는 내 코드가 호출하지만 프레임워크는 정해진 구조와 생명주기 안에서 내 코드를 호출한다. 헷갈렸던 점: MSA라고 항상 더 좋은 것은 아니다. 작은 서비스나 강한 실시간 일관성이 중요한 영역에서는 모놀리스가 더 단순하고 빠를 수 있고, 필요하면 두 방식을 섞은 하이브리드 구조도 가능하다. 서비스 메시를 단일 제품으로 보기 쉽지만, 강의에서는 서비스 간 통신에 필요한 디스커버리·라우팅·로드 밸런싱·인증·회복 탄력성·암호화 같은 공통 기능을 묶은 인프라 계층이라는 추상 개념으로 설명했다. CI의 범위는 코드 병합만이 아니라 자동 빌드와 테스트까지이고, CD는 전달(Delivery) 또는 배포(Deployment) 자동화로 이어진다. 3. 실습 / 적용 직접 해본 것: 강의 구성도에서 요청 흐름을 클라이언트 → API Gateway → 라우팅/로드 밸런싱 → 마이크로서비스 → 서비스별 DB 로 추적하고, Service Discovery와 Config Store가 이 흐름을 어떻게 지원하는지 정리했다. REST 엔드포인트를 /users , /users/{id} 처럼 설계하고 GET·POST·PUT·PATCH·DELETE에 CRUD 동작을 대응시켰다. 개발환경 준비 항목으로 IntelliJ IDEA, Git, Postman, JDK 17 이상, Maven을 확인하고 java -version , git --version , mvn -version 으로 설치 상태를 검사하는 절차를 정리했다. 결과: MSA의 장점만 나열하는 수준을 넘어, 서비스 분리로 생긴 운영 복잡성을 어떤 아우터 아키텍처가 해결하는지 한 흐름으로 설명할 수 있게 됐다. Postman이 UI 없이 REST API의 메서드·헤더·본문·응답을 시험하는 도구이고, Maven의 bin 경로를 PATH에 넣어야 어느 디렉터리에서나 mvn 을 실행할 수 있다는 점을 확인했다. 4. 문제와 해결 막힌 부분: 서비스마다 DB가 분리되면 한 번의 로컬 트랜잭션으로 전체 작업을 원자적으로 되돌릴 수 없고, 서비스 주소도 인스턴스 증감과 재배포로 계속 바뀐다. 해결 방법: 분산 데이터 변경은 Saga와 보상 트랜잭션으로 실패 이전의 완료 작업을 반대로 실행하며 최종적 일관성을 맞춘다. 동적 주소 문제는 각 서비스가 Eureka 같은 Service Discovery에 자신을 등록하고 Gateway와 다른 서비스가 레지스트리 정보를 주기적으로 갱신하도록 해결한다. 5. 다음에 할 일 IntelliJ에서 Spring Boot 3.5 / Java 17 이상 프로젝트를 만들고 Maven 빌드와 실행을 터미널에서 재현하기 /users REST API를 만들고 Postman으로 CRUD, 상태 코드, PUT/PATCH 차이를 검증하기