모든 것을 파괴하지 않고 LLM을 사용하여 레거시 코드를 리팩터링하는 방법

우리 모두에게는 그런 코드베이스가 하나씩 있습니다. 함수 하나가 500줄에 달하는 코드 말이죠. 그 이상한 루프가 왜 존재하는지는 아무도 기억하지 못하지만, 그냥 삭제하면 예측할 수 없는 무언가가 고장 나버리는 그런 코드 말입니다. 모든 것을 한꺼번에 리팩터링(Refactor)하고 싶게 만드는 그런 코드 말이죠.

여기 문제가 있습니다. 아마 그러면 안 될 것입니다. 하지만 LLM은 운영 환경 장애(Production-incident) 지옥에 빠지지 않고도 코드의 _일부_를 안전하게 리팩터링할 수 있도록 도와줄 수 있습니다.

"그냥 새로 쓰면 되잖아"의 문제점

레거시 코드(Legacy code)가 레거시 코드인 데에는 이유가 있습니다. 바로 작동하기 때문입니다. 코드가 지저분할 수도 있고, 새로운 개발자들을 혼란스럽게 할 수도 있지만, 어쨌든 작동은 합니다. 마지막으로 모든 것을 한꺼번에 리팩터링하려고 시도했던 사람은 47개의 파일이 포함된 PR(Pull Request)을 만들었고, 리뷰하는 데 3주가 걸렸으며, 아무도 테스트하지 않았던 두 가지 기능을 망가뜨렸습니다.

LLM은 코드 패턴을 이해하고 개선 사항을 제안하는 데 뛰어나지만, 여러분의 비즈니스 로직(Business logic)이나 예외 케이스(Edge cases)를 이해하는 데는 뛰어나지 않습니다. 따라서 전략이 필요합니다.

안전한 리팩터링 전략

1. 테스트부터 시작하기 (네, 정말입니다)

무엇이든 건드리기 전에, 리팩터링하려는 코드에 대한 테스트를 작성하세요. 여기서 LLM이 실제로 시간을 절약해 줍니다:

프롬프트(Prompt): "여기 배송비를 계산하는 함수가 있습니다. 무게가 0인 경우, 해외 주소, 규격 외 품목과 같은 예외 케이스(Edge cases)를 다루는 단위 테스트(Unit tests)를 작성해 주세요."

함수를 입력으로 넣으세요. LLM이 테스트 케이스를 생성하게 하세요. 여러분은 이를 검토하고, 실제 비즈니스 규칙에 맞게 조정하여 커밋(Commit)합니다. 이제 안전망을 확보했습니다.

LLM은 여러분의 예외 케이스를 알지 못하겠지만, 명백한 것들은 잡아낼 것입니다. 여러분은 도메인 지식(Domain knowledge)을 바탕으로 기묘한 예외 상황들을 잡아낼 것입니다.

2. 아주 작은 조각으로 나누기

500줄짜리 함수를 통째로 리팩터링하는 대신, LLM에게 다음과 같은 작업을 요청하세요:

• 헬퍼 함수(Helper functions) 추출
• 단순화할 수 있는 루프(Loops) 식별
• 통합할 수 있는 반복되는 로직 찾기

이 중 딱 하나만 하세요. 테스트하세요. 배포하세요. 그런 다음 다음 조각으로 넘어가세요.

실제 예시: 따라가기 어려운 데이터 처리 함수가 있다고 가정해 봅시다.

프롬프트(Prompt): "이 함수는 사용자 데이터를 처리하고 여러 변환을 적용합니다. 별개의 논리적 단계들을 식별하고, 이를 각각의 별도 함수로 추출할 것을 제안해 줄 수 있나요? 전체를 다시 작성하지 말고, 추출된 함수들이 어떤 모습일지만 보여주세요."

이제 로드맵이 생겼습니다. 1단계를 구현하고, 병합(merge)하세요. 그러면 코드가 조금 더 나아집니다. 이 과정을 반복(Rinse and repeat)하세요.

3. 재작성이 아닌 현대화를 위해 LLM을 사용하세요

LLM에게 구체적인 개선 사항을 요청하세요:

좋은 프롬프트:

• "이 코드는 모든 곳에서 var를 사용하고 있습니다. 이것들을 어떻게 안전하게 const로 변환할 수 있는지 보여주세요."
• "이 콜백 지옥(callback pyramid)을 async/await로 어떻게 교체할 수 있을까요?"
• "이 에러 체크(error checking)를 처리하는 더 깔끔한 방법을 보여줄 수 있나요?"

나쁜 프롬프트:

• "이 파일 전체를 현대적인 표준에 맞춰 다시 작성해줘"
• "이 코드를 더 좋게 만들어줘"
• "이것을 리팩터링(Refactor)해줘"

좋은 프롬프트는 구체적입니다. 그래야 LLM이 과하게 생각(overthink)하지 않습니다. 여러분은 검토하고 테스트할 수 있는 집중된 변경 사항을 얻게 됩니다.

4. 모든 것을 두 번 검증하세요

1. 읽어보세요. 논리가 타당한가요? 동작 방식이 변했나요?
2. 테스트하세요. 테스트 스위트(test suite)를 실행하세요. 수동 테스트를 수행하세요. 스테이징(staging) 환경에 배포하세요.

LLM은 자신이 틀린 것에 대해서도 확신에 차 있습니다. 함수가 맞아 보일 수는 있지만, 엣지 케이스(edge case)에서 동작을 조용히 변경할 수도 있습니다. 이것이 1단계에서 테스트가 중요한 이유입니다.

실제 예시: 쿼리 빌더(Query Builder)

우리에겐 데이터베이스 쿼리를 생성하는 600줄짜리 함수가 있었습니다. 수많은 조건문과 반복되는 패턴이 섞인 엉망인 상태였지만, 작동은 했습니다.

이를 통째로 다시 쓰는 대신 다음과 같이 했습니다:

1. 20가지의 서로 다른 쿼리 조합에 대한 테스트를 작성했습니다.
2. LLM에게 "DRY(Don't Repeat Yourself) 원칙을 적용하여 중복을 제거할 수 있는 SQL 문자열 생성 부분을 찾아달라"고 요청했습니다.
3. LLM은 4개의 헬퍼 함수(helper functions)를 추출할 것을 제안했습니다.
4. 우리는 한 번에 하나씩 구현하고 테스트했습니다.
5. 각 변경 사항은 중복을 줄였고 코드를 조금 더 명확하게 만들었습니다.
6. 3주 후, 해당 함수는 250줄로 줄어들었고 실제로 읽을 수 있는 코드가 되었습니다.

더 중요한 점은, 운영 환경(production)에서 아무것도 망가뜨리지 않았다는 것입니다. 장애 발생 건수 0건이었습니다.

실제로 도움이 되는 도구들

• Claude 또는 GPT: 패턴을 이해하고 리팩터링 (refactorings)을 제안하는 용도 (네, 저는 Claude를 선호하지만 둘 다 유용합니다)
• GitHub Copilot: 추출된 함수가 무엇을 해야 하는지 파악한 후, 이를 완성하는 용도
• Perplexity: 원래 개발자가 사용한 라이브러리나 프레임워크를 이해해야 할 때
• 자신만의 테스트 스위트 (test suite): (LLM은 아니지만, 매우 중요합니다)

이 도구들에 코드를 던져보고, 제안을 받은 뒤, 체계적으로 구현하세요.

LLM이 실제로 못하는 것들

• 문맥 (context) 없이 비즈니스 규칙 (business rules)을 이해하는 것
• 어떤 엣지 케이스 (edge cases)가 중요한지 아는 것
• 특정 목적을 위해 의도된 복잡성 (intentional complexity)을 인식하는 것
• 변경 사항의 보안 영향 (security implications)을 포착하는 것

따라서 인간인 당신이 루프 안에 머물러야 (stay in the loop) 합니다. LLM은 제안 엔진 (suggestion engine)이지, 운전자가 아닙니다.

한 가지 더

"모든 것을 리팩터링하자"라는 회의는 건너뛰세요. 대신, 함수 하나를 골라 이 프로세스를 사용하여 리팩터링하고, 개선된 모습을 시연하여 다른 사람들이 그 패턴을 복사할 수 있게 하세요. 변화는 강요할 때보다 사람들이 그것이 작동하는 것을 직접 볼 때 더 빠르게 퍼집니다.

레거시 코드는 천천히 개선됩니다. 그래도 괜찮습니다. 적어도 운영 환경 (production)에서 폭발하지는 않으니까요. 그것이 더 낫습니다.