소프트웨어 아키텍처의 필요성(feat. 클린 아키텍처 1~2장)

 요즘 소프트웨어 아키텍처를 공부하고 있어요.생각이 날 때마다 공부하는 건데 항상 어려운 부분 중 하나입니다

그래서 아키텍트가 높은 연봉을 받고 있는 거겠죠?

저는 이전 회사에서 소프트웨어 아키텍처의 중요성을 절실히 느꼈습니다. 저는 회사가 첫 직장이었지만 사수도 없었고 혼자서 소프트웨어를 만들었습니다.

얼마나 엉망진창이었는지 짐작이 가시나요?

그렇게 엉망진창인 소프트웨어에 시스템 출시까지 했다는 사실이 이제 와서 생각하니 황당하기까지 하네요.

2년 정도 허송세월하던 차에 사수가 입사했어요.국내 대기업과 외국계 대기업에서 소프트웨어 엔지니어를 하던 분이라 오자마자 저희 (실은 저 혼자의) 소프트웨어가 엉망인 것을 알고 전면 리팩터링에 착수했습니다. ㅎㅎㅎ

이 때 왜 OOP가 중요한가, 소프트웨어 아키텍처와 디자인 패턴이 왜 중요한가. TDD가 무엇이든 Modern C++가 무엇인지 등 소프트웨어의 기본적인 지식을 그제서야 배울 수 있었습니다.

실무와좋은멘토를통해학교에서배웠고책에서공부할때와는차원이다른속도와퀄리티로소프트웨어역량을키울수있었습니다.

그 중 딱 한 가지만 배울 수 있었다고 가정하면, 당연히 소프트웨어 아키텍처를 채택하죠.그만큼 중요하고 소프트웨어 개발의 효율성을 극대화할 수 있기 때문입니다.

그래서 이번에 소프트웨어 아키텍처를 다시 공부하고 있어요.로버트 C. 마틴의 클린 아키텍처는 제가 본 아키텍처 책 중에서 가장 이해하기 쉽고 아키텍처의 필요성에 대해 상세히 기술된 책입니다.

이 책을 바탕으로 공부한 내용을 블로그에서 공유하고자 합니다. ~

이번 포스팅에서는 책의 1~2장의 내용, 소프트웨어 아키텍처는 무엇이며 왜 공부를 해야 하는지에 대해 다루겠습니다.

다음은 책 내용 중에서 발췌한 것입니다.

---------

프로그램을 작동시키는 데 엄청난 지식과 기술이 필요하다

그러나 프로그램을 올바르게 만드는 것은 전혀 다르다.소프트웨어를 제대로 만드는 것은 어렵다.

소프트웨어를 제대로 만들려면 적정한 지식과 기술을 갖춰야 하는데, 많은 젊은 프로그래머들이 이 수준에 못 미치거나 사고력과 통솔력을 갖춰야 하는데 많은 프로그래머들은 시간을 들여 이런 능력을 개발하지 못하고 있다.그리고 어느 정도의 훈련과 헌신이 필요하지만 대다수 프로그래머는 훈련과 헌신이 필요하다고 생각하지 않는다.

소프트웨어를 제대로 만들기 위해서는 무엇보다도 기술에 대한 열정과 전문가를 향한 열망이 필요하다

반면 △소프트웨어를 제대로 만들게 되면 마법 같은 일이 일어난다 △소수의 프로그래머만으로 프로그램이 지속적으로 작동되도록 할 수 있다 △거대한 요구사항 문서와 이슈가 수두룩하게 등록된 이슈추적 시스템도 필요 없다.전 세계에서 칸막이가 쳐진 작은 사무실에서 쉬는 날 없이 일하는 프로그래머가 없어도 된다

제대로 된 소프트웨어를 만들면 약간의 인력으로 새로운 기능을 추가하거나 유지 보수할 수 있는 변경 사항들은 단순하게 빨리 반영될 수 있는 결함이 줄어들게 되고, 적게 만들게 되는 최소한의 노력으로 기능과 유연성을 극대화할 수 있다

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

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

새로운 기능을 출시할 때마다 비용이 많이 드는 것은 나쁜 설계이다

한 개발자는 코드는 나중에 정리하면 된다. 당장 시장에 내놓는 게 먼저다!라는 흔한 거짓말에 속는 개발자라면 나중에 코드를 정리하는 일은 한 번도 없으면서 시장의 압박은 절대 수그러들지 않기 때문이다.

출시 먼저라고 생각하는 이유는 바로 뒤에 경쟁자들이 따라오고 있고 경쟁자들보다 앞서려면 최대한 빨리 달려야 하기 때문이다.

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

개발자들이 속는 잘못된 거짓말은 더러운 코드를 작성하면 단기간에 빠르게 처리할 수 있고 장기적으로 볼 때 생산성이 떨어진다는 견해다.

이 거짓말을 받은 개발자는 뒤죽박죽 코드 만들기에서 나중에 기회가 되면 망가진 코드를 정리하는 체제로 전환할 수 있다고 자신의 능력을 과신하게 된다.그러나 이는 단지 진실을 오인한 것일 뿐, 엉터리로 하면 깨끗하게 유지할 때보다 항상 늦는다는 것이다.

제이슨 고먼(Jason Gorman)은 테스트 주도의 개발, 즉 TDD 적용 여부에 따른 개발시간을 비교한 실험을 실시했다.TDD를 적용한 날이 적용하지 않은 날보다 약 10% 일찍 작업이 완성되었으며, 나아가 TDD를 적용한 날 중 가장 늦은 날이 TDD를 적용하지 않아 가장 빨리 작업한 날보다 빨랐다.

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

제2장 두 가지 가치에 대한 이야기

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공하는 행위(behavior)와 구조(Architecture - 책에서는 structure로 번역되었지만, 후속 내용에서는 모두 architecture로 사용함)이며, 소프트웨어 개발자는 양쪽의 가치를 반드시 높게 유지해야 할 책임을 진다.

행위(Behavior)- 이해관계자의 기계가 요구사항을 만족하도록 코드를 작성

아키텍처(Architecture)-. 소프트웨어는 변경하기 쉬워야 한다. 기능이 바뀌면 변경사항을 쉽게 적용할 수 있어야 한다. 변경을 적용하는 데 있어서의 곤란은 변경되는 범위에 비례하는 것으로 하며, 변경 사항의 형태와는 관련이 없는 것으로 한다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 선호할수록 새로운 기능을 이 구조에 맞추는 것이 어려워진다-. 따라서 아키텍처는 형태로 독립하고 그럴수록 더욱 실용적이다.

아이젠하워 매트릭스 드와이트 D. 아이젠하워(Dwight D. Eisenhower) 미국 대통령이 고안한 중요성과 긴급성에 대한 매트릭스에는 두 가지 문제가 있습니다.하나는 긴급하고, 다른 하나는 중요하고, 긴급성 문제는 중요하지 않으며, 중요한 문제는 절대 긴급하지 않습니다.드와이트 D. 아이젠하워 - 1954년 노스웨스턴 대학교 강연에서

이 격언에는 매우 중요한 진실이 내포되어 있는 긴급성의 문제는 거의 없으며 중요한 문제는 아주 긴급하게 다루어지지 않는다는 것이다

소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 갖는 것은 아니다.소프트웨어의 두 번째 가치인 아키텍처는 중요하지만, 즉각적인 긴급성을 필요로 하는 경우는 절대로 없다.

물론 어떤 것은 긴급하고 중요할 수도, 긴급할 수도, 중요하지 않을 수도 있다

최종적으로 이들 4가지 경우에 우선순위를 매길 수 있다.

1. 긴급하고 중요한 2. 긴급하지 않지만 중요한 3. 긴급하지도 중요하지도 않은 4. 긴급하지도 중요하지도 않은

아키텍처, 즉 중요한 것은 이 항목에서 가장 높은 2개의 순위를 차지하는 데 반해 행위는 1번과 3번에 위치한다.

업무 관리자와 개발자의 흔한 실수는 셋째에 위치한 항목을 첫째로 격상시키는 것이라고 하지만 중요하지 않은 기능과 긴급하고 중요한 기능을 구별할 수 없다

업무관리자는 통상 아키텍처의 중요성을 평가할 만한 능력을 겸비하고 있지 않기 때문에 개발자는 딜레마에 빠지게 된다, 소프트웨어 개발자를 고용하는 이유는 바로 이 딜레마를 해결하기 위한 것이며, 기능의 긴급성이 아니라 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 당연히 책임져야 한다.

아키텍처를 위해 투쟁하라 당신은 소프트웨어를 안전하게 보호할 책임이 있는 당신의 역할 중 하나이며 그것이 고용의 주요 이유 중 하나이다

아키텍처가 뒷전이 되면 시스템을 개발하는 비용이 추가로 들고 일부 또는 전체 시스템에 변경을 가하는 것이 현실적으로 불가능하다.이러한 사태가 재발하도록 허락한다면, 결국 소프트웨어 개발 팀은 자신들이 옳다고 믿는 가치 때문에 제대로 투쟁하지 않은 것이 된다