레거시 소스는 분석부터 — 손대기 전에 붙잡은 것들

레거시를 “못 한다”기보다, 읽는 순서를 모르면 손이 안 갔다. 나는 수정 전에 분석을 먼저 고정하는 쪽을 택했다.

처음 PG·매출 전산을 받았을 때, 솔직히 빨리 성과를 내고 싶었다. 새 코드로 갈아엎고 싶은 욕심과, “운영 중인 걸 깨면 안 된다”는 두려움이 동시에 있었다.

그 사이에서 내가 찾은 타협점이 분석을 먼저 기록으로 고정하는 것이었다.

왜 분석을 앞에 두었는가 (이유)

화면 하나가 여러 스크립트·공통 include에 묶여 있었다. 한 줄을 고치면 어디가 같이 움직이는지 예측이 안 됐다.
변수명만 봐서는 업무 의미가 안 보였다. flag1, gubun, cd2 같은 이름이 실제로 무엇을 가르는지는 코드가 아니라 데이터와 운영자가 알고 있었다.
운영 중이라 “일단 고치기”가 가장 위험해 보였다. 매출·정산 숫자가 어긋나면 기능 버그가 아니라 신뢰 사고가 됐다.
무엇보다, 나 혼자만 이해하는 수정은 다음 사람(또는 6개월 뒤의 나)에게 또 같은 분석 비용을 떠넘기는 일이었다.

그래서 흐름 → 데이터 → 부작용 순으로 읽기로 했다.

실무에서 쓴 읽기 순서

요청 경로: 어떤 URL·액션에서 시작하는지
화면 조립: JSP/HTML, include, 공통 레이아웃
이벤트·AJAX: jQuery 바인딩, 콜백 체인
서버 응답: JSON/XML 형태, 에러 처리
DB·배치 연계: 같은 키를 쓰는지, 중복 적재 여부

이 순서를 지키면 “어디를 건드리면 깨지는지”가 먼저 보였다.

수정 전에 적어두던 것

이 화면의 단일 책임 (한 문장)
건드리면 안 되는 레거시 규칙 (날짜 포맷, 금액 단위, 권한 체크)
최소 검증 시나리오 (정상 1건, 예외 1건, 재실행 1건)

문서가 길 필요는 없었다. 다음 사람이 같은 실수를 안 하게 남기는 게 목적이었다.

비슷한 경험 — 손대자마자 깨졌던 화면

분석을 건너뛰고 “이 정도면 안다” 하고 바로 고쳤다가 데인 적이 있다. 매입 마감 화면에서 날짜 비교 로직 하나를 “더 깔끔하게” 바꿨는데, 그 화면은 c:forEach로 서버가 미리 박아준 값과 jQuery가 다시 계산한 값을 둘 다 쓰고 있었다. 코드만 보면 중복이라 한쪽을 지웠더니, 특정 카드사 건만 마감 금액이 어긋났다.

당시 결론: 레거시의 “중복처럼 보이는 코드”는 대개 이유가 있다. 그 이유를 못 찾았다는 건, 아직 그 화면을 고칠 자격이 없다는 신호였다.
그 뒤로는 “왜 이 코드가 이렇게 생겼는지”를 한 줄이라도 못 적으면 손대지 않기로 했다.

ES6로 옮기기 전 단계

분석이 끝나기 전에 문법만 바꾸면, 버그 위치를 찾기 더 어려웠다. 그래서 보통은:

동작을 그대로 두고 읽기 쉽게 정리
작은 단위로 ES6+ 패턴 적용 (ES5→ES6 단계적 이전 참고)
그다음 모듈·빌드·프레임워크 논의

순서를 바꾸지 않는 게 중요했다.

지금도 반복하는 습관

diff를 크게 내지 않는다.
“왜 이 코드가 이렇게 생겼는지”를 PR/메모에 한 줄 남긴다.
레거시는 한 번에 예쁘게보다 한 번에 안전하게를 우선한다.

아직 부족한 것 (개선점)

분석 메모가 사람 머리와 PR 본문에만 흩어져 있다. 같은 화면을 또 만지면, 결국 처음부터 다시 읽는 경우가 있었다.
“건드리면 안 되는 규칙(날짜 포맷·금액 단위·권한)”을 자동으로 검증하지 못한다. 지금은 사람이 기억하고, 사람이 빠뜨린다.
검증 시나리오(정상·예외·재실행)를 적어두긴 하지만, 테스트 코드로 박제하지 못해 회귀를 보장하진 못한다.

앞으로 나가야 할 방향

화면 단위 분석 메모를 개발자센터/Notion의 고정된 위치로 옮겨, “이 화면 = 이 문서”가 1:1로 연결되게 만든다.
자주 깨지는 레거시 규칙은 최소한 스냅샷/계약 테스트라도 걸어, 사람이 기억에 의존하지 않게 한다.
분석으로 “설명 가능한 상태”가 된 화면부터 우선순위를 매겨, ES5→ES6 단계적 이전과 React 이관 대상으로 끌어올린다.
궁극적으로는 “레거시 분석 → 안전한 정리 → 점진 이관”이 한 사람의 감이 아니라 팀의 절차가 되는 것이 목표다.

레거시는 적이 아니었다. 설명 가능한 상태로 만드는 일에 가까웠다. 그리고 그 “설명”을 내 머리가 아니라 팀이 공유하는 기준으로 옮기는 게, 지금 내가 풀어야 할 다음 숙제다.