이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
장애나 이슈가 발생했을 때 대응한 경험은 수업 프로젝트에서 배포한 웹 서비스에 오류가 생겨 기능이 작동하지 않은 상황입니다. 가장 먼저 한 건 어떤 기능에서 어떤 범위로 문제가 생겼는지를 빠르게 파악하는 것이었습니다. 영향 범위를 모르면 우선순위를 잡기 어렵습니다. 사용자에게 영향을 주는 부분은 임시 조치로 일단 안정화하는 것이 먼저였고, 근본 원인은 그 이후에 분석했습니다. 원인을 찾는 과정에서는 에러 로그를 순서대로 따라가면서 어느 지점에서 문제가 발생했는지를 좁혀가는 방식을 썼습니다.
수정 후에는 같은 조건에서 재현이 안 되는지를 확인하는 단계가 중요합니다. 이슈 대응은 빠른 복구와 근본 원인 제거, 두 단계를 분리해서 접근하는 것이 핵심입니다.
수업 프로젝트로 배포한 웹 서비스에서 갑자기 핵심 기능이 멈춘 적이 있습니다. 제가 먼저 한 건 어느 기능이 어느 범위까지 영향을 받는지 빠르게 확인하는 일이었습니다. 사용자에게 닿는 부분은 임시 조치로 일단 막아 두고, 근본 원인은 그다음에 봤습니다. 에러 로그를 순서대로 따라가며 문제 지점을 좁혔는데, 제 지식만으로는 한 대목에서 막혔습니다. 그래서 혼자 붙잡고 있기보다, 그 영역을 잘 아는 팀원에게 로그를 보여 주며 도움을 청해 원인을 가렸습니다. 수정한 뒤에는 같은 조건에서 재현되지 않는지 확인하는 단계를 꼭 거쳤습니다. 다만 그때의 대응은 즉흥적인 면이 있어, 이후엔 장애가 나면 영향 파악·임시 조치·원인 분석·재현 확인 순서를 미리 정해 두었습니다. 이슈 대응은 빠른 복구와 근본 원인 제거를 분리해 접근하는 게 핵심이라고 배웠습니다.
장애가 났을 때 제가 가장 중요하게 지키는 건 빠른 복구와 근본 원인 제거를 섞지 않는 일입니다. 수업 서비스에서 오류가 났을 때, 원인부터 파헤치려다 그동안 사용자 피해가 계속된 적이 있었습니다. 그래서 그 뒤로는 순서를 분명히 했습니다. 먼저 영향 범위를 파악해 사용자에게 닿는 부분을 임시로라도 안정화하고, 근본 원인은 불을 끈 다음에 차분히 분석합니다. 급할수록 이 둘을 분리해야 피해가 줄어든다고 느꼈습니다. 원인을 찾을 때는 에러 로그를 따라가며 문제 지점을 좁혔습니다. 다만 제 한계도 인정합니다. 임시 조치가 근본 수정을 미루는 핑계가 되면 같은 장애가 반복되는데, 그 균형을 잡는 게 어려웠습니다. 그래서 임시 조치 뒤엔 반드시 원인 분석과 재현 확인까지 가는 걸 규칙으로 두었습니다. 장애 대응은 두 단계를 분리하되 둘 다 끝까지 가는 일이라고 봅니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.