본문으로 건너뛰기
LeedyBox
후원

케이스 스타일과 이름 규칙 알아보기

코드, 파일, URL, 제목에 쓰는 이름은 언어와 형식마다 다른 규칙을 따릅니다. 이 가이드는 흔히 쓰는 케이스 스타일과 각각이 어디에서 쓰이는지, 그리고 약어, 숫자, 제목, 영어 밖의 문자처럼 헷갈리기 쉬운 부분을 정리합니다.

흔히 쓰는 스타일

스타일예시만드는 방법
camelCaseorderTotal첫 단어는 소문자, 이후 단어는 첫 글자를 대문자로, 구분자 없음
PascalCaseOrderTotal모든 단어의 첫 글자를 대문자로, 구분자 없음
snake_caseorder_total소문자, 단어를 _로 연결
CONSTANT_CASEORDER_TOTAL대문자, 단어를 _로 연결
kebab-caseorder-total소문자, 단어를 -로 연결
dot.caseorder.total소문자, 단어를 .으로 연결
Title CaseOrder Total단어를 공백으로 나누고 각 단어의 첫 글자를 대문자로
Sentence caseOrder total첫 단어만 첫 글자를 대문자로

camelCase는 lower camel case, PascalCase는 upper camel case라고도 부릅니다. CONSTANT_CASE는 screaming snake case라고도 합니다.

언어와 형식별로 기대하는 스타일

대부분의 생태계는 오래전에 규칙을 정했으며, 이를 따르면 그 생태계에 익숙한 사람 누구나 코드를 읽기 쉬워집니다.

위치일반적인 규칙
JavaScript, TypeScript, Java변수와 함수는 camelCase, 클래스는 PascalCase, 고정 상수는 CONSTANT_CASE
Python (PEP 8)함수와 변수는 snake_case, 클래스는 PascalCase, 상수는 CONSTANT_CASE
C#타입, 메서드, 공개 멤버는 PascalCase, 지역 변수와 매개변수는 camelCase
GoPascalCase는 패키지 밖으로 공개하고, camelCase는 비공개로 유지
Ruby, Rust메서드와 변수는 snake_case, 타입은 PascalCase
CSS와 HTML속성, 클래스 이름, data- 속성은 kebab-case
URLkebab-case. Google은 단어 사이에 밑줄보다 하이픈을 권장
SQL 테이블과 열snake_case. 많은 데이터베이스가 따옴표 없는 이름을 한쪽 대소문자로 통일하기 때문
환경 변수DATABASE_URL 같은 CONSTANT_CASE
설정 키server.port처럼 중첩된 설정은 dot.case
JSON API정해진 규칙은 없음. camelCase를 쓰는 곳이 많고 snake_case를 쓰는 곳도 있으니 사용하는 API를 따름

대부분의 프로그래밍 언어에서는 하이픈이 빼기 기호로 읽히기 때문에 변수 이름에 kebab-case를 쓸 수 없습니다. order-total은 order 빼기 total을 뜻합니다.

약어와 숫자

규칙이 가장 많이 엇갈리는 곳이 약어입니다. 한쪽은 약어를 대문자로 유지하고(userID, parseHTML), 다른 쪽은 일반 단어처럼 다룹니다(userId, parseHtml). Google의 Java와 JavaScript 스타일 가이드는 두 번째 방식을 따르며, 약어가 이어질 때 단어 경계가 분명해집니다. XmlHttpRequest가 XMLHTTPRequest보다 나누기 쉽습니다. Microsoft의 .NET 지침은 두 글자 약어는 대문자로 쓰고(IOStream), 더 긴 약어는 첫 글자만 대문자로 씁니다(HtmlButton). 브라우저 API인 XMLHttpRequest는 두 방식이 섞여 있어 나쁜 예로 자주 인용됩니다.

숫자에는 대소문자가 없으므로 변환기는 utf8Decoder가 "utf8 decoder"인지 "utf 8 decoder"인지 알 수 없습니다. 변환기는 보통 숫자를 앞 단어에 붙입니다. 표기를 하나로 정해 모든 곳에 똑같이 쓰세요.

제목의 Title Case와 Sentence case

영어 제목에서 스타일 가이드마다 단어를 대문자로 쓰는 방식이 다릅니다. AP와 Chicago 스타일은 짧은 관사, 접속사, 전치사가 처음이나 끝에 오지 않으면 소문자로 두며("The Lord of the Rings"), 정확한 목록은 서로 다릅니다. Microsoft와 Google의 개발자 문서 가이드를 비롯한 많은 인터페이스·문서 가이드는 대신 Sentence case("Change your password")를 쓰는데, 일관되게 적용하기 쉽고 덜 딱딱하게 읽힙니다.

LeedyBox 변환기의 Title Case는 모든 단어의 첫 글자를 대문자로 바꿉니다. 라벨이나 변수 같은 이름에는 맞지만 신문 제목 스타일에는 맞지 않으니, 변환 뒤 짧은 단어를 직접 소문자로 고치세요.

스타일을 바꾸면 정보가 사라집니다

모든 변환은 먼저 대문자와 구분자를 단서로 이름을 단어로 나눈 뒤, 새 스타일로 단어를 다시 잇습니다. 목표 스타일이 표현하지 못하는 것은 사라집니다. parseHTML은 parse_html이 되고, 다시 바꾸면 parseHtml이 됩니다. 문장 부호도 빠지므로 "don't"는 두 단어가 됩니다.

그러니 한 가지 스타일을 기준으로 삼으세요. 데이터베이스는 snake_case, 코드는 camelCase를 쓴다면 이름을 두 형태로 저장하지 말고, 경계에서 항상 같은 방향으로 변환하세요.

API 경계에서 키 이름 바꾸기

camelCase를 쓰는 프런트엔드가 snake_case를 쓰는 백엔드와 통신할 때, 대부분의 직렬화 라이브러리는 이름을 자동으로 대응시킬 수 있으므로 데이터를 손으로 바꿀 일이 없습니다. 테스트 데이터나 샘플 응답처럼 JSON 문서를 한 번 변환하는 것은 다른 작업이며, 케이스 변환기의 "JSON 키" 모드는 값은 건드리지 않고 이 작업을 해 줍니다.

충돌에 주의하세요. user_name과 userName은 어느 스타일로 바꿔도 같은 키가 되어 하나가 다른 하나를 덮어씁니다. _id나 $ref처럼 기호로 시작하는 키는 특정 데이터베이스나 스키마에서 의미를 갖는 경우가 많으니, 이름을 바꿔도 되는지 먼저 확인하세요.

영어 밖의 대문자와 소문자

대소문자 규칙은 언어마다 같지 않습니다. 독일어 ß는 대문자로 바꾸면 SS가 되어 단어가 길어집니다. 터키어에는 점 있는 i와 점 없는 ı가 있어 대문자 짝이 i → İ, ı → I인데, 대부분의 프로그래밍 언어가 쓰는 기본 규칙은 i를 I로 바꿉니다. JavaScript의 toUpperCase()는 기본 규칙을, toLocaleUpperCase('tr')는 터키어 규칙을 적용합니다. 한국어, 중국어, 일본어에는 대소문자가 아예 없으므로 단어 사이의 구분자만 바뀝니다.

파일 이름에서도 대소문자가 문제될 수 있습니다. Windows와 기본 설정의 macOS는 Readme.md와 README.md를 같은 파일로 보지만, Linux는 서로 다른 두 파일로 봅니다. 그래서 대소문자만 바꾼 이름 변경이 한 시스템에서는 드러나지 않다가 다른 시스템에서 링크나 import를 깨뜨릴 수 있습니다.

자주 묻는 질문

camelCase와 snake_case 중 무엇이 더 좋은가요?

어느 쪽이 일반적으로 더 좋지는 않습니다. 작업하는 언어, 프레임워크, API의 규칙을 따르세요. 한 코드베이스 안에서 일관성을 지키는 것이 무엇을 고르느냐보다 중요합니다.

URL에는 하이픈과 밑줄 중 무엇을 써야 하나요?

하이픈입니다. Google의 URL 지침은 단어 사이에 하이픈을 권장하며, /case-converter/ 같은 kebab-case 슬러그가 웹에서 흔히 쓰입니다.

파일 이름의 대소문자만 바꿨는데 Git이 알아차리지 못하는 이유는 무엇인가요?

대소문자를 구분하지 않는 파일 시스템에서 Git은 옛 이름과 새 이름을 같은 파일로 다루는 경우가 많습니다. 대소문자를 구분하는 시스템에도 변경이 기록되도록, 예를 들어 임시 이름을 거쳐 git mv로 이름을 바꾸세요.

iPhone이나 eBay 같은 브랜드 이름은 camelCase로 어떻게 써야 하나요?

변환기는 대문자에서 단어를 나누므로 이런 이름은 따로 떨어진 단어로 나옵니다. 코드에서는 브랜드를 한 단어로 다루는 편이 보통 더 분명하며(iphoneModel), 공식 표기는 사람에게 보여 주는 텍스트에서만 쓰세요.