이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
리스크를 식별하는 습관은 "이게 실패하면 어떻게 될까"를 배포 전에 미리 쓰는 것에서 시작됐습니다. 팀에서 배포 체크리스트를 만들면서 영향 범위, 롤백 가능 여부, 모니터링 지표를 항목으로 넣었고, 체크리스트를 채우다 보면 미처 생각 못 했던 리스크가 드러나는 경우가 많았습니다. 피처 플래그를 쓰면 배포와 기능 오픈을 분리할 수 있어서, 코드를 먼저 배포한 뒤 트래픽 10% → 50% → 100% 순서로 오픈하는 방식이 실질적인 리스크 관리에 효과적이었습니다. 대응 계획은 구체적인 롤백 커맨드와 담당자가 사전에 명시돼 있어야 긴급 상황에서 혼란이 없었습니다.
인턴 중에 대규모 데이터 마이그레이션 작업을 앞두고 어떤 상황에서 멈춰야 하는지 기준이 없다는 걸 발견했습니다. 팀에서는 그냥 진행하고 문제가 생기면 보자는 분위기였는데, 마이그레이션은 되돌리기 어렵다는 게 마음에 걸렸습니다. 저는 사전에 중단 기준을 문서로 정리했습니다: 오류율 5% 초과, 처리 속도 예상의 50% 미만이면 멈추기로 정했습니다. 실제로 작업 중 오류율이 3%대에서 오르는 걸 보고 원인을 파악해 수정 후 재진행할 수 있었습니다. 기준이 없었다면 언제 멈춰야 할지 판단이 어려웠을 것입니다.
중단 기준을 사전에 정하는 것이 리스크 대응의 핵심이라는 걸 그때 배웠습니다. 지금도 되돌리기 어려운 작업 전에는 멈추는 조건을 먼저 글로 씁니다.
팀 프로젝트에서 외부 결제 API를 처음 연동할 때, API가 갑자기 응답을 안 하면 어떻게 되는가를 아무도 따지지 않고 있었습니다. 저는 장애 시나리오를 직접 작성해서 팀에 공유했습니다: 타임아웃이 너무 길면 요청이 쌓여 서버 전체가 느려질 수 있다는 내용이었습니다. 팀에서 검토 후 타임아웃 3초 + 재시도 2회 + 실패 시 사용자에게 안내 메시지 표시로 정리했습니다. 실제로 테스트 환경에서 API를 강제로 끊어봤더니, 설계한 대로 타임아웃 후 안내 메시지가 잘 뜨는 걸 확인했습니다. 처음에는 기우라고 생각했는데, 장애 상황을 미리 시나리오로 적어두면 팀이 같은 그림을 보고 대응을 준비할 수 있다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.