이커머스 플랫폼 백엔드

A주요 작업:

• 운영 DB 전수 조사로 영향 범위 산출 — 영향 상품 90,696개, 노출 기간 주문 1,086건 중 실제 노출 909건
• 4개 마켓 송출 데이터에 방지 분기를 추가해 정상가 복원 배포
• 전 마켓 전수 대조로 나머지 마켓의 정상 여부까지 확정해 영향 범위를 종결
• 조사에서 그치지 않고 방법론을 재사용 가능한 도구로 만들어 매일 09시 자동 실행

R결과:

• 조용히 새던 이중 할인 손실을 규명하고 전 마켓에서 차단 — 방치하면 계속 누적되는 문제였음
• 부수 성과: 특정 마켓의 할인 정책에 상한이 존재한다는 사실을 처음 규명 — 상한 때문에 셀러에게 전달되지 않던 할인이 있음을 확인
• 일회성 조사를 상시 감사 체계로 전환 — 장부상 손실처럼 보이던 건에서 허위(주문 매핑 결함·이중 차감 착시)를 걸러내고 진짜 손실만 분리하는 것까지 자동화

손실을 찾는 것보다, 손실처럼 보이는 것과 진짜 손실을 구분하는 것이 운영 판단의 질을 결정했습니다.

기술 스택: Kotlin PHP (Laravel) QueryDSL MySQL

A원인 규명과 조치: 원인은 상품 정산기준가와 옵션가를 각각 올림한 뒤 합산한 데 있었습니다. 원래 공식은 둘을 먼저 합친 가격에 수수료를 한 번만 적용하는 것이었고, 여기서 두 가지 증상이 나왔습니다.

• 양수 옵션 → 올림 2회 + PHP 부동소수점 오차로 1원 차이
• 음수 옵션 → 계산값이 음수인데 컬럼이 unsigned라 INSERT 실패 → 주문 생성 트랜잭션 전체 롤백

• 공식 복귀 — 가격을 먼저 합산한 뒤 수수료를 1회만 적용하도록 양쪽 동시 수정
• 정수 연산 통일 — 부동소수점 제거, 정수 나눗셈 헬퍼로 두 언어가 동일 연산 수행
• 레이어별 정책 분리 (핵심 판단) — 운영자 입력 지점은 거부(422), 자동 인입 지점은 0 보정. 처음엔 런타임 예외를 던졌지만, V2의 주문 인입은 메시지 큐 컨슈머를 경유하므로 예외가 나면 컨슈머가 막혀 다른 주문까지 적체됩니다. 거부해도 되는 곳과 거부하면 안 되는 곳을 나눴습니다.
• 공급가·정산기준가·수수료율을 상품 단위로 관리하도록 구조 재설계, 가격 변경 히스토리 관리

R결과:

• 수정한 로직을 실데이터 458만 건으로, 레거시와 신규 시스템을 333만 건으로 비교해 계산 결과가 모두 일치함을 확인
• 실데이터에 음수 옵션가가 3,156건 존재 — 언제든 주문 생성이 실패할 수 있던 상태를 사전에 차단
• 이후 정산 변경 시 실데이터 대량 대조를 상시 절차로 정착 — 어느 시스템에서 처리해도 같은 지급액

기술 스택: Kotlin Spring Boot Kafka AWS SQS Quartz QueryDSL React PHP (Laravel) MySQL

1단계 — 기간형 프로모션(2.0) 신규 구축 (레거시, 2025.11 ~ 2026.04):

• 기존 1.0은 마켓에 걸어둔 할인에 내부 정산을 맞추는 내부 관리 기능이라 마켓·내부 양쪽을 따로 수정해야 했음 → 프로모션 세팅에 따라 외부 마켓 가격을 직접 수정·송출해 이중 작업 제거. 엑셀 업로드/다운로드/템플릿, 스케줄러 기반 시작·종료, 기간 중복 체크, 상태 흐름(시작/중지/재시작/연장/종료) 구현
• 마켓마다 다른 할인 규격(쿠팡·SSG·카카오스타일 최종가 1원 절사, 11번가 할인 타입, 지마켓·옥션 정액) 흡수. 등록 상품이 0건이면 전체 롤백, 상품 삭제 시 외부 채널 가격을 복구하는 동기화 Job으로 마켓과 내부 가격이 어긋나는 상황을 방지 (운영 약 9,200건 처리)

2단계 — 관리형(3.0)으로 확장 (V2 백엔드 단독 설계 + React FE): 2.0은 진행 중에는 상품 가격이 변동되면 안 돼 가격 수정이 막히는 제약이 있었음 → 재계산 통합 로직으로 상품가격·정산기준가·수수료를 상품 단위로 제어해 할인뿐 아니라 판매가 자체를 조정할 수 있게 확장

• 스냅샷은 대기→진행→만료 상태 흐름과 브랜드 설정이 소속 상품 전체에 자동 반영되는 구조로 설계 (새 상품이 등록되면 자동으로 프로모션에 편입)
• 상태 전이를 스케줄러 직접 처리에서 이벤트 발행·소비 분리로 재설계 (2026.06) — 이후 팀에서 진행한 Kafka → AWS SQS FIFO 전환 논의에 참여했고(스트림 처리·이벤트 재소비 없이 "순서 보장 작업 큐"로만 쓰고 있어 기능 손실 없이 비용 절감 가능), 전환 후 전이·편입 경로를 FIFO 그룹·중복 제거 창에 맞춰 재구현 — 월초 자정에 몰리는 대량 가격 송출을 속도 조절로 안정 처리
• 프로모션 가격이 다른 가격 설정보다 우선 적용되어 마켓에 송출되는 규칙을 구현하고, 진행 중인 프로모션을 수정하면 바뀐 가격이 마켓에 자동으로 재송출되게 처리
• 관리자용 정상가 일괄 수정 기능(엑셀 미리보기, 할인율 역산 근거 표시)과 React 관리자 화면(등록/조회/수정, 셀 단위 편집·엑셀 업로드·이력) 구현

R결과:

• 6개 모듈 64개 소스 파일 규모의 신규 도메인을 설계·구현 — 누적 535건 프로모션 등록, 약 190만 건 송출 스냅샷 처리
• 한 시점에 몰린 104만 건 전이를 다른 도메인 영향 없이 처리
• 백엔드(레거시·V2)와 프론트 세 곳에 흩어져 있던 가격 계산식을 어디서 계산해도 같은 값이 나오게 맞춤 — MD 1명이 여러 브랜드의 가격·할인을 대량 관리

기술 스택: Kotlin Spring Boot PHP

A주요 작업:

• 주문·클레임 수집 17종, 상품 연동 8종 이전 — OrderAdapter / ApiDelegate 표준 패턴 정립, 마켓별 외부 API 호출은 선언적 HTTP 클라이언트(HTTP Interface)로 정리
• 입점사 단위 라우팅으로 위험 격리(카나리) — 문제가 생겨도 영향 범위를 입점사 단위로 한정
• 상품 연동 액션 세분화: 생성·업데이트·상태 변경으로만 나뉘어 있던 연동을 생성·상태·가격·재고 등 액션 단위로 분리 — 마켓과 B-Flow의 가격·판매상태 불일치를 줄임
• 가장 어려웠던 건 어느 경로가 실제로 도는지 확정하는 일 — 주문 테이블의 calculation_version='v2'는 레거시 코드가 세팅하는 값이라 "신규 정산식으로 계산됨"이지 "신규 시스템이 생성함"이 아님. 이걸 모르고 V2만 고치면 대부분의 주문에 반영되지 않음

R결과:

• 운영을 멈추지 않고 이전을 진행하며, 신규 개발의 중심을 레거시에서 V2로 전환

기술 스택: Kotlin PHP Kafka Quartz MySQL AWS ECS

A근본 원인 분석 사례:

• 클레임 큐 적체: 실패한 메시지가 반복 재전달되며 뒤를 막고 있었음 — 이미 성공한 건이 5분 간격으로 106회 재처리된 로그가 결정적 증거. 유발 결함 2건까지 추적(복사 주문의 확정 시각 누락으로 인한 무한 재시도, 초 단위 없는 날짜 파싱 예외로 인한 수집 롤백). 처리 상태를 running으로 마킹한 뒤 복구 로직이 없어 하나가 갇히면 같은 채널 전체가 막히는 구조까지 규명
• Quartz 롤링배포 충돌: 배포할 때마다 예약 작업 트리거가 오류 상태로 굳는 원인(isClustered=false + JDBC JobStore 공유 → ClassNotFound → 트리거 ERROR 영구 고착)을 찾아내고, 신·구 버전이 겹쳐 뜨지 않게 배포 절차를 바꿔 재발 방지
• 빌드 캐시 오염 직렬화 오류: sealed class 하위 추가가 캐시에 가려 허용 목록이 갱신되지 않아 Kafka 발행이 막히던 문제를 규명, 배포 산출물을 javap로 직접 확인하는 절차를 만듦
• 마켓 API v1 종료 → v2 전환 대응, 주문 중복수집 방지, 클레임 수집·컨버터 오류 수정 등 상시 대응

R결과:

• 적체 해소 + 유발 결함 2건 제거 + 복구 경로 부재를 구조적 결함으로 문서화
• 원칙 도출: 순서 보장 큐에서 한 메시지의 무한 재시도는 곧 그룹 전체의 정지
• 20+ 마켓 주문·정산·클레임 흐름의 무중단 운영 유지

A주요 작업:

• 원인은 상태 전이 규칙이 여러 코드에 복제된 구조 — 유발 지점이 한 곳이 아니라 마스터 상품 수정 시 자식 상태 변경, 특정 마켓 상품 등록 경로 등 여러 곳. 하나씩 차단하고 잔존 데이터를 복원
• 병행해서 마켓별로 관리자가 지정한 정산기준가가 마스터 상품 수정 시 덮어써지던 문제를 차단 — 조용히 금액이 바뀌는 종류라 발견이 늦으면 정산에 그대로 반영됨

R결과:

• 약 9만 건 규모의 오염을 확인·복원
• 정산 금액이 흐르는 경로에 보호 장치 신설 — 관리자가 지정한 정산기준가가 덮어써지지 않게 차단
• 정산은 잘못된 데이터가 이미 쌓인 상태에서 고쳐야 하므로, 코드 수정과 데이터 복원을 항상 한 쌍으로 진행하는 원칙 정착

기술 스택: PHP Kotlin Python NestJS Java Feign

A구조와 원칙:

• 팩토리 3종 분리 — 인증(Account) / API 호출(Client) / 응답 변환(Mapper). 동작 차이는 플래그로 선언(승인 확인 필요 여부, 임시 상품 선생성, 이미지 생성 등)하고 오케스트레이션 코드는 마켓을 모르는 상태로 유지
• 운영 원칙 — "코드에 구현이 있다 ≠ 그 경로가 활성이다": 수집 경로가 5개 서비스(Kotlin·PHP·Python·NestJS·Java)에 분산돼 있어 코드만 보면 4개 마켓에서 판단을 그르침(지마켓은 전용 변환기가 있지만 실제로는 통합 변환기로 수집). 활성 경로는 반드시 DB의 버전·소스타입·원본 응답으로 확정하는 절차를 세움
• AI 활용 자동 매핑: 수작업이던 마켓 카테고리·상품정보고시 매핑을 마켓 수집 정보 기준으로 자동 매핑하도록 개발 (상세이미지 자동화는 진행 중)
• 다룬 마켓: 퀸잇 · 카카오스타일(지그재그·포스티) · 큐텐 · SSG · 롯데온 · 지마켓/옥션(ESM·글로벌) · 11번가 · 네이버스마트스토어(플러스스토어) · 쿠팡(글로벌) · GS샵 · 카페24 · CJ온스타일 · 알리익스프레스 · 에이블리 · 토스 · 테무 · 사방넷 · 무신사 · 하프클럽 · 홈앤쇼핑 등

R결과:

• 신규 마켓 2개(퀸잇·큐텐)를 상품·출고·반품/교환·CS·정산까지 단독 온보딩 — 판매 채널 확장
• 마켓마다 다른 API(XML/JSON·상태코드·페이지네이션·인증)를 팩토리 + 어댑터 패턴으로 통일
• 주력 저장소 외에 Python·NestJS 수집 서비스에도 직접 기여, 해외 마켓 환율 계산 담당

기술 스택: PHP (Laravel) Kotlin 비동기 Job

A주요 작업:

• 클레임 조건 매핑 구조 설계: 회수조건·귀책여부·배송비 지출조건·배송방법(유료/무료)·조건부 배송타입을 매핑 가능한 구조로 잡고, 클레임 수집 시 자동 매핑되어 반품 배송비가 자동 계산·적용되게 구축
• 주문↔클레임 상태 전이 통합: 분리 수집·매칭 구조에서 생기던 상태 꼬임(취소 접수 후 출고 등)이 일관되게 전이되도록 통합 구조 설계 — 마켓마다 다른 클레임 상태 체계를 공통 enum으로 정규화하고 36개 비동기 Job으로 나눠 일관 처리
• 반품/교환 리스트·검색·엑셀 V2, 교환 재배송 생성 로직 재설계(중복 생성 트랜잭션 보호), 수거완료/회수완료 상태 전이, 강제 반품·교환 완료 처리

R결과:

• 반품 배송비 자동 계산과 상태 전이 일관화로 클레임 관련 문의·CS 감소

기술 스택: Kotlin Spring AOP React 19 TypeScript

A주요 작업:

• 판매관리 2.0 신규 개발: 매칭 없이도 주문을 생성하고 상품은 이후 별도 매칭·수정할 수 있게 재설계. 주문 상태 전환 벌크 API, 세트 자재(SKU) 통합 매핑, 판매자 옵션 매칭
• AOP(@Around) 기반 주문 API 감사 로그 — 주문 API 호출 전후 상태를 JSON 로그로 남겨 문제 추적을 쉽게 함
• 관리자 기능 분리 (진행 중): 마켓 연동 API 기반 주문·클레임·정산 조회, 정산·수수료, 상품 프로모션 등 내부 관리자 기능을 React 기반 관리자 화면 + 전용 API로 이전

R결과:

• 매칭 실패 시 주문 생성이 막히던 레거시 제약 제거
• 레거시에 뭉쳐 있던 내부 관리자 기능을 전용 관리자 화면으로 이전 중 (2026.01 착수)

A겪은 문제 4가지와 대응:

• 근거 없이 원인을 단정 — 정산 분석 중 코드·DB 확인 없이 결론을 내려 오진한 적이 있음. 이후 진단 작업에서 근거 조회나 인용 없이 결론을 내면 출력을 차단하는 훅을 만들고, 규칙이 긴 대화에서 잊히는 문제는 진단형 요청을 감지해 규칙을 다시 주입하는 훅으로 보완
• 운영 DB에 무거운 쿼리 — 수백만 행을 인덱스 없이 훑는 쿼리는 곧 장애로 이어짐. 실행 전 실행계획(EXPLAIN) 확인을 강제해 실제로 425만 행 스캔 쿼리를 실행 전에 차단
• 불필요한 주석 대량 생성 — 편집 시점에 주석 밀도·유형을 검사해 차단하되, 의도적으로 다시 시도하면 통과시켜 꼭 필요한 주석은 남길 수 있게 함
• 같은 실수 반복 — 마켓별 함정·장애 패턴을 매번 다시 조사하고 있었음. 조사 결과를 팀 공유 지식 그래프로 자산화해, 재조사에 반나절 걸리던 내용을 검색해서 바로 꺼내 쓸 수 있게 함

산출물: 가드 훅 4종 · 도메인 전문 에이전트 6종 + 오케스트레이터 2 · 도메인 스킬 12종 · 지식 그래프 114건 · 코드 규칙 209개 · 7개 저장소 통합 개발 가이드

R결과:

• 비즈니스 임팩트로 연결 — 맨 위 카드의 이중 할인 감사를 일회성 조사로 끝내지 않고 자동화 도구로 만들어 매일 실행 — 사람이 기억해야 하던 점검을 시스템이 대신 수행
• 도구를 정비한 뒤 작업 처리 속도가 눈에 띄게 빨라졌고, 담당 범위가 백엔드에서 React 프론트까지 확장

AI를 빠르게 쓰는 것보다 틀린 결과를 걸러내는 체계를 만드는 것이 실제 생산성을 결정합니다. 위 가드는 전부 직접 겪은 실패에서 나왔습니다.

현재 진행 중: 팀 공통 목표가 서버 비용 절감과 에러율 감소(CS 축소·안정적 서비스)로 잡히면서, AI를 활용한 유지보수에 집중하고 있습니다 — 에러·CS 유발 지점을 추적해 선제 수정하고, 비용을 만드는 비효율 쿼리·작업을 찾아 줄이는 방식입니다.

A주요 작업:

• 갱신 로직을 플랜 정의 기반으로 전환
• 플랜 기간과 구독 기간 분리 — 무료 플랜 도입으로 "요금제 유효 기간"과 "구독 생존 기간"이 달라짐. 뭉쳐 있던 개념을 분리해 무료 전환·유료 복귀 시 기간 계산이 어긋나지 않게 함
• 후불 결제 설정·조회, 결제 이력 조회 API·관리자 화면
• 플랜 ↔ 수수료 연계 — 어떤 요금제를 쓰는지가 정산 수수료율에 영향을 주므로 수수료 조회 로직을 개편 체계에 맞게 수정

R결과:

• 요금제 체계 확장이 가능한 구조로 전환 (30일 고정 제약 해소)
• 구독료를 받는 쪽(과금)과 셀러에게 지급하는 쪽(정산)을 모두 담당 — 유료화 흐름 전 구간 경험

기술 스택: Java Spring Boot Python (FastAPI·Django) Node.js / TypeScript MySQL Redis MongoDB Vue.js Electron

주요 프로젝트 — S(상황) → A(행동) → R(결과):

• 판매 프로세스 자동화
  S상품 등록부터 CS까지 온라인 판매 전 과정이 수작업이었고, 상품 상태가 마켓과 어긋나 주문이 취소되는 일이 반복
  APython/FastAPI 배치 시스템 설계·개발 주도, GitLab CI/CD로 수동 배포 자동화, PM2 안정 실행 + 실시간 로그 모니터링, 외부 API 데이터 분석 기반 카테고리 자동 매칭
  R상태 불일치로 인한 주문 취소율 75% 감소 · 수작업 87% 단축(4시간 → 30분)
• 종합몰 상품 등록 자동화
  S토스·카카오·홈플러스·GS SHOP·SSG·현대몰·AKMALL 등 종합몰은 담당자가 건당 5분씩 수작업으로 등록
  A마켓별 상품 관리를 API·크롤링 기반으로 개발, 등록·상태·가격 변경사항 동기화 프로세스 구축
  R종합몰 매출 3배 증가 · 상품 등록 5분 → 2~10초(약 30~150배) · 품절 취소율 감소
• 다잡아 — 쿠팡 위너 로직 안정화 (단독 설계·개발)
  S위너(최저가 노출) 확보 로직이 Selenium 브라우저 자동화로 동작 — 대상 사이트가 바뀔 때마다 깨지고 리소스 과다
  A쿠팡 내부 API 호출로 전환해 브라우저 의존 제거, 사용자·과금·통계 API는 관리자·클라이언트·배치 세 환경이 함께 쓰는 RESTful로 설계
  R위너 상품 생성 속도 10배 개선(5시간 → 30분) · 사이트 변경에 깨지던 취약점 제거
• 키워드 추천 아키텍처 재설계
  S단건 처리만 가능했고, 실제로 쓰이지 않는 Redis·RabbitMQ가 아키텍처에 포함
  A엑셀 업로드 기반 대량 처리로 확장, 파일 처리를 클라이언트로 이전하고 백엔드는 순수 JSON만 처리, 필요 없던 컴포넌트 제거
  R대량 일괄 추출로 사용자 작업 시간 단축 + 운영 복잡도 감소
• 매크로(수집·자동화 도구) 안정성 개선
  S리소스 과부하로 PC당 동시 실행이 5개로 제한되고 그마저 다운
  A관리자와 실행 에이전트를 분리하고 Selenium 서버를 별도 분리, Redis 작업 상태 관리(중단 시 복구) 적용
  R동시 실행 제약 완화 · 다운 문제 해소
• 다팔자(Electron 데스크톱): 상품 대량 등록·상태 동기화, GS SHOP·TOSS 신규 마켓 연동, 주문·CS 관리 개발