로버트 C. 마틴의 클린 아키텍처: 소프트웨어 구조와 설계의 원칙을 읽으며 기록하고 싶은 부분만 발췌해 각색하여 작성한 글입니다. 하여 실제 글쓴이의 의도와 다르게 작성될 수 있음을 알립니다.
'아키텍처'는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면, '설계'는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만 실제로 이러한 구분은 무의미하다. 모든 고수준의 결정사항에는 그를 지탱하는 세부사항이 존재한다. 저수준의 세부사항과 고수준의 결정사항은 전체 설계의 구성 요소가 된다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.
그렇다면 이러한 의사결정의 목표는? 좋은 소프트웨어 설계의 목표는?
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.
설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름없다. 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계라고 말할 수 있다. 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계다. 좋은 설계란 이처럼 단순명료하다.
이솝 우화 중 토끼와 거북이의 교훈은 다양한 형태로 언명되어 왔다.
- "느려도 꾸준하면 이긴다."
- "발 빠른 자가 경주에 이기는 것도 아니며, 힘센 자가 싸움에서 이기는 것도 아니다."
- "급할수록 돌아가라."
토끼는 타고난 빠르기를 과신한 나머지, 경주를 심각하게 받아들이지 않아 낮잠을 자버리고, 그사이 거북이는 결승선을 통과한다.
현대의 개발자도 이와 비슷한 경주를 하며, 토끼와 유사한 과신을 드러낸다. 물론 개발자가 잠을 자는 것은 아니다. 오히려 정반대로, 현대의 대다수 개발자는 눈이 빠지게 일한다. 하지만 그들의 뇌가 잠에 취해 있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠을 자고 있다.
이런 개발자는 흔히 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!"라는 말로 자신을 속인다. 이런 경우 나중에 코드를 정리하는 일은 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다. '시장 출시가 먼저'라는 생각을 하는 이유는 바로 뒤에 여러 무리의 경쟁자가 뒤쫓고 있고, 경쟁자보다 앞서 가려면 가능한 한 빠르게 달려야 하기 때문이다.
그러나 개발자는 절대로 태세를 전환하지 않는다. 이전에 작성한 코드로 돌아가 정리하는 일은 일어나지 않는데, 바로 다음에 만들어야 할 새 기능들이 기다리고 있고, 다음 기능, 또 다음 기능, 또 다음 기능이 계속 기다리고 있기 때문이다. 결국 엉망진창 되고, 생산성은 0에 수렴하기 시작한다.
그러나 소프트웨어는, 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 빨리 가는 유일한 방법은 제대로 가는 것이다.
그리고 이 진실이 경영자의 딜레마에 대한 해답이다. 생산성이 감소되고 비용이 증가하는 현상을 되돌릴 수 있는 유일한 방법은 개발자로 하여금 토끼처럼 과신하려는 믿음을 버리고, 만들어 낸 엉망진창인 코드를 개발자가 책임지도록 하는 것뿐이다.
개발자는 처음부터 다시 시작해 전체 시스템을 재설계하는 것이 해답이라고 생각할 수도 있는데, 이 생각 또한 토끼의 말과 다름없다. 엉망으로 내몰았던 바로 그 과신이 경주를 다시 시작한다면 더 나은 코드를 만들 수 있다고 말하고 있는 것이다. 자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.
어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.
소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다. 비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 이러한 결과로 이끌어 줄 시스템 아키텍처가 지닌 속성을 알아야 한다.
이 책은 바로 이 내용을 다룬다고 한다. 뭣도 모르고 다들 하니 하게됐던 MVVM에서, 내가 직접 알아보게 된 The Composable Architecture를 뜯어보며 사용해보니 이런 아키텍처는 어떤 사람이 어떤 설계 방식으로 어떻게, 왜 만드는지, 좋은 아키텍처는 무엇인지가 궁금해져서 이를 해소하고자 책을 샀다. 대학교 4학년때 스위프트 관련 책을 마지막으로 읽고 거의 일년만에 다시 책을 폈다. 30장이 조금 넘으니 하루 한 장씩 읽어 신년 1월 안에 완독하려고 한다. 인상깊은 내용들만 내 입맛대로 각색해 기록도 해보겠따.
끗 -
