이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
가장 도전적이었던 유지보수 작업은 인턴 기간에 문서가 전혀 없는 레거시 스크립트를 인수받은 것이었습니다. 코드를 작성한 사람이 이미 퇴직한 상태였고, 무엇을 하는 코드인지 설명이 없어서 실행해 보기도 두려웠습니다. 로그 출력을 추가하면서 실행 흐름을 추적하는 방식으로 코드가 무엇을 하는지를 먼저 파악했습니다.
git blame으로 변경 이력을 보면서 마지막으로 수정된 이유를 추측하고, 당시 커밋 메시지에서 힌트를 얻었습니다. 리팩터링보다 이해를 먼저라는 원칙을 지켰는데, 동작을 이해하기 전에 구조를 바꾸면 의도치 않은 사이드 이펙트가 생기는 경우가 있었습니다. 이 경험에서 코드를 인수할 때 먼저 테스트 케이스를 작성해두면 이후 수정에서 회귀를 잡을 수 있다는 것을 배웠습니다. 레거시 유지보수는 동작을 이해한 뒤 고쳐야 한다는 결을 얻었습니다.
이직 후 담당하게 된 시스템이 주석 한 줄 없는 10년된 레거시 코드였습니다. 문서도 없었고, 기존 담당자도 없어서 코드 자체가 유일한 정보 소스인 상황이었습니다. 저는 git blame과 커밋 이력을 추적해 변경 이력과 의도를 복원하고, 코드를 읽으며 핵심 흐름을 직접 문서화했습니다. 이 과정에서 실제로는 사용되지 않는 데드 코드가 전체의 30%를 차지하고 있음을 발견하고, 단계적으로 제거했습니다. 이 경험에서 가장 도전적이었던 것은 기술적 어려움보다 무엇을 건드려도 되고 건드리면 안 되는지를 판단하는 것이었습니다. 지금도 레거시 유지보수를 시작할 때는 먼저 읽고 기록하는 단계를 가장 중요하게 생각합니다.
운영 중인 서비스에서 특정 배치 작업이 갑자기 수 배 느려지는 현상이 발생했습니다. 레거시 코드라 전체 구조를 파악하기 어려운 상태에서, 저는 변경 이력을 역추적해 3개월 전 배포 이후 처음 발생했음을 확인했습니다. 해당 배포의 변경 내역을 좁혀가며 N+1 쿼리 문제가 새로 도입됐음을 발견했습니다. 전체 리팩토링은 리스크가 크다 판단하고, 쿼리 최적화와 캐시 레이어 추가만으로 최소 변경 원칙을 지키며 해결했습니다. 배치 처리 시간이 기존 수준으로 복원됐고, 이 경험에서 레거시 유지보수는 최소 변경으로 목표 상태에 도달하는 판단력이 가장 중요한 기술임을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.