소개
클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다.
설계와 아키텍처란?
설계(design)와 아키텍처(architecture)는 어떤 차이가 있는가?
아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬때 사용 된다.
반면, 설계는 저수준의 구조 또는 결정사항 등을 의미 할 때가 많다.
소프트웨어 설계에서 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 이 둘은 단절 없이 이어진 직물과 같으며, 이를 통해 대상 시스템의 구조를 정의한다.
개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계가 뚜렿하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐이다.
목표는?
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.
설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 다름없다.
새로운 기능을 출시할 때 마다 비용이 증가한다면 나쁜 설계다.
사례 연구
어떤 회사를 예를 들어 설명하면 아래의 그래프와 같이 직원의 수가 증가하는 것을 볼 수 있다.
엔지니어링 직원 수의 증가 추이
그럼 이 회사는 성공했다고 할 수 있는가?? 이제 같은 기간 회사의 생산성을 보자. 생산성은 단순히 코드 라인 수로만 측정 했다.
동일한 기간의 생산성
동일한 기간의 코드 라인당 비용
위 두 그래프를 보면 개발자의 수는 증가하였지만 생산성을 현저히 떨어진다. 왜 8번째 출시한 제품의 코드는 처음 제품보다 40배나 많은 비용이 드는가?
엉망진창이 되어 가는 신호
출시별 생산성
시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면, 파국으로 치닫는 이비용 곡선에 올라타게 된다.
경영자의 시각
출시별 월 인건비
첫 번째 출시와 여덟 번째 출시의 월 인건비가 굉장히 증가한 것을 볼 수 있다.
무엇이 잘 못되었을까? 생산성이 믿기 힘들 정도로 낮아진 원인은 무엇인가?
무엇이 잘못되었나?
개발자들은 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!”라는 흔해 빠진 거짓말에 속는다.
개발자는 자신이 생상성을 유지할 수 있다고 자신의 능력을 과신한다. 하지만 엉망진창인 코드가 서서히 쌓이면 개발자 생산성은 차츰 낮아지고, 코드는 결국 엉망이 된다.
개발자가 속는 더 잘못된 거짓말은 “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.”는 견해다.
이 거짓말을 받아 드린 개발자는 나중에 기회가 되면 엉망인 코드를 정리 할 수 있다고 자신의 능력을 과신하게 된다.
이터레이션별 걸린 시간과 TDD 적용 여부
위 그래프는 제이슨 고먼(Json Gorman)이 수행한 실헝으로 TDD(테스트 주도 개발)를 했을 때 학습 곡선이 뚜렿하게 나타나는 것을 볼 수 있다.
TDD를 적용한 날이 적용하지 않은 날보다 대략 10% 빠르게 작업이 완성되었고, 심지어 TDD를 적용한 날 중 가장 느렸던 날이 TDD를 적용하지 않고 가장 빨리 작업한 날보다 더 빨랐다.
위 결과가 나올 수 있는 이유는 소프트웨어 개발의 단순한 진리를 알기 때문이다.
빨리 가는 유일한 방법은 제대로 가는 것이다.
자신을 과신한다면 재설계를 하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.
결론
소프트웨어 아키텍처를 심각하게 고려할 수 있으려면 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.
비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 이러한 결과로 이끌어 줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.