유지보수하기 좋은 소프트웨어 개발을 위한 아키텍처의 가치

사실이 아니라 공부한 내용과 생각을 정리한 글입니다. 언제든 가르침을 주신다면 감사하겠습니다.

 

개발자는 요구사항을 빠르게 반영하면서도 코드 품질을 지속적으로 높게 유지할 의무를 가진다. 좋은 코드 품질을 유지하기 위해선 어떻게 해야 할까?

객체지향에선 이를 달성하기 위한 방법으로 높은 응집도와 낮은 결합도를 가진 코드를 구성해야 한다고 말한다. 그런데, 높은 응집도를 가져야 하는 단위 혹은 낮은 결합도를 유지해야 하는 단위는 무엇일까? 

이 질문에 대한 답을 하기 위해 우리는 "관심사 분리"라는 개념을 이해해야 한다. 관심사 분리가 무엇인지 위키백과에 질의하면 다음과 같은 답을 얻을 수 있다.

컴퓨터 과학에서 관심사 분리(separation of concerns, SoC)는 컴퓨터 프로그램을 구별된 부분으로 분리시키는 디자인 원칙으로, 각 부문은 개개의 관심사를 해결한다.
관심사란 컴퓨터 프로그램 코드에 영향을 미치는 정보의 집합이다.

 

관심사 분리 원칙과 높은 응집도와 낮은 결합도를 유지해야 한다는 원칙을 결합해 보면, 비슷한 관심사를 가진 코드 단위끼리 높은 응집도를 유지하고 다른 관심사를 가진 코드 단위끼리는 낮은 결합도를 유지하는 것이 코드품질을 높게 유지할 수 있는 방법이라는 것을 이해할 수 있을 것이다.

좋다, 이제 위 원칙을 알았으니 지금까지 내가 작성한 코드들을 높은 품질의 코드로 리팩토링 하고 싶어 진다. 그래서 컴퓨터 앞으로 달려가 리팩토링 하려고 하면............... 아마 잘 안될 것이다!  내가 작성한 코드 중 어떤 부분이 어떤 관심사를 담고 있는지 혹은 담아야 하는지 알지 못하기 때문이다!

개인적으로 관심사를 기반으로 높은 응집도와 낮은 결합도를 유지해야 한다는 객체지향의 대원칙을 이해하는 건 상대적으로 쉽지만, 내가 작성하는 코드에 대한 관심사들을 식별하고 이를 조직화하는 것이 훨씬 더 어렵고 중요하다고 생각한다. 전자의 경우 어떤 상황에서도 흔들리지 않는 원칙이 될 수 있지만 후자는 내가 속한 상황에 맞게 해석할 수 있는 여지가 있는 정답이 없는 문제라고 생각하기 때문이다. 

 

이 지점에서 소프트웨어 아키텍처 개념이 탄생한다고 생각한다. 소프트웨어 아키텍처가 무엇인지 위키백과에 질의해 보면 아래와 같은 답을 받아볼 수 있다.

소프트웨어 구조 또는 소프트웨어 아키텍처(software architecture)는 소프트웨어의 구성요소들 사이에서 
유기적 관계를 표현하고 소프트웨어의 설계와 업그레이드를 통제하는 지침과 원칙이다.

우리가 흔히 접하는 소프트웨어 아키텍처는 무엇이 있을까? Layered Architecture, Hexagonal Architecture, MVC Architecture 등등 많이 있다.

Layered Architecture 에선 [Presentation | Application | Domain | Persistence] 형태의 계층형 구조를 주로 가이드하고 MVC Architecture 에선 [Model | View | Controller] 형태의 구조를 가이드한다. 그리고 Hexagonal Architecture는 [Input Adaptor | Input Port | UseCase | Domain | outputPort | outputAdaptor] 형태를 가이드한다.

각각의 아키텍처마다 필요한 구성요소를 정의하고 나아가 구성요소 간 의존을 어떤 식으로 할지에 대한 가이드를 제공한다.

정의된 구성요소와 구성요소끼리의 관계를 조금 더 면밀하게 들여다보면 각 구성요소는 특정 관심사에 따라 도출되고 분리되고 의존관계가 정의된 것을 이해할 수 있다.

MVC Architecture를 예시로 설명해 보면 각 구성요소는 아래와 같은 관심사에 의해 도출되고 분리된 것을 알 수 있다.

• Model: 비즈니스 및 데이터를 처리한다.
• View: 화면 관련 로직을 처리한다.
• Controller: Model과 View를 중계해 준다.

이렇듯, 아키텍처는 관심사를 도출하고 분리하는 것, 이렇게 도출되고 분리된 관심사들끼리의 높은 응집도와 낮은 결합도를 유지하기 위해 의존성을 관리하는 것에 대한 거시적인 가이드라인을 제공하는 역할을 한다. 따라서 아키텍처 없이 개발한다는 것은 거시적인 가이드라인 없이 개발한다는 의미이고, 이는 일관된 규칙을 기반으로 코드를 발전시키는 것에 큰 어려움을 주어 결국엔 big ball of mud 가 만들어질 가능성을 높인다.

 

지금까지 좋은 품질의 코드를 유지하려면 어떻게 해야 할까?라는 질문에서 출발해서, 객체지향의 대원칙인 높은 응집도와 낮은 결합도, 관심사에 따른 분리, 그리고 이에 대한 거시적인 가이드라인을 제공하는 소프트웨어 아키텍처까지 살펴보았다. 이러한 논리 흐름을 역순으로 따라가면 결국 아키텍처의 존재 이유는 좋은 품질의 코드를 유지하기 위함임을 이해할 수 있을 것이다.

그렇다면 아키텍처를 기반으로 코드를 작성하면 항상 좋은 코드품질을 유지할 수 있을까? 나는 이것만으로는 부족하다고 생각한다. 상황에 맞는 아키텍처를 선택하고, 기존에 존재하던 아키텍처 중 적절한 것이 없다면 일부 타협을 할 수도 있어야 한다고 생각한다. 그리고 이렇게 아키텍처를 결정했다면 코드를 기여하는 모든 구성원들이 아키텍처 의도를 정확히 이해하고 그 사상에 맞는 코드를 기여해야만 한다고 생각한다. 또한 처음부터 모든 것을 이해하고 아키텍처에 대한 의사결정을 할 순 없기 때문에 개발을 하면서도 지속적으로 아키텍처를 개선할 수 있어야 한다고 생각한다.(이는 이론보단 실전 영역이라고 생각한다.)

 

아키텍처는 거시적인 가이드라인을 제공한다는 점을 잊지 말자. 개발자가 처한 상황에 부적절한 아키텍처를 선택하게 되면 이러한 가이드라인은 오히려 불필요한 제약이 될 수 있다. 하지만 적절한 아키텍처를 선택 혹은 만들어낼 수 있다면 이는 개발자로 하여금 관심사를 식별하고 이를 조직화하는 비용을 효과적으로 줄여줄 수 있을 뿐만 아니라 프로젝트에 참여하는 여러 개발자가 일관된 방식으로 관심사를 식별하고 조직화할 수 있도록 도와줘서, 결국에는 유지보수하기 좋은 높은 품질의 코드를 적은 비용으로 개발할 수 있는 원동력이 될 것이다.

 

아키텍처의 가치를 이해했다면 이제 아키텍처 논의에 대한 출발선에 설 자격이 있다.

실무로 돌아가서 프로젝트를 시작할 때 어떤 아키텍처를 선택할지, 어떤 부분을 타협할지 생각해 보고 토론해 보라.

이를 통해 상황에 맞는 아키텍처를 선택하고 타협할 수 있는 능력을 키울 수 있길 기대한다.