모바일 프로젝트의 쓰레기 코드와 엉망 — 징후 및 리팩토링

개발에서 쓰레기 코드란 무엇인가

쓰레기 코드(spaghetti code, 엉망, big ball of mud)는 구조를 잃고 의존성의 얽힌 그물이 된 코드베이스에 대한 은유입니다. 이러한 코드에서는 한 곳의 변경이 다른 곳을 망가뜨리며, 새 기능 추가는 위험한 작업이 됩니다.

모바일 개발에서 쓰레기 코드는 특히 심각합니다. “엉망” 위에 구축된 앱은 느려지고, 오래된 기기에서 충돌하며, 코드 리뷰를 통과하는 데 어려움을 겪습니다. 아키텍처가 없는 iOS 프로젝트는 불안정성으로 인해 App Review를 통과하지 못할 수 있습니다.

Stripe에 따르면, 개발자는 업무 시간의 최대 42%를 기존 코드를 읽고 이해하는 데 사용합니다. 쓰레기 코드가 있는 프로젝트에서는 이 수치가 60%를 초과하여 개발이 극도로 비효율적이 됩니다.

용어의 기원

Spaghetti code는 가장 오래된 용어로, 1970년대로 거슬러 올라갑니다. 엉킨 파스타를 연상시키는 혼란스러운 제어 흐름의 코드를 설명합니다.

Big ball of mud는 Brian Foote와 Joseph Yoder가 1997년에 명확한 아키텍처 없이 혼란스럽게 성장하는 시스템을 설명하기 위해 도입한 용어입니다.

쓰레기 코드가 비즈니스에 위험한 이유

쓰레기 코드는 새로운 기능의 시장 출시를 지연시킵니다. 팀은 가치 창출이 아니라 기존 코드가 어떻게 작동하는지 이해하고 아무것도 망가뜨리지 않으려고 시간을 보냅니다.

McKinsey에 따르면, 코드 품질이 낮은 기업은 제품 유지 관리에 20~40% 더 많은 비용을 지출하며, 새 기능 출시 속도는 코드 품질이 높은 기업에 비해 2~3배 낮습니다.

쓰레기 코드의 징후와 인식 방법

쓰레기 코드는 객관적인 지표 세트를 통해 인식할 수 있으며, 그중 일부는 자동으로 측정됩니다. 일치하는 지표가 많을수록 문제가 더 심각합니다.

업계에서는 Halstead 복잡도, 유지보수성 지수, 기술 부채 비율과 같은 코드 품질 지표가 사용됩니다. 이러한 지표를 이해하면 코드베이스의 상태를 객관적으로 평가하는 데 도움이 됩니다.

복사-붙여넣기(코드 중복)

가장 흔한 쓰레기 코드의 징후는 반복되는 코드 블록입니다. 공통 함수를 추출하는 대신 개발자는 최소한의 변경으로 코드를 한 곳에서 다른 곳으로 복사합니다.

최대 5%의 중복 수준은 정상으로 간주됩니다. 중복이 15%를 초과하면 심각한 신호입니다. Simian 및 PMD Copy Paste Detector와 같은 도구는 복사-붙여넣기를 자동으로 식별하는 데 도움이 됩니다.

긴 메서드와 클래스

100줄이 넘는 메서드는 쓰레기 코드의 명확한 징후입니다. 이러한 메서드는 일반적으로 너무 많은 일을 하며 단일 책임 원칙(Single Responsibility)을 위반합니다.

1000줄이 넘는 코드가 있는 클래스도 문제입니다. 관련 없는 기능을 포함하여 코드 테스트, 이해 및 수정이 어렵습니다.

높은 순환 복잡도

McCabe의 순환 복잡도(Cyclomatic Complexity)는 코드의 독립적인 경로 수를 나타내는 지표입니다. 15를 초과하는 값은 문제가 있는 것으로 간주됩니다.

30을 초과하는 복잡도의 메서드는 “재앙 영역”에 있습니다. 분기가 너무 많아 심층 분석 없이는 테스트하고 이해하는 것이 불가능합니다.

쓰레기 코드의 원인

쓰레기 코드는 “저절로” 생기지 않습니다 — 항상 팀 내 특정 프로세스와 결정의 결과입니다. 원인을 이해하면 미리 예방하는 데 도움이 됩니다.

JetBrains Developer Ecosystem 2024에 따르면, 개발자의 67%가 시간 부족으로 인해 자신의 능력보다 나쁜 코드를 작성한다고 인정합니다. 이것이 기술 부채 축적의 주요 원인입니다.

서두름과 마감일

가장 흔한 원인은 빡빡한 마감일입니다. 팀은 마감일을 맞추기 위해 “되는 대로” 코드를 작성합니다. 리팩토링, 테스트, 코드 리뷰는 “나중에”로 미뤄집니다.

문제는 “나중”이 결코 오지 않는다는 것입니다 — 다음 스프린트에서 새로운 마감일이 나타나고 기술 부채는 눈덩이처럼 쌓입니다.

코드 리뷰 부족

코드 리뷰 없이 각 개발자는 자신만의 스타일로 작성하고, 자신만의 패턴을 사용하며, 자신만의 “흔적”을 남깁니다. 시간이 지나면서 코드베이스는 통일성을 잃습니다.

SmartBear 2024 연구에 따르면, 모든 풀 리퀘스트에 대해 필수 코드 리뷰를 실시하는 팀은 프로덕션에서 결함이 60% 적습니다.

처음부터 약한 아키텍처

프로젝트가 명확한 아키텍처 없이 시작되면 쓰레기 코드는 불가피합니다. 첫 번째 “빠른 수정”이 나중에 품질 좋은 것을 구축하기 어려운 기초를 만듭니다.

모바일 개발에서 아키텍처(MVC, MVP, MVVM, Clean Architecture) 선택은 코드 작성을 시작하기 전에 내려야 할 의식적인 결정이지, 진화의 결과가 아닙니다.

쓰레기 코드 대처 방법

쓰레기 코드에 대처하려면 팀 전체의 체계적인 접근 방식과 규율이 필요합니다. 문제를 해결할 단일 도구나 방법은 없습니다 — 일련의 조치가 필요합니다.

주요 원칙은 쓰레기 코드를 작성 단계에서 방지하는 것이지, 나중에 수정하는 것이 아닙니다. 예방은 항상 기존 “엉망”을 리팩토링하는 것보다 저렴합니다.

코딩 표준

통일된 코드 스타일은 쓰레기 코드 방지의 기초입니다. 코딩 표준(Code Style)은 문서화되어야 하며 린터에 의해 자동으로 검사되어야 합니다.

iOS에는 SwiftLint가, Android에는 Ktlint와 Detekt가 사용됩니다. 구성 파일에 규칙을 설정하면 표준을 위반하는 풀 리퀘스트를 자동으로 거부할 수 있습니다.

정기적인 리팩토링

리팩토링은 버그 수정이 아니라 동작을 변경하지 않고 코드 구조를 개선하는 것입니다. 이는 개발 프로세스의 정기적인 일부여야 하며 별도 프로젝트가 아닙니다.

각 스프린트 시간의 20%를 리팩토링과 기술 부채 상환에 할당하는 것이 좋습니다. 이는 “엉망”이 쌓이는 것을 방지하고 장기적으로 팀의 속도를 유지합니다.

필수 코드 리뷰

모든 풀 리퀘스트는 최소 한 명의 개발자가 검토해야 합니다. 코드 리뷰는 버그뿐만 아니라 아키텍처 위반, 스타일 문제, 쓰레기 코드의 잠재적 원인도 식별합니다.

좋은 방법은 복사-붙여넣기, 메서드 길이, 순환 복잡도, 테스트 커버리지 확인을 포함한 코드 리뷰 체크리스트입니다. 체크리스트 없이 리뷰어는 최대 50%의 문제를 놓칩니다.

코드베이스 정리 도구

현대적인 코드 분석 도구는 쓰레기 코드를 자동으로 감지하고, 기술 부채를 측정하며, 품질을 모니터링할 수 있습니다. 이러한 도구를 CI/CD 파이프라인에 통합하면 지속적인 모니터링이 가능합니다.

최소한 하나의 정적 분석기와 하나의 지표 측정 도구를 사용하는 것이 좋습니다. 추가로 코드 품질 데이터를 집계하는 플랫폼을 연결할 수 있습니다.

정적 분석기

• SonarQube — 선도적인 코드 품질 분석 플랫폼, 30개 이상의 언어 지원, 기술 부채 비율 지표 제공
• ESLint — JavaScript 및 TypeScript 표준, 구성 파일을 통해 설정 가능, IDE에 통합
• SwiftLint — iOS 프로젝트 필수 도구, Swift 스타일 가이드 준수 여부 확인

SonarSource에 따르면, 정적 분석을 사용하는 팀은 도입 후 첫 분기 내에 프로덕션 버그 수를 30% 줄입니다.

지표 측정 도구

CodeClimate와 Codacy는 코드 품질 지표를 집계하고, 추세를 추적하며, “핫스팟” — 기술 부채가 가장 높은 파일을 보여주는 플랫폼입니다.

Android 프로젝트의 경우 Detekt는 순환 복잡도, 메서드 길이, 코드 중복 검사를 포함한 100개 이상의 내장 분석 규칙을 제공합니다.