화훼 도소매 B2B 주문 플랫폼

1. 프로젝트 개요 및 역할

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

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 패턴으로 정산 데이터 지키기 에서 다루고 있습니다.

결과

• 운영 기간 내 결제/정산 데이터 불일치 0건: 서버 통제형 트랜잭션과 JSON Fallback이 금융 데이터 무결성을 완전히 보장했습니다.
• 정산 재실행 시 DB 재조회 횟수를 0회로 줄였습니다. 실패 건은 기존 JSON 파일을 그대로 재사용합니다.
• 공휴일 정산 실패 건 전량 다음 영업일 자동 처리: 수동 개입 없이 파이프라인이 안정적으로 복구됩니다.

---

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

문제 상황

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

해결 과정 (WebSocket 분기)

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

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

문제 상황

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

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

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

3. 결과 및 회고 (Insight)

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