푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 178편 · 1 / 18 페이지)
-
-
이커머스에서 *진짜 어려운 건 코드가 아니다* — 재고 drift·쿠폰 부담 책임·정산 회계·환불 7일·셀러 분쟁 같은 *비기술* 문제 7가지의 *기술 설계 침투* 패턴
이커머스 시스템을 기술적으로 완벽하게 만들어 놓고도 — 결제가 P99 100ms 에 들어오고, 정산이 5분 안에 끝나고, ArchUnit 으로 헥사고날 경계까지 강제했는데도 — 서비스가 안 굴러가는 순간들 이 있다. 그건 코드 버그가 아니다. 재고 숫자가 맞지 않고, 쿠폰을 누가 부담할지 합의가 없고, 세금계산서를 언제 발행하는지 회계팀이 모르고, 환불 거부에 소비자원이 들어오고, 셀러가 가격을 비합리적으로 올리는데도 막을 권한이 없는 — 코드 한 줄로는 절대 풀 수 없는 문제들이다.
-
이커머스 SaaS 의 *가장 큰 적* 은 *트래픽* 이다 — *Edge 부터 DB 까지* 모든 layer 에서 *기술적으로* 막을 수 있는 것들
이커머스 SaaS 를 1 년 운영해보면 알게 된다 — 기능 추가 보다 트래픽 폭주 가 더 자주 더 비싸게 서비스를 망가뜨린다.
-
*물류 SaaS 와 이커머스 SaaS 는 *겉으로는 같은 SaaS — 안쪽 도메인의 *시간축·정합성·외부 N면 연동* 이 *완전히 다른 시스템* 을 강제하는 이유 *7 가지*
이 글은 두 SaaS 도메인의 *내부 구조 차이 를 직접 시스템을 설계해 본 경험 으로 풀어쓴 비교 노트다. 물류 SaaS (WMS/OMS/TMS/LMS) 와 이커머스 SaaS (Shopify, Cafe24, NHN Commerce 류) 는 멀리서 보면 같은 *클라우드 형 B2B 도구 처럼 보이지만, 안쪽으로 들어가면 *데이터 모델·트랜잭션 패턴·SLA 정의·정합성 정의·외부 연동 구조 가 서로 다른 시스템 을 강요한다.
-
ES OOMKilled / SPOF / 백업 부재 — *하룻밤* 안에 production 약점 4 가지를 *진단 → 처방 → 코드 박제* 까지 끝낸 흐름
봇이 르무엘 CPU 부하 알림 을 보낸 새벽 0 시. 단순한 CPU 확인으로 시작한 production 서비스 점검 이 4 가지 약점 동시 발견 → 진단 → 처방 → 검증 → GitOps 코드 박제 까지 5 시간 안에 끝나는 압축 운영 사이클 이 됐다. ES OOMKilled / replica 1 SPOF / 백업 부재 / 런타임-코드 drift 네 가지를 순서대로 추적 한 기록이다.
-
*청각 재활 훈련 웹앱 ASAT (eln.lemuel.co.kr)* 의 *프로젝트 구조 · 기술 스택* 과 *K3s 클러스터 위에서 *어떻게 도는가* — *6 Pod* 의 *헥사고날 + GitOps + Web Audio API* 운영 기록
내가 운영 중인 사이트 중 하나인 eln.lemuel.co.kr 의 백엔드/프론트엔드/인프라 전체 그림 정리. 이름은 ASAT (Auditive Spatial Adaptive Training) — 이명 환자와 청각 재활 대상자 의 주파수 / 공간 청각 변별 능력 을 적응형 알고리즘 으로 훈련 시키는 연구용 웹 애플리케이션.
-
이커머스 + 정산 MSA 를 *왜* / *어떻게* 분리했나 — Hexagonal · Outbox · Read-only Projection · K3s GitOps 까지 한 production 서비스의 *전 구조*
운영 중인 이커머스 + 정산 MSA 플랫폼 한 개를 전 layer 한 번에 풀어 본다. 모놀리스에서 시작해 Bounded Context 분리 → 이벤트 드리븐 → Read-only Projection 으로 진화시킨 백엔드와, 그것이 어떻게 K3s 위에서 GitOps 로 굴러가는지 까지. 도메인 분할의 근거, 헥사고날의 경계, Outbox 의 멱등, 그리고 production K3s 의 ArgoCD/Image-updater/Cloudflare Tunnel 까지 — 하나의 그림 안에서 왜 그 선택을 했는가 를 정리한다.
-
*K8s 클러스터에서 R 의 역할을 정리해줘* 라는 질문에서 시작해 — *R 이 거기 없다는 사실* 부터 마주쳤다
토요일 밤, 텔레그램으로 한 줄 던졌다 : “지금 이 쿠버네티스 클러스터에서 R 언어의 역할에 대해서 깃헙블로그에 써줘.”
답을 쓰기 전 답이 있는지 부터 확인했다. 그리고 답은 — K3s 클러스터 안에 R 워크로드는 없다.
-
내 K3s 클러스터의 *모든 시세 데이터* 가 C++ 를 거치는데, *왜 C++ Pod 는 하나도 없는가* — 6 모듈 quant-core 와 K8s 의 *contract 분리*
내 K3s 클러스터 의 ArgoCD 대시보드를 열면 64 개 Application 이 떠 있다. crypto-prod, dart-prod, trading-prod, codingtest-prod, data-prod, sns-prod, lemuel-xr-prod, settlement-prod, sparta-prod, …. 그 중 crypto / dart / trading / codingtest / data / news 6개 사이트는 전부 *시세 / 공시 / 뉴스 / 채점 같은 latency-critical 한 데이터 흐름 위에서 돌아간다. 그런데 그 데이터의 *원천 은 전부 C++ 로 쓰여 있다.
-
Velero Kopia *'실패한 Job' 알람이 풀리지 않은* 진짜 이유 — LimitRange.maxLimitRequestRatio 가 만든 *admission 함정*, 그리고 같은 파일이 ArgoCD root-app 까지 *연쇄 정지* 시킨 *한 줄 스키마 버그*
토요일 저녁 7시쯤, 텔레그램으로 익숙한 형태 의 알람 3건이 도착했다.