면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
개인 프로젝트로 운영하던 서비스가 가끔 알 수 없는 이유로 응답이 멈추는 문제가 있었는데, 매번 제가 직접 서버 상태를 확인하고 수동으로 재시작하는 게 번거로웠습니다. 그래서 도커 컨테이너의 헬스체크 기능을 이용해 응답이 없으면 자동으로 컨테이너를 재시작하도록 설정을 추가했습니다. 처음 설정할 때는 체크 주기를 너무 짧게 잡아서 정상 상태인데도 재시작이 반복되는 문제가 생겼는데, 주기와 타임아웃 값을 조정하고 나서야 안정됐습니다. 이 경험으로 자동화는 설정값 하나로도 오히려 문제를 키울 수 있어 신중한 튜닝이 필요하다는 걸 배웠습니다.
졸업 프로젝트 발표를 앞두고 배포한 새 기능에서 특정 페이지가 로딩되지 않는 문제가 발생한 적이 있습니다. 저는 처음에 원인을 바로 찾아 고치려 했는데, 시간이 지체되면서 발표 시연에 지장이 생길 것 같아 팀원의 제안으로 먼저 이전 버전으로 롤백했습니다. 롤백 후 안정된 상태에서 여유를 갖고 원인을 다시 살펴보니 새로 추가한 API 호출 경로가 잘못돼 있었습니다. 그때는 원인부터 고치고 싶은 마음이 컸는데, 서비스 영향을 먼저 줄이고 나서 원인을 찾는 순서가 더 안전하다는 걸 그 경험으로 배웠습니다.
스터디에서 함께 운영한 서비스에 장애가 났을 때 한참 뒤에야 사용자 문의로 알게 된 적이 있습니다. 그 일을 계기로 저는 무료 모니터링 도구를 이용해 응답 시간이 일정 기준을 넘으면 슬랙으로 알림이 오도록 설정했습니다. 처음엔 임계값을 너무 낮게 잡아 사소한 지연에도 알림이 계속 와서 오히려 무시하게 되는 부작용이 있었는데, 임계값을 다시 조정하고 나서야 실제 이상 신호만 걸러낼 수 있었습니다. 이 경험으로 장애 대응은 빨리 발견하는 체계를 만드는 것부터 시작해야 한다는 걸 배웠고, 알림 설정도 정교하게 다듬어야 실효성이 있다는 걸 알게 됐습니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.