이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 결제 흐름 성능을 개선한 경험이 있습니다. 사용자가 결제 버튼을 누른 뒤 완료 화면까지 4초 이상이었는데, 이를 줄이는 것이 목표였습니다. 먼저 각 단계의 소요 시간을 로그로 측정해보니, 외부 PG사 API 호출과 재고 확인 쿼리가 순차 실행되는 구조가 병목이었습니다.
비동기 처리로 병렬화 가능한 단계를 분리했고, 재고 확인에 캐시 레이어를 추가했더니 평균 결제 완료 시간이 1.8초로 줄었습니다. 결제 흐름 최적화에서 병렬화와 캐싱 외에 가장 중요했던 건 실패 케이스를 건드리지 않는 것이었는데, 성능 개선 과정에서 오류 처리 로직을 실수로 바꾸면 금액 오류로 이어질 수 있었습니다. 지금도 성능 최적화 코드는 기존 오류 경로를 그대로 유지하는지 먼저 검증하는 순서를 지킵니다.
결제 흐름을 최적화하기 전에 어느 단계에서 시간이 가장 많이 걸리는지 먼저 측정했습니다. 막연히 "빠르게 만들자"는 방향으로 시작하면 효과 없는 자리에 시간을 쓰는 경우가 생기기 때문입니다.
각 단계에 타임스탬프 로그를 추가해서 재고 확인·결제 게이트웨이 호출·DB 저장 순서로 소요 시간을 분리했습니다. 결제 게이트웨이 호출이 전체 시간의 60% 이상을 차지한다는 걸 측정 전까지 몰랐습니다. 비동기 처리 범위를 그 자리에만 집중하니 전체 응답 시간이 줄었습니다.
이 경험으로 최적화는 느낌이 아니라 측정에서 시작해야 한다는 걸 배웠습니다. 측정 없이는 개선 방향이 틀릴 수 있었습니다.
결제 흐름에서 재시도 로직을 처음 만들었을 때 중복 결제가 발생하는 경험을 했습니다. 결제 요청이 타임아웃으로 실패했는데 클라이언트가 재시도하면서 같은 결제가 두 번 처리됐습니다.
이후엔 멱등성 키를 요청에 포함시켜 서버 쪽에서 같은 키가 이미 처리된 요청인지 먼저 확인하는 구조로 바꿨습니다. 타임아웃이 발생해도 재시도가 안전하게 처리되는 흐름이 만들어졌습니다.
이 경험으로 결제 최적화는 빠르게 만드는 것만큼 안전하게 재시도하는 것도 한 축이라는 걸 배웠습니다. 멱등성이 없는 결제 흐름은 언제든 중복 결제의 여지가 있었습니다. 이 교훈은 처음 설계할 때 재시도 시나리오를 함께 그려야 한다는 걸 알게 해줬습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.