[Architecture] 클린 아키텍처 - 소프트웨어 구조와 설계 원칙 1부 : 소개

 

 

​

​

​

​

​

​

​

​

​

​

​

개발자들 사이에서 밥아저씨라고 불리우는 로버트 C 마틴이 작성한

유연하고 유지보수에 용이한 소프트웨어 아키텍처를 설계하는 방법들에 대한 내용을 다룬 책이다.

​

그는 <클린 코드>, <클린 코더>, <클린 소프트웨어> 와 같이 클린 ** 시리즈 책들의 저자이다.

​

​

개발자들이라면 꼭 한번 들어봤을 법 하고, 읽어볼만한 책으로 흔히 추천되는 책인데,

<클린 코드>와 함께 예전에 구매해놓고 읽다가 구석에 방치해두고 있었던 책이였다.

​

당시 "그래 이런 내용이구나~" 하고 읽고 지나갔던 내용들이라,

요즘 리팩토링 업무 고민을 하던 중, 책을 통해 답을 다시 찾을 수 있을 것 같아, 다시 이 책을 꺼내 들었다.

​

​

​

​

​

​

​

최근 레거시 코드를 이관하면서 향후의 비즈니스 로직의 변경에 유연한 구조로 재정비 하기 위한 고민을 많이 하기 시작했다.

​

​

주문 시스템에서 꽤 유사해보이는 두 가지 기능의 전체적인 flow는 비슷한데,

비즈니스 정책에 따라서 다르게 가져 가야할 부분들이 존재하여

​

두 기능의 공통 관심사는 어떻게 모을 것이며,

또한 향후 각각의 변경 가능성을 열어두려면

적절한 두 도메인과 기능의 책임을 어떻게 분리해야할지에 대한 고민에 빠졌다.

​

​

두 핵심 기능의 공통 속성들과 비즈니스 로직을 한곳에 모으는 것 <-> 향후 변경 가능성을 위해 독립적으로 책임을 분배하는 것.

이 두가지 사이에서 절충안을 찾기에 깊은 고민과 답이 필요했다.

​

​

TDD와 OOP, DDD와 관련한 스터디와 교육도 마침 전에 들어왔던 지라,

종합적으로 이를 업무에 어떻게 녹여낼지 고민하면서,

이 책은 또한 좀 더 기초를 다듬고, 근본적인 해답을 얻을수 있지 않을까 생각이 들었다.

​

​

​

​

​

​

또한

업무 상 여러 인입점에서 들어오는 (쇼핑하기, 선물하기) 주문플랫폼의 코드를 유지보수해야하기 때문에,

공통 주문 데이터를 처리한다고 해도,

분기점도 많고 인입점별로 도메인 매핑을 다르게 가져가야하는 사항들이 많았다.

 

그리고 주문 플랫폼이기 때문에

주문과 관련된 많은 서비스들을

요청하여 데이터에 활용하고 있고, 그만큼 복잡도도 어마어마하다.

​

​

비즈니스가 복잡하고, 기능, 도메인 간 강하게 결합 되어있는 상황에서,

잘못설계된 아키텍처를 계속 유지보수하며 변경사항을 적용하는 일이란 정말 스트레스 받는 일이다.

​

​

​

​

따라서 위와 같이

다양한 인입점에 따른 복잡한 분기처리,

높은 복잡도,

각기 다른 비즈니스 정책,

다양한 서비스들과의 상호작용을 코드에 적용하려면

​

​

​

기능과 도메인간 책임과 경계를 명확히 하고,

복잡도를 쉽게 아키텍처 측면에서 풀어내어야 한다는 필요성을 느꼈다.

​

또한 향후 꾸준히 변경해가는 비즈니스에 유연하게 대응할 수 있는 소프트웨어 아키텍처의 필요성도 요구되었다.

​

그렇게 몇년 커머스 도메인 업무를 하면서 아키텍처의 중요성을 몸소 깨달았다.

​

​

​

22년의 마지막 프로젝트도 잘 마무리 지었겠다,

23년엔 그동안 잘 챙기지 못했던 리팩토링 업무를 틈틈이 챙기기 위해

이 책과 같은 아키텍처 관련 스킬들을 정리하여 구체화 해보려고 한다.

​

---

​

​

​

​

​

무튼 서론이 길었고, 이 책에 대한 포스팅을 시리즈로 작성해보려고 한다.

(부디 작심삼일이 되지 않길.....,)

​

​

​

​

​

책의 구성은 총 6부로 구성되어 있고, 각 부에는 N개의 소주제로 다시 나누어진다.

​

​

​

1부 - 간략한 설계와 아키텍처에 대한 소개

2부 - 프로그래밍 패러다임 3가지 (구조적 프로그래밍, 객체지향 프로그래밍, 함수형 프로그래밍)

3부 - 객체지향의 설계원칙인 SOLID에 대한 각각의 설명

4부 - "컴포넌트"의 원칙과 응집도, 결합에 대한 설명

5부 - 아키텍처 설계시 고려해야할 주요 개념들을 소개

6부 - 그외 부가적인 세부사항 (데이터베이스, 웹, 프레임워크) 등에 대한 설명

​

(7장도 있지만 부록에 대한 이야기임.)

​

​

​

이 포스팅은 프롤로그 및 1부에 대한 소개를 한다.

후에 시리즈로 각 부 별로 책의 핵심 내용과 필요하다면 실습 코드를 추가할 예정이고,

4부의 세부주제는 굉장히 많아서 (아마도) 쪼개서 포스팅을 할 예정이다.

.

​

​

 

---

서문과 소개

​

​

글쓴이는 반세기 이상 코드를 작성하는 일을 하면서,

소프트웨어 시스템을 구조화하는 방법을 몇가지 배웠다.

​

수많은 앱과 시스템을 구축하면서 그가 깨달은 바는

아키텍처의 규칙은 동일하다!

라고 한다.

​

​

예전의 소프트웨어나, 현재의 소프트웨어는 전체적인 맥락은 비슷하다.

즉 현재의 소프트웨어는 과거와 동일한 것들로 구성된다.

​

코드들은 여전히 순차, 분기, 반복의 집합체일 뿐이다.

언어는 지속적으로 발전했지만,

컴퓨터 프로그래밍을 이루는 기본 구성요소는 조금도 바뀌지 않았다.

​

​

이처럼 코드가 변하지 않았다는 사실이 시스템의 종류와 관계없이

소프트웨어 아키텍처의 규칙이 일관된 이유이다.

​

​

소프트웨어 아키텍처 규칙이란,

프로그램의 구성요소를 정렬하고 조립하는 방법에 대한 규칙이다.

​

그리고 이 책은, 이 세월이 흘러도 변하지 않는 그 규칙들에 대해 다룬다.

​

​

코드를 단순히 짜는 일, 즉 프로그램이 동작하는데 까지 만드는 것은

엄청난 수준의 지식과 기술이 필요하진 않다.

​

하지만 프로그램을 제대로 만드는 일은 전혀 다르다.

소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하며,

사고력과 통찰력을 갖춰야 하지만 대다수의 프로그래머들은 시간을 들여 이러한 능력을 개발하지 않는다.

​

​

소프트웨어를 올바르게 만드려면,

무엇보다도 기술을 향한 열정과 전문가가 되려는 열망이 필수다.

​

​

​

제대로 된 소프트웨어를 만들면,

아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다.

변경은 단순해지고 빠르게 반영할 수 있다.

결함은 적어지고, 최소한의 노력으로 기능와 유연성을 최대화 할 수 있다.

​

결국 훌륭한 소프트웨어 아키텍처는 시스템, 프로젝트, 팀에 놀라운 효과를 가져다준다.

​

​

​

​

​

이 책의 서론만 읽어도 지난간 마주한 나의 고민을 그대로 꼬집었다.

​

서로 강하게 연관되어 있고 복잡하게 결합되어서,

아주 사소한 변경에도 몇 주가 걸릴 뿐 아니라 큰 위험을 감수하지는 않았나?

잘못된 코드와 끔찍한 설계를 인해 방해를 받지 않았나?

시스텡믜 설계가 팀의 사기를 떨어뜨리고 관리자의 인내심을 시험하는 (ㅋㅋㅋ)

부정적인 영향을 끼치지는 않았나?

​

​

복잡하게 기능들과 도메인들이 얽힌, 잘못 짜여진 아키텍처를 유지보수하기 위해서는,

향후 비즈니스 변경요청이 올 때마다,

정확히 어디 어디 코드를 고쳐야하는지, 코드를 고칠때 다른 기능들에 대한 영향도는 없는지

항상 유지보수를 하던 담당자들이 기억을 하고 있어야하고 변경 요청이 올때마다 누락된 곳은 없는지

기존 기능은 정상동작하는지, 추가 기능도 정상 동작하는지, 다른 기능도 혹시 변경에 영향도가 있는지 테스트해야 한다.

​

심지어 팀에 새로운 팀원이 들어온다면, 위와같은 복잡한 상황들을 그대로 신입 팀원에세 인수인계를 해줘야한다.

​

코드는 복잡해지고, 복잡하게 기능이 얽혀있다보니 테스트도 복잡해지고,

다른 기능들과의 영향도도 얽혀서 다른 기능까지 검증해야하고,

너무 복잡한 경우엔 심지어 구조를 변경하려는 노력보다 주석으로 설명까지 달아놓는다.

​

구조를 변경하지 않고, 계속 변화에 대한 요구사항을 기존 잘못된 구조에 덧붙일 수록

위와 같은 상황은 악순환된다.

​

​

이러한 상황에서 이 책에서 말한 그 "규칙"들은 위와 같은 지옥에서 벗어날수 있는 구조적 리팩토링에 대한 해답을 줄 수 있을 것이다.

​

​

​

​

---

1장. 설계와 아키텍처란?

​

​

​

​

​

https://www.ndesconstruction.com/images/architecture-design/1.jpg

​

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되고,

설계는 저수준의 수조 또는 결정사항 등을 의미할 때가 많다.

​

하지만 아키텍츠가 실제로 하는일을 보면 이런 구분은 무의미하며 둘의 차이는 없다.

​

소프트웨어 설계에서,

저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소이다.

이 둘은 단절없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다.

​

​

소프트웨어 아키텍처의 목표는?

필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.

​

​

​

​

엉망진창이 되어가는 신호

​

전력을 기울이지 않는 개발자는 없다.

개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작한다.

​

심지어 사소한 기능을 추가하는 일도 그저 엉망이 된 코드를

이곳에서 저곳으로, 다시 다음 곳으로 이동하는 반복작업으로 변경된다.

​

​

무엇이 잘못되었나?

현대의 대다수 개발자는 뼈빠지게 일한다.

하지만 그들의 뇌는 잠에 취해 있다.

훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다.

​

"코드는 나중에 정리하면 돼, 당장은 시장에 출시하는 게 먼저야!"

라는 흔해 빠진 거짓말에 속는다.

​

결국 개발자는 절대로 태세를 전환하지 않는다.

이전에 작성한 코드로 돌아가 정리하는 일은 일어나지 않는데,

바로 다음에 만들어야 할 새로운 기능이 기다리고 있고, 다음 기능, 또 다음 기능, 또 다음 기능이 계속 기다리고 있다.

​

​

이 부분은 정말 공감한다.

특히 커머스, 주문 도메인이라 그런지 사업과 기획에서 추진하려는 프로젝트가 정말 줄줄이 밀려있고,

타사의 커머스의 기능들을 따라 잡기 위해 끊임 없이 개선 과제가 밀려있는 듯 하다.

이 상황에서 항상 개발팀에서는 인력 문제가 생긴다.

​

그러다 보니 리팩토링, 개선 업무에 대한 우선순위는 점점 밀리게 되고,

레거시 아키텍처에서의 코드 수정만 계속 반복될 뿐이다.

​

​

결국 저자는 엉망으로 만들면, 깔끔하게 유지될 때보다 항상 더 느리다고 한다.

​

TDD를 예시로 들면,

TDD를 적용한 날이 적용하지 않은 날보다 대략 10% 빠르게 작업이 완성되었고,

심지어 TDD를 적용한 날중 가장 느렸던 날이

TDD를 적용하지 않고 가장 빨리 작업한 날보다도 더 빨랐다는 그래프를 예시로 든다.

​

​

빨리 가는 유일한 방법은 제대로 가는 것이다.

​

​

개발자로 하여금 토끼처럼 과신하려는 믿음을 버리고,

만들어 낸 엉망진창인 코드를 개발자가 책임지도록 하는 것 뿐이다.

​

​

​

소프트웨어 아키텍처를 심각하게 고려할 수 있으려면,

좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

​

비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면,

이러한 결과로 이끌어 줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

​

​

이 책은 바로 이 속성들에 대한 내용을 다룰 예정이다.

​

​

​

​

---

​

​

2장. 두 가지 가치에 대한 이야기

​

​

​

모든 소프트웨어 시스텡믄 이해관계자에게 서로 다른 두 가치 가치를 제공한다.

행위와 구조.

​

소프트웨어 개발자는 두 가치를 모두 반드시 높에 유지해야 하는 책임을 진다.

​

하지만 불행하게도,

개발자는 한 가지 가치에만 집중하고

나머지 가치는 배제하곤 한다.

​

더 안타까운 일은,

대체로 개발자가 둘 중 덜 중요한 가치에 집중하여

결국에는 소프트웨어 시스템이 쓸모없게 된다는 사실이다.

​

​

​

​

​

​

​

행위

기계가 요구사항을 만족하도록 코드를 작성한다.

기계가 요구사항을 위반하면, 디버거를 열고 문제를 괸다.

​

많은 프로그래머가 이러한 활동이 자신이 해야 할 일의 전부라고 생각한다.

​

​

​

​

​

아키텍처

​

소프트웨어라는 단어는 "Soft" 부드러운 과, "ware" 제품이라는 단어의 합성어이다.

소프트웨어는 즉 부드러움을 지니도록 만들어졌다.

소프트웨어를 만든 이유는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서이다.

​

​

소프트웨어가 가진 본연의 목적을 추구하려면,

소프트웨어는 반드시 부드러워야 한다.

다시 말해 변경하기 쉬워야 한다.

​

이해관계자가 기능에 대한 생각을 바꾸면,

이러한 변경사항을 간단하고 쉽게 적용할 수 있어야 한다.

​

소프트웨어의 개발 비용 증가의 주원인은 바로 이 변경사항의 범위와 형태의 차이에 있다.

​

​

새로운 요청사항이 발생할 때마다

바로 이전의 변경사항을 적용하는 것보다 조금 더 힘들어지는데,

시스템의 형태와 요구사항의 형태가 서로 맞지 않기 때문이다.

​

​

아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록,

새로운 기능을 이 구조에 맞추는게 더 힘들어진다.

따라서 아키텍처는 형태에 독립적이여야 하고, 그럴수록 더 실용적이다.

​

​

​

​

​

결국 저자는 아키텍처를 위해 투쟁해야한다고 말한다.

기능의 긴급성이 아닌, 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 한다.

​

아키텍처가 후순위가 되면,

시스템을 개발하는 비용이 더 많이 들고,

일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다.

​

​

​

​

​

​

​

​

​

---

​

​

​

이렇게 1장에서는 시스템 아키텍처의 중요성에 대해 수차례 강조한다.

​

결국 잘못된 아키텍처를 유지한다는 것은 결국 생산성과 개발 비용을 증가시킬 것이며,

​

개발자는 훌륭한 아키텍처를 만들어야한다는 책임을 져야 하고,

그러한 업무를 우선순위로 두기 위해 투쟁해야한다고 강조한다.

​

항상 기능 구현에 대한 업무에만 치중하지 말고,

결국 더 빨리 가기 위해서는 제대로 가는 것 (훌륭한 아키텍처가 근본이 되어야 한다는 것)임을

​

개발자들은 마음속에 새기면서 업무를 대해야 한다.

​

​

​

​

​

​

​

​

​

다음 2부에서는 프로그래밍 패러다임 3가지를 소개할 예정이다.

1부 내용에 대한 포스팅은 여기까지!

​

​

​

​

​

#클린아키텍처 #cleanArchitecture #로버트마틴 #UncleBob #소프트웨어아키텍처