[클린 아키텍처] 1부 1장. 설계와 아키텍처란?

1부. 1장 설계와 아키텍처란?

👩🏻‍💻 [클린 아키텍처 소프트웨어 구조와 설계의 원칙 - 로버트C.마틴] 을 읽으면서 정리한 글 입니다. 읽으면서 기억하고 싶거나 다시 보고 싶은 문구 위주로 정리합니다.

 

아키텍처는 시스템을 구체화하는 중요한 설계 결정을 표현하며, 그 결정의 중요도는 변경에 드는 비용으로 측정된다.
- 그래디 부티

좋은 아키텍처가 비싸다는 생각이 든다면, 나쁜 아키텍처를 시도해 보라
- 브라이언 푸트와 조셉 요더

아티켁처는 구현과 측정을 통해 증명해야 하는 가설이다.
- 톰 길브

빨리 가는 유일한 방법은 제대로 가는 것이다.
- 로버트 C.마틴

1부 소개

1장 설계와 아키텍처란?

설계(Design)와 아키텍처(Architecture)는 아무런 차이가 없다.

아티텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 편이다.

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

둘은 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만 있을 뿐이다.

목표는?

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

설계 품질을 재는 척도는 고객의 요구를 만족시키는 데 드는 비용을 재는 척도와 같다.

수명이 다할 때까지 비용이 낮게 유지할 수 있다면 좋은 설계, 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계다.

사례 연구

엉망진창이 되어 가는 신호

• 8번째 출시한 제품의 코드는 처음 제품보다 코드 라인당 비용이 40배나 증가했다는 데이터.
• 시스템을 급하게 만들거나 결과물의 총량을 순전히 프로그래머 수만으로 결정하고나 코드의 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면 파국으로 치닫는 비용 곡선에 올라타게 된다.
• 개발자의 생산성은 거의 100%로 시작해서 출시할 때마다 하락한다. 결국에는 0으로 수렴한다.
• 지독한 절망감 - 전력을 기울이지 않는 개발자는 없다. 잔업을 하며 헌신 함에도 불구하고 더 이상 진척이 없는 상황에 처하게 된다. 개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작한다. 심지어 사소한 기능을 추가하는 일도 엉망이 된 코드를 이동시키는 반복 작업으로 변질된다. 개발자들이 쏟은 노력의 가치가 결국 보잘것없게 된다
•  👩🏻‍💻 정말 공감 간다. 버전이 올라갈수록, 기능이 추가될수록 생산성은 떨어지고 유지 보수하기 어려워지는 상황 속에 놓인 적 있다. 함께하는 개발자들이 여러 번 바뀌기도 하였다. 눈에 띄는 성과는 없는 채로, 생산성이 낮은 상태가 유지되는 상황에 놓였다. 하지만 그렇다고 우리가 놀고 있던 것도 아니었다. 항상 버그와 코드 분석 등 유지보수에 애쓰고 있었다. 전력을 기울이지 않아서가 아니였다. 할 일은 항상 많고 생산성이 나오지 않는 상황에 쉽게 우울감에 빠졌다.

경영자의 시각

같은 기간에 개발하는 데 쓰인 월별 인건비를 보게 되면 첫 번째 출시 대비 여덟 번째 출시에는 월 인건비가 200배 넘게 차이 난다. 심지어 계속 증가하는 추세다.

조치가 필요하다.

무엇이 잘못되었나?

토끼와 거북이의 우화의 교훈과 비슷하다. “느려도 꾸준히 가면 이긴다.”, “발 빠른 자가 경주에 이기는 것도 아니며, 힘센 자가 싸움에서 이기는 것도 아니다.”, “급할수록 돌아가라.”

잘 설계된 코드가 중요하다는 사실을 알고 있지만 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!”라는 거짓말에 속는다. 나중에 코드를 정리하는 경우는 한 번도 없다. 시장의 압박은 절대로 수그러들지 않는다. 바로 다음에 만들어야 할 새로운 기능들이 계속 기다리고 있다. 결국 엉망진창이 되고, 생산성은 0을 향해 수렴한다.

더 잘못된 거짓말은 “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다”는 견해다.

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

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

개발자로 하여금 토끼처럼 과신하려는 믿음을 버리고, 만들어 낸 엉망진창인 코드를 개발자가 책임지도록 하는 것뿐이다.

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

결론

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

이 책에서 훌륭하고 깔끔한 아키텍처와 설계가 무엇인지 설명하고 이를 통해 소프트웨어 개발자가 장기간에 걸쳐 수익을 창출하는 시스템을 만들 수 있게 하고자 한다.

---

👩🏻‍💻 읽으면서 든 생각

16? 17년에 만들어진 도구를 중간에 맡아 21년도까지 유지보수하면서 느꼈던 답답한 감정이 떠오른다. 초기엔 설계도 있었고 고민을 많이 한 것이 느껴지는 프로젝트였지만 그 고민을 계속 이어 나갈 사람도 없었을뿐더러 코드만 유지되고 있을 뿐 아키텍처나 코드 스타일에 대한 방향성은 이미 잃어버린 상태였다. 그 상태에서 전체를 파악하지 못한 개발자들이 급급하게 필요한 버그 픽스나 기능 추가가 이루어지는데 어떻게 처음의 아키텍처를 유지될 수 있겠는가. 생각해보면 생산성 떨어지는 것이 너무 당연한 것이고 그래서 우리가 그렇게 고생을 했구나 싶다. 잘 해내고자 개선도 많이 했지만 일은 계속 많았고 우리가 느끼는 코드의 상태는 너무나도 미미하게 나아져서 항상 부채감이 있었고, 여러모로 맘이 무거웠던 것 같다. 내가 “우리 도구는 더 좋아질 일만 남았어요”라고 말하고 다녔는데... 지금 생각해보니 무슨 자신감이였냐?ㅋㅋㅋ 이 책을 읽을 동기를 불어넣어 줘서 좋았고, 끝까지 잘 읽어보고 실무에 잘 적용해보고 싶다.