이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
On-Premise 시스템을 AWS로 직접 전환한 경험은 없습니다. 수업에서 클라우드 마이그레이션의 첫 단계는 현재 시스템의 의존성 맵과 리소스 사용 패턴을 파악하는 것이라고 배웠습니다.
케이스에서 인상적이었던 건 Lift-and-Shift로 빠르게 옮겼다가 온프레미스 전용 설정이 클라우드에서 호환되지 않아 재작업이 필요했던 사례였습니다. "이 컴포넌트가 클라우드에서 어떻게 동작하는가"를 검증하지 않고 옮기면 오히려 더 큰 비용이 발생한다는 교훈이었습니다.
직접 경험은 없지만, 마이그레이션에서 중요한 건 기술보다 검증 계획이라고 생각합니다. 파일럿 워크로드 하나를 먼저 전환해 리스크를 확인한 뒤 전체 전환 계획을 세우는 방식이 안전하다고 봅니다.
On-Premise에서 AWS로 전환할 때 왜 전환하는지를 명확히 하는 것이 전환 범위와 방식을 결정하는 자리입니다. 단순히 클라우드로 이전하는 것이 목적이면 Lift-and-Shift로 시작하지만, 확장성 문제나 유지보수 비용 절감이 목적이라면 아키텍처를 함께 바꾸는 방식을 선택하는 자리가 생깁니다. 온프레미스 환경의 어떤 부분이 불편했는지를 먼저 정리하면 전환 후 어떤 지표로 개선을 확인할 수 있는지가 명확해집니다.
전환 후 성공 기준을 미리 정의하지 않으면 전환이 완료됐어도 기대를 달성했는지 판단하기 어려운 자리가 생깁니다. 목적이 명확한 전환이 마이그레이션을 실질로 만드는 결이 됩니다. 기술 실행보다 왜 전환하는지가 더 중요한 자리입니다. 이 시각이 있어야 전환 과정에서 방향을 잃지 않는 결이 만들어집니다.
On-Premise에서 AWS로 전환하는 과정에서 이론으로는 알지만 실제로 막히는 자리가 있습니다. 온프레미스 서버에서 직접 관리하던 네트워크 설정이 VPC, 서브넷, 보안 그룹으로 표현될 때 어떻게 매핑해야 하는지가 처음에는 직관적이지 않은 자리입니다.
기존 내부 DNS가 클라우드 환경에서 어떻게 연계되는지도 예상과 다르게 작동하는 자리가 있습니다. 온프레미스의 특정 서비스가 직접 하드웨어 접근을 요구해서 클라우드로 그대로 올릴 수 없는 경우도 막히는 자리가 됩니다. 막힌 자리를 파악하는 것이 전환 계획을 현실적으로 만드는 결입니다. 이 경험이 마이그레이션 역량을 실질로 키우는 결이 됩니다. 막힌 자리를 솔직하게 말하는 것이 경험의 깊이를 보여주는 방법입니다. 이 깊이가 있어야 전환 프로젝트에서 현실적인 판단을 하는 결이 만들어집니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 인프라/클라우드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.