클린 아키텍처

 

로버트 마틴의 클린 코드에선 코드를 깔끔하게 잘 짜는 방법을 배웠다면 클린 아키텍처에서는 소프트웨어를 더 잘 만드는 방법을 배운 것 같다. 책의 표현을 빌리자면 클린 코드에서는 좋은 벽돌을 구분하는 방법을 배웠다면 클린 아키텍처에서는 좋은 벽돌로 건물을 짓는 방법을 배운 느낌이랄까. 책에선 저자가 경험한 내용을 바탕으로 전달하려는 교훈이 많다. 저수준, 고수준, 프레임워크는 세부사항일 뿐이다 등등.. 그런데 나의 소프트웨어 깊이가 부족해 공감하기 어려운 부분도 있었고 이해되지 않던 부분도 있어서 모두 소화하진 못했다. 그래도 연차가 늘어나고 더 큰 규모의 소프트웨어를 경험하다보면 이 책에서 내가 캐치하지 못했던 새로운 면이 보일 것 같아 기대된다. 2-3년 후에 다시 이 책을 읽어봐야 겠다.

 

많은 전달 내용 중 내 머릿속을 관통하는 소프트웨어 원칙은 이 그림으로 표현 할 수 있다.

 

 

다이어그램 상에선 컴포넌트A 가 컴포넌트B를 가리키고 있는 그림인데 소프트웨어상에선 컴포넌트A 가 컴포넌트B 에 의존한다는 의미의 그림이다. 이 의존 관계는 소프트웨어 상에서 생길 수 있는 가장 중요한 관계고 이 관계를 어떻게 정의하느냐에 따라서 소프트웨어의 아키텍처가 결정된다. 컴포넌트A는 저수준으로, 컴포넌트B는 고수준으로 둬야한다고 그림상에선 표현 했는데 여기서 말하는 수준은 어떤 컴포넌트가 우월한지를 결정하는 기준이 아니라 얼마만큼 변동성이 크냐를 기준으로 결정한다.

 

위 그림처럼 의존관계가 성립되려면 고수준인 컴포넌트B는 수정할 일이 적어야 한다. 그래야 컴포넌트A에 미치는 영향을 최소화 할 수 있기 때문이다. 위 그림처럼 결정되는 대표적인 예가 애플리케이션에서 String, Math 같은 자바 고유 라이브러리 클래스를 사용하는 경우다. 자바 버전에 따라서 클래스가 변경될 소지가 있지만 그래도 우리가 개발하는 클래스보다 변경될 소지는 적다. 이런 경우 의존 관계는 적절한 것으로 볼 수 있다.

 

그래도 가끔은 이런 의존 관계를 성립하기 힘든 경우도 있다. 둘다 변경의 소지가 크지만 두 클래스를 연결해야할 때가 있다. 이럴때 사용하는 방식이 의존성 역전원칙이다. 좀더 고수준으로 보이는 클래스에 특정 인터페이스를 만들고 이것과 상속 관계로 만든다. 그리고 저수준 클래스를 인터페이스에 의존하는 관계로 만든다. 인터페이스는 변경될 소지가 적기 때문에 이 의존 관계도 적절한 관계로 볼 수 있다.

 

 

물론 매번 이렇게 코딩할 수는 없다. 개발하다보면 새로운 함수도 추가해야돼 인터페이스도 손될 일이 많아지니까. 모든 원칙을 지키다 보면 오버 엔지니어링이돼 개발 프로세스가 느려지는 부작용도 생길 수 있다. 항상 모든 원칙을 지키기는 어려울 것 같다. 하지만 원칙을 알고 생략하는 것과 모르고 넘어가는 것은 차이가 크다. 앞으로 일하면서 어떤 원칙을 넘기면서 개발하고 있는지 되새겨봐야 할 것 같다.