레거시 코드 한 줄 고치기 전 — 5분 점검
고치기 전 5분이 사고 4시간을 막는다. 실전 점검 순서.
막상 고치면 벌어지는 일
“한 줄만 바꾸면 돼”라고 시작한 수정이 3시간 장애로 끝난 적이 두 번 있다. 한 번은 util 함수 하나가 14개 모듈에서 호출되고 있었고, 다른 한 번은 return 타입이 조용히 null을 허용하고 있었다. 테스트는 통과했다. 배포 후에 터졌다.
레거시 코드는 주석도 없고, 작성자도 없고, 의도도 없다. 그래서 고치기 전 5분이 실제로는 보험이다.
5분 점검 순서
1. 호출 지점 먼저 센다
grep -rn '함수명'또는 IDE reference 검색- 10개 이상이면 일단 멈춘다. 영향 범위가 예상보다 넓다는 신호
2. 입출력 타입 확인
- 함수 시그니처가 실제 사용처와 일치하는지
None,undefined, 빈 문자열 같은 엣지 케이스가 암묵적으로 흘러다니는지- 2026년 기준 타입 힌트 없는 Python 코드,
any도배된 TypeScript는 특히 주의
3. 테스트가 실제로 이 경로를 덮고 있나
- 커버리지 숫자가 아니라, 이 함수 이 분기를 직접 찌르는 케이스가 있는지
- 없으면 고치기 전에 테스트 한 줄 추가하고 시작
4. 롤백 방법 정해두기
- feature flag 가 없으면 최소한 직전 커밋 해시를 메모장에
- 배포 후 10분 모니터링 누가 볼지 미리 정해놓기
5. 변경 이유 한 줄 커밋 메시지에
fix: 오타 수정말고,fix: null 반환 시 downstream에서 NPE 발생 — 기본값 빈 배열로 교체- 6개월 뒤 내가 고맙다고 할 커밋 메시지
다음 한 가지
다음 레거시 수정 때, 호출 지점 숫자를 커밋 메시지 첫 줄에 적어둔다. (callers: 7)처럼. 영향 범위를 스스로 인지하고 시작했다는 증거.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.