카멜케이스 스네이크케이스 변환 규칙 총정리

camelCase와 snake_case가 헷갈리는 이유는 표기법 이름이 낯설어서가 아니라, 텍스트가 정확히 어느 지점에서 단어로 잘리고 그 단어들이 무슨 기호로 다시 이어지는지 규칙을 모르기 때문입니다.

이 규칙만 알면 myVariableName이 my_variable_name으로 바뀌는 과정과, 숫자·특수문자가 섞인 텍스트가 예상과 다르게 잘리는 이유까지 전부 설명됩니다.

변수·파일 이름 표기법을 다루는 개발자나, 변환 결과를 눈으로 검증해야 하는 사람이 볼 내용입니다.

요약 ① 단어는 로마자 소문자·숫자 바로 뒤에 대문자가 오는 지점과, 문자·숫자·한글이 아닌 기호가 연속된 지점에서 잘립니다. ② camelCase·PascalCase는 잘린 단어를 기호 없이 이어 붙이고, snake_case·kebab-case·CONSTANT_CASE는 밑줄·하이픈으로 이어 붙입니다. ③ Title Case·문장형은 이 단어 분리 규칙을 쓰지 않아서, 공백 없는 camelCase 텍스트를 그대로 넣으면 단어별로 나뉘지 않습니다.

표기법 변환이 실제로 필요해지는 상황

API 문서나 디자인 스펙에는 "User Profile Image"처럼 사람이 읽기 좋은 이름이 적혀 있는 경우가 많습니다. 이 이름을 그대로 코드에 쓰기는 어렵습니다. 실제 코드에서는 이렇게 나뉩니다.

• JavaScript 변수명: camelCase (예: userProfileImage)
• 데이터베이스 컬럼명: snake_case (예: user_profile_image)
• CSS 커스텀 속성·URL 경로: kebab-case (예: user-profile-image)
• 환경변수: CONSTANT_CASE (예: USER_PROFILE_IMAGE)

문제는 이름에 숫자나 약어가 섞였을 때 생깁니다. getUserID, html5Video처럼 대문자·숫자·소문자가 뒤섞인 텍스트를 손으로 직접 나누다 보면, 어디서 끊어야 하는지 사람마다 다르게 판단하기 쉽습니다.

그 결과 같은 이름이 팀 안에서 getUserId, getUserID, get_user_id로 제각각 표기되는 일이 생깁니다. 표기법마다 단어를 나누고 합치는 규칙이 정확히 정해져 있다는 것을 알면, 이런 표기 흔들림을 규칙으로 검증할 수 있습니다.

도구 없이 직접 단어를 나누고 표기법을 적용하는 방법

표기법 변환은 두 단계로 이뤄집니다. 먼저 텍스트를 단어 단위로 자르고, 그다음 그 단어들을 표기법별 규칙으로 다시 붙입니다. 이 두 단계를 손으로 그대로 따라 하면 도구 없이도 같은 결과를 얻을 수 있습니다.

1단계: 단어 경계를 찾는다

camelCase·PascalCase·snake_case·kebab-case·CONSTANT_CASE 다섯 가지는 단어 경계를 두 가지 규칙으로 찾습니다.

• 규칙 1(대소문자 경계): 로마자 소문자 또는 숫자 바로 뒤에 대문자가 오면 그 사이를 자릅니다. myVariableName은 my / Variable / Name으로, html5Video는 html5 / Video로 나뉩니다.
• 규칙 2(기호 경계): 로마자·숫자·한글이 아닌 문자(공백, 밑줄, 하이픈, 마침표 등)가 한 개든 여러 개든 연속으로 나오면 그 구간 전체를 경계로 보고, 양옆 글자만 단어로 남깁니다. hello___world는 밑줄이 세 개 연달아 있어도 hello / world 두 단어로만 나뉩니다.

반면 Title Case와 문장형은 이 두 규칙 중 규칙 2에 해당하는 것과 비슷하게 공백·기호로 끊긴 덩어리만 하나의 단어로 봅니다. 규칙 1(대소문자 경계)은 적용하지 않습니다.

그래서 공백 없이 이어 쓴 camelCase 텍스트를 그대로 Title Case에 넣으면, getUserID 같은 텍스트가 단어별로 나뉘지 않고 첫 글자만 대문자로 바뀐 하나의 덩어리(Getuserid)가 됩니다.

같은 텍스트를 camelCase로 바꾸면 get / User / ID 세 단어로 정확히 나뉘어 getUserId가 됩니다.

2단계: 나뉜 단어를 표기법별 규칙으로 다시 합친다

camelCase·PascalCase에서 "첫 글자만 대문자로 바꾼다"는 것은 나머지 글자를 전부 소문자로 강제 변환한다는 뜻입니다.

그래서 단어 안에 이미 대문자가 여러 개 있던 약어(ID, URL 등)는 첫 글자만 남고 나머지가 소문자로 바뀝니다. 이 점은 아래 확인 방법으로 이어집니다.

저희 도구로 확인하기.

직접 해보기 →

자주 헷갈리는 변환 결과

같은 입력을 여러 표기법에 넣어보면 규칙만으로는 예상하기 어려운 결과가 나오는 지점이 있습니다. 아래는 실제로 자주 걸리는 경우입니다.

정리

• 변환 방식은 크게 두 그룹으로 나뉩니다. 텍스트 전체를 통째로 다루는 그룹(대문자·소문자·Title Case·문장형)과, 단어로 나눈 뒤 다시 합치는 그룹(camelCase·PascalCase·snake_case·kebab-case·CONSTANT_CASE)입니다.
• 단어로 나누는 그룹은 로마자 소문자·숫자 바로 뒤에 대문자가 오는 지점과, 로마자·숫자·한글이 아닌 기호가 연속된 지점에서 잘립니다.
• camelCase·PascalCase는 각 단어의 첫 글자만 남기고 나머지를 소문자로 바꾸므로, 연속 대문자로 된 약어는 원래 형태를 잃습니다.
• Title Case·문장형은 대소문자 경계를 인식하지 않고 공백·기호만 경계로 삼으므로, 공백 없는 camelCase 텍스트를 넣으면 단어별로 나뉘지 않습니다.
• 한글은 대소문자 구분이 없는 문자라서 어떤 표기법을 선택해도 그대로 남습니다.

📖 현업 개발자들이 겪는 현실적인 케이스 변환 사연과 트러블

사연 1: 데이터베이스 마이그레이션과 프론트엔드 DTO의 불일치

한 백엔드 엔지니어는 데이터베이스 마이그레이션을 진행하며 모든 컬럼명을 데이터베이스 표준인 snake_case로 작성했습니다. user_profile_image와 같이 말이죠. 그러나 프론트엔드의 TypeScript DTO(Data Transfer Object)는 팀의 네이밍 컨벤션에 따라 camelCase(예: userProfileImage)를 사용하도록 엄격하게 설정되어 있었습니다. 문제는 중간에 API 응답을 매핑해주는 Jackson 라이브러리의 프로퍼티 명명 전략(Property Naming Strategy)이나 자동 CamelCase 변환기가 누락되었다는 점이었습니다. 결과적으로 프론트엔드가 받은 JSON 응답 필드와 DTO가 매핑되지 않아, Production 환경 배포 직후 40여 개의 Null Pointer Exception(NPE)이 폭발하며 첫 릴리즈가 롤백되는 대참사가 일어났습니다.

사연 2: 디자인 시스템의 CSS 토큰과 케밥 케이스 혼용

대규모 커머스 서비스의 프론트엔드 팀에서 새로운 디자인 시스템을 구축하며 CSS 커스텀 속성(Custom Properties)을 도입했습니다. CSS의 표준인 kebab-case를 사용하여 디자인 토큰을 정의해야 했으나, 개발자들이 JavaScript에서 사용하던 camelCase 습관을 버리지 못해 userProfileCard와 user-profile-card 두 가지 명명법이 혼용되기 시작했습니다. 이로 인해 동일한 색상과 패딩 값을 가진 CSS 토큰 정의가 중복 생성되었고, 웹팩(Webpack) 빌드 결과물에서 무려 150KB에 달하는 불필요한 번들 블로트(Bundle Bloat)가 발생했습니다.

사연 3: Python 개발자의 Go 언어 이직과 파스칼 케이스

오랜 기간 Python으로 백엔드를 개발하던 시니어 개발자가 최근 높은 동시성 처리를 위해 Go 언어 프로젝트로 이직했습니다. Python의 PEP8 컨벤션에 익숙했던 그는 습관적으로 모든 구조체(Struct) 필드명을 snake_case로 작성했습니다. 그러나 Go 언어에서는 필드명의 첫 글자가 대문자인 PascalCase여야만 외부 패키지로 노출(Export)되며 JSON 등으로 직렬화될 수 있다는 중요한 언어적 특성을 간과했습니다. 그 결과 QA 환경에서 모든 API 응답의 필드가 텅 빈 중괄호 구문({})으로만 직렬화되어 반환되는 황당한 장애를 경험했습니다.

🔬 핵심 기술 메커니즘 — 정규식 경계 인식 알고리즘과 토크나이저

단순해 보이는 케이스 변환 이면에는 복잡한 문자열 처리와 정규 표현식(Regular Expression)의 경계 인식 메커니즘이 숨어 있습니다. 특히 약어를 보존하고 대소문자 전환 지점을 정확히 포착하는 것은 컴퓨터 과학적으로도 꽤나 까다로운 토큰화(Tokenization) 문제입니다.

정규식 전방탐색과 후방탐색 (Lookaround)

일반적인 정규식으로는 연속된 문자열을 자르기 어렵습니다. 따라서 Lookbehind(후방탐색)과 Lookahead(전방탐색) 단언(Assertion)을 결합하여 가상의 분리 경계를 만들어냅니다. 가장 기본적인 카멜 케이스 분할 정규식 패턴은 다음과 같습니다. 정규식: (?<=[a-z0-9])(?=[A-Z]) 이 패턴은 "앞에 소문자나 숫자가 있고, 뒤에 대문자가 오는 그 사이의 공간"을 매칭합니다. 따라서 myVariableName은 my, Variable, Name으로 분리됩니다. 그러나 약어가 연속된 경우 문제가 발생합니다. HTTPServer 같은 단어는 위 정규식만으로는 HTTP, Server로 나뉘지 않습니다. 이를 위해 두 번째 규칙이 추가됩니다. 정규식: (?<=[A-Z])(?=[A-Z][a-z]) 이 패턴은 "앞에 대문자가 있고, 뒤에 대문자+소문자 조합이 오는 공간"을 매칭하여 HTTP와 Server의 경계를 정확히 찾아냅니다.

문자열 토큰화(Tokenization) 파이프라인

케이스 변환기는 일반적으로 4단계 파이프라인을 거칩니다.

1. 정규화(Normalization): 입력된 문자열의 양쪽 공백을 제거하고, 연속된 특수문자나 구분자를 하나의 공백으로 치환합니다.
2. 토큰 분리(Split into tokens): 위에서 언급한 정규식 Lookaround 기법을 사용해 문자열을 독립적인 단어(Token)들의 배열로 쪼갭니다.
3. 토큰별 대소문자 변환(Casing transformation per token): 타겟 표기법에 맞춰 각 토큰의 대소문자를 강제로 변환합니다. PascalCase라면 모든 토큰의 첫 글자를 대문자로, 나머지를 소문자로 바꿉니다.
4. 구분자 병합(Join with delimiter): 변환된 토큰들을 타겟 구분자(빈 문자열, 밑줄 _, 하이픈 -)로 다시 연결합니다.

약어 보존의 난제 (Acronym Preservation Challenge)

변환기 개발자들이 가장 골치 아파하는 부분은 XMLHTTPRequest와 같은 약어의 처리입니다. 이를 스네이크 케이스로 변환할 때, 어떤 변환기는 xml_http_request로 똑똑하게 분리하지만, 정규식이 정교하지 못한 단순 변환기는 xml_httprequest로 합쳐버리거나 심지어 x_m_l_h_t_t_p_request처럼 낱글자로 산산조각 내버리기도 합니다. 언어별 코딩 스펙과 팀 컨벤션에 따라 어떤 방식이 맞는지 합의가 선행되어야 합니다.

언어별 공식 네이밍 컨벤션의 차이

각 프로그래밍 언어 생태계는 고유한 공식 스타일 가이드를 가집니다.

• Python (PEP 8): 함수명과 변수명은 snake_case, 클래스명은 PascalCase.
• Java (Google Java Style Guide): 메서드와 변수는 camelCase, 상수는 CONSTANT_CASE.
• Go (Effective Go): 패키지 외부로 노출(Export)할 때는 PascalCase(MixedCaps), 내부는 camelCase.
• Rust (RFC 430): 변수와 함수는 snake_case, 타입과 트레잇은 PascalCase.
• TypeScript / JavaScript: 변수와 함수는 camelCase, 클래스와 인터페이스는 PascalCase, 파일명은 종종 kebab-case.

📊 7대 명명 규칙(Casing Conventions) 비교 및 분석 테이블

⚠️ 케이스 변환 시 자주 저지르는 5가지 치명적 실수

개발 과정에서 표기법을 수동으로 변환하거나 잘못된 스크립트를 사용할 때 흔히 발생하는 5가지 문제입니다.

1. 단순 정규식 사용으로 인한 약어 경계 붕괴 (Losing Acronym Boundaries):

getURL을 스네이크 케이스로 바꿀 때, 단순하게 대문자 앞에서 밑줄을 긋는 정규식을 사용하면 get_u_r_l처럼 의미 없는 낱글자로 조각나는 치명적인 문제가 발생합니다. 정교한 Lookaround 정규식 또는 전용 도구의 사용이 필수적입니다.

2. 문자와 숫자 혼합 시 분리 오류 (Mixing Numbers with Letters):

v2Api라는 문자열을 변환할 때, 변환기에 따라 v_2_api로 자르거나 v2_api로 자르는 등 동작이 파편화됩니다. 숫자를 독립된 단어로 취급할지, 아니면 앞선 문자열의 연속으로 볼지 팀 내 명확한 규칙 수립이 필요합니다.

3. 비 ASCII 및 한국어 문자 포함 시 정규식 오작동: 한글이나 이모지 등 유니코드 문자가 섞인 식별자(예: get유저Info)의 경우, 로마자 알파벳만을 기준으로 작성된 낡은 정규식 변환기에서는 경계 인식이 실패하여 get유저info처럼 엉뚱한 결과가 나오거나 아예 에러를 내뿜습니다.

4. 대규모 팀 내 파편화된 네이밍 컨벤션 방치: 같은 프로젝트 내에서 누구는 user_id, 누구는 userId, 심지어 user_ID로 섞어 쓰는 경우입니다. 이는 코드의 가독성을 심각하게 훼손하며, 검색 기능(grep)을 통한 전역 리팩토링이나 텍스트 대치를 불가능하게 만듭니다.

5. JSON 직렬화(Serialization) 시 대소문자 변환 규칙 누락: 백엔드(스네이크 케이스)와 프론트엔드(카멜 케이스)가 통신할 때, 중간 API 게이트웨이나 DTO 시리얼라이저(예: Jackson, GSON, class-transformer)에서 필드명 변환 옵션을 켜지 않으면 클라이언트는 undefined 값을 렌더링하게 됩니다.

💡 레거시 코드를 정화하는 5단계 클린 네이밍 리팩토링 워크플로우

1. 팀 스타일 가이드 확립 및 도구화 (.editorconfig / ESLint): 구두로 정하는 컨벤션은 무의미합니다. 프로젝트 루트에 .editorconfig와 .eslintrc(또는 .prettierrc)를 세팅하여 모든 팀원의 IDE에서 강제적으로 표기법을 통제할 수 있도록 시스템을 구축하세요.
2. 현재 식별자 일관성 감사 (Audit Current Identifier Consistency): 정적 분석 도구(SonarQube 등)를 돌려 베이스라인 코드를 스캔합니다. 어떤 모듈에서 네이밍 규칙 위반이 가장 심각한지 파악하고, 점진적인 리팩토링 계획을 세웁니다.
3. 자동화된 직렬화 변환 미들웨어 구성: Spring Boot, NestJS 등의 프레임워크 단에서 들어오고 나가는 JSON 페이로드의 키 값을 자동으로 변환해주는 미들웨어나 데코레이터(PropertyNamingStrategy)를 전역으로 활성화합니다.
4. 전용 케이스 변환 도구를 통한 일괄 리네이밍 (Batch Renames): IDE의 Refactor - Rename 기능이나, 본 페이지 상단의 케이스 변환기 도구를 적극 활용하여 수십 개의 변수명을 한 번에 안전하게 변환합니다. 수작업은 오타를 유발합니다.
5. CI 파이프라인에 강력한 린트 체크 연동 (Run CI Lint Checks): GitHub Actions 등의 CI/CD 과정에 린트(Lint) 검증 스텝을 필수로 삽입하여, 규칙에 맞지 않는 식별자가 포함된 PR(Pull Request)은 자동으로 머지(Merge)가 차단되도록 방어막을 칩니다.

🔍 코드의 품격을 높이는 7가지 전문가 네이밍 및 표기 팁

1. 개인의 취향보다 언어와 프레임워크의 관용구(Idiom)를 절대적으로 따르세요. Python에서 카멜 케이스를 쓰거나 Java에서 스네이크 케이스를 쓰면 동료들의 극심한 인지 부하를 유발합니다.
2. 연속된 대문자 약어 표기법을 명확히 합의하세요. HTTPRequest로 할 것인지 HttpRequest로 할 것인지, userID인지 userId인지 팀의 규칙을 명문화해야 합니다. 최신 트렌드는 일반 단어처럼 첫 글자만 대문자로 쓰는 HttpRequest 방식을 선호합니다.
3. 자동 직렬화 데코레이터를 적극 활용하세요. Java의 @JsonProperty("user_id"), TS의 @Expose({ name: "user_id" }), Go의 json:"user_id" 태그를 사용하면 코드 내부의 카멜 케이스를 유지하면서도 DB나 API의 스네이크 케이스와 완벽하게 매핑할 수 있습니다.
4. URL 경로와 REST API 엔드포인트는 무조건 kebab-case를 사용하세요. /get_user_profile(X), /getUserProfile(X)보다 /get-user-profile(O) 형식이 검색엔진 최적화(SEO)와 가독성 측면에서 글로벌 표준입니다.
5. 상수(CONSTANT_CASE)는 진정한 불변(Immutable) 값에만 부여하세요. 런타임에 값이 변경될 수 있는 일반 변수를 대문자 스네이크 케이스로 선언하는 것은 상수의 시맨틱(의미론적) 목적을 위반하는 안티 패턴입니다.
6. Lookaround 정규식의 원리를 이해하고 커스텀 스크립트를 작성해보세요. 일회성 변환이 아니라면 앞서 설명한 (?<=[a-z0-9])(?=[A-Z]) 패턴을 활용한 정규식 치환 매크로를 에디터에 등록해두면 생산성이 폭발적으로 상승합니다.
7. 이 케이스 변환기 도구를 브라우저 북마크에 저장하세요. 급하게 DB 쿼리문을 작성하거나 DTO 인터페이스를 타이핑해야 할 때, 직접 손으로 바꾸는 시간을 획기적으로 줄여줄 최고의 유틸리티가 될 것입니다.

🎯 완벽한 결정을 위한 표기법 선택 트리 (Decision Tree)

"이 변수명은 도대체 어떤 케이스로 지어야 할까?" 고민될 때 다음 의사결정 트리를 따라가면 1초 만에 답이 나옵니다.

1. 이것은 설정 파일(.env), 불변 상수, 혹은 글로벌 환경 변수인가요?
   • YES ➔ CONSTANT_CASE (예: MAX_RETRY_COUNT)
   • NO ➔ 다음으로 이동
2. 이것은 웹 URL 엔드포인트, CSS 클래스 명, 혹은 디렉토리명/파일명인가요?
   • YES ➔ kebab-case (예: user-profile-card)
   • NO ➔ 다음으로 이동
3. 이것은 관계형 데이터베이스(RDBMS)의 테이블명이나 컬럼명인가요?
   • YES ➔ snake_case (예: created_at)
   • NO ➔ 다음으로 이동
4. 사용 중인 언어가 Python, Rust, Ruby, 혹은 PHP(부분적)인가요?
   • YES ➔ snake_case (예: fetch_user_data)
   • NO (Java, JS, TS, C#, Go 등) ➔ 다음으로 이동
5. 이것은 클래스, 인터페이스, 타입, 혹은 Go 언어의 Export 대상인가요?
   • YES ➔ PascalCase (예: UserDataResponse)
   • NO (일반 변수, 함수, 메서드, 파라미터) ➔ camelCase (예: fetchUserData)

📑 전문가를 위한 핵심 기술 용어 치트시트 (Terminology)

• camelCase (카멜 케이스): 단어를 공백 없이 연결하되 첫 단어는 소문자, 이어지는 단어의 첫 글자는 대문자로 표기. 낙타의 혹을 닮아 붙여진 이름.
• PascalCase (파스칼 케이스): 모든 단어의 첫 글자를 대문자로 시작하는 표기법. UpperCamelCase라고도 불림.
• snake_case (스네이크 케이스): 뱀처럼 길게 이어진다는 의미로, 띄어쓰기 공백을 밑줄(Under-score, _)로 대체하는 표기법.
• kebab-case (케밥 케이스): 꼬치에 꿰어진 케밥 모양처럼, 단어 사이를 하이픈(Dash, -)으로 잇는 표기법. URL과 CSS에서 주로 사용됨.
• CONSTANT_CASE (상수 케이스): 모든 문자를 대문자로 작성하고 단어 사이를 밑줄로 연결하는 방식(UPPER_SNAKE_CASE). 상수 및 환경변수 표현에 국한됨.
• Lookaround 정규식 (Regex Lookaround): 정규표현식에서 결과에 포함되지 않으면서 조건을 검사하는 강력한 탐색 기능. 전방탐색(?=...)과 후방탐색(?<=...)이 있음.
• DTO 직렬화 (Serialization): 메모리 상의 객체 데이터(DTO)를 네트워크 전송이나 DB 저장을 위해 JSON 등의 포맷으로 변환하는 과정. 이때 빈번한 케이스 변환이 발생함.

자주 묻는 질문

Q1. IOStream과 같이 대문자 약어가 연속되는 식별자는 어떻게 변환하는 가장 안전한가요?

연속된 대문자 약어는 전통적인 camelCase 변환기에서 가장 취약한 부분입니다. IOStream을 카멜 케이스화 할 때, 어떤 시스템은 iOStream으로 만들고, 어떤 곳은 ioStream으로 만듭니다. 가장 안전하고 현대적인 접근 방식은 약어도 하나의 단어처럼 취급하여 IoStream(파스칼 케이스) 또는 ioStream(카멜 케이스)으로 선언하는 것입니다. 이렇게 하면 이후 snake_case로 자동 변환될 때 io_stream으로 깔끔하게 분리되어 상호 운용성이 극대화됩니다.

Q2. 식별자에 숫자가 포함될 경우 단어 분리는 어떤 규칙을 따르게 되나요?

숫자의 처리는 도구와 프레임워크마다 미묘하게 다릅니다. 일반적으로 숫자도 로마자 소문자와 동등한 지위를 가집니다. 따라서 user2Name은 user2 / Name으로 분리되어 user2_name이 됩니다. 하지만 앞뒤가 모두 문자인 경우(예: v2Api) 숫자를 독립된 단어로 취급하여 v_2_api로 자르는 엄격한 린트 룰도 존재합니다. 예측 불가능성을 줄이려면 애초에 식별자 중간에 숫자를 넣는 네이밍을 지양하고, 숫자는 식별자 끝에 배치하는 것이 가장 권장됩니다.

Q3. 케이스 변환기는 한글이나 CJK(한중일) 문자를 어떻게 처리하나요?

한글 자체는 대문자와 소문자의 개념이 존재하지 않으므로 변환의 대상이 되지 않고 원형이 그대로 보존됩니다. 문제는 단어의 경계 인식입니다. 현대적이고 유니코드를 완벽히 지원하는 정규식 기반 변환기(마치 본 페이지의 도구처럼)는 영문자와 한글 사이의 경계를 영문자와 영문자 사이처럼 자연스럽게 인식합니다. 하지만 과거의 낡은 정규식만을 사용하는 스크립트들은 한글을 공백이나 특수문자처럼 취급해버려 변수명이 훼손될 위험이 있습니다. 한글 변수명을 사용할 때는 반드시 유니코드(UTF-8) 친화적인 변환 도구를 사용해야 합니다.