camelCase와 PascalCase의 차이는 무엇인가요?
camelCase는 첫 단어를 소문자로 시작하고, PascalCase는 모든 단어의 첫 글자를 대문자로 시작합니다. 변수와 함수에는 camelCase, 클래스나 컴포넌트에는 PascalCase를 쓰는 경우가 많습니다.
대소문자 변환
텍스트를 다양한 케이스로 변환합니다. UPPER, lower, Title, camelCase, snake_case, kebab-case를 지원합니다.
입력
결과
케이스 변환 핵심 질문
프로그래밍 언어마다 권장하는 케이스가 다른가요?
그렇습니다. JavaScript는 camelCase, Python은 snake_case, CSS와 URL 슬러그는 kebab-case, 상수는 UPPER_CASE가 일반적입니다. 팀 규칙과 생태계 관례를 맞추면 가독성과 유지보수가 좋아집니다.
snake_case와 kebab-case는 어떤 차이가 있나요?
snake_case는 밑줄로 단어를 구분하고 kebab-case는 하이픈을 사용합니다. 전자는 Python과 DB 컬럼명에서, 후자는 CSS 클래스와 URL 구조에서 자주 쓰입니다.
자주 묻는 질문
camelCase와 PascalCase의 차이는 무엇인가요?
camelCase는 첫 단어를 소문자로 시작(getUserName)하고, PascalCase는 모든 단어의 첫 글자를 대문자로 시작(GetUserName)합니다.
프로그래밍 언어마다 권장하는 케이스가 다른가요?
네. JavaScript는 camelCase, Python은 snake_case, CSS는 kebab-case, 상수는 UPPER_CASE를 관례로 사용합니다.
snake_case와 kebab-case는 어떤 차이가 있나요?
snake_case는 밑줄(_)로, kebab-case는 하이픈(-)으로 단어를 구분합니다. snake_case는 Python/DB 컬럼명에, kebab-case는 URL/CSS에 주로 사용됩니다.
API 응답의 케이스를 프론트엔드에서 변환해야 하나요?
API가 snake_case로 응답하고 프론트엔드가 camelCase를 사용한다면, 변환 라이브러리나 직접 매핑이 필요합니다. 이 도구로 빠르게 확인해볼 수 있습니다.
Title Case는 언제 사용하나요?
영문 제목, 헤딩, UI 버튼 텍스트에서 주로 사용합니다. 전치사(in, on, at 등)와 관사(a, the)는 소문자로 유지하는 것이 일반적인 관례입니다.
프로그래밍 네이밍 컨벤션 가이드
프로그래밍에서 케이스 변환이 자주 필요한 상황은 언제인가요?
API 응답이 snake_case인데 프론트엔드 코드는 camelCase를 사용하는 경우, 또는 DB 컬럼명을 JSON 키로 그대로 쓸 때 변환이 필요합니다. 팀마다 컨벤션이 달라 협업 코드 정리나 레거시 마이그레이션 시에도 빠른 케이스 변환 도구가 유용하며, 반복 수작업 없이 즉시 결과를 확인할 수 있습니다.
코드에서 변수, 함수, 클래스 이름을 짓는 방식을 네이밍 컨벤션(Naming Convention)이라고 합니다. 프로그래밍 언어와 분야마다 권장하는 케이스가 다르기 때문에, 팀 프로젝트나 오픈소스 기여 시 해당 컨벤션을 따르는 것이 매우 중요합니다.
| 케이스 | 표기법 | 사용 언어/분야 | 예시 |
|---|---|---|---|
| camelCase | 첫 단어 소문자, 이후 대문자 | JavaScript, TypeScript, Java | getUserName, totalPrice |
| snake_case | 밑줄로 단어 구분, 전체 소문자 | Python, Ruby, DB 컬럼명 | get_user_name, total_price |
| kebab-case | 하이픈으로 단어 구분 | CSS, URL 슬러그, HTML 속성 | main-container, nav-link |
| PascalCase | 모든 단어 첫 글자 대문자 | C#, React 컴포넌트, 클래스명 | UserProfile, ShoppingCart |
| UPPER_CASE | 밑줄 구분, 전체 대문자 | 상수, 환경변수 | MAX_RETRY_COUNT, API_BASE_URL |
| Title Case | 각 단어 첫 글자 대문자 | 영문 제목, UI 버튼 텍스트 | The Quick Brown Fox |
언어별 권장 네이밍 규칙
JavaScript / TypeScript: 변수와 함수는 camelCase(getUserData), 클래스와 React 컴포넌트는 PascalCase(UserProfile), 상수는 UPPER_CASE(API_KEY)를 사용합니다. ESLint의 naming-convention 규칙으로 자동 검사할 수 있습니다.
Python: PEP 8 스타일 가이드에 따라 변수와 함수는 snake_case(get_user_data), 클래스는 PascalCase(UserProfile), 상수는 UPPER_CASE(MAX_CONNECTIONS)를 사용합니다. pylint나 flake8으로 컨벤션 위반을 검출합니다.
CSS: 클래스명과 ID에 kebab-case(main-header, nav-link)를 사용합니다. BEM(Block Element Modifier) 방법론에서는 block__element--modifier 패턴을 따르는데, 예를 들어 card__title--highlighted처럼 작성합니다. Tailwind CSS 같은 유틸리티 프레임워크에서도 text-sm, bg-gray-50 등 kebab-case를 기본으로 합니다.
SQL / 데이터베이스: 테이블명과 컬럼명에 snake_case(user_profiles, created_at)를 사용하는 것이 가장 보편적입니다. PostgreSQL은 대소문자를 구분하지 않으므로(따옴표 없이) snake_case가 자연스럽고, MySQL에서도 같은 관례를 따르는 경우가 많습니다.
API 응답 케이스 변환 실무
실무에서 가장 흔하게 케이스 변환이 필요한 상황은 백엔드와 프론트엔드 간의 데이터 교환입니다. 백엔드(Python/Ruby)에서 snake_case로 내려온 API 응답을 프론트엔드(JavaScript)에서 camelCase로 변환하는 작업이 거의 매번 발생합니다.
직접 매핑: 간단한 경우에는 구조 분해 할당으로 처리할 수 있습니다. const { user_name: userName, created_at: createdAt } = response; 형태로 키 이름을 바꿔서 받는 방식입니다.
라이브러리 활용: 대규모 프로젝트에서는 lodash의 camelCase() 함수나 humps 라이브러리를 사용합니다. humps.camelizeKeys(response)를 호출하면 중첩된 객체의 모든 키를 재귀적으로 camelCase로 변환해줍니다. Axios 인터셉터에 적용하면 모든 API 응답에 자동으로 변환을 걸 수 있어 편리합니다.
GraphQL: GraphQL은 스키마에서 필드명을 자유롭게 정의할 수 있어서, 백엔드와 프론트엔드가 동일한 camelCase 필드명을 사용하도록 설계하면 별도 변환이 필요 없습니다. 이 점이 REST API 대비 GraphQL의 장점 중 하나입니다.
좋은 변수명을 짓는 원칙
의미 있는 이름을 사용하세요. x, tmp, data 같은 이름보다 userAge, maxRetryCount, isLoggedIn처럼 역할을 명확히 드러내는 이름이 좋습니다. 코드를 읽는 사람(6개월 후의 자기 자신 포함)이 변수의 용도를 즉시 파악할 수 있어야 합니다.
일관된 케이스 규칙을 유지하세요. 한 프로젝트 안에서 getUserData와 get_user_list가 섞여 있으면 혼란스럽습니다. 팀에서 합의한 하나의 규칙을 정하고, 린터(ESLint, pylint)를 설정하여 자동으로 검사하는 것이 가장 효과적입니다.
축약어 사용 규칙을 정하세요. URL, HTTP, API 같은 널리 알려진 축약어도 케이스 규칙에 따라 표기 방식이 달라집니다. camelCase에서는 xmlHttpRequest처럼 축약어도 일반 단어처럼 취급하는 것이 관례이지만, 팀마다 XMLHttpRequest처럼 대문자를 유지하는 경우도 있습니다. 중요한 것은 프로젝트 내에서 일관성을 지키는 것입니다.
케이스 변환이 필요할 때 일일이 수작업으로 바꾸는 것은 시간 낭비이고 오타 위험도 있습니다. 이 도구에서 텍스트를 붙여넣고 원하는 케이스 버튼을 누르면 즉시 변환됩니다.