컴퓨터가 빌려온 이름 6개 — queue·bootstrap·algorithm·cipher·robot·daemon의 출처

이 글의 위치: 영어(English) → 어원(Etymology) → 개발 영어(Developer English)
시리즈 hub: 낱말 카드 여섯 편으로 쓰려던 것을 한 페이지로 묶었다. 어근 시리즈(접두사 · 접미사 · 어근)와 달리, 여기 여섯은 쪼개지지 않는 단어들이라 따로 모았다.
어원은 Online Etymology Dictionary · Cambridge Dictionary 로 교차 확인했고, 기원설이 갈리는 대목은 그렇게 표시했다. 기준은 Editorial Policy 참조.

쪼개지지 않는 단어들

접두사·접미사·어근 시리즈를 정리하고 나서 한동안은 모르는 단어를 만나면 일단 쪼개 보는 버릇이 들었다. in- + ject, con- + tain, infra- + structure. 대개는 이 방법이 통했다.

그런데 안 통하는 단어들이 있었다. algorithm을 아무리 뜯어봐도 algo-에서 뜻이 나오지 않는다. queue도, daemon도 마찬가지다. 한참 헤매다 알았다. 이 단어들은 조립된 게 아니라 통째로 빌려온 것이다.

단어	어디서 빌려왔나	원래 무엇이었나
queue	프랑스어·라틴어	동물의 꼬리
bootstrap	영어 관용구	장화끈 — 원래는 허풍을 비꼬던 말
algorithm	사람 이름	9세기 수학자 알콰리즈미
cipher	아라비아어	숫자 0, 비어 있음
robot	체코어	농노의 강제 부역
daemon	그리스어	곁을 지키는 수호 정령

여섯을 한자리에 모아 놓고 보니 더 흥미로운 게 있었다. 무엇을 빌려왔는지가 그 개념의 성격을 그대로 드러낸다. 큐가 하필 "꼬리"인 것도, 배경 프로세스가 하필 "정령"인 것도, 자동화된 것들이 하필 "부역"인 것도 우연이 아니다.

1. queue — 꼬리

queue
└── 고대 프랑스어 queue (꼬리, 꼬리처럼 늘어선 것)
    └── 라틴어 cauda (동물의 꼬리)
= "꼬리에 꼬리를 물고 늘어선 줄, 먼저 온 것이 앞"

queue는 원래 동물의 꼬리를 뜻했고, 프랑스어에서 "꼬리처럼 뒤로 길게 이어진 것"으로 뜻이 번졌다. 영국 영어에서 "줄을 서다"가 바로 queue인 이유다. 앞사람의 꼬리에 꼬리를 물고 늘어선 모습 그대로다. 철자에 붙은 ueue가 발음되지 않는 것도 "q 뒤에 알파벳들이 꼬리처럼 줄줄이 붙어 기다리는 단어"라는 농담으로 기억한다. 뜻도 철자도 꼬리인 셈이다.

cauda 가족 — coda(곡의 꼬리 → 마무리 악절) · cue(대사의 꼬리 → 신호) · cauda equina(말꼬리 모양 신경 다발) · coward(꼬리 만 자 → 겁쟁이).

음악의 coda와 개발의 queue가 한 가족이라는 게 의외지만, 둘 다 "무언가의 뒤 끝에 이어 붙는다"는 점에서 같다. 큐에 원소를 넣는 걸 꼬리(tail)에 붙인다고 말하는 것도 정확히 같은 그림이다.

개발에서. 자료구조의 큐, RabbitMQ·SQS 같은 메시지 큐, 백그라운드 작업 큐, 우선순위 큐 — "순서대로 기다렸다 처리되는 것"을 죄다 queue라 부른다. 큐의 본질이 꼬리 끝에 붙어 차례를 기다리다 먼저 온 것이 먼저 빠져나가는 것, 곧 FIFO이기 때문이다. 새 원소는 꼬리(tail)에 붙고(enqueue), 소비는 머리(head)에서 일어난다(dequeue).

연산 이름을 뜯어보면 더 선명하다. enqueue는 en-(안으로) + queue, 곧 "줄 안으로 들여 꼬리에 붙이다"이고, dequeue는 de-(떼어내) + queue, 곧 "줄 앞에서 하나 떼어내다"다. 처리에 실패한 메시지가 흘러가는 dead-letter queue는 "주인을 못 찾은 편지들이 모이는 꼬리"인 셈이다.

"Messages pile up in the queue when consumers are slow."
소비자가 느리면 메시지가 큐에 쌓인다.

꼬리 끝에 계속 붙는데(생산) 앞에서 빠져나가는 속도(소비)가 느리면 줄은 자꾸 길어진다. 큐가 "쌓인다"는 건 곧 꼬리가 감당 못 할 만큼 길어졌다는 뜻이고, 이때 보는 지표가 queue depth(줄의 길이)와 queue latency(꼬리 끝에서 머리까지 기다린 시간)다. list나 buffer가 아니라 굳이 queue인 이유는, 단순히 담아두는 통이 아니라 먼저 온 것이 먼저 나가야 공정한 줄이라는 약속이 이름에 박혀 있기 때문이다.

헷갈리는 이웃. stack은 쌓아서 위부터(LIFO), buffer는 속도 차를 메우는 완충, pool은 순서 없이 고여 있는 재사용 묶음에 방점이 있다. queue만이 순서의 공정함을 갖는다.

2. bootstrap — 장화끈

bootstrap
├── boot  (장화)
└── strap (끈, 죔줄)
= "to pull oneself up by one's bootstraps"
= 제 장화끈을 당겨 스스로를 들어올린다 → 물리적으로 불가능한 일

재미있는 건 이 말이 처음엔 칭찬이 아니었다는 점이다. 19세기 미국에서 "to pull oneself up by one’s bootstraps"는 "제 끈을 당겨 하늘로 날아오르겠다"처럼 말이 안 되는 허풍을 비꼬는 표현이었다. 그러다 20세기 들어 "외부 도움 없이 제 힘만으로 해낸다"는 긍정적 의미로 뒤집혔다.

그리고 컴퓨터가 등장하면서 이 "스스로를 끌어올린다"는 감각이 딱 들어맞는 자리를 찾았다. 전원 말고는 아무것도 없는 기계가 저 혼자 프로그램을 읽어 자신을 구동시키는 그 순간이다.

boot 가족 — boot(부팅) · reboot(재부팅) · bootloader · boot sector. 라틴 어근을 파고드는 다른 단어들과 달리 이 가족은 소박하다. 뿌리가 그냥 장화이기 때문이다. 그런데 이 장화 한 켤레에서 오늘날 매일 쓰는 "부팅"이 통째로 나왔다. bootstrap이 줄어 boot가 되고, 거기서 reboot·bootloader가 갈라졌다.

개발에서. 전원이 들어온 CPU에는 사실상 아무것도 없다. 그 텅 빈 상태에서 아주 작은 코드가 조금 더 큰 코드를 불러오고, 그게 다시 운영체제를 불러온다. 제 끈을 당겨 한 단계씩 몸을 끌어올리듯이. BIOS/UEFI → boot sector → bootloader → kernel → init 순서가 그 자력 기동이다.

같은 감각이 개발 전반에 퍼져 있다. npm create vite로 빈 폴더에서 프로젝트 뼈대가 스스로 생기고, 셋업 스크립트가 첫 실행에 자기 의존성을 스스로 설치한다. 컴파일러를 그 언어 자신으로 만드는 self-hosting도 마찬가지다. 첫 버전은 다른 언어로 bootstrap 컴파일러를 지어 두고, 그걸로 자신을 컴파일한다. "닭이 먼저냐 달걀이 먼저냐" 문제를 개발에서 만나면 대개 bootstrap이 답이다.

"The script bootstraps its own dependencies on first run."
그 스크립트는 첫 실행에 자기 의존성을 스스로 갖춘다.

install이나 setup이 아니라 굳이 bootstrap을 쓰는 이유는, 바깥의 준비된 손을 빌리지 않고 맨바닥에서 저 혼자 일어선다는 자립의 뉘앙스 때문이다. 같은 결로, 투자 없이 매출만으로 큰 회사를 bootstrapped company라 부르고, 표본 하나에서 분포를 길어 올리는 통계 기법을 bootstrapping이라 부른다.

헷갈리는 이웃. init은 처음 상태로 세팅, seed는 초기 데이터를 심음, scaffold는 임시 뼈대를 세움에 방점이 있다. bootstrap만이 바깥 도움 없이 제 힘으로라는 자립의 감각을 갖는다.

3. algorithm — 사람 이름

algorithm
└── 라틴어 algorismus (십진 자릿수 계산법)
    ├── al-Khwārizmī — 9세기 페르시아 수학자의 이름
    │   └── "Khwarazm(고향) 출신의 그 사람"
    └── arithmos (그리스어 "수") ← 후대에 철자가 뒤섞임

이 단어의 뿌리는 뜻이 있는 라틴어 조각이 아니라 사람 이름이다. 9세기 바그다드에서 활동한 수학자 알콰리즈미(al-Khwārizmī)의 이름이, 인도식 십진 자릿수 계산법을 유럽에 소개한 그의 저작을 통해 라틴어 algorismus로 굳었다. 원래 뜻은 "알콰리즈미의 그 셈법"이다. 여기에 그리스어 arithmos(수)가 소리로 끼어들면서 -rism이 -rithm으로 바뀌어 오늘의 철자가 되었다.

logarithm이 algorithm과 닮은 것도 우연이 아니다. 둘 다 뒤쪽에 arithmos를 품고 있어 -rithm이라는 꼬리를 공유한다. 다만 algorithm의 앞머리 algo-는 뜻이 아니라 사람 이름의 잔상이다. 어근을 아무리 뜯어봐도 "algo = 무엇"이 안 나오는 이유가 여기 있다. 나올 게 없다. 화라즘 출신 한 사람의 이름이니까.

개발에서. algorithm은 "똑똑한 무언가"를 뜻하는 유행어가 아니라, 어원 그대로 정해진 입력을 정해진 유한한 단계를 거쳐 정해진 출력으로 바꾸는 절차다. 알콰리즈미가 자릿수를 하나씩 밟아 답에 이르렀듯, 정렬도 탐색도 해싱도 결국 "끝이 보장된 단계의 묶음"이다.

어원을 되짚으면 자연스럽게 유한성과 결정성이 떠오른다. 알콰리즈미의 셈법은 자릿수가 정해져 있어 언젠가 끝났고, 같은 수를 넣으면 같은 답이 나왔다. 오늘의 알고리즘도 같다. "언젠가 끝나는가(termination), 같은 입력에 같은 출력인가"가 절차를 알고리즘이라 부를 자격이다.

"The recommendation is driven by an algorithm."
그 추천은 알고리즘이 좌우한다.

하루에도 몇 번씩 말하는 이 단어가 실은 9세기에 살았던 한 사람의 이름이다. 사람 이름이 보통명사가 되는 일은 종종 있지만(sandwich, boycott), algorithm만큼 원래 이름을 완전히 잊은 채 쓰이는 말도 드물다.

헷갈리는 이웃. heuristic은 정답 보장을 접고 빠르게, procedure는 일단 순서대로, function은 입력→값이라는 형태에 방점이 있다. algorithm만이 끝이 있고 답이 보장된 절차라는 무게를 갖는다. "이건 heuristic이지 algorithm은 아니다"라는 말은 최적성·종료성을 포기했다는 정직한 고백이다.

4. cipher — 아라비아어 ‘0’

cipher
└── 라틴어 cifra (0, 그리고 알 수 없는 기호)
    └── 아라비아어 ṣifr (صفر) "비어 있음"
        └── 인도 수학의 '영(零)' 개념을 옮긴 말
= "비어 있음" → 0 → "낯설고 알 수 없는 기호" → 암호

이 단어의 재미는 zero와 뿌리가 같다는 데 있다. 인도에서 넘어온 영(零) 개념을 아라비아어가 ṣifr(비어 있음)로 옮겼고, 그 말이 라틴어 cifra가 되며 두 갈래로 갈라졌다. 한쪽은 이탈리아어 zefiro를 거쳐 zero로, 다른 한쪽은 "유럽 사람 눈에 낯설고 알 수 없던 그 새 기호"라는 어감을 이어받아 cipher(남은 못 읽는 비밀 부호)가 되었다. 처음엔 ‘아무것도 없음’을 가리키던 말이 ‘속을 알 수 없음’으로 옮겨 앉은 셈이다.

ṣifr 가족 — zero(비어 있음이 수가 됨) · cipher(알 수 없는 기호 → 암호) · decipher(풀어냄 → 해독) · encipher(암호화) · ciphertext · cipher suite.

zero와 cipher가 형제라는 사실은 영어에 흔적을 남겼다. 사람을 두고 *"He was a mere cipher"*라고 하면 "있으나 마나 한 존재"라는 뜻인데, 자리는 차지하되 값은 비어 있는 것이라는 옛뜻이 그대로 살아 있는 표현이다.

개발에서. TLS 핸드셰이크의 cipher suite, AES 같은 block cipher, stream cipher, 그리고 decipher까지. 이 단어가 암호화 방식 그 자체를 가리킨다는 걸 알면, 왜 encrypt와 cipher가 짝을 이루면서도 구분되는지가 선명해진다. encrypt는 감추는 행위이고, cipher는 그 행위가 따르는 규칙이다. 그래서 "encrypt with the AES cipher"처럼 쓴다.

"The server and client negotiate a cipher suite before any data is sent."
서버와 클라이언트는 데이터를 주고받기 전에 암호 스위트를 협상한다.

어원 그대로 읽으면 "둘만 통하는 알 수 없는 기호 체계를 무엇으로 할지 정한다"는 말이다. 아무것도 없음(0)에서 출발한 단어가 천 년을 돌아 ‘남은 아무것도 알 수 없게 하는 기술’의 이름이 되었다는 게 곱씹을수록 근사하다.

헷갈리는 이웃. 이 넷을 뭉뚱그리면 사고가 난다. encode는 비밀이 아니라 표현 방식일 뿐이라 Base64를 암호로 착각하면 큰일이고, hash는 되돌릴 수 없으니 암호화가 아니다. encrypt는 동작, cipher는 규칙이다.

5. robot — 체코어 부역

robot
└── 체코어 robota (고된 노동, 부역, 강제 노역)
    └── 슬라브어 계열 *orb- / rab- (노예·노역의 감각)
= robota(노동) + 1920년 희곡 R.U.R.
= "사람이 하기 싫은 고된 일을 대신 떠맡는 존재"

robot의 뿌리는 놀랍도록 소박하다. 체코어 robota는 중세 봉건제에서 농노가 영주에게 바치던 강제 노역, 곧 "하기 싫어도 해야 하는 고된 일"이었다. 1920년 카렐 차페크가 희곡 『R.U.R.』에서 인간을 대신해 노동하는 인조 존재의 이름을 찾을 때 형 요제프가 이 단어를 권했다고 전해진다.

그래서 robot은 처음부터 "금속 몸통"이 아니라 떠맡겨진 노동을 가리키는 말이었다. 기계라는 이미지는 나중에 덧붙은 것이고, 어원의 중심에는 언제나 ‘일’이 있다.

robota 가족 — robotics · bot(줄임말) · corvée(봉건 부역, 프랑스어 친척) · roboticist. 인도유럽조어 *orbh-("소속·신분이 바뀌어 노역에 들어간 처지")까지 거슬러 orphan(고아)이 먼 친척으로 거론되기도 하는데, 이건 설이 갈리는 대목이라 그렇게만 적어둔다. 다만 robot의 밑바닥에 흐르는 정서가 남을 위해 짊어지는 고된 일이라는 점은 어느 계보를 따르든 또렷하다.

개발에서. 크롤러도 봇, 챗봇도 봇, CI에서 자동으로 코멘트를 다는 것도 봇이고, RPA는 아예 "소프트웨어 로봇"이다. 공통점은 하나다. 사람이 반복하기엔 지루하고 고된 일을 대신 떠맡아 자동으로 처리한다. robota가 "강제로 시키는 고된 일"이었다는 걸 알면, 자동화된 것마다 bot을 붙인 이유가 단어만으로 설명된다.

재미있는 건 bot이 robot에서 꼬리만 남긴 줄임말이라는 점이다. 정작 어원의 핵심인 "노동(robota)"의 앞머리는 잘려 나갔는데도 뜻은 고스란히 남았다.

"Nearly half of the traffic came from bots, not humans."
트래픽의 절반 가까이가 사람이 아니라 봇에서 왔다.

이 봇들은 지치지도 쉬지도 않고 고된 일을 반복하는 존재다. 검색엔진 크롤러처럼 고마운 봇도, 콘텐츠를 긁어가거나 로그인을 무차별 시도하는 악성 봇도 있다. 공통점은 "사람이라면 지쳐서 못 할 반복을 감정 없이 계속한다"는 것, 정확히 robota의 정의다. 그래서 robots.txt로 착한 봇에게 길을 안내하고 레이트 리밋으로 나쁜 봇의 노역을 끊는다. 이름의 뿌리를 알고 나니 봇 트래픽 관리가 곧 "누구에게 어떤 노동을 허락할까"의 문제로 읽혔다.

6. daemon — 그리스 수호 정령

daemon
└── 그리스어 daimōn (δαίμων) — 신적인 힘, 곁을 지키는 정령
    ├── 라틴어 daemon ← "수호 정령" 뜻을 간직 → 컴퓨팅 daemon
    └── demon ← 후대 기독교 문맥에서 "악마"로 갈라짐
= 원래 뜻은 악령이 아니라 "곁을 지키는 정령"

핵심은 daimōn이 처음부터 악한 존재가 아니었다는 점이다. 그리스 사상에서 daimōn은 사람 곁에 붙어 그를 인도하고 지키는 보이지 않는 신적인 힘이었다. 소크라테스가 말한 내면의 목소리도 이 daimōn이다. 기독교 문맥을 거치며 demon이 "악마"로 어둡게 갈라졌지만, 철자 ae를 간직한 daemon은 원래의 "곁을 지키는 정령" 뜻을 그대로 남겼다.

그래서 이 단어를 컴퓨팅에 데려온 사람들은 정확한 감각을 골랐다. 사용자 눈에 안 띄게 뒤에서 상주하며 일을 돌보는 프로세스, 딱 그 정령이다.

daimōn 가족 — demon(악마) · pandemonium(모든 정령의 소굴 → 대혼란) · eudaemonia(좋은 정령 → 행복·번영) · daimonic.

같은 뿌리에서 demon(악마)과 eudaemonia(행복)가 함께 나왔다는 게 이 단어의 묘미다. daimōn은 선악을 나누기 전의 "곁에 깃든 신적인 힘"이었을 뿐이고, 그 힘을 어떻게 보느냐에 따라 한쪽은 악마로, 한쪽은 행복으로 갈라졌다. 컴퓨팅의 daemon은 다행히 원래의 중립적이고 이로운 감각을 물려받았다.

개발에서. sshd, dockerd, crond, systemd — 유닉스 이름 뒤에 붙은 d는 하나같이 daemon의 약자다. 이 프로세스들의 공통점은 사용자가 로그인해 명령을 내리지 않아도 부팅 후부터 배경에 조용히 상주하며 자기 일을 돌본다는 것이다.

쿠버네티스의 DaemonSet은 이 어원을 가장 노골적으로 드러낸 이름이다. "노드마다 파드를 하나씩 상주시켜라"는 명령인데, 그 하나하나가 각 노드 곁을 지키는 정령인 셈이다. 로그 수집기, 노드 모니터링 에이전트처럼 모든 노드에 조용히 붙어 있어야 하는 것이 DaemonSet으로 배포된다.

"The daemon runs in the background and restarts on failure."
그 데몬은 배경에서 돌며 실패 시 다시 시작한다.

이 프로세스는 부르지 않아도 곁에서 보이지 않게 상주하고, 무언가 잘못되면 스스로 몸을 추슬러 다시 선다. 신화의 수호 정령이 하던 바로 그 일이다. program이나 process가 아니라 굳이 daemon인 건, 이것이 앞에 나서서 대화하는 존재가 아니라 뒤에서 묵묵히 지키는 존재라는 성격을 담기 위해서다. 그래서 daemon은 시작하고 끝나는 게 아니라 계속 "돈다(runs)"고 말한다. 정령은 임무를 마치고 사라지는 게 아니라 곁에 머무는 것이니까.

헷갈리는 이웃. process는 실행 중인 프로그램 일반, job은 일을 마치면 사라지는 한 회성 실행, service는 그것을 관리 대상으로 보는 바깥 관점이다. daemon만이 사라지지 않고 배경에 상주한다는 성격을 이름 안에 품는다. cron job은 때가 되면 실행되고 끝나지만, 그 때를 지켜보는 crond는 daemon이다.

빌려온 이름이 말해주는 것

여섯을 다시 세워 놓고 보면, 무엇을 빌려왔는지가 그 개념에서 무엇을 가장 중요하게 봤는지를 드러낸다.

단어	빌려온 것	그래서 강조되는 성질
queue	꼬리	순서의 공정함 — 먼저 온 것이 먼저
bootstrap	장화끈	자립 — 바깥 도움 없이 스스로
algorithm	사람 이름	정해진 절차 — 끝이 있고 답이 보장됨
cipher	숫자 0	알 수 없음 — 남은 못 읽는 상태
robot	강제 부역	대신 짊어지는 노동
daemon	수호 정령	나서지 않고 곁을 지킴

buffer가 아니라 queue를 고른 사람은 순서의 공정함을 지키고 싶었고, install이 아니라 bootstrap을 고른 사람은 자립을 강조하고 싶었으며, process가 아니라 daemon을 고른 사람은 "나서지 않음"을 말하고 싶었다. 이름을 고르는 일이 곧 그 개념의 무엇을 볼 것인지 정하는 일이었다.

내가 이 여섯 개를 묶어 놓고 얻은 건 어휘 몇 개가 아니라 이 관점이다. 새 기술에 이름을 붙일 때, 혹은 남이 붙인 이름을 처음 읽을 때, "왜 하필 그 단어였을까"를 묻는 습관 하나. 물론 이건 어원이 증명해주는 사실이 아니라 내 해석이라, 반례가 나오면 고칠 생각이다.

월	화	수	목	금	토	일
			1	2	3	4
5	6	7	8	9	10	11
12	13	14	15	16	17	18
19	20	21	22	23	24	25
26	27	28	29	30	31