이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 회계 시스템과 PG사 API를 연동하는 작업을 담당했습니다. 테스트 환경에서는 잘 됐는데 실제 배포 후 중복 결제가 간헐적으로 발생했습니다. 추적해보니 멱등성 키 없이 재시도 로직을 짠 게 원인이었습니다. 트랜잭션 ID를 요청마다 생성해 DB에 기록하고, 동일 키가 들어오면 이전 결과를 그대로 반환하도록 고쳤습니다. 재시도에는 지수 백오프를 붙여 서버 부하도 줄였습니다. 이후 한 달간 중복 결제 0건을 유지했고, 팀에서 API 연동 가이드라인을 만들 때 이 경험을 사례로 넣었습니다. 이후 팀 내에서 멱등성 설계를 첫 번째 항목으로 넣었고, 재시도 로직은 항상 백오프와 함께 고려하도록 공유했습니다. 외부 금융 API는 처음부터 멱등성을 설계에 포함해야 한다는 걸 직접 겪으며 배웠습니다.
외부 금융 API 연동에서 OAuth 2.0 기반 토큰 인증을 구현한 경험이 있습니다. 처음에는 토큰을 환경 변수로만 관리했는데, 토큰 만료 시 처리 로직이 없어서 특정 시간대에 요청이 일괄적으로 실패하는 문제가 생겼습니다. 기술 스택으로는 Python requests + JWT 디코딩 + Redis 캐시를 조합해 토큰을 저장하고, 만료 전에 자동 갱신하는 구조를 만들었습니다. API 연동 경험으로는 은행 오픈 API와 연동해 잔액 조회와 이체 내역을 회계 시스템에 자동으로 반영하는 기능을 담당했습니다. 수동으로 입력하던 거래 내역이 자동화되면서 오류율이 크게 줄었습니다. 문제 해결로는 토큰 캐시가 만료됐을 때와 API 서버가 일시적으로 응답하지 않을 때를 구분하는 에러 핸들링을 추가하는 것이 핵심이었습니다. 같은 네트워크 오류처럼 보여도 원인이 달라 대응이 달라야 했습니다. 프로젝트 결과로는 기존에 1시간 걸리던 수동 대사 작업이 5분 자동화로 대체됐습니다.
외부 API 연동은 정상 케이스보다 예외 케이스를 얼마나 촘촘하게 설계하느냐가 신뢰성을 결정합니다.
외부 PG사와 연동할 때 결제 완료 이벤트를 웹훅으로 수신하는 방식을 구현한 경험이 있습니다. 폴링 방식보다 실시간성이 높고 서버 부하가 낮다는 판단에서 웹훅을 선택했습니다. API 연동 경험으로는 웹훅 수신 엔드포인트를 만들고, 서명 검증으로 위변조를 차단하는 구조를 먼저 설계했습니다. PG사마다 서명 방식이 달라 각각 처리 로직을 분리했습니다. 기술 스택으로는 FastAPI + Celery + Redis 조합으로 웹훅 수신과 실제 처리를 분리했습니다. 수신은 빠르게 응답하고, 처리는 비동기로 넘겨 타임아웃 없이 처리하는 구조입니다. 문제 해결로는 간헐적으로 같은 이벤트가 두 번 들어오는 경우가 있었습니다. 웹훅은 재전송이 보장되는 구조라 멱등성 처리를 놓치면 중복 처리가 생깁니다. 이벤트 ID를 DB에 기록하고 중복 확인 후 처리하는 방식으로 해결했습니다. 프로젝트 결과로는 결제 이후 재고 차감과 정산 계정 반영이 즉시 이루어지는 구조가 완성됐습니다.
웹훅 설계의 핵심은 빠른 수신과 안전한 처리를 분리하는 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.