[Clean Architecture] 아키텍처란?

아키텍처라는 단어는 권력과 신비로움을 연상케 합니다. 소프트웨어 아키텍처는 기술적 성취의 정점에 서 있습니다. 저도 처음에는 알고리즘을 짜는 개발자가 제일 최고인줄 알았는데 뭔가를 배울수록 소프트웨어 아키텍처를 만드는 사람들이 존경스러워 집니다. 제가 생각하는 아키텍처란 어떤 기능을 고치는데 드는 비용을 최소화 하게할 수 있는 사람입니다. 많은 경험으로 쌓인 노하우들을 적용하는 과정이라고 생각합니다. 제가 요즘 Clean Architecture를 비롯하여 Refactoring, Design Pattern 등에 관심을 가지는것이 이 때문입니다. 제가 소프트웨어를 만들면 유지보수하는데 걸리는 비용이 너무 커서 그것을 줄이는 방법이 무엇일까?를 계속 고민하기 때문입니다.

그러면 소프트웨어 아키텍처의 정의란 무엇일까요?

소프트웨어 아키텍트는 프로그래머 이며, 앞으로도 계속 프로그래머로 남는다. 소프트웨어 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야 한다는 거짓말에 절대로 속아 넘어가서는 안된다. 소프트웨어 아키텍트는 코드와 동떨어져서는 안된다. 소프트웨어 아키텍트는 최고의 프로그래머이며, 앞으로도 계속 프로그래밍 작업을 맡을 뿐만 아니라 동시에 나머지 팀원들이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 줘야 한다. 지속적으로 프로그래밍에 참여하여 문제를 경험하고 다른 프로그래머들에게 지원을 해야 한다.

궁극적으로, 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어야 한다.

위 정의를 실현하기 위해서 소프트웨어 아키텍트는 가능한 많은 선택지를, 가능한 오래 남겨두는 전략을 따라야 합니다.

이책 초반에서 저자가 설명했듯이, 소프트웨어는 두 종류의 가치, 즉 행위적 가치와 구조적 가치를 지닙니다. 이 중에서 두 번째 가치가 중요한데, 소프트웨어를 부드럽게 만드는 것은 바로 이 구조적 가치입니다. 소프트웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문입니다. 하지만 이러한 유연성은 시스템의 형태, 컴포넌트의 배치 방식, 컴포넌트가 상호 연결되는 방식에 상당히 크게 의존합니다.

소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 많이, 그리고 가능한 오랫동안 열어 두는 것입니다. 그렇다면 열어두어야 하는 선택사항이란 어떤것일까요? 바로 세부사항입니다. 세부사항이란 서비스를 구현하기 위해 필요한 요소들을 말합니다. 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등등이 있습니다.

아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는데 있습니다. 이를통해 세부사항을 미룰 수 있을때까지 미룰 수 있게 됩니다. 세부사항에 몰두하지 않은 채 고수준의 정책을 만들 수 있다면, 이러한 세부사항에 대한 결정을 오랫동안 미루거나 연기할 수 있습니다. 이러한 결정을 더 오래 참을 수 있다면 더 많은 정보를 얻을 수 있고, 이를 기초로 제대로 된 결정을 내릴 수 있습니다. (이번에 외주하면서 처음에는 Bluetooth Classic이었다가 나중에 BLE로 바뀌어서 고치는데 고생했음. 인터페이스로 유연하게 대처했다면 변경 비용이 작았을것 같음)

이러한 뜻은 인터페이스와 같이 의존성을 최소화하여 언제든지 세부사항을 바꿀 수 있게 해야 한다라는 말인것 같습니다. 따라서 좋은 아키텍트는 결정되지 않은 사항의 수를 최대화 한다고 볼 수 있습니다.

Clean Architecture 카테고리 내 다른 글 보러가기