대문자와 소문자: 유래와 쓰임
큰 글자와 작은 글자의 구분은 오늘날 당연해 보이지만, 하나의 알파벳에 두 가지 형태를 두는 것은 비교적 늦게 자리 잡은 관습입니다.
라틴어와 그리스어, 키릴 문자 같은 고대 문자 체계는 지금 우리가 대문자로 인식하는 형태만으로 쓰였습니다. 돌과 밀랍, 점토에 새겼기 때문에 곧고 각진 획이 그리기 쉬웠던 것입니다. 파피루스와 양피지가 등장하면서 필경사들은 더 빠르고 둥근 서체를 발전시켰고, 수 세기에 걸쳐 그것이 소문자가 되었습니다.
두 벌 체계가 정착한 것은 8세기 후반 카롤루스 대제의 후원 아래 이루어진 카롤링거 르네상스 때입니다. 제국 전역에서 통용될 읽기 쉬운 서체를 찾던 학자들이 카롤링거 소문자를 만들었고, 이때 처음으로 대문자가 문장의 시작과 고유명사에 배정되었습니다.
영어의 upper case와 lower case라는 말은 인쇄소에서 왔습니다. 15세기 구텐베르크의 활판 인쇄에서 식자공들은 금속 활자를 나무 상자에 보관했는데, 덜 쓰이는 대문자는 손이 닿기 어려운 위쪽 서랍에, 늘 쓰는 소문자는 아래쪽 서랍에 두었습니다. 한국어의 "대문자·소문자"는 크기를 기준으로 삼은 다른 계보의 명명입니다.
영문 표기 방식
문장형(Sentence case)
본문에 쓰는 표준 방식으로, 문장의 첫 글자와 고유명사만 대문자로 씁니다. 긴 글에서 가독성이 가장 높은데, 소문자가 이어지면 위아래로 뻗은 획이 단어마다 다른 윤곽을 만들어 시선이 매끄럽게 흘러가기 때문입니다.
제목형(Title case)
영어권에서 제목과 표제에 쓰는 방식입니다. 첫 단어와 마지막 단어, 그리고 주요 단어를 대문자로 쓰고 관사와 접속사, 짧은 전치사는 소문자로 둡니다. APA, MLA, 시카고 등 스타일 가이드마다 규칙이 조금씩 달라 손으로 맞추면 일관성이 깨지기 쉽습니다. 한국어에는 이 개념이 없습니다.
모두 대문자와 모두 소문자
모두 대문자는 주의를 끌거나 경고를 표시할 때 쓰지만, 글 전체를 그렇게 쓰면 읽기가 눈에 띄게 나빠집니다. 모든 글자가 같은 사각형을 이루면서 단어를 구별해 주던 윤곽이 사라지기 때문입니다. 모두 소문자는 비격식 소통이나 미니멀한 브랜드 표기에 쓰입니다.
프로그래밍에 명명 규칙이 필요한 이유
컴파일러는 코드를 모호함 없이 읽어야 하는데, 공백이 키워드와 연산자와 변수를 가르는 구분자 역할을 합니다. 그래서 변수 이름을 user first name처럼 지을 수 없습니다. 컴파일러는 그것을 세 개의 별개 요소로 보고 문법 오류를 냅니다.
이 제약을 피하면서도 사람이 이름을 읽을 수 있게 하려고, 여러 단어를 하나의 연속된 문자열로 잇는 규칙들이 생겼습니다. 시간이 흐르며 언어마다 고유한 관례가 자리 잡았고, 이제는 표기 방식만 봐도 그것이 변수인지 클래스인지 상수인지 짐작할 수 있습니다.
| 규칙 | 예시 | 주로 쓰는 곳 | 형태 |
|---|---|---|---|
| camelCase | userFirstName | JavaScript, Java, Swift, C++ | 첫 단어는 소문자, 이후 단어는 첫 글자를 대문자로. 구분자 없음. |
| PascalCase | UserFirstName | C#, 파이썬 클래스, React 컴포넌트 | 첫 단어를 포함해 모든 단어의 첫 글자를 대문자로. |
| snake_case | user_first_name | 파이썬, 루비, PostgreSQL, MySQL | 전부 소문자, 밑줄로 구분. |
| kebab-case | user-first-name | HTML, CSS, URL | 전부 소문자, 하이픈으로 구분. |
| CONSTANT_CASE | USER_FIRST_NAME | C, 자바 상수, 환경 변수 | 전부 대문자에 밑줄. 바뀌지 않는 값을 뜻함. |
| dot.case | user.first.name | JSON 경로, YAML 키 | 전부 소문자, 점으로 구분. 중첩 구조를 나타냄. |
변환은 어떻게 이루어지는가
userFirstName을 user_first_name으로 바꾸려면 글자의 대소문자를 바꾸는 것만으로는 부족합니다. 단어가 어디서 끝나는지 알아내야 합니다. 과정은 세 단계입니다.
- 경계 탐지: 공백과 탭, 하이픈과 밑줄, 점과 슬래시 같은 구분자를 찾고, 소문자에서 대문자로 넘어가는 지점도 함께 봅니다. camelCase에서는 그 전환이 새 단어의 시작을 뜻하기 때문입니다.
- 정규화: 찾아낸 경계로 문자열을 쪼개 소문자 단어의 목록으로 만듭니다.
get_USER_Profile은["get", "user", "profile"]이 됩니다. - 재조립: 목표 형식의 규칙을 각 단어에 적용하고 알맞은 구분자로 다시 잇습니다. kebab-case로 가면
get-user-profile, PascalCase로 가면GetUserProfile이 됩니다.
실제로 쓰이는 곳
개발과 데이터베이스
서로 다른 관례를 기대하는 시스템 사이에서 데이터를 옮기는 일은 늘 있습니다. 쿼리는 created_at처럼 snake_case로 컬럼을 돌려주는데 프런트엔드는 createdAt을 기대합니다. 속성 목록을 한 번에 변환하면 API 연동이나 리팩터링 때마다 반복되는 수작업이 사라집니다.
콘텐츠와 검색 최적화
kebab-case로 정리된 URL은 사람에게도 크롤러에게도 읽기 쉽습니다. 영어 콘텐츠를 다룬다면 제목형 변환으로 표제가 스타일 가이드를 벗어나지 않게 맞출 수 있습니다.
데이터 분석
예전 시스템이나 입력 폼에서 온 자료는 대개 뒤죽박죽입니다. 같은 열에 JOHN SMITH, jane doe, mArY jAnE가 섞여 있는 식이죠. 변환기를 한 번 거치면 표기가 통일되어 집계와 시각화가 깔끔해집니다.
디자인과 카피
버튼 문구가 모두 대문자에서 문장형으로 바뀌면, 여러 시안에 걸쳐 텍스트를 다시 타이핑하는 것은 아무것도 만들어 내지 못하는 작업입니다. 한 번에 변환해 두면 그 시간을 다른 데 쓸 수 있습니다.