Backend 엔지니어

이태현

배경 및 문제 상황모놀리식에서 MSA로 전환한 이후에, 외부 도메인에서 재고 테이블에 직접 update 방식이 지속됨. 이로 인해 다음과 같은 재고 정합성 문제 발생:<ul><li>재고 변경 책임 분산: 다양한 도메인에서 재고를 직접 변경하면서, 정합성 유지가 어려워짐</li><li>원인 추적 불가: DB 직접 수정 방식으로 인해 재고 오류 발생 시 원인 도메인 파악이 불가능</li><li>수량 불일치 식별 불가: 외부 시스템이 재고를 중복으로 반영하거나, 잘못된 수량을 반영해도 식별이 불가능</li></ul>개선 및 설계1단계: 재고 변경 책임 일원화<ul><li>외부 도메인이 재고 DB를 직접 수정하던 방식을, Inventory 서비스가 정의한 Kafka 메시지 프로토콜에 따라 메시지만 발행하도록 개선</li><li>Kafka 메시지를 통해 재고 변경은 Inventory 서비스만 수행하게 하여 책임을 일원화하고, 변경 이력 추적과 정합성 제어가 용이한 구조로 전환</li><li>트레이드오프 분석<ul><li>API 방식은 정합성 보장에는 유리하지만, 장애 발생 시 외부 도메인까지 영향을 미쳐 출고 전체 중단 리스크 존재</li><li>당사는 SLA 상 출고 지연이 절대 허용되지 않기 때문에, 출고 흐름을 유지하면서 사후 복구 가능한 Kafka 기반 비동기 구조를 선택</li><li>Kafka 메시지 지연 가능성은 데드레터 큐 기반 재처리 로직으로 대응하여 정합성 문제는 사후 해결 가능</li></ul></li><li>파티션 키 전략<ul><li>메시지의 순서 보장과 상품 단위 처리 일관성을 확보하기 위해 상품ID 를 파티션 키로 설정하여 설계</li></ul></li></ul>2단계: 예약 기반 정합성 검증 및 Slack 알림 도입<ul><li>기존 구조에서는 외부 도메인이 중복 메시지를 전송하거나, 예약과 다른 수량을 완료 처리해도 Inventory 서비스가 이를 식별할 수 없음<ul><li>예: 50개 예약 후, 30개만 완료 처리해도 시스템은 오류를 인지하지 못함</li></ul></li><li>이에 따라,<ul><li>작업 생성 시 ‘예약 수량’을 명시적으로 기록</li><li>완료 시점에 예약 수량과의 일치 여부를 검증</li><li>불일치 발생 시 Slack 알림을 자동 발송하여 실시간 문제 인지 및 빠른 대응이 가능하도록 개선</li></ul></li></ul>성과<ul><li>재고 도메인에 대한 책임을 Inventory 서비스로 일원화함으로써, 외부 서비스의 재고 의존도를 제거하고 서비스 간 결합도를 효과적으로 분리함</li><li>재고 정합성 오류 건수를 월 20건 → 2건 이하로 감소</li><li>재고 정합성 문제 인지 리드타임을 평균 20일 → 실시간으로 단축, 대응 속도 및 신뢰도 향상</li><li>Kafka 기반 메시징 구조 전환으로 출고 업무의 연속성 보장, SLA(출고 지연 없음) 기준을 안정적으로 준수</li></ul>

재고 시스템 Ver2

배경 및 문제 상황기존 입고 시스템은 사전에 등록된 입고 요청 내역과 완전히 일치하지 않으면 처리할 수 없는 고정된 구조였음. 이로 인해 다음과 같은 문제가 발생:<ul><li>고객 요청 내역과 실제 입고 물품 간 불일치: 고객이 사전에 요청한 상품과 공급사가 실제로 보낸 물품이 다를 경우, 관리자가 수동으로 입고 요청을 생성해야 했으며, 이러한 사례는 전체 입고 요청 건의 약 30%에 달했음</li><li>복잡한 커뮤니케이션: 미요청/과입고 발생 시 작업자 → 창고 관리자 → CX팀 → 고객까지 반복적인 커뮤니케이션이 필요, 대응 시간 증가 및 리소스 낭비 유발</li></ul>역할 및 기여<ul><li>CX팀의 월간 VoC(Voice of Customer) 리포트를 직접 분석하여, 현장에서 반복적으로 발생하는 입고 프로세스 문제를 개발 요청 없이 먼저 인지</li><li>실물 기반 입고 처리 방식으로 전환하기 위해, 기존 데이터 모델링 구조를 전면 개선<ul><li>기존에는 사전 등록된 입고 요청과 정확히 일치하지 않으면 처리 불가한 구조로, 입고 프로세스에 제약이 있었음</li><li>입고 요청 시스템을 개선하여, 실물 기준으로 처리 가능한 구조로 변경하고, 과입고 및 미요청 상품도 자동 입고 요청이 생성되도록 백엔드 로직 개선</li><li>요청 수량과 실입고 수량 불일치 시, 해당 이력을 자동으로 기록하고, 고객에게 실시간 알림 전송</li></ul></li></ul>성과<ul><li>평균 입고 완료 시간 15% 단축</li><li>관리자의 수동 요청 생성 비율을 30% → 0%로 감소</li><li>입고 요청 1건당 평균 30분 소요되던 커뮤니케이션 비용을 0분으로 제거, 월 기준 약 40시간 이상의 CS 리소스 절감</li></ul>

입고 프로세스 개선

배경 및 문제 상황신규 고객 유입과 출고량 증가로 인해, 출고 작업의 처리 효율을 개선하지 않으면 작업자 인력 확충에 따른 인건비 부담이 불가피한 상황역할 및 기여<ul><li>피킹 작업 최적화<ul><li>기존에는 주문 수집 이후, 일정 시간이 지나면 자동으로 피킹 작업이 생성되어 유사 주문 간 묶음 비효율 발생</li><li>이를 개선하여, 주문 수집 이후 작업 생성 시점을 지연 → 유사 주문의 작업 묶음 최적화</li></ul></li><li>패킹 작업 개선<ul><li>이전에는 한 주문 내 상품이 여러 컨테이너에 분산 → 패킹 효율 저하</li><li>시스템 로직을 개선하여 하나의 주문이 여러 컨테이너에 나뉘지 않도록 피킹-패킹 연계 흐름 설계 변경하여 패킹 속도 및 정확도 향상</li><li>데이터 상으로는 다수 주문을 여러 컨테이너에 최적 배치하는 것이 효율적일 수 있지만, 현장 작업자는 물리적으로 상품을 찾아야 하므로 오히려 비효율이 발생 — 이 점을 고려한 실물 기반 최적화</li></ul></li></ul>성과<ul><li>피킹 작업 최적화를 통해 UPH(Unit Per Hour)를 100 → 200으로 약 2배 향상</li><li>패킹 작업 개선으로 PPH(Packing Per Hour)를 50 → 65으로 30% 향상</li><li>출고량 증가(월 20만 → 30만, +50%)에도 불구하고, 작업 인력 추가 없이 기존 인원으로 안정적으로 대응</li></ul>

출고 효율 개선

<ul><li>물류관리시스템(WMS) 백엔드 엔지니어로 3년간 근무하며, 재고·입출고·작업 관리 전반의 시스템 설계 및 고도화를 주도</li><li>고객의 요구에 맞춘 재고 수불부 기능을 신규로 설계·개발하여 유치 성사에 핵심 기여하였고, 해당 고객 유입으로 월 출고량이 25% 증가(20만 건 → 25만 건)</li><li>MSA 구조에서 분산된 재고 변경 책임을 단일 서비스로 집중하고, 실시간 정합성 검증 및 Slack 알림을 연동해 고객 컴플레인을 월 8건 → 1건 이하로 줄이고, 평균 20일 걸리던 이슈 인지 시간을 실시간 수준으로 단축하여 운영 신뢰도 향상</li><li>입고 시스템을 개선하여 추가 입고 요청 비율을 30% → 0%로 감소시키고, 요청 1건당 CS팀 커뮤니케이션 비용을 30분 → 0분으로 감소시켜 월별 총 40시간의 대응 시간을 절감함</li><li>피킹/패킹 작업 흐름을 최적화해 UPH (Unit Per Hour) 100%, PPH (Packing Per Hour) 30% 향상시켜, 출고량 (월 20만 -&gt; 월 30만) 50% 증가 상황에서도 추가 인력 고용 없이 안정적인 운영이 가능하도록 시스템을 개선</li><li>3년간 주기적으로 온콜을 담당하며 반복 이슈 대응의 비효율을 개선하기 위해 SOP (Standard Operating Procedure) 문서를 제작하고 주간 공유 미팅을 주도하여, 팀의 대응 일관성을 높이고 평균 처리 시간을 30분에서 10분으로 단축하여 온콜 효율을 약 67% 향상시킴</li><li>‘함께 자라기’, ‘소프트웨어 아키텍처 101’ 등 기술 도서 기반의 팀 내 스터디를 주도하며 설계 및 구현방안 논의 시 최소 2가지 이상의 대안을 제시하고 트레이드오프를 비교·의사결정하는 문화 정착에 기여</li></ul>