Backend Engineer경력 3년 5개월
설로인(회원 약 44만 명, 비회원 포함 최대 MAU 약 80만)에서 커머스 서비스와 어드민 전체를 맡아 주문·결제, 홈·전시(홈 화면, 기획전, 타임딜), 쿠폰·마일리지, 프로모션, 알림, CRM을 개발·운영합니다.
주요 성과
01 about
2023년 5월부터 백엔드 개발을 하고 있습니다. 지금은 설로인에서 커머스 서비스와 어드민을 맡고 있고, 그중 주문·결제와 메시징, 고객이 처음 보는 홈 화면·기획전·타임딜 같은 전시 영역을 주로 다룹니다.
성능, 결제 안정성처럼 사용자가 바로 느끼는 문제를 원인부터 찾아 구조로 고치는 일을 가장 많이 해 왔습니다.
아임포트와 토스페이먼츠를 함께 운영하다가 토스로 단일화했습니다. 그 과정에서 웹훅과 결제 처리의 락 키가 달라 중복 결제가 날 수 있는 잠재 결함을 찾아 수정했습니다.
운영 장애 4건(큐 소비 약 90시간 정지, 워커 OOM, 쿠폰 동시 발급 유실, 택배 API 무응답)의 원인을 찾아 수정했습니다.
결제 후속 처리를 아웃박스로 분리해 운영 30일 발행·저장 실패 0건을 유지하고 있고, 새 알림 경로는 Inbox(message_id)로 같은 알림이 한 번만 나가게 설계했습니다.
관련 글온라인 식품 커머스, 상품 유형에 따라 시스템이 달라진다이제 와서 고쳐보는 2024년의 내 코드
how I work기획 판단, AI 활용, 장애 대응 방식일하는 방식02 experience
총 경력 3년 5개월 (4년차)
문제마다 상황, 과제, 행동, 결과(STAR)로 정리했습니다. 카드를 누르면 자세한 내용이 열립니다.
회원 약 44만 명(비회원 포함 최대 MAU 약 80만) 규모 커머스의 서비스 서버와 어드민 서버를 맡고 있습니다. 주문·결제, 쿠폰·마일리지, 프로모션, 홈·전시, 알림, CRM 기능을 개발하고 운영합니다. 가장 큰 일은 토스페이먼츠 직접 연동이었습니다.
Payment
마케팅 프로모션에 토스 직접 연동이 필요했지만, 결제 코드가 아임포트에 묶여 있었고 운영 결제는 멈출 수 없었습니다.
결제를 멈추지 않고 6가지 흐름을 옮기기. 전환 중 중복 승인 0.
Architecture
월 1만 건 이상의 결제가 WMS를 동기로 호출해, 물류가 느리거나 발행이 실패하면 결제와 후속 처리가 함께 멈췄습니다.
물류가 실패해도 결제는 끝나고, 물류로 보낼 일은 잃지 않게 하기.
관련 글Outbox만으로 충분할까? CDC와 DLQ를 통한 기초적인 이벤트 기반 설계를 알아보자Coroutine과 ReactiveMongo 다중DB 환경에서 @Transactional을 사용해 보자MongoDB의 WiredTiger Engine과 Transaction에 대해서 알아보자
자세히 보기Performance2025.05 ~ 2025.10
명절 최대일 트래픽이 평시의 약 5~10배인데, 홈 바디 조회는 영역을 순서대로 읽어 평균 782ms(k6)였습니다.
명절 전에 홈 응답을 줄이고, 같은 조건으로 다시 재서 확인하기.
관련 글비동기로 성능개선을 한다고? Coroutine, Semaphore, BulkHead로 안정적인 성능 만들기코틀린 코루틴의 정석 (1): 실무 중심으로 다시 공부하는 코루틴
자세히 보기Incident2026.08
큐 선언 실패 세 번에 리스너가 영구 정지해, 그 큐의 소비가 약 90시간 멈췄고 어떤 경보도 울리지 않았습니다.
사람 없이 스스로 복구되고, 멈추면 바로 알기.
Messaging2026.09 ~
설계·구현 전체 담당
월 약 2만 건의 거래성 알림톡을 상주 워커가 직접 보내, 재시도·배포 때 사라지거나 두 번 나갈 수 있었습니다.
같은 알림은 한 번만 보내고, 결과를 모르는 건은 숨기지 않기.
관련 글Outbox만으로 충분할까? CDC와 DLQ를 통한 기초적인 이벤트 기반 설계를 알아보자
자세히 보기Batch2026.09 ~
2인 공동 프로젝트. 본인: 서비스 구조·잡 실행 구조(CronJob 차트·공통 러너)·실패 지점 재개·알림 발송 대기열 중계
결제 후속 처리·알림과 같은 워커에서 스케줄 잡이 겹치면 힙이 넘쳐 OOM이 났고, 피크에 맞춰 키우면 비용이 하루 종일 들었습니다.
잡은 돌 때만 자원을 쓰고, 같은 회차는 한 번만, 끊기면 실패 지점부터.
2차전지 기업의 평가 데이터를 관리하고 모니터링하는 B2B SaaS입니다. 4인 팀(BE 2, FE 2)에서 백엔드를 맡았고, 론칭 후 3개 고객사(삼성전기 등)가 운영했습니다.
Performance
기업별 평가 데이터가 하루 120만 건 이상 쌓이면서 조회가 눈에 띄게 느려졌습니다.
여러 고객사가 함께 쓰는 만큼 기업별 데이터를 분리하면서 조회 속도도 올려야 했습니다.
Cost
배치는 잠깐 도는데 Spring Batch 서버는 상시 떠 있어 유휴 비용과 운영 부담이 컸습니다.
배치가 도는 동안만 자원을 쓰는 구조로 바꾸기로 했습니다.
DevOps
수동 배포에 30분이 걸려 릴리스가 밀리고 실수할 여지가 있었습니다.
배포를 자동화하고 정적 분석을 파이프라인에 넣었습니다.
충방전기 시계열 데이터를 저장하기 위한 사내 압축 모듈입니다. Gorilla 논문을 분석해 부동소수점 압축을 구현했습니다.
Algorithm
시계열 평가 데이터가 빠르게 쌓이는데, 모든 칼럼에 같은 ZIP을 쓰고 있었습니다.
칼럼 성격에 맞춘 무손실 압축으로 ZIP보다 작고 빠르게.
관련 글데이터 압축을 위한 Gorilla 알고리즘 적용 사례: 사내 솔루션 개발기 및 회고
자세히 보기03 more work
사례로 따로 다루지 않은 작업 중 신규 기능, 장애 개선, 성능 개선을 골랐습니다. 쿠폰·등급·알림 같은 CRM 작업은 CRM으로 표시했습니다.
신규 기능Admin2026.10
어드민 서버를 MCP 서버로 만든 팀 작업에서, 사이드바 화면의 세팅값을 읽는 툴 99개와 노션 정책 문서 툴을 설계·구현했습니다. 툴은 화면이 쓰는 resolver·service를 그대로 부르고, 권한은 그 화면이 속한 메뉴의 읽기 권한을 따릅니다. 회원·주문 추출도 신 고객등급제 기준으로 맞췄습니다.
결과운영자가 전사 Claude에서 상품·배송·혜택 등 8개 메뉴의 세팅값과 커머스 정책을 채팅으로 조회합니다. 툴 99개를 공통 정의 하나로 같은 권한·응답 형식에 맞췄습니다.
신규 기능Commerce2026.10
외부 단축 URL 서비스가 종료된 뒤 알림톡·브랜드 메시지의 대체 문자(LMS)에 긴 UTM 주소가 그대로 나갔습니다. base62 7자 자체 단축 링크로 바꾸고, 같은 원본은 같은 코드를 쓰게 했습니다.
결과500ms 안에 줄이지 못하면 원본 주소로 보내, 단축 때문에 발송이 막히지 않게 했습니다.
신규 기능CRM2026.07 ~ 2026.10
회원 등급 API를 GraphQL에서 REST(Prisma, Swagger)로 다시 만들었습니다. 등급 혜택은 버전으로 관리하고, 강제조정은 기존 이력을 건드리지 않고 새 버전 행을 쌓는 방식으로 구현했습니다.
같은 강제조정 요청 5건을 동시에 보내도 등급 버전은 1개만 생성 (통합 테스트)
장애 개선Commerce2026.09
워커 OOM 4일 3회 → 배포 후 17일 0회 (같은 날 배포된 힙 설정 변경과 함께)
신규 기능Admin2026.08 ~ 2026.09
기획전·타임딜·매거진을 스케줄로 묶어 편성하는 어드민 기능입니다. 편성 저장, 타임라인 편성표, 기획전 기간을 바꿀 때 스케줄 겹침 검증을 만들었습니다.
편성 건수와 상관없이 편성 콘텐츠 조회를 1회로 고정
성능 개선Commerce2026.08 ~ 2026.09
기획전 오픈 직후 요청이 평시 분당 300~700건에서 최대 약 2만 건(30배 이상)으로 늘고 그날 5xx가 났습니다. 상품그룹마다 $lookup을 세 번씩 반복하던 조회를 분리 조회로 바꿔 쿼리 수를 고정하고, 완성된 응답은 Redis에 1분 캐싱했습니다.
p95 스토어 438ms → 98ms, 기획전 360ms → 63ms (7일)
성능 개선Commerce2026.08
Spring @Cacheable이 suspend 함수를 지원하지 않아 캐시가 계속 빗나가고 있었습니다. 함수 호출형 캐시를 만들고, Redis 장애 시에는 원본 조회로 넘어가게 했습니다.
Redis 장애 시 캐시 대기 상한 9초 → 200ms
신규 기능Commerce2026.08
어드민에서 증정품을 제품과 연결해 관리하고, 결제 완료된 배송에 증정품을 지급해 물류 수집에 반영합니다. 잔여 수량이 다음 1회 제공량보다 적어지면 Slack으로 알립니다.
100개 등록에 200개가 출고되던 버그 수정, 잔량 조건부 원자 갱신으로 초과 지급 차단
장애 개선CRM2026.08
성능 개선Admin2026.02 ~ 2026.07
주문·배송 엑셀은 쿼리를 묶고 스트리밍으로 생성하게 바꿨습니다. 이후 엑셀 12종을 RabbitMQ 요청, 워커 생성, S3 보관, Slack 전달 방식으로 옮겨 어드민 서버에서 무거운 작업을 뺐습니다.
주문 엑셀 5,000건 기준 쿼리 약 700회 → 350회, 동시에 메모리에 올라가는 셀 30만 → 60
신규 기능CRM
고객 기념일에 맞춰 쿠폰을 지급하는 배치입니다. 지급 실패를 회원 단위로 격리해, 한 명이 실패해도 나머지 고객에게는 쿠폰이 나가게 했습니다.
신규 기능CRM
고객별 수신동의 범위에 맞는 채널(FCM 푸시, 카카오 친구톡·브랜드메시지, LMS)로 보내고, 실패한 대상만 다음 채널로 다시 보냅니다. 푸시에 성공한 대상에게도 대체 발송이 나가던 버그를 찾아 수정했습니다.
신규 기능CRM
상품 조회, 장바구니, 가입, 로그인 같은 행동을 회원과 비회원 모두 같은 구조로 쌓는 로그 파이프라인을 만들었습니다. CRM 타겟 메시징에 씁니다.
신규 기능CRM
고객 행동과 상태 조건으로 인앱 메시지, 플로팅 배너, 띠 배너를 노출합니다. 운영팀이 배포 없이 노출 조건과 템플릿을 바꿀 수 있게 했습니다.
신규 기능Commerce
타임딜 일정 알림을 1분 주기로 보내고, 일정이 바뀌면 구독을 초기화해 잘못된 알림이 가지 않게 했습니다. 프레스티지 상품은 0원 결제를 뺀 결제에만 마일리지를 추가 적립합니다.
04 skills
05 education
06 contact
채용이나 협업 관련 연락은 메일로 부탁드립니다.
GitHub 활동 · 최근 1년기여 4274회
최근 1년 기여 합계 4274회. 개인 101회, 회사 4173회. 기여한 날 235일, 가장 많았던 날 2026.09.29 (84회).
Pangyo, South Korea
+ details
후속 개선
WMS의 커머스 DB 직접 쓰기를 끊고 Kafka 이벤트를 직접 소비
이전: WMS가 OMS·WMS의 배송 이벤트를 받아 커머스 MongoDB에 직접 썼습니다. 현재: 커머스 워커가 같은 Kafka 토픽을 직접 소비하고, 인박스와 상태 선행조건으로 한 번만 반영합니다.
이전
현재
WMS가 커머스 MongoDB에 직접 붙어 배송·아웃박스·상품을 읽고 씁니다(붉은 선). 커머스는 자기 데이터가 바뀐 것을 모릅니다.
WMS와 커머스 DB 사이의 선이 없습니다. 배송 이벤트는 Kafka로, 화면용 조회·연결은 커머스 내부 API로만 오갑니다.
커머스가 아웃박스에 적재하면 WMS가 5초마다 커머스 DB를 폴링해 CAS로 선점하고 Kafka로 OMS에 보냅니다. OMS가 수집을 마치면 WMS가 수집 완료 표시를 커머스 배송에 직접 씁니다.
커머스 api의 릴레이가 자기 아웃박스를 폴링해 Kafka로 발행합니다. 토픽·메시지·키는 그대로라 OMS는 바뀌지 않습니다. 수집 완료 이벤트는 커머스 워커가 받고, 이미 표시돼 있으면 NOOP으로 넘깁니다.
OMS가 송장 발급을 Kafka로 알리면 WMS가 현재 상태를 보지 않고 커머스 배송을 배송준비중으로 덮어씁니다. 이 전이는 커머스 코드에 없습니다.
커머스 워커가 같은 이벤트를 받아, 상태가 결제완료·배송준비중일 때만 배송준비중으로 바꿉니다. 이미 앞선 상태면 NOOP입니다.
WMS가 패킹 완료를 Kafka로 내고 자기가 다시 받아 커머스 배송을 배송중으로 덮어씁니다. 배송완료 건도 되돌릴 수 있습니다.
WMS는 이벤트만 내고, 커머스 워커가 결제완료·배송준비중인 건만 배송중으로 바꿉니다.
OMS에서 주문 상태(보류·확정·출고·출고취소)를 바꾸면 WMS가 커머스 배송의 현재 상태를 직접 읽고 바꿉니다.
커머스 워커가 같은 전이 규칙을 상태 선행조건으로 적용합니다. 여러 건 중 일부만 반영되면 PARTIAL로 남기고 실패 항목은 DLQ로 보냅니다.
OMS에서 수령인·주소·희망일·송장을 고치면 WMS가 커머스 배송 문서를 직접 덮어씁니다.
커머스 워커가 null이 아닌 값만 반영하고, 빈 송장 값은 건너뛰어 기존 송장을 지우지 않습니다.
WMS 관리자 화면이 커머스 배송·상품을 직접 조회하고, 상품 연결 값과 재수집용 아웃박스 행을 직접 씁니다.
WMS 화면은 커머스 내부 API(배송 상태 조회·재수집·상품 조회/연결)를 부르고, WMS의 커머스 DB 연결은 없앴습니다.
이벤트 도착
자동 출고 이벤트(eventId e-101)가 옵니다. 배송은 배송준비중입니다.
사전 확인
인박스에 출고토픽:e-101 키가 없으니 처리를 이어갑니다.
한 트랜잭션으로 반영
인박스 insert와 조건부 갱신(상태가 결제완료·배송준비중이면 배송중)을 같은 배송 DB 트랜잭션으로 커밋합니다. 1건 반영.
오프셋 커밋
DB 커밋이 끝난 뒤에 Kafka 오프셋을 수동 커밋합니다.
같은 eventId 재도착
재발행으로 같은 이벤트가 다른 오프셋에 다시 실려 옵니다. 인박스에 키가 있어 반영하지 않고 오프셋만 커밋합니다.
현재 상태
배송은 이미 배송완료입니다.
늦은 이벤트 도착
송장 발급(→ 배송준비중) 이벤트 e-087이 뒤늦게 옵니다. 인박스에는 키가 없습니다.
상태 선행조건 불일치
조건부 갱신의 조건은 결제완료·배송준비중이라 0건이 바뀝니다. 배송완료가 되돌아가지 않고 NOOP으로 인박스에 남습니다.
오프셋 커밋
정상 중복이라 DLQ로 보내지 않고 오프셋을 커밋합니다.
eventId가 다른 같은 일
같은 출고 요청이 한 번 더 들어와 eventId가 다른 출고 이벤트(e-102)가 옵니다. 인박스는 통과하지만 상태 선행조건이 맞지 않아 NOOP이고 오프셋을 커밋합니다.
다음 단계
설계·구현 전체 담당
2인 공동 프로젝트. 본인: 서비스 구조·잡 실행 구조(CronJob 차트·공통 러너)·실패 지점 재개·알림 발송 대기열 중계