계층형 아키텍처 및 관심사 분리

계층형 아키텍처는 소프트웨어 시스템을 논리적으로 구분된 여러 계층으로 구성하는 설계 패턴이다. 각 계층은 특정한 책임과 기능을 가지며, 일반적으로 상위 계층이 하위 계층의 서비스를 호출하는 단방향 의존 관계를 형성한다. 이 패턴의 주요 목적은 시스템의 복잡성을 관리하고, 유지보수성을 높이며, 구성 요소 간의 결합도를 낮추는 데 있다.

계층형 아키텍처는 관심사 분리 원칙을 구현하는 대표적인 방식이다. 사용자 인터페이스 처리, 핵심 비즈니스 로직 실행, 데이터 저장 및 조회와 같은 서로 다른 관심사를 별도의 계층으로 분리함으로써, 한 계층의 변경이 다른 계층에 미치는 영향을 최소화한다. 예를 들어, 데이터베이스를 MySQL에서 MongoDB로 변경해야 할 경우, 데이터 접근 계층만 수정하면 되며 비즈니스 로직 계층은 영향을 받지 않는다.

이 아키텍처의 궁극적인 목표는 소프트웨어의 이해하기 쉬운 구조를 제공하고, 개발, 테스트, 배포를 용이하게 하는 것이다. 계층별로 독립적인 개발과 팀 구성이 가능해지며, 특정 기술 스택의 교체나 업그레이드가 상대적으로 수월해진다. 전통적으로는 주로 3계층 아키텍처(표현, 비즈니스, 데이터) 모델이 널리 사용되었으나, 필요에 따라 더 세분화된 계층으로 구성되기도 한다.

계층형 아키텍처에서 계층은 일반적으로 특정 책임과 역할을 가진 논리적 그룹핑을 의미한다. 가장 전통적이고 널리 알려진 구성은 3계층 아키텍처로, 표현 계층, 비즈니스 계층, 데이터 접근 계층으로 구분된다. 각 계층은 상위 계층에 서비스를 제공하고, 하위 계층의 서비스를 사용하는 단방향 의존 관계를 형성한다. 이는 시스템의 복잡성을 관리하고, 각 부분을 독립적으로 개발, 테스트, 유지보수할 수 있게 하는 근간이 된다.

각 계층의 주요 책임은 다음과 같이 구분된다. 표현 계층은 사용자와의 상호작용을 처리하며, 사용자 인터페이스와 요청/응답 변환을 담당한다. 비즈니스 계층은 애플리케이션의 핵심 로직과 규칙을 포함한다. 데이터 접근 계층은 데이터베이스나 외부 시스템과의 통신을 추상화하여 데이터의 영속성을 관리한다. 이 구성은 아래 표와 같이 요약할 수 있다.

이 기본 3계층 모델은 필요에 따라 더 세분화될 수 있다. 예를 들어, 복잡한 비즈니스 로직을 위해 도메인 계층과 애플리케이션 서비스 계층을 분리하거나, 외부 시스템과의 통합을 위한 별도의 게이트웨이 계층을 추가하는 경우가 있다. 또한, 모든 계층이 공통으로 사용하는 크로스커팅 컨셉을 처리하기 위한 인프라 계층이 별도로 존재하기도 한다. 이러한 구성의 핵심은 계층 간의 경계를 명확히 하고, 상위 계층이 하위 계층의 구현 세부사항에 직접 의존하지 않도록 하는 것이다.

관심사 분리(Separation of Concerns, SoC)는 소프트웨어 공학의 근본적인 설계 원칙 중 하나이다. 이 원칙은 복잡한 시스템을 서로 다른 관심사나 책임 영역으로 분리하여 개발하고 관리하는 것을 목표로 한다. 각 모듈이나 구성 요소는 하나의 명확한 관심사에 집중하며, 다른 관심사와는 최대한 독립적으로 동작하도록 설계된다.

SoC의 핵심은 시스템의 복잡성을 관리 가능한 단위로 나누는 데 있다. 예를 들어, 사용자 인터페이스, 비즈니스 규칙, 데이터 저장 로직은 각각 별개의 관심사이다. 이들을 하나의 코드 블록에 섞어 두면, 사용자 인터페이스를 변경하려 할 때 비즈니스 로직에 영향을 미칠 위험이 생긴다. SoC는 이러한 문제를 방지하기 위해 각 관심사를 명확히 구분된 구성 요소로 분리하도록 권장한다.

이 원칙을 적용하면 여러 가지 이점이 발생한다. 첫째, 코드의 유지보수성이 향상된다. 특정 기능을 수정할 때 해당 관심사에만 집중하면 되므로 변경의 영향 범위가 제한된다. 둘째, 재사용성이 높아진다. 잘 정의된 단일 책임을 가진 모듈은 다른 컨텍스트에서도 쉽게 재사용될 가능성이 크다. 셋째, 개발자 간의 협업이 용이해진다. 서로 다른 관심사를 담당하는 팀이 독립적으로 작업을 진행할 수 있다.

관심사 분리의 개념은 1974년 에츠허르 데이크스트라가 그의 논문에서 공식적으로 언급한 것으로 알려져 있다[1]. 이후 이 아이디어는 구조적 프로그래밍, 객체지향 프로그래밍, 그리고 다양한 소프트웨어 아키텍처 패턴의 기초가 되었다. 계층형 아키텍처는 이 SoC 원칙을 공간적(수직적)으로 계층을 나누어 적용한 대표적인 사례이다.

관심사 분리 원칙은 계층형 아키텍처를 설계하고 구현하는 근본적인 철학적 기반을 제공한다. 계층형 아키텍처는 복잡한 소프트웨어 시스템을 논리적으로 구분된 계층으로 분해하는 구체적인 구조적 패턴인 반면, 관심사 분리는 이러한 분해가 왜 필요한지, 그리고 어떤 기준으로 이루어져야 하는지를 설명하는 보다 일반적인 설계 원칙이다. 따라서 계층형 아키텍처는 관심사 분리 원칙을 실현하는 가장 대표적이고 전통적인 방법론 중 하나로 볼 수 있다.

관심사 분리의 핵심은 각 구성 요소가 단일하고 명확한 책임을 가지도록 하는 것이다. 계층형 아키텍처는 이 원칙을 공간적(수평적) 분리로 적용한다. 예를 들어, 표현 계층은 사용자 인터페이스와 입력 검증에만 집중하고, 비즈니스 로직은 핵심 업무 규칙을 처리하며, 데이터 접근 계층은 데이터베이스와의 통신에만 전념한다. 각 계층은 자신의 고유한 관심사에만 집중하며, 다른 계층의 내부 구현 세부 사항을 알 필요가 없도록 설계된다. 이는 시스템의 복잡성을 관리 가능한 단위로 나누고, 각 부분의 독립적인 개발, 테스트, 유지보수를 가능하게 한다.

두 개념의 관계는 상호 보완적이다. 관심사 분리 원칙 없이 단순히 계층을 나누는 것은 의미가 없으며, 단지 코드를 물리적으로 분리하는 것에 그칠 수 있다. 반대로, 관심사 분리 원칙을 효과적으로 적용하기 위해서는 계층형 아키텍처와 같은 구조적 틀이 필요하다. 이 관계는 아래 표를 통해 명확히 구분할 수 있다.

결론적으로, 계층형 아키텍처는 관심사 분리 원칙을 구조적으로 체계화한 실천 방안이다. 성공적인 계층형 아키텍처 구현은 각 계층이 명확하게 분리된 관심사를 가지도록 보장함으로써, 결합도를 낮추고 응집도를 높이는 데 기여한다.

표현 계층은 계층형 아키텍처의 최상위 계층으로, 사용자나 외부 시스템과의 직접적인 상호작용을 담당한다. 이 계층의 주요 책임은 사용자 인터페이스를 표시하고, 사용자의 입력을 받아 적절한 형식으로 변환하여 비즈니스 계층에 전달하는 것이다. 또한 비즈니스 계층에서 처리된 결과를 다시 사용자가 이해할 수 있는 형태(웹 페이지, API 응답 등)로 변환하여 출력한다.

표현 계층의 구체적인 구성 요소는 애플리케이션의 유형에 따라 달라진다. 웹 애플리케이션의 경우 HTML, CSS, 자바스크립트로 구성된 뷰(View)와 사용자 요청을 처리하는 컨트롤러(Controller)가 이에 해당한다. 데스크톱 애플리케이션에서는 GUI 폼과 이벤트 핸들러가, 모바일 앱에서는 액티비티나 뷰 컨트롤러가 표현 계층의 역할을 수행한다. RESTful API를 제공하는 서버의 경우, 요청과 응답을 처리하는 컨트롤러 클래스가 표현 계층을 구성한다.

이 계층은 애플리케이션의 핵심 비즈니스 로직을 포함해서는 안 된다. 그 대신 입력값의 유효성을 간단히 검증하거나, 데이터 형식을 변환하는 등의 역할만 수행한다. 모든 복잡한 계산이나 데이터 처리 규칙은 반드시 하위의 비즈니스 계층에 위임해야 한다. 이는 관심사 분리 원칙을 따르는 핵심적인 실천법이다.

표현 계층은 다른 계층, 특히 비즈니스 계층에 대한 의존성을 가지지만, 그 반대 방향의 의존성은 존재하지 않는다. 이는 상위 계층이 하위 계층을 참조하는 단방향 의존 관계를 유지함으로써 시스템의 결합도를 낮추고 각 계층의 독립적인 변경과 테스트를 가능하게 한다.

비즈니스 계층은 계층형 아키텍처의 핵심으로, 애플리케이션의 핵심 로직과 규칙을 담당한다. 이 계층은 표현 계층과 데이터 접근 계층 사이에 위치하여, 사용자 요청에 대한 실제 처리를 수행한다. 시스템의 고유한 업무 규칙, 계산, 검증, 데이터 처리 흐름을 구현하는 곳이다. 때로는 애플리케이션 계층 또는 서비스 계층이라고도 불린다.

이 계층의 주요 책임은 다음과 같다. 첫째, 표현 계층에서 전달받은 요청을 해석하고, 필요한 비즈니스 규칙을 적용하여 처리한다. 둘째, 데이터 접근 계층을 통해 데이터를 조회하거나 저장하는 작업을 조정한다. 셋째, 여러 데이터 소스에 걸친 트랜잭션을 관리하고 데이터의 일관성을 보장한다. 예를 들어, 은행 송금 서비스에서 잔액 확인, 출금, 입금, 로그 기록이라는 여러 단계를 조율하는 로직이 여기에 해당한다.

비즈니스 계층은 순수한 비즈니스 로직에 집중하며, 사용자 인터페이스나 데이터베이스 접근 기술과 같은 하부구현 세부사항으로부터 독립되어야 한다. 이는 관심사 분리 원칙을 명확히 반영한다. 일반적으로 서비스 클래스나 도메인 모델 객체의 형태로 구현된다. 아래는 간단한 계층 간 상호작용을 보여주는 표이다.

이러한 구조 덕분에 비즈니스 규칙이 변경되면 주로 이 계층만 수정하면 되며, 다른 계층에 미치는 영향을 최소화할 수 있다. 또한 비즈니스 로직을 중앙에서 관리함으로써 코드의 재사용성과 테스트 용이성이 크게 향상된다.

데이터 접근 계층은 계층형 아키텍처에서 영속성 데이터의 저장, 조회, 수정, 삭제와 같은 CRUD 연산을 담당하는 계층이다. 이 계층은 비즈니스 로직을 수행하는 계층이 데이터베이스나 외부 API와 같은 데이터 소스에 직접 접근하는 것을 막는 추상화 계층 역할을 한다. 주된 목적은 데이터 저장소의 구체적인 기술과 구현 세부사항으로부터 상위 계층을 보호하는 것이다.

일반적으로 이 계층은 데이터베이스 테이블에 대응되는 엔티티 객체나 도메인 모델을 사용하며, SQL 쿼리를 실행하거나 ORM 프레임워크를 활용하여 데이터를 조작한다. 구현에는 DAO 패턴이나 Repository 패턴이 흔히 사용된다. 예를 들어, 사용자 정보를 관리하는 UserRepository 인터페이스와 그 구현체를 두어, 상위 비즈니스 계층에서는 findById, save 같은 메서드 호출만으로 데이터를 처리할 수 있다.

이러한 구조는 데이터 저장소를 관계형 데이터베이스에서 NoSQL 데이터베이스나 파일 시스템으로 변경해야 할 때, 비즈니스 계층의 코드 수정을 최소화할 수 있게 한다. 또한, 데이터 접근 로직의 중복을 방지하고 단위 테스트 시 가짜 객체(Mock 객체)를 쉽게 주입하여 테스트할 수 있는 이점을 제공한다.

의존성 주입은 계층형 아키텍처에서 각 계층 간의 결합도를 낮추고 관심사 분리를 실현하기 위한 핵심적인 구현 패턴이다. 이 패턴은 객체가 필요로 하는 의존 객체를 직접 생성하거나 찾지 않고, 외부로부터 주입받도록 설계하는 것을 의미한다.

의존성 주입은 주로 세 가지 방식으로 구현된다. 생성자 주입, 세터 주입, 인터페이스 주입이 그것이다. 이 중 생성자 주입은 객체 생성 시점에 필요한 의존성을 모두 주입받아 객체의 불변성을 보장하는 방식으로 가장 권장된다. 세터 주입은 선택적 의존성이나 변경 가능한 의존성을 설정할 때 사용된다.

이 패턴을 효과적으로 관리하기 위해 의존성 주입 컨테이너 또는 IoC 컨테이너가 사용된다. 스프링 프레임워크, Google Guice 등이 대표적인 컨테이너 라이브러리다. 이 컨테이너는 애플리케이션 구성 요소들의 생명주기와 의존 관계를 관리하며, 설정(예: XML, Java Config, 어노테이션)에 따라 적절한 객체 인스턴스를 생성하고 연결한다. 결과적으로 비즈니스 계층은 구체적인 데이터 접근 계층 구현에 의존하지 않고, 인터페이스에만 의존하게 되어 단위 테스트와 모듈 교체가 용이해진다.

인터페이스는 계층형 아키텍처에서 각 계층 간의 결합도를 낮추고 관심사 분리를 실현하는 핵심 도구이다. 구체적인 구현 클래스가 아닌 인터페이스에 의존하도록 설계함으로써, 한 계층의 변경이 다른 계층에 미치는 영향을 최소화한다. 예를 들어, 비즈니스 계층은 데이터 접근 계층의 구체적인 ORM이나 데이터베이스 기술을 알 필요 없이, 데이터 저장소 조작을 위한 인터페이스만을 사용한다.

이러한 접근 방식은 테스트와 유지보수성을 크게 향상시킨다. 비즈니스 로직을 단위 테스트할 때, 실제 데이터베이스에 의존하지 않고 모의 객체를 이용한 가짜 데이터 접근 구현체를 쉽게 주입할 수 있다. 또한, 데이터베이스를 MySQL에서 PostgreSQL로 변경하거나, 파일 시스템에서 클라우드 스토리지로 전환하는 경우에도, 해당 인터페이스를 준수하는 새로운 구현체를 만들어 교체하기만 하면 된다.

따라서, 각 계층의 경계를 정의할 때는 먼저 안정적인 인터페이스를 설계하는 것이 좋다. 이 인터페이스는 해당 계층이 제공해야 하는 핵심 책임과 연산을 명확히 정의한다. 이후 실제 구현은 이 인터페이스를 구현하는 별도의 클래스에서 담당하게 하여, 의존성 주입 프레임워크를 통해 런타임에 적절한 구현체가 연결되도록 한다.

헥사고날 아키텍처는 앨리스테어 콕번이 제안한 아키텍처 패턴으로, 포트와 어댑터 아키텍처라고도 불린다. 이 패턴의 핵심 목표는 비즈니스 로직을 외부 요소(데이터베이스, 사용자 인터페이스, 외부 서비스 등)로부터 독립시키는 것이다. 이를 통해 애플리케이션의 핵심이 외부 기술이나 프레임워크의 변경에 영향을 받지 않도록 설계한다.

이 아키텍처는 육각형 모양의 다이어그램으로 표현되며, 중앙에 애플리케이션 코어(도메인)가 위치한다. 코어는 외부와의 모든 통신을 특정 포트(인터페이스)를 통해 수행한다. 외부 세계(예: 웹 클라이언트, 데이터베이스, 메시지 큐)와의 실제 연결은 어댑터가 담당한다. 어댑터는 드라이빙(입력) 어댑터와 드리븐(출력) 어댑터로 구분된다.

계층형 아키텍처가 상하 계층 간의 엄격한 의존성을 가진다면, 헥사고날 아키텍처는 모든 의존성이 코어를 향하도록 한다. 이는 의존성 역전 원칙을 아키텍처 수준에서 적용한 것으로 볼 수 있다. 결과적으로 코어는 완전히 격리되어 테스트하기 쉬워지며, 인프라 변경 시 코어를 수정하지 않고 새로운 어댑터를 교체하거나 추가하기만 하면 된다.

클린 아키텍처는 로버트 C. 마틴(Uncle Bob)이 제안한 소프트웨어 설계 원칙과 계층 구조를 의미한다. 이 아키텍처는 계층형 아키텍처의 한계를 극복하고, 관심사 분리 원칙을 더욱 엄격하게 적용하여 시스템을 비즈니스 규칙을 중심으로 구성하는 것을 목표로 한다. 핵심 아이디어는 의존성 규칙으로, 소스 코드의 의존성은 항상 안쪽으로, 즉 고수준의 정책을 향해야 한다는 것이다.

이 아키텍처는 동심원 형태로 표현되며, 가장 안쪽의 원은 엔티티와 유스 케이스와 같은 비즈니스 로직을 포함한다. 바깥쪽 원으로 갈수록 인터페이스 어댑터, 프레임워크와 드라이버와 같은 저수준의 세부 사항이 위치한다. 이 구조에서 외부 계층(예: 데이터베이스, 웹 프레임워크, UI)은 내부 계층의 변경 없이 쉽게 교체될 수 있어야 한다. 예를 들어, MySQL 데이터베이스를 MongoDB로 변경하거나 웹 프레임워크를 교체하더라도 핵심 비즈니스 규칙은 영향을 받지 않아야 한다.

클린 아키텍처의 주요 구성 요소는 다음과 같다.

이 패턴의 실질적인 이점은 테스트 용이성과 프레임워크 독립성이다. 핵심 로직이 외부 요소에 의존하지 않기 때문에 단위 테스트를 작성하기 매우 쉬워진다. 또한, 애플리케이션의 비즈니스 가치가 외부 라이브러리나 도구의 생명주기에 얽매이지 않도록 보호한다. 그러나 구현에는 더 많은 추상화(인터페이스)와 의존성 관리가 필요하므로, 소규모 또는 단순한 프로젝트에서는 과도한 설계가 될 수 있다는 비판도 존재한다.