설계와 아키텍처란?
사실 설계와 아키텍처간의 차이는 없다.
설계라는 단어와 아키텍처라는 단어가 있고, 각각의 의미가 다음과 같다.
•
아키텍처 : 저수준의 세부사항화 분리된 고수준의 무언가를 가리킬 때 사용
•
설계: 저수준의 구조 또는 결정사항등을 의미할 때 사용한다.
하지만 실제 아키텍트가 실제로 하는 일을 살펴보면 무의미한 구분이다.
집을 설계한다고 가정했을때 집의 설계 도면을 보면 고수준의 아키텍처(형태, 외관, 입면도, 공간, 방의 배치 등….) 부터 저수준의 세부사항(콘센트, 전등 스위치, 전등, …)이 모두 포함되어 있다.
즉, 저수준의 세부사항과 고수준의 결정사항은 모두 전체 설계의 구성요소가 된다.
소프트웨어 역시 크게 다르지 않다. 개별로는 존재할 수 없고 경계또한 뚜렷하지 않다.
오직 고수준에서 저수준으로 향하는 의사결정의 연속성만이 존재한다.
결국 목표는…
그럼 좋은 설계의 목표란 무엇일까? 소프트웨어 아키텍처의 목표는 클라이언트가 요구하는 필요한 시스템 을 만들고 유지보수에 투입될 비용을 최소화하는데 있다.
당장 배포일이 다가오는데, 나중에 정리하면 되는게 아닐까?
실무에 투입된 수많은 현업 개발자들이 하는 생각이고, 나 역시 종종 생각하는 부분이다.
당장 내일 배포를 해야하는데, 언제 테스트를 작성하고 클린 아키텍처를 고려하지? 일단 돌아가게 만들고 에러가 안나도록 작성하고 나중에 시간이 될 때 리팩토링하면 되지 않을까? 이런 생각들을 하고만다.
하지만, 이런 생각은 오만이고 지나친 과신이라 할 수 있다.
거의 대부분의 개발자는 이런 자기자신의 거짓말의 속아넘어가 리팩토링을 하는 경우는 거의 없다.
배포를 한다 하더라도 QA의 압박은 수그러들지 않고 시장의 압박도 수그러들지 않는다.
배포를 하고 여유롭게 리팩토링을 하는게 아닌 경쟁자들보다 앞서가기 위한 새로운 기획에 맞춰서 전력질주를 해야하기 때문이다. 결국 개발자는 이런 스탠스를 변경하지 못하고, 코드는 엉망인 상태로 몇년이고 그대로 남게 된다.
그리고 이런 상황이 지속될수록 프로젝트의 전체적인 퀄리티는 낮아지고, 그에 비례해서 생산성도 0으로 수렴하는 일이 발생한다. 초기에는 10명의 개발자가 100이라는 생산성을 가질 수 있지만, 몇 년뒤에는 100명의 개발자가 10의 생산성을 확보하기도 불가능에 가까워질 수 있다는 것이다.
결국, 빨리 가는 유일한 방법은 제대로 가는 것이다.
두 가지 가치에 대한 이야기
소프트웨어가 공통적으로 제공하는 두 가지 가치는 행위(behavior)와 구조(structure)다.
이 두 가지 가치를 모두 높게 유지해야 할 책임을 개발자는 가지고 있지만, 현실은 보통 한 가지 가치에 치중한다는 것인데, 이는 시스템이 엉망이 되도록 가는 길이다. 우선은 두 가치에 대해 좀 더 알아보자.
행위(behavior)
소프트웨어가 가지는 첫 번째 가치로, 회사에서 프로그래머를 고용하는 이유이기도 하다.
회사에서는 수익창출 혹은 비용절감을 목적으로 소프트웨어를 만들 필요성을 가진다.
그리고 프로그래머는 이런 필요성을 해결하기 위해 요구사항 문서 혹은 기능명세서를 구체화 할 수 있도록 코드를 작성하여 소프트웨어를 만들고, 문제가 발생하면 디버깅을 통해 문제를 해결한다.
그럼 개발자는 클라이언트의 요구사항을 구현하고 버그를 수정하는게 할 일의 전부일까?
이는 틀린 생각이다.
아키텍처
소프트웨어의 두 번째 가치로 우선 소프트웨어라는 단어의 의미를 생각해보자.
의미를 생각하면 부드러운 제품이라고 해석할 수 있는데, 즉, 변경하기 쉬운 제품이라고 생각할 수도 있을 것 같다. 클라이언트에 변심으로 기획이 변경되고 기능이 변경되더라도 이런 변경사항들이 되도록 간단하게 적용할 수 있어야 한다.
실제로 작은 SI회사(더 큰 회사로 이직을 했지만 크게 다르진 않다.) 에서는 이런 기획변경이 잦고, 이는 기한내에 소프트웨어를 완성하는 난이도를 높히는 주범이 된다. 그렇기에 개발 비용은 요청된 변경사항의 크기에 비례한다.
그런데 이런 시스템(소프트웨어)의 아키텍처가 특정 형태를 따른다면 새로운 요구사항(기능)을 추가할 때마다 이 구조에 맞춰야하는데 이는 쉽지않고, 아키텍처가 특정 형태를 선호하는 정도가 클 수록 더 힘들어진다. 그렇기에 아키텍처는 형태에 독립적이어야 하고 그래야 새로운 기능을 추가하는데 어려움이 적어진다.
더 높은 가치
그럼 우리는 기능과 아키텍처 어디에 더 집중하고 높은 가치를 부여해야 할까?
다음은 이 양 쪽의 가치중 하나에 극단적인 중요도를 부여한 두 가지의 소프트웨어가 있다고 할 때 무엇이 더 가치있을까?
•
완벽하게 동작하지만, 수정이 아예 불가능한 프로그램
•
동작하지는 않지만 변경이 쉬운 프로그램
너무 극단적인 예시이고, 사실 변경이 완전히 불가능한 프로그램은 존재하지 않는다.
하지만, 수정이 현실적으로 불가능한 시스템은 있을 수 있는데, 변경에 드는 비용이 변경으로 창출되는 수익을 초과하는 경우이다. 즉, 변경을 했더니 오히려 손해가 발생한다면 수정이 사실상 불가능해지는 것이다.
당장의 완료를 위해 전자를 제공한다면, 나중에 기획변경 혹은 업무 관리자의 변경 요청에 대해서 변경 비용이 너무 커서 변경할 수 없다고 대답하면, 개발자의 무능력만 언급하며 지적받을 가능성이 높다.
