화훼 도소매 B2B 주문 플랫폼

1. 프로젝트 개요 및 역할

도매상과 화원 간의 실시간 화훼 거래를 지원하는 B2B 플랫폼입니다. 1인 백엔드 개발자로서 실시간 주문 상태 동기화, 구독 기반 자동 빌링(Toss 연동), 정산 파이프라인 구축 등 코어 서버 로직 전반을 단독 설계했습니다. 프론트엔드(React) 2인 팀의 초기 아키텍처 표준화도 주도하여 팀 전체의 개발 생산성과 코드 일관성을 끌어올렸습니다.

운영 규모는 월 주문 약 100건 , 월 결제액 약 400~500만 원 , 정산 대상 화원 약 50개 수준이었습니다. 규모가 크지는 않지만, 실제 현금 이동과 파트너 정산이 연결된 도메인이었기 때문에 중복 결제·누락 정산·재처리 안정성을 특히 중요하게 다뤘습니다.

2. 핵심 챌린지 및 문제 해결

챌린지 1: 비가역적 정산 데이터의 유실 방지 및 무결성 확보

문제 상황

외부 지급대행 API를 통한 정산은 한 번 실행되면 되돌릴 수 없습니다. 공휴일이나 네트워크 장애 시 중복 정산되거나 누락되는 사고를 방어해야 했고, 정산 대상 데이터를 매 실행마다 DB에서 재조회할 때 발생하는 I/O 부하 문제도 동시에 해결해야 했습니다.

고려한 대안과 판단

대안	접근	기각 사유
DB 상태값만으로 재시도 관리	정산 실패 시 상태를 '실패'로 마킹, 다음 실행 시 재조회	실패 후 재조회 쿼리 부하 + 이중 실행 위험 잔존
정규 Outbox 테이블 + MQ	DB 트랜잭션과 메시지 발행을 분리, 메시지 큐로 재시도	리소스 제약 환경에서 RabbitMQ/Kafka 도입은 과도한 운영 복잡도
JSON 파일 기반 간이 Outbox 패턴	정산 대상 데이터를 물리 JSON 파일로 저장, 성공 시 삭제	—

DB 상태 선점으로 중복 실행을 막고, JSON 파일을 Fallback으로 두어 실패 시 다음 영업일에 파일을 그대로 재사용하는 구조가 현재 팀 규모와 운영 환경에 가장 실용적인 타협점이었습니다.

해결 과정

• 스케줄러(node-schedule) 실행 시 정산 대상을 DB에서 조회한 뒤 상태를 '정산 대기'로 선점하여 중복 실행을 방어했습니다.
• 조회 결과를 물리 JSON 파일로 저장해 이후 API 호출은 DB가 아닌 파일을 참조하도록 구성했습니다.
• 지급대행 API 호출 성공 시에만 파일을 삭제하고, 실패(네트워크 오류, 공휴일 등) 시 파일을 보존해 다음 영업일 재시도의 근거로 활용했습니다.
• 결제 스케줄러는 PM2 단일 프로세스로 격리하고, 주문 생성 → 결제 요청 → 승인 → 실패 시 취소 흐름을 서버 주도 단일 트랜잭션으로 묶어 클라이언트 콜백 의존성을 제거했습니다.

이 챌린지의 설계 결정과 기술적 상세는 인사이트 JSON 파일을 활용한 간이 Outbox 패턴으로 정산 데이터 지키기 에서 다루고 있습니다.

결과

• 월평균 약 70건의 정산을 매월 실제 지급 금액과 대사(reconciliation)해 확인했고, 이 대사 기준으로 결제/정산 데이터 불일치는 발생하지 않았습니다. 서버 통제형 트랜잭션과 JSON Fallback으로 금융 데이터 불일치 리스크를 낮췄습니다.
• 정산 재실행 시 DB 재조회 횟수를 0회로 줄였습니다. 실패 건은 기존 JSON 파일을 그대로 재사용합니다.
• 공휴일 정산 실패 건은 보존된 JSON 파일을 기준으로 다음 영업일에 재처리되도록 구성했습니다.

---

챌린지 2: 트래픽 낭비를 줄이는 실시간 상태 동기화망 구축

문제 상황

도매상과 화원이 '주문 접수 ➝ 승인 ➝ 진행 ➝ 완료' 상태를 즉각적으로 공유해야 했으나, 기존의 HTTP Polling 방식은 트래픽 낭비와 서버 부하를 유발해 B2B 거래의 실시간성을 보장하기에 비효율적이었습니다.

해결 과정 (WebSocket 분기)

비효율적인 Polling을 걷어내고, Socket.io의 Room(User UUID 기반) 시스템을 도입했습니다. 상태 변경 시점에만 관련 도매상과 타겟 화원에게 이벤트를 즉각적으로 Emit 하는 이벤트 파이프라인을 구축하여 서버 부하를 최소화했습니다.

부하 테스트와 한계 분석

K6로 통합회원 서버와 화훼 주문 서버를 함께 호출하는 부하 테스트를 시도했습니다. 로그인 후 주문 생성 시나리오와 주문 생성 단독 시나리오를 나누어, 인증 부하와 주문 처리 부하를 분리해서 보려는 목적이었습니다.

다만 당시 테스트는 목표 부하 대비 실제 총 요청 수가 충분하지 않아, 처리량이나 성공률을 포트폴리오 성과 수치로 사용하기에는 부정확하다고 판단했습니다. 대신 이 테스트를 통해 “부하 테스트는 도구 실행보다 시나리오 설계와 측정값 해석이 더 중요하다”는 점을 학습했습니다.

향후 같은 테스트를 다시 수행한다면, 먼저 “1분 동안 몇 명이 실제로 어떤 행동을 반복하는지”를 명확히 정의하고, 로그인과 주문 생성을 분리해 각각의 실패 원인을 확인할 것입니다. 또한 서버가 다운되지 않았는지뿐 아니라, 어떤 API에서 실패가 발생했는지와 응답 지연이 어느 구간에서 시작되는지를 함께 기록해야 한다고 판단했습니다. 특히 주문 생성 경로는 레이트 리밋, 요청 큐잉, 멱등성 키, Socket.io 수신 확인 같은 개선안과 함께 다시 검증할 계획입니다.

챌린지 3: 프론트엔드 아키텍처 파편화 극복 및 표준화 리드

문제 상황

과거 프로젝트에서 정형화된 아키텍처의 부재로 작업자마다 코드 스타일과 디렉터리 구조가 달라져 유지보수에 큰 어려움을 겪었던 한계가 있었습니다.

해결 과정 (기능 중심 모듈화)

과거의 산발적인 구조를 탈피하고자, 전역 상태를 '유저 정보' 수준으로 최소화했습니다. 대신 기능(Feature) 단위로 폴더링을 모듈화하는 디렉터리 아키텍처 규약을 선제적으로 제시하여 철저히 캡슐화된 상태 관리를 리드했습니다.

3. 결과 및 회고 (Insight)

• 결제/정산 데이터 불일치 방어: 서버 통제형 트랜잭션과 JSON Fallback 시스템을 통해, 월평균 약 70건의 정산을 매월 실지급액과 대사한 기준에서 금융 데이터 불일치가 발생하지 않도록 관리했습니다.
• 조직 내 개발 표준 확립: 주도적으로 설계한 기능 단위 아키텍처가 팀 내 FE 표준으로 자리 잡아 UI/UX 개발 속도와 코드 가독성을 개선했습니다.
• 차세대 아키텍처 고도화 구상
  • 결제 멱등성 및 비즈니스 확장: 네트워크 지연에 따른 이중 결제 시도를 방어하기 위해 Idempotency Key(멱등성 키) 와 DB Unique 제약조건을 활용한 방어 로직의 필요성을 체감했습니다. 잔액 부족 시 즉시 해지가 아닌 Grace Period(유예 기간)를 두는 로직 확장도 구상 중입니다.
  • 정규 Outbox와 MQ 도입: 현재의 JSON Fallback은 훌륭한 타협점이었으나, 향후 트래픽 증가 시 이를 DB 기반의 정규 Outbox 테이블 로 승격시키고, 메인 트랜잭션과 이벤트 발행을 분리하는 Message Queue(RabbitMQ, Kafka) 아키텍처로 고도화하여 결합도를 낮추고 싶습니다.
  • 실시간 통신 신뢰성 개선: Socket.io Emit 구조에 클라이언트 수신을 보장하는 ACK(Acknowledgement) 구현과 서버 재시작 시의 메시지 복구 전략을 수립하여 통신 신뢰성을 개선하고자 합니다.