한국의 단위인 평을 변수로 만들 때 어떻게 해야할까요?
Pyeong? 가끔 개발을 하다가 이런 일을 만나게 되면 난감할 때가 있습니다. 직방 프론트엔드 팀에서는 종종 한글로 코딩을 할 때가 있습니다. 이번에 진행하게 된 새 프로젝트에서 컨벤션을 어떻게 할까 고민하던 중에 한글을 어디까지 사용해야 할지에 대한 이야기가 나왔습니다. 정답을 찾지는 못했지만, 서로 많은 의견을 나누었고 한글 코딩에 대해서 다시 한번 생각할 수 있었던 기회인 것 같아 글을 작성합니다.
한글코딩이란?
여러가지 정의가 있겠지만, 이 글에선 아래 코드와 같이 변수와 함수 등 코드 내 한글 식별자를 사용하는 것으로 한정하여 다루도록 하겠습니다.
function 더하기(숫자1, 숫자2) {
return 숫자1 + 숫자2
}
const 열 = 10
const 이십 = 20const 합 = 더하기(열,이십) // 30
안 되는 줄 알고 쓰지 않는 분도 있을 것이고, 되는 것은 알지만 어떤 문제가 발생 할 지 알 수 없어서 쓰지 않는 분도 있을 것입니다.
물론 한글 코딩을 지원하지 않는 언어도 있겠지만 현재 대부분의 에디터 및 컴파일러 등은 유니코드를 지원하기 때문에 식별자를 한글로 쓸 수 있습니다. 하지만 우리는 코드를 작성할 때 거의 대부분 영어로 작성합니다. 예약어들이 대부분 영어라서 굳이 한영키를 바꿔가며 개발하기 번거롭기도 하고, 혹시라도 운영체제나 컴파일러 등이 오작동을 일으킬까봐 걱정되기 때문이기도 한 것 같습니다.
저는 어렸을 때 어떤 게임을 설치했었는데, 며칠동안 해봐도 게임을 실행할 수가 없었던 적이 있었습니다. 나중에 알고보니 Window의 user를 한글 이름으로 설정하면 동작하지 않더라구요. 그 때의 허무함이란.. 저도 개발을 배우기 전부터 막연하게 컴퓨터 관련한건 꼭 영어로 해야겠다는 고정관념이 심어졌던 것 같습니다.
그런데 직방에 입사하니까 오히려 프로젝트에서 한글 식별자를 쓰는 곳이 곳곳에 보였습니다. 나중에 알고 봤더니 DB컬럼도 한글을 사용하는 곳도 있었습니다. 처음엔 생소했고, 이게 되는구나! 하고 느꼈지만 저도 어느새 금방 적응하고 영어로 표현하기에 까다로운 단어들(순 우리말이나 한자어)은 한글을 사용하기도 했습니다. 저는 한글을 평소에 사랑(?)하는지라 꽤 괜찮은 경험이었습니다.
한글 코딩, 되는건 알겠는데 그럼 다 한글로 해도 돼?
이번에 진행하게 된 프로젝트에서 컨벤션에 대한 이야기 중, ‘한글을 어디까지 사용해야 할까?’ 에 대한 이야기가 나왔습니다. 저는 다들 저랑 비슷하게 생각하는 줄 알았는데 크게 세가지 정도의 의견이 있었습니다.
진보파 -왜 안 쓰는거야? 훨씬 편한데!
- 우리는 한국인이다.
직방은 현재 글로벌 서비스가 아니며, 한국인에겐 한국어가 당연히 훨씬 편합니다. 처음에 느끼는 약간의 위화감을 없애고 나면, 한글 식별자를 볼 때 가독성이 더 좋을 때가 꽤 많습니다. - 구분을 gubun으로 쓰는 일을 막자
가끔 영어로 표현하기 애매한 단어가 있습니다. 구분, 평 등을 gubun, pyeong 등으로 쓰는 것보단, 한글로 쓰는게 훨씬 가독성이 좋지 않을까요?
보수파 -오히려 한글이 섞이면 불편해!
const sum = (a,b) => a+b
const 합 = sum(1,2) // 3- 쓸 때마다 한영키를 바꿔야 하는게 불편하다
사실 한글을 칠 때 마다 한/영키를 누르는 것은 또 하나의 귀차니즘이 됩니다. 귀찮은걸 싫어하는 개발자들에게 한글을 치려고 할 때마다 키를 하나 더 누르라고 하는 것은 재앙과도 같은 일입니다. - 영어로 모든 것을 코딩 할 수는 있지만, 한글로 모든 것을 코딩 할 수는 없다.
맞는 말입니다. 기본적으로 예약어들이나 사용하는 환경의 api들은 당연히 영어이고 이 경우엔 오히려 헷갈리게 되는 일이 생길 수 있습니다.
중도파 -한글을 쓸 때의 이점은 분명히 있지만, 무분별하게 쓰진 말자!
- 영어로 표현하면 의미가 이상해져!
직방에는 안심피드백이란 제도가 있는데, 이걸 영어로 하면 reliefFeedback이 됩니다. 아무 지식 없이 이 단어를 봤을 때는 어떤 의미인지 알 수가 없습니다. 차라리 기획서에 적힌대로 ‘안심피드백’이라고 써져 있으면 헷갈리는 수고를 덜 수 있습니다. - 최소한 한영 혼용은 막고, 영어로 쓸 수 있는걸 굳이 한글로 쓸 필요는 없지 않을까?
적어도 ‘안심Feedback’은 한영키를 누르기도 짜증나고, 좋지 않습니다. 최소한 한 식별자 안에선 통일성은 있어야합니다.
위와 같은 세가지 정도의 의견이 있었고, 어쨌든 한글로 표현하기 훨씬 쉬운 용어들이 많이 있었기 때문에, 중도파의 의견에 따라 한글을 사용할 수 있지만 서로 어느정도의 기준을 맞추기로 했습니다.
한글을 쓰기로 한 이상 처음엔 모두가 확실하게 알 수 있는 기준을 맞추면 좋겠다고 생각하여 아래의 두가지 의견이 나왔는데, 결과적으로는 둘 다 쉽지 않아 포기하게 되었습니다.
용어 사전을 만드는 것은 어떨까?
처음엔 한글 용어 사전을 만드는 것은 어떨까? 라는 이야기가 나왔습니다. 하지만 용어 사전을 만드는데는 두가지 문제가 있었습니다.
- 큰 프로젝트도 아닌데, 사전 만드는 시간이 더 걸린다.
- 나중에 관리 할 수 있을까?
우선 관리 이슈가 컸고, 모두가 만족할 수 있는 용어를 정하는데는 시간이 너무 많이 걸릴 것으로 예상 되었기 때문에 사전은 사용하지 않기로 했습니다.
영어에 없는 단어만 한글로 하는건 어떨까?
명확한 기준이긴 하지만, 이걸 굳이 영어로..? 라는 느낌의 단어들이 존재하는 것을 확인하고 포기했습니다.
아까 위의 예시에서 ‘건폐율 / 용적률’을 예시로 들었는데, 저는 회의하면서 이게 영어로 어딨어~ 라고 생각했는데 찾아보니까 있더라구요…
용적률 — Floor area Ratio
건폐율 — Building Coverage Ratio
한국어로 해도 어려운 이 단어를 굳이 영어로 해야할 필요가 있을까요? 이런 류의 어려운 단어가 나오면 다른 사람은 또 영어로 검색하고 다시 그걸 한국어로 해야하는데, 이건 한영키를 한번 더 누르는 것보다도 더한 고통이라고 생각되었습니다.
결국, 한글로 써야하는 기준을 명확하게 규정하는 것은 효율과, 기준의 모호함 속에서 어렵다 판단하게 되었습니다. 하지만 이렇게 회의를 하면서 서로 어느정도가 적당한 기준인지는 러프하게나마 느낄 수 있었고 이렇게 함께 생각한 내용을 바탕으로 아래와 같은 결론을 내렸습니다.
일반적으로 쓰는 영어단어가 떠오르지 않는 다면 한글로 쓰자
그 외에는 모두 영어!
개인의 판단에 맡기는 것이지만, 함께 이야기를 한번하고 나니 서로가 평소에 생각하던 기준보다는 훨씬 더 명확해짐을 느낄 수 있었고, 후에 프로젝트를 진행 할 때도 부드럽게 진행됨을 느낄 수 있었습니다.
정 어려운 단어는 한글로 써보니 쓸데없이 변수명에 고민하는 시간을 많이 줄일 수 있었고, 다른 사람이 볼 때도 좀 더 이해가 빠른 것을 느낄 수 있었습니다. 한국의 단위인 ‘평’을 굳이 Pyeong로 쓰고 읽는 것보다는 훨씬 나은 경험을 할 수 있었고, 다른 사람의 코드를 볼 때도 기획서에서 써진 어려운 용어가 영어로 어떻게 되는지 헷갈려하지 않아도 되었습니다. 이런 부분에선 많은 이득을 봤던 것 같습니다.
개발하는 도메인이 한국적이라서 영어로만 코딩하기 어렵다면, 한글을 써보는건 어떨까요? 좋은 선택이 될 수 있습니다!
번외
회의를 마치고 팀원들과 한글코딩에 대해 같이 이야기를 했었는데, 한글 코딩이 불편하다고 느끼는 포인트 ‘초성만 쳤을 때 자동완성이 되지 않는다’는 이야기가 나왔었습니다.
const 한글 = () => ...위와 같이 했을 때 ‘ㅎ’만 쳤을 때도 자동완성이 되면 한글 코딩을 할 때도 좀 더 편할 것 같은데, 현재 VS Code에선 지원하지 않더라구요. 그래서 그날 저녁에 간단히 extension을 만들었습니다. 사실 크게 도움이 되는지는 모르겠지만, 구현할 수는 있더라구요! VS Code나 다른 IDE에서도 공식적으로 지원해줬으면 좋겠습니다.
