개발 표기법(Naming Convention)정리: camelCase, PascalCase, snake_case

반응형

 

개발 표기법(Naming Convention)정리: camelCase, PascalCase, snake_case

표기법 삽화 이미지

1. 표기법은 왜 필요하며, 어떤 종류가 있는가

표기법은 취향이 아니라 설계의 결과입니다.

언어, 플랫폼, 계층은 각자 “기대하는 이름의 형태”가 있으며, 이를 따르지 않으면 가독성뿐 아니라 자동화 도구, 협업, 유지보수에까지 영향을 미치게 됩니다.

 

🔷 표기법은 ‘읽는 사람과 도구를 위한 약속’

공식 문서들이 공통적으로 강조하는 핵심은 다음과 같습니다.

▸ 코드는 사람이 읽는 시간이 훨씬 길다
▸ 컴파일러·인터프리터·프레임워크는 이름에 의미를 부여한다
▸ 일관된 표기법은 의사결정 비용을 줄인다

 

즉, 표기법은 단순한 스타일이 아니라 의도를 전달하기 위한 인터페이스에 가깝습니다.

 

🔷 대표적인 표기법 종류

✔️ camelCase

▸ 첫 단어는 소문자, 이후 단어의 첫 글자는 대문자
▸ 변수, 함수, 객체 속성에 가장 널리 사용
▸ Java, JavaScript, TypeScript 공식 문서에서 기본 권장

userName
createdAt
fetchUserProfile()

 

✔️ PascalCase

▸ 모든 단어의 첫 글자가 대문자
▸ 타입(Type)을 표현할 때 사용 : “이 식별자는 값이 아니라 구조다”라는 신호
▸ 클래스, 인터페이스, Enum의 표준

UserService
CreateUserRequest
OrderStatus

 

✔️ snake_case

▸ 단어를 _로 구분
▸ Python(Python Enhancement Proposal 8)과 SQL에서 표준
▸ 사람이 읽기에 안정적이며 DB와 궁합이 좋음

user_name
created_at
get_user_profile()

 

✔️ UPPER_SNAKE_CASE

▸ 상수, 환경 변수
▸“변경되지 않는 값”이라는 강한 의미 전달

MAX_RETRY_COUNT
DATABASE_URL

 

✔️ kebab-case

▸ 파일명, URL, CSS 클래스에서 사용
▸ 대소문자 문제를 피할 수 있어 웹 환경에 적합

user-profile.component.ts
/api/user-profile
.main-header

 

2. 언어별로 굳어진 표기법 관습

많은 개발자들이 표기법을 “언어별로 하나씩 정해진 규칙”으로 이해하지만, 실제 공식 문서와 실무 코드를 살펴보면 하나의 언어 안에서도 여러 표기법이 역할에 따라 공존합니다.

 

🔷 Java – 역할이 명확하게 드러나는 표기법 분리

Java는 가장 오래되고 엄격한 컨벤션을 가진 언어 중 하나입니다.

Oracle의 공식 Java Code Conventions는 이름만 보고도 역할을 구분할 수 있어야 한다는 철학을 강조합니다.

▸ 클래스 / Enum / Interface → PascalCase
▸ 메서드 / 변수 / 필드 → camelCase
▸ 상수(static final) → UPPER_SNAKE_CASE
▸ 패키지명 → all lowercase

Java에서는 이 규칙이 깨지면 “문법 오류는 아니지만 리뷰 대상”이 되는 경우가 대부분입니다.

package com.company.user;

public class UserService {

    private String userName;              // camelCase (필드)
    private LocalDateTime createdAt;

    public static final int MAX_USER_COUNT = 100; // UPPER_SNAKE_CASE (상수)

    public UserService() {
    }

    public void createUser(String userName) {     // camelCase (메서드)
        this.userName = userName;
    }
}

 

🔷 JavaScript / TypeScript – 값과 타입을 시각적으로 분리

JavaScript 자체는 표기법을 강제하지 않지만, TypeScript와 함께 사용되면서 사실상의 표준 패턴이 정착되었습니다.

▸ 변수 / 함수 / 객체 속성 → camelCase
▸ 타입 / 인터페이스 / 클래스 → PascalCase
▸ 상수 → UPPER_SNAKE_CASE
▸ 파일명 → kebab-case
▸ JSON 필드 → camelCase

TypeScript 공식 문서에서는 “타입은 PascalCase, 값은 camelCase”라는 구분을 강하게 권장합니다.

// 타입: PascalCase (구조/도메인 표현)
interface UserProfile {
  userId: number;
  createdAt: Date;
  isActive: boolean;
}

// 클래스: PascalCase (비즈니스 로직 담당)
class UserService {
  fetchUserProfile(userId: number): UserProfile {
    return { userId, createdAt: new Date(), isActive: true };
  }
}

// 상수: UPPER_SNAKE_CASE (변경 불가 값)
const API_TIMEOUT_MS = 3000;

// 함수/변수: camelCase (동작·값 표현)
function fetchUserData() {}
let currentUserId = 1;


// 파일명
user-profile.service.ts
user-profile.controller.ts

 

🔷 Python – snake_case 중심의 강한 일관성 (PEP 8)

Python은 표기법을 “선택 사항”으로 두지 않습니다.
PEP 8 문서는 사실상 표기법 규격서에 가깝습니다.

▸ 변수 / 함수 / 메서드 → snake_case
▸ 클래스 → PascalCase
▸ 상수 → UPPER_SNAKE_CASE
▸ 파일 / 모듈 → snake_case

Python에서는 이 규칙을 어길 경우 코드 자체보다 코드 스타일이 문제로 지적되는 경우가 많습니다.

MAX_RETRY_COUNT = 5          # UPPER_SNAKE_CASE (상수)

class UserService:           # PascalCase (클래스)
    def __init__(self, user_name: str):
        self.user_name = user_name   # snake_case (필드)

    def get_user_profile(self):      # snake_case (메서드)
        return {
            "user_name": self.user_name
        }


//파일명
user_service.py
user_profile_repository.py

 

🔷 Go – 표기법 자체가 접근 제어자

Go는 매우 독특합니다.
표기법이 곧 public / private을 결정합니다.

▸ 공개 식별자 → PascalCase
▸ 비공개 식별자 → camelCase
▸ 상수 → UPPER_SNAKE_CASE
▸ 파일명 → snake_case.go

Go 공식 문서에서는 “이름의 첫 글자가 API의 일부”라고 명시합니다.

type UserService struct {}   // PascalCase → public

func GetUser() string {      // public
    return "user"
}

func getUserId() int {       // private
    return 1
}

const MAX_COUNT = 10         // UPPER_SNAKE_CASE


//파일명
user_service.go
auth_handler.go

반응형

 

3. 계층별 표기법이 달라지는 이유: 데이터의 ‘경계’ 이해하기

🔷 데이터의 이동 경로와 계층별 표준

데이터는 사용자에게 도달하기까지 총 4개의 주요 성격이 다른 지점을 통과합니다.

계층	환경	표기법	주요 목적
DB	SQL / RDBMS	snake_case	데이터의 영속성 보존, 정합성 유지
Backend	Java, Kotlin, Go 등	camelCase	비즈니스 로직 실행, 타입 안정성 확보
API	JSON (JavaScript 기반)	camelCase	시스템 간 계약(Contract) 정의 및 데이터 교환
Frontend	JavaScript / TypeScript	camelCase	UI 구현, 개발 생산성 및 일관성 유지

 

🔷 왜 DB는 snake_case를 고집하는가?

단순히 관습 때문이 아닙니다. SQL 환경의 특수성 때문입니다.

1. SQL 예약어와의 시각적 분리:

SQL 문법(SELECT, FROM, WHERE)은 대문자로, 데이터 이름은 소문자로 쓰는 것이 관례입니다.

이때 단어 사이를 구분하기 위해 언더바(_)를 사용하는 것이 가독성이 가장 높습니다.

SELECT created_at FROM users; (구조와 데이터가 한눈에 구분됨)

 

2. 대소문자 구분 문제:

많은 DB 설정에서 테이블명이나 컬럼명의 대소문자를 구분하지 않거나, 자동으로 변환해 버립니다.

createdAt이 createdat으로 변환될 위험이 있으므로, snake_case가 가장 안전한 선택입니다.

3. 언어 중립성:

DB는 Java, Python, Node.js 등 어떤 언어에서도 접근할 수 있어야 합니다.

특정 언어의 관습(Camel)보다는 공통적인 구분자(Snake)를 사용합니다.

 

🔷 왜 JSON과 코드는 camelCase인가?

현대 웹 개발의 중심이 JavaScript(JS)에 있기 때문입니다.

 

1. JSON의 뿌리:

JSON은 'JavaScript Object Notation'의 약자입니다. JS에서 객체의 속성에 접근할 때 표준은 camelCase입니다.

2. 프론트엔드 생산성:

최신 IDE(VS Code 등)의 자동 완성 기능은 camelCase에 최적화되어 있습니다.

API가 camelCase를 내려주면 프론트엔드 개발자는 별도의 변환 없이 즉시 객체 지향적인 코드를 작성할 수 있습니다.

3. 글로벌 표준:

구글, 마이크로소프트 등 주요 테크 기업의 API 가이드는 JSON 필드에 camelCase 사용을 강력히 권장합니다.

 

🔷 핵심 과제: "누가 변환을 책임질 것인가?"

표기법이 다른 것은 문제가 아닙니다. 진짜 문제는 "그 변환을 어디서 처리하느냐"를 정하지 않았을 때 발생합니다.

 

❌ 나쁜 사례 (Anti-Pattern)

▸ DB를 Camel로 설계: SQL 가독성이 떨어지고 DB 툴과의 호환성 문제가 발생합니다.
▸ API를 Snake로 노출: 프론트엔드 코드에 user.created_at이 침투하여 JS 코드의 일관성을 해칩니다.

 

✅ 올바른 사례: 매핑 계층(ORM/DTO)의 활용

백엔드 애플리케이션의 ORM(Object-Relational Mapping)과 DTO(Data Transfer Object)가 그 완충지대 역할을 해야 합니다.

▸ DB ↔ Entity 변환:

    ORM 설정(@Column(name = "created_at"))을 통해 DB의 Snake를 코드의 Camel로 바꿉니다.

▸ Entity ↔ JSON 변환:

    DTO나 직렬화 라이브러리(Jackson, Gson 등)를 통해 최종 API 규격을 결정합니다.

 

💡 설계의 핵심 요약

표기법 변환은 단순한 '번역'이 아니라, 계층 간의 경계를 명확히 긋는 행위입니다.

이 책임을 백엔드의 매핑 계층(ORM/DTO)에 집중시키면, DB와 프론트엔드는 각자의 환경에서 가장 편한 방식으로 일할 수 있습니다.

 

4. 권장 표기법 요약

아래 표는 대부분의 현대 웹/백엔드 프로젝트에서 무리 없이 적용되는 표준 조합입니다.

영역	권장 표기법	설명
변수 / 함수	camelCase	대부분의 프로그래밍 언어에서 기본값
클래스 / 타입	PascalCase	타입임을 즉시 인식 가능
상수	UPPER_SNAKE_CASE	불변 값이라는 강한 의미 전달
DB 컬럼	snake_case	SQL 친화적, 언어 독립적
JSON 필드	camelCase	JavaScript 생태계 표준
파일 / URL / CSS	kebab-case	웹 환경에 최적화

 

 

---

※ 게시된 글 및 이미지 중 일부는 AI 도구의 도움을 받아 생성되거나 다듬어졌습니다.

반응형