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

설계와 아키텍처

• 결론부터 말하자면, 설계와 아키텍처는 같다. 둘의 차이는 없다.
• 흔히 '아키텍처'는 고수준의 무언가를 가리킬 때, '설계'는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다. 하지만, 이러한 구분은 실제로는 무의미하다.
• 하나의 아키텍트에서는 모든 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있다.
• 소프트웨어 설계도 마찬가지다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다.
  • 이들은 개별로는 존재할 수 없고, 실제로 이 둘을 구분 짓는 경계도 뚜렷하지 않다. 고수준에서 저수준으로 향하는 의사결정의 연속성만이 있을 뿐이다.

목표는?

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

잘못된 아키텍처를 만드는 원인

• 아키텍처가 잘 설계되면 좋다는 것은 누구나 알고 있다. 그런데, 우리는 왜 잘못된 아키텍처를 설계하고 고통받을까.
• 결국 나쁜 코드를 작성하는 것과 이유가 같다. 우리는 우리를 너무 과신한다. 일단은 상부의 요구에 맞춰 일단 돌아가게만 만들어놓고, 나중에 수정하고자 한다. 그러나 나중은 절대 오지 않는다.
• 또한 우리는 '지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다'는 거짓말에 자주 속곤한다. 사실은 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.

- 제이슨 고먼의 실험

• 제이슨 고먼은 단순한 앱을 만들면서 6일 동안 실험을 진행했다. 첫 째날, 셋 째날, 다섯 째날은 코드를 깔끔하게 유지하는 잘 알려진 수련법 중 하나인 TDD기법으로 앱을 만들었고, 다른 날은 TDD를 적용하지 않았다.
• 실험 결과, TDD를 적용한 날이 그렇지 않은 날보다 10% 정도 더 빠르게 작업이 완성되었다. 심지어 TDD를 적용한 날 중 가장 느렸던 날이 TDD를 적용하지 않고 가장 빨리 작업한 날보다도 더 빨랐다.

결론

• 어떤 경우라도 개발 조직의 최고의 선택지는 과신을 방지하고 소프트웨어 아키텍처의 품질을 심각하게 고민하기 시작하는 것이다.
• 소프트웨어 아키텍처를 심각하게 고려할 수 있으려면, 좋은 소프트웨어 아키텍처가 무엇인지 이해해야 한다.
  • 비용은 최소화하고 생산성은 최대화 할 수 있는 설계와 아키텍처를 가진 시스템을 만들기 위해서는, 이러한 결과로 이끌어 줄 시스템 아키텍처가 지닌 속성을 알고 있어야 한다.