이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 서버 이중화와 자동 확장을 직접 구성해본 경험이 있습니다. 처음에는 단일 서버로 운영하다가 트래픽이 몰리는 시점에 응답이 느려지는 문제가 생겼고, 로드 밸런서를 앞에 두고 두 인스턴스로 분산하는 구조로 변경했습니다. Auto-scaling 그룹을 설정해 CPU 사용률 70% 이상이 1분 이상 지속되면 인스턴스를 추가하도록 정책을 잡았고, 부하가 줄면 최소 인스턴스 수로 자동 축소되게 했습니다. 이 과정에서 스케일 아웃 시 세션 공유 문제를 처음으로 겪었는데, 세션을 인메모리가 아닌 Redis로 분리해 해결했습니다. 트래픽 패턴을 분석한 뒤 스케일링 임계값을 조정하는 과정이 생각보다 여러 번의 실험을 필요로 했습니다.
시스템 이중화는 설정보다 장애 시나리오를 먼저 정의하는 것이 더 중요하다는 결을 이 경험에서 얻었습니다.
사내 스터디 프로젝트에서 Active-Active 이중화와 Active-Standby를 직접 비교해본 경험이 있습니다. Active-Standby로 먼저 구성했을 때 장애 감지 후 전환까지 30초 이상이 걸려 체감 단절이 발생했습니다. 두 방식의 전환 속도와 월 비용을 비교표로 정리한 뒤 Active-Active로 변경했고, 로드 밸런서 헬스체크 간격을 5초로 조정해 장애 시 인스턴스 교체까지 10초 이내로 줄였습니다.
Auto-scaling 임계값은 CPU 70%로 시작했는데, 급격한 트래픽 스파이크 때 인스턴스 추가가 1분 늦어지는 경우가 생겼습니다. 예측 스케일링(Scheduled Scaling)으로 트래픽이 집중되는 시간대에 미리 인스턴스를 늘려두니 스파이크 대응 지연이 사라졌습니다.
가용성은 99.9%에서 99.97%로, Spot 인스턴스 혼합으로 비용은 약 23% 줄었습니다. 수치를 쥐어야 트레이드오프를 설명할 수 있다는 결을 이 경험에서 얻었습니다.
인프라 비용을 줄여야 하는 상황에서 Spot 인스턴스 혼합 전략을 처음 설계해봤습니다. 온디맨드 Auto-scaling 그룹에 Spot을 30% 섞는 혼합 정책으로 바꾸었는데, Spot이 예고 없이 회수되는 상황을 대비하지 않아 초반에 서비스가 짧게 끊기는 일이 생겼습니다. 회수 알림(2분 전 인터럽트 신호)을 훅으로 잡아 진행 중인 요청을 다른 인스턴스로 드레인하는 로직을 추가한 뒤부터 회수가 일어나도 사용자 영향이 없어졌습니다.
Scheduled Scaling은 2주치 트래픽 데이터를 분석해 오전 9시·오후 6시에 인스턴스를 미리 늘리는 정책으로 적용했습니다. 전략은 트래픽 패턴 분석 → 비용 시뮬레이션 → 장애 시나리오 검증 순으로 짜야 실제로 작동한다는 걸 배웠습니다. 설정 하나로 끝나는 게 아니라 패턴을 읽고 판단해야 하는 작업이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부스터즈 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.