맨위로가기

다층 구조

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

다층 구조는 1990년대 분산 시스템 환경에서 등장하여 클라이언트-서버 모델과 함께 발전한 아키텍처 개념으로, 사용자 인터페이스, 비즈니스 로직, 데이터베이스를 분리하는 3계층 구조가 일반적이다. 프레젠테이션 계층, 애플리케이션 계층, 비즈니스 계층, 데이터 액세스 계층으로 구성되며, 각 계층은 서로 다른 역할을 수행하며 상위 계층에 기능을 제공한다. 3계층 아키텍처는 사용자 인터페이스, 비즈니스 로직, 데이터베이스를 독립적인 모듈로 개발하고 유지하며, 웹 개발, 특히 전자 상거래 웹사이트 구축에 널리 사용된다. 3층 아키텍처는 모델-뷰-컨트롤러(MVC)와 유사하지만, 통신 방식과 적용 분야에서 차이를 보인다.

더 읽어볼만한 페이지

  • 아키텍처 패턴 - 서비스 지향 아키텍처
    서비스 지향 아키텍처(SOA)는 기능들을 독립적인 서비스 단위로 분리하여 느슨하게 결합함으로써, 네트워크를 통해 접근 가능한 서비스를 재사용하고 결합하여 응용 프로그램을 구축하는 소프트웨어 아키텍처이다.
  • 아키텍처 패턴 - 제어 반전
    제어 반전은 프로그램의 제어 흐름을 프레임워크나 컨테이너가 관리하도록 하는 프로그래밍 원칙으로, 코드 결합도를 낮추고 유연성을 높이지만, 복잡성을 증가시킬 수 있다는 비판도 존재한다.
  • 소프트웨어 공학 - 통합 개발 환경
    통합 개발 환경(IDE)은 코드 편집, 빌드, 디버깅 등 소프트웨어 개발에 필요한 여러 기능을 통합적으로 제공하는 응용 프로그램이다.
  • 소프트웨어 공학 - 소프트웨어 개발
    소프트웨어 개발은 요구사항 분석, 설계, 코딩, 테스트, 배포, 유지보수를 포함하는 컴퓨터 프로그램 및 관련 데이터를 만드는 과정으로, 다양한 방법론과 도구가 사용되며, 개발자 외에도 다양한 전문가들이 참여한다.
  • 월드 와이드 웹 - 구글
    구글은 래리 페이지와 세르게이 브린이 개발한 웹 검색 엔진에서 출발하여 검색 기술 혁신을 통해 유튜브, 안드로이드 등 다양한 서비스를 제공하는 세계적인 기술 기업으로 성장했지만, 개인정보보호 및 독점 논란에도 직면하고 있다.
  • 월드 와이드 웹 - 온라인 언론
    온라인 언론은 인터넷을 통해 뉴스 및 정보를 제공하며, 디지털 기술 발달과 함께 성장하여 시민 저널리즘 부상, 정보 전달 속도 혁신 등의 특징을 보이지만 정보 신뢰성 문제, 전통 언론 쇠퇴 등의 과제를 안고 있다.
다층 구조
개요
유형소프트웨어 아키텍처 패턴
설명애플리케이션을 프레젠테이션 계층, 애플리케이션 계층, 데이터 계층으로 구성하는 클라이언트-서버 소프트웨어 아키텍처
계층 구조
계층 1프레젠테이션 계층 (Presentation tier) 또는 클라이언트 계층 (Client tier)
계층 2애플리케이션 계층 (Application tier) 또는 비즈니스 로직 계층 (Business Logic tier)
계층 3데이터 계층 (Data tier) 또는 데이터베이스 계층 (Database tier)
목적
목적개발, 수정 및 유지 관리를 용이하게 하기 위해 애플리케이션을 분리
이점재사용성
유지보수성
확장성

2. 역사적 배경

3층 애플리케이션 개요.


다층 구조는 사용자 인터페이스, 비즈니스 로직, 데이터베이스를 독립된 모듈로 개발하고 유지하는 구조로, 이들은 일반적으로 각각 다른 플랫폼에서 구동된다. 3층 구조는 2층 구조의 제한을 극복하기 위해 탄생했으며, 사용자 인터페이스 환경과 데이터베이스 관리 서버 환경 사이에 중간층이 추가되었다.[7]

중간층은 트랜잭션 처리 모니터, 메시지 서버, 응용 서버 등 여러 가지 방법으로 구축될 수 있다. 이 중간층은 데이터베이스의 다단계나 응용 프로그램 실행, 사용자 요구 분산을 위한 큐잉을 수행한다. 예를 들어 중간층이 큐 역할을 하면, 클라이언트는 요청을 중간층에 전달하고, 중간층은 서버에 접속하여 응답을 받아 클라이언트에 돌려준다. 이러한 중간층의 역할은 스케줄링을 가능하게 하고, 다수 사용자 요구 처리에 대한 우선순위를 정하여 서버 부하를 줄여준다.

"3계층(three-tier 또는 three-layer)" 또는 "다층 아키텍처"라는 용어는 래셔널에서 기원했다고 알려져 있다.[17][18] 일반적으로 tier는 물리적으로 다른 서버, layer는 소프트웨어상의 역할 분담으로 해석되지만, 영어로 tier라고 쓰여 있어도 소프트웨어적인 역할 분담을 의미하는 경우도 있어 주의가 필요하다.

또한, 시대에 따라 의미의 범위가 변동한다는 점도 유의해야 한다. 예를 들어, 마틴 파울러가 정리한 서적인 애널리시스 패턴(1996)과 엔터프라이즈 애플리케이션 아키텍처 패턴(2002)은 용어 정의에 변천이 있다.

3. 계층의 종류 및 역할



다층 아키텍처는 사용자 인터페이스, 비즈니스 로직, 데이터베이스를 독립된 모듈로 개발하고 유지하는 구조이다. 각 계층은 일반적으로 서로 다른 플랫폼에서 구동된다. 3층 구조는 2층 구조의 제한을 극복하기 위해 사용자 인터페이스와 데이터베이스 관리 서버 환경 사이에 중간층을 추가한 것이다. 중간층은 트랜잭션 처리 모니터, 메시지 서버, 애플리케이션 서버 등 다양한 방법으로 구축될 수 있으며, 데이터베이스 다단계, 애플리케이션 실행, 사용자 요구 분산을 위한 큐잉을 수행할 수 있다. 예를 들어, 중간층이 큐 역할을 하면 클라이언트는 요청을 중간층에 전달하고, 중간층은 서버에 접속하여 응답을 받아 클라이언트에 돌려준다. 이를 통해 스케줄링 및 다수 사용자 요구 처리에 대한 우선순위 결정이 가능해져 서버 부하를 줄일 수 있다.[7]

정보 시스템의 객체 지향 설계에서 가장 일반적인 4가지 계층은 다음과 같다.


  • '''프레젠테이션 계층''' (UI 계층, 뷰 계층)
  • '''애플리케이션 계층''' (서비스 계층[8][9] 또는 GRASP 컨트롤러 계층[10])
  • '''비즈니스 계층''' (비즈니스 로직 계층 (BLL), 도메인 로직 계층)
  • '''데이터 액세스 계층''' (지속성 계층, 로깅, 네트워킹 및 특정 비즈니스 계층 지원에 필요한 기타 서비스)


각 계층은 상위 계층 없이 존재할 수 있지만, 기능을 하려면 하위 계층이 필요하다. 엄격한 계층 시스템에서는 계층이 바로 아래 인접한 계층에만 의존하지만, 느슨한 계층 시스템에서는 모든 하위 계층에 의존할 수 있다.[7] 다중 계층 아키텍처는 일부 계층은 엄격하고 다른 계층은 느슨한 하이브리드 접근 방식을 사용할 수 있다.[13][14]

일반적으로 애플리케이션은 클라이언트-서버 모델의 한 형태로, 여러 소프트웨어 에이전트에 의해 실행된다. 사용자와 데이터베이스 간 데이터 요청 서비스에 미들웨어를 이용하는 애플리케이션은 다층 구조에 해당하며, 대표적인 다층 구조로 3층 구조가 있다.

3. 1. 프레젠테이션 계층 (Presentation Layer)

응용 프로그램의 최상위에 위치하며, 서로 다른 층에 있는 데이터 등과 커뮤니케이션한다.[19][20][21][22] UI 계층, 뷰 계층이라고도 불리는 프레젠테이션 계층은 사용자가 직접 상호작용하는 부분이다. 웹 애플리케이션의 경우, 웹 브라우저에 표시되는 화면이 여기에 해당한다.

일반적으로 데스크톱 PC워크스테이션에서 표준 GUI를 사용하여 동작한다.

3. 2. 애플리케이션 계층 (Application Layer)

애플리케이션 계층은 비즈니스 로직 계층 또는 서비스 계층[8][9]이라고도 불리며, 사용자의 요청을 처리하고 비즈니스 규칙에 따라 데이터를 처리하는 역할을 한다. 이 계층은 프레젠테이션 계층과 데이터 접근 계층 사이의 중간 다리 역할을 수행하며, 시스템의 핵심 기능을 담당한다.[10]

애플리케이션 계층은 일반적으로 지원되는 비즈니스 기능을 노출하는 API 정의를 캡슐화하여 비즈니스 계층의 하위 계층으로 간주된다. 실제로 애플리케이션/비즈니스 계층은 별개의 책임을 강조하기 위해 추가 하위 계층으로 더 세분화될 수 있다. 예를 들어, 모델-뷰-프레젠터 패턴을 사용하는 경우, 프레젠터 하위 계층은 사용자 인터페이스 계층과 비즈니스/애플리케이션 계층 (모델 하위 계층으로 표현됨) 사이에 추가 계층으로 사용될 수 있다.

웹 개발 분야에서 애플리케이션 계층(중간 계층)은 자카르타 EE 플랫폼과 같이 동적 콘텐츠를 생성하는 애플리케이션 서버를 의미한다.

다음은 3층 아키텍처에서의 각 층의 명칭을 나타내는 표이다.

IPA[19]분석 패턴[20]AAfNAAG[21]고전 DDD[22]출처 불명
프레젠테이션 계층Presentation &
Application logic
PresentationPresentationUI로직 계층/비즈니스 로직 계층/트랜잭션 계층
펑션 계층DomainBusinessServicesApplication
---BusinessDomain-
데이터 액세스 계층Data interfaceDataDataInfrastructure데이터베이스 계층


3. 3. 비즈니스 계층 (Business Layer)

비즈니스 로직 계층 (BLL) 또는 도메인 로직 계층이라고도 한다. 애플리케이션의 핵심 비즈니스 로직을 포함하는 계층으로, 특정 업무 규칙 및 프로세스를 정의하고 처리한다.[11] 비즈니스 로직은 워크스테이션으로부터의 클라이언트 요청에 대해 마치 서버처럼 행동한다. 또한 어떤 데이터가 필요한지를 결정하고, 메인프레임 컴퓨터 상에 위치하고 있을 세 번째 계층의 프로그램에 대해서는 마치 클라이언트처럼 행동한다.

일부에서는 비즈니스 계층(들)과 인프라 계층(들) 사이에 위치한 비즈니스 인프라 계층 (BI)이라는 별도의 계층을 식별하기도 한다. 이 계층은 "낮은 수준의 비즈니스 계층" 또는 "비즈니스 서비스 계층"이라고도 하며, 매우 일반적이며 여러 애플리케이션 계층에서 사용될 수 있다 (예: 통화 변환기).[12]

3. 4. 데이터 접근 계층 (Data Access Layer)

데이터베이스, 파일 시스템 등 데이터 저장소에 접근하여 데이터를 읽고 쓰는 역할을 담당하는 계층이다. 데이터 접근 로직을 추상화하여 애플리케이션 계층과의 결합도를 낮추고, 데이터베이스 시스템의 변경에 대한 유연성을 제공한다. 일반적으로 DAO(Data Access Object) 패턴을 사용하여 구현된다.[12] 데이터 계층은 데이터베이스와 그것에 접근해서 읽거나 쓰는 것을 관리하는 프로그램을 포함한다.

4. 3계층 아키텍처 (Three-Tier Architecture)



3계층 아키텍처는 소프트웨어 아키텍처의 한 종류로, 사용자 인터페이스(프레젠테이션 계층), 기능 프로세스 로직(애플리케이션 계층), 데이터 스토리지 및 접근(데이터 계층)을 독립적인 모듈로 개발하고 유지 관리하는 구조이다. 주로 서로 다른 플랫폼에서 운영된다.[15] 이는 존 J. 도노반이 설립한 툴 회사인 Open Environment Corporation (OEC)에서 개발되었다.

3계층 구조는 각 계층을 독립적으로 업그레이드하거나 교체할 수 있어, 요구 사항이나 기술 변화에 유연하게 대응할 수 있다. 예를 들어, 프레젠테이션 계층에서 운영 체제가 변경되어도 사용자 인터페이스 코드만 수정하면 된다.[16]

일반적으로 사용자 인터페이스는 데스크톱 PC 또는 워크스테이션에서 표준 GUI를 통해 실행된다. 기능 프로세스 로직은 하나 이상의 별도 모듈로 구성되어 워크스테이션이나 애플리케이션 서버에서 실행될 수 있다. RDBMS는 데이터베이스 서버 또는 메인프레임에 위치하여 컴퓨터 데이터 스토리지 로직을 포함한다. 중간 계층 자체가 다중 계층일 수 있으며, 이 경우 전체 아키텍처를 "''n''-계층 아키텍처"라고 한다.[16]

3계층 아키텍처는 다음과 같이 구성된다.


  • 프레젠테이션 계층: 애플리케이션의 최상위 수준으로, 상품 검색, 구매, 장바구니 내용 등 서비스 관련 정보를 표시한다. 다른 계층과 통신하며, 사용자에게 결과를 출력한다. 사용자가 직접 접근하는 계층(예: 웹 페이지, 운영 체제의 GUI)이다.
  • 애플리케이션 계층 (비즈니스 로직 계층, 로직 계층, 중간 계층): 프레젠테이션 계층과 분리되어, 상세한 처리를 통해 애플리케이션의 기능을 제어한다.
  • 데이터 계층: 데이터 지속성 메커니즘(데이터베이스 서버, 파일 공유 등)과 이를 캡슐화하고 데이터 접근을 제공하는 데이터 접근 계층을 포함한다. API를 통해 애플리케이션 계층에 저장된 데이터를 관리하는 메서드를 제공한다.


"3계층(three-tier 또는 three-layer)"과 "다층 아키텍처"라는 용어는 래셔널에서 기원했다고 알려져 있다. 일반적으로 tier는 물리적으로 다른 서버, layer는 소프트웨어상의 역할 분담으로 해석되는 경우가 많지만, 영어로 tier라고 쓰여 있어도 소프트웨어적인 역할 분담을 의미하는 경우도 있어 주의가 필요하다.[17][18]

시대에 따라 각 계층의 명칭은 다양하게 표현되어 왔으며 변천이 있어왔다.

IPA[19]분석 패턴[20]AAfNAAG[21]고전 DDD[22]출처 불명
프리젠테이션 계층Presentation &
Application logic
PresentationPresentationUI
펑션 계층DomainBusinessServicesApplication로직 계층/비즈니스 로직 계층/트랜잭션 계층
---BusinessDomain-
데이터 액세스 계층Data interfaceDataDataInfrastructure데이터베이스 계층


4. 1. 웹 개발에서의 활용

3계층 아키텍처는 웹사이트, 특히 전자 상거래 웹사이트 구축에 널리 사용되는 소프트웨어 아키텍처 패턴이다. 이 구조는 프런트엔드 웹 서버, 애플리케이션 서버, 그리고 백엔드 데이터베이스로 구성된다.

  • 프런트엔드 웹 서버: 정적 콘텐츠를 제공한다. 웹 기반 애플리케이션에서 프런트엔드는 브라우저에서 렌더링되는 콘텐츠이며, 정적이거나 동적으로 생성될 수 있다.
  • 애플리케이션 서버: 중간 계층에서 동적 콘텐츠 처리 및 생성을 담당한다. Symfony, 스프링, ASP.NET, Django, Rails, Node.js와 같은 플랫폼이 사용될 수 있다.
  • 백엔드 데이터베이스: 데이터 세트를 관리하고 데이터 접근을 제공하는 데이터베이스 관리 시스템 소프트웨어로 구성된다. 데이터 저장소 역할을 한다.


이러한 3계층 구조는 각 계층을 독립적으로 유지보수하고 확장할 수 있다는 장점을 제공한다. 예를 들어, 기술 변화에 따라 특정 계층만 업그레이드하거나 교체하는 것이 가능하다.[15] [16]

5. 모델-뷰-컨트롤러(MVC) 아키텍처와의 비교

모델-뷰-컨트롤러(MVC)와 겉으로 보기에는 유사하지만, 적용 분야와 토폴로지 측면에서 다르다. 3계층 아키텍처의 기본 원칙은 표현 계층(프리젠테이션 계층)이 데이터 계층과 직접 통신하지 않고, 모든 통신은 반드시 중간 계층을 거쳐야 한다는 것이다. 따라서 3계층은 한 줄의 직선으로 표현된다. 반면, MVC는 모델, 뷰, 컨트롤러 3가지 요소가 서로 상호작용하기 때문에 삼각형을 형성한다.

3계층 아키텍처는 데이터베이스와 사용자 간의 정보 경로를 나타내는 반면, MVC는 사용자 인터페이스에서 화면상의 구성 요소(컴포넌트) 관리 방법을 나타낸다. MVC 기반 컴포넌트는 3계층 아키텍처의 애플리케이션에서도 자주 사용된다.

역사적으로 보면, 3계층 아키텍처는 1990년대웹 애플리케이션 등의 분산 시스템에서 클라이언트, 미들웨어, 데이터베이스의 세 주체가 각각 물리적으로 다른 플랫폼에서 동작하게 되면서 생겨났다. 즉, 구현이 먼저 이루어졌고, 나중에 개념으로 추상화되었다. 한편, MVC는 1980년대 (팔로알토 연구소에서 1970년대 말부터 1980년대 초에 걸쳐)에 하나의 그래픽 워크스테이션에서 동작하는 애플리케이션 구조에서 탄생했다. MVC가 분산 애플리케이션에 적용된(콘텐츠와 표현의 분리가 이루어진) 것은 훨씬 이후의 일이다.

6. 기타 고려 사항

다층 아키텍처에서 계층 간의 데이터 전송은 중요한 요소이며, SNMP, CORBA, Java RMI, .NET 리모팅, Windows Communication Foundation, 소켓, UDP, 웹 서비스 등 다양한 표준 또는 독점 프로토콜이 사용될 수 있다.[7] 별도의 계층을 연결하는 데에는 종종 미들웨어가 사용된다.[7] 별도의 계층은 종종 (반드시 그런 것은 아님) 별도의 물리적 서버에서 실행되며, 각 계층은 자체적으로 클러스터에서 실행될 수 있다.[7]

n계층 시스템에서 데이터 흐름을 종단 간 추적하는 것은 시스템 복잡성이 증가함에 따라 더욱 중요해진다. 애플리케이션 응답 측정은 성능을 측정하고 계층 간의 트랜잭션을 연관시키는 개념과 API를 정의한다.[7]

일반적으로 "계층"이라는 용어는 별도의 서버, 컴퓨터 또는 네트워크(처리 노드)에서 시스템 구성 요소의 물리적 분산을 설명하는 데 사용된다. 따라서 3계층 아키텍처는 세 개의 처리 노드를 갖게 된다. "레이어"라는 용어는 하나의 처리 노드에 물리적으로 위치할 수도 있고 그렇지 않을 수도 있는 구성 요소의 논리적 그룹화를 나타낸다.[7]

참조

[1] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[2] 서적 Software Architecture Patterns O'Reilly Media, Inc.
[3] 웹사이트 Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices) http://msdn.microsof[...]
[4] 논문 Patterns of Enterprise Application Architecture Addison Wesley
[5] 서적 2021 XLVII Latin American Computing Conference (CLEI) 2021
[6] 웹사이트 Deployment Patterns (Microsoft Enterprise Architecture, Patterns, and Practices) http://msdn.microsof[...]
[7] 서적 Pattern-Oriented Software Architecture, Volume 1, A System of Patterns http://www.wiley.com[...] Wiley 1996-08
[8] 웹사이트 Martin Fowler's Service Layer http://martinfowler.[...]
[9] 웹사이트 Martin Fowler explains that Service Layer is the same as Application Layer http://martinfowler.[...]
[10] 웹사이트 Comparison/discussion of the GRASP Controller Layer vs. Application/Service Layer https://archive.toda[...]
[11] 문서 Domain-Driven Design, the Book pp. 68-74 http://www.domaindri[...]
[12] 서적 "Applying UML and Patterns, 3rd edition, page 203" http://www.craiglarm[...]
[13] 서적 Fundamentals of Software Architecture: An Engineering Approach O'Reilly Media
[14] 서적 Software Architecture Patterns O'Reilly Media, Inc
[15] 간행물 "Three Tier Client/Server Architecture: Achieving Scalability, Performance, and Efficiency in Client Server Applications." Open Information Systems 1995-01
[16] 웹사이트 three-tier "{{FOLDOC|three-tier[...]
[17] 웹사이트 3層アーキテクチャーとは - 日本 | IBM https://www.ibm.com/[...]
[18] 웹사이트 エンタープライズ アプリケーションアーキテクチャパターン 第1章 レイヤ化 https://www.shoeisha[...]
[19] 문서 情報処理技術者試験 シラバス(レベル1~3)用語例集 Version 4.0 対応 https://www.ipa.go.j[...]
[20] 문서 アナリシスパターン 再利用可能なオブジェクトモデル 第12章 情報システムの層別化アーキテクチャ
[21] 웹사이트 Microsoft Application Architecture Guide, 2nd Edition Chapter 5: Layered Application Guidelines https://docs.microso[...]
[22] 문서 エリック・エヴァンスのドメイン駆動設計 第4章ドメインを隔離する レイヤ化アーキテクチャ



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com