응용 계층

응용 계층은 네트워크에서 프로그램끼리 주고받는 내용이 무슨 뜻인지 정합니다. 웹 브라우저의 요청을 웹 서버가 알아듣는 것도 둘이 이 계층의 약속을 함께 따르기 때문입니다. 아래 계층들은 데이터를 상대 프로그램까지 실어 나를 뿐 내용은 들여다보지 않습니다. 소프트웨어 설계에서 같은 이름으로 부르는 계층은 이 문서가 다루는 것과 다릅니다.

상세

택배 기사는 상자를 받는 사람의 집 앞까지 가져다줍니다. 상자 안의 주문서를 읽고 무엇을 보내 달라는 것인지 알아듣는 일은 받는 사람의 몫입니다. 주문서를 쓰는 사람과 읽는 사람은 같은 양식을 알고 있어야 합니다.

응용 계층(application layer)은 네트워크 통신을 여러 계층으로 나눈 모델에서 맨 위에 있는 계층입니다. 아래 계층들이 데이터를 상대 컴퓨터의 프로그램까지 옮겨 놓습니다. 그런데 아래 계층이 건네는 것은 뜻 없는 바이트일 뿐입니다. 어디서 끊어 무엇으로 읽을지는 응용 계층이 정합니다.

이 계층의 약속을 응용 계층 프로토콜이라고 부릅니다. 프로토콜은 둘이 데이터를 주고받는 순서와 형식을 정해 둔 규칙입니다. 웹 페이지를 주고받는 HTTP(HyperText Transfer Protocol, 하이퍼텍스트 전송 프로토콜)가 대표입니다.

네트워크 계층 모델의 맨 위

네트워크 소프트웨어는 통신을 여러 계층으로 나눠 계층마다 한 가지 일만 맡깁니다. 인터넷이 쓰는 모델은 네 계층입니다. 보낼 메시지는 맨 위 응용 계층에서 만들어져 아래 계층으로 차례로 내려갑니다.

전송 계층에서는 TCP(Transmission Control Protocol, 전송 제어 프로토콜)가, 인터넷 계층에서는 IP(Internet Protocol, 인터넷 프로토콜)가 대표 프로토콜입니다. 이 모델은 두 이름을 따서 TCP/IP 모델이라고 부릅니다.

네트워크를 설명할 때 자주 쓰는 OSI(Open Systems Interconnection, 개방형 시스템 상호연결) 7계층 모델에서도 응용 계층은 맨 위인 7번째 계층입니다. 그래서 실무에서는 이 계층을 L7(Layer 7, 7계층)이라고도 부릅니다.

OSI 모델은 응용 계층 아래에 표현 계층과 세션 계층을 따로 둡니다. 표현 계층은 데이터를 어떤 형식으로 적을지를 맡습니다. 세션 계층은 대화를 언제 열고 닫을지를 맡습니다.

TCP/IP 모델에는 이 두 계층이 없습니다. 그 일이 필요하면 응용 계층 프로토콜이 스스로 맡습니다.

응용 계층 프로토콜이 정하는 네 가지

응용 계층 프로토콜 하나는 대화에 필요한 약속을 미리 정해 둡니다. 아래 표로 그 약속을 추린 뒤 HTTP 메시지 한 벌로 확인합니다.

두 프로그램이 대화하려면 네 가지를 똑같이 알고 있어야 합니다. 어떤 메시지가 오가는지, 메시지를 어떤 칸으로 나누는지, 칸의 값이 무슨 뜻인지, 누가 언제 보내는지입니다.

표의 네 줄이 실제 메시지에서 어떻게 보이는지 봅니다. 아래는 클라이언트가 서버에 사용자 42번의 정보를 달라고 보내는 HTTP 요청입니다. 네트워크로 나가는 것은 이 글자들 그대로입니다.

GET /users/42 HTTP/1.1
Host: api.example.com
Accept: application/json

첫 줄은 무엇을 할지와 대상을 적습니다. GET 은 가져오라는 뜻입니다. /users/42 가 가져올 대상입니다.

다음 줄들은 헤더입니다. 헤더는 이름: 값 꼴로 적는 부가 정보입니다. 빈 줄 하나가 헤더의 끝을 알립니다.

서버는 같은 약속으로 이 글자를 읽고 응답을 적어 돌려보냅니다.

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "name": "kim"}

응답 첫 줄의 200 은 요청이 성공했다는 상태 코드입니다. 빈 줄 뒤는 본문입니다. 여기서는 JSON(JavaScript Object Notation, 자바스크립트 객체 표기법)으로 적은 사용자 정보가 들었습니다.

두 메시지를 표의 네 줄에 다시 대 봅니다. 오간 메시지는 요청과 응답 두 종류였습니다. 200 이 성공을 뜻하는 것은 의미의 약속입니다. 클라이언트가 먼저 묻고 서버가 답한 것은 순서의 약속입니다.

글자로 적는 메시지와 이진 메시지

방금 본 HTTP 메시지는 사람이 읽을 수 있는 글자로 적혀 있습니다. 메일을 보내는 SMTP(Simple Mail Transfer Protocol, 간이 메일 전송 프로토콜)도 같은 방식입니다. 글자로 적으면 사람이 메시지를 눈으로 읽고 손으로 쳐서 시험해 볼 수 있습니다.

반대로 메시지의 칸을 바이트 단위로 정해 두는 프로토콜도 있습니다. 이런 메시지를 이진 메시지라고 부릅니다. 이진 메시지는 크기가 작고 기계가 읽기 빠릅니다. 대신 사람이 읽으려면 도구로 풀어 봐야 합니다. 같은 HTTP 도 HTTP/2부터는 이진 메시지로 바꿨습니다.

대표 프로토콜과 포트 번호

응용 계층 프로토콜은 쓰임새마다 따로 있습니다. 아래 표에 백엔드에서 자주 만나는 것들을 모았습니다. 표의 「쓰는 전송 계층 프로토콜」과 「기본 포트」가 무엇인지 먼저 짚습니다.

「쓰는 전송 계층 프로토콜」은 메시지를 실어 보낼 때 아래에서 쓰는 프로토콜입니다. TCP 는 빠진 조각을 다시 보내 순서대로 넘겨 줍니다. UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 연결을 맺는 절차 없이 바로 보냅니다. 빠진 조각은 챙기지 않습니다.

「기본 포트」는 포트 번호입니다. 포트 번호는 한 컴퓨터 안에서 통신하는 프로그램들을 가려내는 번호입니다. 서버 프로그램은 프로토콜마다 관례로 정해진 번호에서 메시지를 기다립니다.

표에서 보듯 응용 계층 프로토콜은 아래 전송 계층을 골라 씁니다. 웹 페이지와 메일은 한 글자도 빠지면 안 되므로 TCP 를 씁니다. DNS 와 NTP 는 짧은 질문 하나에 짧은 답 하나로 끝나므로 UDP 를 주로 씁니다.

클라이언트는 말을 걸 상대 프로그램의 포트 번호를 골라 적습니다. 받는 컴퓨터의 전송 계층이 그 번호를 보고 메시지를 건넬 프로그램을 가려냅니다. 어느 번호를 고를지는 응용 계층 프로토콜의 관례가 정합니다.

프로그램 안에서 도는 유일한 계층

전송 계층부터 그 아래는 대개 운영체제의 커널이 처리합니다. 데이터를 조각내고 주소와 포트 번호를 덧붙이는 일도 커널이 맡습니다. 응용 계층만은 우리가 짜는 프로그램 안에서 처리됩니다. 브라우저·웹 서버·메일 서버 같은 응용 프로그램이 메시지를 직접 만들고 읽습니다.

두 쪽의 경계는 소켓입니다. 소켓은 운영체제가 프로그램에 내주는 통신 창구입니다. 프로그램은 만든 메시지를 소켓에 씁니다. 도착한 메시지도 소켓에서 읽습니다.

flowchart TD
    subgraph P["응용 프로그램 안"]
        A["응용 계층 · 메시지를 만들고 읽는다"]
    end
    subgraph K["운영체제 커널 안"]
        B["전송 계층"] --> C["인터넷 계층"]
        C --> D["링크 계층"]
    end
    A -->|"소켓에 쓴다"| B

그래서 백엔드 개발자가 짜는 코드는 대부분 이 계층에 있습니다. 웹 프레임워크가 HTTP 요청을 읽어 우리 함수에 넘깁니다. 함수가 돌려준 값은 프레임워크가 HTTP 응답으로 적어 보냅니다. 요청 경로와 헤더와 상태 코드를 다루는 일이 모두 응용 계층의 일입니다.

새 응용 계층 프로토콜을 만들 때는 운영체제를 고칠 필요가 없습니다. 양쪽 프로그램이 같은 약속만 알면 됩니다. 인터넷에 응용 계층 프로토콜이 유난히 많은 까닭입니다. 대신 프로그램 종류마다 약속을 따로 정하고 양쪽에 구현해야 합니다.

웹의 암호화 통신은 HTTP 메시지를 TLS(Transport Layer Security, 전송 계층 보안)로 감싸 보냅니다. TLS 는 이름에 전송 계층이 들어 있습니다. 그래도 커널이 아니라 프로그램이 불러 쓰는 라이브러리가 처리합니다. 그래서 흔히 응용 계층과 전송 계층 사이에 끼운 계층으로 봅니다.

응용 계층까지 읽는 중간 장비

클라이언트와 서버 사이에는 여러 장비가 끼어 있습니다. 대개는 아래 계층이 덧붙인 주소와 포트 번호까지만 보고 데이터를 넘깁니다. 그 가운데 몇몇은 응용 계층 메시지까지 풀어 읽습니다.

로드 밸런서는 요청을 여러 서버에 나눠 보내는 장비입니다. 그 가운데 L7 방식은 HTTP 요청의 경로와 헤더를 읽고 보낼 서버를 고릅니다. /images 로 시작하는 요청은 이미지 서버로, 나머지는 다른 서버로 보내는 식입니다.

리버스 프록시도 HTTP 메시지를 읽습니다. 서버 앞에 서서 요청을 먼저 받습니다. 경로를 바꾸거나 로그인 여부를 확인한 뒤 서버로 넘깁니다.

API(Application Programming Interface, 응용 프로그램 인터페이스)는 프로그램이 다른 프로그램을 부르는 통로입니다. 서비스가 여럿이면 각 서비스의 API 앞에 이런 일을 한데 모아 맡는 장비를 둡니다. 이 장비를 API 게이트웨이라고 부릅니다.

내용을 읽는 만큼 장비가 할 일이 늘어납니다. 메시지를 끝까지 받아 풀어 봐야 합니다. TLS 로 암호화된 연결이면 먼저 암호를 풀어야 합니다. 포트 번호만 보고 넘기는 L4(Layer 4, 4계층) 장비에는 이 일이 없습니다.

같은 이름을 쓰는 설계의 계층

백엔드 코드를 설계할 때도 응용 계층이라는 말을 씁니다. 계층형 아키텍처에서 요청을 받는 계층과 업무 규칙을 담는 도메인 계층 사이의 계층을 가리킵니다. 이 계층은 요청 하나를 받아 도메인 객체들에 일을 순서대로 시킵니다. 트랜잭션을 열고 닫는 일도 여기서 합니다.

이 계층은 네트워크의 응용 계층과 이름만 같습니다. 코드 구조를 이야기하다가 응용 계층이나 응용 서비스라는 말이 나오면 이쪽 뜻입니다.

관련 항목

응용 계층 아래에 쌓이는 계층

전송 계층 · 인터넷 계층 · 링크 계층 · 네트워크 계층 · 물리 계층 · 데이터 링크 계층

응용 계층을 어디에 둘지 정하는 계층 모델

TCP-IP 모델 · OSI 7계층 · 표현 계층 · 세션 계층 · 계층 · 프로토콜 스택 · 인터넷 프로토콜 스위트

응용 계층에서 일하는 프로토콜

HTTP · HTTP-2 · HTTP-3 · SMTP · IMAP · POP3 · DNS · NTP · SSH · FTP · DHCP · SNMP · MQTT · WebSocket · gRPC · 응용 계층 프로토콜

응용 계층 메시지를 이루는 구성 요소

메시지 · 헤더 · 상태 코드 · HTTP 메서드 · 직렬화 · JSON · 메시지 경계

응용 계층 메시지를 실어 나르는 전송 프로토콜

TCP · UDP · QUIC · SCTP

응용 계층과 전송 계층을 잇는 장치

소켓 · 포트 · 잘 알려진 포트 · TLS · ALPN

응용 계층 메시지를 읽는 중간 장비

로드 밸런서 · L7 로드 밸런싱 · 리버스 프록시 · API 게이트웨이 · 프록시 · 웹 애플리케이션 방화벽 · CDN

응용 계층 프로토콜이 따르는 통신 구조

클라이언트-서버 모델 · P2P · 요청-응답 · 클라이언트 · 서버

응용 계층과 이름이 겹치는 설계 용어

계층형 아키텍처 · 도메인 주도 설계 · 응용 서비스 · 도메인 계층 · 트랜잭션