계층형 아키텍처

계층형 아키텍처란

계층형 아키텍처(Layered Architecture)는 시스템의 책임을 표현·업무·데이터 같은 역할별 계층으로 나누어 쌓아 올리는 전통적 구조다. 사용자와 맞닿는 표현 계층, 핵심 규칙을 담는 업무 계층, 저장과 조회를 담당하는 데이터 계층이 위에서 아래로 정렬되며, 각 계층은 자신의 관심사에만 집중한다.

모든 코드를 한곳에 섞어 두면 화면 변경이 데이터 처리에까지 영향을 미쳐 수정 범위를 가늠하기 어렵지만, 계층을 나누면 변경의 파급을 한 층 안에 가둘 수 있다. 오랫동안 엔터프라이즈 시스템의 기본 골격으로 쓰여 온 만큼 검증되고 이해하기 쉬운 구조라는 점이 강점이다.

관심사의 분리 원칙

계층화의 본질은 관심사의 분리에 있다. 화면을 어떻게 보여줄지, 어떤 규칙으로 처리할지, 데이터를 어디에 어떻게 저장할지를 서로 다른 층의 문제로 떼어 놓는 것이다.

이렇게 분리하면 각 계층을 독립적으로 이해하고 교체할 수 있어, 데이터베이스를 바꾸더라도 업무 규칙이나 화면이 그대로 유지될 여지가 생긴다. 표현 계층과 업무 계층, 모델을 구분하는 MVC 패턴 역시 같은 분리 원칙을 화면 단위에 적용한 사례로 볼 수 있다.

분리가 명확할수록 역할 분담과 병행 개발이 수월해지고, 테스트 또한 계층별로 독립해 작성할 수 있어 결함의 위치를 좁히기 쉽다. 분리의 기준이 흐릿하면 같은 규칙이 여러 층에 중복되거나 어느 층에도 속하지 않는 코드가 생겨, 시간이 지날수록 구조가 흐트러진다.

계층 간 의존 방향

건강한 계층 구조의 핵심은 의존이 한 방향으로만 흐르도록 통제하는 데 있다. 상위 계층은 바로 아래 계층의 기능을 호출하지만, 하위 계층이 상위 계층을 거꾸로 참조해서는 안 된다.

또한 표현 계층이 업무 계층을 건너뛰고 데이터 계층을 직접 호출하면, 계층화가 주는 통제력이 무너져 구조가 형식만 남는다. 이런 우회 호출이 누적되면 겉으로는 계층이 나뉜 듯 보여도 실제로는 모든 층이 서로 얽힌 상태가 된다.

따라서 계층의 경계를 코드 차원에서 강제하는 규율이 설계만큼 중요하다.

분산 구조와의 관계

계층형 아키텍처는 책임을 수평으로 쌓는 구조인 반면, SOA나 MSA는 기능을 서비스 단위로 수직 분할해 독립 배포와 확장을 추구한다. 두 관점은 대립한다기보다 적용 범위가 다르며, 실제로는 마이크로서비스 하나의 내부를 다시 계층형으로 구성하는 경우가 흔하다.

즉 큰 그림에서는 서비스로 나누고, 각 서비스 안에서는 표현·업무·데이터의 계층 규율을 유지하는 식이다. 시스템 전체를 무조건 잘게 쪼개기보다, 변경과 확장의 요구가 명확한 영역부터 선택적으로 분리하는 판단이 필요하다.

분산 구조는 독립 배포의 이점만큼 운영과 통신의 복잡성도 함께 늘리므로, 계층형의 단순함이 여전히 합리적인 영역도 적지 않다.

장점과 한계의 균형

계층형 구조는 이해하기 쉽고 역할이 분명해 유지보수와 인력 교체에 유리하지만, 모든 요청이 여러 층을 순차로 통과하면서 단순한 처리에도 불필요한 중간 단계가 생길 수 있다. 계층을 지나치게 잘게 나누면 한 기능을 구현하는 데 거쳐야 할 코드가 늘어 생산성이 떨어지고, 너무 뭉뚱그리면 분리의 이점이 사라진다.

결국 몇 개의 계층을, 어떤 책임 경계로 나눌지를 시스템의 복잡도에 맞게 정하는 감각이 설계의 핵심이다. 구조 자체의 우열보다 그 경계를 일관되게 지켜내는 규율이 시스템의 수명을 좌우한다.