Fall in IT.

전통적인 모놀리식(Monolithic) 아키텍처에서 마이크로소프트 아키텍처(MSA)로의 전환은 이제 거스를 수 없는 흐름이 되었다. MSA는 서비스의 독립적인 개발과 배포를 가능하게 하여 조직의 생산성을 극대화하는 강력한 장점을 가지고 있다. 하지만 서비스가 잘게 쪼개지고, 하나의 요청이 여러 서비스 간의 복잡한 네트워크 호출로 이어지면서 새로운 문제가 발생했다. 바로 시스템의 동작을 이해하고 추적하기가 극도로 어려워졌다는 점이다.과거 모놀리식 환경에서는 CPU, Memory 사용률과 같은 시스템 매트릭과 로그 파일만 잘 확인해도 장애의 원인을 비교적 쉽게 파악할 수 있었다. 그러나 MSA 환경에서는 문제가 발생했을 때, 수많은 서비스 중 어느 곳에서 문제가 시작되었고, 그 여파가 어디까지 미쳤는지 파악..

MSA 아키텍처로 여러 서비스를 운영하면서, 저는 도메인 단위로 유스케이스를 묶는 구조를 사용해 왔습니다.예를 들어, User 서비스에서는인증 관련 로직은 AuthUsecase회원 정보 관련 로직은 UserUsecase이렇게 기능별로 Usecase를 구분해 구성했습니다.AuthUsecase에는 이메일 인증, 휴대폰 인증, 본인 인증 등을, UserUsecase에는 회원가입, 로그인, 유저 정보 조회, 비밀번호 재설정 등 다양한 메서드를 구현해 관리했습니다.처음에는 이 구조가 충분히 단순하고 효과적이었습니다. 하지만 서비스가 점차 확장되고 비즈니스 요구사항이 복잡해지면서 한계가 드러났습니다.문제의 시작: 사용자 유형에 따른 분기 증가시간이 지나면서 User 서비스는 B2B와 B2C 사용자를 동시에 지원하게..