Clean Architecture : (1장) 소개 - 설계와 아키텍처란 ?

 프롬스의 SWDEVLAB 

설계와 아키텍처란?

설계와 아키텍처 사이에는 오랫동안 많은 혼란이 있었습니다. 두 사이에는 어떤 차이가 있는 것일까?

이 책의 목적은 이러한 혼란을 없애고, 설계와 아키텍처가 무엇인지를 완전하게 정의하는 것입니다.

우선 첫째로 주장하고 싶은 바는 둘 사이에는 차이가 없다는 것입니다. 아무런 차이가 없습니다.

 

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 사용하는 반면, 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많습니다. 하지만 아키텍처가 실제로 하는 일을 살펴보면 이러한 구분은 무의미합니다.

 

새로운 집을 설계하는 아키텍트가 있고 아키텍처를 살펴보면, 집의 형태, 외관, 입면도, 공간이나 방의 배치 등을 볼 수 있습니다. 그리고 자세히 살펴보면 도면에서 무수히 많은 세부사항도 볼 수가 있습니다. 콘센트, 전등 스위치, 전등의 위치에 대한 정보 그리고 기초 공사는 어떻게 진행될지도 볼 수 있습니다. 다시 말해, 모든 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있습니다.

 

소프트웨어 설계도 마찬가지 입니다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소 입니다. 이 둘을 구분짓는 경계는 뚜렷하지 않습니다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐입니다.

 

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

 

사례 연구

약 10명이 안되던 회사는 8번째 제품을 출시할 때, 인원이 약 1,200명이 되었습니다. 이 추세만 보면 엄청나게 회사가 성장한 것으로 보입니다..

그리고 출시된 제품의 코드라인으로 생산성의 지표로 삼았을 때, 첫 제품이 3천 라인이었지만 8번째 제품은 7천 라인밖에 안되는 제품이였습니다. 첫 제품의 라인당 비용이 10이라고 했을 때, 8번째 제품의 라인당 비용은 350까지 높아져 버린 것입니다.

 

결국 이러한 비용 곡선은 사업 모델의 수익성을 엄청나게 고갈시키며, 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 만들어버릴 것입니다.

 

- 엉망 진창이 되어가는 신호

그렇다고 어떤 개발자는 열심히 하고, 어떤 개발자는 놀던 것이 아닙니다. 모두 열심히 개발했음에도 이러한 사실을 알게 된 그들은 절망에 빠집니다. 엉망이 된 현재 상황에 대처하는데 소모되는 시간은 점점 늘어만 갑니다. 결국 개발자들의 노력의 가치는 보잘것없게 되어버립니다. 

 

- 경영자의 시각

나빠지는 상황속에 경영자는 월별 인건비를 살펴보게 됩니다. 첫번째 제품은 월별 수십만 달러의 인건비만 제품에 전달하면 되었지만, 8번째 제품은 월별 2천만 달러가 초과하게 되어버리고, 얻은 것도 없게 되어버립니다. CFO는 당장 조치를 취해야 한다고 생각할 것입니다.

어떤 조치를 취해야 할까? 무엇이 잘못됬지? 생산성이 낮아진 원인은 무엇이지? 개발자를 향해 고함을 외치는 것 말고 무슨일을 할 수 있지? 라고 생각할 것입니다.

 

- 무엇이 잘못되었나?

약 2600년 전 이솝(Aesop)은 토끼와 거북이 우화를 지었습니다. 그리고 교훈은 다양한 형태로 언명되어 왔습니다.

• 느려도 꾸준하면 이긴다.
• 발 빠른 자가 경주에 이기는 것도 아니며, 힘센 자가 싸움에서 이기는 것도 아니다.
• 급할수록 돌아가라

이 우화 자체는 지나친 과신을 가진 어리석음을 말해줍니다. 현대의 개발자도 이와 비슷한 경주를 합니다. 그렇다고 개발자가 잠을 자고 있는 것은 아니고, 오히려 뼈 빠지게 일하고 있습니다. 하지만 뇌는 잠에 취해 있습니다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있는 것입니다.

 

개발자는 "코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!" 라는 거짓말에 속아버립니다. 결국 엉망진창이 되고 생산성이 0으로 수렴하게 되어버립니다. 이는 시간문제입니다.

더 잘못된 거짓말은 "지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다"라는 견해입니다. 나중에 기회가되면 엉망이 된 코드를 정리하는 태세로 전환할 수 있다고 자신의 능력을 과신하게 됩니다.

 

코드를 깔끔하게 유지하는 잘 알려진 수련법 중 하나인 테스트 주도 개발(TDD)를 적용하여 개발을 할 때와 그렇지 않을 때 생산성을 비교해 보았습니다. 프로그램은 정수를 로마 숫자로 변환하는 단순한 것이었습니다. 결과는 TDD가 더 빨랐습니다.

 

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

 

이를 깨닫고 처음부터 다시 설계를 한다면 결과가 달라질까요?

토끼가 다시 경주하면 이길 수 있다고 생각하는 것과 같습니다. 자신을 과신하고 있다면, 다시 설계를 수행해도 결과는 똑같을 것입니다.

 

결론

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

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

 

관련글

이전글 : Clean Architecture : 서론
다음글 : Clean Architecture : (2장) 소개 - 두 가지 가치에 대한 이야기

 

내용이 도움이 되셨으면 공감 버튼 꼬옥 눌러주세요 ♥
본문을 퍼가실 경우 댓글을 달아주세요 ★