firstName이야 first_name이야? — 팀 프로젝트에서 네이밍 때문에 싸운 썰

코드 리뷰 코멘트 중에 가장 인상 깊었던 게 있어요. 기능 구현 자체보다 변수 이름 형식 때문에 스레드가 20개 넘게 달린 거예요. 'Python 코드에서 왜 camelCase를 써요?', '저는 항상 이렇게 써왔는데요', '그래도 언어 컨벤션은 따라야죠'. 저도 한쪽에서 읽으면서 속으로 생각했어요. '이거 미리 문서 하나 공유했으면 됐을 텐데.' 이 글이 그 문서예요.

대소문자 형식 6가지 — 이름과 쓰임새

네이밍 컨벤션이 생각보다 많아요. 이름이 모양을 설명해서 직관적이긴 한데, 어디서 어떤 걸 쓰는지가 핵심이에요. 그냥 형식을 아는 것보다 맥락을 아는 게 훨씬 중요하거든요.

언어별로 실제로 어떻게 쓰는지

네이밍 컨벤션이 까다로운 이유는 언어마다 다르기 때문이에요. 자바스크립트에서 맞는 게 파이썬에서는 틀리고, CSS에서 자연스러운 게 SQL에서는 이상해 보여요. 한 번에 정리해드릴게요.

// JavaScript / TypeScript
const firstName = 'Alice';          // camelCase — 변수
class UserProfile { }               // PascalCase — 클래스
const MAX_RETRIES = 3;              // SCREAMING_SNAKE — 상수
type ApiResponse = { ... };         // PascalCase — 타입/인터페이스

# Python
first_name = 'Alice'               # snake_case — 변수와 함수
class UserProfile:                  # PascalCase — 클래스
MAX_RETRIES = 3                    # SCREAMING_SNAKE — 모듈 레벨 상수

/* CSS */
.user-profile { }                  /* kebab-case — 클래스명 */
--primary-color: #3B82F6;          /* kebab-case — 커스텀 프로퍼티 */

-- SQL
CREATE TABLE user_profiles (        -- snake_case — 테이블명
  first_name VARCHAR(50),           -- snake_case — 컬럼명
  PRIMARY KEY (id)
);

// Go
func GetUserProfile() { }           // PascalCase — 외부 공개 함수
func getUserProfile() { }           // camelCase — 내부 전용

API 네이밍 — 가장 분쟁이 많은 영역

API에서 네이밍이 복잡해지는 이유는 백엔드와 프론트엔드가 다른 언어를 쓰기 때문이에요. Python Django 백엔드는 snake_case가 자연스럽고, JavaScript React 프론트엔드는 camelCase를 기대해요. API 응답을 어떤 형식으로 내려보낼지 정해야 하는데, 여기서 팀이 갈려요.

업계에서는 대체로 두 진영으로 나뉘어 있어요. JSON:API랑 OpenAPI 커뮤니티는 JavaScript 소비자가 더 편하다며 camelCase를 선호해요. Python이나 Ruby 개발자들은 백엔드 모델이 snake_case라 그대로 내려보내는 게 낫다고 해요. GraphQL 스키마는 camelCase가 거의 표준이에요.

• REST API: 공식 표준은 없지만, 프론트엔드 팀이 강한 곳에서는 camelCase 채택이 더 많아요. Python/Ruby 기반은 snake_case가 흔하고요.
• GraphQL: 필드명에 camelCase가 사실상 표준 (firstName, first_name 아님)
• gRPC / Protocol Buffers: .proto 파일에서 snake_case 사용, JS 출력에서 camelCase로 자동 변환
• DB에서 API로 매핑: Pydantic alias_generator 같은 직렬화 레이어로 snake_case DB 컬럼을 camelCase JSON으로 자동 변환 가능
• 환경 변수: SCREAMING_SNAKE_CASE가 사실상 전 플랫폼 공통 표준

SEO와 Title Case — 생각보다 복잡해요

콘텐츠 팀이랑 마케팅 팀이 주로 논쟁하는 건 제목에 Title Case를 쓸지 Sentence case를 쓸지예요. Title Case는 주요 단어의 첫 글자를 대문자로 써요(전치사, 접속사 등 짧은 단어 제외). Sentence case는 첫 단어랑 고유명사만 대문자예요.

SEO 관점에서는 구글이 두 형식 모두 동등하게 크롤링하고 랭킹에 차이를 두지 않아요. 차이는 브랜드 보이스와 사용자 경험이에요. Title Case는 권위 있고 공식적인 느낌(언론사, 법률 문서에서 흔함), Sentence case는 대화하듯 친근한 느낌이에요. 구글, 애플, 노션, 리니어 모두 인터페이스에서 Sentence case를 써요. 선택의 문제지, 옳고 그름이 아니에요. 다만 전체 사이트에서 일관되게 써야 해요.

• Title Case: 'How to Calculate Compound Interest in Python' — 공식적, 에디토리얼한 느낌
• Sentence case: 'How to calculate compound interest in Python' — 현대적, 대화체
• 제목에 전부 대문자는 피해요 — 소리 지르는 느낌이고 사용자 테스트에서 읽기 불편하다는 결과가 나왔어요
• URL 슬러그에는 kebab-case 필수 — 공백은 %20으로 인코딩되고, 하이픈은 구글이 단어 구분자로 인식해요
• React 컴포넌트 파일명은 PascalCase — UserProfile.tsx, 이건 컨벤션이 아니라 거의 생태계 표준이에요

변환 — 손으로 하면 지치고 도구 쓰면 5초

케이스 변환을 직접 하는 건 간단해 보이는데 50개 넘어가면 진짜 지쳐요. 특히 DB 스키마에서 snake_case 컬럼명 50개를 camelCase JSON 키로 바꿔야 할 때. 알고리즘은 항상 같아요 — 구분자(공백, 언더스코어, 하이픈, 대문자)로 분리하고 목표 포맷으로 다시 조합하는 것. 도구가 이걸 즉시 해줘요.