네이밍 컨벤션 변환기

사용법

아무 형식으로나 이름을 입력하면 여섯 가지 표기법으로 한 번에 바꿉니다. 공백, 하이픈(-), 밑줄(_), 점(.), 그리고 camelCase의 대소문자 경계를 모두 단어 구분으로 인식합니다. 여러 줄을 넣으면 줄 단위로 변환하고, 각 형식의 결과 전체를 복사할 수 있습니다.

쓰임새: API 응답의 snake_case 키를 프론트엔드 camelCase로 옮길 때, 디자인 토큰 이름을 CSS 변수 --kebab-case로 바꿀 때, 상수 목록을 CONSTANT_CASE로 정리할 때 등입니다.

실제 응용

어디에 무엇을 쓰는가

표기법은 취향이 아니라 자리마다 굳어진 관례입니다. 관례를 따르면 이름만 보고도 그게 무엇인지 짐작할 수 있습니다.

경계에서 표기법이 바뀌는 지점이 실무의 대부분입니다. DB는 snake_case, 프론트엔드는 camelCase인 상황이 가장 흔합니다.

여러 줄을 한꺼번에 옮기는 게 진짜 쓸모

이름 하나를 바꾸는 건 손으로도 됩니다. 이 도구가 시간을 아껴 주는 순간은 목록을 통째로 옮길 때입니다. DB 스키마의 컬럼 목록을 그대로 붙여넣고 camelCase 결과를 복사하면, 타입 정의의 뼈대가 한 번에 나옵니다.

# 입력 (DB 컬럼 목록을 그대로 붙여넣기)
user_id
created_at
is_active
last_login_at
profile_image_url

# camelCase 결과
userId
createdAt
isActive
lastLoginAt
profileImageUrl

반대 방향도 같습니다. 프론트엔드에서 쓰던 필드 이름을 붙여넣고 snake_case 결과를 가져가면 마이그레이션 파일에 그대로 넣을 수 있습니다.

약어는 원래 모양으로 돌아오지 않는다

이 도구를 쓰기 전에 알아 둬야 할 한 가지입니다. 변환 과정에서 단어를 전부 소문자로 내렸다가 다시 조립하기 때문에, 연속된 대문자 약어는 원형이 유지되지 않습니다.

이게 문제인지 아닌지는 팀 규칙에 달렸습니다. 구글 자바스크립트 스타일 가이드를 비롯해 약어도 일반 단어처럼 쓰도록(userId) 정한 규칙이 많고, 그런 팀에서는 오히려 원하는 결과가 나옵니다. 반대로 약어를 대문자로 유지하는 규칙이라면 변환 후 그 부분만 손으로 되돌려야 합니다.

iOSDevice처럼 소문자로 시작하는 약어는 i-os-device가 되어 의도와 크게 달라집니다. 이런 이름은 변환에 맡기지 말고 직접 쓰는 편이 낫습니다.

숫자가 붙는 위치를 확인한다

숫자는 앞 단어에 붙습니다. grid2Col은 grid2와 col로, h1Title은 h1과 title로 나뉩니다. 대부분 의도한 대로지만, v2Endpoint를 v-2-endpoint로 만들고 싶었다면 결과가 다릅니다(v2-endpoint). 숫자가 들어간 이름은 결과를 한 번 확인하고 쓰세요.