이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
레거시 시스템을 클라우드로 마이그레이션하는 프로젝트를 직접 수행한 경험은 없습니다. 수업에서 마이그레이션 실패의 가장 흔한 원인은 기술보다 "레거시 시스템의 의존성을 충분히 파악하지 못한 것"이라고 배웠습니다.
Lift-and-Shift, Re-platforming, Refactoring 세 전략 중 어떤 방식을 선택하느냐에 따라 마이그레이션 리스크와 클라우드 최적화 수준이 달라진다는 것도 배웠습니다. 빠르게 옮기고 싶을수록 Lift-and-Shift를 선택하지만, 클라우드 환경에 최적화되지 않아 비용이 오히려 늘어나는 사례가 많다는 점이 인상적이었습니다.
직접 경험은 없지만, 마이그레이션에서 중요한 건 "먼저 파악하고, 그다음 옮기는" 순서라고 생각합니다. 현재 의존성 맵을 만드는 것이 모든 마이그레이션 계획의 출발점이라고 봅니다.
레거시 시스템을 클라우드로 마이그레이션할 때 예상하지 못한 자리에서 막히는 경우가 많습니다. 공부한 내용에서 자주 언급되는 것은 레거시 시스템이 특정 하드웨어나 OS 버전에 종속되어 있어서 그대로 올리는 것이 불가능한 경우입니다. 이 자리에서 재설계가 필요한지 호환 레이어를 쓸지를 결정해야 하는데, 그 결정이 전체 일정과 비용에 큰 영향을 줍니다.
종속성 파악을 먼저 하는 것이 막히는 자리를 미리 찾는 방법입니다. 이 과정을 건너뛰면 마이그레이션 도중에 예상치 못한 문제가 나타나고 전체 계획이 흔들립니다. 막히는 자리를 예상하고 준비하는 것이 마이그레이션을 예측 가능하게 만드는 결이 됩니다. 레거시의 복잡성을 무시하면 나중에 더 큰 비용을 치르는 자리가 생깁니다. 종속성 분석이 선행되어야 현실적인 마이그레이션 계획이 나옵니다.
레거시 시스템의 클라우드 마이그레이션에서 이전 작업이 완료된 것과 실제 운영이 안정된 것은 다른 자리입니다. 시스템을 클라우드로 옮긴 직후에는 새 환경에 맞는 모니터링, 로그 수집, 알람 체계가 아직 자리 잡지 않은 상태가 많습니다. 운영 초기의 불안정한 시간을 예상하고 그 기간에 맞는 대응 체계를 미리 준비하는 것이 중요합니다.
롤백 계획을 명확하게 준비해 두면 심각한 문제가 생겼을 때 빠르게 이전 상태로 돌아갈 수 있습니다. 운영 안정 기간 동안 발생하는 이슈를 수집하고 분석하는 것이 다음 유사 마이그레이션에 쓰이는 학습이 됩니다. 이전 완료가 아니라 운영 안정을 목표로 잡는 시각이 마이그레이션의 실질적인 완성 결을 만듭니다. 운영까지 책임지는 범위를 처음부터 설계에 포함하는 것이 프로젝트 성공의 기준입니다. 이 시각이 있는 사람이 이전 후 발생하는 문제에도 흔들리지 않는 결을 만듭니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 시스템 운영 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.