Clean Architecture 스터디[1장]

1. 설계와 아키텍처란?

이 책의 목적 중 하나는, 설계와 아키텍처 사이의 혼란을 없애고, 설계와 아키텍처가 무엇인지를 완전하게 정의하는 것입니다. 결론부터 말씀 드리 자면 둘 사이의 차이점은 없다는 것입니다.

 

아키텍처

저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용된다

 

설계

저수준의 구조 또는 결정사항 등을 의미할 때가 많다.

 

집 설계 EX)

아키텍처 - 집의 형태, 외관, 입면도, 공간, 방의 배치 등 / 고수준의 결정사항

설계 - 콘센트, 전등 스위치, 전등의 위치 /  저수준의 세부사항

 

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

 

사례연구

[그림 1.1] 엔지니어링 직원 수의 증가 추이

어느 한 회사의 실제 데이터입니다. 

엔지니어링 수가 증가하면서 성공을 이뤄냈음을 알 수 있는 그래프입니다.

 

[그림 1.2] 동일한 기간의 생산성

동일한 기간 동안 회사의 생산성입니다. 단순 코드 라인 수로 측정했을 때입니다.

매번 기능을 출시할 때마다 개발자의 수는 증가했지만, 코드 생산성은 고정돼 있는 것처럼 보입니다.

[그림 1.3] 동일한 기간의 코드 라인당 비용

여러분은 지금 생산성은 크게 달라지지 않았지만, 개발자의 수가 늘어나고, 코드 라인당 수가 늘어나 있는 기업의 그래프를 보고 계십니다. 이러한 그래프는 수익을 엄청나게 고갈시키며, 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 할 수 있습니다. 

 

엉망진창이 되어가는 신호

[그림 1.4] 출시별 생산성

이 비용 곡선은 개발자의 관점에서 보여줍니다. 개발자의 생산성은 100%로 시작했지만, 출시할 때마다 하락하고, 결국 바닥을 치고 맙니다. 개발자 입장에서 보면 야근을 하고, 열심히 만들었는데, 더 이상 진척이 없고, 기능을 개발하는 것보다는, 이전에 꼬여버린 코드를 수정하는 데 많은 시간을 허비하게 됩니다. 사소한 기능 하나를 추가하려 해도, 이곳저곳 손볼 곳이 많고, 개발자들이 쏟은 노력의 가치가 결국 보잘것없게 됩니다. 

 

경영자의 시각

[그림 1.5] 출시별 월 인건비

경영자의 시점으로 봤을 때는, 점점 인건비가 증가하는 것을 볼 수 있습니다. 8번째 출시를 했을 때는, 인건비만 높아졌지, 결국 얻은 것은 거의 없는 것을 볼 수 있습니다. 

 

무엇이 잘못되었나?

개발자들은 코드는 "나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!"라는 착각을 합니다. 기능을 배포를 해도, 시장의 압박은 절대로 줄지 않고, 시장 출시가 먼저라고 생각하는 기업들이 많기 때문에, 그보다 앞서 나가기 위해서 코드를 정리할 시간은 없어지고, 더욱더 지저분해지기 시작합니다.

엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다

 

느낀 점

저는 스타트업은 경쟁 속에서 살아남아야 하니, 출시를 먼저 하고, 나중에 자리를 잡게 되면 그때 코드 정리를 해야 한다는 생각이 박여있었습니다. 하지만 대부분의 스타트업에서는 이전에 작성한 코드를 배포를 하고 나면, 또 다음 개발해야 할 기능들이 쌓여있기 때문에 이전 코드를 되돌아볼 시간 따위는 존재하지 않았는 경우가 많습니다. 

 

이 책에서 ‘지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다.’라는 말을 한 적이 있습니다. 저는 이 말에 공감하게 되었습니다. 가끔씩 코드를 보면 코드와 기능의 조화가 어울리지 않을 때는 싹 갈아엎어야 하는 경우가 생길 때가 있습니다. 이렇게 엉망으로 만들게 되면 깔끔하게 유지할 때보다 개발 속도가 느려지게 된다는 것을 이번 장을 읽으면서 느끼게 되었습니다.