클린 아키텍처, 소프트웨어 구조와 설계의 원칙을 읽어봤습니다

2024년 06월 23일 작성한 글을 옮겨왔습니다.

 

🧐 책을 읽게 된 이유

iOS 개발자로 성장해나가며 최근 가장 관심 있었던 주제는 단연 '아키텍처', 즉 구조 설계였다. 다른 사람들과 함께 협업하는 것, 어제의 나와 프로덕트를 만들어나가는 것, 개발자로서의 의미 모두 구조 설계라는 맥락으로 귀결됐고 배움의 필요성을 절실히 느끼게 되었다.

 

그러던 중 애플 아카데미 내 '클린 아키텍처 책 읽기' 스터디에 참여하게 되었고, 자연스레 책을 접하게 되었다. 꽤나 폭력적으로 생긴 표지(?)와 어렵다는 악명,, 을 뒤로하고 끝까지 읽을 수 있었던 이유는 함께 읽어서였던 것 같다. 열정적으로 서로의 생각을 나누고, 토론하며 성장해나감을 느꼈고 이 과정을 이끌어준 모수에게 감사 인사를 올린다!

 

🐰 느낀점 적어보기

처음 클린 아키텍처라는 단어를 들었을 때 나는 MVC, MVVM과 같은 아키텍처를 떠올렸다. 하지만 책을 모두 읽고 이제는 확실히 이야기할 수 있어졌다. 클린 아키텍처는 MVC와 MVVM과 같이 정형화된 아키텍처를 이야기하지 않는다. (사실 이 부분에 대해서는 이견이 있을 수도 있는데, 위 두 아키텍처도 사용하는 방식이 다양하기 때문이다. 하지만 내가 집중해서 말하고자 하는 것은 Model, View, Controller와 같은 명확한 기준점을 제시하지 않는다는 뜻이다.)

 

그럼 클린 아키텍처는 무엇일까? 클린 아키텍처를 검색하면 등장하는 이미지에서 크게 4가지 레이어로 분리하는 것으로 설명할 수 있을까? 나는 꼭 그렇지 않다고 느꼈다. 내가 이해한 클린 아키텍처의 핵심은 다음과 같다.

 

의존성의 방향은 저수준에서 고수준을 바라봐야 한다는 것이다. 저수준이라 함은 세부사항 즉 UI, Framework, DB 혹은 iOS 개발자의 입장에서는 백엔드 팀이 전달해 주는 API 사용을 위한 DTO와 같은 외부 요인들이다. 이들은 변화되기 쉽다.(변화될 수밖에 없는 것들이기도 하다)

 

고수준이라 함은 핵심 업무 규칙 즉 도메인, 유스케이스, 엔티티와 같은 것들이다. 이 단어들을 말로 풀어보자면 개발팀이 아니어도 이야기할 수 있는 것들이고, 바뀌어서는 안되는 핵심적인 것들도 포함되어 있다. (인스타그램에서 사진을 업로드하고 이를 피드에 업로드하는 것은 팀 모두가 함께 결정한 사항이었을 것이다. 반대로 그게 어떻게 구현되는지는 개발팀이 아니라면 함께 결정하지 않아도 된다. 또한 인스타그램의 운영 방식이 180도 바뀌는 게 아닌 이상 해당 업무 규칙은 변화되지 않을 것이다) 이들은 저수준과 비교해 상대적으로 변화되기 어렵다.

 

소프트웨어는 왜 소프트웨어인가? 하드웨어와 소프트웨어의 가장 큰 차이점은 '변화'에 있다. 하드웨어는 한번 공장에서 생산되어 나오면 다시 변화되기 매우 어렵다. 소프트웨어는 어떤가? 말 그대로 부드럽고 유연하게 변화가 가능하다. 즉, 소프트웨어의 본질은 변화에 있는 것이다.

 

그럼 우리는 자연스레 변화하기 쉬운 것(저수준)들이 변화하기 어려운 것(고수준) 들에 의존해야 할 것임을 짐작할 수 있다. 소프트웨어는 변화하기 때문이다! 고수준이 저수준을 바라보고 있거나 이들이 서로를 바라보고 있는 상황을 상상해 보자. 디자인 팀에서 UI 변경을 요청했는데 우리가 건드려야 할 곳이 깊은 고수준 규칙들인 상황과 기획 팀에서 새로운 기능 추가 요청을 했는데 강하게 결합되어 어디를 건드려야 할지 모르는 상황들 말이다.

 

소프트웨어 개발자는 이러한 변화의 비용을 관리해야 할 책임이 있다. 작은 변화 하나에도 한숨을 쉬며 코드를 바라보는 일은 없어야 한다는 것이다.

 

결국 다시 돌아와 나는 의존성의 방향이 저수준에서 고수준을 향할 수 있는 설계가 클린 아키텍처의 핵심이고, 이는 레이어의 개수와는 무관할 것이라 생각한다. 레이어의 개수는 이를 얼마나 더 명확하게 가져가야 하는가의 문제이지, 모든 곳에서 적용할 수 있는 일관된 것은 아니라 생각하기 때문이다. (아키텍처 설계의 비용에 대해서도 생각해 봐야 하는 문제이다)

 

마지막으로 클린 아키텍처를 공부하며 새롭게 안 사실 중 한 가지는 아키텍처를 바라보는 사람들의 시각에 의구심이 섞여있을 때가 많다는 것이다. 여러 가지 이유로 필요성에 대해 의구심을 품곤 하는 데 대개 설계 비용, 러닝 커브, 팀원 간의 설득, 구현 자체에 초점 등이 있다.

아키텍처는 절대적이지 않다. 어느 유명한 아키텍쳐를 우리의 프로덕트에 적용한다고 해도 들어맞지 않을 수밖에 없을 것이다.

 

결국 우리는 탐구해야 한다. 우리 프로덕트가 진정으로 전달하고자 하는 요구사항이 무엇인지, 어떤 변화를 일으킬 수 있는지 끝없이 고민해 우리만의 아키텍처를 만들어나갈 때 비로소 그 진가를 확인할 수 있을 것이다.

 

소프트웨어 개발자로서 이러한 탐구를 하지 않는다면 프로덕트에서 개발자가 가져야 할 책임은 구현 그뿐일 것이다. 나는 그렇게 생각하지 않는다. 더 많은 책임을 가지고 오기 위해 투쟁해야 한다.

 

저자는 이렇게 말한다. "아키텍처는 종착지가 아니라 여정에 더 가까우며, 고정된 산출물이 아니라 계속된 탐구과정에 더 가까움을 이해해야 한다."

 

개발자로서의 의미를 견고하게 가져갈 수 있었던 시간이었다!(아직 부족한 부분이 많아 기회가 된다면,,, 다회독을 해보려 한다!)