프로토콜은 원래 풀로 붙인 종이였다 — 접속 한 번에 다 등장하는 다섯 단어의 내력

이 글의 위치: 영어(English) → 어원(Etymology) → 개발 영어(Developer English)
어원은 Online Etymology Dictionary 원문과 Cambridge Dictionary 로 대조했고, 사전에서 확인되지 않는 대목은 그렇게 표시했다. 측정값은 전부 내 서버(seongwon.net)에서 직접 뽑았다. 기준은 Editorial Policy 참조.

접속 한 번에 오간 것

브라우저 주소창에 도메인을 치면 화면이 뜨기까지 대개 1초가 안 걸린다. 그 사이에 실제로 무엇이 오가는지, 내 서버에 직접 붙어서 받아봤다.

$ echo Q | openssl s_client -connect seongwon.net:443 \
             -servername seongwon.net -alpn h2,http/1.1

SSL handshake has read 4753 bytes and written 1654 bytes
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
ALPN protocol: h2
    Session-ID: 505E4232952504183A11569E669030C4...
    TLS session ticket lifetime hint: 300 (seconds)
    Verify return code: 0 (ok)

여섯 줄 안에 이 글에서 다룰 다섯 단어가 전부 들어 있다. handshake(4,753바이트를 읽고 1,654바이트를 씀), protocol(TLSv1.2, 그리고 ALPN이 고른 h2), 협상의 결과인 암호 방식(negotiation), session(ID와 300초짜리 티켓), 그리고 주소창의 https:라는 scheme.

재미있는 건 다섯 개 중 어느 것도 컴퓨터가 만든 말이 아니라는 점이다. 전부 다른 세계에서 빌려왔고, 빌려올 때 원래 뜻의 어떤 부분을 가져왔는지가 지금 그 단어의 성격을 정한다. 오래된 것부터 순서대로 따라가 본다.

2세기 — 두루마리 맨 앞에 풀로 붙인 종이

protocol의 뿌리는 그리스어 prōtokollon이다. prōtos(첫)와 kolla(풀)가 붙은 말로, 뜻은 문자 그대로 "맨 앞에 풀로 붙인 낱장"이다. 파피루스 두루마리를 말 때 제일 앞에 한 장을 덧붙여, 그 안에 무엇이 들어 있는지와 정오표를 적었다. 오늘날로 치면 표지이자 목차다.

뜻이 옮겨 앉은 경로가 선명하다.

시기	뜻
그리스·중세 라틴	두루마리 맨 앞 낱장 (`protocollum`)
15세기 중엽	서문·프롤로그
1540년대	문서의 초안, 거래의 회의록
—	조약의 원본 → 공식 기록 → 외교 문서
1896년	외교 의전의 격식
1952년	일반적인 "지켜야 할 관례"

컴퓨팅이 이 단어를 가져온 건 맨 마지막이다. 그러니까 네트워크 프로토콜은 "통신 내용"이 아니라 "통신을 어떻게 다룰지 앞장에 적어 둔 약속" 이라는 뜻을 그대로 물려받았다. TLS 레코드 안에 실린 HTML이 본문이라면, TLSv1.2나 h2 같은 이름은 두루마리 맨 앞의 그 종이에 해당한다.

kolla(풀)의 어원 자체는 불확실하다고 사전이 밝히고 있다. 다만 "낱장 → 초안 → 공식 기록 → 의전 → 관례"로 이어지는 의미 이동은 문헌으로 확인된다.

ALPN이라는 이름을 이 눈으로 다시 읽으면 재미있다. Application-Layer Protocol Negotiation — "앞장에 뭐라고 적을지를 먼저 정하자"는 뜻이 된다. 위 출력에서 그 결과가 h2였다.

13세기 — 법정은 열리는 게 아니라 앉는 것이었다

session은 라틴어 sedere(앉다)에서 왔다. sessionem은 "앉아 있는 행위, 한 번 앉음"이다. 재판이나 의회를 두고 지금도 "session이 열린다"고 하는데, 어원으로는 사람들이 그 자리에 앉아 있는 동안을 가리킨다. 앉아 있으면 열린 것이고, 일어서면 끝난 것이다.

같은 뿌리에서 나온 단어들을 보면 감각이 잡힌다.

sedentary — 앉아 지내는
assess — ad(곁에) + sedere, 재판관 옆에 앉아 세금을 매기던 사람에서
siege — 성 앞에 눌러앉아 있는 것. 포위란 결국 앉아 버티는 일이다
preside — prae(앞에) + sedere, 앞자리에 앉다 → 주재하다

웹의 세션이 왜 하필 이 이름인지가 여기서 풀린다. HTTP 자체는 요청 하나가 끝나면 서로를 잊는다. 그런데 "당신이 아직 그 자리에 앉아 있다" 고 기억해 주는 장치가 필요했고, 그게 세션이다. 위 출력의 TLS session ticket lifetime hint: 300은 어원 그대로 읽으면 "이 자리는 5분간 당신 것" 이라는 뜻이다.

실제로 그런지 확인해봤다. 같은 서버에 연달아 붙으면서 티켓을 재사용하도록 하면 이렇게 나온다.

$ echo Q | openssl s_client -connect seongwon.net:443 \
             -servername seongwon.net -reconnect

New,    TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384

처음 한 번만 New이고 나머지 다섯 번은 전부 Reused다. 자리를 새로 잡지 않고 앉아 있던 자리로 돌아간 것이다. 앉기까지가 비싸고 앉아 있는 동안은 싸다는 게 세션이라는 개념의 핵심인데, 단어가 그걸 이미 말하고 있었다.

16세기 — 겉으로 드러난 모양

scheme은 그리스어 skhēma(형태·모양·겉모습)에서 왔다. 더 거슬러 가면 ekhein(가지다·지니다), 즉 "어떤 상태를 지니고 있음"이다. 영어에 들어올 때는 수사학 용어였다 — 문장이 취하는 형태를 가리켰다. "계획"이나 "책략"이라는 지금의 뜻은 17세기에 붙은 것이고, 원래는 훨씬 중립적인 "모양"이었다.

그래서 URI의 scheme은 오히려 원뜻에 가장 가깝게 남은 용법이다.

https://seongwon.net/dao-dto-vo-overview/
└─┬─┘
  scheme — 내용이 아니라 "이걸 어떤 형식으로 다룰지"를 알리는 표지

https:는 무엇을 가져올지 말하지 않는다. 어떤 모양으로 다룰지를 말한다. mailto:, file:, data:도 마찬가지다. 계획이나 음모라는 뜻으로만 이 단어를 알고 있으면 URI 명세의 "scheme"이 뜬금없어 보이는데, 어원으로는 이쪽이 본가다.

1590년대 — 여가가 없는 상태

negotiation의 뿌리는 라틴어 negotium이고, 이건 neg-(아닌) + otium(여유·한가함)이다. 그러니까 어원 그대로는 "한가하지 않음", 곧 일거리다. 로마인은 여가(otium)를 기본값으로 두고, 그 여가가 없는 상태를 사업이라 불렀다. 영어에는 1590년대에 "합의를 찾아 서로 소통하다"라는 뜻으로 들어왔고, 1862년에는 사냥에서 "울타리를 무사히 넘다"라는 뜻까지 뻗었다. 지금 "협상을 잘 넘겼다"고 말할 때의 그 어감이 여기서 왔다.

TLS 핸드셰이크의 cipher suite 협상은 이 단어의 뜻을 거의 문자 그대로 수행한다. 클라이언트가 자기가 지원하는 목록을 내밀고, 서버가 그중 하나를 고른다. 위 출력의 결과가 이것이었다.

Cipher is ECDHE-RSA-AES256-GCM-SHA384
         └ 키교환 ECDHE · 인증 RSA · 암호 AES-256-GCM · 해시 SHA-384

협상은 TLS에만 있는 게 아니다. HTTP도 매 요청마다 조용히 협상한다. 내 서버에 같은 페이지를 서로 다른 조건으로 요청해봤다.

보낸 헤더	받은 응답	해석
`Accept-Encoding: gzip`	`Content-Encoding: gzip`	가능하니 압축해서 준다
`Accept-Encoding: br`	(헤더 없음)	brotli는 못 하니 원본으로 준다
`Accept-Encoding: identity`	(헤더 없음)	압축하지 말라니 그대로 준다

이게 HTTP 명세가 content negotiation이라고 부르는 것이다. 한쪽이 "이런 것들을 받을 수 있다"고 내밀면 다른 쪽이 고른다. 요구가 아니라 제안과 선택이라는 점에서, 여가 없이 주고받는 그 일과 정확히 같은 모양이다.

1801년 — 손을 흔들어 보이던 인사

handshake가 명사로 처음 확인되는 건 1801년이고, "손을 맞잡다(shake hands)"라는 표현 자체는 16세기부터 있었다. 무기를 들지 않았음을 보이며 손을 내미는 인사에서 왔다는 설명이 널리 알려져 있는데, 이 유래담 자체는 사전이 확정해 주지 않는다. 어원 사전이 담고 있는 것은 어디까지나 "hand + shake, 1801년"까지다.

기술 용어로서의 handshake도 마찬가지다. 통신 장비끼리 준비 상태를 확인하는 신호 교환을 이렇게 부른 것이 언제부터인지, 일반 어원 사전에는 실려 있지 않다. 여기서는 확인되는 것만 적어 둔다 — 사람의 인사에서 기계의 절차로 은유가 옮겨왔고, 옮겨오면서 남은 핵심은 "본론에 들어가기 전에 서로 준비됐음을 확인하는 짧은 왕복" 이라는 점이다.

그 왕복의 비용은 숫자로 남는다. 위 측정에서 핸드셰이크에만 읽기 4,753바이트 / 쓰기 1,654바이트가 오갔다. 본문 HTML을 한 글자도 받기 전에 쓴 양이다. 세션 재사용이 왜 그렇게 중요한지, 그리고 TLS 1.3이 왕복 횟수를 줄이는 데 왜 그토록 공을 들였는지가 이 숫자로 설명된다.

다시 그 여섯 줄로

이제 처음의 출력에 다섯 단어를 맞춰 놓으면 이렇게 읽힌다.

출력	단어	어원이 말하는 것
`TLSv1.2` / `ALPN protocol: h2`	protocol	맨 앞장에 적어 둔 약속 (`prōtos`+`kolla`)
`Cipher is ECDHE-RSA-AES256-GCM-SHA384`	negotiation	한가하지 않게 주고받아 정한 것 (`neg`+`otium`)
`read 4753 / written 1654 bytes`	handshake	본론 전에 준비를 확인하는 짧은 왕복
`Session-ID` / `ticket lifetime 300`	session	앉아 있는 동안 (`sedere`)
주소창의 `https:`	scheme	겉으로 드러난 모양 (`skhēma`)

한 번의 접속이 곧 약속을 확인하고(protocol) → 조건을 맞추고(negotiation) → 준비를 확인하고(handshake) → 자리를 잡는(session) 순서라는 게, 단어 다섯 개의 내력만으로 설명된다.

헷갈리는 이웃

protocol vs scheme vs standard. scheme은 "어떤 모양으로 다룰지"를 알리는 표지(URI 앞부분), protocol은 그 형식으로 주고받는 절차 전체, standard는 그 절차를 문서로 고정한 합의다. https는 scheme이고, HTTP over TLS는 protocol이며, RFC 9110은 standard다.

session vs connection vs handshake. connection은 물리적·논리적으로 이어진 상태, handshake는 그 연결을 세우는 절차, session은 연결이 끊겨도 이어지는 자리의 기억이다. 그래서 연결은 끊겼는데 세션은 살아 있는 상황이 성립한다 — 위 실측에서 Reused가 나온 게 정확히 그 경우다.

정리

protocol — 두루마리 맨 앞에 풀로 붙인 낱장. 내용이 아니라 "다루는 법"을 앞장에 적어 둔 것
session — 앉아 있는 동안. 앉기는 비싸고 앉아 있기는 싸다
scheme — 겉으로 드러난 모양. URI의 그 자리가 원뜻에 가장 가깝다
negotiation — 여가가 없는 상태. 요구가 아니라 제안과 선택
handshake — 본론 전의 짧은 왕복. 그 비용이 4,753바이트였다

기술 용어를 처음 만났을 때 "이건 어디서 빌려온 말이지"를 묻는 습관이 생기면, 이름만 보고도 그 개념이 무엇을 강조하려 했는지가 얼추 잡힌다. 적어도 나는 scheme을 "계획"으로만 알고 있던 동안 URI 명세를 계속 어색하게 읽었다.