loading...

클린코드란 무엇인가?

오늘은 개발자라면 누구나 한 번쯤은 고민해 봤을 만한 클린코드에 대한 이야기를 해보겠습니다. 클린코드의 중요성에 대해서는 다들 인지하고 있을 텐데요, 그렇다면 클린코드를 한마디로 정의하면 어떻게 이야기할 수 있을까요?

# 읽기 쉬운 코드가 클린코드이다.

우선 저명한 개발자가 어떻게 클린코드를 정의했는지 살펴보겠습니다.


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은 왜 발생하는가?

변경 비용과 대응속도에 대한 이상치와 실제 프로젝트에서 발생하는 수치 비교(출처: Clean Code sheet)
변경 비용과 대응속도에 대한 이상치와 실제 프로젝트에서 발생하는 수치 비교(출처: Clean Code sheet)

이 그림을 보면 왜 클린코드를 작성해야 하는지에 대한 또 다른 설명이 될 것 같습니다. 변경 비용과 대응속도에 대한 이상치와 실제 프로젝트에서 발생하는 수치를 비교해 보았습니다.

왼쪽의 그래프는 시간이 지나감에 따라 들어가는 변경비용으로, 이상적인 변경비용은 일관되게 낮지만 실제 변경비용은 증가함을 볼 수 있습니다. 오른쪽의 그래프는 시간이 지나감에 따른 고객 요구사항의 대응속도로, 이상적인 대응속도는 일관되게 높지만 실제 대응속도는 점점 낮아짐을 볼 수 있습니다.

이러한 차이가 생기는 이유는 프로젝트 초기에 클린코드로 개발하기 보다는 좀더 빠르고 쉬운 방법을 선택하기 때문입니다. 대표적인 것이 'copy & paste'인데요.
이로 인하여 이상적인 변경 비용과의 차이가 나는 부분이 다음 그림의 Technical Debt입니다. 즉 클린코드 작성을 위해 개발자들이 언젠가 해결해야 되는 부채인 셈입니다.

이상적인 변경 비용과 차이가 나는 부분 Technical Debt(출처: Clean Code sheet)
이상적인 변경 비용과 차이가 나는 부분 Technical Debt(출처: Clean Code sheet)

# 클린코드를 작성하기 위한 원칙들은 어떤 것이 있을까?

그럼 클린코드를 작성하기 위한 가장 기본적인 원칙들을 살펴볼까요?

Clean Code의 주요원칙(General) Follow Standard Conventions : Coding 표준, 아키텍처 표준 및 설계 가이드를 준수하라. Keep it Simple, Stupid (KISS) : 단순한 것이 효율적이며, 복잡합을 최소화하라. Boy Scout Rule : 캠피장을 떠니기 전에 원래보다 깨끗하게 해야 한다.(참조되거나 수정되는 코드는 원래보다 clean하게 해야함) Root Cause Analysis : 항상 근본적인 원인을 찾아라. 그렇지 않으면 반복될 것이다 Do Not Multiple Language in One Source File: 하나의 파일은 하나의 언어로 작성하라 (Java, JavaScript, Html...)
Clean Code의 주요원칙(General)

일반적인 사항으로는 다들 잘 알고 있는 것처럼 Coding 표준을 준수하고 단순하게 만들어서 가독성을 높이는 방법입니다.
Boy Scout Rule은 개발자로서 내가 담당하게 된 시스템을 내가 담당하기 이전의 코드보다 더 클린하게 만들자는 원칙인데요, 그런 과정을 거치면서 대규모 레가시 코드들도 점점 더 클린해질 수 있겠죠?

Clean Code의 주요원칙(Class Design) S Simple Responsibility Principle(SRP) : 하나의 클래스는 하나의 책임만 가져야 한다. O Open/Closed Principle (OCP) : 클래스는 확장에 대하여 열려 있어야 하고, 변경에 대해서는 닫혀 있어야 한다. L Liskov Substitution Principle(LSP) : 파생 클래스의 메소드는 기반 클래스의 메서드를 대체하여 사용될 수 있어야 한다. I Interface Segregation(ISP) : 클라이언트가 사용하지 않는 메소드에 의존하지 않아야 한다. D Dependency Inversion Principle (DIP) : 추상화된 것은 구체적인 것에 의존하면 안된다(자주 변경되는 구체적인 것에 의존하지 말고 추상화된 것을 참조)
Clean Code의 주요원칙(Class Design)

그리고 설계 관점으로 클린코드를 이야기할 때 가장 많이 회자되는 것이 위의 SOLID 원칙인데요.
SOLID 원칙에 대해서는 다음 시간에 모델링과 소스 코드를 보면서 상세하게 소개할 예정이니 많은 관심 부탁드립니다.

(참고)
1. Clean Code - Robert C Martin
2. Clean Code Cheat Sheet - Urs Enzler


삼성SDS 소셜크리에이터 김동식(Principal Professional)


이 글이 좋으셨다면 구독&좋아요

여러분의 “구독”과 “좋아요”는
저자에게 큰 힘이 됩니다.

subscribe

구독하기

subscribe

공유하기