이 글의 위치: 영어(English) → 어원(Etymology) → 접미사(Suffix) / 동시 분류: 기술 블로그 → Backend
시리즈 hub: 본 글은 기존 7편의 짧은 어원 노트(-ity,-ability,availability,scalability,reliability,sanity,provision) 를 하나의 학습 단위로 통합하여 다시 정리한 long-form 글입니다. 원본 7편은 본 글로 영구 301 리다이렉트되었습니다.검증: 모든 어원은 etymonline.com · Oxford English Dictionary · Merriam-Webster 로 교차검증한 결과만 정리했습니다. 작성 방식·검증 절차는 Editorial Policy 참조.
왜 이 시리즈를 한 번 더 정리하는가
처음 어원 노트를 쓸 때는 단어 하나에 한 글을 썼다. 그러다 availability 노트를 쓰고 며칠 뒤 scalability 노트를 쓰면서 묘하게 같은 말을 두 번 하고 있다는 느낌이 들었다. -able + -ity 가 합쳐진 자리에는 어떤 어근이 들어가도 의미 패턴이 거의 같다 — "그 동작/상태가 가능한 정도" 라는 명사가 만들어진다.
그래서 한 번 묶었다. 묶고 나니 한 가지 더 보였다. 백엔드 엔지니어가 매일 보는 단어들 — SRE 의 4 대 키워드 중 3 개(availability, reliability, scalability) 가 같은 접미사를 공유한다는 사실이다. 우연이 아니다. 관측하고 측정할 수 있는 시스템의 성질 을 가리키는 말이라 자연스럽게 같은 형태소를 쓴다.
이 글은 그래서 두 가지 독자를 동시에 겨냥한다:
- 영어 어휘를 형태소 단위로 이해하고 싶은 사람 —
-ity와-ability가 다른 접미사가 아니라 같은 가족이라는 사실을 분해해 본다. - 개발 문서를 매일 읽는 사람 — Kubernetes 의 HPA(
scalability), Postgres 의 HA(availability), SLO 의 4 골든 시그널 중 한 축인error rate / availability등 실제 문서에서 마주치는 용어의 의미를 한 줄로 분해할 수 있게 된다.
한 줄 정의: -ity 와 -ability 의 차이는 사실 차이가 아니다
| 접미사 | 어디서 왔나 | 무엇을 하나 |
|---|---|---|
| -ity | 라틴어 -itās → 고대 프랑스어 -ité → 영어 -ity. 형용사를 추상명사로 바꿈. |
"그 형용사가 가리키는 상태·성질" |
| -able / -ible | 라틴어 -ābilis. 동사에 붙여 "그 동작이 가능한 (capable of)" 형용사를 만듦. |
"X 할 수 있는" |
| -ability | 위 두 개의 연쇄 합성: -able + -ity = "X 할 수 있는 상태/성질" |
즉, -ability 는 독립 접미사가 아니라 -able + -ity 의 빈번한 결합이 굳어진 것. |
그래서 sanity (san + ity) 와 availability (avail + able + ity) 는 같은 접미사 가족 안에 있다. 전자는 한 번만 추상화, 후자는 두 번 추상화(가능성 → 그 가능성의 정도)일 뿐.
7개 단어 한 페이지 분해
각 항목은 형태소 분해 → 직역 → 영영 사전 정의 → 개발/실무 맥락에서의 쓰임 순.
1. availability — avail + able + ity
- 분해:
a- (라틴 ad-, "쪽으로")+val/vail (라틴 valēre, "강하다, 가치 있다")+-able+-ity - 직역: "쓸 수 있는 상태로 강한 정도" → "이용 가능한 정도"
- OED: "the quality of being available or accessible; the state of being free or unoccupied"
- 개발 맥락:
Postgres HA · Kubernetes Pod readiness · SLO 의 4 골든 시그널 중availability는 보통(성공한 요청 수) / (전체 요청 수)의 비율로 정의된다."Our SLO target is 99.9% availability over a rolling 30-day window."
3-nine 은 한 달에 약 43 분의 다운타임, 4-nine 은 약 4.3 분. 9 한 자리가 비용을 한 자릿수 끌어올린다.
2. scalability — scala + able + ity
-
분해:
scala (라틴어 "사다리, 계단")+-able+-ity -
직역: "사다리(단계)를 오를 수 있는 정도" → "단계적으로 확장 가능한 성질"
-
OED: "the ability to be scaled in size"
-
개발 맥락:
Kubernetes HPA(Horizontal Pod Autoscaler) 가 다루는 차원, 데이터베이스의 sharding 가능 여부, 캐시 레이어를 더해서 throughput 이 늘어나는 정도. 보통 두 가지로 쪼개서 말한다:- vertical scalability — 같은 노드의 자원을 키워서 (CPU/메모리 증설)
- horizontal scalability — 노드 수를 늘려서
scala (사다리)가 어근이라는 점이 중요한데, 단순히 "크기" 가 아니라 "단계적으로 위로 쌓을 수 있다" 라는 어감이 있다. 그래서 elastic (탄력적) 과는 결이 다르다.
3. reliability — re + lig + able + ity
-
분해:
re- (강조, "강하게")+lig (라틴 ligāre, "묶다")+-able+-ity -
직역: "단단히 묶여 의지할 수 있는 정도" (어원적으로
religion과 같은 어근. "다시 묶다 = 우리를 신에게 다시 결속") -
OED: "the quality of being reliable; the ability to be trusted to perform consistently well"
-
개발 맥락:
SRE 에서reliability는 보통 두 가지 지표로 추적된다:- MTBF (Mean Time Between Failures) — 평균 무고장 시간
- MTTR (Mean Time To Recovery) — 장애 시 평균 복구 시간
availability가 "지금 살아 있는가" 의 비율이라면,reliability는 "얼마나 자주 죽지 않고 잘 돌아가는가" 의 시간 분포 다. 예를 들어 99.99% availability 라도 reliability 가 낮으면 짧고 잦은 장애가 많을 수 있다.
4. sanity — san + ity
- 분해:
san (라틴 sānus, "건강한, 온전한")+-ity - 직역: "온전한 상태" → 제정신, 합리적 판단력
- OED: "the quality of being sane; reasonable and rational behaviour"
- 개발 맥락:
코드에서 자주 쓰는 표현은sanity check. 명시적 단위 테스트보다 가벼운, "이 함수가 최소한 미친 짓을 하지는 않는지" 빠르게 확인하는 검사.// Sanity check — config 가 비어 있으면 즉시 panic if cfg.DatabaseURL == "" { panic("sanity: DatabaseURL is required") }같은 어근에서 온 친척 단어:
sanitary(위생적인),sanatorium(요양소),insane(제정신 아닌 = in- + sane).
5. provision — pro + vis + ion
-
분해:
pro- ("앞으로, 미리")+vis (라틴 vidēre, "보다")+-ion (행위/결과 명사화) -
직역: "미리 내다본 것" → 미리 마련해 둠, 예비
-
OED: "the action of providing or supplying something for use; a supply of food and other necessities, especially for a journey"
-
개발 맥락:
provisioning으로 동명사화되어 "자원을 미리 세팅해 두는 행위" 를 가리킨다. Terraform 이 하는 일, Kubernetes 의StorageClass.provisioner, GCP 의 IAM Workload Identity 사전 셋업 등이 모두 provisioning.pro + vis의 어원을 알면 "미래에 필요할 것을 미리 보고 준비" 라는 어감이 자연스럽게 잡힌다.note:
provision은-able / -ity조합이 아니지만, 같은 SRE 어휘 가족에 속해 함께 정리. 분해의 핵심 어근(vis = 보다) 은vision,visible,revise,supervise와 공유된다.
6. -ity 그 자체 — 형용사를 추상명사로
-ity 는 영어 단독으로는 거의 항상 형용사 뒤에 붙는다.
| 형용사 | + ity | 의미 |
|---|---|---|
sane |
sanity |
온전한 상태 |
able |
ability |
할 수 있는 상태 |
pure |
purity |
순수한 상태 |
equal |
equality |
동등한 상태 |
secure |
security |
안전한 상태 |
complex |
complexity |
복잡한 상태 |
dense |
density |
밀한 상태 |
valid |
validity |
유효한 상태 |
규칙: 라틴 어근 형용사 + -ity 가 자연스러움. 게르만 계열 형용사(good, tall, hard)는 -ity 가 아닌 -ness 를 쓴다 (goodness, tallness, hardness). 이 분할은 영어가 라틴어와 고대 영어를 모두 흡수한 흔적이다.
7. -ability 그 자체 — 동사를 "가능성 명사" 로
-ability 는 항상 동사에 붙어 그 동작의 "가능성/성질" 을 가리키는 명사를 만든다.
| 동사 | + ability | 의미 |
|---|---|---|
read |
readability |
읽을 수 있는 정도 (= 가독성) |
test |
testability |
테스트 가능한 정도 |
observe |
observability |
관측 가능한 정도 |
maintain |
maintainability |
유지보수 가능한 정도 |
deploy |
deployability |
배포 가능한 정도 |
port |
portability |
옮길 수 있는 정도 (이식성) |
compose |
composability |
조합 가능한 정도 |
predict |
predictability |
예측 가능한 정도 |
SRE 의 4 골든 시그널 중 3 개가 -ability 가족인 이유: 시스템의 측정 가능한 성질 을 가리킬 때 영어가 자연스럽게 도달하는 단어 형태가 이것이기 때문이다. observability 라는 단어가 2010 년대 후반에 갑자기 SRE 어휘로 굳어진 것도 같은 맥락 — "측정할 수 있는 성질" 을 한 단어로 가리켜야 했고, 그 자리에 -ability 가 정확히 맞아 들어갔다.
한 줄로 묶으면
-able 은 "할 수 있는", -ity 는 "그 상태", -ability 는 그 둘의 합. 이 셋을 어근으로 분해하면 SRE · K8s · Postgres 문서에서 마주치는 abstract noun 들이 한 가족으로 보인다. 단어를 외우는 대신, 어떤 어근에 -able + -ity 가 붙어 있는지 만 보면 의미가 80% 잡힌다.
다음 글에선 -tion / -sion (행위 → 결과 명사화) 시리즈를 같은 방식으로 묶어 보려 한다.
참고
- Online Etymology Dictionary — etymonline.com
- Oxford English Dictionary (subscription) — oed.com
- Merriam-Webster — merriam-webster.com
- Google SRE Book, "Embracing Risk" 챕터 (availability·reliability 측정 정의) — sre.google/sre-book
- Kubernetes 공식 문서, HPA — kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
이 글의 개정 이력
- 2026-05-XX (발행일) — 최초 발행. 기존 7편 어원 노트 통합. AdSense W6 콘텐츠 정리 사이클의 첫 hub 글.
답글 남기기