이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 장애 대응 프로세스 문서화 작업에 참여한 경험이 있습니다. 실제 장애가 발생했을 때 팀이 우왕좌왕하던 모습을 보고 나서, 장애 단계별로 누가 무엇을 하는지를 정리한 런북이 없다는 점이 문제라는 걸 알았습니다. 저는 탐지→분류→대응→복구→사후 리뷰 다섯 단계로 나눠 각 단계의 담당자와 알림 채널을 표로 정리했고, 팀장님께 검토 요청을 드렸습니다. 이 문서가 팀 내부 위키에 올라가면서 이후 장애 발생 시 첫 대응 시간이 눈에 띄게 줄었다는 피드백을 받았습니다. 사용자와 파트너사의 불편을 최소화하는 핵심은 누구에게 언제 무엇을 알릴지를 사전에 정해두는 것이라고 생각합니다. 장애 상황에서의 커뮤니케이션 흐름을 미리 설계하는 일이 PM의 중요한 역할 중 하나라는 점을 이때 배웠습니다.
인턴 때 장애 대응 프로세스를 문서화하는 작업에 참여하며, 제가 직접 한 건 단계별 런북을 만드는 일이었습니다. 실제 장애가 났을 때 팀이 우왕좌왕하는 걸 보고, 누가 무엇을 하는지 정해진 게 없다는 게 문제라고 봤습니다. 그래서 저는 탐지·분류·대응·복구·사후 리뷰의 다섯 단계로 나눠, 각 단계의 담당자와 알림 채널을 표로 정리했습니다. 이 문서가 팀 위키에 올라간 뒤, 장애 발생 시 첫 대응 시간이 눈에 띄게 줄었다는 피드백을 받았습니다. 사용자와 파트너사의 불편을 줄이는 핵심은 누구에게 언제 무엇을 알릴지를 미리 정해 두는 것이라는 걸 배웠습니다. 다만 제 한계도 인정합니다. 결제 장애는 사용자와 파트너사 두 채널을 동시에 관리해야 하는데, 저는 내부 대응 흐름을 정리한 단계라 대체 라우팅이나 거래 정합성 검증까지 설계해 본 경험은 없습니다. 그래서 런북을 만드는 토대 위에, 복구 후 검증과 재발 방지까지 잇는 역량을 더 키우려 합니다.
결제 장애 대응을 기획할 때 제가 특히 중요하게 보는 건, 사용자와 파트너사라는 두 채널을 동시에 챙겨야 한다는 점입니다. 장애가 나면 사용자는 앱 안에서 무슨 일인지 알아야 이탈과 불신이 줄고, 가맹점이나 PG 같은 파트너사에는 협약 기준 시간 안에 공식 채널로 상황을 전파해야 합니다. 그래서 저는 차단·격리 단계에서 대체 경로로 넘기되, 그때 사용자에게 보일 에러 메시지를 미리 설계해 두는 게 중요하다고 봅니다. 한쪽만 챙기면 다른 쪽에서 불신이 커집니다. 다만 제 한계도 인정합니다. 저는 소통 흐름을 원리로 이해하는 단계라, 복구 후 미결 거래나 중복 결제를 점검하는 거래 정합성 검증까지 실제로 다뤄 본 경험은 없습니다. 또 복구를 완료로 보지 않고 사후 검토로 재발을 막는 데까지 가야 합니다. 그래서 장애 대응을 복구로 끝내는 게 아니라, 두 채널 소통과 재발 방지까지 설계하는 일로 보려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 카카오페이 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.