개발자 영어 이름 짓기: 명사·동사와 camelCase·snake_case 구분

코드를 읽다가 UserAccount, userAccount, user_account가 한꺼번에 나오면 세 단어처럼 느껴질 수 있다. 하지만 셋은 모두 user account라는 같은 영어 구절에서 출발한다. 달라진 것은 무엇의 이름인지와 어떤 표기 규칙으로 붙였는지다.

개발자 영어 이름은 두 단계로 생각하면 덜 헷갈린다. 먼저 클래스인지 메서드인지 보고 명사와 동사 중 알맞은 뜻을 고른다. 그다음 프로젝트의 규칙에 맞춰 대문자나 밑줄을 적용한다. 뜻보다 모양부터 고르면 Manager, Data, Process처럼 그럴듯하지만 역할이 흐린 이름이 남기 쉽다.

클래스는 명사, 메서드는 동사라고 외우면 충분할까?

좋은 출발점은 다음 한 줄이다.

UserAccount는 사용자 계정이라는 대상을 가리킨다. loadUser()는 사용자를 불러오는 행동을 가리킨다. isActive는 활성 상태인지 묻는다. 이름을 소리 내 읽었을 때 명사는 대상처럼, 동사는 행동처럼 들리면 코드의 역할도 빠르게 드러난다.

물론 모든 이름을 사전 문법에 억지로 맞출 필요는 없다. 이벤트 처리 메서드인 onClick()은 '클릭 시점에'라는 관용적인 이름이고, 값을 변환하는 toString()은 to로 시작한다. 중요한 것은 문법 시험이 아니라 이름만으로 책임을 예측할 수 있게 하는 것이다.

아래 그림은 이 순서를 요약한다. 왼쪽에서 이름의 의미를 정한 뒤 오른쪽에서 프로젝트가 선택한 모양을 적용한다.

왼쪽은 이름의 역할을 고르는 단계이고, 오른쪽은 같은 뜻을 프로젝트 표기 규칙에 맞추는 단계다. 모양을 고르기 전에 대상과 행동을 먼저 정하는 순서를 기억하면 된다.

UpperCamelCase와 lowerCamelCase는 무엇이 다를까?

camel case는 여러 단어를 공백 없이 붙이고 단어의 시작을 대문자로 구분하는 계열을 말한다. 첫 글자까지 대문자인지에 따라 두 형태로 나누면 기억하기 쉽다.

UpperCamelCase는 흔히 PascalCase라고도 부른다. 이름이 두 개라 처음에는 새로운 규칙처럼 보이지만 모양은 같다. 반면 lowerCamelCase는 첫 단어만 소문자로 시작한다.

언어마다 관례가 다르다. Google Java Style Guide는 클래스에 UpperCamelCase, 메서드와 상수가 아닌 필드에 lowerCamelCase, 상수에 UPPER_SNAKE_CASE를 사용한다. Python의 PEP 8은 클래스에 CapWords를, 함수와 변수에는 밑줄로 단어를 나눈 소문자 이름을 권한다.

따라서 camelCase가 맞나, snake_case가 맞나의 답은 하나가 아니다. 같은 저장소 안에서는 언어의 공식 관례, 프레임워크 규칙, 이미 합의한 코드 스타일 순서로 확인해야 한다. Java 파일에 Python 관례를 섞거나, 새 취향을 이유로 기존 모듈의 이름을 절반만 바꾸면 통일보다 혼란이 먼저 온다.

이름의 뜻은 어떻게 고르면 좋을까?

표기법이 맞아도 뜻이 흐리면 읽기 어렵다. processData()는 문법과 camel case를 모두 지켰지만 어떤 데이터를 어떻게 처리하는지 알 수 없다. 실제 행동을 한 단계 더 구체적으로 적으면 이름이 설명이 된다.

길다고 무조건 좋은 것도 아니다. loadUserByIdFromPrimaryDatabase()처럼 구현 위치까지 이름에 박아 넣으면 저장소가 바뀔 때 이름이 거짓말을 한다. 호출자가 알아야 할 행동과 결과까지만 드러내고, 내부 구현은 본문 코드에 맡기는 편이 낫다.

불리언은 질문처럼 읽는다

불리언 이름은 is, has, can을 앞에 붙이면 뜻을 기억하기 쉽다.

• isVisible: 지금 보이는 상태인가?
• hasPermission: 필요한 권한을 가지고 있는가?
• canRetry: 다시 시도할 수 있는가?

세 접두어는 비슷해 보여도 질문이 다르다. is는 상태, has는 보유, can은 가능 여부에 가깝다. checkPermission()이 값을 반환하는지 예외를 내는지 모호하다면 hasPermission()처럼 결과의 성격을 이름에 담는 편이 읽기 쉽다.

prefix와 suffix는 단어의 앞뒤 단서다

prefix는 앞에 붙는 부분, suffix는 뒤에 붙는 부분이다. 개발 용어에서는 단어를 외울 때도, 이름의 역할을 읽을 때도 유용하다.

• disconnect의 dis-: 연결을 끊거나 반대 상태로 만든다는 단서
• restart의 re-: 다시 한다는 단서
• nullable의 -able: 가능하다는 단서
• UserRepository의 Repository: 저장소 책임이라는 단서

다만 접미사만 붙였다고 책임이 자동으로 선명해지지는 않는다. Helper, Util, Manager가 계속 커진다면 이름보다 클래스가 너무 많은 역할을 맡았는지 먼저 살펴야 한다.

헝가리안 표기법은 언제 읽어야 할까?

헝가리안 표기법은 이름 앞에 타입이나 용도를 나타내는 짧은 접두어를 붙이는 방식이다. 예를 들어 오래된 코드에서 strName, m_user, g_count 같은 이름을 만날 수 있다.

현대의 정적 분석과 IDE는 타입과 범위를 직접 보여 주므로 새 코드에 이런 접두어를 무조건 추가할 이유는 적다. 접두어와 실제 타입이 달라지면 오히려 잘못된 정보를 준다. 다만 기존 프로젝트가 일관되게 사용하거나 특정 플랫폼의 규칙이 요구한다면, 개인 취향으로 섞어 없애기 전에 팀의 명명 규칙부터 확인해야 한다.

암기할 때는 '헝가리안 표기법을 써야 한다'가 아니라 이름 앞의 짧은 글자가 타입·범위·용도를 나타낼 수 있다 정도로 기억하면 충분하다.

이름을 정할 때 무엇부터 확인해야 할까?

새 이름을 붙이거나 기존 이름을 검토할 때 다음 순서면 대부분의 혼란을 줄일 수 있다.

1. 이름의 대상이 클래스, 메서드, 값 중 무엇인지 정한다.
2. 클래스는 명사, 행동은 동사, 불리언은 질문처럼 읽히는지 확인한다.
3. 저장소와 언어가 사용하는 표기법을 확인한다.
4. 이름이 호출자에게 필요한 책임과 결과를 드러내는지 본다.
5. 타입·저장소·구현 방법처럼 바뀔 세부사항을 과하게 박아 넣지 않는다.

코드 리뷰에서 이름이 막히면 철자부터 고치기보다 '이 클래스는 무엇이고, 이 메서드는 무엇을 하는가?'를 먼저 묻는 편이 빠르다. 답이 한 문장으로 나오지 않으면 이름 문제가 아니라 책임이 섞인 설계 문제일 수도 있다.

핵심 요약

개발자 영어 이름은 의미를 먼저 고르고 표기법을 나중에 적용하면 쉽다. 클래스와 타입은 명사, 메서드는 동사, 불리언은 is·has·can으로 시작하는 질문처럼 읽는다. 그다음 Java의 UpperCamelCase·lowerCamelCase, Python의 snake_case처럼 언어와 저장소의 규칙에 맞춘다. 모양이 정확해도 책임이 흐린 이름은 좋은 이름이 아니므로, 코드가 무엇이고 무엇을 하는지부터 한 문장으로 설명해 보자.

표를 덮고 사용자 계정을 불러올 수 있는가?를 이름으로 바꿔 보자. 대상은 UserAccount, 행동은 loadUser(), 가능 여부는 canLoadUser()처럼 역할에 따라 달라진다. 같은 단어를 명사·동사·질문으로 바꿔 보는 것이 표기법 이름만 반복하는 것보다 오래 남는다.