변수명 짓기가 매번 막힐 때: Curioustore로 작명 시간 줄이는 법
TL;DR — 변수·컬럼·약어 이름이 떠오르지 않아 코딩이 멈추는 순간, 다른 개발자들의 실제 작명 데이터를 검색해주는 Curioustore 활용법과 좋은 네이밍 원칙을 정리했습니다.
개발을 하다 보면 로직보다 이름 짓기에서 더 오래 멈출 때가 있습니다. "사용자 마지막 로그인 시각"을 변수로 담아야 하는데 lastLoginTime이 맞는지, lastLoggedInAt이 더 자연스러운지, 아니면 recentSignInDate인지 한참을 고민하게 됩니다. 함수 하나는 5분이면 짜지만, 그 안에 들어갈 변수 세 개의 이름을 정하는 데 15분이 걸리는 경험은 거의 모든 개발자에게 익숙합니다.
이 글에서는 이런 "작명 마비" 상황을 빠르게 벗어나게 해주는 도구 Curioustore를 소개하고, 단순히 도구를 쓰는 것을 넘어 읽기 좋은 이름을 만드는 원칙까지 함께 정리합니다.
왜 변수명 짓기가 어려운가
변수명이 어려운 이유는 단순히 영어 실력 문제가 아닙니다. 좋은 이름은 다음 세 가지를 동시에 만족해야 하기 때문입니다.
- 정확성: 그 변수가 실제로 담는 값을 오해 없이 표현해야 한다.
- 간결성: 너무 길면 코드가 지저분해지고, 너무 짧으면 의미를 잃는다.
- 관습 일치: 팀과 언어 생태계에서 통용되는 패턴(camelCase, snake_case 등)을 따라야 한다.
특히 한국어로 개념은 명확한데 이를 영어 식별자로 옮기는 단계에서 막히는 경우가 많습니다. "재고 수량"은 알지만 stock, inventory, quantity 중 무엇을 쓸지, 약어로 qty를 써도 되는지가 헷갈리는 식입니다.
Curioustore가 해결하는 문제
Curioustore(https://www.curioustore.com/)는 실제 다른 개발자들이 어떤 단어를 어떤 영어 식별자로 작명했는지를 모아 검색해주는 사이트입니다. 사전이 아니라 "작명 사례 데이터베이스"라는 점이 핵심입니다.
제공하는 기능은 크게 세 가지입니다.
- 변수명 추천: 한글이나 영어 키워드를 입력하면 그에 대응하는 변수명 후보들을 보여준다.
- 컬럼명 추천: 데이터베이스 테이블 컬럼처럼 snake_case가 흔한 영역에 맞는 이름을 제안한다.
- 영어 약어 추천: 길어지기 쉬운 단어를 어떻게 줄여 쓰는지(예:
number→num) 통용 사례를 보여준다.
가장 큰 장점은 추천 수가 많은 순으로 정렬된다는 점입니다. 즉 상단에 뜨는 이름일수록 다른 개발자들이 많이 채택한 "검증된" 작명이라고 볼 수 있어, 후보 중 위쪽 것을 고르면 큰 실수를 피할 수 있습니다.
단계별 사용법
실제로 사용하는 흐름은 매우 단순합니다.
- 사이트 접속: https://www.curioustore.com/ 로 이동한다.
- 키워드 입력: 검색창에 짓고 싶은 개념을 입력한다. 한글(예: "주문 번호")이나 영어(예: "order") 모두 시도해본다.
- 결과 확인: 추천 변수명 목록이 인기순으로 나열된다.
- 상단 후보 채택: 가장 위쪽에 있는, 즉 많이 선택된 이름 중 맥락에 맞는 것을 고른다.
- 컨벤션 보정: 프로젝트 규칙(camelCase / snake_case)에 맞게 형식만 다듬어 사용한다.
실전 예시: 개념을 식별자로 바꾸기
아래는 자주 마주치는 한국어 개념을 영어 식별자로 옮길 때의 예시입니다. Curioustore에서 키워드를 검색하면 이런 식의 후보를 얻을 수 있고, 여기서 맥락에 맞는 것을 고르면 됩니다.
// 개념: "장바구니에 담긴 상품 개수"
// 후보 검색 키워드: cart, item, count
const cartItemCount = 3; // 가장 직관적 — 추천
const numberOfCartItems = 3; // 의미는 같지만 다소 장황
const cartCnt = 3; // 약어 — 팀 컨벤션이 허용할 때만
// 개념: "결제 완료 여부"
// boolean 은 is/has/can 같은 접두사를 붙이면 의도가 분명해진다
const isPaid = true; // 권장
const paymentComplete = true; // 동사/형용사가 모호
데이터베이스 컬럼이라면 같은 개념이라도 표기 규칙이 달라집니다.
-- 개념: "사용자 가입 일시"
-- 컬럼명은 snake_case 가 관례인 경우가 많다
CREATE TABLE users (
id BIGINT PRIMARY KEY,
email VARCHAR(255) NOT NULL,
created_at TIMESTAMP NOT NULL, -- 가입/생성 시각의 사실상 표준 이름
last_login_at TIMESTAMP -- "_at" 접미사로 시각임을 명시
);
이처럼 Curioustore는 "어떤 단어를 쓸까"를 빠르게 좁혀주고, 나머지 형식 보정은 프로젝트 규칙에 맞춰 직접 하면 됩니다.
좋은 변수명을 위한 추가 원칙
도구는 후보를 줄 뿐, 최종 판단은 결국 개발자의 몫입니다. 다음 원칙을 함께 적용하면 작명 품질이 올라갑니다.
- 의미 단위로 끊어 읽히게:
usrInptVal처럼 모음을 빼는 극단적 축약은 피하고,userInputValue처럼 읽히게 한다. - 타입을 이름에 녹이기: 배열은 복수형(
users), boolean은is/has접두사, 시각은_at/Time접미사처럼 규칙을 정한다. - 스코프가 좁으면 짧게: 반복문 인덱스
i처럼 수명이 짧은 변수는 짧아도 무방하다. 반대로 모듈 전역 상태는 충분히 설명적으로. - 부정형 이름 피하기:
isNotReady보다isReady를 쓰고 조건에서 부정한다. 이중 부정은 버그의 원천이다.
흔한 실수와 주의점
- 번역기 결과를 그대로 식별자로: 번역기는 자연어 문장을 줄 뿐 식별자 컨벤션을 모릅니다. 번역 → Curioustore 사례 확인 → 컨벤션 보정 순서를 권합니다.
- 인기순 1위를 무조건 채택: 추천이 많다고 해서 내 맥락에 맞는다는 보장은 없습니다.
count가 1위여도 "총합"이라면total이 더 적절할 수 있습니다. - 작명에 과몰입: 원문 글쓴이의 조언처럼, 변수명에 너무 오래 매달리지 마세요. 완벽한 이름은 없으며, 나중에 IDE의 리네임 기능으로 한 번에 바꿀 수 있습니다. 간단하고 직관적인 이름이 가장 좋은 이름입니다.
- 팀 컨벤션 무시: 아무리 좋은 이름도 팀 규칙(예:
snake_case강제)과 어긋나면 코드 리뷰에서 되돌려집니다. 사이트 추천보다 팀 합의가 우선입니다.
요약
| 상황 | 활용 방법 |
|---|---|
| 영어 단어가 안 떠오를 때 | 한글 키워드로 검색 |
| 후보가 너무 많을 때 | 인기순 상단에서 선택 |
| DB 컬럼명이 필요할 때 | 컬럼명/약어 모드 활용 |
| 최종 결정 | 팀 컨벤션 + 맥락으로 보정 |
Curioustore는 "0에서 후보를 떠올리는" 가장 비싼 단계를 대신 처리해주는 도구입니다. 사례 데이터로 출발점을 빠르게 잡고, 나머지 다듬기는 위에서 정리한 원칙으로 직접 마무리하면 작명에 쓰는 시간을 크게 줄일 수 있습니다.
AI에게 물어볼 때 (프롬프트 팁)
요즘은 변수명 작명도 ChatGPT나 Claude 같은 AI에게 맡기는 경우가 많습니다. 다만 그냥 "변수명 추천해줘"라고 하면 맥락 없는 답이 나오기 쉽습니다. 아래처럼 언어·컨벤션·맥락을 함께 주면 훨씬 정확한 결과를 얻습니다.
[프롬프트 예시 1 — 맥락 명시형]
나는 TypeScript로 이커머스 백엔드를 짜고 있어.
"사용자가 마지막으로 장바구니를 비운 시각"을 담을 변수가 필요해.
camelCase 컨벤션을 따르고, 시각 값은 "At" 접미사를 쓰는 규칙이야.
후보 3개를 추천하고 각각의 장단점을 한 줄로 설명해줘.
[프롬프트 예시 2 — 일괄 정리형]
아래 한글 개념 목록을 snake_case 데이터베이스 컬럼명으로 바꿔줘.
표 형태로 (개념 | 컬럼명 | 선택 이유) 출력해줘.
- 주문 상태
- 결제 완료 여부
- 배송 시작 일시
[프롬프트 예시 3 — 리뷰 요청형]
내가 지은 변수명들을 검토해줘: userFlag, data2, tmpList, isNotInactive.
각 이름의 문제점을 지적하고 더 나은 이름으로 고쳐줘. 부정형 이름은 긍정형으로 바꿔줘.
이렇게 역할·언어·컨벤션·출력 형식을 명확히 지정하면 AI 작명의 적중률이 눈에 띄게 올라갑니다. 좋은 프롬프트는 좋은 변수명과 닮았습니다. 모호함을 줄이고 의도를 정확히 전달하는 것이 핵심입니다. 프롬프트 자체를 더 잘 다듬고 싶다면 Prompt Architect의 프롬프트 분석기로 작성한 질문의 명확성을 점검해볼 수 있습니다.