설계와 아키텍쳐의 차이점?
많은 사람들은 설계와 아키텍쳐의 차이점을 이렇게 인지하고 사용한다. 아키텍쳐는 저수준의 세부사항과는 분리된 고수준(Repo 구조 등등)의 무언가를 설계하는 것이다. 설계 같은경우는 저수준(구현 등등)의 구조 또는 결정사항 등을 의미하여 사용한다.
하지만 둘 사이에는 사실상 아무런 차이가 없다. 아키텍트가 실제로 하는일을 살펴보면 이러한 구분은 무의미 하다. 여기서 말하는 아키텍트는 아키텍쳐 및 시스템을 설계하는 사람을 뜻한다.
예를 들어서 새로운 집을 설계하는 아키텍트가 있다고 하자. 이 새로운 집은 아키텍쳐를 가지고 있는지 한번 생각을 해보자. 이 집은 아키텍쳐에 대해서 당연히 가지고 있다. 그렇다면 이 집의 아키텍쳐는 무엇일까? 아마 집의 형태, 외관 , 입면도, 공간이나 방의 배치 등등이 여기에 포함된다.
하지만 아키텍트가 만든 도면을 살펴보면 무수히 많은 저수준의 세부사항도 확인 할 수 있다.
콘센트, 전등 스위치, 전등이 모두 어디에 위치하는지를 도면에서 확인 할 수 있다. 또한 기초 공사가 어떻게 진행될지도 상세히 확인 할 수 있다.
다시 말해 모든 고수준의 결정사항을 지탱하는 모든 세부사항을 자세하게 확인할 수 있다. 이러한 저수준의 세부사항과 고수준의 결정사항은 집의 두 소프트웨어 전체 설계의 구성요소이다.
소프트웨어 설계도 마찬가지이다. 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소이기 때문이다. 개별로는 존재할 수 없고 실제로 이 둘을 구분 짓는 경계는 뚜렷하지 않기 때문에 아까 말했듯이 아키텍쳐와 설계를 구분해서 나누는건 무의미 하다고 생각한다.
좋은 소프트웨어 설계의 중요성
일단 소프트웨어 설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다를게 없다. 이 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때 까지 낮게 유지할 수 있다면 그 소프트웨어 설계는 좋은 설계라고 말할 수 있다. 반면에 새로운 기능을 출시할 때마다 비용이 크게 증가한다면 이는 나쁜 설계라고 볼 수 있다. 이렇게 생각해보면 좋은 설계란 이처럼 단순명료하다.
예를 들어 한 사례를 들어보자면 어떤 회사의 엔지니어링 직원 수가 늘어나는 추세를 살펴보면 점차 엔지니어링의 직원수가 늘어나는 걸보고서는 이 회사는 굉장한 성공을 이뤄냈다고 생각을 할 것이다.
그럼 이제 같은 기간 회사의 생산성을 살펴보자 매번 새로운 기능을 출시할 때마다 개발자의 수는 지속적으로 증가했지만 코드 생산비용은 점점 고점으로 수렴한다고 해보자 이러한 상황을 보고 이 회사가 성공을 이뤄냈다고 생각할 수 있는가? 이 추세로는 오래 갈 수 없을 것이다. 이러한 신호들은 엉망진창이 되어가는 신호이다. 코드와 설계의 구조를 깔끔하게 만드려는 생각을 전혀 하지 않으면, 이러한 문제가 생기게 된다.
좋은 소프트웨어 설계를 하기 위해서는?
어떠한 경우라도 개발 조직이 할 수 있는 최고의 선택지는 조직에 스며든 과신을 인지하여 방지하고, 소프트웨어 아키텍쳐의 품질을 심각하게 고민을 하고 고쳐야 한다는 것이다.
소프트웨어 아키텍쳐를 고려할 수 있으려면 좋은 소프트웨어 아키텍쳐가 무엇인지 이해해야 한다. 비용은 최소화하고 생산성은 최대할 수 있는 설계와 아키텍쳐 말이다.
그래서 우리는 좋은 설계에 대해 꾸준히 고민하고 공부해야 한다.
