자바 백엔드 실무

들어가며

“Legacy Code(레거시 코드)란, 남이 짠 코드다.”

개발자 농담 중에 이런 말이 있습니다. 하지만 시스템 운영(SM) 업무를 맡게 되면 이 농담은 뼈아픈 현실이 됩니다. 입사 첫날 마주하게 될 코드는 최신 Spring Boot와 JPA로 짜인 우아한 코드가 아닐 확률이 높습니다.

변수명은 str1, str2로 되어 있고, SQL은 수백 줄에 달하며, 주석 하나 없이 10년 전 선배가 남기고 간 // 건드리지 마시오라는 경고문만 있는 상황.

지원 공고에 있는 “Java 시스템 구축 및 운영 경험”은 단순히 코드를 짤 줄 아는 것을 넘어, 이런 레거시 시스템을 안정적으로 끌고 갈 수 있는 인내심과 해결 능력을 묻는 것입니다. 오늘은 낡은 코드와 평화롭게 공존하며 점진적으로 개선해 나가는 저만의 전략을 이야기합니다.

전략 1. “돌아가는 코드는 죄가 없다” (존중하기)

처음 레거시 코드를 보면 “이걸 왜 이렇게 짰지? 다 엎고 새로 짜고 싶다”는 욕구가 솟구칩니다. 하지만 그 코드는 지난 10년간 수많은 버그 픽스와 예외 케이스를 견뎌내며 회사의 돈을 벌어다 준 검증된 코드입니다.

무턱대고 리팩토링을 시도하다가는 숨겨진 비즈니스 로직(히든 룰)을 건드려 시스템 장애를 유발할 수 있습니다.

• Tip: 코드를 비난하기 전에 Git History(또는 SVN 로그)를 먼저 봅니다. “2018-05-20: 재무팀 요청으로 감가상각 로직 예외 처리 추가” 같은 커밋 메시지를 보면, 그 이상한 if 문이 왜 들어갔는지 이해할 수 있습니다.

전략 2. 보이스카우트 규칙 (점진적 개선)

“캠핑장은 처음 왔을 때보다 더 깨끗하게 해 놓고 떠나라.” - 보이스카우트 규칙

대대적인 리팩토링(Big Bang)은 위험합니다. 대신 기능을 추가하거나 버그를 수정할 때, 내가 건드리는 그 파일, 그 메소드만큼은 조금 더 깨끗하게 만들어 놓고 나옵니다.

1. 의미 없는 변수명 변경: String a -> String deptCode (IDE의 Refactor 기능 활용 시 안전함)
2. 중복 코드 추출: 똑같은 쿼리 생성 로직이 세 군데 있다면 private 메서드로 추출.
3. 죽은 코드 삭제: 더 이상 호출되지 않는 주석 처리된 코드는 과감히 삭제 (형상관리가 기억해주니까요).

이런 작은 습관들이 1년, 2년 쌓이면 시스템은 놀랍도록 건강해집니다.

전략 3. 테스트 코드 없는 리팩토링은 도박이다

레거시 시스템의 가장 큰 문제는 테스트 코드(Test Case)가 없다는 점입니다. 테스트 없이 코드를 고치는 것은 눈을 가리고 수술을 하는 것과 같습니다.

하지만 전체 시스템에 대해 테스트를 다 짤 순 없습니다.

• Golden Master 기법:
  1. 수정하려는 핵심 로직(예: 이자 계산)의 현재 입/출력 데이터를 캡처합니다.
  2. 이 데이터를 기반으로 ‘현재 로직이 정상임’을 보장하는 테스트 케이스를 짭니다.
  3. 리팩토링을 수행합니다.
  4. 테스트를 돌려 결과가 동일한지(Green) 확인합니다.

이 안전망이 있어야 자신 있게 코드를 고칠 수 있습니다.

전략 4. 문서화: 미래의 나를 위한 배려

내가 고생해서 파악한 로직을 내 머릿속에만 남겨두면, 1년 뒤의 나(혹은 내 후임자)는 똑같은 고생을 합니다.

거창한 산출물이 아니어도 좋습니다. 코드 상단에 JavaDoc 형태로 비즈니스 로직을 요약해 두거나, 팀 위키(Confluence 등)에 “자산 마감 프로세스 흐름도” 하나만 남겨둬도 그것은 훌륭한 자산이 됩니다.

마무리하며

유지보수 업무를 ‘발전 없는 일’이라고 폄하하는 시선도 있습니다. 하지만 복잡하게 얽힌 스파게티 코드를 분석해 문제를 해결하고, 운영 중단을 최소화하며 더 나은 구조로 개선하는 과정은 고도의 엔지니어링 역량을 요구합니다.

특히 방산/공공 분야처럼 안정성이 최우선인 곳에서는 신기술 도입보다 기존 시스템의 안정적 운영과 리스크 관리 능력이 훨씬 더 높은 평가를 받습니다.

이제 시스템 내부 이야기는 충분히 한 것 같습니다. 마지막으로 보안 이야기를 하지 않을 수 없습니다. “방산 보안 정책상 신원조회 실시”라는 문구가 말해주듯, 이 분야에서 보안은 선택이 아닌 생존입니다.

다음 글에서는 [방산/공공 분야 프로젝트에서의 시큐어 코딩과 데이터 보안]을 주제로, 개발자가 지켜야 할 최소한의, 그리고 절대적인 보안 원칙들을 다뤄보겠습니다.