카카오페이 백엔드 면접 질문 — Kafka를 외우지 말고, 실패한 결제의 다음 상태를 답하세요

카카오페이 백엔드 면접을 검색하면 Java·Kotlin, Spring Boot, Kafka, MSA부터 줄을 세우게 됩니다. 공고에 적힌 기술이니 틀린 준비는 아닙니다. 그런데 그 목록에서 멈추면 답은 전부 ‘써봤습니다’가 됩니다.

공고 한가운데에는 더 까다로운 문장이 있습니다. 데이터 불일치를 탐지하고 보정하는 대사 로직. 외부 금융기관의 처리는 끝났는데 우리 서버의 응답이 끊겼다면, 그 결제는 성공일까요, 실패일까요. 이 직무가 확인하려는 건 기술 이름의 개수가 아니라 돈의 상태가 어긋난 순간부터 다시 맞을 때까지의 설계입니다.

💳 실제로 보는 것 — 기술보다 돈의 상태

Cue가 보관한 카카오페이 결제 서비스 공고에는 승인·취소·매입, 동시성 제어, 분산 트랜잭션, 외부 금융기관 연동, 불일치 탐지·보정, 모니터링이 한 업무 흐름 안에 놓여 있습니다. 서로 떨어진 기술 문제가 아닙니다.

결제 요청이 들어옵니다. 외부 승인은 성공합니다. 그 직후 우리 서버의 응답이 끊깁니다. 사용자가 다시 누릅니다. 이제 시스템은 성공·실패·확인 중 가운데 상태를 구분하고, 같은 돈이 다시 움직이지 않게 막고, 외부 기록과 내부 기록을 맞춰 최종 상태를 확정해야 합니다.

Kafka는 이 흐름에 쓰일 수 있는 도구입니다. 정합성은 이 흐름이 끝난 뒤 설명할 수 있어야 하는 결과고요. 둘을 바꿔 말하면 면접 답도 바뀝니다. ‘Kafka를 썼습니다’는 이력이고, ‘응답 유실 뒤 중복 처리를 막고 최종 상태를 확인했습니다’는 채용 근거입니다.

📋 면접관 화면에서 ‘Kafka’는 답이 아니라 근거가 됩니다

카카오페이의 실제 면접 평가표는 공개되지 않았습니다. 그러니 칸 이름까지 안다고 쓰면 거짓말입니다. 다만 뽑는 쪽에서 공고를 면접 도구로 바꾸는 순서는 공개돼 있습니다.

고용노동부·한국산업인력공단의 「2025 공정채용 가이드북」은 포지션별 능력 정의로 평가요소를 구체화하고, 질문지와 평가표를 준비한 뒤, 답변을 정리해 결과를 E-HR 시스템에 입력하도록 안내합니다. 공고의 문장이 면접관 머릿속 감상으로 끝나는 게 아니라 평가할 칸과 그 칸을 채울 질문으로 바뀌는 겁니다.

20년 넘게 채용과 면접을 운영해온 경험으로 보면, 평가표에 옮기기 쉬운 답은 ‘Kafka 경험 있음’이 아닙니다. 외부 승인은 끝났지만 내부 응답이 끊긴 상황에서 요청 식별자로 중복을 막고, 대사 작업으로 최종 상태를 확인했다처럼 조건·행동·확인이 붙은 문장입니다. 면접관이 받아 적을 근거가 있어야 채용 회의에도 가져갑니다.

🙃 예상질문 탭을 늘릴수록 답은 더 얇아집니다

Kafka와 RabbitMQ의 차이, 분산 락의 종류, ACID 정의를 묻는 탭을 계속 열고 있나요. 지식 확인에는 쓸모가 있습니다. 하지만 탭마다 정답을 외우면 결제가 중간에서 끊겼을 때 무엇부터 지킬지는 여전히 안 보입니다.

Kafka·RabbitMQ 예상질문을 더 외우는 건 소용없습니다. 평가표에 남는 건 도구 이름이 아니라 결제가 끊긴 뒤 중복을 막고 상태를 맞춘 근거입니다. 대신 당신이 겪은 장애나 예외 상황 하나를 요청 → 불일치 → 복구 → 검증 네 칸으로 적으세요.

요청: 같은 요청임을 무엇으로 식별했나.
불일치: 내부와 외부 중 어디까지 끝났는지 어떻게 구분했나.
복구: 재시도·보상·수동 확인 가운데 무엇을 선택했고 중복은 어떻게 막았나.
검증: 최종 상태가 맞다는 것을 어떤 로그·대사·알림으로 확인했나.

정답지는 기술 블로그가 아닙니다. 장애 뒤 상태도입니다.

🎯 대표 질문은 달라도, 답변 기준은 한 줄입니다

아래 질문은 실제 면접 후기가 아닙니다. Cue가 공개 공고의 업무와 자격을 질문으로 뒤집어 보관한 대표 질문입니다. 출제 문구를 맞히는 용도가 아니라, 공고가 요구한 증거를 꺼내는 용도로 보세요.

“결제 시스템에서 데이터 정합성과 트랜잭션 관리를 어떻게 처리하나요?”
ACID 설명으로 끝내지 마세요. 한 트랜잭션으로 묶을 수 있는 경계와 외부 연동 때문에 묶을 수 없는 경계를 먼저 가르세요. 그다음 알 수 없는 상태를 어떻게 표시했는지, 중복 요청을 무엇으로 막았는지, 대사 뒤 최종 상태를 어떻게 확정했는지까지 가야 합니다.

“고가용성 아키텍처를 설계할 때 무엇을 고려하나요?”
구성도에 서버를 더 그리는 답은 약합니다. 무엇이 실패 단위였는지, 그때 결제를 중단할지 제한적으로 받을지, 전환 과정에서 중복 처리를 어떻게 막을지, 복구 완료를 무엇으로 판단할지 말하세요. 가용성도 결국 돈의 상태를 흐리지 않는 설계여야 합니다.

“TDD와 단위·통합 테스트에서 어떤 이점을 기대하나요?”
테스트 수나 커버리지 자랑보다 깨지면 안 되는 조건을 꺼내세요. 같은 요청이 다시 들어온 경우, 외부 성공 뒤 내부 응답이 끊긴 경우, 승인과 취소가 맞물린 경우를 어떤 테스트 경계에 두었는지가 답입니다.

세 질문의 대본을 따로 만들 필요는 없습니다. 같은 사례 하나를 정합성에서는 경계로, 고가용성에서는 복구로, 테스트에서는 불변 조건으로 꺼내면 됩니다.