camelCase, snake_case, kebab-case 차이와 사용 예시

표기법이 여러 개인 이유

프로그래밍 언어는 대부분 식별자에 공백을 허용하지 않습니다. 그래서 두 단어 이상으로 된 이름을 표현하려면 어떤 방식으로든 단어 경계를 표시해야 합니다.

대문자로 구분하는 방식이 camelCase와 PascalCase, 밑줄로 구분하는 방식이 snake_case, 하이픈으로 구분하는 방식이 kebab-case입니다. 기술적으로는 어느 쪽이든 동작하지만, 각 언어 커뮤니티가 오랜 시간에 걸쳐 관례를 만들어 왔기 때문에 그 관례를 따르는 것이 읽기 좋은 코드가 됩니다.

어디에 무엇을 쓰는가

언어와 맥락별로 널리 쓰이는 관례입니다.

• camelCase: JavaScript와 Java의 변수와 함수 이름. userName, getTotalPrice 형태입니다.
• PascalCase: 클래스와 컴포넌트 이름. 대부분의 언어에서 공통이며 React 컴포넌트도 이 방식입니다.
• snake_case: Python과 Ruby의 변수와 함수, 그리고 대부분의 데이터베이스 컬럼명. user_name 형태입니다.
• kebab-case: CSS 클래스, URL 경로, HTML 속성, 파일 이름. 하이픈은 대부분의 언어에서 식별자로 쓸 수 없어 코드 밖에서 주로 사용됩니다.
• CONSTANT_CASE: 상수와 환경 변수. MAX_RETRY_COUNT, DATABASE_URL 형태입니다.

한 프로젝트에서 표기법이 섞일 때

현실적인 프로젝트에서는 여러 표기법이 동시에 존재합니다. 데이터베이스 컬럼은 snake_case인데 JavaScript 코드는 camelCase를 쓰고, 같은 개념이 CSS에서는 kebab-case로 나타나는 식입니다.

중요한 것은 경계를 명확히 하는 것입니다. 어느 계층에서 변환할지 한 곳으로 정해 두면 혼란이 크게 줄어듭니다. 보통은 데이터 접근 계층이나 직렬화 계층에서 한 번 변환하고, 애플리케이션 내부에서는 한 가지 표기법만 사용합니다.

많은 ORM과 직렬화 라이브러리가 이 변환을 자동으로 처리하는 옵션을 제공합니다. 다만 자동 변환은 약어를 다루는 방식에서 예상과 다른 결과를 낼 수 있으므로 실제 출력을 확인해 두는 것이 좋습니다.

약어를 다룰 때의 주의점

ID, URL, HTTP, API 같은 약어는 단어 경계를 판단하기 어려워 도구마다 결과가 갈립니다.

userID를 snake_case로 바꿀 때 user_id가 될 수도 있고 user_i_d가 될 수도 있습니다. HTTPRequest는 http_request가 될 수도, h_t_t_p_request가 될 수도 있습니다.

이런 문제를 피하려면 처음부터 약어를 한 단어처럼 다루는 규칙을 정하는 것이 좋습니다. userId, HttpRequest처럼 첫 글자만 대문자로 쓰는 방식이 널리 쓰이며, Java와 Kotlin의 공식 스타일 가이드도 이 방식을 권장합니다.