이 글의 위치: 영어(English) → 어원(Etymology) → 어근(Root) / 동시 분류: 기술 블로그 → Backend
시리즈 hub: 본 글은 기존 6편의 짧은 어근 노트(port,duct/duc,vis/vid,spect/spec,man/men,per/peri) 를 하나의 학습 단위로 통합하여 다시 정리한 long-form 글입니다. 원본 6편은 본 글로 영구 301 리다이렉트되었습니다.검증: 모든 어원은 etymonline.com · Oxford English Dictionary · Merriam-Webster 로 교차검증한 결과만 정리했습니다. 작성 방식·검증 절차는 Editorial Policy 참조.
왜 이 6개를 한 페이지로 묶는가
처음엔 어근 하나에 글 하나를 썼다. port 노트를 쓰고, 며칠 뒤 duct 노트를 쓰고, 그다음에 vis, spect… 그렇게 여섯 번을 쓰고 나서 묘한 기시감이 들었다. 매번 같은 문장 구조를 반복하고 있었다 — "어근은 의미의 핵이고, 접두사가 방향을 정한다." 카드마다 어근만 갈아 끼웠을 뿐, 하는 말은 똑같았다.
그래서 한 번 묶기로 했다. 묶고 나니 더 선명하게 보이는 게 있었다. 접두사 시리즈가 "방향"을 다뤘다면, 어근 시리즈는 "동작" 그 자체를 다룬다는 점이다. re-, pre-, trans- 같은 접두사는 혼자서는 의미가 비어 있다. "다시", "미리", "건너서" — 무엇을? 그 빈칸을 채우는 게 어근이다. import / export / transport 에서 방향(im-, ex-, trans-)을 빼고 남는 port 가 바로 "무엇을" 에 해당한다. 나르는 것. 어근은 단어의 의미 핵(semantic core)이고, 접두사는 그 핵을 어느 방향으로 굴릴지 정하는 손잡이다.
이 관점으로 보면 매일 보던 개발 용어가 한꺼번에 친척으로 묶인다:
port(나르다) → import / export / transport, 그리고 네트워크 port 번호, 코드 portingduct(이끌다) → conduct / produce / reduce, 함수형의 reduce, 메시지 conductorvis/vid(보다) → visible / visibility / provide / provision, observability, 코드 reviewspect/spec(보다·살피다) → inspect / aspect / spec, K8s describe 의 그 specman/men(머물다) → permanent / remain / maintenance, 301 permanent redirect, persistent storageper/peri(시도·경험하다) → experiment / experience / expert, A/B 테스트, UX·DX
개발 용어에 라틴어 어근이 유독 많은 건 우연이 아니다. 프로그래밍 용어 대부분이 영어 학술·기술 어휘에서 왔고, 그 어휘층이 통째로 라틴어에서 차용된 것이기 때문이다. 그래서 어근 여섯 개만 손에 쥐고 있으면, 처음 보는 함수명이나 API 이름도 "아, 이건 무엇을 어느 방향으로 하는 거구나" 하고 골격이 잡힌다.
한 장 요약
| 어근 | 핵심 의미 | 라틴어 유래 | 개발에서 자주 보는 단어 |
|---|---|---|---|
| port | 나르다 (carry) | portare (나르다, 운반하다) |
import, export, transport, portable, 네트워크 port |
| duct / duc | 이끌다 (lead) | ducere (이끌다), 과거분사 ductus |
conduct, produce, reduce, introduce, conductor |
| vis / vid | 보다 (see) | videre (보다) ← PIE *weid- |
visible, visibility, provide, provision, review |
| spect / spec | 살펴보다 (look) | spectare (바라보다), specere (보다) |
inspect, aspect, spec, prospect, perspective |
| man / men | 머물다·남다 (remain) | manere (머물다) ← PIE *men- |
permanent, remain, maintenance, immanent |
| per / peri | 시도·경험하다 | periri (직접 겪다, 위험 무릅쓰다) |
experiment, experience, expert, peril, empirical |
각 행의 마지막 칸이 곧 이 글의 목적지다. 아래에서 어근 하나하나가 접두사를 만나며 어떻게 이 단어들로 갈라지는지를 본다.
1. port — 나르다 (carry)
핵심 의미: 무언가를 한 곳에서 다른 곳으로 나른다. 라틴어 portare. 접두사는 "어디로 나르는지"를 정한다.
| 단어 | 분해 | 뜻 |
|---|---|---|
| transport | trans(넘어) + port(나르다) | 운송하다 (건너 나르다) |
| import | im(안으로) + port(나르다) | 수입하다 (안으로 나르다) |
| export | ex(밖으로) + port(나르다) | 수출하다 (밖으로 나르다) |
| report | re(되돌려) + port(나르다) | 보고하다 (정보를 돌려 나르다) |
| support | sup(아래에서) + port(나르다) | 지지하다 (아래에서 받치다) |
| portable | port(나르다) + able(가능한) | 휴대용의, 이식 가능한 |
| deport | de(떨어져) + port(나르다) | 추방하다 (멀리 나르다) |
한 가지 주의할 점. 같은 철자의 port(항구)는 라틴어 portus 에서 온 별개의 어원이다. 다만 "항구 = 물건을 나르는 곳"이라 의미적으로는 자연스럽게 이어진다. passport(항구를 통과하는 문서), airport 의 port 가 이쪽이다.
개발 맥락. port 는 백엔드에서 가장 다의적인 단어 중 하나다. 같은 철자가 세 군데서 다르게 쓰인다 — (1) import / export 의 모듈 입출력, (2) 코드를 다른 언어·플랫폼으로 옮기는 "porting"(portable 과 같은 결), (3) 네트워크 port 번호(8080). 표면적으론 따로 노는 듯하지만, 어근으로 보면 셋 다 "데이터를 실어 나른다"는 한 이미지로 수렴한다. 포트 번호조차 사실상 "데이터를 실어 나르는 게이트"라는 비유다. port = carry 로 외워두면 메트릭 exporter(밖으로 실어 보내는 것), transport layer(TCP 계층) 같은 표현이 갑자기 직관적으로 읽힌다.
이 "내보낸다(ex + port)"의 결을 가장 선명하게 보여주는 게 관측 스택이다. 프로메테우스의 node_exporter 는 9100 포트를 열고 호스트의 CPU·메모리·디스크 메트릭을 텍스트로 export 하고, 프로메테우스 서버가 그 포트를 주기적으로 scrape 해 간다 — "밖으로 실어 보내는 것(exporter)"이 "데이터를 실어 나르는 게이트(port)"로 데이터를 흘려보내는 그림이, 한 문장 안에 같은 어근 두 번으로 정확히 그려진다. 데이터 엔지니어링의 export to parquet, 트레이싱의 OTLP exporter, 컨테이너의 EXPOSE/포트 매핑(-p 8080:80)도 같은 발상이다. 한편 portable 의 결은 빌드 타깃에서 산다 — Go 의 GOOS=linux GOARCH=arm64 go build 한 줄로 바이너리를 다른 플랫폼으로 "port"하는 크로스 컴파일, 혹은 코드를 Python 2 에서 3 으로 옮기는 마이그레이션이 전부 "다른 환경으로 실어 나르기"다. 같은 어근이 런타임(네트워크 port)·빌드타임(porting)·데이터(export)에 동시에 박혀 있는 셈이다.
2. duct / duc — 이끌다 (lead)
핵심 의미: 사람·물체·결과를 어딘가로 이끈다. 라틴어 ducere, 과거분사 ductus. 접두사는 "어디로 이끄는지"를 정한다.
| 단어 | 분해 | 뜻 |
|---|---|---|
| conduct | con(함께) + duct(이끌다) | 수행하다, 지휘하다 |
| produce | pro(앞으로) + duce(이끌다) | 생산하다 (앞으로 이끌어내다) |
| reduce | re(뒤로) + duce(이끌다) | 줄이다 (뒤로 이끌다) |
| introduce | intro(안으로) + duce(이끌다) | 소개하다 (안으로 이끌어 들이다) |
| deduce | de(아래로) + duce(이끌다) | 추론하다 (아래로 끌어내다) |
| induce | in(안으로) + duce(이끌다) | 유도하다, 유발하다 |
| educate | e(밖으로) + duc(이끌다) + ate | 교육하다 (밖으로 이끌어내다) |
| aqueduct | aqua(물) + duct(이끌다) | 수로 (물을 이끄는 길) |
혼동하기 쉬운 친척이 tract(끌다, pull/drag)다. duct 는 "방향을 정해 인도"하는 것이고 tract 는 "잡아당기는" 것이다. conduct(지휘) vs attract(끌어당김)을 나란히 두면 결의 차이가 보인다.
개발 맥락. 함수형 패러다임의 reduce 가 바로 이 어근이다 — 컬렉션을 하나의 값으로 "뒤로 이끌어 줄이는" 동작. [1,2,3].reduce((acc, x) => acc + x, 0) 가 배열을 6 이라는 한 값으로 "이끌어 줄이는" 장면이 어원 그대로다. 같은 동작을 언어마다 fold(Kotlin·Scala)·aggregate(C#)·inject(Ruby) 로 부르지만, MapReduce 의 그 Reduce, RxJS 의 scan/reduce, Redux 의 reducer(이전 state 를 새 state 로 이끌어내는 함수)까지 전부 같은 "이끌어 합친다" 한 동작이다. produce / producer, consume 의 짝꿍인 메시지 큐 conductor, 데이터 파이프라인의 introduce a stage 도 전부 같은 root다.
특히 카프카 같은 메시지 시스템을 열면 이 어근이 아키텍처의 뼈대로 박혀 있다 — producer 가 토픽으로 메시지를 "앞으로 이끌어내고(pro + duce)", consumer 가 그걸 받아 간다. 흥미로운 건 머신러닝 쪽에서 induce(귀납)와 deduce(연역)가 inference(추론)의 어원을 이룬다는 점이다. 알고리즘 문서를 읽다 induction / deduction 이 튀어나오면, "안으로 이끌어 일반화한다(데이터→규칙) / 아래로 이끌어 도출한다(규칙→결론)"는 방향 차이만 떠올리면 된다. 결정 트리의 학습을 "tree induction", 타입 시스템이 표현식에서 타입을 끌어내는 걸 "type deduction"(C++ auto, 제네릭 추론)이라 부르는 것도 같은 이끌어내기다.
3. vis / vid — 보다 (see)
핵심 의미: 눈으로 본다. 라틴어 videre, 멀리는 PIE *weid-(보다·알다)까지 올라가 영어 wit(알다), wise(지혜)와도 동족이다. vis- 와 vid- 는 같은 어근의 어간 변형이다.
| 단어 | 분해 | 뜻 | IT 맥락 |
|---|---|---|---|
| visible | vis + ible(가능한) | 보이는 | CSS visibility, UI 표시 여부 |
| visibility | vis + ibility | 가시성 | 모니터링·관측성, k8s pod 가시성 |
| vision | vis + ion | 비전, 시야 | computer vision, OCR |
| provide | pro(앞을) + vid + e | 제공하다 | API가 데이터 provide, DI provider |
| provision | pro(앞을) + vis + ion | 준비, 공급 | 서버 provisioning, Terraform |
| supervise | super(위에서) + vis + e | 감독하다 | supervisor process |
| review | re(다시) + view(←vis) | 검토하다 | code review, PR review |
| revise | re(다시) + vis + e | 수정·개정하다 | 스펙 revise, code revision |
의미는 세 갈래로 묶인다. 직접 봄(visible, vision), 위에서 살핌(supervise, review, revise), 앞을 미리 봄(provide, provision). 특히 마지막 갈래가 개발에서 핵심인데, pro + vis = "앞을 미리 보고 준비해 둔다"가 그대로 인프라 용어가 됐다.
개발 맥락. provision(서버를 사용 가능한 상태로 미리 마련) 과 review(다시 보다)가 같은 어근에서 왔다는 게 이 어근의 묘미다. Terraform·Ansible·K8s 의 리소스 provisioning, DI 컨테이너의 provider, 모니터링의 visibility/observability — 전부 "본다"의 파생이다. 분산 시스템 디버깅에서 "시스템이 보이는가(visibility)"가 운영의 출발점이라는 점을 생각하면, 이 어근이 클라우드 어휘의 한복판에 있다는 게 우연이 아니다.
가장 손에 잡히는 장면은 terraform apply 다. terraform plan 으로 "무엇이 만들어질지 미리 보고(provision = pro + vis, 앞을 미리 봄)" 승인하면, apply 가 EC2·RDS·VPC 를 실제로 provision 한다 — 단어 자체가 이 도구의 동작을 요약한다. 쿠버네티스에서도 StorageClass 의 provisioner 필드가 PVC 요청을 받아 실제 볼륨을 깎아내고, DI 프레임워크(Spring·Guice·NestJS)의 provider 는 "필요할 때 객체를 마련해 공급하는 쪽"이다. 다른 갈래인 review/revise 는 코드 리뷰 워크플로에 산다 — PR 에 다는 Request changes, 머지 전 revision 히스토리, 그리고 supervisor 프로세스(systemd·supervisord 가 자식 프로세스를 "위에서 살피며" 죽으면 되살리는 것)까지. 같은 vis 가 "앞을 미리 봄(provision)"·"다시 봄(review)"·"위에서 살핌(supervise)"으로 갈라져 인프라 어휘 전체에 퍼져 있다.
4. spect / spec — 살펴보다 (look)
핵심 의미: 같은 "보다"지만 vis 보다 의도를 갖고 주의 깊게 살핀다는 뉘앙스다. 라틴어 spectare(바라보다)·specere(보다). 접두사는 "어디를 보는지"를 정한다.
| 단어 | 분해 | 뜻 |
|---|---|---|
| inspect | in(안을) + spect(보다) | 검사하다 (안을 들여다보다) |
| respect | re(다시) + spect(보다) | 존경하다 (다시 바라보다) |
| expect | ex(밖을) + spect(보다) | 기대하다 (밖을 내다보다) |
| suspect | sus(아래서) + spect(보다) | 의심하다 (아래서 올려보다) |
| prospect | pro(앞을) + spect(보다) | 전망 (앞을 내다보다) |
| retrospect | retro(뒤를) + spect(보다) | 회고 (뒤를 돌아보다) |
| perspective | per(꿰뚫어) + spect(보다) + ive | 관점 (꿰뚫어 보는 방식) |
| spectacle | spect(보다) + acle(것) | 구경거리, 장관 |
vis 와의 차이는 한 줄로 정리된다. spect 는 "의도를 갖고 바라봄", vis 는 "보이는 상태", 그리고 도구로 보는 scop(microscope, telescope)이 또 다른 갈래다.
개발 맥락. 이 어근의 대표 선수는 단연 inspect — 코드 리뷰의 inspect, 브라우저 devtools 의 inspector, docker inspect <container> 가 뱉는 JSON 메타데이터다. 그리고 spec. K8s 디버깅의 전형적 장면이 이 어근 위에 서 있다 — kubectl describe pod(또는 kubectl get pod -o yaml)로 한 Pod 의 spec(내가 원한다고 선언한 상태)과 status(스케줄러·kubelet 이 실제로 만든 상태)를 나란히 놓고 비교하는 디버깅. spec.containers[].image 에 적은 태그와 status 의 ImagePullBackOff 가 어긋나는 지점을 찾는 게 곧 트러블슈팅이다. 일상에선 specification(명세)으로 굳었지만 어원적으로는 "보이는 것/봄"에 더 가까워서, spec 블록이 "원하는 상태를 기술해 보여주는 곳"이라는 선언형 API 의 발상과 깔끔하게 맞물린다.
같은 어근이 테스트 도구의 명명에도 박혀 있다 — RSpec·Jasmine 의 describe/it, 파일명 *.spec.ts, 그리고 expect(result).toBe(42) 의 expect(ex + spect, "밖을 내다봄" → 결과를 미리 내다보고 단언). OpenAPI/Swagger 의 "API spec", JSON Schema 로 기술하는 "spec" 도 같은 결이다. 관점지향(AOP)의 aspect(로깅·트랜잭션 같은 "한 측면"을 가로질러 보는 것), 회고 미팅의 retrospective(retro + spect, 스프린트를 "뒤돌아봄")까지 — 전부 "어느 방향으로 보는가"의 변주다. vis 가 "보이는 상태"라면 spect 는 한결같이 "의도를 갖고 들여다봄"이라, 검사·단언·관측 도구의 이름에 유독 자주 등장한다.
5. man / men — 머물다·남다 (remain)
핵심 의미: 그 자리에 머물러 남는다. 라틴어 manere, PIE *men-. man-/men-/main- 로 어간이 변한다.
주의:
manage,manual,manufacture의man-은 라틴어manus(손, hand)에서 온 완전히 다른 어근이다. 발음은 같지만 어원이 갈린다. 여기서 다루는 건 오직manere(머물다) 쪽이다.
| 단어 | 분해 | 뜻 | IT 맥락 |
|---|---|---|---|
| permanent | per(완전히) + man(머물다) + ent | 영구적인 | permanent redirect(301), permanent storage |
| remain | re(뒤에) + main(머물다) | 남다, 머물다 | remaining capacity, 잔여 리소스 |
| remnant | re + man(머물다) + ant | 나머지, 잔재 | 마이그레이션 후 남은 구형 코드 |
| maintenance | main(머물다) + ten(잡다) + ance | 유지, 유지보수 | maintenance window, scheduled maintenance |
| immanent | im(안에) + man(머물다) + ent | 내재하는 | immanent property (설계·철학 용어) |
maintenance 의 분해가 재미있다. main(머물다, manere) + ten(잡다, 라틴어 tenere)의 합성으로, "상태가 그대로 머물도록 붙잡는 것"이다. 유지보수의 본질이 어원에 그대로 들어 있다.
개발 맥락. 이 어근의 핵심 두 단어가 permanent 와 maintenance 다. 301 permanent redirect — 지금 이 hub 글로 원본 6편을 영구히 보내는 그 "permanent"가 바로 "끝까지(per) 그 자리에 머문다(man)"이다. HTTP 명세가 301(Moved Permanently)과 302(Found, 임시)를 가르는 핵심도 이 "머묾"의 유무다 — 301 은 브라우저·검색 엔진이 "이 이전은 끝까지 유효하다"고 보고 캐시하고 링크 가중치를 새 URL 로 넘기지만, 302 는 머물지 않으므로 그러지 않는다. 어원 한 단어가 곧 캐싱 동작의 차이다. permanent storage·permanent delete 도 같은 결.
maintenance 의 분해(main머물다 + ten잡다)가 운영에서 그대로 산다 — maintenance window(점검 시간대), maintenance mode(503 을 내리고 트래픽을 잠시 막아두는 상태), 의존성 관리의 "actively maintained"(이 라이브러리는 아직 누가 붙잡아 두고 있다) 같은 표현이 전부 "상태가 그대로 머물도록 붙잡는" 일이다. 그리고 마이그레이션 뒤 끝까지 안 사라지는 legacy remnant, remaining technical debt, 큐에서 처리 못 하고 남은 remaining items 의 그 "남음"도 여기서 온다. K8s 의 node drain 후 노드를 빼기 전에 거치는 cordon 상태, 즉 "이 노드에 남아 있는(remaining) Pod 가 0 이 될 때까지 대기"하는 흐름을 떠올리면 remain 의 결이 손에 잡힌다.
참고로, 이름이 비슷한 persistent(per + sist, 라틴어 sistere "서다")는 엄밀히는 다른 어근이지만 "끝까지 남는다"는 이미지를 permanent 와 공유한다 — storage 문서에서 둘이 나란히 보이는 이유다.
6. per / peri — 시도·경험하다
핵심 의미: 직접 해보고 겪어서 안다. 라틴어 periri(직접 겪다, 위험을 무릅쓰고 시도하다). PIE *per-(앞으로 나아가다·통과하다)에서 갈라졌다.
주의: 접두사
per-("통하여, 완전히" — performance·permission 계열)와 이름이 같지만, 여기 어근peri-는 "시도·경험"에 초점이 다르다. 둘 다 같은 PIE*per-뿌리지만 라틴어 단계에서 분기했다.
| 단어 | 분해 | 뜻 | IT 맥락 |
|---|---|---|---|
| experiment | ex(밖으로) + per(시도) + ment | 실험 | A/B 테스트, feature flag, MLflow Experiment |
| experience | ex(밖으로) + per(시도) + ience | 경험 | user experience(UX), developer experience(DX) |
| expert | ex + pert(←periri 과거분사) | 전문가 | subject matter expert, domain expert |
| expertise | expert + ise | 전문 지식 | "deep expertise in distributed systems" |
| peril | peri + l (←periculum) | 위험 | at peril of data loss |
| empirical | (그리스어 peira 시도) + ic + al | 경험에 기반한, 실증적 | empirical testing, empirical evidence |
| repertoire | re(다시) + per(시도) + toire | 보유 역량 | "team’s technical repertoire" |
이 어근의 가장 흥미로운 점은 "전문성(expert)"과 "위험(peril)"이 한 뿌리에서 나왔다는 사실이다. periri 가 원래 "위험을 감수하고 직접 해보다"였기 때문이다. 경험은 언제나 위험과 함께 얻어진다 — 어원이 그렇게 말하고 있다.
개발 맥락. experiment 는 feature flag 와 A/B 테스트의 그 experiment, MLflow 의 Experiment 객체다 — "미지의 영역을 시도해 본다"는 본뜻 그대로다. 구체적으로, LaunchDarkly·Optimizely 에서 한 플래그를 두고 트래픽을 50:50 으로 갈라 전환율을 재는 단위를 "experiment"라 부르고, MLflow 에서는 mlflow.start_run() 한 번이 하나의 시도(run)고 그 run 들을 묶는 상위 컨테이너가 Experiment 다 — 하이퍼파라미터를 바꿔가며 "직접 돌려보고 겪어서 아는" 과정이 곧 객체 이름이 됐다. experience 는 UX·DX, expert/expertise 는 도메인 전문성(subject matter expert 의 SME).
empirical(실증적)은 데이터 기반 의사결정의 언어다 — "추측 말고 empirical evidence 를 가져와라", 즉 프로파일러를 붙여 실제 측정한 hotspot 을 보고 최적화하라는 말은 "직접 해보고 확인하라"는 어원의 직역이다("성급한 최적화" 경고의 다른 표현이기도 하다). 그리고 위험. periri 가 원래 "위험을 무릅쓰고 해보다"였던 흔적이 운영 경고에 남아 있다 — 백업 없이 prod DB 에 DROP 을 날리거나 --force 로 푸시하면 "at your own peril", 본인이 위험을 감수하는 것이다. 한 어근에서 "실험·경험·전문성"이라는 성장의 언어와 "위험"이라는 경고의 언어가 동시에 나온다는 게, 모든 배포가 결국 작은 도박이라는 운영의 현실과 묘하게 들어맞는다.
같은 어근이 코드 곳곳에 — 한눈에
어근 하나가 접두사에 따라 어떻게 갈라지는지, 개발 용어 중심으로 모으면 이렇게 보인다.
| 어근 | + 접두사 → 개발 용어 |
|---|---|
| port (나르다) | im·import / ex·export / trans·transport / re·report / portable(이식) / 네트워크 port |
| duct (이끌다) | con·conduct(or) / pro·produce / re·reduce(함수형) / intro·introduce / in·induce / de·deduce |
| vis (보다) | visible/visibility / pro·provide·provision / super·supervisor / re·review·revise |
| spect (살피다) | in·inspect(or) / re·respect / ex·expect / pro·prospect / per·perspective / spec(K8s) |
| man (머물다) | per·permanent(301) / re·remain(ing) / maintenance / re·remnant(legacy) |
| per (시도) | ex·experiment / ex·experience(UX/DX) / ex·expert(ise) / empirical / peril |
세로로 읽으면 "어근 하나에서 갈라진 친척들", 가로로 같은 접두사(re-, pro-, ex-, in-)를 찾아 읽으면 "같은 방향이 어근만 바꿔 가며 반복되는 패턴"이 보인다. 예컨대 re-(다시/뒤로)는 reduce(뒤로 이끌다)·review(다시 보다)·respect(다시 보다)·remain(뒤에 남다)·report(돌려 나르다)에 똑같이 얹혀 있다. 접두사와 어근의 곱셈표 — 그게 영어 학술 어휘의 뼈대다.
한 줄로 묶으면
어근은 "무엇을"이고 접두사는 "어느 방향으로"다. port(나르다)·duct(이끌다)·vis/spect(보다)·man(머물다)·per(시도하다) 여섯 개의 동작 핵에, im-/ex-/re-/pro- 같은 방향 손잡이가 붙으면서 import·reduce·provision·inspect·permanent·experiment 가 만들어진다. 단어를 통째로 외우는 대신 어근 하나에 어떤 접두사가 얹혔는지만 분해하면, 처음 보는 개발 용어도 의미의 80%가 잡힌다.
접두사 시리즈가 "방향"을 정리했다면 이 어근 시리즈는 "동작"을 정리했다. 다음엔 tract(끌다)·ten(잡다)·pos/pon(놓다) 처럼 손동작 계열 어근을 같은 방식으로 묶어 볼 생각이다.
함께 읽으면 좋은 어원 허브
같은 시리즈에서 형태소 단위로 개발 영어를 분해한 다른 글이다.
- 라틴어 접두사 6개 — re·pre·pro·trans·per·un — 단어 앞머리가 정하는 방향·시점.
- 영어 접미사 8개 — -tion·-ment·-able·-less… — 단어 꼬리가 정하는 품사(명사/형용사).
- 개발 영어 ‘~성’ 단어 — -ity / -ability — availability·scalability·reliability를 한 페이지로.
참고
- Online Etymology Dictionary — etymonline.com
- Oxford English Dictionary (subscription) — oed.com
- Merriam-Webster — merriam-webster.com
이 글의 개정 이력
- 2026-06-24 (발행일) — 최초 발행. 기존 어근 노트 6편(port·duct·vis·spect·man·per)을 한 페이지로 통합·재작성. 원본 6편은 본 글로 301. AdSense W6 콘텐츠 정리 사이클의 Phase 2 hub 글.
답글 남기기