Clean Code 작성하기 - 관심사 분리

 

좋은 코드를 쓰는 것보다 나쁜 코드를 쓰지 않는 것이 중요하다. 왜냐하면 코드는 결국 소프트웨어를 이루는 근간이기 때문이다. 소프트웨어가 나쁜 코드로 구성되어 있으면 결국 해당 소프트웨어는 망가진다. 망가진다는 말은 더 이상 기능을 확장하거나 수정할 수 없게 된다는 의미다.

 

간혹 개발자들은 당장의 기능 구현이 급해서 좋은 코드를 포기하고자 하는 상황이 생긴다. 그리고 그 결정은 대부분 안 좋은 결과로 이어지게 된다. 실제로 프로그램의 복잡도가 올라갈수록 코드 한 줄을 입력하거나 수정하는데 드는 시간은 점점 늘어난다. 시간을 아끼기 위해서 좋은 코드를 포기했는데 결국 더 많은 시간을 들이게 되는 경우는 드문 일이 아니다.

 

그리고 대부분의 경우 기능 구현이 급해서 시간을 아끼기 위해서 좋은 코드를 포기하기보다는 좋은 코드를 고민하고 찾아보려는 노력을 점점 덜 하게 되어서 나쁜 코드로 나아가게 된다. 결국 그렇게 프로젝트 완성이나 기능 구현이 우선이고, 나중에 개선하면 된다는 생각을 하게 된다. 하지만 나중에 다시 개선할 거라는 코드를 다시 볼 수 있는 여유가 생기는 경우나 여유가 생겨도 다시 보는 일은 대부분 일어나지 않거나 쉽지 않은 일이다.

 

물론 여기서 말하는 나쁜 코드가 나중에 봤을 때 나쁜 코드를 의미하는 것은 아니다. 때로는 그때는 최선이었던 방법이 시간이 흐름에 따라서 현재에는 적합한 방법이 아닐 수 있는 것이다. 이런 이유로 레거시 취급을 받는 코드도 분명히 존재하며, 그때의 최선이었던 코드는 비교적 마이그레이션이나 개편하기 쉽다. 하지만 애초에 나쁜 코드는 이러한 작업들을 불가능에 가깝게 만든다. 나는 이전 직장에서 이런 레거시 코드를 경험해본 적이 있는데, 정말 개편 작업이 불가능에 가까웠다.

 

따라서 개발자는 반드시 좋은 코드, 깨끗한 코드를 작성하기 위해서 노력해야 한다. 그리고 개발자의 실력을 평가하는 기준이 되는 여러 중요한 요소 중 하나가 바로 이 좋은 코드, 깨끗한 코드를 작성할 수 있는지에 대한 여부라고 생각한다. 좋은 코드를 작성하기 위해서는 좋은 코드의 기준과 방법이 무엇인지를 고민하고 연구해야 한다. 그리고 개발 업계에서는 학습한 내용을 공유하는 문화 덕택에 좋은 개발자들이 지금껏 연구해놓은 수많은 좋은 코드를 작성하기 위한 원칙과 방법들이 존재한다. 이는 참으로 감사한 일이다.

 

관심사의 분리

개발에는 관심사의 분리(Seperation Of Concerns)이라는 용어가 있다. 이는 좋은 코드를 짜기 위한 가장 기본적인 원칙이며, 더 좋은 애플리케이션을 만들기 위한 여러 디자인 패턴, 기법, 아키텍처 등은 결국 모두 이 SoC를 가장 기본적인 원칙으로 삼고 있다.

 

관심사의 분리를 알아보기 위해 먼저 관심사라는 단어에 대해 알아보자면, 하나의 모듈이 수행하고자 하는 목적이다. 여기서 모듈이란 함수, 클래스 등의 단위로 해석할 수 있다. 따라서 관심사의 분리란 각 모듈들이 한 번에 여러 관심사를 처리하려고 하지 않고 하나의 관심사만 처리하도록 분리하는 것을 의미한다.

 

관심사를 분리하는 이유

관삼사를 분리하는 이유가 무엇인지, 하나의 모듈에서 여러 기능을 할 수 있으면 좋을 것 같은데 왜 하나의 모듈은 하나의 관심사만 처리해야 하는지 의문을 가질 수도 있다. 관심사를 분리하면 하나의 모듈은 하나의 목적만 가지게 된다. 하나의 목적만 가지게 된다는 말을 조금 다르게 해석해보자면, 하나의 모듈이 수정될 이유는 한 가지만 존재하게 된다는 의미다.

 

소프트웨어는 계속해서 변화한다. 하드웨어는 물리적인 실체가 있는 제품들을 의미한다. 반면 소프트웨어는 코드로 구성된 무형의 제품들을 의미한다. 물리적인 실체가 있는 제품들에 하드라는 용어가 붙은 의미는 수정하기가 힘들기 때문이다. 하드웨어를 수정하기 위해서는 실제로 부품을 생산하고 교체하는 과정을 거쳐야 하기에 많은 공수가 든다.

 

반면 소프트웨어는 상대적으로 수정하기 쉽다. 코드로 이루어져 있기 때문에 소프트웨어를 수정하기 위해서는 단순히 코드의 일부만 수정하면 소프트웨어의 동작을 변경할 수 있다. 즉, 소프트웨어는 변화에 유연하게 대응할 수 있어야 한다는 의미다. 실제로 소프트웨어가 잘못 설계되어서 변경하기 힘든 상황이라면 이는 하드웨어와 다를 바 없어지는 것이다.

 

위의 이유로 인해서 소프트웨어에서의 변화는 필연적이며, 좋은 소프트웨어일수록 기존의 기능을 수정하는 것과 기능을 확장하는 것을 잘할 수 있어야 한다. 이를 흔히 유지보수라고 부른다. 관심사를 분리하는 이유는 소프트웨어를 유지 보수하기 위해, 소프트웨어의 특정 부분이 변경되는 이유를 한 가지로 제한하기 위해서이다. 만약 여러 모듈들이 여러 관심사를 동시에 다루고 있다면 특정분야에 대해서 수정을 해야 할 때 관련된 모든 모듈을 수정해야 할 것이다.

 

예를 들어 애플리케이션 내에서 인증(Authentication)과 인가(Authorization)에 대해 모든 모듈들이 관여하고 있다면, 추후 인증과 인가의 동작에 수정이 필요할 경우에는 모든 모듈들을 수정해야 한다. 하지만 인증과 인가를 다루는 핵심 모듈을 한 가지로 제한해두고 나머지는 이 모듈을 사용하는 형식으로 설계되어 있다면, 인증과 인가의 동작이 변경되었을 경우에는 해당 모듈만 수정하면 되기에 변화에 유연하게 대응할 수 있게 된다.

 

관심사의 분리는 소프트웨어 개발에서 가장 기본이 되는 원칙이며, 비슷한 개념을 표현하는 여러 많은 단어들과 프로그래밍 격언들이 생겨났다.

• 단일 책임 원칙(Single Responsibility Principle): 관심사의 분리와 유사한 개념이지만, 관심사란 표현 대신 책임이란 용어를 사용한다. 각 모듈들은 책임(수행해야 하는 동작)을 가지고 있으며 각기 하나의 책임만을 가져야 한다는 원칙이다.
• KISS(Keep It Simple, Stupid): 각 모듈들은 간단하고 단순하게 만들라는 의미로, 여러 기능을 포함시켜 복잡하게 만들지 말고 하나의 기능만 수행하도록 하라는 의미다. 이 역시 SoC, SRP 등의 원칙과 유사한 의미를 가지고 있다.

 

참고하기 좋은 자료

https://ko.wikipedia.org/wiki/%EA%B4%80%EC%8B%AC%EC%82%AC_%EB%B6%84%EB%A6%AC

관심사 분리 - 위키백과, 우리 모두의 백과사전

https://teamdable.github.io/techblog/SoC-to-IoC

더 나은 객체지향 개발을 위한 아이디어: 관심사의 분리부터 제어의 역전까지