대소문자 변환기

언어·플랫폼마다 관례가 정해져 있습니다

어떤 케이스를 쓸지는 취향 문제가 아니라 그 생태계의 관례를 따르는 문제입니다. 관례를 어기면 동작은 하지만 코드 리뷰에서 지적당하고 자동 완성·린터와도 어긋납니다.

가장 흔한 작업 — API 응답과 코드 사이의 변환

실무에서 이 도구를 여는 순간은 대체로 정해져 있습니다. 파이썬·PHP 백엔드가 snake_case 로 JSON을 내려주는데 프런트는 camelCase 를 쓰는 상황, 또는 DB 컬럼 목록을 받아 자바스크립트 객체 키로 바꿔야 하는 상황입니다.

입력창에 붙여넣으면 14가지 형식이 동시에 나오므로 필요한 칸만 복사하면 됩니다. 다만 이 도구는 입력 전체를 하나의 문자열로 보고 단어를 나눕니다 — 줄바꿈도 단어 구분자가 되므로 여러 줄을 넣으면 전체가 하나의 camelCase 로 합쳐집니다. 한 줄씩 변환하는 것이 의도한 사용법입니다.

• 역방향도 됩니다 — camelCase 를 붙여넣으면 대문자 앞에서 단어를 끊어 snake_case 로 만들어 줍니다. 입력창 오른쪽에 몇 개 단어로 인식했는지 표시되니 그 숫자로 확인하세요.
• dot.case 는 설정 파일 키(spring.datasource.url)나 로그 네임스페이스에, path/case 는 URL 경로를 만들 때 씁니다.
• 역순(뒤집기)은 이모지·한글이 섞여도 깨지지 않게 코드 포인트 단위로 처리합니다.

약어가 섞이면 어떻게 되나

개발자들이 실제로 논쟁하는 지점입니다. HTTPServer 를 어떻게 나눌 것인가. 이 도구는 연속된 대문자 뒤에 대문자+소문자가 오면 거기서 끊습니다. HTTPServer 는 HTTP + Server 로, XMLHttpRequest 는 XML + Http + Request 로 인식합니다. 그래서 snake_case 는 http_server, camelCase 는 httpServer 가 됩니다.

결과가 항상 기대와 같지는 않습니다. userID 는 user + ID 로 잘 끊겨 user_id 가 나오지만, 대문자가 연달아 붙은 이름은 사람이 생각한 경계와 다르게 갈릴 수 있습니다. 약어가 많이 섞인 이름은 결과를 눈으로 확인하는 편이 낫습니다.

한글이 섞였을 때 벌어지는 일

한글에는 대소문자가 없습니다. 대문자 변환을 해도 그대로입니다. 그래서 이 도구는 한글을 손대지 않고 그대로 둡니다 — "상품 재고 관리"를 camelCase 로 바꾸면 "상품재고관리"가 됩니다.

한글과 영문이 붙어 있으면 단어 경계로 봅니다. "사용자Name"은 사용자 + Name 두 단어로 인식해 snake_case 에서 사용자_name 이 됩니다. 실무에서 이 조합을 만나는 곳이 있습니다.

• 기획서의 한글 항목명을 영문 변수명으로 옮기기 전, 구분자만 먼저 정리하는 중간 단계.
• 엑셀에서 받은 한글 컬럼 헤더를 임시 키로 만들 때 — 다만 최종 코드에 한글 식별자를 남기지는 마세요. 인코딩 문제로 도구·환경마다 다르게 깨질 수 있습니다.
• CSS 클래스나 URL 경로에 한글이 들어가면 브라우저는 처리하지만 퍼센트 인코딩되어 주소가 길어지고, 일부 빌드 도구가 처리하지 못합니다.

이 도구로 안 되는 것

기계적인 규칙만 적용하므로 문맥은 모릅니다. 한계를 정직하게 적어 둡니다.

• 제목형(Title Case)은 모든 단어의 첫 글자를 대문자로 만듭니다. 영어 표기법상 관사·전치사(a, the, of, in)는 소문자로 두는 것이 맞지만 그 구분은 하지 않습니다. 영문 제목을 정식으로 다듬으려면 손을 봐야 합니다.
• 문장형(Sentence case)은 마침표·느낌표·물음표 뒤를 문장의 시작으로 봅니다. "Dr. Kim" 같은 약어의 마침표도 문장 끝으로 오해합니다.
• 전체 대문자·소문자와 문장형을 제외한 나머지 형식은 원래 문장의 문장부호를 버립니다(구분자로만 쓰므로). 문장을 그대로 두면서 대소문자만 바꾸고 싶다면 UPPERCASE·lowercase·Sentence case 칸을 보세요.