이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
고가용성·재해복구 아키텍처를 직접 설계한 경험은 없습니다. 수업에서 설계 시 가장 중요하게 봐야 할 두 지표로 RTO(복구 목표 시간)와 RPO(복구 목표 지점)를 배웠습니다. "얼마나 빨리 복구되는가"와 "최대 얼마까지 데이터를 잃어도 되는가"를 먼저 정해야 아키텍처 선택이 가능하다는 것이었습니다.
케이스에서 인상적이었던 건 비용과 가용성의 트레이드오프였습니다. Active-Active 구성은 가용성이 높지만 비용이 크고, Active-Standby는 비용이 낮지만 Failover 시간이 길어지는 구조라는 차이를 분석했습니다.
직접 설계 경험은 없지만, 고가용성 설계에서 가장 먼저 확인할 것은 비즈니스가 실제로 요구하는 가용성 수준이라고 생각합니다. 과도하게 높은 가용성 목표는 그 자체로 운영 비용과 복잡도를 늘리는 위험이 된다고 봅니다.
고가용성과 재해복구 아키텍처 설계에서 모든 것을 최고 수준으로 보장하는 것은 비용과 복잡도 때문에 현실적이지 않습니다. 전체 시스템을 Active-Active로 구성하면 가용성은 높아지지만 데이터 동기화 문제가 생기고 비용도 늘어납니다. 어느 서비스는 RTO 1시간이 허용되고 어느 서비스는 5분도 안 되는지를 먼저 파악하는 것이 설계의 시작입니다.
서비스 중요도에 따른 등급 분류가 거래를 의식한 설계를 가능하게 합니다. 모든 것을 동일한 수준으로 보호하려다가 정작 중요한 서비스에 집중하지 못하는 자리가 생깁니다. 우선순위를 명확히 하는 것이 재해복구 설계를 실질로 만드는 결이 됩니다. 이 거래 의식이 있어야 제한된 자원으로 최선의 가용성 구조를 만들 수 있습니다. 거래를 의식한 설계가 비용과 성능 사이에서 합리적인 균형을 찾는 방법입니다.
고가용성과 재해복구 개념이 실제 결정에 쓰인 자리가 학습의 결입니다. 저는 홈랩에서 VM을 구성할 때 스냅샷을 언제 찍고, 백업 주기를 어떻게 잡을지를 결정하면서 RTO와 RPO 개념이 직접 판단 기준이 된 경험이 있습니다. 소규모 환경이지만 같은 질문을 하게 된다는 것을 알았습니다.
백업이 있어도 복구 테스트를 안 하면 의미가 없다는 원칙을 직접 확인한 것도 그 경험에서 나왔습니다. 이론으로 알던 것이 실제 결정의 기준이 될 때 이해의 밀도가 달라집니다. 그 경험이 있어야 더 큰 환경의 설계에서도 같은 질문을 할 수 있는 결이 생깁니다. 손에 쥔 경험이 있는 사람과 이론만 아는 사람의 차이는 질문의 구체성에서 드러납니다. 이 구체성이 면접과 실무 모두에서 신뢰를 만드는 결입니다. 작은 환경에서 배운 원칙이 큰 환경에서도 같은 방식으로 작동합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 시스템 운영 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.