SPOF 정의를 외우고 있는지가 아니라, 주어진 구조에서 SPOF를 짚어내고 이중화 이후의 부수 문제까지 같이 설계할 수 있는지를 본다. "이중화하면 끝"으로 답하는지, 이중화 이후의 운영 점검 항목까지 가져오는지가 가장 큰 갈림길이다.
SPOF는 어떤 컴포넌트 하나가 죽으면 전체 시스템이 같이 멈추는 구조적 취약점이다. API 서버 한 대, DB 마스터 한 대, 단일 로드밸런서, 한 AZ에만 있는 캐시 — 형태는 다 다르지만 공통점은 "이게 죽으면 끝"이라는 것이다. 다중 인스턴스화·로드밸런싱·자동 failover로 완화하지만, 이중화한 순간부터 세션 일관성·분산 동시성·로그 통합·배포 순서 같은 부수 문제가 같이 따라온다. 그래서 SPOF 제거는 "한 대 더 띄운다"가 아니라 "이중화 이후 시스템을 다시 설계한다"에 가깝다.
단일 인스턴스 장애로 전체 트래픽이 멈춰본 경험이 있다면, 그때 무엇이 SPOF였고 어떻게 끊어 갔는지를 답변에 그대로 가져올 수 있다
이중화 후 세션·캐시 정합이 깨져 곤혹스러웠던 경험이 있다면 "이중화는 끝이 아니다"를 본인 사례로 풀 수 있다
장애 훈련(Chaos·DR 훈련)으로 failover 경로를 실제 끊어본 경험이 있다면 검증 단계의 중요성을 구체적으로 말할 수 있다
블루그린·롤링 같은 배포 전략을 정비하며 SPOF 관점이 바뀐 경험이 있다면 배포·가용성의 연결고리로 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.