소프트웨어 아키텍처 101 - CHAPTER 11 파이프라인 아키텍처 스타일

레이어드 아키텍처(layered architecture, n-티어(n-tiered) 아키텍처)는 가장 흔한 아키텍처 스타일 중 하나입니다. 단순하고 대중적이면서 비용도 적게 들어 모든 애플리케이션의 사실상 표준(de facto standard) 아키텍처입니다. 그러나 레이어드 아키텍처 스타일은 묵시적 아키텍처(architecture by implication) 안티패턴, 우발적 아키텍처(accidental architecture) 안티패턴 등의 몇몇 아키텍처 안티패턴의 범주에 속합니다.

10.1 토폴로지

레이어드 아키텍처에서 내부 컴포넌트는 논리적으로 수평한 레이어들로 구성되며, 각 레이어는 애플리케이션에서 (프레젠테이션 로직, 비즈니스 로직 등의) 주어진 역할을 수행합니다.

이러한 관심사의 분리(separation of concerns) 개념 덕분에 레이어드 아키텍처 스타일은 아키텍처 내부의 역할 및 책임 모델을 효과적으로 구성할 수 있습니다. 따라서 개발자 본인의 기술 역량을 도메인의 (프레젠테이션 로직, 퍼시스턴스 로직 등의) 기술 적인 부분에 집중시킬 수 있지만, 그런 장점을 대가로 전체적인 민첩성(변화에 신속하게 반응하는 능력)이 떨어지는 트레이드오프가 있습니다.

레이어드 아키텍처는 (도메인 분할 아키텍처의 반대인) 기술 분할된 아키텍처입니다. 즉, 컴포넌트를 (고객 같은) 도메인 단위로 묶는 게 아니라, 아키텍처의 (프레젠테이션 또는 비즈니스 같은) 기술 역할에 따라 묶기 때문에 비즈니스 도메인이 각각 모든 아키텍처 레이어에 분산됩니다. 이런 이유로 이 아키텍처 스타일은 도메인 주도 설계 방식과는 잘 안 맞습니다.

10.2 레이어 격리

레이어드 아키텍처의 각 레이어는 폐쇄(closed) 또는 개방(open) 상태입니다.

[그림 10-3]에서 단순 조회 요청이라면 불필요한 레이어를 건너뛰고 프레젠테이션 레이어가 데이터베이스를 직접 액세스하는 편이 더 빠르고 간편할 것입니다(2000년대 초반에는 이를 추월 차선 리더 패턴(fast-lane reader pattern)이라고 했습니다.).

레이어 격리는 어느 아키텍처 레이어에서 변경이 일어나도 다른 레이어에 있는 컴포넌트에 아무런 영향을 끼치지 않기에 레이어간 계약은 불변임을 의미합니다. 레이어 격리를 지원하려면 요청의 메인 흐름에 관한 레이어가 반드시 폐쇄되어 있어야 합니다.

또 레이어를 격리하면 아키텍처의 모든 레이어를(다시 말하지만, 잘 정의된 계약과 비즈니스 위임 패턴(business delegate pattern)을 사용한다는 가정 하에) 다른 레이어에 영향을 주지 않고 교체할 수 있습니다.

10.3 레이어 추가

아키텍처 내부적으로 폐쇄 레이어를 이용해 변경을 격리할 수 있지만, 어떤 레이어는 개방하는 것이 더 합리적인 경우도 있습니다. 예를 들어, 비즈니스 레이어에 공통 비즈니스 기능이 구현된 객체를 구현하여 공유하고, 프레젠테이션 레이어에서는 이 공유 객체를 직접 사용할 수 없도록 아키텍처 결정을 했다고 합시다. 이 시나리오는 지배/통제하기 어려운 아키텍처 구조입니다([그림 10-4]).

이런 제약 조건을 아키텍처적으로 강제하려면 공유 비즈니스 객체가 모두 포함된 새로운 서비스 레이어를 아키텍처에 추가하면 됩니다. 서비스 레이어를 개방 레이어로 만들어 추가하면 비즈니스 레이어는 이 레이어를 액세스하거나([그림 10-5]의 아래 방향 실선), 이 레이어를 지나처 다음 레이어로 향할([그림 10-5]의 아래 방향 점선) 수 있습니다.

개방/폐쇄 레이어 개념을 잘 활용하면 아키텍처 레이어간 관계와 요청 흐름을 정의할 때 유용합니다. 아키텍처의 어느 레이어가 개방/폐쇄되어 있는지 (그리고 왜 그런지) 정확히 문서화하여 소통하지 않으면 테스트, 유지 보수, 배포 작업이 아주 힘든, 단단히 커플링되어 금방이라도 깨질 듯한 아키텍처가 되어버릴 것입니다.

10.4 기타 고려 사항

아직 아키텍처 스타일을 완전히 결정하지 못했다면 대부분의 애플리케이션에서 레이어드 아키텍처는 좋은 출발점이 될 것입니다. 하지만 재사용은 최소한으로, 개체 계층(hierarchy)은 최대한 가볍게 맞추어 적절한 모듈성을 유지하는 거이 중요합니다.

레이어드 아키텍처에서는 아키텍처 싱크홀(architecture sinkhole) 안티패턴을 조심해야 합니다.

이 안티패턴으로 처리 중인 요청의 전체 비율을 따져보는 것이 중요합니다. 80 대 20 법칙을 적용해서 전체 요청의 20%가 싱크홀인 정도면 그런대로 괜찮은 수준입니다. 그러나 분석 벽롸 80%가 싱크홀이라면 이 문제 도메인에 레이어드 아키텍처는 적합한 아키텍처 스타일이 아니라는 증거입니다. 아키텍처 싱크홀 안티패턴을 해결하는 또 다른 방법은 아키텍처의 모든 레이어를 개방하는 것입니다. 그러나 이는 아키텍처상 변경 관리의 어려움이 가중되는 트레이드오프가 있음을 분명하게 인식해야 합니다.

10.5 왜 이 아키텍처 스타일을 사용하는가

레이어드 아키텍처는 작고 단순한 애플리케이션이나 웹사이트에 알잔은 아키텍처 스타일입니다.

레잉어드 아키텍처 기반의 애플리케이션은 규모가 커질수록 유지 보수성, 민첩성, 시험성, 배포성 같은 아키텍처 특성이 점점 나빠집니다. 따라서 레이어드 아키텍처를 사용한 대규모 애플리케이션이나 시스템은 다른 더 모듈러한 아키텍처 스타일이 더 잘 맞습니다.

10.6 아키텍처 특성 등급

전체 비용과 단순성은 레이어드 아키텍처 스타일의 주요 강점입니다. 이 아키텍처는 원래 모놀리식에 가깝기 때문에 분산 아키텍처 스타일에 따른 복잡도가 낮고, 구조가 단순해서 알기 쉬운데다 구축 및 유지보수 비용도 비교적 적게 듭니다. 그러나 모놀리식 레이어드 아키텍처가 점점 커지고 결과적으로 더 복잡해질수록 이런 장점들도 빛을 바랜다는 사실에 유의해야 합니다.

레이어드 아키텍처 스타일은 배포성과 시험성 별점이 매우 낮습니다. 배포를 하려면 절차가 까다롭고(그만큼 더 고생스럽고) 리스크가 높으며 자주 배포할 수 없기 때문에 배포성은 떨어집니다.

분산 아키텍처에서 일반적인 네트워크 트래픽, 대역폭, 레이턴시 문제는 덜하므로 신뢰성은 보통으로 매겼지만, 모놀리식 배포 속성상 시험성(테스트의 완벽도)과 배포 리스크 측면에서 점수를 낮게 줄 수밖에 없습니다.

이 아키텍처는 모놀리식 배포와 아키텍처 측면에서 모듈성이 부족하므로 탄력성과 확장성은 점수가 낮습니다.

레이어드 아키텍처는 모놀리식 배포 탓에 또 부족한 아키텍처 모듈성 때문에 내고장성도 별로입니다.

요약

10.1 토폴로지

• 레이어드 아키텍처는 논리적으로 수평한 레이어들로 구성됨.
• 각 레이어는 특정 역할(프레젠테이션 레이어, 비즈니스 로직 등)을 수행.
• 기술적 분할에 따른 아키텍처로, 비즈니스 도메인이 여러 레이어에 분산됨.

10.2 레이어 격리

• 레이어는 폐쇄(closed) 또는 개방(open) 상태로 구분됨.
• 폐쇄 레이어: 바로 아래 레이어만 접근 가능, 유지보수성과 캡슐화가 뛰어남.
• 개방 레이어: 하위 레이어에 자유롭게 접근 가능, 유연성과 성능이 높음.
• 개방/폐쇄 레이어 선택은 프로젝트 요구사항에 따라 결정됨.

10.3 레이어 추가

• 공유 비즈니스 객체를 위한 서비스 레이어 추가 가능.
• 개방/폐쇄 레이어 개념을 활용해 레이어 간 관계와 요청 흐름 정의.
• 개방/폐쇄 레이어의 명확한 문서화 필요.

10.4 기타 고려 사항

• 레이어드 아키텍처는 대부분의 애플리케이션에 좋은 출발점.
• 아키텍처 싱크홀(architecture sinkhole) 안티패턴을 주의.
• 요청의 80% 이상이 싱크홀일 경우 레이어드 아키텍처는 적합하지 않음.

10.5 왜 이 아키텍처 스타일을 사용하는가

• 작고 단순한 애플리케이션에 적합한 아키텍처 스타일.
• 규모가 커질수록 유지 보수성, 민첩성, 시험성, 배포성 등이 저하됨.

10.6 아키텍처 특성 등급

• 레이어드 아키텍처는 비용과 단순성이 강점.
• 배포성과 시험성에서 낮은 평가를 받음.
• 모놀리식 배포로 인해 확장성과 내고장성이 떨어짐.