카멜케이스 스네이크케이스 변환 완벽 가이드 - 개발자가 알아야 할 표기법 변환법
camelCase, snake_case, PascalCase의 차이부터 자동 변환 방법, 변환 시 자주 하는 실수까지 한 번에 정리했습니다. 프론트엔드와 백엔드 데이터 연동이 편해집니다.
프론트엔드에서는 userName으로 쓰던 변수가, 백엔드 API 응답에서는 user_name으로 내려옵니다. 데이터베이스 컬럼은 또 USER_NAME이고요. 같은 데이터인데 표기법이 제각각이라 변환 코드를 짜다가 시간을 다 보낸 경험, 개발자라면 한 번쯤 있으실 겁니다.
카멜케이스 스네이크케이스 변환은 단순해 보이지만, 약어 처리나 연속 대문자 같은 예외 상황에서 의외로 자주 꼬입니다. 이 글에서 표기법별 차이와 정확한 변환 규칙, 그리고 실수를 줄이는 방법을 정리했습니다.
표기법 변환이 왜 필요할까
표기법(naming convention)은 변수나 함수, 데이터 키에 이름을 붙이는 규칙입니다. 문제는 언어와 플랫폼마다 권장하는 규칙이 다르다는 점입니다.
예를 들어 JavaScript와 Java는 카멜케이스를, Python과 PostgreSQL은 스네이크케이스를, C# 클래스명은 파스칼케이스를 주로 씁니다. 그래서 서로 다른 시스템이 데이터를 주고받을 때 변환이 거의 필수가 됩니다.
표기법 변환을 자동화하지 않으면, 키 하나하나를 손으로 매핑하다가 오타와 누락이 쌓입니다. 변환 규칙을 한 곳에서 관리하는 것이 핵심입니다.
특히 REST API 응답을 다룰 때 자주 마주칩니다. 서버가 스네이크케이스로 JSON을 내려주면, 프론트엔드는 이걸 카멜케이스로 바꿔야 코드 컨벤션이 깨지지 않습니다.
네이밍 표기법 4가지 정리
변환을 제대로 하려면 먼저 표기법 종류를 명확히 구분해야 합니다. 가장 많이 쓰이는 4가지는 다음과 같습니다.
| 표기법 | 예시 | 특징 | 주요 사용처 |
|---|---|---|---|
| camelCase (카멜) | userName | 첫 단어는 소문자, 이후 단어 첫 글자 대문자 | JavaScript, Java 변수 |
| snake_case (스네이크) | user_name | 모두 소문자, 단어 사이 언더스코어 | Python, DB 컬럼 |
| PascalCase (파스칼) | UserName | 모든 단어 첫 글자 대문자 | 클래스명, 컴포넌트명 |
| kebab-case (케밥) | user-name | 모두 소문자, 단어 사이 하이픈 | URL, CSS 클래스 |
이름이 낙타 등(camel)처럼 중간이 볼록해서 카멜케이스, 뱀(snake)처럼 길게 이어져서 스네이크케이스라고 부릅니다. 직관적인 작명이라 한 번 들으면 잘 잊히지 않습니다.
카멜케이스 스네이크케이스 변환 방법
두 표기법 사이의 변환 규칙 자체는 단순합니다.
카멜케이스에서 스네이크케이스로
- 대문자를 찾아 그 앞에 언더스코어(_)를 넣습니다
- 모든 대문자를 소문자로 바꿉니다
- 예: createdAt 에서 created_at 으로
스네이크케이스에서 카멜케이스로
- 언더스코어를 제거합니다
- 언더스코어 바로 뒤 글자를 대문자로 올립니다
- 예: profile_image_url 에서 profileImageUrl 로
정규식으로도 간단히 처리됩니다. JavaScript에서 카멜을 스네이크로 바꾸려면 str.replace(/[A-Z]/g, m => '_' + m.toLowerCase()) 한 줄이면 충분합니다.
다만 객체 키를 통째로 변환할 때는 직접 짜기보다 검증된 도구를 쓰는 편이 안전합니다. API 응답 JSON을 정리하고 구조를 확인할 때는 JSON 포매터로 먼저 보기 좋게 정렬한 뒤, 어떤 키를 변환할지 파악하면 실수가 줄어듭니다.
변환할 때 자주 하는 실수
규칙은 단순하지만, 실무 데이터에는 예외가 많습니다. 자동 변환이 깨지는 대표적인 경우를 정리했습니다.
연속된 대문자(약어) 처리
userID를 스네이크로 바꾸면 user_i_d가 되어버리는 경우가 흔합니다. 의도한 결과는 user_id죠. ID, URL, API 같은 약어는 별도 규칙으로 묶어줘야 합니다.
숫자가 섞인 경우
address1이나 md5Hash처럼 숫자가 붙으면 변환 위치가 애매해집니다. 숫자 앞뒤를 어떻게 끊을지 팀 내 규칙을 미리 정해두는 것이 좋습니다.
타임스탬프 같은 특수 값 변환
키 이름은 변환하더라도 값은 건드리지 않아야 합니다. 특히 created_at, updated_at 같은 필드의 유닉스 타임스탬프 값을 다룰 때는, 값이 사람이 읽을 수 있는 날짜인지 타임스탬프 변환기로 확인해두면 디버깅이 훨씬 수월합니다. 키 변환 과정에서 값까지 망가뜨리는 실수를 사전에 차단할 수 있습니다.
실무에서 표기법 관리하는 법
변환 자체보다 중요한 건 변환을 어디서 한 번만 처리하느냐입니다. 변환 로직이 코드 곳곳에 흩어지면 유지보수가 지옥이 됩니다.
- 경계에서 변환: API 요청을 보내기 직전과 응답을 받은 직후, 즉 시스템 경계 한 곳에서만 변환을 처리합니다
- 인터셉터 활용: axios 같은 HTTP 클라이언트의 인터셉터에 변환 함수를 걸어두면, 비즈니스 로직은 표기법을 신경 쓸 필요가 없습니다
- 중첩 객체 대응: 실무 JSON은 객체 안에 객체가 들어있는 경우가 많으므로, 재귀적으로 모든 키를 변환하는지 반드시 확인합니다
팀 단위로 작업한다면 컨벤션 문서에 "DB와 API는 스네이크, 프론트 코드는 카멜"처럼 한 줄로 명시해두는 것만으로도 불필요한 논쟁이 사라집니다.
지금 진행 중인 프로젝트에서 API 키 표기법이 뒤섞여 있다면, 먼저 변환 지점을 한 곳으로 모으세요. 그다음 약어와 숫자 처리 규칙을 팀 컨벤션으로 정리하면, 표기법 때문에 버그가 생기는 일이 거의 없어집니다.
