Clean Architecture

Introduction

개발자라면 누구나 알고 있는 그 책 Clean Architecture를 드디어 읽어 보았다. 이전에 Clean Code를 읽고 Clean Architecture도 꼭 읽어봐야지 했었는데, 이제서야 이 책을 읽게 되었다.

이 글을 통해 내가 이 책을 읽고 생각 나는 키워드 들과 소감을 적어보고자 한다.

클린 아키텍처

이 책에서는 클린 아키텍처란 정확히 무엇인지를 정의하고 있진 않다. 하지만 나는 추천사에서 한 문장을 발견하였고 이 문장이 우리가 추구하는 클린 아키텍쳐가 아닐까 생각한다.

소프트웨어가 지닌 부드러움을 인지하고 이 부드러움을 시스템에서 최우선으로 보존하는 것을 목표로 한다.

소프트웨어 아키텍쳐의 규칙은 과거 프로그래밍 코드가 처음나온 이후로 지금까지 변하지 않았다. 저자는 아마 앞으로도 이러한 규칙은 변하지 않을 것이므로 우리는 이러한 규칙을 지키기 위해 노력해야 한다고 말하고 있다.

경계

소프트웨어에는 분명한 경계가 존재하며 우리는 아키텍처를 설계할 때 어떻게, 언제 선을 그어서 경계를 결정할지 잘 선택해야 한다. 경계는 MSA와 같이 각 어플리케이션이 될 수도 있고 모듈, 패키지 등이 될 수도 있다. 소프트웨어 아키텍처를 설계할 때 우리는 이러한 경계를 어떻게 넘나들 것이며 어떠한 방향으로 흐름을 가질 것인지 잘 선택해야 좋은 아키텍처를 설계할 수 있다.

디테일

내가 고민을 많이 하고 잘못 이해하고 있었던 부분이 디테일이었다. 책에서는 웹을 포함하여 데이터베이스 심지어 프레임워크조차도 디테일이라고 말하고 있다. 우리는 이러한 디테일을 어느 경계에 둘지 알아야 하며 가장 핵심인 도메인 코드가 어느 방향성을 가지고 디테일에 접근하도록 설계해야 하는지, 디테일이 도메인을 더럽히지 않도록 어떻게 해야 하는지 이 책을 통해 배울 수 있다.

구현

아무리 잘 경계가 나누어지고 유연하게 설계된 아키텍처라도 세부사항을 구현하는 개발자가 규칙을 우회하거나 깨어버린다면 그 시스템은 더이상 클린 아키텍처라고 할 수 없다. 아마 많은 아키텍트가 고민하고 있는 부분일 것이고 이를 방지하기 위해 노력하고 있을 것이다. 우리는 소프트웨어가 계속해서 부드러움을 유지할 수 있도록 좋은 아키텍처를 이해하고 그 규칙을 지키기 위해 노력해야한다.

Wrap up

회사에서 동료들과 프로젝트를 진행하면서 시스템을 설계할 때 다음과 같은 이야기를 한적이 있다.

“도메인 코드가 디테일 코드를 사용하지 못하게 모듈을 물리적으로 분리하는게 어떨까요?”

동료들 중 한분은 이렇게 대답해 주셨다.

“말씀하신 방법은 이상적이고 좋다고 생각해요. 하지만 실제로 작업을 하다보면 이러한 제약으로 인해 많은 불편함을 느끼게 될 것이고 이는 프로젝트의 일정에 영향을 미칠 수 있으니 분리하지 않는게 좋다고 생각해요”

프로젝트 일정이 정해져 있는 시점에서 프로젝트를 관리해야 하는 매니저는 당연히 일정을 고려하지 않을 수 없다. 그래서 그 분이 말씀하신 의견을 공감하기는 하지만 내 머릿 속에는 아래와 같은 문구가 생각이 나는 건 어쩔 수 없었다.

빨리 가는 유일한 방법은 제대로 가는 것이다. - 로버트 C. 마틴

나는 아직 주니어 개발자이고 좋은 아키텍처를 설계할 수 있을 만한 능력과 재목은 되지 못한다고 생각한다. 하지만 다행히 이 책을 읽음으로써 아직 부족하지만 내가 하지 말아야 할 것들을 알 수 있게 되었고, 앞으로 많은 연습과 경험을 토대로 좋은 아키텍처를 만들 수 있는 역량을 키우기 위해 노력할 수 있게 되었다.

이 책은 나에게 큰 도움이 된 책이 될 것이고 두고두고 내가 가야할 길을 못찾고 있을 때마다 도움을 줄 것이라 생각한다.