base
소프트웨어 개발을 하다 보면 코드가 뒤죽박죽 섞여 "어디서부터 고쳐야 하지?"라고 고민하는 경우가 많습니다. 기능이 많아질수록 로직이 복잡해지고 유지보수가 어려워집니다. 이러한 문제를 예방하기 위해 소프트웨어 아키텍처가 중요해지는데요, 오늘 소개할 Layered Architecture(레이어드 아키텍처) 는 이런 복잡성을 해결하고 유지보수를 편리하게 만들어주는 기본적이고도 강력한 설계 방법 중 하나입니다.
Layered Architecture란 소프트웨어 시스템을 관심사 별로 명확하게 구분하여 계층(layer)으로 나누고, 각 계층이 서로 역할과 책임을 명확히 하도록 분리하는 설계 방법입니다. 각 계층은 추상화된 인터페이스를 통해 인접한 계층끼리만 소통하며, 이는 계층 간의 단방향 의존성을 만들어줍니다.
즉, 상위 계층은 바로 아래 계층에게 요청을 보내 처리하지만, 하위 계층은 상위 계층의 존재를 모르고 단지 요청을 받아 처리할 뿐입니다. 이렇게 하면 코드가 잘 정리되고, 한 계층의 변경이 다른 계층에 최소한의 영향을 주게 되어 시스템 유지보수가 더욱 용이해집니다.
대부분의 웹 애플리케이션은 4개의 계층(tier)으로 구성되며, 보통 Presentation Layer, Business Layer, Persistence Layer, Database Layer로 나누어집니다. 아래에서 각 계층의 역할을 더 자세히 살펴보겠습니다. (하지만 반드시 4개층으로 나눠서 개발해야하는 것은 아닙니다. 4계층이란 일반적인 개론을 설명하는 것이고, 개발하는 상황과 팀 정책에 따라 최선의 선택이 필요합니다.)
Presentation Layer는 사용자 또는 클라이언트와 직접 소통하는 최상위 계층입니다. 사용자가 시스템과 직접적으로 상호작용하는 인터페이스(UI)를 제공하며, 사용자의 입력을 받아 하위 계층으로 전달합니다.
예를 들어 웹사이트나 모바일 앱의 화면, 사용자가 클릭하는 버튼 등이 이 계층에 속합니다. 사용자는 이 계층을 통해 시스템과 소통하며, 실제 비즈니스 로직이나 데이터 처리 로직은 이 계층 아래에서 처리됩니다.
Business Layer는 시스템의 핵심적인 로직을 처리하는 계층입니다. Presentation Layer로부터 사용자의 요청을 전달받고, 이를 실제로 처리하여 결과를 반환합니다.
간단히 말하면, "서비스가 무엇을 하는지?"에 대한 로직이 들어가 있습니다. 예를 들어 쇼핑몰 시스템에서는 주문 처리, 재고 관리, 결제 처리 등 서비스의 핵심 기능이 Business Layer에 위치합니다.
Persistence Layer는 데이터의 영구 저장과 관리를 담당하는 계층으로, Business Layer에서 처리한 데이터를 저장하거나 조회하는 역할을 수행합니다. 데이터베이스와의 직접적인 상호작용을 추상화하여 데이터베이스 구현 세부사항을 상위 계층에 숨기는 역할도 합니다. Database Layer가 따로 없다면, 두 Layer를 함께 담당 할 수도 있습니다.
이 계층은 데이터베이스의 종류가 바뀌더라도 상위 계층에 미치는 영향을 최소화하여 시스템의 유연성과 유지보수성을 높이는 데 큰 역할을 합니다.
Database Layer는 실제 데이터를 영구적으로 저장하는 데이터베이스 자체를 의미합니다. 이 계층은 실제 데이터의 물리적 저장소이며, 데이터를 효율적으로 저장하고 관리하는 역할을 합니다. MySQL, PostgreSQL, MongoDB 같은 실제 데이터베이스가 여기에 속합니다.
이러한 4계층 구조로 아키텍처를 설계하면 다음과 같은 장점이 있습니다.
간단히 정리하면 Layered Architecture는 Presentation, Business, Persistence, Database라는 4계층으로 시스템의 관심사를 명확히 나누고, 계층 간 단방향 의존성을 통해 유지보수성을 극대화한 아키텍처 설계 방법입니다. 각 계층이 추상화된 인터페이스로 소통하여 변경이 다른 계층에 전파되지 않도록 하는 구조적 설계로, 유지보수성과 시스템의 확장성을 높이는 효과적인 설계 기법입니다.