[클린 아키텍처] 1장 설계와 아키텍처란? & 2장 두 가지 가치에 대한 이야기

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

---

설계(design) 와 아키텍처(architecture) 사이에 차이가 있을까?

결론부터, 전체 설계의 구성요소로 보면 설계와 아키텍처 모두 필요하기때문에 구분지을 필요가 없다.

아키텍처는 고수준의 구조, 설계는 저수준의 세부사항이라고 정의되어 있지만..

실제로 집을 지을때나 소프트웨어를 설계할때 아키텍처와 설계는 개별적으로 존재할 수 없기 때문이다.

 

좋은 소프트웨어 설계의 목표는?

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

새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계이다. 

 

엉망진창이 되어 가는 신호

특정 사례를 통해 직원이 많아지지만, 코드 생산성은 그대로라면 각자의 생산성은 떨어지는 것을 보여준다.

시스템을 급하게 만들거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면 생산성이 떨어지게 된다.

각자는 열심히 시간을 투자해서 일하지만.. 엉망이 된 코드를 대처하는데 소모될 뿐이다.

 

무엇이 잘못되었나?

토끼와 거북이 우화에 개발자의 모습을 비유 👀 

토끼 개발자 = 뼈 빠지게 일하지만, 설계의 중요성을 알고있는 뇌는 잠들어 있는 개발자. 생산성을 유지할 수 있다고 과신한다.

거북이 개발자 = 좋은 소프트웨어 아키텍처가 무엇인지 이해하고, 좋은 설계와 아키텍처를 가진 시스템을 만드는 개발자

 

당장 시장에 출시하는데 바빠 토끼 개발자는 "코드는 나중에 정리하면 돼!" 라고 말하지만, 그렇게 말하는 개발자는 코드를 정리하지 않는다. ..  "엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다" 를 기억하자.

처음부터 전체 시스템을 재설계하는 것은 해결책이 아니다. 자신을 과신한다면 똑같이 유지보수에 엉망인 코드를 작성하게 된다.

 

결론

개발 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이 중요하다.

소프트웨어 아키텍처의 품질을 고민하기 위해서는 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.

비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 그러한 시스템 아키텍처의 속성을 알아야 한다.

=> 이 책에서는 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지 설명하고, 개발자가 장기간에 걸쳐 수익을 창출하는 시스템을 만들 수 있게 한다.

 

 

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

---

소프트웨어 시스템은 서로 다른 두 가지 가치 "행위(behavior)와 구조(structure)"를 제공한다.

 

행위 (기능)

소프트웨어의 첫 번째 가치, 행위는 기능 명세서나 요구사항 문서 구체화를 돕고, 요구사항을 만족하도록 코드를 작성하는 것이다. 

대부분 기능을 구현하고 버그를 수정하는 일이 자신이 해야할 일의 전부라고 생각한다. 

 

아키텍처 (구조)

소프트웨어는 soft + ware 의 합성어로, 기계의 행위를 쉽게 변경할 수 있도록 하기 위해 만들어진 것이다.

소프트웨어가 가진 본연의 목적을 추구하려면 부드러워야한다. 즉 소프트웨어는 변경하기 쉬워야 한다.

 

변경사항을 적용하는데 드는 어려움은 변경되는 범위에 비례해야하며, 변경사항의 형태(shape)와는 관련이 없어야 한다.

시스템의 형태와 요구사항의 형태가 서로 맞지 않는 경우에 개발자는 변경사항을 적용하기 어렵다고 생각한다.

소프트웨어 아키텍처는 특정 시스템에 맞춰져 특정 형태를 가진다면 변경하기 어려워진다.

소프트웨어 변경을 쉽고 실용적으로 하기위해서, 아키텍처는 형태에 독립적이어야한다.

 

행위와 아키텍처, 더 높은 가치는 무엇일까?

1 완벽하게 동작하지만 수정이 불가능한 프로그램 

-> 요구사항이 변경될 때 동작하지 않게 되고, 결국 돌아가도록 만들 수 없게 된다. 사실상 불가능은 없겠지만 변경에 드는 비용이 창출되는 수익을 초과하는 경우가 될것이다.

 

2 동작은 하지 않지만 변경이 쉬운 프로그램

=> 개발자는 프로그램을 동작하게 만들 수 있고, 변경사항이 발생하더라도 계속해서 유지보수할 수 있다. 앞으로도 유용하게 이용할 수 있다. 

 

현실적으로는.. 동작하지 않는다면 안되겠지만 👀  저자는 현재 동작여부보다 앞으로의 변경 가능한 시스템이 더 좋은 시스템이라고 말하고 있다.

 

아이젠하워 매트릭스

중요성과 긴급성에 관한 아이젠하워 매트릭스에 행위와 아키텍처를 적용해서 한번 더 아키텍처의 중요성을 언급한다. (작년에 인턴을 할 때 업무 우선순위 정하는 과정에서 봤던 매트릭스!!)

 

행위 = 긴급하지만, 매번 높은 중요도를 가지는 것은 아니다. 지금 당장 개발해야하는 기능.. 중요도는 매번 다르다.

아키텍처 = 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다. 유지보수 측면에서 필요한 리팩토링은 당장 수정하지 않아도 프로그램이 정상 동작하므로.. 긴급하진 않다 🥲

 

우선순위는 다음과 같다. "중요 & 긴급 > 중요 & 긴급X > 중요X & 긴급 >  중요X & 긴급X"

업무 관리자와 개발자는 세번째에 위치한 "중요하지 않지만 긴급한" 항목을 첫번째 우선순위로 생각하는 실수를 많이 저지른다.

"긴급하지만 중요하지 않은" 기능과 "긴급하면서 중요한" 기능을 구분하지 못한다.

=> 그렇기에 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 된다.

 

아키텍처를 위해 투쟁하라

소프트웨어 개발자는 소프트웨어를 안전하게 보호해야 할 책임이 있다. 효율적인 소프트웨어 개발팀은 아키텍처를 개선하기 위해 다른 팀과 투쟁해야한다.

아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 변경을 가하는 일이 현실적으로 불가능해진다. 이러한 상황이 용납되면, 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이다. 🥲

 

---

 

개인적인 생각

클린 아키텍처를 읽어보고 싶다는 생각은 했지만, 왜 클린 아키텍처를 읽어야 할까? 왜 설계를 잘 해야 할까? 를 생각할 수 있었던 챕터였다. 한 번 쓰고 버려지는 코드가 아닌, 계속해서 수정 가능한 소프트웨어를 개발하기 위해 설계부터 고민해야겠다.

그리고 이전에 작성된 코드를 어떻게하면 더 소프트하게 변경할 수 있을지도 고민해야겠다.

"소프트웨어는 변경하기 쉬워야 한다."