이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
하이브리드 클라우드 구성을 처음 경험한 것은 사이드 프로젝트에서 온프레미스 서버와 클라우드를 연결하는 구조를 실험했을 때였습니다. 가장 기본적인 방법으로 VPN 터널을 사용해 두 환경 간 사설 네트워크를 구성했고, 라우팅 테이블을 설정하는 과정에서 CIDR 블록 충돌이 생기는 문제를 겪었습니다.
서브넷 설계를 처음부터 충돌 없이 잡는 것이 중요하다는 것을 이 경험에서 배웠습니다. 레이턴시 차이도 중요한 고려 사항인데, 온프레미스와 클라우드 사이의 왕복 지연이 데이터 처리 흐름에 영향을 줄 수 있어, 빈번하게 오가는 데이터는 어느 쪽에 두는지 설계 단계에서 결정하는 것이 중요했습니다. 실제 IDC 수준의 하이브리드 구성은 아직 경험하지 못했지만, 네트워크 설계는 IP 플랜부터 잡아야 한다는 결을 얻었습니다.
캡스톤 프로젝트에서 온프레미스 서버와 클라우드를 연동할 때 IPSec VPN 단일 터널로 구성했는데, 피크 시간대에 응답 지연이 35ms 이상 들쭉날쭉해졌습니다. 처음에는 인스턴스 사양 문제로 잘못 판단해 스펙을 올렸지만 개선이 없었고, 로 경로를 따라가 보니 ISP 구간에서 패킷이 우회하는 게 원인이었습니다. 이후 두 개의 VPN 터널을 Active-Passive 이중화로 재구성해 기본 경로와 백업 경로를 분리했습니다. 헬스체크 주기를 10초로 설정하자 장애 전환 시간이 줄었고, 최종적으로 레이턴시 편차가 12ms 이내로 안정됐습니다. 비용 때문에 전용선을 포기한 결정이었지만, 이중화만으로도 충분한 안정성을 확보할 수 있다는 걸 이 경험으로 알게 됐습니다. 지금도 연동 구성을 설계할 때 단일 경로 의존 여부를 먼저 확인합니다.
인턴 기간에 팀 내부 네트워크와 클라우드 VPC를 연동하는 작업을 처음 맡았을 때, CIDR 대역 충돌이 발생했습니다. 사내망이 을 통째로 쓰고 있었고, 클라우드 VPC도 같은 대역으로 설정돼 있어 라우팅이 뒤엉켰습니다. VPC 설정만 바꾸면 될 거라 생각했는데, 이미 다른 서비스 세 곳이 그 대역에 묶여 있어 재설계 범위가 예상보다 훨씬 넓었습니다. 결국 클라우드 VPC를 로 새로 만들고 서브넷 피어링만으로 필요한 경로를 좁혀 연결했습니다. 네트워크 담당자가 아니었는데 이 작업을 도맡아, 서브넷 계산과 라우팅 테이블을 종이에 직접 그려가며 이해했습니다. 이후 VPC를 새로 만들 때 대역 설계를 처음부터 여유 있게 잡는 습관이 생겼고, 충돌이 생기면 수정 범위가 얼마나 넓어지는지 이 경험으로 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.