이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 소규모 마켓플레이스 정산 시스템을 직접 설계하며 핀테크 도메인의 핵심을 체험했습니다. 판매자별 수수료·부분 환불·세금 처리가 겹치는 케이스에서 금액 불일치가 발생했고, 원인을 파악하니 부동소수점 연산 오차가 누적되는 문제였습니다.
BigDecimal 기반으로 전면 교체하고 원 단위 반올림 정책을 코드에 명시하니 불일치가 사라졌습니다. 이 경험은 핀테크 정산에서 정밀도 보장이 UX보다 선행돼야 하는 이유를 체감하게 해줬고, 실제 핀테크 서비스의 정산 로직이 왜 복잡하게 설계되는지 이해하는 기반이 됐습니다.
감사 로그와 정산 재계산 가능성도 처음부터 설계에 포함하는 것이 중요하다는 것도 배웠습니다.
정산 시스템을 만들면서 처음에는 계산 결과를 저장하는 것에만 집중했는데, 나중에 계산 로직에 버그가 발견됐을 때 이미 처리된 건들을 다시 계산하는 방법이 없었습니다. 잘못 계산된 금액을 수동으로 찾아서 수정하는 데 오랜 시간이 걸렸습니다. 이 경험에서 정산 시스템에서 재계산 가능성은 선택이 아니라 필수라는 것을 배웠습니다. 원본 입력값을 보존하고 계산 로직을 언제든 다시 실행할 수 있는 구조를 설계하는 것이 정산 시스템의 운영 안정성을 위해 중요하다는 것을 알게 됐습니다. 핀테크 정산에서 계산 결과의 정확성을 보장하는 것과 함께 오류가 생겼을 때 빠르게 수정하고 소급 적용할 수 있는 구조를 만드는 것이 실무에서 더 중요한 역량이라는 것을 이 경험에서 배웠습니다.
정산 시스템에서 처음에는 전체 환불만 처리하는 방식으로 설계했는데, 나중에 부분 환불 요구가 생기면서 계산 로직이 복잡해지는 경험을 했습니다. 수수료가 금액 비율로 계산되는 경우 부분 환불 시 수수료를 어떻게 처리할지, 세금은 어떻게 소급 적용할지를 처음부터 고려하지 않았던 것이 원인이었습니다. 이미 구현된 계산 로직을 부분 환불을 지원하도록 바꾸는 것이 처음부터 설계에 반영했을 때보다 훨씬 복잡했습니다. 정산 시스템에서 예외 케이스인 것처럼 보이는 부분 환불, 취소, 이중 결제 같은 상황이 실제로는 자주 발생하고, 이런 케이스를 처음부터 설계에 포함하는 것이 핀테크 정산 경험에서 가장 중요한 교훈이라는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.