오늘은 개발자라면 누구나 한 번쯤은 고민해 봤을 만한 클린코드에 대한 이야기를 해보겠습니다. 클린코드의 중요성에 대해서는 다들 인지하고 있을 텐데요, 그렇다면 클린코드를 한마디로 정의하면 어떻게 이야기할 수 있을까요?
# 읽기 쉬운 코드가 클린코드이다.
우선 저명한 개발자가 어떻게 클린코드를 정의했는지 살펴보겠습니다.
“I like my code to be elegant and efficient. The logic should be straightforward and make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.”
- Bjarne Stroustrup, inventor of ‘C++
C++의 창시자인 Bjarne Stroustrup은 C에는 객체 개념이 없기 때문에 객체지향 효과를 극대화하기 위해서 C++를 만든 것으로 유명합니다.
Bjarne Stroustrup은 위와 같이 클린코드에 대하여 정의했는데요. 코드가 우아하다는 의미는 군더더기 없이 깔끔하다는 의미이고, 효과적이라는 것은 기능을 수행하는 코드를 최대한 작은 라인으로 구현한다는 의미로 보면 될 것 같습니다. 또한 클린코드는 직접적이고 에러 처리가 잘 되어 있으며 하나의 역할을 수행한다고 합니다.
최근 ‘백종원의 골목식당’이라는 프로그램을 보면 음식 메뉴를 줄이고 경쟁력을 키워주는 솔루션이 많이 등장하는데 그 의미와 비슷한 맥락이 있습니다.
그럼 여기서 또 다른 개발자의 의견을 들어보도록 하겠습니다.
“Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designers’ intent but rather is full of crisp abstractions and straightforward lines of control.”
- Grady Booch, author of ‘Object-Oriented Analysis and Design with Applications’
Grady Booch는 James Rumbaugh, Ivar Jacobson과 함께 UML(Unified Modeling Language)을 창시한 사람입니다. Grady Booch의 '클린코드가 단순하고 직접적이다’라는 말은 앞에서 설명한 내용과 동일한 의미입니다. 또한 그렇게 함으로써 클린코드는 결코 원작자의 의도를 숨기지 않는다고 합니다.
이렇듯 Bjarne Stroustrup과 Grady Booch의 의견을 종합해 볼 때 클린코드의 가장 중요한 요소 중 하나는 가독성이라고 볼 수 있습니다. 즉, 모든 팀원이 이해(understandability)하기 쉽도록 작성된 코드인 것이죠.
그럼 가독성이 왜 이렇게 중요할까요?
일반적으로 기존 코드를 변경하고자 할 때, 해석하는 시간과 수정하는 비율이 10:1이라고 합니다. 예를 들면 코드를 변경하기 위해서 걸리는 전체 시간이 10시간이라고 하면, 사전에 코드를 분석하는 시간이 9시간 이상 걸린다는 말로 이해하면 쉬울 것 같습니다.
그렇다면 해석이 어려운 코드는 그만큼 분석에 소요되는 시간이 더 오래 걸리겠죠? 더욱이 대부분의 결함은 기존 코드를 수정하는 동안에 발생한다고 하니 이해하기 쉬운 코드야말로 오류의 위험성을 최소화하는 셈입니다. 따라서 이해하기 쉽게 코드를 작성하는 것이 가장 중요하다고 볼 수 있습니다.
# Technical Debt은 왜 발생하는가?
이 그림을 보면 왜 클린코드를 작성해야 하는지에 대한 또 다른 설명이 될 것 같습니다. 변경 비용과 대응속도에 대한 이상치와 실제 프로젝트에서 발생하는 수치를 비교해 보았습니다.
왼쪽의 그래프는 시간이 지나감에 따라 들어가는 변경비용으로, 이상적인 변경비용은 일관되게 낮지만 실제 변경비용은 증가함을 볼 수 있습니다. 오른쪽의 그래프는 시간이 지나감에 따른 고객 요구사항의 대응속도로, 이상적인 대응속도는 일관되게 높지만 실제 대응속도는 점점 낮아짐을 볼 수 있습니다.
이러한 차이가 생기는 이유는 프로젝트 초기에 클린코드로 개발하기 보다는 좀더 빠르고 쉬운 방법을 선택하기 때문입니다. 대표적인 것이 'copy & paste'인데요.
이로 인하여 이상적인 변경 비용과의 차이가 나는 부분이 다음 그림의 Technical Debt입니다. 즉 클린코드 작성을 위해 개발자들이 언젠가 해결해야 되는 부채인 셈입니다.
# 클린코드를 작성하기 위한 원칙들은 어떤 것이 있을까?
그럼 클린코드를 작성하기 위한 가장 기본적인 원칙들을 살펴볼까요?
일반적인 사항으로는 다들 잘 알고 있는 것처럼 Coding 표준을 준수하고 단순하게 만들어서 가독성을 높이는 방법입니다.
Boy Scout Rule은 개발자로서 내가 담당하게 된 시스템을 내가 담당하기 이전의 코드보다 더 클린하게 만들자는 원칙인데요, 그런 과정을 거치면서 대규모 레가시 코드들도 점점 더 클린해질 수 있겠죠?
그리고 설계 관점으로 클린코드를 이야기할 때 가장 많이 회자되는 것이 위의 SOLID 원칙인데요.
SOLID 원칙에 대해서는 다음 시간에 모델링과 소스 코드를 보면서 상세하게 소개할 예정이니 많은 관심 부탁드립니다.
(참고)
1. Clean Code - Robert C Martin
2. Clean Code Cheat Sheet - Urs Enzler
