이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
레거시 서비스를 분리할 때 가장 먼저 한 것은 어떤 부분이 어디에 의존하고 있는지를 파악하는 것이었습니다. 분리 순서가 틀리면 한쪽을 건드렸을 때 다른 쪽이 망가지기 때문입니다.
팀 프로젝트에서 단일 서비스 안에 여러 기능이 뒤엉킨 코드를 분리하는 작업을 맡았는데, 코드를 보니 로그인·결제·알림 기능이 같은 모듈에 섞여 있고 서로 직접 참조하고 있었습니다. 다이어그램으로 의존 관계를 먼저 그리고, 참조가 가장 적은 모듈부터 분리하는 순서로 접근하였습니다. 실패는 처음에 순서를 생각하지 않고 분리하다가 연쇄 오류가 발생한 것이었는데, 이후 순서를 의존 역방향으로 정하고 나서 안정적이었습니다.
레거시 분리는 작업량보다 어떤 순서로 떼어낼지를 먼저 설계하는 것이 더 중요합니다.
레거시 서비스를 분리할 때 한 번에 교체하지 않고, 인터페이스를 먼저 정의해서 그 계층 뒤에서 교체하는 방식을 썼습니다.
팀 프로젝트에서 오래된 데이터 처리 로직을 새 방식으로 바꾸는 작업을 맡았는데, 기존 코드와 새 코드를 동시에 운영할 수 있도록 공통 인터페이스를 먼저 만들고 내부 구현을 점진적으로 교체하는 방식으로 진행했습니다. 덕분에 다른 파트에 영향을 주지 않고 모듈 하나씩 교체할 수 있었어요. 실패는 인터페이스 설계를 너무 빨리 확정했다가 나중에 요구사항이 바뀌면서 수정 비용이 커진 것이었습니다.
레거시 교체에서 가장 중요한 건 외부에 보이는 계약은 유지하면서 내부를 바꾸는 것이라고 생각합니다.
레거시 서비스 분리에서 모든 것을 한 번에 바꾸는 게 아니라 기능 단위로 점진적으로 새 서비스로 이전하는 방식을 택했습니다.
수업 프로젝트에서 레거시 방식을 유지하면서 새 기능은 새 구조로 만들고, 기존 기능을 하나씩 옮겨가는 접근을 했어요. 옮긴 기능은 새 경로로, 아직 안 옮긴 기능은 기존 경로로 처리하는 방식이어서 전환 중에도 서비스가 정상 작동했습니다. 실패는 라우팅 기준이 불명확해서 같은 기능이 두 경로에서 각각 다르게 동작하는 케이스가 발생한 것이었는데, 라우팅 기준을 문서로 먼저 정리하고 나서 해소됐어요.
레거시 분리는 빠르게 끝내는 것보다, 운영 중에도 서비스가 안정적이도록 단계를 설계하는 것이 더 중요합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부동산플래닛 풀스택 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.