이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 2년 이상 된 레거시 배치 모듈을 인수받았는데, 문서가 거의 없었습니다. 처음엔 막막했지만 git log --follow 로 변경 이력을 커밋 단위로 거슬러 올라가며 언제, 왜 코드가 바뀌었는지 추적했습니다.
그 과정에서 특정 예외 처리 블록이 3년 전 장애 대응용으로 급하게 추가된 것임을 알게 됐고, 현재는 그 예외가 발생하지 않음에도 매 실행마다 불필요한 DB 조회를 유발하고 있었습니다. 처음엔 '이 코드가 왜 있지?'였는데, 히스토리가 '이때 이런 사건이 있었구나'로 바꿔줬습니다.
팀 선임께 당시 상황을 여쭤보니 세부 맥락을 채울 수 있었고, 불필요한 조회를 제거해 배치 실행 시간을 18분에서 11분으로 단축했습니다. 히스토리 분석이 단순 읽기가 아니라 팀의 기억을 복원하는 작업이라는 걸 그때 배웠습니다.
사이드 프로젝트에서 외부 API 연동 모듈을 인수했을 때, 테스트 코드가 전혀 없었습니다. 코드를 직접 읽어선 동작 의도를 파악하기 어려워서, 먼저 운영 로그에서 실제 입출력 샘플을 50건 추출해 엣지 케이스 목록을 만들었습니다.
그 샘플로 특정 응답 포맷이 바뀐 시점부터 파싱 오류가 무음으로 삼켜지고 있었다는 걸 발견했습니다. 실패가 예외로 터지지 않고 빈 값으로 저장되던 구조였습니다. 오류가 조용히 묻히는 코드가 히스토리 분석을 어렵게 만든다는 사실을 이때 처음 깨달았습니다.
파싱 로직을 수정하고 구조화된 로그와 간단한 단위 테스트를 붙인 뒤, 이후 변경이 생겨도 의도를 코드에서 바로 읽을 수 있게 됐습니다. 히스토리가 없는 코드엔 먼저 안전망부터 깐다는 원칙이 그때 생겼습니다.
졸업 작품 팀에서 1년 전 선배가 만든 인증 모듈을 이어받았습니다. 코드 자체는 돌아갔지만 특이한 분기가 많아 손대기 무서웠습니다. 혼자 읽는 것에 한계를 느껴 선배에게 직접 30분 인터뷰를 요청했고, 당시 왜 그런 구조를 선택했는지 들었습니다.
알고 보니 소셜 로그인 연동 응답이 버전마다 달라 분기가 늘어난 것이었고, 현재는 단일 버전만 지원해도 됐습니다. 모르면 묻는 게 코드를 다시 짜는 것보다 빠르다는 걸 그때 느꼈습니다.
이후 가장 위험도가 낮은 분기부터 테스트를 먼저 작성하고 제거하는 순서로 점진적으로 정리했습니다. 한꺼번에 뒤집지 않은 덕분에 중간에 실수가 생겨도 금방 되돌릴 수 있었습니다. 히스토리 파악 → 테스트 추가 → 점진적 제거, 이 순서를 지키는 것이 레거시를 다루는 제 기본 접근이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.