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