웹 개발에 한글 변수를 사용해 보신 적이 있나요?
목차 펼치기
머리말
머리말
printf, Hello World, foo, bar, function… 개발을 처음 배울 때면 자연스럽게 영어를 사용하게 돼요. 한글은 주석으로만 존재할 뿐인데, 왜 한글로 코딩하진 않을까요? 기본 문법이야 그렇다쳐도 개발자가 자유롭게 지정하는 변수명에는 한글을 사용할 수 있지 않을까요? 개발 환경마다 다를 수 있겠지만 적어도 현대의 JavaScript에서는 한글 변수를 사용할 수 있어요. 다만 영어로 다져진 멘탈 모델에서 한글은 어색한 느낌이 많이 들 수 있을 거예요. 이 글에서는 한글 변수 사용의 장, 단점을 살펴보며 한글 변수로 개발하는 것에 대해 이야기해보려고해요.
이런 상황이 있지 않나요?
이런 상황이 있지 않나요?
개발을 하다 보면 복잡한 비즈니스 도메인 용어를 사용해야 할 때가 많아요. 그럴 때면 영어로 어떻게 번역을 해야 할 지 많은 고민을 하게 돼요. 쉬운 단어여도 문화에 따른 뉘앙스 차이를 고려해야하는 경우도 있기 때문에 더욱 난감해질 수 있어요.
예전에는 영단어로 번역하지 않고 독음을 그대로 스펠링으로 변환해서 사용하기도 했는데, 예를 들면 ‘주민’을 ‘jumin’, 전세를 ‘jeonse’라고 하는 식이에요. 익숙해지지 않는 이상 쉽게 읽히지 않는 방식이라고 생각해요.
심지어는 팀 내에 용어가 정리되어있지 않거나, 규칙이 존재하지 않는다면 서버와 프론트 간 번역이 다르거나 작업자마다도 달라질 수 있어요. 만약 이럴 때 그냥 한글 명칭을 그대로 사용해서 개발하면 훨씬 명확하게 사용할 수 있지 않을까요?
한글 변수를 사용했을 때의 장점
한글 변수를 사용했을 때의 장점
도메인 용어의 통일성
기획/UI/디자인/코드 간 용어를 일관되게 유지할 수 있어요.
의사소통 시 혼란을 줄일 수 있어요.
높은 가독성
한국어 네이티브 개발자는 직관적인 이 해가 가능해요.
복잡한 비즈니스 로직을 설명하기 쉬워져요.
명확한 의미 전달
애매한 영어 번역으로 인한 의미 손실을 방지할 수 있어요.
도메인 전문성을 코드에 더 잘 반영할 수 있어요.
한글 변수를 사용했을 때의 단점
한글 변수를 사용했을 때의 단점
코드 스타일링의 제약
대/소문자 구분이 불가능해 일반적인 네이밍 컨벤션 적용이 어려워요.
camelCase, PascalCase 등의 표기법을 사용할 수 없어 용도를 구분하기 어려워요.
기술적 제약
유니코드를 지원하는 개발 언어에서만 사용할 수 있어요.
일부 도구나 라이브러리에서 한글 지원이 미흡할 수 있어요.
협업 관련 이슈
한글을 모르는 외국인 개발자와 협업이 어려워요.
오픈소스 기여가 제한될 수 있어요.
개발 문화적 이슈
기존 개발자 멘탈 모델과 충돌할 수 있어요.
코드 리뷰나 디버깅 시 불편함이 있을 수 있어요.
한글 변수명을 사용하면 초기 번들 크기는 약간 커질 수 있지만, 미니파이 과정을 거친다면 영어 변수와 동일하게 짧은 변수명으로 변환될 수 있기 때문에 순서 항목에 추가하진 않았어요.
나만의 한글 변수 사용 원칙
나만의 한글 변수 사용 원칙
단점도 명확히 존재하는 만큼, 저는 한글 변수를 사용할 때에 대한 원칙을 세워서 그 장점만을 극대화할 수 있는 상황에서 활용해봤어요. 실제로 도메인 관련 데이터를 보여줘야하는 테이블이나 상세 화면에서 매우 유용하게 사용할 수 있었어요. 기존에 영어로 번역해서 작업했을 때보다 작업의 흐름이 간결하고 명확해질 수 있었어요.
외국인과 협업 가능성이 존재하는가?
가능성이 존재한다면 한글 변수는 고려하지 않았을거예요.
변수의 사용 범위가 제한되어 있는가?
API와 통신하거나 전역적으로 사용되는 등 여러 곳에서 참조하는 경우에는 사용하지 않았어요.
저는 외부 의존성 없이 UI와 가까이 위치하여 한 곳에서만 관리되는 경우에 사용했어요.
한글변수만 사용할 경우 표기법에 따라 용도를 구분하기 어려우므로, ‘한글 변수는 전시에만 사용된다.’ 라는 표기 규칙을 세운거예요.
영어로 번역하기 어려운 도메인 용어인가?
사실 이 원칙은 선택사항이에요.