이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
레거시 시스템을 재개발할 때 가장 중요하게 생각한 것은 기존 시스템의 동작을 먼저 이해하는 것이었습니다. 문서가 없거나 오래된 경우에는 코드와 로그를 직접 분석해야 했고, 기존 동작을 정확히 파악하지 않으면 재개발 후 누락된 기능이 운영에서 문제가 됐습니다.
한 번에 전체를 교체하는 대신 점진적으로 모듈을 전환하는 전략을 사용했습니다. 기존 시스템과 새 시스템을 병행 운영하면서 결과를 비교해 동일하게 동작하는지 검증한 뒤 전환하면 리스크를 줄일 수 있었습니다.
테스트 커버리지 확보도 중요했습니다. 레거시 코드를 건드리기 전에 현재 동작을 명세화한 테스트를 먼저 작성하면, 재개발 과정에서 의도치 않은 동작 변경을 즉각 감지할 수 있었습니다. 이 테스트가 재개발 완료 후에도 회귀 방지 자산으로 남았습니다.
레거시 시스템 재개발에서 가장 위험한 순간은 데이터 마이그레이션이라는 걸 직접 경험했습니다. 구 DB에서 신 DB로 한 번에 데이터를 옮기면 마이그레이션 중 발생한 오류로 데이터가 불일치하는 상태가 서비스에 영향을 줍니다. 이를 피하려고 이중 쓰기(Dual-Write) 방식으로 구·신 DB에 동시에 쓰면서 읽기 결과를 비교하는 단계를 먼저 거쳤습니다.
비교 로그를 쌓아 두 DB의 결과가 다른 케이스를 추출하고, 원인을 찾아 해결한 뒤에야 읽기를 새 DB로 전환했습니다. 마이그레이션 롤백 기준도 미리 정해뒀는데, 오류율이 임계값을 넘으면 구 DB로 돌아가도록 설정했습니다. 레거시 마이그레이션은 데이터 정합성을 수치로 검증하면서 단계별로 좁혀가는 것이 핵심이었습니다.
레거시 재개발에서 가장 예상치 못한 문제는 코드에 드러나지 않는 암묵적 규칙이었습니다. 오래된 코드에는 왜 이렇게 동작하는지 이유가 없고, 건드리면 예상치 못한 곳이 깨지는 경우가 있었습니다. 이런 암묵적 규칙을 먼저 발굴하기 위해 기존 코드를 실행하며 입력과 출력을 케이스별로 기록하는 특성 테스트를 먼저 작성했습니다.
Golden Master Test 방식으로 기존 동작을 기준점으로 저장해두면, 재개발 코드가 같은 결과를 내는지 자동으로 비교할 수 있었습니다. 테스트를 먼저 만들고 나서 코드를 바꾸니 어디를 바꾸면 어디가 깨지는지가 즉각 보였습니다. 레거시 재개발은 테스트가 없으면 뭘 변경해도 불안한 상태가 끝나지 않는다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 코코네 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.