이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴에서 Oracle RAC(Real Application Cluster) 기반 고가용성 구성을 직접 담당하지는 않았지만, 운영 중인 시스템의 장애 대응 과정을 옆에서 지켜봤습니다. Active-Active 구성으로 두 노드가 같은 데이터를 공유하는 구조에서, 한 노드 장애 시 자동으로 페일오버가 일어나는 과정이 인상 깊었습니다. 가용성을 높이기 위해 스토리지 다중화와 네트워크 본딩이 함께 설계돼야 한다는 점도 배웠습니다. 그 경험에서 고가용성은 소프트웨어만의 문제가 아니라 인프라 전체의 설계 문제라는 걸 이해했습니다.
단일 장애점을 없애는 것이 고가용성 설계의 출발점임을 알게 됐습니다. 고가용성은 소프트웨어와 인프라가 함께 설계될 때 실질적으로 작동하며, 단일 장애점을 없애는 구조가 그 출발점임을 이 경험에서 배웠습니다.
Oracle DB 운영에서 고가용성 외에 성능 관리 측면에서 인상 깊었던 경험이 있습니다. 인턴 때 대규모 로그 테이블에 대한 조회 쿼리가 느려지는 문제를 분석하는 작업에 참여했습니다. EXPLAIN PLAN을 통해 전체 테이블 스캔(Full Table Scan)이 발생하고 있는 것을 확인했고, 날짜 컬럼 기준으로 파티션 테이블로 재구성하는 방안을 제안하는 과정을 옆에서 봤습니다. 파티셔닝 이후 해당 날짜 범위만 스캔하는 구조가 되어 쿼리 실행 시간이 크게 줄어드는 결과가 나왔습니다. 수업에서 배운 인덱스와 파티셔닝 개념이 실제 운영 환경에서 어떻게 쓰이는지를 직접 확인한 경험이었습니다.
대용량 데이터 환경에서 설계 단계의 파티셔닝 전략이 이후 운영 비용을 결정한다는 것을 그 경험에서 배웠습니다.
고가용성 아키텍처 설계에서 장애 발생 시 얼마나 빠르게, 얼마나 최신 데이터로 복구할 수 있는가를 정의하는 RPO와 RTO 개념을 이해한 것이 중요한 배움이었습니다. RPO(Recovery Point Objective)는 복구 시점에서 허용 가능한 데이터 손실 범위이고, RTO(Recovery Time Objective)는 복구에 허용되는 최대 시간입니다.
이 두 지표를 낮출수록 더 많은 인프라 비용이 들기 때문에, 비즈니스 요구사항에 따라 적정 목표를 설정하는 것이 설계의 핵심입니다. 인턴 때 DR(재해복구) 계획 문서를 검토하면서 Oracle Data Guard를 통한 실시간 로그 전송으로 RPO를 0에 가깝게 유지하는 구성을 배웠습니다.
고가용성 설계의 도전은 기술보다 '얼마나 가용성이 필요한가'를 비즈니스 관점에서 정의하는 것이라는 것을 그 경험에서 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 마켓컬리 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.