🔠 카멜케이스 스네이크케이스 등 표기법 정리

같은 식별자라도 언어나 컨텍스트에 따라 camelCase, PascalCase, snake_case처럼 표기 방식이 달라집니다. 이 글에서는 코드에서 자주 쓰이는 네이밍 컨벤션 각각이 무엇이고 어떤 언어·상황에서 관례로 쓰이는지, 그리고 표기법을 일관되게 지켜야 하는 이유를 정리합니다.

코드에서 자주 쓰이는 표기법들

같은 개념인 'user login count'를 예로 표기법별 차이를 보면 다음과 같습니다.

• camelCase: userLoginCount — 첫 단어는 소문자로 시작하고, 이후 단어의 첫 글자만 대문자로 붙여 씁니다.
• PascalCase: UserLoginCount — camelCase와 규칙은 같지만 첫 단어도 대문자로 시작합니다.
• snake_case: user_login_count — 모든 단어를 소문자로 쓰고 밑줄(_)로 구분합니다.
• kebab-case: user-login-count — snake_case와 비슷하지만 밑줄 대신 하이픈(-)으로 구분합니다.
• CONSTANT_CASE: USER_LOGIN_COUNT — snake_case와 같은 구분자를 쓰되 모든 글자를 대문자로 씁니다.

이름은 다르지만 목적은 같습니다. 여러 단어로 이뤄진 개념을 하나의 유효한 식별자(공백을 쓸 수 없는 변수명·파일명·URL 등)로 표현하면서도 단어 경계를 눈으로 구분할 수 있게 하는 것입니다.

언어·컨텍스트별 관례

각 표기법은 특정 언어나 문맥에서 관례로 굳어져 있습니다. JavaScript·Java·C#에서는 변수명과 함수명에 camelCase(예: getUserName)를, 클래스명에는 PascalCase(예: UserAccount)를 씁니다. Python과 Ruby는 반대로 변수·함수명에 snake_case(예: get_user_name)를 쓰고, 클래스명은 이 언어들도 PascalCase를 따릅니다. kebab-case는 CSS 클래스명(.user-card)이나 HTML 속성(data-user-id), URL 경로(/guides/case-styles/)에서 표준처럼 쓰이는데, 이는 CSS와 URL 문법에서 밑줄보다 하이픈이 더 자연스럽게 취급되기 때문입니다. 마지막으로 CONSTANT_CASE는 언어를 가리지 않고 '변경되지 않는 상수'라는 의미를 표기 자체로 드러내고 싶을 때(예: MAX_RETRY_COUNT, API_BASE_URL) 관례적으로 쓰입니다.

왜 일관성이 중요할까

표기법 자체에는 우열이 없지만, 한 프로젝트 안에서 표기법이 뒤섞이면 문제가 됩니다. 같은 종류의 값인데 어떤 곳은 userId, 어떤 곳은 user_id로 쓰여 있으면 코드를 읽는 사람이 매번 '이건 어느 쪽 표기였더라'를 신경 써야 하고, 자동완성이나 검색으로 식별자를 찾기도 어려워집니다. ESLint, Prettier 같은 린터·포매터 도구는 대개 프로젝트 전체에 하나의 네이밍 컨벤션을 강제하는 규칙을 제공하는데, 이는 표기법 통일이 가독성뿐 아니라 코드 리뷰 시간과 실수 가능성까지 줄여주기 때문입니다. 특히 여러 언어가 얽히는 프로젝트(예: Python 백엔드의 snake_case 필드명을 JavaScript 프론트엔드의 camelCase로 매핑하는 API 응답)에서는 어느 지점에서 표기법이 바뀌는지 명확히 인지하고 있어야 버그를 줄일 수 있습니다. 표기법을 통일할 때 특히 자주 필요한 작업이 대문자·소문자 변환입니다. 예를 들어 이미 밑줄로 단어가 구분된 user_login_count를 CONSTANT_CASE로 바꾸려면 전체를 대문자로만 바꾸면 되는데, 이런 대소문자 변환은 텍스트 도구로 바로 처리할 수 있습니다.

다른 가이드