camelCase? snake_case? — 개발 표기법 한 번에 정리

가이드약 4분2026.06.11

코드에서 띄어쓰기는 쓸 수 없습니다. 그래서 개발자들은 userName, user_name, user-name처럼 단어를 잇는 자기들만의 방법을 만들었고, 각각에 동물 이름 같은 별명이 붙었습니다. 네 가지 표기법과 "언제 뭘 쓰는지"를 정리합니다.

이 글의 순서

4가지 표기법과 이름의 유래
언어·상황별 관례
왜 통일이 중요한가
한 번에 바꾸는 법

4가지 표기법과 이름의 유래

camelCase — userName · 중간의 대문자가 낙타 혹처럼 솟아서 "낙타 표기법".
PascalCase — UserName · 모든 단어가 대문자로 시작. 파스칼 언어의 관례에서 유래.
snake_case — user_name · 밑줄이 땅을 기는 뱀 같다고 "뱀 표기법". 전부 대문자면 USER_NAME(상수용).
kebab-case — user-name · 하이픈에 단어가 꼬치처럼 꿰여서 "케밥 표기법".

언어·상황별 관례

JavaScript·Java·Kotlin: 변수·함수 camelCase, 클래스 PascalCase
Python·Ruby·Rust: 변수·함수 snake_case, 클래스 PascalCase
상수(대부분 언어): SCREAMING_SNAKE_CASE — MAX_RETRY
URL 경로·CSS 클래스·파일명: kebab-case — /user-profile/, .btn-primary
DB 컬럼·API 응답: snake_case가 흔함 — 그래서 프런트와 백엔드 사이에서 표기 변환이 늘 생깁니다.

왜 통일이 중요한가

이름이 곧 정보: 관례가 지켜진 코드에서는 UserService(클래스)·getUser(함수)·MAX_SIZE(상수)를 이름 모양만 보고 구분할 수 있습니다. 표기법은 멋이 아니라 읽는 속도입니다.

한 프로젝트에 userName과 user_name이 섞이면, 같은 것을 두 곳에서 다른 이름으로 찾는 버그의 온상이 됩니다.
팀 컨벤션 문서에 한 줄로 정해 두고, 코드 리뷰에서 지키는 것이 가장 싸게 먹히는 품질 투자입니다.

한 번에 바꾸는 법

바꿀 식별자들(예: API의 snake_case 필드 목록)을 변환기에 붙여 넣습니다.
목표 표기(camelCase·PascalCase·kebab-case 등)를 고르면 일괄 변환됩니다.
결과를 복사해 코드·문서에 사용합니다 — 손으로 옮길 때 생기는 오타가 사라집니다.

대소문자·표기 변환camel·snake·kebab 일괄 변환 변환하기 →

자주 묻는 질문

Q. camelCase와 PascalCase는 뭐가 다른가요?

첫 글자의 대소문자만 다릅니다. camelCase는 첫 단어를 소문자로 시작하고 다음 단어부터 대문자로 잇는 방식(userName)이고, PascalCase는 모든 단어를 대문자로 시작합니다(UserName). 많은 언어에서 변수·함수는 camelCase, 클래스·타입은 PascalCase로 구분하는 것이 관례라, 이름만 봐도 그것이 클래스인지 변수인지 알 수 있게 됩니다.

Q. 언어마다 쓰는 표기법이 정해져 있나요?

강제는 아니지만 관례가 뚜렷합니다. JavaScript·Java는 변수·함수에 camelCase, Python·Ruby는 snake_case, 클래스는 대부분의 언어에서 PascalCase, 상수는 SCREAMING_SNAKE_CASE(전부 대문자+밑줄)를 씁니다. URL 경로와 CSS 클래스는 kebab-case가 일반적입니다. 핵심은 그 언어 생태계의 관례를 따르고 한 프로젝트 안에서 섞지 않는 것입니다.

Q. 다른 표기법으로 된 이름들을 한 번에 바꿀 수 있나요?

변환 도구를 쓰면 됩니다. 대소문자·표기 변환기에 user_name 같은 식별자 목록을 붙여 넣으면 camelCase·PascalCase·kebab-case 등으로 일괄 변환됩니다. API의 snake_case 응답 필드를 프런트엔드의 camelCase 변수명으로 옮겨 적을 때, DB 컬럼명을 코드 네이밍으로 바꿀 때 한 줄씩 고치는 것보다 훨씬 빠르고 오타가 없습니다.