프로그램을 동작하게 만들기는 그리 어려운 일이 아니다. 하지만 프로그램을 제대로 만드는 일은 전혀 다르다.
제대로 된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있다. 결함은 적어지고 잦아든다.
아주 사소한 변경에도 몇 주가 걸릴 뿐만 아니라 큰 위험을 감수해야 하지는 않았나? 잘못된 코드와 끔찍한 설계로 인해 방해를 받지 않았나? 형편없는 소프트웨어 구조로 인해 실패한 적은 없었나? 프로그래밍 지옥을 경험하지 않았나?
훌륭한 소프트웨어 설계를 바탕으로 작업하면서 즐거움을 느끼기보다는, 형편없는 소프트웨어 설계와 맞서 싸우는 일을 훨신 더 자주 맞닥뜨린다.
[1장] 설계와 아키텍처란?
설계(design)와 아키텍처(architecture) 사이에는 오랫동안 많은 혼란이 있었다. 둘사이에는 어떤 차이가 있는가?
둘사이에는 차이가 없다. 아무런 차이가 없다.
‘아키텍처’는 저수준의 세부사항과는 분리된 고수준의 뭉너가를 가리킬때 흔히 사용되는 반면, ‘설계’는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만 아키텍트가 시제로 하는 일을 살펴보면 이러한 구분은 무의미하다.
저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다. 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓느 ㄴ경계는 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 ㅇ녀속성만이 있을 뿐이다.
<목표는?>
소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.
<사례 연구>
매번 새로운 기능을 출시할 때마다 개발자의 수는 지속적으로 증가했지만, 코드 생산성은 마치 한 곳으로 수렴하는 것처럼 보인다.
이 추세로는 오래 갈 수 없다. 결국 이러한 비용 곡선은 사업 모델의 수익을 엄청나게 고갈시키며, 회상의 성장을 멈추게 하거나 심지어는 완전히 망하게 만든다.
시스템을 급하게 만들거나, 결과물의 총량을 순전히 프로그래머 수만으로 결정하거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면, 파국으로 치닫는 이 비용 곡선에 올라타게 된다.
개발자의 노력은 기능 개발보다는 엉망이 된 상황에 대처하는 데 소모되기 시작한다. 심지어 사소한 기능을 추가하는 일도 그저 엉망이 된 코드를 이곳에서 저곳으로, 다시 다음 곳으로 이동하는 반복 작업으로 변질된다. 개발자들이 쏟은 노력의 가치가 결국 보잘것없게 된다.
“느려도 꾸준하면 이긴다.”
“발 빠른 자가 경주에 이기는 것도 아니며, 힘센 자가 싸움에서 이기는 것도 아니다.”
“급할수록 돌아가라.”
현대의 대다수 개발자는 뼈 빠지게 일한다. 하지만 그들의 뇌는 잠에 취해 있다. 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다는 사실을 알고 있는 바로 그 뇌가 잠자고 있다.
이들 개발자는 “코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!”라는 흔해 빠진 거짓말에 속는다. 결국 개발자는 절대로 태세를 전환하지는 않는다. 이전에 작성한 코드로 돌아가 정리하는 일은 일어나지 않는데, 바로 다음에 만들어야 할 새로운 기능이 기다리고 있을 뿐이다.
토끼가 자신의 빠르기를 과신한 것과 마찬가지로, 개발자도 생산성을 유지할 수 있다고 자신의 능력을 과신한다. 하지만 엉망진창인 코드가 서서히 쌓이면 개발자 생산선은 차츰 낮아지고, 코드가 엄앙이 되는 추세는 절대 멈추거나 수그러들지 않는다.
개발자가 속는 더 잘못된 거짓말은 “지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼때만 생산성이 낮아진다”는 견해다. 즉, 나중에 기회가 되면 엉망이 된 코드를 정리하는 태세로 전환할 수 있다고 자신의 능력을 과신하게 된다. 진실은 다음과 같다. 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다. 시간 척도를 어떻게 보든지 관계없이 말이다.
코드를 깔끔하게 유지하는 잘 알려진 수련 법 중 하나인 테스트 주도 개발(TDD)
빨리 가는 유일한 방법은 제대로 가는 것이다.
개발자는 처음부터 다시 시작하여 전체 시스템을 재설계하는 것이 해답이라고 생각할지도 모른다. 하지만 이 생각 또한 토끼의 말과 다름없다.
자신을 과신한다면 재설계하더라도 원래의 프로젝트와 똑같이 엉망으로 내몰린다.
<결론>
어떤 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.
비용은 최소화하고 생산성은 최대화할 수 있는 설계와 아키텍처를 가진 시스템을 만들려면, 이러한 결과로 이끌어 줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.
댓글