이 글의 위치: 영어(English) → 어원(Etymology) → 접미사(Suffix) / 동시 분류: 기술 블로그 → Backend
시리즈 hub: 본 글은 기존 8편의 짧은 접미사 노트(-tion/-sion,-ment,-ure,-able/-ible,-ness,-less,-ful,-ent/-ant) 를 하나의 학습 단위로 통합하여 다시 정리한 long-form 글입니다. 원본 8편은 본 글로 영구 301 리다이렉트되었습니다.검증: 모든 어원은 etymonline.com · Oxford English Dictionary · Merriam-Webster 로 교차검증한 결과만 정리했습니다. 작성 방식·검증 절차는 Editorial Policy 참조.
왜 이 8개를 한 페이지로 묶는가
접두사 시리즈를 쓸 때는 단어의 앞만 봤다. re-, pre-, trans- 처럼 단어 머리에 붙어 방향과 시점을 바꾸는 형태소들이었다. 그런데 정작 개발 문서에서 내가 매일 읽는 단어들의 의미를 결정하는 건 꼬리 쪽이었다. deployment, migration, exception, nullable, stateless — 이 단어들이 명사인지 형용사인지, 어떤 추상 개념을 가리키는지는 전부 끝에 붙은 접미사가 정한다.
접미사를 한 줄로 정의하면 이렇다: 품사를 바꾸는 형태소. 동사나 형용사를 명사로 바꾸거나, 명사·동사를 형용사로 바꾼다. deploy(동사)에 -ment가 붙으면 deployment(명사, 배포된 것)가 되고, null(명사)에 -able이 붙으면 nullable(형용사, null이 될 수 있는)이 된다. 어근의 뜻은 그대로 두고, 그 단어가 문장에서 맡는 역할만 바꾸는 장치다.
묶고 나니 한 가지가 선명해졌다. 개발 문서의 추상 어휘는 사실상 두 무리로 갈린다.
- 명사를 만드는 접미사 —
-tion/-sion(migration, exception, serialization),-ment(deployment, requirement),-ure(failure, closure, signature),-ness(readiness, correctness, robustness). "그 동작/상태를 가리키는 추상명사" 를 만든다. - 형용사를 만드는 접미사 —
-able/-ible(nullable, serializable, observable),-less(stateless, serverless, timeless),-ful(useful, stateful, meaningful),-ent/-ant(persistent, idempotent, concurrent, redundant). "그런 성질을 가진" 형용사를 만든다.
그래서 이 글은 단어를 외우게 하려는 글이 아니다. 어떤 접미사가 붙어 있는지만 보면 그 단어가 명사인지 형용사인지, 대략 어떤 추상 개념인지 가 보이도록 형태소 단위로 분해하는 글이다. stateful과 stateless가 정확히 반대인 이유(둘 다 state에 정반대 접미사가 붙은 것), persistent에 -ce를 붙이면 persistence가 되는 이유 — 이런 게 한 페이지에서 한꺼번에 보이게 묶었다.
한 장 요약
| 접미사 | 무엇을 만드나 | 핵심 의미 | 개발에서 자주 보는 단어 |
|---|---|---|---|
| -tion/-sion | 동사 → 명사 | 행위·과정·결과의 명사화 | migration, serialization, exception, partition |
| -ment | 동사 → 명사 | 행위의 결과물·수단·상태 | deployment, requirement, argument, environment |
| -ure | 동사/형용사 → 명사 | 행위의 결과물·과정·상태 | failure, closure, structure, signature |
| -ness | 형용사 → 명사 | ~인 상태, ~의 성질 (게르만 계열) | readiness, correctness, robustness, uniqueness |
| -able/-ible | 동사 → 형용사 | ~할 수 있는 (가능·적합) | nullable, serializable, observable, scalable |
| -less | 명사 → 형용사 | ~이 없는, ~으로부터 자유로운 | stateless, serverless, seamless, timeless |
| -ful | 명사 → 형용사 | ~으로 가득한, ~의 성질을 가진 | useful, stateful, meaningful, successful |
| -ent/-ant | 동사 → 형용사/명사 | ~하는 성질의 / ~하는 것 (현재분사 어미) | persistent, concurrent, idempotent, component |
아래에서 8개를 하나씩 분해한다. 각 항목은 핵심 의미 → 대표 단어 표(원본 카드 정리) → 개발 맥락 한 단락 순서다.
1. -tion/-sion — 동사를 "행위·결과 명사"로
- 유래: 라틴어
-tionem→ 고대 프랑스어-tion→ 영어-tion. 영어 명사 접미사 중 사용 빈도 최다. - 핵심 의미: 동사를 명사로 바꾼다. 크게 두 갈래 — 행위/과정(creation = 만드는 행위), 상태/결과(solution = 푼 결과).
| 단어 | 동사 원형 | 뜻 | 유형 |
|---|---|---|---|
| creation | create | 창조, 창작 | 행위 |
| action | act | 행동 | 행위 |
| operation | operate | 운영, 동작 | 행위 |
| solution | solve | 해결책 | 결과 |
| decision | decide | 결정 | 결과 |
| position | pose/posit | 위치 (놓인 상태) | 상태 |
| permission | permit | 허가 (허락한 결과) | 결과 |
철자 규칙은 동사의 끝글자가 정한다. -ate로 끝나면 -ation(create → creation), -t/-ct면 -tion(act → action), -de/-d면 -sion(decide → decision, expand → expansion), -mit/-ss면 -ssion(permit → permission, discuss → discussion).
개발 맥락: 백엔드 문서에 들어 있는 명사의 절반쯤은 사실상 -tion 명사다 — production, distribution, replication, partition, optimization, serialization, migration. 핵심은 동사형을 알면 명사형이 자동으로 잡힌다는 점이다. replicate를 알면 replication, serialize를 알면 serialization이 그냥 따라온다. 예외처리의 exception도 except(빼내다)에서 온 -tion 명사다 — "정상 흐름에서 빼낸 사건". DB 마이그레이션 문서를 읽을 때 "migration(이동시키는 행위)" 이라는 어감만 잡혀도 절반은 읽은 셈이다.
serialization이 좋은 예다. Jackson으로 객체를 JSON으로 직렬화할 때 필드에 @JsonProperty("user_id")를 붙이면 자바의 userId 필드가 출력에서 user_id로 바뀐다 — 직렬화(serialize, "한 줄로 늘어세우다")라는 행위가 끝나 만들어진 결과물이 serialization이고, 그 역과정이 deserialization이다. Kafka 파이프라인에서 "serialization format"을 Avro로 둘지 Protobuf로 둘지 정하는 결정도 결국 이 -tion 명사를 두고 하는 얘기다. partition도 마찬가지 — part(나누다)의 결과로 카프카 토픽이 여러 조각으로 쪼개진 그 단위가 partition이고, "partition key가 같으면 같은 partition으로 간다"는 문장은 -tion이 "나눈 결과물"을 가리킨다는 걸 알면 그냥 읽힌다. 동사 partition(나누다)과 명사 partition(나뉜 조각)이 철자가 같아 보이지만, 후자가 -tion이 붙어 굳은 명사라는 점만 잡으면 헷갈리지 않는다.
2. -ment — 동사를 "행위의 결과물·수단·상태"로
- 유래: 라틴어
-mentum("~하는 데 쓰이는 것" 또는 "~한 결과") → 고대 프랑스어-ment→ 영어-ment.instrumentum(도구 = 쓰이는 것),documentum(문서 = 가르침의 결과)이 원형 이미지. - 핵심 의미: 동사에 붙어 "그 행위가 만들어낸 것" 을 명사화한다.
-tion보다 구체적인 산출물 느낌이 강하다.
| 단어 | 동사 기원 | IT 맥락 |
|---|---|---|
| deployment | deploy(배치하다) | Kubernetes Deployment, 배포 단위 |
| requirement | require(요구하다) | functional requirement, system requirements |
| measurement | measure(측정하다) | latency measurement, performance measurement |
| statement | state(진술하다) | SQL statement, problem statement |
| argument | argue(주장하다) | function argument, command-line argument |
| management | manage(관리하다) | memory/state/dependency management |
| commitment | commit(확약하다) | git commit, SLA commitment |
| environment | environ(둘러싸다) | dev/staging/prod environment, runtime environment |
개발 맥락: deployment, requirement, argument, environment, management — 이 다섯 단어를 하루에 쓰지 않는 백엔드 개발자는 드물다. 전부 -ment 패밀리라는 걸 알면 묶어서 외울 수 있다. 특히 헷갈리는 건 argument다. argue(주장하다)에서 왔지만 코드에서는 "함수에 넘기는 인자" — 호출자가 함수에게 "이게 그 값이다" 라고 주장해서 건네는 것이라고 보면 어원과 코드 의미가 이어진다. statement도 마찬가지로 SQL이든 if문이든 "하나의 완결된 진술" 단위다.
deployment는 어원의 "행위의 결과물" 어감이 도구 이름에 그대로 박힌 경우다. Kubernetes에서 kind: Deployment라고 쓰는 YAML은 "배포한다(deploy)는 동작"이 아니라 "배포의 결과로 유지되어야 하는 상태"를 선언하는 오브젝트다 — 그래서 명사 Deployment가 ReplicaSet과 Pod를 거느리고, kubectl rollout이 그 명사를 두고 버전을 굴린다. argument와 parameter의 구분도 이 어원 감각으로 갈린다. 함수 정의부 def send(to, body)의 to·body는 자리(parameter, "옆에 둔 것")이고, 호출부 send("a@b.com", "hi")에서 실제로 건네는 "a@b.com"이 argument(주장해서 넘긴 값)다. 에러 로그에서 TypeError: missing 1 required positional argument를 볼 때, 빠진 게 "자리"가 아니라 "건네받지 못한 값"이라는 점을 떠올리면 메시지가 정확히 읽힌다.
3. -ure — 동사를 "굳어진 결과물·과정·상태"로
- 유래: 라틴어
-ura(동사 어간 +-ura→ 행위의 결과/상태) → 고대 프랑스어-ure→ 영어-ure. - 핵심 의미: 동사·형용사를 명사로 바꾼다. "그 행위가 굳어진 결과물" 이라는 어감이 핵심 — 결과물(structure, signature), 과정/절차(procedure, closure), 상태(failure, exposure).
| 단어 | 분해 | IT/개발 맥락 |
|---|---|---|
| structure | struct(쌓다) + ure | data structure, struct 타입 |
| architecture | archi + tect + ure | 시스템 아키텍처, MSA, 클린 아키텍처 |
| configure | con + fig(형태) + ure | configuration file, 서버/앱 설정 |
| closure | clos(닫다) + ure | 함수형 프로그래밍의 클로저 |
| procedure | pro + ced(가다) + ure | stored procedure, 호출 절차 |
| failure | fail + ure | 서버 장애, failure handling, fallback |
| exposure | ex + pos(놓다) + ure | API 노출, 보안 취약점 exposure |
| signature | sign(표시) + ature | function signature, 디지털 서명 |
개발 맥락: -ure가 흥미로운 건 "닫힌 것", "쌓아 만든 것", "실패한 상태" 처럼 동작이 명사로 굳어버린 느낌을 준다는 점이다. closure(클로저)가 좋은 예 — close(닫다)에서 왔고, 함수가 자기 스코프를 "닫아서 가둔" 결과물이다. failure는 fail(실패하다)이 굳어 "장애 상태" 라는 명사가 된 것. signature(함수 시그니처)는 그 함수를 "서명처럼 식별하는 형태" 다. infrastructure, architecture, structure가 모두 struct(쌓다) 계열로 묶이는 것도 한 번에 보인다.
closure를 코드로 보면 어원이 더 선명하다. 자바스크립트에서 function counter() { let n = 0; return () => ++n; }이 반환하는 화살표 함수는 바깥 스코프의 n을 "닫아서 가둔 채" 들고 다닌다 — 함수가 자기를 둘러싼 변수 환경을 close해 묶은 그 결과물이 closure다. failure는 SRE 문서에서 명사로 굳은 정도가 특히 두드러진다. "cascading failure"(연쇄 장애), "single point of failure(SPOF)", "failure domain" — 전부 fail이라는 동사가 아니라 "장애라는 상태/지점"을 가리키는 명사 자리에 들어가 있다. signature도 실무 두 맥락에서 같은 "식별하는 형태" 어감을 공유한다 — 컴파일러가 보는 function signature(이름+인자 타입+반환 타입의 조합으로 오버로딩을 구분하는 형태)와, JWT나 TLS의 digital signature(메시지를 서명처럼 식별·검증하는 형태)가 그것이다. closure·failure·signature를 따로 외울 게 아니라, 셋 다 동작이 명사로 굳은 -ure 가족으로 묶어 두면 새 단어 exposure(노출된 상태)·procedure(절차로 굳은 호출 순서)도 같은 틀로 짚인다.
4. -ness — 형용사를 "상태·성질 명사"로
- 유래: 고대 영어
-nes/-ness← Proto-Germanic*-nassu(상태/성질). 게르만 계열 접미사라는 점이 중요하다. - 핵심 의미: 형용사 뒤에 붙어 "그 상태/성질" 을 가리키는 추상명사를 만든다. 영어에서 가장 생산적인 접미사 중 하나로, 어떤 형용사에든 붙일 수 있다.
| 단어 | 분해 | IT/개발 맥락 |
|---|---|---|
| readiness | ready + ness | readiness probe (K8s), 배포 준비 상태 |
| robustness | robust + ness | 에러에 강한 서비스 설계 |
| correctness | correct + ness | 알고리즘 정확성 검증 |
| uniqueness | unique + ness | uniqueness constraint (DB), UUID |
| effectiveness | effective + ness | 캐시·알고리즘 효과성 |
| laziness | lazy + ness | lazy evaluation (지연 평가) |
| randomness | random + ness | 암호화의 난수성 |
| openness | open + ness | open-source openness, 개방형 API |
개발 맥락: Kubernetes를 만지면 readiness와 liveness를 매일 본다 — readiness probe(요청 받을 준비가 됐는가), liveness probe(살아 있는가). 둘 다 형용사 ready/live에 -ness가 붙은 상태 명사다. 코드 리뷰에서 시스템 품질을 말할 때도 robustness(견고함), correctness(정확성), uniqueness(고유성)처럼 -ness가 자연스럽게 나온다. 여기서 중요한 분할 하나 — 게르만 계열 형용사는 -ness, 라틴 계열은 -ity 를 쓰는 경향이 있다. ready → readiness(게르만)지만 available → availability(라틴)인 식이다. 그래서 같은 "성질" 이라도 robustness는 -ness, scalability는 -ity로 갈린다.
probe 두 개를 실무에서 구분하는 감각도 이 어원 차이와 정확히 맞물린다. liveness probe가 실패하면 kubelet은 컨테이너를 죽이고 재시작하지만(살아 있지 않으니), readiness probe가 실패하면 죽이지 않고 Service의 엔드포인트 목록에서만 빼낸다(아직 받을 준비가 안 됐을 뿐이니). live(살아 있는)와 ready(준비된)라는 두 형용사의 상태 차이가 그대로 운영 동작의 차이로 번역되는 셈이다. correctness도 분산 시스템 글에서 무게가 다르다 — "linearizability는 강한 correctness 조건이다" 같은 문장에서 correctness는 "그냥 맞다"가 아니라 "동시 연산이 어떤 순서로 보여야 옳은가라는 성질"을 가리키는 명사로 쓰인다. 그리고 게르만/라틴 분할은 코드 네이밍에서 실제로 부딪힌다 — DB 제약을 uniqueness constraint라 부르지만 SQL 키워드는 UNIQUE이고, 한편 SLA 문서의 가용성은 uniqueness처럼 -ness로 가지 않고 라틴 계열 availability로 굳어 "99.9% availability"가 표준 표기가 된다.
5. -able/-ible — 동사를 "~할 수 있는 형용사"로
- 유래: 라틴어
-abilis / -ibilis→ 프랑스어-able→ 영어. 동사 → 형용사 변환. - 핵심 의미: "그 동작이 가능한(capable of being)" — 가능(readable, washable), 가치/적합(remarkable, comfortable).
| 단어 | 분해 | 뜻 |
|---|---|---|
| available | avail(쓸모) + able | 이용 가능한 |
| readable | read(읽다) + able | 읽을 수 있는 |
| portable | port(나르다) + able | 휴대·이식 가능한 |
| possible | poss(할 수 있다) + ible | 가능한 |
| flexible | flex(굽다) + ible | 유연한 (굽힐 수 있는) |
| visible | vis(보다) + ible | 볼 수 있는 |
| responsible | respons(응답) + ible | 책임 있는 |
-able과 -ible의 구분은 실용 규칙 하나면 충분하다 — 접미사를 떼었을 때 영어 단어로 성립하면 -able(read + able), 라틴 어근만 남아 단독으로 안 되면 -ible(vis + ible, poss + ible).
개발 맥락: -able은 SaaS·클라우드 시대 시스템 디자인 원칙을 한 단어로 압축하는 형용사다 — scalable(확장 가능한), observable(관측 가능한), configurable(설정 가능한), composable(조합 가능한). 자바·코틀린의 인터페이스 이름이 Comparable, Iterable, Serializable, Runnable인 것도 같은 패턴 — "이 타입은 비교/순회/직렬화/실행 할 수 있다" 는 능력 선언이다. 코틀린의 nullable(null이 될 수 있는 타입)도 정확히 같은 구조다. -able이 붙은 이름을 보면 "이게 무엇을 할 수 있는 성질인가" 로 읽으면 거의 맞는다.
자바의 Serializable이 이 능력 선언을 가장 순수하게 보여준다. 이 인터페이스에는 구현할 메서드가 하나도 없다 — public interface Serializable {}로 텅 비어 있는 marker interface다. 메서드를 강제하는 대신 단지 "이 타입은 직렬화 될 수 있다"는 가능성만 타입 시스템에 선언하고, JVM이 implements Serializable이 붙은 클래스만 ObjectOutputStream에 흘려보낸다. -able이 "할 수 있음"이라는 어원 그대로, 능력의 유무를 타입으로 표시하는 장치인 셈이다. 같은 감각이 API 설계에도 박힌다 — idempotent한 엔드포인트를 만들면 클라이언트가 안전하게 retryable(재시도 가능)해지고, 메트릭과 로그·트레이스를 갖춰 시스템이 observable해지면 장애를 디버깅 가능한 상태로 둔다. -able로 끝나는 형용사가 설계 문서 제목에 자주 오르는 건, 그 단어들이 전부 "우리 시스템이 무엇을 할 수 있는 상태인가"라는 품질 목표를 한 단어로 못박기 때문이다.
6. -less — 명사를 "~이 없는 형용사"로
- 유래: 고대 영어
-leas(없는, 자유로운) ← Proto-Germanic*lausaz(풀린, 자유로운) ← PIE*leu-(자르다, 풀다). - 핵심 의미: 명사 뒤에 붙어 "그것이 결여된 / 그것으로부터 자유로운" 형용사를 만든다.
-ful(가득한)의 반의 접미사.
| 단어 | 분해 | IT/개발 맥락 |
|---|---|---|
| stateless | state(상태) + less | stateless API/서버 — 스케일 아웃 핵심 |
| serverless | server + less | Lambda, Cloud Functions — 서버 관리 없음 |
| seamless | seam(이음새) + less | seamless migration, 매끄러운 전환 |
| wireless | wire(선) + less | WiFi, 무선 프로토콜 |
| limitless | limit(한계) + less | limitless scaling |
| endless | end(끝) + less | endless loop (무한루프), endless scroll |
| flawless | flaw(결함) + less | flawless deployment |
| meaningless | meaning + less | 의미 없는 변수명, meaningless log |
개발 맥락: 현대 클라우드 아키텍처의 핵심 키워드 셋이 전부 -less다. stateless(서버가 클라이언트 상태를 기억하지 않음 → 수평 확장 가능), serverless(개발자가 서버를 직접 관리하지 않음 → 인프라 추상화), seamless(사용자가 전환점을 느끼지 못함 → 좋은 UX). 여기서 -less는 단순 결핍이 아니라 "그 제약으로부터 자유롭다" 는 긍정적 뉘앙스다 — 어원의 *lausaz(풀린, 자유로운)가 그대로 살아 있다. 상태를 안 가져서 부담이 없는 게 stateless의 강점이듯이. 비슷하게 보이는 -free(error-free)와 결이 다른 점도 여기 있다 — -free는 "그것이 없어서 깨끗한", -less는 "그것 없이 동작하는".
stateless의 "상태로부터 자유롭다"가 왜 설계상 이득인지는 로드밸런서 뒤에 세워 보면 분명해진다. 세션을 서버 메모리에 들고 있는 stateful 서버는 같은 유저의 다음 요청이 반드시 같은 인스턴스로 가야 해서 sticky session이 필요하지만, JWT처럼 상태를 토큰에 실어 보내 서버가 아무것도 기억하지 않는 stateless 설계는 어떤 인스턴스가 받아도 똑같이 처리한다 — 그래서 Auto Scaling으로 인스턴스를 늘렸다 줄였다 해도 깨지지 않는다. serverless도 어원대로 읽으면 오해가 풀린다. AWS Lambda를 써도 서버는 분명히 존재한다 — 다만 개발자가 그 서버의 프로비저닝·패치·스케일링이라는 부담으로부터 자유로워질 뿐이다. "서버가 없다"가 아니라 "서버 관리 없이 동작한다"는 -less의 뜻 그대로다. seamless migration(이음새 없는 전환)도 같은 결 — DB를 무중단으로 옮길 때 사용자가 끊김(seam)을 느끼지 못하게 만든다는 목표를 한 단어가 담는다.
7. -ful — 명사를 "~으로 가득한 형용사"로
- 유래: 고대 영어
-full(←full, 가득 찬).-less의 정확한 반대. - 핵심 의미: 명사 뒤에 붙어 "그것으로 가득 찬 / 그 성질을 가진" 형용사를 만든다. 가득함(beautiful, powerful), ~을 일으킴(painful, fearful).
| 단어 | 분해 | 유형 |
|---|---|---|
| useful | use(쓸모) + ful | 가득한 |
| powerful | power(힘) + ful | 가득한 |
| successful | success(성공) + ful | 가득한 |
| helpful | help(도움) + ful | 가득한 |
| meaningful | meaning(의미) + ful | 가득한 |
| careful | care(주의) + ful | 가득한 |
| painful | pain(고통) + ful | 일으키는 |
| fearful | fear(두려움) + ful | 일으키는 |
개발 맥락: 백엔드에서 가장 자주 만나는 -ful은 단연 stateful이다 — 바로 stateless의 짝이다. 서비스가 stateful이라는 건 "상태를 가득(full) 가지고 있다" 는 의미 그대로다. 그래서 stateful 서비스는 복제(replication)가 복잡해지지만 in-flight 트랜잭션의 일관성 모델은 단순해진다. 로그 품질을 말할 때 쓰는 meaningful logs(의미가 가득한 로그)도 같은 패턴. 다만 주의할 점 하나 — 모든 -ful에 -less 짝이 있는 건 아니다. hopeful ↔ hopeless, powerful ↔ powerless는 성립하지만, beautiful의 반대는 beautiless(존재하지 않음)가 아니라 다른 단어다. stateful ↔ stateless처럼 짝이 깔끔하게 맞는 경우가 오히려 운이 좋은 쪽이다.
이 "상태를 가득 가짐"이 운영 부담으로 번역되는 지점이 Kubernetes의 StatefulSet이다. 무상태 워크로드는 Deployment로 굴리면 Pod가 죽어도 아무 새 Pod나 대신 받으면 되지만, DB나 Kafka처럼 각 인스턴스가 고유한 디스크 상태를 가득 들고 있는 워크로드는 StatefulSet으로 띄워 Pod마다 안정적인 네트워크 ID(mysql-0, mysql-1)와 전용 PersistentVolume을 보장받아야 한다 — 상태가 가득(full)하다는 형용사가 그대로 다른 컨트롤러 타입을 요구하는 것이다. meaningful 역시 실무 권고로 자주 나온다 — 예외를 던질 때 throw new RuntimeException()처럼 빈손으로 던지지 말고 meaningful한 메시지("user 4012 not found in tenant 7")를 실으라는 것이, 곧 그 로그를 "정보로 가득 차게" 만들라는 -ful의 요구다. 반대로 null이나 빈 문자열을 의미 없이 흘려보내는 코드가 meaningless해지는 것도 같은 축의 반대편이다.
8. -ent/-ant — 동사를 "~하는 성질의 형용사·행위자"로
- 유래: 라틴어 현재분사 어미
-entem / -antem→ 고대 프랑스어 → 영어.-ent는 라틴어 2·3변화 동사,-ant는 1변화 동사에서 왔지만 실용적 차이는 거의 없다. - 핵심 의미: 동사를 형용사(~하는 성질의) 또는 명사(그 역할을 하는 것)로 바꾼다. 현재분사 어미라서 "지금 ~하고 있는" 어감이 깔려 있다.
| 단어 | 분해 | IT/개발 맥락 |
|---|---|---|
| persistent | per + sist(서다) + ent | persistent volume/connection |
| concurrent | con + curr(달리다) + ent | concurrent requests, 동시성 |
| consistent | con + sist(서다) + ent | eventual consistency, consistent hashing |
| resilient | re + sili(뛰다) + ent | resilient system, 장애 복구 설계 |
| efficient | ef + fic(만들다) + ient | efficient algorithm, 시간복잡도 최적화 |
| redundant | re + und(넘치다) + ant | redundant server (이중화), 잉여 코드 |
| component | com + pon(놓다) + ent | UI/마이크로서비스 컴포넌트 |
| dependent | de + pend(매달리다) + ent | 의존성(dependency), 종속 서비스 |
개발 맥락: 분산 시스템 문서를 읽으면 -ent 형용사가 쏟아진다 — persistent(영속하는), concurrent(동시의), consistent(일관된), resilient(탄력적인), transparent(투명한). 전부 시스템의 "성질" 을 가리킨다. 멱등성의 idempotent도 같은 가족이다 — HTTP PUT/DELETE를 설계할 때 핵심인 "여러 번 호출해도 결과가 같은 성질". 그리고 결정적인 패턴 하나 — -ent 형용사에 -ce/-cy를 붙이면 추상명사가 된다. persistent → persistence, consistent → consistency, efficient → efficiency, idempotent → idempotence. 그래서 "persistence layer", "eventual consistency" 같은 용어가 자연스럽게 만들어진다. -ent가 형용사 자리를, -ence가 그 성질의 명사 자리를 맡는 짝이다.
이 형용사 → 명사 변환이 실제 아키텍처 용어로 굳는 장면을 보면 외울 게 줄어든다. Spring에서 @Repository가 사는 계층을 persistence layer라 부르는데, 이건 persistent(영속하는)라는 성질을 -ence로 명사화해 "영속성을 담당하는 층"이라 이름 붙인 것이다. JPA의 핵심 객체 EntityManager가 관리하는 1차 캐시도 persistence context라 불린다 — 같은 명사가 또 등장한다. consistent → consistency도 마찬가지다. CAP 정리의 C가 consistency이고, 분산 DB가 "지금 당장은 노드마다 값이 다를 수 있지만 결국 같아진다"는 모델을 eventual consistency(궁극적 일관성)라 부를 때, 형용사 consistent가 -cy를 달고 명사 자리로 옮겨 앉는다. idempotent → idempotence도 결제 API 설계에서 그대로 쓰인다 — 같은 Idempotency-Key 헤더로 두 번 요청해도 한 번만 결제되게 보장하는 그 성질의 이름이다. 그래서 -ent 형용사 하나를 알면 -ence/-ency 명사가 거의 공짜로 따라오고, "이 시스템은 consistent하다"와 "consistency를 보장한다"가 같은 성질의 형용사 자리·명사 자리일 뿐임이 보인다.
보너스 — -ate: 동사를 만드는 접미사
이 페이지의 8개는 명사·형용사를 만든다. 짝으로 늘 함께 보는 -ate 는 반대로 동사 를 만들기에, 한곳에 정리해 둔다. 라틴어 과거분사 -atus 에서 왔고, 명사·형용사에 붙어 "~한 상태로 만들다"라는 동사가 된다. 개발 동사의 상당수가 여기서 나온다 — allocate, validate, migrate, generate, terminate. 같은 철자가 명사·형용사로 굳은 경우(candidate, private)도 있어 품사를 문맥으로 구분한다.
- A. 동사 — "~하게 하다" —
activate(활성화하다),validate(유효하게 하다) - B. 명사·형용사로 굳음 —
candidate(후보),duplicate(중복: 동사/명사 둘 다)
| 단어 | 분해 | 뜻 | 유형 |
|---|---|---|---|
| allocate | al(=ad, ~에) + loc(장소) + ate | (메모리를) 할당하다 | A. 동사 |
| validate | valid(유효한) + ate | 검증하다 | A. 동사 |
| migrate | migr(옮기다) + ate | 이전하다 | A. 동사 |
| generate | gener(낳다) + ate | 생성하다 | A. 동사 |
| terminate | termin(끝) + ate | 종료시키다 | A. 동사 |
| deprecate | de(아래로) + prec(빌다) + ate | 사용 중단 처리하다 | A. 동사 |
| duplicate | dupli(둘) + ate | 복제하다 / 중복 | B. 동사·명사 |
개발 맥락: -ate 는 거의 항상 "무언가를 어떤 상태로 만드는" 동작이라, API·함수 이름의 동사 자리에서 끝없이 마주친다. 메모리의 allocate/deallocate, 입력의 validate, 스키마의 migrate, 코드의 generate, 프로세스·연결의 terminate, 더 이상 쓰지 말라는 deprecate. 명사형이 필요하면 다시 -tion 을 붙여 allocation·validation·migration 으로 굳는다 — 즉 동사(-ate) → 명사(-ation) 변환이 한 묶음으로 움직인다(이 페이지 1번 항목 -tion 과 연결된다).
명사형 vs 형용사형 — 한눈에
8개를 다시 두 줄로 가르면 이렇다.
| 명사를 만드는 접미사 | 무엇에 붙나 | 대표 |
|---|---|---|
| -tion/-sion | 동사 | migration, exception |
| -ment | 동사 | deployment, requirement |
| -ure | 동사/형용사 | failure, closure |
| -ness | 형용사 | readiness, correctness |
| 형용사를 만드는 접미사 | 무엇에 붙나 | 대표 |
|---|---|---|
| -able/-ible | 동사 | nullable, serializable |
| -less | 명사 | stateless, serverless |
| -ful | 명사 | stateful, useful |
| -ent/-ant | 동사 | persistent, idempotent |
읽는 요령: 단어 끝이 -tion / -ment / -ure / -ness 면 십중팔구 추상명사("그 행위/상태를 가리키는 것")이고, -able / -less / -ful / -ent 면 형용사("그런 성질을 가진")다. 그리고 두 무리는 서로 변환된다 — 형용사 persistent에 -ce를 붙이면 명사 persistence, 동사 deploy에 -ment를 붙이면 명사 deployment, 다시 deploy에 -able을 붙이면 형용사 deployable. 어근 하나를 두고 접미사만 갈아 끼우면 명사·형용사가 자유롭게 오간다.
한 줄로 묶으면
접미사는 어근의 뜻은 두고 품사만 바꾸는 장치다. -tion·-ment·-ure·-ness는 명사를, -able·-less·-ful·-ent는 형용사를 만든다. 개발 문서에서 마주치는 추상 어휘 — migration, deployment, failure, readiness, nullable, stateless, stateful, persistent — 는 전부 이 8개 접미사 중 하나가 붙은 결과다. 단어를 통째로 외우는 대신 어근 + 어떤 접미사 인지만 분해하면, 그 단어가 명사인지 형용사인지·대략 어떤 개념인지가 한눈에 잡힌다. stateful과 stateless가 정반대인 이유, persistent에서 persistence가 나오는 이유가 형태소 한 칸 차이로 보인다.
함께 읽으면 좋은 어원 허브
같은 시리즈에서 형태소 단위로 개발 영어를 분해한 다른 글이다.
- 라틴어 접두사 6개 — re·pre·pro·trans·per·un — 단어 앞머리가 정하는 방향·시점.
- 라틴어 어근 6개 — port·duct·vis·spect·man·per — 단어의 의미 핵.
- 개발 영어 ‘~성’ 단어 — -ity / -ability — availability·scalability·reliability를 한 페이지로.
참고
- Online Etymology Dictionary — etymonline.com
- Oxford English Dictionary (subscription) — oed.com
- Merriam-Webster — merriam-webster.com
이 글의 개정 이력
- 2026-06-20 (발행일) — 기존 접미사 노트 8편(
-tion/-sion,-ment,-ure,-able/-ible,-ness,-less,-ful,-ent/-ant)을 한 페이지로 통합·재작성. 원본 8편은 본 글로 영구 301 리다이렉트. AdSense Low value content 정비 Phase 2.
답글 남기기