NYO_O

명칭이 왜 중요한가MSA 구조를 처음 설계하다 보면 자연스럽게 이런 고민이 생깁니다. Config를 띄우면 이건 서버인가, 서비스인가. 유레카(Eureka)가 올라가 있는 인스턴스는 어떻게 부르는 게 맞을까. 주문을 처리하는 Order 모듈은 또 어떻고.처음에는 그냥 "다 서비스 아닌가?" 하고 넘겼습니다. 그런데 팀원과 이야기를 나눌 때마다 같은 단어가 다른 의미로 쓰이고 있다는 걸 알게 됐습니다. "서비스 재시작해"라는 말 한 마디에 "어떤 서비스요?"가 자동으로 따라붙는 상황, 한 번쯤 겪어보셨을 겁니다.핵심 질문: 인프라 역할을 하는 컴포넌트와, 실제 비즈니스 로직을 담은 컴포넌트를 같은 이름으로 불러도 되는가.혼란의 출발점 — 모두 "서비스"라고 부르던 시절MSA를 처음 접할 때 보통 "마이크로..

지난 시간, Enum과 계층형 YAML을 결합한 전역 예외 처리 구조를 공통 모듈에 구축하는 방법을 살펴보았습니다. 오늘은 공통 모듈에 담을 두 번째 기능으로 페이징 표준화를 다루어 보겠습니다.2026.05.27 - [Tech/MSA] - 공통 모듈 적용 - 일관된 전역 예외 처리 로직 구축 공통 모듈 적용 - 일관된 전역 예외 처리 로직 구축지난 시간, 공통 모듈을 도메인 서비스에 연동하는 전체 과정을 살펴보았습니다. Auto-configuration을 구성해두면 의존성 선언만으로 공통 모듈의 기능이 각 서비스에 자연스럽게 녹아드는 구조였ddangnyo.tistory.comMSA 환경에서 페이징 처리를 각 서비스에 맡겨두면 서비스마다 허용하는 페이지 크기가 달라지는 문제가 생깁니다."이 서비스는 siz..

지난 시간, 공통 모듈을 도메인 서비스에 연동하는 전체 과정을 살펴보았습니다. Auto-configuration을 구성해두면 의존성 선언만으로 공통 모듈의 기능이 각 서비스에 자연스럽게 녹아드는 구조였습니다.이제 실제로 공통 모듈에 무언가를 담아볼 차례입니다. 가장 먼저 다룰 주제는 예외 처리입니다.MSA 환경에서는 서비스가 여러 개로 나뉘어 있기 때문에, 예외 처리 방식이 서비스마다 제각각이면 프론트엔드 팀은 서비스별로 다른 에러 응답 형식을 모두 파악해야 합니다. 공통 모듈에 예외 처리 로직을 구축해두면 모든 서비스가 동일한 형태의 에러 응답을 보장할 수 있습니다. 오늘은 이 구조를 어떻게 설계하고 구현하는지 정리해 보겠습니다.에러 관리 전략 비교본격적인 구현에 앞서, 에러를 어떻게 관리할 것인지 전..

지난 시간까지 공통 모듈을 설계하고, 배포 파이프라인을 구축하고, 실제로 서비스에 연동하는 과정을 살펴보았습니다. 전역 예외 처리와 페이징 표준화 같은 기능들도 공통 모듈에 하나씩 쌓아왔습니다.2026.05.27 - [Tech/MSA] - 공통 모듈 의존성 주입 및 연동 가이드 공통 모듈 의존성 주입 및 연동 가이드지난 시간, 공통 모듈을 GitHub Packages에 배포하고 GitHub Actions로 자동화 파이프라인을 구성하는 방법을 살펴보았습니다. 이제 패키지 레지스트리에는 우리가 만든 공통 모듈이 버전별로 잘 쌓여ddangnyo.tistory.com그런데 어느 순간 이런 고민이 생기기 시작합니다."공통 모듈이 점점 커지고 있는데, 이대로 계속 하나의 모듈에 모든 걸 담아도 괜찮을까?"처음에는 ..

지난 시간, 공통 모듈을 GitHub Packages에 배포하고 GitHub Actions로 자동화 파이프라인을 구성하는 방법을 살펴보았습니다. 이제 패키지 레지스트리에는 우리가 만든 공통 모듈이 버전별로 잘 쌓여 있는 상태입니다.2026.05.27 - [Tech/MSA] - GitHub Packages를 활용한 공통 모듈 배포 파이프라인 구축 GitHub Packages를 활용한 공통 모듈 배포 파이프라인 구축지난 시간, 공통 모듈에 어떤 내용을 담아야 하는지, 그리고 포함해서는 안 되는 것들은 무엇인지 그 설계 기준을 살펴보았습니다. 비즈니스 로직을 배제하고, 서비스들이 함께 공유하는 기술적ddangnyo.tistory.com그런데 막상 여기까지 오고 나면 새로운 고민이 생깁니다."배포된 공통 모듈을..

지난 시간, 공통 모듈에 어떤 내용을 담아야 하는지, 그리고 포함해서는 안 되는 것들은 무엇인지 그 설계 기준을 살펴보았습니다. 비즈니스 로직을 배제하고, 서비스들이 함께 공유하는 기술적인 규약과 도구 상자를 만드는 것이 핵심이었습니다.2026.05.27 - [Tech/MSA] - 공통 모듈, 무엇을 담고 무엇을 빼야할까? 공통 모듈, 무엇을 담고 무엇을 빼야할까?지난 시간, 우리는 MSA 환경에서 왜 공통 모듈(Common Library)이 필요한 이유에 대해 살펴보았습니다. 서비스가 분산될수록 파편화되는 코드를 관리하기 위해 공통 모듈은 필수적인 선택지입니다.ddangnyo.tistory.com모듈 설계가 어느 정도 갖춰지고 나면 자연스럽게 다음 고민이 생깁니다."잘 만든 공통 모듈을, 어떻게 각 서..

지난 시간, 우리는 MSA 환경에서 왜 공통 모듈(Common Library)이 필요한 이유에 대해 살펴보았습니다. 서비스가 분산될수록 파편화되는 코드를 관리하기 위해 공통 모듈은 필수적인 선택지입니다. 하지만 막상 모듈을 만들고 나면 새로운 고민이 시작됩니다."공통 모듈에 어디까지 넣어야 할까요?"너무 많이 넣으면 서비스 간 결합도가 높아져 MSA의 독립성을 해치고, 너무 적게 넣으면 모듈을 사용하는 의미가 퇴색됩니다. 오늘은 공통 모듈을 설계할 때 반드시 지켜야 할 기준과 포함해야 할 핵심 요소들을 정리해 보겠습니다.공통 모듈 설계의 핵심 원칙: 응집도와 결합도공통 모듈에 코드를 추가하기 전에 항상 다음 두 가지 질문을 던져보아야 합니다.모든 도메인 서비스에서 공통으로 사용하는가?비즈니스 로직(업무 ..

지금까지 다룬 내용들을 통해 인프라 관점에서의 MSA 설계는 어느 정도 마무리가 되었습니다. 이제 개발팀은 모놀리식 통짜 프로젝트를 30개의 마이크로서비스 프로젝트로 물리적으로 분리하는 데 성공했습니다. 각 서비스는 각자의 데이터베이스를 가지며, 필요에 따라 유연하게 스케일 아웃(Scale-out)됩니다.하지만 물리적인 인프라가 완벽하게 분리되었다고 해서 개발자들의 고통이 끝나는 것은 아닙니다. 오히려 '코드 레벨'에서는 새로운 재앙이 시작됩니다. 클라이언트의 요청이 들어오면 모든 서비스는 공통적으로 사용자의 JWT 토큰을 파싱하고 검증해야 합니다. 또한, 일관된 규격으로 로그를 남겨야 하며, 비즈니스 예외가 발생했을 때 프론트엔드에게 동일한 형태의 JSON 에러 응답 구조를 내려주어야 합니다.만약 이 ..