이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
직접적인 레거시 이관 경험은 없지만, 인턴 기간에 기존 `jQuery` 기반 스크립트를 일부 `Vue.js`로 전환하는 작업에 참여한 경험이 있습니다.
전체를 한 번에 바꾸는 것이 아니라, 새로운 기능을 추가할 때만 새 스택으로 작성하고 기존 코드는 건드리지 않는 방식으로 진행했습니다. 두 스택이 같은 페이지에 공존하는 기간이 있었는데, 데이터 흐름이 섞이지 않도록 인터페이스를 명확하게 분리하는 것이 핵심이었습니다.
이 경험에서 점진적 전환의 핵심은 경계를 명확하게 유지하는 것이라는 것을 배웠습니다. 경계가 흐려지면 어느 쪽에서 문제가 생겼는지 추적하기 어려워집니다. 또 테스트 커버리지가 있어야 기존 동작이 유지되는지 확인하며 이관할 수 있다는 것도 이 작업에서 실감했습니다. 작은 범위였지만 이관 작업의 실제 어려움을 피부로 느낀 경험이었습니다.
캡스톤 프로젝트에서 처음에는 모든 로직이 하나의 파일에 쌓이는 구조로 시작했습니다. 기능이 늘어나면서 수정 하나가 다른 부분에 영향을 미치는 상황이 반복됐고, 팀에서 일부 기능을 모듈로 분리하는 시도를 했습니다. 전체를 한 번에 분리하는 대신 가장 독립적이고 자주 변경되는 부분을 먼저 잘라내는 순서를 정했습니다. 의존성이 많은 부분을 먼저 건드리면 연쇄 수정이 발생한다는 것을 초반 시도에서 직접 겪었기 때문입니다. 분리된 모듈과 기존 코드 사이에 명확한 입출력 인터페이스를 먼저 정의하고, 내부 구현을 그 다음에 바꾸는 순서가 훨씬 안전했습니다. 이관보다 경계를 그리는 것이 선행돼야 한다는 생각은 그 때부터 갖게 됐습니다.
레거시 코드를 새 스택으로 옮길 때 가장 위험한 것은 기존 동작이 조용히 깨지는 것입니다. 수업에서 진행한 리팩토링 실습에서 테스트가 없는 코드를 변경하면 무엇이 깨졌는지 알 수 없어 되돌리는 데 더 많은 시간이 들었습니다. 이후 팀 프로젝트에서는 이관 대상 코드의 현재 동작을 테스트로 먼저 고정하는 것을 출발점으로 삼았습니다. 테스트가 없으면 만드는 것이 먼저였고, 그 기반 위에서 새 스택으로 구현한 뒤 기존 테스트가 통과하는지를 확인하는 방식으로 진행했습니다. 이관 속도보다 각 단계에서 동작이 보장되는지가 더 중요한 지표였고, 이 순서를 지켰을 때 최종 통합에서 예상치 못한 오류가 훨씬 줄었습니다. 완성도보다 안전성을 먼저 확보하는 순서가 결국 더 빠르다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.