JSON 키 camelCase↔snake_case 변환법

API 응답이 snake_case로 오는데 프론트엔드 코드는 camelCase 컨벤션을 쓰고 있다면, 매번 key 이름을 손으로 바꾸는 대신 표기법 변환 규칙 하나만 알면 됩니다.

camelCase·snake_case·PascalCase·kebab-case는 전부 "단어를 어떻게 나누고 다시 붙이는가"라는 같은 원리 위에서 정해진 표기 규칙입니다. 이 글은 그 규칙을 직접 손으로 적용하는 법과, 자동 변환기에서 흔히 놓치는 예외 케이스를 정리합니다.

요약 ① camelCase·snake_case·PascalCase·kebab-case는 단어 구분 방식만 다른 같은 데이터의 표기법입니다. ② 변환은 대문자 위치와 언더스코어·하이픈 위치로 단어를 나눈 뒤 목표 표기법대로 다시 합치는 방식입니다. ③ 중첩된 객체와 배열 안의 key도 같은 규칙이 depth 제한 없이 재귀적으로 적용됩니다.

이 문제가 실제로 생기는 상황

이 문제는 서로 다른 언어·프레임워크의 관례가 API 하나를 사이에 두고 만날 때 생깁니다. 백엔드가 Python 계열 프레임워크로 짜여 있으면 응답 JSON의 key가 보통 snake_case(user_id, created_at)로 나옵니다.

반면 프론트엔드가 JavaScript·TypeScript라면 코드 컨벤션은 camelCase(userId, createdAt)를 쓰는 경우가 많습니다.

이 상태에서 응답을 그대로 쓰면 한 파일 안에 user_id와 userName이 뒤섞인 코드가 나옵니다. 필드가 몇 개 안 되면 매핑 함수를 손으로 짜서 넘어갈 수 있지만, 필드가 수십 개이고 그 안에 중첩 객체와 배열까지 섞여 있으면 깊은 depth의 key 하나를 빠뜨리기 쉽습니다.

도구 없이 표기법 규칙대로 직접 바꾸는 방법

네 가지 표기법은 모두 같은 원리로 만들어집니다. key 이름을 "단어" 단위로 나눈 뒤, 그 단어들을 표기법마다 정해진 방식으로 다시 붙이는 것입니다.

단어를 나누는 기준은 두 가지뿐입니다. camelCase·PascalCase처럼 구분자가 없는 표기법은 대문자가 시작되는 자리를 새 단어의 시작으로 보고, snake_case·kebab-case처럼 구분자가 있는 표기법은 언더스코어(_)나 하이픈(-)이 나오는 자리를 기준으로 나눕니다.

단어를 나눴으면 아래 규칙대로 다시 합치면 됩니다.

중첩 객체·배열도 같은 규칙

예를 들어 { "user_id": 1, "profile": { "email_address": "a@test.com" } }를 camelCase로 바꾼다면, user_id는 언더스코어 기준으로 나뉘어 userId가 되고, 중첩된 profile 객체 안의 email_address도 같은 규칙으로 emailAddress가 됩니다.

최상위 key만 바꾸고 안쪽 객체를 그대로 두면 절반만 바뀐 결과가 나오므로, 나뉜 모든 depth에 같은 규칙을 반복 적용해야 합니다.

배열이 섞여 있어도 규칙은 같습니다. order_list처럼 배열 자체의 key는 orderList로 바뀌고, 그 배열 원소가 { order_id: 1 } 같은 객체라면 원소 안의 key도 같은 규칙으로 바뀝니다. 원소가 문자열이나 숫자라면(예: "tags": ["new", "sale"]) 바꿀 key 자체가 없으므로 값은 그대로 남습니다.

정규식으로 자동화하는 방법

이 과정을 프로그램으로 구현할 때는 정규식으로 처리하는 것이 일반적입니다. camelCase로 바꾸는 함수는 "-"나 "_" 뒤에 오는 소문자를 찾아 대문자로 바꾸면서 구분자를 없애는 치환 한 번으로 끝납니다.

snake_case나 kebab-case로 바꾸는 함수는 반대로 대문자가 나오는 자리마다 구분자를 끼워 넣은 뒤 전체를 소문자로 바꾸는 방식이며, PascalCase는 camelCase 결과에서 첫 글자만 대문자로 바꾸면 됩니다.

key가 몇 개뿐이라면 이 규칙을 손으로 적용해도 충분합니다. 하지만 depth가 여러 겹이고 key 수가 많아지면 하나씩 손으로 바꾸다가 중첩된 곳의 key를 빠뜨리기 쉽습니다. 저희 도구는 이 재귀 적용을 자동으로 처리합니다.

저희 도구로 확인하기.

직접 해보기 →

흔히 오해하는 지점

규칙 자체는 단순하지만, 실제 데이터에서는 몇 가지 key 모양 때문에 결과가 예상과 다르게 나올 수 있습니다.

구분자가 섞이거나 대문자로 시작하는 key

하이픈과 언더스코어가 한 key 안에 섞여 있어도(user-id_name) 걱정할 필요는 없습니다. 두 구분자 모두 "새 단어의 시작"으로 인식되기 때문에 camelCase로 바꾸면 userIdName처럼 정상적으로 합쳐집니다.

반대로 원본 key가 이미 PascalCase처럼 대문자로 시작한다면(UserId) 결과를 유심히 봐야 합니다. snake_case·kebab-case로 바꾸는 규칙은 "대문자가 나오는 자리마다 구분자를 끼워 넣는" 방식이라, 첫 글자가 대문자면 그 자리에도 구분자가 붙어 결과 맨 앞에 구분자가 남을 수 있습니다.

결과 맨 앞에 구분자가 보인다면 원본 key가 대문자로 시작했다는 신호로 읽으면 됩니다.

값(value)과 JSON 문법 오류

값(value)은 변환 대상이 아닙니다. 문자열·숫자·불리언·null 값은 표기법과 무관하게 원래 내용 그대로 남습니다. 값 안에 우연히 user_id 같은 문자열이 들어 있어도 그 문자열 자체는 바뀌지 않습니다.

JSON 문법이 틀렸을 때는 변환 대신 파싱 에러 메시지가 그대로 화면에 나타납니다. 대괄호·중괄호가 안 맞거나, key를 큰따옴표로 감싸지 않았거나, 마지막 항목 뒤에 쉼표가 남아 있거나(trailing comma), 작은따옴표를 큰따옴표 대신 썼을 때 흔히 발생합니다.

에러 메시지에 포함된 position 숫자는 문자열 맨 앞부터 공백까지 포함해 몇 번째 글자에서 문제가 생겼는지를 가리키므로, 그 위치 주변을 확인하면 원인을 좁힐 수 있습니다.

정리

• camelCase·snake_case·PascalCase·kebab-case는 단어를 나누고 다시 합치는 규칙만 다른 같은 데이터의 표기법입니다.
• 대문자 시작 지점과 언더스코어·하이픈 위치가 단어를 나누는 기준이 됩니다.
• 중첩된 객체와 배열 안의 key에도 같은 규칙이 depth 제한 없이 반복 적용되어야 빠짐없이 바뀝니다.
• 원본 key가 대문자로 시작하면 snake_case·kebab-case 변환 결과 맨 앞에 구분자가 남을 수 있다는 점을 알아두면 됩니다.
• key가 아닌 값(value)의 내용은 변환 대상이 아니며, JSON 문법이 틀리면 파싱 에러 메시지가 그대로 표시됩니다.

자주 묻는 질문

중첩된 객체나 배열 안의 key도 변환되나요?

네. 객체 안에 또 다른 객체가 들어 있거나 배열 안에 객체가 들어 있어도, 그 안의 모든 key까지 depth 제한 없이 재귀적으로 찾아 같은 규칙으로 변환합니다.

입력창의 JSON을 수정하면 결과도 자동으로 바뀌나요?

아니요. 변환은 "변환하기" 버튼을 눌렀을 때 그 시점의 입력값으로 1회 실행됩니다. 입력을 고친 뒤에는 버튼을 다시 눌러야 새 결과가 나옵니다.

key 이름이 아니라 값(value) 안의 문자열도 표기법이 바뀌나요?

아니요. 변환 대상은 key 이름뿐입니다. 문자열·숫자·불리언·null 같은 값은 원래 형태 그대로 유지됩니다.

JSON 문법 오류라는 에러가 뜨는데 무엇이 문제인가요?

입력한 문자열이 JSON.parse가 요구하는 문법을 지키지 않은 경우입니다. 마지막 항목 뒤 쉼표(trailing comma), 작은따옴표 사용, key를 큰따옴표로 감싸지 않은 경우가 흔한 원인입니다. 화면에 표시되는 에러 메시지에 포함된 position 숫자로 몇 번째 글자에서 문제가 생겼는지 확인할 수 있습니다.