유지보수 힘든 JSP를 Claude Code로 구조화해본 기록

드디어 틈새 시간이 조금 생겨서,

Claude Code를 활용해 유지보수가 너무 힘들었던 기존 JSP를 정리하는 테스트를 해봤다.

 

이번에 손댄 화면은 특정 타입에 따라 표시되는 내용이 달라지는 구조였는데,

기존에는 타입마다 소스가 덕지덕지 붙어 있는 상태였다.

 

여러 사람의 손을 거쳐 수정되다 보니, 타입 하나만 추가하려고 해도 어디를 건드려야 할지부터 막막한 수준이었다.

말 그대로 소스만 봐도 머리가 아파오는 구조였다.

---

왜 이 화면이 특히 힘들었나

이 페이지가 더 골치 아팠던 이유는 단순히 조건문이 많아서가 아니었다.

 

$().load() 방식으로 다른 페이지를 불러오고 있어서

실제로는 JSP가 2개가 얽혀 있었고, 변수 선언도 여기저기 흩어져 있었다.

 

중복 소스는 기본이고, 왜 존재하는지조차 알기 어려운 코드도 적지 않았다.

유지보수하는 입장에서는 손대는 것 자체가 부담스러운 상태였다.

 

타입 하나를 추가하거나 기존 타입의 동작을 수정하려고 하면,

한 군데만 보면 되는 게 아니라 여기저기 흩어진 분기와 HTML 조각들을 같이 봐야 했다.

이쯤 되면 기능 추가는 지옥문을 여는 느낌과 같다.

---

이번에 잡은 목표

그래서 이번에는 목표를 단순하게 잡았다.

해당 페이지에서 표시되는 HTML 구조를 전체적으로 정리하고,

타입별로 필요한 요소는 show/hide 방식으로 제어할 수 있게 구조를 다시 잡아보자는 것이었다.

 

여기에 더해, 타입별 설정도 한눈에 볼 수 있도록 map 형태로 정리해서

이후 유지보수가 조금이라도 쉬워지게 만들고 싶었다.

 

즉, 단순히 코드를 예쁘게 정리하는 게 아니라,

이후에 타입이 추가되더라도 수정 포인트를 줄일 수 있는 방향으로 구조화하는 것이 목표였다.

---

Claude Code에 맡겨보니

먼저 Claude Code에 HTML 구조부터 정리해달라고 요청했다.

확실히 이런 작업에서는 열심히 일한다. 다만 그만큼 사용량도 정말 열심히 녹아내린다.

 

Pro 요금제로 테스트 중이었는데, 정리 작업만 하는 데도 사용량이 꽤 빠르게 줄어드는 게 보였다.

이번에 다시 느낀 건, AI가 이런 레거시 코드를 한 번에 완벽하게 정리해줄 거라고 기대하면 생각보다 실망할 수도 있다는 점이다.

 

코드가 처음부터 어느 정도 정리되어 있는 상태라면 결과가 훨씬 잘 나올 수도 있겠지만,

원래 구조가 복잡하고 중복과 예외가 많은 상태라면 생각처럼 한 번에 떨어지지 않는다.

 

원하는 방향과 다르게 정리될 수도 있고, 기대 이하의 결과가 나올 수도 있다.

그래서 어떤 프롬프트든 한 번에 끝내겠다는 생각은 버리는 게 맞다는 걸 다시 느꼈다.

---

한 번에 끝내려 하지 말아야 하는 이유

대화를 여러 번 주고받으면서 방향을 조금씩 맞춰가니 확실히 결과가 달라졌다.

대략 3~4번 정도 정리 방향을 조정해가며 요청하니,

처음에는 보기만 해도 답답했던 코드가 점점 읽을 수 있는 형태로 바뀌기 시작했다.

 

그다음에는 타입별 처리를 map 형식으로 정리해달라고 요청했다.

중복된 화면 요소와 분기 로직을 분리하고,

타입별 설정을 한곳에서 관리할 수 있게 구조화하는 방향으로 계속 다듬어갔다.

 

결국 이런 작업은 “한 번에 정답을 받는 방식”보다, “초안 생성 → 방향 수정 → 구조 정리 → 예외 처리 보완”처럼 단계적으로 밀고 가는 쪽이 훨씬 잘 맞았다

---

토큰은 많이 들었지만

이 단계까지 오니 사용량이 더 많이 들었다.

어짜피 사용량은 4시간마다 초기화 되지만 체감상 꽤 크게 빠져나갔다.

 

그래도 모두가 고개를 젓던 소스가 실제로 관리 가능한 수준으로 정리되는 걸 보니,

왜 이런 도구를 써야 하는지 조금은 알 것 같았다.

 

특히 단순히 눈에 보이는 코드만 정리하는 게 아니라,

나중에 타입이 추가됐을 때 어떤 식으로 요청하면 되는지까지 주석 형태로 남겨준 점이 꽤 실용적이었다.

 

예를 들면 아래와 같은 식이었다.

[기본 형식]
[타입코드] 타입 추가해줘.
뷰어는 [요소1], [요소2], [요소3] 표시하고 [요소4] 숨겨줘.
작성자는 [요소1], [요소2] 숨기고 제목은 [셀렉터]를 [텍스트]로 바꿔줘.
A_EXCEPTION_TYPES에도 추가해줘.

 

아직 이 형식을 실제 유지보수에 본격적으로 써보진 않았지만,

적어도 이후 타입이 늘어났을 때 어떤 기준으로 수정해야 하는지 감을 잡게 해준다는 점에서 의미가 있었다.

 

예전처럼 소스를 다시 뒤져가며 “이번에는 어디를 또 건드려야 하지?”를 반복하는 상황은 줄어들 것 같았다.

---

기존 로직도 같이 확인해봤다

정리된 결과물을 기존 소스와 함께 비교하면서, 기존 로직 흐름에 문제는 없는지도 확인해봤다.

그리고 특정 타입 몇 개만 실제로 테스트해봤는데 다행히 큰 문제 없이 동작했다.

 

물론 이걸로 모든 경우가 끝났다고 볼 수는 없다.

레거시 화면은 항상 예외가 숨어 있기 때문이다. 그래도 적어도 “이 방향으로 정리해도 되겠다”는 확신은 얻을 수 있었다.

---

해보면서 느낀 점

이번에 해보면서 가장 크게 느낀 건 두 가지였다.

하나는, 레거시 JSP처럼 복잡하게 얽힌 구조도 AI를 잘 활용하면 생각보다 많이 정리할 수 있다는 점이다.

 

다른 하나는, 이런 작업은 절대 한 번에 끝내려고 하면 안 된다는 점이다.

처음부터 완벽한 결과를 기대하기보다, HTML 정리, 중복 제거, 분기 분리, 타입별 설정 정리처럼 단계를 나눠서 요청하는 편이 훨씬 현실적이었다.

 

토큰은 금방 다 써버렸지만 직접 손으로 처음부터 구조를 다시 잡는 시간을 생각하면, 충분히 써볼 만한 이유가 있다고 느꼈다.

특히 새 기능 개발보다 기존 소스를 정리하고 유지보수성을 높이는 일이 더 급한 상황이라면, 이런 방식의 활용은 꽤 괜찮은 선택지일 수 있겠다는 생각이 들었다.

---

마무리

이번 테스트를 통해 확실히 느낀 건, Claude Code가 레거시 JSP를 마법처럼 한 번에 정리해주는 도구는 아니라는 점이다.

대신 사람이 방향을 잘 잡아주고, 여러 번 대화를 주고받으며 구조를 다듬어가면 꽤 실용적인 결과를 만들어낼 수는 있다.

 

특히 타입별 분기가 많고, HTML과 로직이 여기저기 얽혀 있어서 손대기 무서운 화면일수록 더 도움이 될 수 있겠다는 생각이 들었다.

 

이런 도구들을 직접 써보면서 아이디어와 실행력만 있다면 적은 인원으로도 꽤 많은 일을 해낼 수 있겠다는 생각이 들었다.

요즘 해외 기업들의 대규모 해고 소식을 접할 때마다 그런 변화가 더 현실적으로 다가오기도 한다.