n-tier

n-tier 는 애플리케이션이 하는 일을 여러 서버에 나눠 맡기는 구조입니다. 화면을 내주는 서버와 업무를 처리하는 서버와 데이터를 담는 서버가 따로 섭니다. 이렇게 나눈 한 부분을 티어라고 부릅니다. 요청은 한 티어에서 바로 다음 티어로 차례차례 넘어갑니다. 덕분에 한 부분만 따로 늘리거나 바꿀 수 있습니다.

쉽고 빠른 이해

n-tier 는 한 애플리케이션을 여러 부분으로 쪼개 부분마다 한 가지 일만 맡깁니다. 이렇게 나눈 한 부분을 티어라고 부릅니다. 쇼핑몰이라면 화면을 만드는 서버, 주문 규칙을 따지는 서버, 주문을 저장하는 데이터베이스 서버가 따로 돕니다.

모든 일을 서버 한 대에 몰면 주문이 몰릴 때 그 한 대를 더 큰 기계로 바꾸는 수밖에 없습니다. 인터넷에서 오는 요청을 받는 그 한 대 안에 데이터베이스도 들어 있으니, 그 서버가 뚫리면 데이터까지 바로 닿습니다.

하는 일마다 티어를 하나씩 둡니다
각 티어는 바로 다음 티어에만 요청을 보냅니다
바쁜 티어에만 서버를 더 붙입니다

대가는 늘어나는 왕복과 서버입니다. 요청 하나가 티어를 지날 때마다 네트워크를 한 번씩 더 건너므로 응답이 느려집니다. 띄우고 지켜볼 서버도 늘어납니다. 그래서 사용자가 적어 서버 한 대로 충분하면 티어를 나누지 않고 한 대로 시작합니다.

상세

티어는 따로 떨어진 기계나 프로세스에서 도는 애플리케이션의 한 부분입니다. 티어끼리는 네트워크로 요청을 주고받습니다. 화면을 만드는 프로그램과 데이터베이스가 서로 다른 서버에서 돈다면 둘은 다른 티어입니다.

n-tier 의 n 은 정해지지 않은 개수를 뜻하는 문자입니다. 티어가 둘이면 2티어, 셋이면 3티어 아키텍처라고 부릅니다. 그 모두를 묶어 부르는 이름이 n-tier 입니다. 멀티티어 아키텍처라고도 부릅니다.

이 절은 쇼핑몰의 주문 조회 기능 하나를 가지고 봅니다. 가장 흔한 세 티어로 나눴을 때 요청이 어떻게 지나가는지 먼저 따라갑니다.

그다음 티어를 나누는 까닭과 그 대가를 봅니다. 끝으로 이름이 비슷한 레이어드와 어떻게 갈리는지, 언제 이 구조를 고르는지 봅니다.

가장 흔한 세 티어

백엔드 애플리케이션을 티어로 나눌 때는 셋으로 나누는 경우가 가장 많습니다. 이름이 문서마다 조금씩 다르므로 이 문서에서 쓸 이름을 먼저 정합니다.

이 문서의 이름	맡는 일	흔히 보는 다른 이름
프레젠테이션 티어	사용자에게 화면을 내주고 입력을 받는다	웹 티어 · 표현 티어
애플리케이션 티어	업무 규칙을 따지고 일의 순서를 정한다	미들 티어 · 비즈니스 티어 · 로직 티어
데이터 티어	데이터를 저장하고 꺼내 준다	데이터베이스 티어 · 저장 티어

프레젠테이션 티어에는 사용자가 보는 화면을 만드는 서버가 듭니다. 웹이라면 화면을 만들어 내주는 웹 서버가 여기 속합니다.

이 티어는 업무 규칙을 따지지 않습니다. 받은 입력을 애플리케이션 티어에 넘깁니다. 돌아온 결과를 화면으로 바꿀 뿐입니다.

애플리케이션 티어는 업무를 처리하는 프로그램이 도는 서버입니다. 이런 서버를 애플리케이션 서버라고 부릅니다.

이 티어가 다루는 규칙을 비즈니스 로직이라고 합니다. 「다른 사람의 주문은 보여 주지 않는다」처럼 화면이나 저장 기술과 상관없이 업무가 정한 규칙입니다.

데이터 티어는 데이터베이스 서버입니다. 애플리케이션 티어가 데이터를 달라고 하면 꺼내 줍니다. 저장하라고 하면 저장합니다. 주문 규칙은 모릅니다.

요청이 티어를 지나가는 순서

사용자가 주문 7번을 열어 보면 요청은 위 티어에서 아래 티어로 한 칸씩 내려갑니다. 결과는 같은 길을 거꾸로 올라옵니다. 아래 그림이 그 순서입니다.

sequenceDiagram
    participant U as 사용자
    participant P as 프레젠테이션 티어
    participant A as 애플리케이션 티어
    participant D as 데이터 티어
    U->>P: 주문 7번 화면 요청
    P->>A: 주문 7번을 달라
    A->>D: 주문 7번 조회
    D-->>A: 주문 데이터
    Note over A: 요청한 사람의 주문인지 따진다
    A-->>P: 주문 내용
    Note over P: 받은 내용으로 화면을 만든다
    P-->>U: 주문 화면

티어마다 한 가지 일만 했습니다. 프레젠테이션 티어는 화면만 만들었습니다. 주인을 따지는 일은 애플리케이션 티어가 했습니다. 데이터 티어는 데이터를 꺼내기만 했습니다.

화살표 하나하나는 네트워크를 건너는 요청입니다. 같은 프로그램 안의 함수 호출과는 다릅니다. 다른 서버로 메시지를 보낸 뒤 답을 기다립니다.

바로 다음 티어만 부르는 규칙

그림에서 프레젠테이션 티어는 데이터 티어에 직접 요청하지 않았습니다. 반드시 애플리케이션 티어를 거쳤습니다. 각 티어가 바로 다음 티어만 부르는 것이 n-tier 의 기본 규칙입니다.

이 규칙을 지키는 까닭은 업무 규칙이 빠지지 않게 하려는 것입니다. 화면 쪽이 데이터베이스를 바로 읽으면 「다른 사람의 주문은 보여 주지 않는다」는 검사를 건너뜁니다. 그러면 남의 주문이 화면에 나갈 수 있습니다.

규칙을 지키면 데이터베이스에 접속하는 쪽이 애플리케이션 티어 하나로 줄어듭니다. 데이터베이스 주소와 비밀번호도 애플리케이션 티어만 압니다. 화면 쪽 서버가 뚫려도 데이터베이스까지 바로 닿지는 못합니다.

티어를 나누는 까닭

첫째 까닭은 티어마다 서버 수를 따로 정할 수 있다는 점입니다. 주문이 몰리면 바빠지는 쪽은 대개 업무 규칙을 따지는 애플리케이션 티어입니다. 그 티어에만 서버를 더 붙입니다.

같은 일을 하는 서버를 여러 대로 늘려 일을 나눠 받게 하는 방법을 수평 확장이라고 합니다. 기계 한 대를 더 큰 것으로 바꾸는 대신 대수를 늘리는 방식입니다.

서버가 여러 대가 되면 들어온 요청을 어느 서버에 보낼지 정해야 합니다. 그 일을 하는 장치가 로드 밸런서입니다. 로드 밸런서는 티어 사이에 서서 요청을 고르게 나눕니다.

flowchart TD
    U["사용자"] --> P["프레젠테이션 티어"]
    P --> LB["로드 밸런서"]
    subgraph AT["애플리케이션 티어 · 서버 세 대"]
        A1["서버 1"]
        A2["서버 2"]
        A3["서버 3"]
    end
    LB --> A1
    LB --> A2
    LB --> A3
    A1 --> D[("데이터 티어")]
    A2 --> D
    A3 --> D

그림에서 애플리케이션 티어만 세 대로 늘었습니다. 프레젠테이션 티어와 데이터 티어는 한 대 그대로입니다. 티어가 한 덩어리였다면 화면과 데이터베이스까지 함께 세 벌을 띄워야 했습니다.

둘째 까닭은 따로 바꿀 수 있다는 점입니다. 티어끼리 주고받는 요청 모양만 지키면 한 티어의 서버를 새로 올려도 다른 티어는 손대지 않습니다. 화면을 고칠 때 애플리케이션 티어를 다시 띄울 필요가 없습니다.

셋째 까닭은 보안 경계입니다. 티어마다 다른 네트워크 구역에 둘 수 있습니다. 바깥 인터넷에는 프레젠테이션 티어만 드러냅니다. 데이터 티어는 방화벽 안쪽에 둡니다. 애플리케이션 티어에서 오는 요청만 받게 합니다.

n-tier 가 치르는 대가

티어를 나누면 요청이 지나가는 길이 길어집니다. 굴릴 서버도 늘어납니다. 그 대가는 셋입니다.

첫째는 늘어나는 지연 시간입니다. 지연 시간은 요청을 보내고 답을 받기까지 걸리는 시간입니다. 티어를 하나 지날 때마다 네트워크를 한 번 더 건너므로 응답이 그만큼 늦어집니다. 티어를 잘게 나눌수록 이 왕복이 쌓입니다.

둘째는 늘어나는 고장 지점입니다. 티어 하나가 멈추면 그 아래를 거쳐야 하는 요청은 전부 실패합니다. 데이터 티어가 한 대뿐이면 그 한 대가 멈출 때 서비스 전체가 멈춥니다. 이렇게 혼자 멈춰도 전체를 세우는 부분을 단일 장애 지점이라고 부릅니다.

셋째는 기능 하나가 모든 티어를 가로지른다는 점입니다. 주문 화면에 「배송 메모」 칸을 하나 더하면 데이터 티어의 테이블, 애플리케이션 티어의 규칙, 프레젠테이션 티어의 화면을 차례로 고칩니다. 티어를 기능이 아니라 기술의 역할로 나눴기 때문입니다.

두 티어와 네 티어 이상

티어는 셋보다 적게도, 많게도 나눕니다. 이 소절은 둘로 나눈 구조와 넷 이상으로 나눈 구조를 차례로 다룹니다.

티어가 둘인 구조로 가장 흔한 것은 사용자 쪽 프로그램이 데이터베이스에 바로 붙는 모양입니다. 사무실 컴퓨터마다 깔린 프로그램이 회사 데이터베이스를 직접 읽고 쓰는 식입니다. 이 모양을 흔히 클라이언트-서버 구조라고 부릅니다.

이 모양에서는 업무 규칙이 사용자 컴퓨터마다 깔린 프로그램 안에 있습니다. 규칙 하나를 바꾸려면 모든 컴퓨터의 프로그램을 새로 깔아야 합니다. 데이터베이스 접속 정보도 컴퓨터마다 들어 있습니다. 가운데에 애플리케이션 티어를 끼운 것이 세 티어가 나온 까닭입니다.

네 티어 이상은 세 티어에 티어를 하나 더 보탠 것입니다. 사용자의 브라우저에서 도는 화면 코드를 티어 하나로 따로 세는 것이 한 예입니다. 그러면 브라우저, 웹 서버, 애플리케이션 서버, 데이터베이스 서버로 네 티어가 됩니다.

애플리케이션 티어와 데이터 티어 사이에 캐시 티어를 끼우는 것도 그렇습니다. 캐시는 자주 읽는 값을 담아 둡니다. 몇 개로 나누든 하는 일마다 티어 하나를 두고 바로 다음 티어만 부른다는 생각은 같습니다.

계층과 티어

n-tier 와 자주 섞이는 이름이 레이어드입니다. 둘 다 위아래로 나눕니다. 부를 때도 위에서 아래로만 부릅니다. 갈리는 것은 무엇을 나누느냐입니다.

레이어드는 한 프로그램 안의 코드를 나눕니다. 이렇게 나눈 코드 한 덩이를 계층이라고 부릅니다. 요청을 받는 컨트롤러, 업무 규칙을 따지는 서비스, 데이터베이스를 읽는 리포지토리가 흔한 세 계층입니다. 이 셋이 한 프로세스 안에서 한꺼번에 돌아도 레이어드입니다.

n-tier 는 프로그램이 도는 기계를 나눕니다. 그래서 둘은 겹쳐 쓸 수 있습니다. 애플리케이션 티어 하나 안의 코드를 다시 계층으로 나누는 구성이 흔합니다.

flowchart TD
    P["프레젠테이션 티어"] --> C
    subgraph AT["애플리케이션 티어 · 서버 한 대"]
        C["컨트롤러 계층"] --> S["서비스 계층"]
        S --> R["리포지토리 계층"]
    end
    R --> D[("데이터 티어")]

그림의 세 계층은 애플리케이션 티어 하나 안에 모두 들어 있습니다. 계층 사이의 호출은 같은 프로세스 안의 함수 호출입니다. 티어 사이의 호출만 네트워크를 건넙니다. 우리말로 둘 다 「계층」이라 부르는 일이 많아서 자주 헷갈립니다.

고를 만한 상황과 다른 길을 볼 상황

n-tier 는 웹 애플리케이션의 오래된 기본 구성입니다. 화면, 업무 규칙, 데이터가 뚜렷이 갈리는 애플리케이션에 잘 맞습니다. 바빠지는 쪽이 한 티어에 몰리면 그 티어만 늘리면 됩니다. 티어가 셋뿐이라 새로 온 사람도 무엇이 어디서 도는지 짐작합니다.

기능이 많아지고 팀이 여럿으로 늘면 셋째 대가가 커집니다. 기능 하나를 고칠 때마다 모든 티어를 건드립니다. 그 티어들을 함께 배포하게 됩니다.

이때는 시스템을 기술의 역할이 아니라 업무 단위로 자르는 마이크로서비스를 봅니다. 주문, 결제, 배송을 각각 따로 배포하는 프로그램으로 나누는 방식입니다. n-tier 가 가로로 자른다면 마이크로서비스는 세로로 자릅니다.

반대로 사용자가 적고 서버 한 대로 충분하면 티어를 나누는 대가만 남습니다. 화면과 업무 규칙을 한 프로그램으로 묶어 한 번에 배포하는 모놀리스로 시작해도 됩니다. 모놀리스로 지어도 데이터베이스는 대개 다른 서버에 둡니다. 그러면 모놀리스 서버와 데이터베이스 서버, 이렇게 티어 둘로 나뉩니다.

n-tier

상세

가장 흔한 세 티어

요청이 티어를 지나가는 순서

바로 다음 티어만 부르는 규칙

티어를 나누는 까닭

n-tier 가 치르는 대가

두 티어와 네 티어 이상

계층과 티어

고를 만한 상황과 다른 길을 볼 상황

관련 항목

n-tier 를 이루는 티어

티어마다 놓이는 서버와 장치

티어 수로 갈리는 n-tier 의 하위 종류

n-tier 가 기대는 원칙과 성질

n-tier 를 나눌 때 치르는 비용

n-tier 와 맞세워지는 아키텍처 양식

n-tier 가 속하는 상위 분류

n-tier 의 티어와 헷갈리는 이름