화훼 도소매 B2B 주문 플랫폼

백엔드 전반을 혼자 담당하고 프론트엔드 2인 개발에 참여해 거래 흐름과 기능 단위 구조를 구축했습니다. 신규 거래 운영은 2026년 6월 종료됐으며 현재는 관리자 조회와 기존 데이터 보존 상태를 유지합니다.

백엔드는 혼자 담당했고 서버와 결제·정산, Socket.io 실시간 이벤트, 운영 유지보수를 맡았습니다. 프론트엔드는 저를 포함한 2명이 함께 개발했고, 최초 구축 단계에서 기능·페이지 단위 디렉터리와 기능 내부 상태 소유 규칙을 제안한 뒤 실제 화면 기능도 구현했습니다.

공통 전역 상태는 사용자 정보처럼 여러 기능이 함께 쓰는 값으로 제한했습니다. 이 규칙은 두 명이 기능을 나눠 구현하고 이후 코드를 리뷰·유지보수하는 동안 기능과 상태의 위치를 찾고 공용 파일 충돌을 줄이는 기준으로 사용했습니다. 별도의 생산성 수치로 측정하지는 않았습니다.

신규 실시간 기능을 설계할 때 HTTP Polling과 Socket.io를 비교했습니다. 주문 상태가 바뀌는 시점에 관련 대상만 갱신해야 했기 때문에 주기적으로 다시 조회하는 방식보다 Socket.io 이벤트를 선택했습니다. 이는 운영 중이던 Polling을 교체한 작업이 아니라 최초 구축의 선택입니다.

정산에서는 DB 상태를 지급 여부의 기준으로 두고, 계산을 마친 지급 입력과 실패 후 다시 사용할 입력을 JSON 파일에 남기는 방식을 사용했습니다. 지급 전에는 DB를 다시 확인하고 단일 scheduler process만 실행하도록 분리했습니다. 당시 별도의 메시지 시스템이나 검증하지 않은 복구 기술을 비교해 선택한 것은 아닙니다.

결제 승인 전 내부 DB transaction을 시작하고, 승인 뒤 주문 저장이 성공하면 commit했습니다. 주문 저장에서 오류가 나면 rollback한 다음 결제 취소 API를 호출하는 보상 흐름을 구현했습니다. 개발 환경에서는 자동 취소 성공과 취소 API 실패를 각각 확인했습니다.

정산은 DB의 상태를 지급 판단 기준으로 사용했습니다. 지급 직전에 DB 상태를 다시 확인했고, 계산된 지급 입력은 JSON 파일로 보존했습니다. 성공한 항목은 완료 상태로 바꾸고 JSON에서 제거했으며 실패한 항목은 파일에 남겨 매일 10시와 14시에 다시 확인했습니다. scheduler는 웹 요청을 처리하는 worker와 분리한 단일 PM2 process로 실행해 같은 서버 안에서 중복 schedule이 시작되지 않게 했습니다. 자세한 판단은 정산 상태는 DB에, 재처리 입력은 JSON에 둔 이유에서 다룹니다.

실시간 상태는 최초 공용 Room에서 시작했지만 개발 중 코드 재검토에서 관계없는 사용자까지 받을 수 있는 구조임을 발견했습니다. 이후 user_<gardenId> 형태의 화원별 Room으로 바꾸고 여러 계정으로 관련 화원만 이벤트를 받는지 확인했습니다. 이 변경은 전달 대상을 좁힌 것이며 이벤트 도달 자체를 보장한 것은 아닙니다. 자세한 범위는 공용 Room에서 화원별 User Room으로: 전달 범위와 전달 보장은 다르다에서 분리해 설명합니다.

신규 거래 운영 기간에는 월 2회 정산했고, 운영팀이 월말 보고서를 준비할 때 내부 정산 내역과 지급대행사의 실제 지급 내역을 함께 대조했습니다. 2026년 6월까지 이 대사 범위에서 정산 금액 불일치나 중복 지급을 확인하지 못했습니다. 이는 시스템 전체의 영구적인 무결성을 보장한다는 뜻이 아니라 매월 수행한 운영 확인 결과입니다.

결제 보상 흐름은 개발 환경에서 주문 DB 저장 실패 뒤 rollback과 자동 취소가 성공하는 것을 확인했습니다. 동시에 취소 API 자체가 실패하는 경우도 재현했고, 그 뒤 자동 복구가 없다는 한계를 구분했습니다. Socket.io는 개발 중 여러 계정으로 관련 주문·수령 화원만 이벤트를 받고 화면이 갱신되는 것을 확인했습니다. 성능 개선률이나 유실 방지 효과는 측정하지 않았습니다.

기능 설계부터 마지막 코드 수정은 2024년 8월부터 2025년 8월까지 진행했습니다. 신규 주문·결제·정산 운영은 2026년 6월에 종료됐고, 현재는 관리자 조회와 기존 데이터 보존 상태를 유지하고 있습니다.

외부 결제 승인과 내부 DB 저장 사이에는 항상 이중 실패 가능성이 남습니다. 지금 다시 구성한다면 결제 취소 API까지 실패하는 즉시 운영자에게 알리고, 결제사와 내부 주문 상태를 수동 확인·취소할 수 있는 절차부터 명확히 두겠습니다. 검증하지 않은 자동 복구를 구현된 기능처럼 설명하지 않는 것도 중요합니다.

정산에서 DB를 상태 기준으로 둔 판단은 유지할 수 있지만, 서버 로컬 JSON 파일은 로드밸런싱이나 scale-out 환경에서 같은 방식으로 사용할 수 없습니다. 파일을 다른 저장소로 옮길지 DB만으로 관리할지, scheduler 실행 구조를 어떻게 바꿀지는 아직 검토해 확정한 답이 없습니다.

실시간 이벤트에서는 전달 범위와 전달 보장을 분리해서 봐야 한다는 점을 배웠습니다. 사용자나 조직에 속한 상태는 대상별 Room으로 제한하고, 모두가 받아야 하는 진짜 공지만 공용 Room을 사용할 수 있습니다. 다만 Room을 나누는 것만으로 연결이 끊긴 동안의 이벤트 도달을 증명할 수는 없습니다.