개발과 일상을 기록합니다
"MSA의 시작은 Kafka가 아니라 의존 방향이다."모놀리스를 MSA로 나누겠다고 마음먹으면 보통 가장 먼저 드는 생각은 이런 것들이다.Kafka를 붙여야 하나?API Gateway는 뭘 써야 하지?서비스 디스커버리가 필요할까?DB는 언제 분리하지?그런데 실제 프로젝트를 뜯어보면, 진짜 먼저 해야 하는 일은 기술 선택이 아니라 경계 정리다.이번 글에서는 Co-Talk 백엔드에서 MSA 전환을 염두에 두고 진행한 첫 번째 리팩토링, notification 경계 분리 이야기를 정리해보려 한다.핵심은 단순하다.다른 도메인이 notification 모듈의 인바운드 유스케이스를 직접 호출하지 않게 만들기이걸 작은 단계로 해두면, 나중에 notification을 별도 서비스로 떼어낼 때 훨씬 수월해진다.왜 Not..
Series: 선착순 티켓팅 시스템을 만들며Author: Backend Developer (8yr)Date: 2026-03-11Complexity: 중상급1. 이번 글에서 다루는 것선착순 티켓팅에서 가장 치명적인 문제 중 하나는 재고 차감의 동시성 제어입니다.1000명이 동시에 마지막 100장의 티켓을 사려고 할 때:101명째 사용자가 성공해서는 안 됨모든 사용자가 정확히 "100장 판매, 901명 실패"라는 결과를 받아야 함재고가 음수로 가면 절대 안 됨이 글에서는:왜 재고 차감이 어려운가 — 동시성 문제의 본질세 가지 대안 비교 — 낙관적 락, 비관적 락, 분산 락벤치마크 결과 — 실제 측정한 성능 데이터우리의 선택 — 비관적 락을 선택한 이유구현 디테일 — 코드와 함정들동시성 테스트 — 검증 방법회..
Series: 선착순 티켓팅 시스템을 만들며#0. 전체 설계 | #1. 헥사고날 아키텍처 |오픈 당일 30만 명이 3번씩 이벤트 상세를 조회하면? DB에 쿼리가 90만 건 날아간다. 이벤트가 1,000개라면 3억 건. 캐시 없이는 DB가 버틸 수 없다.TL;DR문제해결결과3억 DB 조회Cache-Aside (EventCachePort)캐시 히트 시 DB 쿼리 0DB IDENTITY 의존Snowflake ID (41+10+12 bit)INSERT 전 ID 확정, 분산 안전IllegalArgumentException → 500GlobalExceptionHandler 전면 구축모든 예외가 올바른 HTTP 상태로1. Snowflake ID — DB한테 ID를 물어보지 않는다문제DB IDENTITY(auto-in..
Series: 선착순 티켓팅 시스템을 만들며Date: 2026-03-20Event.java를 열었는데 @Entity, @Column, @Autowired가 뒤섞여 있다면 — 그 도메인은 이미 인프라에 잡아먹힌 것이다.TL;DR문제해결검증도메인 클래스에 JPA/Spring 어노테이션이 침투헥사고날 포트-어댑터로 계층 분리domain/ 패키지에 Spring import 0개"어디에 뭘 넣어야 하지?" 혼란4계층 패키지 규칙 확립디렉터리 구조만 보면 역할이 보임포맷/스타일 리뷰에 시간 낭비Spotless + Google Java Format 자동화./gradlew spotlessCheck CI 게이트1. 문제 — 레이어드에서 도메인이 오염되는 과정전형적인 레이어드 아키텍처(Controller -> Servic..
설계 노트: 이 글은 구현 전 초기 설계를 기록한 것이다. 실제 구현 과정에서 일부 전략이 바뀌었다. 무엇이 왜 바뀌었는지는 이 글 하단과 #3. 재고 동시성에서 설명한다.1) 왜 "대용량 쿠폰 발급 시스템"을 따로 만들기로 했나솔직히 처음엔 "쿠폰 발급이 얼마나 어렵겠어"라는 생각이었다. 그런데 조금만 파고들면 금방 알게 된다. 이벤트 오픈 순간처럼 트래픽이 한꺼번에 몰리는 상황에서 쿠폰 발급을 "정확하게" 처리하는 건 생각보다 훨씬 까다로운 문제라는 걸.그래서 이 프로젝트를 시작했다. 이벤트 오픈 순간의 트래픽 폭주 속에서도 쿠폰 발급의 정합성을 깨지 않으면서, 요청은 빠르게 "접수"하고 결과는 안정적으로 "확정"하는 시스템을 직접 설계하고 구현해보기 위해서다. 이론으로만 알고 있던 것들을 실제로 손..
"배포 전략은 고정이 아니다. 하드웨어 앞에서는 교과서도 접어야 할 때가 있다."이전 글에서 카나리아 롤링 배포를 자랑스럽게 소개했다. app-1, app-2, app-3 세 인스턴스가 동시에 돌아가고, 배포 시엔 한 대씩 교체하며 에러율을 검증하는 구조. 그런데 얼마 지나지 않아 Grafana에서 불편한 숫자를 보게 됐다.CPU 사용률이 배포 중에 100%에 닿았다.이 글은 그 숫자를 보고 카나리아를 포기한 이야기다.CPU가 항복한 순간하드웨어 환경지금 Co-Talk이 돌아가는 곳은 Synology DS923+다. CPU는 Celeron J4125, 4코어. RAM은 20GB로 업그레이드했다. 클라우드 관점에서 보면 t3.small보다 조금 나은 수준이다. 서버라기보다 NAS에 가깝다.이 위에 올라간 ..
"로컬에서 fastlane deploy_all_platforms 치면 되긴 한다. 근데 내 맥북이 2시간 동안 먹통이 되는 건?"백엔드는 이미 GitHub Actions + GHCR + 카나리아 배포 파이프라인이 완성돼 있다(blog-07). 코드 푸시 → 자동 빌드 → 자동 배포, 다 된다. 근데 Flutter 앱은 아직도 내 맥북에서 fastlane deploy_all_platforms 를 직접 치고 있다. 이 명령 한 번이면 iOS, Android, macOS 세 플랫폼이 빌드되고 TestFlight + Google Play로 올라가는데, 그 2시간 동안 맥북으로 다른 일을 못 한다. ( 사실 가능은 하지만 극단적으로 말하자면 그렇다는 것이다. )Fastlane은 이미 준비돼 있다(blog-17)...
"flutter build ios, flutter build macos, flutter build appbundle… 이걸 매번 수동으로?"Flutter 앱을 iOS, macOS, Android 세 플랫폼에 동시에 배포해야 할 때, 수동 빌드는 금방 한계에 부딪힌다. 각 플랫폼마다 빌드 명령이 다르고, 코드 서명 방식이 다르고, 업로드 도구도 다르다. Co-Talk 프로젝트를 운영하면서 이 세 가지를 하나의 Fastfile로 통합한 경험을 정리했다. 특히 macOS 코드 서명은 iOS보다 훨씬 복잡해서 별도 섹션으로 다뤘다. 시리즈 17편이다.1. 통합 Fastfile 설계세 플랫폼을 하나의 Fastfile로 관리하는 핵심 아이디어는 레인(lane) 계층화다. 최상위 레인이 하위 레인을 호출하는 구조로,..
"앱이 잠금 해제될 때마다 비밀번호를 치게 할 순 없잖아?"채팅 앱에서 사용자 경험을 결정짓는 요소는 생각보다 많다. 메시지 전송 속도나 알림 정확도처럼 눈에 띄는 기능만이 아니라, "앱이 어두운 방에서도 눈이 안 아프냐", "자리를 잠깐 비웠다 돌아왔을 때 매번 잠금을 풀어야 하냐", "인터넷이 끊겼을 때 이전 대화를 볼 수 있냐" 같은 것들이 실제 사용 만족도를 좌우한다.이번 편은 co-talk Flutter 앱에서 구현한 세 가지 UX 기능을 다룬다.테마 시스템 — Light/Dark/System 전환 + TextScaler로 전역 폰트 크기 조절생체인증 & 앱 잠금 — Grace Period와 Hybrid 동기/비동기 캐시Drift(SQLite) 오프라인 캐시 — FTS5 전문 검색과 syncSt..
"메시지를 보냈는데 화면에 안 뜬다. 서버 응답을 기다리는 동안 사용자는 뭘 보고 있어야 하지?"실시간 채팅을 구현할 때 가장 먼저 부딪히는 문제가 이거다. 서버 응답 전까지 메시지가 안 뜨면 사용자는 "전송됐나?" 하고 불안해한다. 반면 즉시 화면에 뜨면 앱이 빠르다고 느낀다. 그 차이가 UX의 전부인 셈이다.Co-Talk Flutter 앱의 실시간 채팅은 STOMP over WebSocket으로 동작한다. 연결 관리, 재연결, 메시지 중복 제거, Optimistic UI까지 — 구현하다 보니 단순한 WebSocket 클라이언트가 아니라 꽤 복잡한 시스템이 됐다. 이번 15편에서는 그 전체 구조를 정리한다.1. WebSocket 아키텍처 — Facade + 4 Manager처음엔 WebSocketSer..
"백엔드는 헥사고날로 깔끔한데, 프론트는 왜 이렇게 스파게티지?"백엔드에 헥사고날 아키텍처를 적용하고 나서 프론트엔드 코드를 다시 봤을 때 느낌이 묘했다. 도메인 로직과 HTTP 호출이 위젯 안에 뒤섞여 있고, 상태 관리는 setState와 전역 변수가 혼재했다. 백엔드에서 그토록 강조한 "관심사 분리"가 프론트엔드에서는 적용되지 않고 있었다.그래서 Co-Talk Flutter 앱에도 같은 원칙을 적용하기로 했다. 4레이어 Clean Architecture, GetIt + Injectable 기반 DI, GoRouter와 AuthBloc 통합 라우팅, Cubit과 BLoC의 의식적인 선택. 이 글은 그 설계 과정의 기록이다. 시리즈 14편.1. 왜 Flutter에서도 Clean Architecture인가..
"이번엔 진짜 고쳤어요." — 10번 반복하다 지친 나.1탄에서 5가지 문제를 해결했고, 이번에는 진짜로 끝났다고 생각했다. Flyway 비호환, SecurityFilterChain 충돌, @TestConfiguration 스캔 누락, IP 헤더 불일치, Redis Pub/Sub 레이스 컨디션. 하나씩 파고들어 고쳤고, CI에 올렸다.WebSocket 테스트 4건이 또 실패했다.Should receive chat message when user sends message — FAILShould broadcast when second user joins — FAILShould receive announcement when user leaves room — FAILShould not receive messag..
|
