사용자 에이전트

사용자를 대신해 요청을 내는 쪽에 서는 프로그램입니다. 웹 브라우저가 가장 익숙한 형태입니다. 사람이 화면 앞에 앉아 있지 않아도 이 자리에 섭니다. 규격 문서가 요청을 시작하는 쪽을 가리킬 때 쓰는 이름입니다.

상세

장을 직접 보러 가지 않고 심부름을 보냅니다. 가게에 들어가 먼저 물건을 달라고 하는 쪽은 심부름꾼이고, 주인이 마주하는 상대도 심부름꾼입니다. 심부름을 맡기만 하면 누구든 심부름꾼입니다.

사용자 에이전트는 요청을 시작하는 클라이언트 프로그램을 통틀어 가리키는 이름입니다. HTTP(HyperText Transfer Protocol) 의미론을 정의한 RFC(Request for Comments) 9110 은 이 말이 요청을 시작하는 여러 클라이언트 프로그램 가운데 어느 것이든 가리킨다고 적습니다. 가장 익숙한 형태는 범용 웹 브라우저입니다. 같은 문서는 그것이 전체 구현 가운데 작은 비율에 지나지 않는다고 곧바로 덧붙입니다. 다른 흔한 사용자 에이전트로 웹을 훑는 로봇, 명령줄 도구, 전광판, 가전제품, 저울, 전구, 펌웨어 갱신 스크립트, 모바일 앱, 온갖 모양과 크기의 통신 기기를 듭니다.

이 이름은 사람이 지금 그 앞에 붙어 있다는 뜻을 담지 않습니다. 같은 문서는 사용자 에이전트라는 것이 요청 시점에 사람 사용자가 그 소프트웨어와 직접 상호작용하고 있음을 뜻하지는 않는다고 적습니다. 많은 경우 백그라운드로 돌도록 설치되거나 설정되어 결과를 나중에 살펴보도록 저장합니다. 그 결과 가운데 흥미롭거나 잘못된 것만 골라 저장하기도 합니다. 웹을 훑는 로봇이 그런 예입니다. 대개 시작 URI(Uniform Resource Identifier) 를 받습니다. 그리고 웹을 하이퍼텍스트 그래프로 삼아 크롤하는 동안 지킬 동작을 설정받습니다.

가르는 기준은 무엇으로 만들어졌나가 아닙니다. 요청을 시작하는 쪽인가입니다. 그래서 이 말은 특정 프로그램의 이름이 아니라 프로그램이 서는 자리의 이름입니다. 사용자를 대신하는 쪽에 이름을 붙여 둔 규격은 웹 하나가 아닙니다. 메일과 통신 규격도 같은 자리에 각자 이름을 정의해 두었습니다.

배경

HTTP 는 클라이언트와 서버로 이루어진 프로토콜입니다. 그런데 RFC 9110 은 클라이언트와 서버라는 말이 특정 연결에서 그 프로그램들이 맡는 역할만 가리킨다고 적습니다. 같은 프로그램이 어떤 연결에서는 클라이언트로, 다른 연결에서는 서버로 행동할 수 있습니다. 요청이 중개자를 거쳐 가면 사슬 위에 놓인 프로그램 대부분이 어느 한 연결에서는 클라이언트입니다. 클라이언트라는 말로는 사슬 맨 끝에서 요청을 처음 낸 쪽을 집어낼 수 없습니다.

규격이 적어야 하는 문장 가운데 그 끝자리를 꼭 집어야 하는 것이 있습니다. 같은 문서는 서버가 한 연결 위의 두 요청이 같은 사용자 에이전트에서 왔다고 가정해서는 안 된다고(must not) 적습니다. 연결이 보안되어 있고 그 에이전트에게 전용일 때만 예외입니다. 방향을 정의할 때도 이 이름이 쓰입니다. 같은 문서는 inbound 를 오리진 서버 쪽, outbound 를 사용자 에이전트 쪽이라고 정의합니다. 반대편 끝도 서버가 아니라 오리진 서버라는 이름을 따로 받았습니다. 같은 문서는 오리진 서버가 주어진 대상 자원에 대해 권위 있는 응답을 만들어 낼 수 있는 프로그램을 가리킨다고 적습니다.

사람을 대신하는 쪽에 이름을 붙이는 어휘는 메일 쪽에도 있습니다. 인터넷 메일 구조를 정리한 RFC 5598 은 MUA(Message User Agent) 가 사용자 행위자와 사용자 애플리케이션을 대신해 일한다고 적습니다. 이메일 서비스 안에서 그들의 대표라고 이어 적습니다. 서로 다른 규격이 사용자를 대신하는 쪽에 같은 어휘를 붙여 두었습니다.

예시

robots.txt 의 User-Agent 줄

로봇 배제 프로토콜을 정의한 RFC 9309 는 크롤러가 자기 이름을 스스로 정한다고 적습니다. 그 이름을 product token 이라고 부릅니다. 대문자와 소문자와 밑줄과 하이픈만 담아야 한다고(must) 적습니다. 이 토큰은 크롤러가 서비스에 보내는 식별 문자열의 부분 문자열이어야 한다고(should) 적습니다. HTTP 의 경우 그 자리가 User-Agent 헤더입니다. 식별 문자열은 크롤러의 목적을 설명해야 한다고 (should) 이어 적습니다.

User-Agent HTTP 헤더	robots.txt user-agent 줄
`User-Agent: Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html)`	`User-Agent: ExampleBot`

같은 문서가 든 값입니다. 괄호 안의 주소가 이 크롤러의 목적을 설명하는 페이지를 가리킵니다. product token 인 ExampleBot 이 User-Agent 헤더 값의 부분 문자열로 들어 있습니다.

User-Agent: *
Disallow: *.gif$
Disallow: /example/
Allow: /publications/

User-Agent: foobot
Disallow:/
Allow:/example/page.html
Allow:/example/allowed.gif

User-Agent: barbot
User-Agent: bazbot
Disallow: /example/page.html

User-Agent: quxbot

EOF

같은 문서가 든 robots.txt 한 벌입니다. 규칙 묶음마다 어느 사용자 에이전트에게 적용되는지를 이 줄이 정합니다.

Cookie 헤더

쿠키를 정의한 RFC 6265 는 사용자 에이전트가 저장해 둔 쿠키를 Cookie HTTP 요청 헤더에 담는다고 적습니다. 하나의 HTTP 요청에 Cookie 헤더 필드를 둘 이상 붙여서는 안 된다고(must not) 적습니다. Cookie 헤더를 통째로 빼도 됩니다(may). 같은 문서가 드는 경우는 서드파티 요청에서 쿠키가 나가는 것을 막고 싶을 때입니다. 헤더를 붙인다면 cookie-string 을 값으로 보내야 한다고(must) 적습니다. 그 문자열을 쿠키 저장소와 요청 URI 로부터 계산하는 절차도 같은 문서가 지정합니다.

언제까지 들고 있을지도 이쪽이 정합니다. 같은 문서는 Max-Age 도 Expires 도 없는 쿠키를 사용자 에이전트가 현재 세션이 끝날 때까지 들고 있는다고 적습니다. 현재 세션이 끝났다는 것이 무엇인지는 사용자 에이전트가 정의한다고 괄호로 못 박습니다.

HTML 렌더링 기본 스타일

WHATWG(Web Hypertext Application Technology Working Group) 가 펴내는 HTML(HyperText Markup Language) Living Standard 의 렌더링 절은 자기 제안을 대체로 CSS(Cascading Style Sheets) 용어로 적습니다. 사용자 에이전트가 CSS 를 지원하거나, 이 절이 주는 CSS 규칙을 다른 표현 수단에 맞는 근사로 옮길 것으로 기대한다고 적습니다. 반대로 지시하는 스타일 계층 규칙이 없을 때 기대하는 바도 적어 두었습니다. 요소가 나타내는 의미가 사용자에게 전달되도록 렌더링하라는 것입니다. 저자 스타일시트가 그런 스타일 계층 규칙의 예입니다.

같은 절의 제안은 대체로 96dpi(dots per inch) 이상 해상도의 시각 출력 매체를 가정합니다. 다만 HTML 은 여러 매체에 적용되도록 의도된 매체 독립 언어라고 적습니다. 그래서 사용자 에이전트 구현자가 이 제안을 자기 대상 매체에 맞게 조정하도록 권장합니다.

메일의 MUA

메일에서는 이 자리가 보내는 쪽과 받는 쪽으로 갈립니다. RFC 5598 은 작성자 MUA(AMUA, Author Message User Agent) 가 메시지를 만들어 MSA(Mail Submission Agent) 를 거쳐 전송 기반 구조로 처음 제출한다고 적습니다. 작성 시점과 게시 시점의 보관을 자기 메시지 저장소에서 수행할 수도 있습니다. 수신자 MUA(RMUA, Recipient Message User Agent) 는 수신자를 대신해 받은 메일을 처리한다고 적습니다.

저장소를 어떻게 묶는지는 정해 두지 않습니다. 같은 문서는 흔한 모델이 폴더라고 부르는 묶음을 쓴다고 적습니다. IMAP(Internet Message Access Protocol) 에서는 그것을 메일박스라고 부릅니다. 초안과 발송 대기와 발송 완료를 각각 폴더로 두는 방식이 가능하지만, 이 폴더들 가운데 어느 것도 필수가 아닙니다.

SIP 의 UAC 와 UAS

SIP(Session Initiation Protocol) 를 정의한 RFC 3261 에서는 같은 소프트웨어가 두 배역을 오갑니다. UAC(User Agent Client) 는 새 요청을 만들어 클라이언트 트랜잭션 상태 기계로 그것을 보내는 논리적 실체입니다. UAS(User Agent Server) 는 SIP 요청에 대한 응답을 만드는 논리적 실체입니다. 그 응답은 요청을 받아들이거나 거절하거나 다른 곳으로 돌립니다.

두 배역은 트랜잭션 하나 동안만 유지됩니다. 같은 문서는 어떤 소프트웨어가 요청을 시작하면 그 트랜잭션 동안 UAC 로 행동한다고 적습니다. 나중에 요청을 받으면 그 트랜잭션의 처리 동안 UAS 배역을 맡습니다. UA(User Agent) 는 UAC 와 UAS 둘 다로 행동할 수 있는 논리적 실체입니다.

소프트웨어 A 가 소프트웨어 B 에게 요청을 내면 그 트랜잭션 동안 A 가 UAC 이고 B 가 UAS 입니다. 뒤에 B 가 A 에게 요청을 내면 같은 두 소프트웨어의 배역이 뒤집힙니다.

sequenceDiagram
    participant A as 소프트웨어 A
    participant B as 소프트웨어 B
    A->>B: 요청을 만들어 보냄
    Note over A,B: 이 트랜잭션 동안 A 가 UAC · B 가 UAS
    B-->>A: 응답을 만들어 보냄
    B->>A: 나중에 요청을 만들어 보냄
    Note over A,B: 이 트랜잭션 동안 B 가 UAC · A 가 UAS

경계

프록시나 게이트웨이도 사용자 에이전트인가. 아닙니다.

RFC 9110 이 이 자리를 가르는 기준은 요청을 시작하는가입니다. 중개자는 요청을 시작하지 않습니다. 받은 요청을 넘깁니다. 같은 문서는 중개자를 세 가지로 나눕니다. 프록시는 클라이언트가 대체로 로컬 설정 규칙으로 골라 두는 메시지 전달 에이전트입니다. 게이트웨이는 바깥쪽 연결에서 오리진 서버처럼 행동하는 중개자입니다. 받은 요청을 옮겨 안쪽의 다른 서버로 전달합니다. 리버스 프록시라고도 부릅니다. 터널은 메시지를 바꾸지 않고 두 연결 사이를 잇는 눈먼 중계입니다. 같은 문서는 터널이 일단 활성화되면 HTTP 통신의 당사자로 여기지 않는다고 적습니다.

flowchart TD
    UA["사용자 에이전트"] --> A["중개자 A"]
    A --> B["중개자 B"]
    B --> C["중개자 C"]
    C --> O["오리진 서버"]

같은 문서가 그린 사슬입니다. 사슬 전체를 지나는 메시지는 별도 연결 네 개를 거칩니다. 요청을 시작한 쪽은 맨 왼쪽 하나뿐입니다.

역할 이름과 헷갈리기 쉬운 자리이기도 합니다. 클라이언트와 서버는 특정 연결에서 맡는 역할입니다. 중개자는 자기가 요청을 넘기는 쪽 연결에서 클라이언트로 행동합니다. 그래도 사용자 에이전트는 아닙니다.

요구사항은 겹치기도 합니다. 같은 문서는 제3자 HTTP 서버와 상호운용하려는 HTTP-to-HTTP 게이트웨이가 그 게이트웨이의 안쪽 연결에서 사용자 에이전트 요구사항을 따를 필요가 있다고 적습니다. 자리를 물려받는 것이 아니라 그 연결에서 지킬 규칙만 같아지는 것입니다.

사용자 에이전트

상세

배경

예시

robots.txt 의 User-Agent 줄

Cookie 헤더

HTML 렌더링 기본 스타일

메일의 MUA

SIP 의 UAC 와 UAS

경계

관련 항목

이것의 하위 종류

자기를 밝히는 수단

이것이 관리하는 상태

이것이 처리하는 응답 동작

이것과 마주하는 반대편 역할

다른 프로토콜에서 이 배역을 가리키는 이름

이것을 정의하는 표준·문서