https://waylog.pages.dev/category/architecture Waylog Blog의 Architecture 카테고리에 속한 글 모음 ko-KR Thu, 21 May 2026 13:50:29 GMT Fri, 03 Apr 2026 00:00:00 GMT Next.js https://waylog.pages.dev/posts/domain-driven-design-aggregate-bounded-context https://waylog.pages.dev/posts/domain-driven-design-aggregate-bounded-context Fri, 03 Apr 2026 00:00:00 GMT Architecture 모놀리스가 무너지는 순간은 갑자기 오지 않는다 우리가 운영하던 커머스 플랫폼은 초창기엔 단 하나의 Spring Boot 애플리케이션이었습니다. 주문, 결제, 회원, 상품, 배송이 하나의 코드베이스에 공존했고, 초기에는 그것이 오히려 장점이었습니다. 그러다 팀이 세 배로 늘고 하루 배포 횟수가 두 자릿수를 넘기 시작하면서 상황이 달라졌습니다. 이 상황의 진짜 원인은 기술 부채가 아니었습니다. 도메인 경계가 코드에 반영되지 않은 것이 문제였습니다. 도메인 주도 설계(DDD)는 이 문제를 소프트웨어 구 https://waylog.pages.dev/posts/cqrs-event-sourcing-read-write-separation-real-world https://waylog.pages.dev/posts/cqrs-event-sourcing-read-write-separation-real-world Fri, 12 Dec 2025 00:00:00 GMT Architecture 읽기와 쓰기가 같은 모델을 공유할 때 생기는 일 결제 시스템을 운영하다 보면 특이한 현상을 목격하게 됩니다. 쓰기 트래픽이 몰리는 시간대에 주문 목록 조회가 같이 느려집니다. 원인을 추적하면 항상 같은 곳에 도달합니다. 쓰기와 읽기가 동일한 테이블, 동일한 인덱스, 동일한 ORM 모델을 공유하고 있다는 사실입니다. 결제 상태를 업데이트하는 트랜잭션이 걸어 둔 행 잠금이 조회 쿼리의 응답 시간을 끌어올립니다. 인덱스를 쓰기에 맞게 최적화하면 조회 성능이 떨어지고, 조회를 위한 컬럼을 추가하면 쓰기 https://waylog.pages.dev/posts/feature-flags-progressive-delivery-cleanup https://waylog.pages.dev/posts/feature-flags-progressive-delivery-cleanup Wed, 29 Oct 2025 00:00:00 GMT Architecture 배포와 출시를 분리한다는 것 Feature flag의 가장 큰 가치는 배포(deploy)와 출시(release)를 분리하는 것입니다. 코드는 production에 배포하되, 기능은 특정 사용자에게만 켜거나 아예 꺼둘 수 있습니다. 이 단순한 분리가 배포 리스크를 크게 낮춥니다. 문제가 생기면 rollback 대신 flag를 끄고, 새 기능은 내부 사용자부터 천천히 열 수 있습니다. 하지만 feature flag는 잘못 운영하면 또 다른 복잡도가 됩니다. 오래된 flag가 코드 곳곳에 남고, 어떤 https://waylog.pages.dev/posts/transactional-outbox-idempotency-distributed-systems https://waylog.pages.dev/posts/transactional-outbox-idempotency-distributed-systems Fri, 22 Aug 2025 00:00:00 GMT Architecture 결제는 성공했는데 메시지는 사라졌다 분산 시스템에서 가장 불편한 진실은 "데이터베이스 커밋"과 "메시지 발행"을 하나의 원자적 동작으로 묶기 어렵다는 점입니다. 주문 서비스가 결제를 승인하고 orders 테이블에 상태를 저장한 뒤, Kafka나 RabbitMQ로 OrderPaid 이벤트를 발행한다고 가정해봅시다. 평소에는 아무 문제 없이 동작합니다. 그런데 데이터베이스 커밋 직후 애플리케이션 프로세스가 죽거나, 메시지 브로커 연결이 순간적으로 끊기면 어떤 일이 벌어질까요? 주문은 이미 결제 완료 https://waylog.pages.dev/posts/micro-frontends-deep-dive https://waylog.pages.dev/posts/micro-frontends-deep-dive Thu, 28 Nov 2024 00:00:00 GMT Architecture 마이크로 프론트엔드(Micro-frontends) 아키텍처는 현대의 거대한 웹 애플리케이션 개발에서 파생된 복잡성을 해결하기 위한 가장 강력한 대안 중 하나로 자리 잡았습니다. 백엔드의 마이크로서비스 아키텍처(MSA)가 서비스 간의 결합도를 낮추고 각 서비스의 독립적인 발전을 이끌어냈듯이, 마이크로 프론트엔드는 프론트엔드 모놀리스(Monolith)의 한계를 극복하고 대규모 개발 조직이 수직적으로 기능을 소유하고 배포할 수 있는 환경을 제공합니다. 본 포스트에서는 마이크로 프론트엔드의 이론적 배경부 https://waylog.pages.dev/posts/frontend-monorepo-architecture https://waylog.pages.dev/posts/frontend-monorepo-architecture Fri, 01 Nov 2024 00:00:00 GMT Architecture 프론트엔드 모노레포: 파편화된 코드 베이스를 넘어 거대한 협업 생태계로 기업이 성장하고 서비스가 확장됨에 따라 프론트엔드 코드의 복잡도는 기하급수적으로 증가합니다. 여러 개의 웹 앱, 공통 UI 컴포넌트 라이브러리, 유틸리티 함수, 그리고 백엔드와 공유하는 타입 정의까지. 이 모든 것을 각각의 별도 저장소(Repo)로 관리하면 어떤 일이 벌어질까요? 버전 관리의 지옥(Dependency Hell), 중복되는 설정 코드(Config drift), 그리고 한 곳의 변경이 다른 곳에 미치는 영향을 파악 https://waylog.pages.dev/posts/micro-frontends-architecture https://waylog.pages.dev/posts/micro-frontends-architecture Tue, 29 Oct 2024 00:00:00 GMT Architecture 마이크로 프론트엔드: 거대한 프론트엔드 모놀리스를 해체하는 기술 현대 웹 애플리케이션은 하나의 거대한 프론트엔드(Frontend Monolith)로 시작하여, 시간이 지남에 따라 수십만 줄의 코드와 수백 개의 컴포넌트를 품은 괴물로 성장하는 경우가 허다합니다. 이러한 모놀리식 프론트엔드는 초기에는 빠르게 개발할 수 있는 장점이 있지만, 규모가 커지면 빌드 시간의 폭증, 팀 간 코드 충돌, 그리고 기술 스택 고착화라는 치명적인 문제에 직면합니다. 백엔드에서는 이미 마이크로서비스 아키텍처(MSA)가