결제 금액의 정합성이 중요한 주문/프로모션 영역에서 6년간 일해왔습니다. TV홈쇼핑과 온라인몰이 함께 있는 이커머스 환경에서 주문/프로모션 도메인 서비스의 API와 배치를 개발해왔고, 외부 서비스 연동과 프로젝트 CI/CD 구성까지 전 주기를 경험했습니다.
최근에는 프로모션 효율성 분석 자동화 PoC와 영업/물류 도메인 분리(MSA 전환) 과제를 이어서 맡으며 범위를 넓히고 있고, 개인 사이드 프로젝트도 기획부터 배포까지 직접 진행하고 있습니다.
금액이 얽힌 문제일수록 전체 흐름부터 살핀다
기존 청구할인은 결제 시점이 아닌 카드사 정산 시점에 할인이 반영되어 고객이 혜택을 즉시 체감하기 어려웠고, 내부적으로는 정산 이후 경정청구와 수기 정산 업무가 반복되는 구조였습니다. 카드즉시할인 프로젝트에서 이를 결제 단계에서 할인금액이 즉시 차감되는 구조로 전환하는 과제를 맡았습니다.
가장 어려웠던 점은 여러 할인이 정해진 순서로 적용되며 앞 단계의 결과 금액이 뒷 단계의 기준 금액이 되는 구조에 새로운 할인을 안전하게 편입시키는 일이었습니다. 앞선 할인에 영향이 없도록 청구할인과 동일한 단계에 배치하는 것으로 판단했고, 결제만이 아니라 취소/부분취소, 반품, 결제수단변경 시 할인 환원까지 함께 설계해야 금액이 맞았기 때문에 주문부터 클레임까지 전 구간을 하나의 흐름으로 놓고 검토했습니다. TV, ARS, 웹, 앱 등 채널마다 결제 흐름이 달라 채널별 영향도를 정리해 시나리오별로 검증했고, 오픈 이후 금액 정합성 이슈 없이 안정적으로 운영되어 경정청구와 수기 정산 업무 비용을 절감하는 데 기여했습니다.
명세의 빈틈을 그냥 지나치지 않는다
저의 업무 방향성은 신입 때의 경험에서 굳어졌습니다. 첫 과제가 백오피스의 ActiveX 기반 CTI 레거시를 이벤트 드리븐 방식으로 전면 재개발하는 일이었는데, 테스트 환경 없이 관련 문서만으로 구현했다가 실제 장비를 연결한 뒤 동작 차이가 드러나 수정해야 했습니다. 그 이후로 인터페이스 명세의 빈틈이 없는지 분석하고 확인하는 것이 습관이 되었습니다.
이후 다른 프로젝트에서 표준 아키텍처 정의와 공통 모듈, 배포 환경, CI/CD를 담당하면서는 한 번의 수정이 서비스 전체로 번지는 공통 영역의 특성상 변경 전 영향 범위를 정리해 관련 개발자에게 공유하며 일했고, 제 파트 밖의 업무까지 파악하려는 성향도 이때 굳어졌습니다.
필요한 서비스는 직접 만들고, 운영하며 키워간다
회사 밖에서도 정합성과 동시성 문제를 직접 운영하며 겪고 있습니다. 제가 개발 중인 피트니스 통합 관리 시스템은 급여정산과 회원관리, PT 수업관리를 위한 백오피스로 시작했습니다. 현장에서는 매월 정산 기간마다 세션 기록과 정산 데이터를 일일이 대조하느라 2~3일씩 야근이 반복되고 있었는데, 수업 기록이 급여 계산과 정산까지 하나의 흐름으로 이어지게 만들어 수작업을 없앴고, 1개 지점에서 시작해 지금은 4개 지점까지 확대 운영하고 있습니다.
실제로 쓰이기 시작하면서 현장 요구가 계속 붙어 GX, 필라테스, 요가 수업까지 도메인을 넓혔습니다. 정원이 있는 수업 예약은 오픈 시점에 동시 요청이 몰리면 정원을 넘길 수 있어 Redis 분산 락을 적용하고 정원 검증과 예약 등록을 하나의 트랜잭션으로 묶어 초과 예약을 막았고, 예약 상태 변경은 화면마다 폴링을 두는 대신 서버에서 단방향으로 밀어주는 SSE로 처리했습니다. 종이로 받던 회원 계약은 전자계약으로 바꿔 서명 이력이 데이터로 남게 했고, EC2에 Docker Compose와 Nginx로 배포도 직접 하고 있습니다.
핵심역량
- E-커머스 핵심 도메인(상품/주문/프로모션/클레임) End-to-End 설계, 개발 경험
- 대량 쿼리 튜닝과 캐싱 적용 등 성능 최적화 및 서비스 안정화 경험
- 레거시 시스템(Adobe Flex → ExtJS) 마이그레이션 리드 및 CTI 시스템 이벤트 기반 아키텍처 전환
- Jenkins 기반 CI/CD 파이프라인 구축 및 배포 자동화 경험
