[클린 아키텍처] 1단원 1장 설계와 아키텍처란?

프로그램이 동작하도록 만드는 데 엄청난 수준의 지식과 기술이 필요하지는 않다. 프로그램을 동작하게 만들기는 그리 어려운 일이 아니기 때문이다.

하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하고 사고력과 통찰력을 갖춰야 한다.

좋은 설계와 아키텍처는 적은 인력으로 유지보수가 가능하게 해준다.

1장 설계와 아키텍처란?

먼저 말하자면 설계와 아키텍처는 아무런 차이가 없다.

‘아키텍처’는 고수준의 무언가를 가리킬때 흔히 사용되는 반면, ‘설계’는 저수준의 구조 또는 결정사항 등을 의미할때가 많다.

저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.

목표는?

좋은 소프트웨어 설계의 목표는 무엇일까?

소프트웨어 아키텍처의 목표는 팔요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는데 있다.

사례연구

지금 당장의 수익성은 중요하지 않다. 잘못된 설계로인한 가파른 비용 곡선(개발자당 생산성)은 사업 모델의 수익을 엄청나게 고갈시키며, 회사의 성장을 멈추게하거나 완전히 망하게 만든다.

엉망진창이 되어 가는 신호

가파른 비용 곡선이 발생한것은 엉망진창이 되어 가는 신호다.

시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면 파국으로 치닫는 이 비용 곡선에 올라타게 된다.

개발자가 초인적인 노력을 기울이고, 잔업을 하며, 헌신함에도 불구하고 더 이상 진척이 없는 상황에 처하게 된다. 개발의 노력은 기능 개발 보다는 엉망이 된 상황을 대처하는 데 소모되기 시작한다.

개발자들이 쏟은 노력의 가치가 결국 보잘것없게 된다.

경영자의 시각

출시를 하면 할 수록 엄청난 인건비가 나간다. 나간 인건비만큼 많은 기능을 탑재하면 다행이지만 오히려 얻은 게 거의 없다. 경영자는 이런 상황을 방지하기위해 당장 조치를 취해야한다고 할 것이다.

하지만 어떤 조치를 취해야하나, 그저 발을 동동 구르며 개발자를 향해 고함치는 일 외에, 경영자는 무슨 일을 할 수 있는가?

무엇이 잘못되었나?

토끼와 거북이라는 이야기가있다.

이 이야기는 지나친 과신이 가진 어리석음을 말해준다. 현대의 개발자도 이와 비슷한 경주를 하며, 토끼와 유사한 과신을 드러낸다. 물론 개발자가 잠을 자는것은 아니다. 오히려 뼈 빠지게 일한다. 하지만 그들의 뇌는 잠에 취해 있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고있는 그들의 뇌가 잠자고 있다.

개발자들은 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는게 먼저야!”라는 거짓말에 속는다. 이렇게 속아 넘어간 개발자라면 나중에 코드를 정리하는 경우는 한 번도 없는데, 시장의 압박은 절대로 수그러들지 않기 때문이다.

결국 개발자는 절대로 태세를 전환하지 않는다. 이전에 작성한 코드로 돌아가 정리하지 않는데, 바로 다음에 만들어야 할 새로운 기능이 기다리고있고, 다음, 또 다음이 계속 기다리고 있다. 결국 엉망진창이 되고, 생산성은 0을 향해 수렴하기 시작한다.

개발자가 속는 더 잘못된 거짓말은 “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.”라는 견해다. 진실은 다음과 같다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 시간 척도를 어떻게 보든지 관계없이.

제이슨 고먼이 수행한 실험에 따르면 TDD를 할때와 안할때의 작업속도는 첫째날부터 마지막날까지 항상 TDD가 빨랐다. TDD를 적용한 날 중 가장 느렸던날이 적용 안했을때의 가장빠른날보다 더 빨랐다.

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

이 진실이 경영자의 딜레마에 대한 해답이다. 개발자로 하여금 토끼처럼 과신하려는 믿음을 버리고, 만들어 낸 엉망진창인 코드를 개발자가 책임지도록 하는 것뿐이다.

개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모른다. 하지만 이 생각 또한 토끼의 말과 다음없다.

자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.

결론

어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.

심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다. 비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 이러한 결과로 이끌어줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.

참조

로버트 C. 마틴, 『클린 아키텍처』, 송준이 옮김, 인사이트(2020), P2-14.