전체 글83 DDD 야호~! 주문 서비스에 검증, 재고 확인, 가격 계산, 쿠폰 적용, 알림 발송 로직이 한 곳에 뒤섞였다고 생각해 보자. 공포스럽다. 기능이 추가될 때마다 로직이 쌓이고, 결국 누구도 손대기 두려운 코드가 된다. 이 문제를 해결하기 위해 DDD 방법론을 고려할 수 있는데 패턴들을 암기하기보다는 "비즈니스 로직을 어느 객체에 위치시킬 것인가"라는 질문부터 출발하면 된다. 실무에서 제품 개발을 하면서 까다로운 것 중 하나가 도메인 용어를 맞추는 일이다. 현업의 언어와 코드의 언어가 일치하지 않으면 소통과 개발이 매끄럽지가 않은데, 보통 다음과 같다. 기획자는 "주문을 취소한다"라고 표현하는데 코드에서는 다르게 표현된 경우를 생각하면 된다. 이를 유비쿼터스 언어를 통해 해결할 수 있다.유비쿼터스 언어란 도메인 주도 설계.. 2026. 6. 16. PostgreSQL WAL (Write-Ahead Logging) 데이터 구조 MSK 커넥터와 Debezium을 활용해 CDC 환경을 구축하다 보면, 결국 PostgreSQL의 WAL 내부 동작을 깊이 이해해야 하는 순간이 오게 된다. 특히 Debezium은 논리적 디코딩 방식으로 WAL을 읽기 때문에, 복제 슬롯 지연, REPLICA IDENTITY, 그리고 체크포인트와의 상호작용 등을 이해하는 게 중요하다. 본 글에서는 백엔드 개발자의 시선에서 PostgreSQL 17을 기준으로 WAL의 관리 방식과 논리적 디코딩 아키텍처를 정리한다.1. WAL이 해결하는 문제2. WAL 데이터 구조3. LSN (Log Sequence Number)4. WAL 쓰기 흐름5. 체크포인트와 WAL 재활용6. 스트리밍 복제 vs 논리적 복제7. 논리적 디코딩과 복제 슬롯8. Debezium은 WAL.. 2026. 5. 20. 코빗은 왜 체결 엔진에 Rust를 선택했을까? (feat. 추리) 💡 코빗 기술 블로그를 보고 개인적으로 추리한 내용입니다.💡 코빗과는 무관합니다.두 편의 블로그 2025년 9월, 코빗 CTO는 블로그에 「Go와 Rust, 코빗은 이렇게 나눠 씁니다」를 공개했다. 글 중간에 짧은 아키텍처 도식이 있었다.눈에 띄는 점이 있었다. 같은 시스템의 내부를 두 언어로 나눠 놓은 것이다. 더 구체적으로는 체결 엔진과 시세 서비스만 Rust였다.한 달 뒤인 10월 14일, 같은 저자의 후속 글이 올라왔다. 「완전히 새롭게 구축한 코빗의 가상자산 거래 시스템」. 1편이 언어 선택에 초점을 맞췄다면, 2편은 시스템 전체의 설계를 서술했다. Event-Driven Architecture, Kafka 기반 이벤트 버스, Transactional Outbox, Active/Standby.. 2026. 4. 22. Kafka 간 맞추기 Kafka 간보기에 이어서 이번 아티클에서는 이론적인 관점에서 카프카를 탐구하려 한다. 지난 아티클이 구현 리뷰에 초점을 맞췄다면, 이번에는 내부 동작 원리를 바탕으로 카프카에 대한 이해를 한 단계 더 높이는 게 목표다.Kafka를 언제 어떻게 사용하냐면... 왜 Kafka인가? 가장 먼저 이해해야 할 것은 디커플링이다. 서비스가 늘어날수록 시스템은 복잡해지기 마련이다. 스파게티 아키텍처 (문제점): 각 서비스가 서로 직접 연결(Point-to-Point)되어 있어, 하나만 수정해도 전체 시스템에 영향을 전파한다. Kafka 도입 후 (해결책): Kafka를 이벤트 버스로 활용한다. 발행자(Producer)는 데이터를 던지기만 하고, 구독자(Consumer)는 필요한 데이터만 가져간다. 서로의 존재를.. 2026. 4. 20. 샤갈!! 저 Temporal Workflow 엔진 도입했어요!! 이번 아티클은 취미로 진행 중인 사이드 프로젝트 커머스 플랫폼(pick-me)에서 Temporal 워크플로우 엔진을 도입한 과정을 공유한다.1. 왜 Temporal이 필요했는가pick-me는 주문, 결제, 재고, 정산, 파트너를 다루는 이커머스 플랫폼이다. 처음에는 Kafka 기반 코레오그래피 사가 패턴으로 서비스 간 통신을 설계했다.각 서비스가 이벤트를 발행하고 구독하는 구조다. 단순한 흐름에서는 유연한 구조였으나, 도메인이 비대해지면서 코레오그래피 방식의 구조적 한계에 직면하게 되었는데 구체적으로 다음과 같다. ⚙️ 무엇이 문제였나 문제 무엇이 문제였나 어떤 고통이 있었나 트랜잭션 가시성 부재진행 상태를 한눈에 볼 수 있는 곳이 없음장애 발생 시 여러 서비스의 로그를 일일이 대조프로세스 고착이벤트 .. 2026. 4. 12. 와 CDC(Change Data Capture)! Debezium 로그 기반 아시는구나! 이번 아티클은 취미로 진행 중인 사이드 프로젝트 커머스 플랫폼(pick-me)에서 폴링 Relay 방식에서 로그 기반 CDC(Debezium) 방식으로 전환한 이유와 과정을 다룬다.1. CDC란 무엇인가CDC(Change Data Capture)는 데이터베이스에서 발생하는 데이터 변경사항(INSERT, UPDATE, DELETE)을 감지하고 이를 다른 시스템에 전파하는 기술이다.MSA 환경에서는 각 서비스가 독립된 데이터베이스를 가지므로 서비스 간 데이터 일관성을 유지하는 것이 핵심이다. 전통적인 2PC(Two-Phase Commit)는 분산 환경에서 성능과 가용성을 크게 저하시키기 때문에 이벤트 기반의 비동기 데이터 동기화가 사실상 표준이 되었다.pick-me 프로젝트는 8개의 바운디드 컨텍스트 (Or.. 2026. 4. 8. Kafka 간보기 취미로 진행 중인 사이드 프로젝트 커머스 플랫폼(pick-me)에서 Kafka를 사용하면서 배운 점을 정리했다.1. Event Driven Architecture (EDA)Event Driven Architecture는 분산 시스템에서 이벤트의 발행과 구독을 통해 서비스 간 통신을 처리하는 아키텍처다. 동기 통신의 요청-응답(Request-Response) 모델 대신, 비동기 통신의 발행-구독(Pub-Sub) 모델을 사용한다.이벤트가 생성되면 이벤트 로그에 보관되고 해당 이벤트를 필요로 하는 구독자가 이를 받아 처리한다.### EDA 적용 전주문 서비스와 결제, 재고, 통지 서비스가 REST로 동기 통신하는 구조를 가정한다.주문이 생성되면 주문 서비스가 결제 서비스를 직접 호출하고, 결제가 완료되면 다시.. 2026. 4. 7. DDD 안에 객체지향이 있잖아! 취미로 진행 중인 사이드 프로젝트 커머스 플랫폼(pick-me)을 DDD로 설계하면서 느낀 점을 정리했다. DDD(Domain-Driven Design) 전술적 패턴을 처음 공부할 때 묘한 기시감이 들었다.처음에는 "DDD가 OOP를 다른 이름으로 포장한 건가?" 싶었다. 하지만 실제로 코드를 작성해 보니 같은 문제를 다른 관점에서 바라보는 것이었다. OOP가 "좋은 코드 구조"를 추구한다면 DDD는 "좋은 코드 구조가 비즈니스 문제를 정확히 반영하는가"를 추구한다.이 글에서는 pick-me 프로젝트의 실제 코드를 통해 DDD 패턴을 적용하다 보면 왜 자연스럽게 좋은 객체지향 코드가 되는지 이야기해 본다.1. "주문 취소"를 어디에 작성할 것인가프로젝트에서 가장 먼저 부딪힌 질문이다. 주문 취소 로직을 .. 2026. 4. 6. 기술 면접에서 털리고 쓰는 동시성 제어와 멱등성 최근 해외 송금 시스템 관련 과제를 수행하며 데이터 정합성과 시스템 안정성에 대해 고민할 기회가 있었다. 통장에서 돈이 출금되어 환전이 이루어지고, 이 결과가 해외 파트너망으로 전송되기까지의 모든 과정을 안전하게 보장해야 했다. 특히 도메인 특성상 여러 네트워크를 거치며 네트워크 단절이나 타임아웃이 빈번하게 발생하는 환경이었기 때문에, 중복 출금을 막고 장애를 방지하기 위한 동시성 제어와 멱등성 설계가 핵심 과제였다. 이참에 고민했던 동시성 제어와 멱등성 관련 내용을 정리해 본다.동시성 제어다수의 스레드가 공유 자원을 읽고, 수정하고, 다시 쓰는 과정에서 OS 커널의 선점형 스케줄러가 개입하면 어떻게 될까? 연산이 무작위로 교차하며 데이터 정합성이 박살 나는 경쟁 상태가 발생하게 된다. 선점형 스케줄러는.. 2026. 3. 27. 이전 1 2 3 4 ··· 10 다음
