이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 서버 한 대에 모든 요청을 처리하다가 장애가 생기는 경험을 하면서 고가용성 설계에 관심을 갖게 됐습니다. 중복화가 기본이라는 걸 배웠고, 로드밸런서 뒤에 여러 인스턴스를 두는 구조를 만들어서 한 대가 내려가도 서비스가 이어지게 했습니다. 장애 격리 측면에서는 하나의 마이크로서비스 장애가 전체로 번지지 않도록 서킷 브레이커 패턴을 배웠습니다. 재시도 로직에서는 지수 백오프를 적용해서 장애 상황에서 재시도 폭풍이 생기지 않도록 했습니다. 관측도 중요해서, 인스턴스별 상태와 에러율을 개별로 추적해서 특정 인스턴스만 비정상인 경우를 빠르게 감지하게 했습니다.
고가용성은 장애가 났을 때 대응하는 게 아니라 장애가 나도 버티는 구조를 미리 만드는 것이라는 걸 배웠습니다.
고가용성 구조를 만들면서 얼마나 잘 되는지 수치로 확인하는 방법도 중요하다는 것을 배웠습니다. 인스턴스를 여러 개 두는 것이 고가용성이라는 체감은 있었는데, 실제로 가용률이 몇 퍼센트인지 측정하는 기준을 정하지 않으면 개선됐는지 알 수 없었습니다. 서비스 수준 목표를 정의하면서 99.9% 가용성이 한 달에 약 44분의 다운타임을 허용한다는 의미라는 것을 계산해봤는데, 이 숫자를 알고 나니 장애 대응의 우선순위를 판단하는 기준이 생겼습니다. 장애 발생부터 복구까지 걸리는 평균 시간도 지표로 추적했는데, 이 수치가 높으면 복구 절차가 비효율적이거나 탐지가 늦다는 신호였습니다. 알람이 울린 시점과 실제 장애 발생 시점의 차이를 줄이는 것이 복구 시간을 단축하는 첫 번째 단계라는 것도 배웠습니다. 고가용성은 구조를 만드는 것만큼, 그 구조가 실제로 목표를 달성하는지 지표로 확인하는 과정이 함께 있어야 한다는 것을 이 경험에서 배웠습니다.
고가용성 구조를 설계한 후 실제로 장애가 나도 버티는지 검증하는 것도 중요하다는 것을 배웠습니다. 이론적으로 인스턴스 하나가 내려가도 다른 인스턴스로 트래픽이 넘어가야 하는데, 실제로 인스턴스를 내려봤더니 페일오버에 걸리는 시간이 예상보다 길었습니다. 헬스 체크 주기가 너무 길게 설정돼 있어서 로드밸런서가 죽은 인스턴스를 늦게 감지했던 것이 원인이었습니다. 서킷 브레이커도 설정이 까다로웠는데, 임계값을 너무 민감하게 잡으면 일시적인 지연에도 서킷이 열려서 정상적인 요청까지 차단하는 오탐이 생겼습니다. 반대로 너무 느슨하면 장애가 퍼지는 것을 막지 못했습니다. 의도적으로 장애를 주입해서 복구 절차를 실전처럼 훈련하는 방식이 설정 문제를 발견하는 가장 효과적인 방법이었습니다. 장애 대응 능력은 훈련 없이 실전에서 처음 써보면 예상치 못한 문제가 나온다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 누아 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.