이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
결제·라이선스 시스템에서 가장 집중한 것은 상태 전이의 무결성이었습니다. 결제 처리 중 실패가 생겼을 때 상태가 애매하게 남으면 사용자도 서비스도 판단하기 어려운 상황이 생기기 때문에, 각 상태가 명확히 정의되고 전이 조건이 코드로 강제되는 구조를 설계했습니다.
라이선스 만료 처리에서는 만료 예정 알림→유예 기간→만료 후 기능 제한 순서의 단계적 처리 흐름을 구현했습니다. 한 번에 기능이 차단되는 것보다 단계적 전환이 사용자 이탈을 줄이는 데 효과적이었습니다.
결제 실패 재시도 설계에서는 멱등성을 핵심 원칙으로 삼았습니다. 같은 결제 요청이 여러 번 전송됐을 때도 한 번만 처리되도록, 고유 키를 생성해 처리 여부를 먼저 확인하는 로직을 파이프라인 앞에 배치했습니다.
결제·라이센스 시스템을 설계하면서 정상 흐름보다 예외 케이스가 더 어렵다는 것을 경험했습니다. 특히 결제 취소나 환불이 발생했을 때 이미 활성화된 라이센스를 어떻게 처리할지가 가장 판단하기 어려운 부분이었습니다. 즉시 비활성화하면 사용자 입장에서 갑자기 기능이 막히는 경험이 생기고, 잔여 기간까지 유지하면 실제 결제 금액과 서비스 제공 기간이 어긋나는 회계 문제가 생겼습니다. 이 정책은 기술적 결정이 아니라 비즈니스 정책 결정이라는 것을 알게 됐는데, 개발 과정에서 이 질문을 명확히 하지 않으면 나중에 코드를 다시 짜야 하는 상황이 생겼습니다. PG 웹훅을 통해 결제 상태가 변경되는 것을 비동기로 받는 구조에서는 웹훅이 늦게 오거나 누락됐을 때 라이센스 상태가 결제 상태와 어긋나는 케이스도 관리해야 했습니다. 결제 시스템은 정상 흐름 구현이 절반이고, 취소·환불·실패 케이스의 정책을 미리 결정하는 것이 나머지 절반이라는 것을 이 경험에서 배웠습니다.
결제·라이센스 시스템을 운영하면서 두 시스템의 상태가 어긋나는 경우를 감지하는 것이 중요하다는 것을 배웠습니다. PG에서 결제가 완료됐는데 라이센스 활성화가 안 된 케이스, 반대로 결제가 실패했는데 라이센스가 활성 상태로 남아있는 케이스가 생겼습니다. 두 경우 모두 사용자나 운영팀이 직접 발견하기 전까지는 모르는 상태가 지속됐습니다. 정기적으로 PG 결제 내역과 DB의 라이센스 활성화 기록을 비교하는 대사 작업을 스케줄로 돌리니, 불일치가 생겼을 때 알람이 오는 구조를 만들 수 있었습니다. 불일치가 발견됐을 때 자동으로 수정하는 것보다 먼저 알람을 보내고 사람이 확인하는 방식을 선택했는데, 자동 수정이 잘못된 방향으로 가면 더 큰 문제가 생길 수 있었기 때문입니다. 결제 시스템은 구축 이후에도 결제와 라이센스 상태의 동기화를 지속적으로 감시하는 운영 절차가 필요하다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 이스트소프트 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.