코드 리팩터링이란 무엇인가요?

Martin Fowler는 1999년에 처음 출간된 그의 저서 '리팩터링(Refactoring)'을 통해 이 관행을 대중화했습니다. 코드 리팩터링은 Martin Fowler가 '일반적으로 시스템의 더 깊은 문제를 나타내는 표면적인 징후'라고 정의하는 '코드 냄새'를 제거하는 데 도움이 될 수 있습니다. Martin Fowler는 코드 냄새를 '쉽게 발견하거나 냄새를 맡을 수 있다'고 덧붙이며, 데이터만 있고 동작이 없는 긴 방법과 클래스를 코드 냄새의 사례로 꼽았습니다.

코드 리팩터링의 예로는 잘못된 서식 수정, 설명이 없는 변수 이름 바꾸기, 중복되거나 사용하지 않는 함수 제거, 크고 긴 방법을 더 작고 관리하기 쉬운 블록으로 나누기 등이 있습니다. 이러한 미세한 동작 보존 수정은 코드를 손상하거나 오류를 일으킬 가능성은 적지만, 점진적인 효과를 통해 소프트웨어 성능을 최적화하는 데 도움이 될 수 있습니다.

리팩터링은 간단한 작업처럼 보일 수 있지만, 다음과 같이 소프트웨어 개발자가 더 전략적으로 접근하는 데 도움이 되는 몇 가지 전술이 있습니다.

    ● 추상화

    ● 구성

    ● 피처 이동

    ● 레드-그린 리팩터링

    ● 간소화

추상화는 객체 지향 프로그래밍의 기본 개념입니다. 객체를 일반화하여 복잡한 세부 사항은 숨기고 필수 정보만 남기도록 합니다.

코드 리팩터링에서 추상화는 일반적으로 대규모 코드베이스에 대해 구현됩니다. 추상화는 다음 두 가지 메커니즘으로 구성됩니다.

● 풀업 방법은 하위 클래스에서 코드를 가져와 계층 구조에서 추상 클래스 또는 수퍼 클래스로 옮기는 것입니다. 이렇게 하면 코드 중복이 줄어들고 공유 속성이나 함수의 재사용성이 향상됩니다.

 ● 푸시다운 방법은 재사용할 수 없거나 특정 하위 클래스에만 적용되는 논리를 위해 추상 클래스 또는 슈퍼클래스의 코드를 하위 클래스로 푸시하는 것입니다.

이 모듈식 접근 방식은 거대한 코드 덩어리를 더 간단하고 관리하기 쉽도록 더 작은 코드 덩어리로 나누거나 세분화합니다. 추출 방법과 인라인 방법은 다음과 같이 두 가지 구성 방식입니다.

● 추출 접근 방식은 기존 방법의 일부를 가져와 새로운 방법으로 옮기는 것입니다. 예를 들어 서로 다른 함수를 포함하는 거대한 방법에 대해 각 함수가 독립된 방법을 가질 수 있도록 할 수 있습니다.

● 인라인 접근 방식은 방법 호출을 방법 자체의 본문이나 내용으로 대체한 후 해당 방법을 삭제합니다. 이는 일반적으로 몇 줄의 코드만 있고 단일 클래스에 의해서만 호출되는 방법에 적용됩니다.

이 기법에서는 클래스 간에 속성, 방법 및 기타 피처를 이동하여 종속성을 줄이고 클래스 내 기능 및 클래스 간의 일관성을 향상합니다. 이러한 재배포를 통해 기존 코드를 더 논리적이고 균형 있게 설계하여 확장 및 유지보수가 더 쉬워집니다.

레드-그린-리팩터링은 소스 코드 자체보다 먼저 테스트가 작성되는 테스트 주도 개발에서 차용한 것입니다. 이는 지속적인 리팩터링과 테스트를 허용하는 반복적인 전략입니다.

이 3단계 프로세스는 다음을 따릅니다.

● 레드 단계에서는 개발자가 특정 소프트웨어 동작이나 기능을 검증하기 위해 테스트를 작성합니다. 이러한 테스트는 코드가 아직 생성되지 않았기 때문에 처음에는 실패하도록 되어 있습니다.

● 그린 단계에서는 프로그래머가 지정된 동작 또는 기능에 대한 코드를 작성합니다. 여기서 목표는 품질보다 속도이기 때문에 테스트를 통과하는 데 필요한 최소 코드일 수 있습니다.

● 마지막으로 리팩터링 단계에서는 코드의 동작을 유지하고 모든 관련 테스트를 통과하면서 더 깔끔하고 명확하며 효율적인 코드를 위해 필요한 개선 작업을 수행합니다.

여기서 목표는 코드와 관련 로직을 단순화하는 것입니다. 이는 방법의 매개변수 수를 줄이고, 지나치게 긴 변수나 방법의 이름을 바꾸고, 동일한 결과를 가져오는 조건 표현식을 결합하고, 복잡한 조건 조각을 분리하거나 조건부 대신 다형성을 사용하는 등의 형태로 이루어질 수 있습니다.

코드 리팩터링은 주말 청소를 훨씬 쉽고 빠르게 하려고 매일 방을 정리하는 것과 같습니다. 코드 리팩터링의 목표는 프로그래머가 로직 중복, 코딩 표준 미준수, 불분명한 변수 이름 사용 등 편법을 택하면서 쌓인 기술 부채를 줄이는 것입니다.

소프트웨어 개발 팀이 코드 리팩터링을 통해 얻을 수 있는 몇 가지 이점은 다음과 같습니다.

    ● 복잡성 감소

    ● 유지보수성 향상

    ● 코드 가독성 향상

    ● 속도 향상

리팩터링하면 코드가 더 간단해질 수 있습니다. 이를 통해 개발자는 대규모 코드베이스를 더 잘 이해할 수 있습니다. 새로 고용된 프로그래머도 익숙하지 않은 코드의 내부 작동을 빠르게 파악할 수 있으므로 이점이 있습니다.

코드 리팩터링은 더 나은 유지보수를 위한 토대를 마련합니다. 코드가 명확하면 디버깅, 새로운 기능 구현, 기존 피처 업데이트 또는 최신 기술로 업그레이드 시 수고를 덜어줍니다. 제조업의 예방적 유지보수와 마찬가지로 코드 리팩터링을 사용하면 현재의 미세한 수정으로 향후 큰 버그를 방지할 수 있습니다.

코드를 리팩터링하면 더 깔끔해져서 이해하고 작업하기가 더 쉬워집니다. 또한 리팩터링한 코드는 탐색이 더 원활해져 소프트웨어 개발 프로세스를 간소화하는 데 도움이 됩니다.

리팩터링은 성능을 목표로 하는 실제 코드 최적화만큼 큰 영향을 미치지 않을 수도 있습니다. 하지만 코드가 더 간단하고 부피가 적으면 여전히 소프트웨어의 효율성과 런타임 단축에 기여할 수 있습니다.

코드를 리팩터링하면 명확하고 깔끔해질 수 있지만 이 프로세스에 단점이 없는 것은 아닙니다. 다음은 개발 팀이 코드를 리팩터링할 때 직면할 수 있는 몇 가지 문제입니다.

    ● 개발자 할당

    ● 버그 발생

    ● 레거시 코드

    ● 범위 확장

    ● 시간 제약

팀에서는 코드 리팩터링 프로세스에 누가 참여할지, 각자의 역할과 책임이 무엇인지 결정해야 합니다. 이로 인해 프로그래머가 중요한 소프트웨어 개발 작업에서 멀어질 수 있으며, 소규모 팀에서는 이러한 절충안을 감당하지 못할 수도 있습니다.

코드를 조금만 변경해도 새로운 버그가 발생하거나 기존 버그가 재등장할 가능성이 있습니다. 코드 리팩터링이 더 복잡해지면 피처와 기능이 손상되거나 변경될 가능성도 있습니다.

레거시 코드란 여전히 용도에 부합하지만, 현재는 구식인 기술로 개발되어 더 이상 적극적으로 지원되거나 유지보수되지 않는 오래된 코드베이스를 말합니다. 리팩터링 시 종속성 문제와 호환성 문제가 발생할 수 있습니다. 이를 위해서는 더 심층적인 코드 분석과 레거시 코드에 영향을 미치는 모든 변경 사항에 대응하기 위한 세부 계획이 필요합니다.

특별히 계획이 없거나 명확한 목표가 설정되지 않은 경우, 필요한 것 이상을 수정하고 싶은 유혹에 빠질 수 있습니다. 특히 논리적 재구성을 다룰 때 프로그래머가 코드를 검토하고 어떤 부분을 개선할 수 있는지 숙고하지 않으면 그 범위가 확장될 수 있습니다.

코드 리팩터링에는 많은 시간이 소요될 수 있으며, 대부분의 개발 팀에서는 시간이 부족합니다. 리팩터링의 필요성과 프로젝트 마감일 준수 사이의 균형을 맞추고 리팩터링의 시기와 양을 고려해야 합니다.

코드 리팩터링 여정을 시작하기 전에 프로세스의 문제를 해결하는 데 도움이 되는 다음 팁을 고려하시기 바랍니다.

    ● 시기가 중요

    ● 계획이 핵심

    ● 분석 및 표준화

    ● 테스트 및 문서화

코드 리팩터링을 언제 하느냐도 이유나 방법만큼이나 중요합니다. 소프트웨어 개발 팀의 정기적인 유지보수 활동의 일부로 수행하거나 코드 검토에 통합할 수 있습니다.

새로운 피처 추가, 실질적인 업데이트 구현, 최신 기술 스택으로 전환, 애플리케이션 프로그래밍 인터페이스(API) 또는 라이브러리 업그레이드 전에도 리팩터링은 필수입니다. 이를 통해 향후에 더욱 확장 가능하고 적응력 있는 프레임워크를 구축할 수 있습니다.

코드 리팩터링은 시간이 많이 소요될 수 있으므로 계획이 필수적입니다. 개발 팀은 목표와 범위를 고려해야 합니다. 데드 코드 삭제, 서식 수정 또는 중복 제거와 같은 미세한 변경에 며칠 동안 집중하여 작은 단계를 밟을 수 있습니다. 더 복잡한 정리가 필요한 경우 리팩터링은 장기 프로젝트가 됩니다.

간단한 리팩터링 작업에는 많은 분석이 필요하지 않을 수 있습니다. 그러나 논리를 다루는 기법의 경우 모든 관련 코드를 이해하는 것이 중요합니다. 코드 구조의 근거를 파악하면 프로그래머가 더 많은 정보를 바탕으로 의사 결정을 내리고 의도적인 수정하는 데 도움이 될 수 있습니다.

또한 팀의 코딩 표준 및 설계 원칙을 따르면 무결성을 유지하고 코드베이스의 아키텍처를 유지할 수 있습니다.

리팩터링은 코드를 개선하는 것뿐만 아니라 개선된 코드가 제대로 작동하는지 확인하는 작업이기도 합니다. 그렇기 때문에 소프트웨어 자체와 그 동작이 그대로 유지되는지 확인하기 위해 테스트가 중요합니다.

개발자가 직접 통합 및 단위 테스트를 실행할 수 있지만, QA 팀의 역할이 매우 중요합니다. 기능 테스트를 실행하여 피처를 검증하고 회귀 테스트를 실행하여 리팩터링한 코드에 버그가 발생하거나 기능이 중단되지 않았는지 확인할 수 있습니다.

변경 사항을 문서화하는 것도 프로세스의 일부가 되어야 합니다. 이렇게 하면 수정 사항을 더 쉽게 추적할 수 있고 향후 코드 리팩터링을 더 원활하게 수행할 수 있습니다.

코드 리팩터링의 속도를 높이고 자동화하는 데 도움이 되는 여러 툴이 있습니다. 다음은 몇 가지 인기 툴입니다.

    ● 통합 개발 환경(IDE)

    ● 정적 코드 분석기

    ● 기타 리소스

현재 IDE 중 다수는 코드를 손상시키거나 버그를 발생시키지 않고도 자동 리팩터링을 지원하는 기능을 기본으로 갖추고 있습니다. 일부는 AI 기반 리팩터링 권장 사항을 제공하기도 합니다.

코드 리팩터링에 사용할 수 있는 IDE로는 Java Virtual Machine(JVM) 기반 프로그래밍 언어용 IntelliJ IDEA, Python용 PyCharm, C#, C++ 및 .NET용 ReSharper Visual Studio 확장 프로그램 등이 있습니다.

정적 분석기는 코드를 실행하지 않고도 평가합니다. 이러한 분석기는 일반적인 프로그래밍 결함과 코드 품질 문제를 탐지하여 개발자가 소프트웨어 개발 프로세스 초기에 수정할 수 있도록 지원합니다.

정적 코드 분석기의 예로는 여러 프로그래밍 언어를 지원하는 Codacy 및 오픈 소스 PMD, Java용 JArchitect, .NET용 NDepend, Ruby용 RuboCop linter 및 Formatter가 있습니다.

Refactoring.com은 Martin Fowler의 웹 사이트로, 그의 책에 수록된 리팩터링 방법의 온라인 카탈로그가 포함되어 있습니다. Refactoring.Guru는 리팩터링 기법과 설계 패턴에 대해 설명하는 또 다른 웹 사이트입니다.

인공 지능(AI)은 코드 리팩터링 프로세스를 지원할 수 있습니다. 생성형 AI 애플리케이션은 복잡하거나 거대한 코드베이스를 분석하고 그 이면의 의미와 컨텍스트를 이해할 수 있는 대규모 언어 모델(LLM)으로 구동됩니다. 이를 기반으로 실시간 리팩터링 권장 사항을 즉시 제공합니다.

예를 들어 IBM watsonx Code Assistant는 IBM Granite 모델을 활용하여 버그 및 개선 필요 영역을 식별합니다. 그런 다음 팀의 기존 코딩 규칙에 부합하는 타겟팅된 수정 사항을 제안하여 코드 리팩터링을 간소화하고 가속화할 수 있도록 지원합니다. 다른 유사한 AI 리팩터링 툴로는 Amazon CodeGuru Reviewer, GitHub Copilot, OpenAI의 ChatGPT 등이 있습니다.

레거시 코드를 다루는 사용자를 위해 IBM watsonx Code Assistant for Z는 생성형 AI와 자동화를 결합하여 개발자가 애플리케이션을 현대화할 수 있도록 지원합니다. Refactoring Assistant용 watsonx Code Assistant를 사용하면 프로그래머가 애플리케이션을 더 모듈화되고 재사용 가능한 서비스로 리팩터링할 수 있습니다. 코드 분석 알고리즘을 사용하여 COBOL 애플리케이션을 현대화합니다.

다른 AI 시스템과 마찬가지로 개발자는 AI 기반 코드 리팩터링 툴의 아웃풋을 검토하여 정확성을 확인해야 합니다. 또한 테스트도 진행하여 제안된 변경 사항이 예상대로 작동하는지 확인해야 합니다.