그래서 아키텍처가 뭔데?
# 아키텍처란 무엇이고 왜 중요할까요?
2023년 11월 23일
아키텍처?
어떤 대상의 구성과 동작 원리, 구성 요소간의 관계 및 시스템 외부 환경과의 관계를 설명하는 하나의 설명서
아키텍처는 어떤 대상의 구성과 동작 원리, 구성 요소간의 관계 및 시스템 외부 환경과의 관계를 설명하는 하나의 설명서다. 간단하게 말하자면 아키텍처는 시스템의 설계 및 동작하는 방식이라고 이해할 수 있다.
해당 아키텍처는 Offispace 프로젝트의 아키텍처를 가져온것인데, 시스템이 전반적으로 어떻게 구성되어 있는지와 각각의 요소들은 무엇이 있는지에 대해 설명하고 있다. 이렇게 아키텍처 구성도를 미리 제공한다면 코드를 이해하거나 작성하는 입장에서 애플리케이션의 전체 설계를 이해하기 쉬울 것이다.
아키텍처의 중요성
아키텍처는 소프트웨어가 제공하는 가치인 기능과 구조 중에 구조에 해당한다. 소프트웨어가 제공하는 가치 중에 기능은 곧 내가 작성한 코드가 기능 자체가 되기 때문에 그 가치를 판단하기 쉽겠지만, 구조는 왜 중요한것일까?
또 기능과 구조 중에서 어느 것이 더 중요할까?
Offispace 프로젝트 또한 기획으로부터 어떤 기능을 만들지 고민하고 기능이 잘 돌아가기 위해 여러 팀들이 많은 시간을 투자했다. 애플리케이션은 동작해야만 가치가 있기 때문이다. 하지만 클린 코드와 클린 아키텍처를 쓴 로버트 마틴은 구조가 더 중요하다고 설명한다. 구조를 잘 만들어 두면 개발하는 데 있어 좋은 것은 알겠는데 왜 애플리케이션의 기능 보다 더 중요하다고 했을까? 예시를 통해 설명하자면,
지금부터 방에 물건을 배치하는 상황을 가정하고, 방은 구조, 물건은 기능이라고 생각한다면, 다시말해 기능을 구조에 배치하는 상황을 상상해보자.
만약에 방 구조를 설계하지 않고 아무렇게나 기능을 배치한다면 어디에 어떤 물건이 있는지 한눈에 알기 어렵고, 물건을 추가로 넣을 공간도 없어질 것이다. 결국 사진처럼 물건은 많지만 제대로 활용할 수 없는 방이 될 것이다. 즉, 기능은 많지만 너무 복잡한 구조가 돼 버린 것이다.
다시 돌아와서 처음부터 물건 배치할 구조를 잘 정하고 물건을 배치한다면, 아까와 다르게 어떤 곳에 물건 있는지도 명확하게 알 수 있고, 물건을 추가로 놓을 공간도 존재한다. 새로운 물건이 추가 되더라도 구조가 잘 잡혀 있으니 어디에 위치해야 할지 금방 파악할 수 있고 배치하기도 쉬울것이다.
우리가 계속해서 고민해야 되는 부분도 이러한 부분이다. 좋은 구조를 가지도록 코드를 작성해야 한다. 결국 기능을 추가 하고 수정할 때 구조도 기능 만큼 중요하다 라고 이해할 수 있다. 이러한 아키텍처를 의미하는 구조는 소프트웨어 비용과도 관련이 있다.
개발 초기 단계에는 많은 기능을 빠르게 개발 해야 되기 때문에 개발 비용이 높지만, 개발이 완료되고 나서부터는 계속해서 변화하는 소프트웨어를 유지보수 해야 한다. 이때 기능 개발비용보다 유지보수비용이 늘어나는것을 그래프를 통해 확인할 수 있다. 따라서 장기적으로 봤을 때 기능을 개발하는 비용보다 유지보수비용이 훨씬 크다는 것을 알 수 있다.
그렇다면 좋은 구조는 어떻게 만들 수 있을까? 보통 응집성을 높이고 결합도를 낮추면서 개발하는것이 좋은 구조를 만드는 방법이라고 설명된다.
이런 원칙들을 모두 지켜 가면서 개발하는 것은 어려운 일 일것이다. 때문에 더 쉽게 해당 원칙을 지키면서 구조를 잡을 수 있게 방향을 제시해 주는 것이 아키텍처 패턴이다.
앞서 말했던 모든 원칙을 꼼꼼히 지킬 수 없지만 따라 하는 것만으로도 원칙들이 일부 지켜지고 기능 개발에도 쉽게 적용할 수 있도록 도와준다.
아키텍처 패턴에는 다양한 종류가 있지만, 오늘 소개해볼 아키텍처는 레이아웃 아키텍처와 클린 아키텍처이다.
레이아웃 아키텍처
레이어드 아키텍처는 관심사가 같은 코드를 계층으로 그룹화한 아키텍처이다. Presentation, Application, Persistence 계층으로 나눠 사용하고 필요에 따라서 계층을 추가하여 사용할 수 있다. 계층화로 인해 각 레이어는 분리된 책임을 가지고 있고, 편의에 따라 여러 계층을 추가 가능하다. 구조가 단순하고 익숙하기 때문에 많이 사용되지만, Persist 계층이 가장 하위에 위치하는 아키텍처의 특성상 데이터베이스 주도 설계가 될 수 있다는 단점이 존재한다.
레이어드 아키텍처의 동작 흐름
클라이언트 요청 → 프레젠테이션 계층은 애플리케이션 계층으로 비즈니스 처리 요청 → 애플리케이션 계층은 비즈니스 로직에 필요한 데이터를 Persist 계층에 요청 → Persist 계층은 데이터를 응답 → 받은 데이터로부터 로직을 처리하고 완료한 애플리케이션 계층은 외부로부터 전달한 정보를 프레젠테이션 계층에 응답 → 프레젠테이션 계층은 클라이언트에게 이를 전달
이 과정에서 Persentation, Application, Persist 순으로 의존성이 발생하는데 이는 상위 레이어가 하위 레이어를 알 수 있는 상황을 만들게 된다. 즉 상위 레이어가 하위 레이어를 알게 되기 때문에 하위 레이어 변경이 상위 레이어의 변경 까지 영향을 주게 되는 상황을 만든다.
이는 변경에 영향을 주는 상황을 의존성이 생긴것인데, Persist 계층의 변화가 애플리케이션 계층의 변화를 발생시키고 프레젠테이션 계층까지 수정이 필요해지게 되고,이러한 의존성을 갖는 경우 한 계층의 변화가 다른 계층에까지 영향을 주기 때문에 코드 변경이 어려워 진다.
클린 아키텍처
클린 아키텍처에서는 의존성 역전을 통해 이러한 문제를 해결한다.
사진처럼 의존성 방향이 → → → 으로 한 방향으로 흐르는 것은 레이어드 아키텍처와 큰 차이가 없다. 클린 아키텍처의 특징은 아래와 같다.
- 핵심 규칙을 담고 있는 도메인이 중심이 된다.
- 도메인이 세부 사항에 의존하지 않는다.
클린 아키텍처는 가장 간단하게 두 가지 계층으로 구분할 수 있다. 첫 번째 계층은 Entity와 Use Cases가 있는 계층이다. 이 계층은 비즈니스 로직을 추출한 계층이고 외부 요소에 대해서는 절대로 알면 안된다. 두 번째 계층은 외부 요소가 있는 계층이다. 어떤 DB를 사용하는지 어떤 프레임워크를 사용하는지와 같은 것들이 있다.
핵심은 이 두 가지 부분을 분리 하는 것이 가장 중요한데, 각각의 레이어에 대해서 알아보자면 클린 아키텍처는 총 4개의 레이어로 구성되어 있다.
첫 번째 레이어는 Entity 레이어인데 가장 핵심적인 비즈니스 로직이나 규칙을 담고 있는 레이어고, 외부 요소에 대해서 어떠한 의존성도 갖고 있으면 안된다.
두 번째 레이어는 Use Cases 레이어다. 비즈니스 로직을 포함하고 있고, 보통 Repository에서 객체를 받아 와서 특정한 행위를 하고 업데이트 하는 부분을 처리한다.
세 번째 레이어 Adapter 레이어이다. 데이터를 Use Case에서 사용하는 형태로 변하거나 외부에서 사용하는 형태를 외부에 적합한 형태로 변환한다.
네 번째 레이어는 Infrastructure 레이어다. DB와 프레임워크 같은 외부와 통신 작업을 해주는 작업을 해준다.
