Architecture

모놀리스가 무너지는 순간은 갑자기 오지 않는다 우리가 운영하던 커머스 플랫폼은 초창기엔 단 하나의 Spring Boot 애플리케이션이었습니다. 주문, 결제, 회원, 상품, 배송이 하나의 코드베이스에 공존했고, 초기에는 그것이 오히려 장점이었습니다. 그러다 팀이 세 배로 늘고 하루 배포 횟수가 두 자릿수를

읽기와 쓰기가 같은 모델을 공유할 때 생기는 일 결제 시스템을 운영하다 보면 특이한 현상을 목격하게 됩니다. 쓰기 트래픽이 몰리는 시간대에 주문 목록 조회가 같이 느려집니다. 원인을 추적하면 항상 같은 곳에 도달합니다. 쓰기와 읽기가 동일한 테이블, 동일한 인덱스, 동일한 ORM 모델을 공유하고 있다는

배포와 출시를 분리한다는 것 Feature flag의 가장 큰 가치는 배포(deploy)와 출시(release)를 분리하는 것입니다. 코드는 production에 배포하되, 기능은 특정 사용자에게만 켜거나 아예 꺼둘 수 있습니다. 이 단순한 분리가 배포 리스크를 크게 낮춥니다. 문제가 생기면 rollba

결제는 성공했는데 메시지는 사라졌다 분산 시스템에서 가장 불편한 진실은 "데이터베이스 커밋"과 "메시지 발행"을 하나의 원자적 동작으로 묶기 어렵다는 점입니다. 주문 서비스가 결제를 승인하고 orders 테이블에 상태를 저장한 뒤, Kafka나 RabbitMQ로 OrderPaid 이벤트를 발행한다고 가정

마이크로 프론트엔드(Micro frontends) 아키텍처는 현대의 거대한 웹 애플리케이션 개발에서 파생된 복잡성을 해결하기 위한 가장 강력한 대안 중 하나로 자리 잡았습니다. 백엔드의 마이크로서비스 아키텍처(MSA)가 서비스 간의 결합도를 낮추고 각 서비스의 독립적인 발전을 이끌어냈듯이, 마이크로 프론

프론트엔드 모노레포: 파편화된 코드 베이스를 넘어 거대한 협업 생태계로 기업이 성장하고 서비스가 확장됨에 따라 프론트엔드 코드의 복잡도는 기하급수적으로 증가합니다. 여러 개의 웹 앱, 공통 UI 컴포넌트 라이브러리, 유틸리티 함수, 그리고 백엔드와 공유하는 타입 정의까지. 이 모든 것을 각각의 별도 저장

마이크로 프론트엔드: 거대한 프론트엔드 모놀리스를 해체하는 기술 현대 웹 애플리케이션은 하나의 거대한 프론트엔드(Frontend Monolith)로 시작하여, 시간이 지남에 따라 수십만 줄의 코드와 수백 개의 컴포넌트를 품은 괴물로 성장하는 경우가 허다합니다. 이러한 모놀리식 프론트엔드는 초기에는 빠르게