백엔드 취준생이 클린 아키텍처를 읽고

도서를 읽으며 의존성이 무엇인지 명확하게 파악할 수 있었다. 의존성을 이해함으로써 지금까지 학습했던 SOLID 원칙, 스프링프레임워크의 IoC/DI의 편리함, 객체지향의 다형성 나아가 객체지향의 장점까지 되돌아 볼 수 있는 좋은 기회였다.

 

클린 아키텍처를 읽고 나에게 주입된 문장은 ‘정책과 세부 사항을 분리하고, 의존 방향을 제어 흐름과 반대로 역전시켜 세부사항이 정책을 의존하게 하라’이다. 

 

이 문장은 클래스 레벨부터, 모듈과 컴포넌트, 서비스, 시스템 레벨까지 아우르는 말이라고 생각한다. 상위 수준의 정책은 인터페이스를 두어 하위 수준의 세부 사항 컴파일 타임에는 의존하지 않고, 런타임에 의존한다. 또한, 세부 사항은 정책의 인터페이스를 구현하도록 하여 확장에 열려있고, 세부 사항의 변경에 정책은 영향을 받지 않는 OCP를 만족한다.

 

지금까지는 클린 아키텍처에서 말하는 수평 계층형 아키텍처를 사용하여 개발해왔다. 스프링MVC를 사용한 전형적인 MVC 패턴의 프로젝트 구조이다. 보통 이런 구조를 가진 프로젝트에서 JPA를 사용한 방법론으로 개발한다면 데이터베이스 엔티티=도메인 이 되기 쉽다.

 

즉, 비즈니스 로직에서 사용하는 데이터는 변하지 않았음에도 불구하고, 데이터베이스 구조가 변경됨에 따라 데이터베이스 엔티티가 필연적으로 변경되며, 이를 의존하는 비즈니스 로직도 연쇄적으로 변경된다. 어쩌면 UI를 담당하는 컨트롤러 레이어까지 변경이 필요할 수도 있다.

이전 프로젝트에서 몇번 겪어본 상황이다. 그때는 데이터베이스 엔티티와 도메인이 동일한 줄 알았으니 무엇이 문제인지 몰랐다. 그저 데이터베이스 테이블의 구조 변경이 필요한 요구사항을 가져오는 PM이 나빠보였다 (ㅎㅎ..) 사실 개발자의 역량 부족인데 말이다.

 

이제는 프로젝트를 설계함에 있어 아키텍처는 빠질 수 없는 요소라는 것을 깨달았다. 요구사항이 완벽하게 정리되지 않고 자주 변경된다면 혹은 세부사항(데이터베이스, 프레임워크, 입출력 방식 등)이 결정되지 않은 상황이라면 더더욱 정책과 세부사항을 분리하고 의존 방향을 잘 설정하여 아키텍처를 구성하는 것이 현명해 보인다.

 

물론 클린 아키텍처에서 말하는 헥사고날, 마이크로서비스 아키텍처가 모든 프로젝트에서 효율적이고 안정적인 마법의 은탄환이라고 생각하지 않는다. 프로젝트의 규모, 기술 수준과 일정 등을 고려하여 현제 상황에 적합한 아키텍처를 채택하는 것도 개발자의 능력이라고 생각한다.

 

아직 실무 경험이 전무하기에 클린 아키텍처의 내용을 해석하고 정리하는 것은 나중으로 미루려한다. 도서에서 다루는 정책, 도메인, 수준 등의 단어의 명확한 기준이 아직 나에게는 없다고 생각이 들었기 때문이다. 클린 아키텍처는 지금까지 읽었던 개발 도서중 나에게 가장 많은 생각을 하게 했으며, 가장 많은 인사이트를 주었다는 것은 확실하다.

 

---

 

 

 

클린 아키텍처는 참 우연처럼 읽게 되었다. 1년 전 중고 서적을 판매하는 서점을 구경하던 나는 이 책을 클린 코드로 착각하고 실수로 구매했다. 집으로 돌아와 그제야 클린 아키텍처인 것을 확인했고, 그대로 책장에 꽂아놨다. 그렇게 1년이 지났다. 

 

나는 새로운 프로젝트에 헥사고날 아키텍처 구조를 적용하고 각 레이어를 Java 모듈로 구현하고자 했다. 여러 레퍼런스를 참고해서 처음엔 헥사고날 아키텍처를 모노리틱하게 구현하고 이를 여러 모듈로 리팩터링하는 작업을 거쳤다. 이 때 아키텍처의 존재를 희미하게 알게되었고, 공부할 가치가 충분히 있다고 판단했다. 마침 책장에 꽂혀있던 1년전에 구매한 클린 아키텍처가 눈에 띄었고, 그렇게 이 책을 일주일간 읽게 되었다. 

 

책의 내용이 내포하고 있는 의미를 완벽하게 이해하지 못한 부분도 더러 있다. 1년 혹은 2년 후 다시 읽으면서 나름의 경험을 바탕으로 책의 내용을 정리하려 한다.