🚨 주의: 이 포스트는 민감한 내용을 포함 할 수도 있습니다.

세상에서 가장 어려운 일이다. 철학관이나 작명소가 돈을 버는 이유기도 하다. 📎 프로그래머에게 가장 어려운 일이 무엇인지 조사하는 설문에서도 1위는 '변수 이름 짓기'이라는 결과가 사람들을 웃게 했었다.

오늘은 가볍운 마음으로 변수의 '네이밍'과 '타입'에 관련해서 말 해보려고 한다. 회사에서 일하면서 날 힘들게 했던 변수 이름 4가지가 있다.

isRedisServerOff

처음 이 변수 이름을 봤을 때 나의 정신은 멍해 졌다. 여러분은 어떤 생각이 드는가? 결론부터 말하자면 Boolean Type의 변수에서 부정형을 쓰는건 좋지 않다.

레디스 서버가 꺼져있는지 켜져 있는지 알아야 하는 상황에서 '레디스 서버 안 켜져 있지?"라고 물었을 때 "네"라고 대답 했다고 치자. "네"라는 긍정적인 대답을 했지만 실제로는 False의 의미를 갖게 된다.

반면에 '레디스 서버가 켜졌어?'라는 질문에 누군가 '네'라고 대답하면 훨씬 더 직관적이다. 아, 레디스 서버는 지금 켜져있구나.

나는 한가지 더 의문이 생겼다. 아니, 이건 영어잖아. 프로그래밍 언어는 영어고 이 변수 이름도 영어니까 한국어와는 반대로 생각해야 하는거 아닌가?

그렇다 한국어와 영어는 부정 의문문에 대한 대답이 완벽하게 서로 완벽하게 거꾸로다. 예를들면 아래와 같다.

👨🏻 너 밥 안 먹었지?
👩🏻‍🦰 응

한국어는 밥을 안 먹었다는 의미가 된다. 그러나 영어는.

👨🏻 Don't you have breakfast?
👩🏻‍🦰 Yes

영어는 완전히 반대다. 여기서 Yes라고 대답하면 밥을 먹었다는 의미가 된다! 자 그럼 이제 여러분은 아래 변수의 의미를 추측 해 보자.

bool isRedisServerOff = true

결국 나는 짜증나서 그냥 변수를 True로 만들어 버린 다음에 직접 코드를 실행해서 서버가 켜져 있는지 꺼져 있는지 확인했다. 나는 이 변수 이름을 봤을 때 아래의 대화가 떠올랐다.

철수 : "영희야 어제 뭐 했어?"
영희 : "응 ㅋㅋ"

개발자 : "레디스야 지금 뭐하고 있어?"
레디스 : "True"
개발자 : "???"

relate_entry

일단 바로 보이는 문제 하나부터 짚고 넘어 가자. relate entry보다는 related entry가 좀 더 자연스러울 것이다.

이 변수를 본건 어떤 REST API의 http response였다. 구조는 아래와 같았다.

{
  "relate_entry": ["jpg", "png", "gif"]
}

relate_entry는 '단수형'의 변수 이름을 갖고 있으면서 실제로는 Array Type의 값을 가지고 있다. 따라서 아래와 같이 하는게 더 자연스러울 것이다.

{
  "related_entries": ["jpg", "png", "gif"]
}

이게 대체 무슨 차이냐고 면박을 주는 개발자도 많았다. 심하게는 꼭 문법이나 맞춤법을 따지고 들면서 잘난체 하기 좋아하는 놈이 있다고 쏘아 붙이던 사람도 있었다.

이렇게만 봐서는 별 중요성이 안 느껴질 수도 있다. 여러분이 만약 이 response를 받아서 처리 해야하는 개발자가 됐다고 가정하자.

relate_entry라는 변수명을 보고 이거 결과 값이 뭘까 짐작하다가 브라우저를 켜서 GET 요청을 한 번 날려본 뒤 Ctrl + F로 해당 key를 찾아 유심히 살펴 보기 시작한다. 이제 알겠다, 타입은 Array였고 반복문을 작성하기 시작한다.

그러나 변수 이름이 related_entries가 되면 단어 자체가 '복수형'이니 쉽게 for문을 먼저 작성하고 코딩을 진행 할 수 있게 해준다. 결과가 뭐든 간에 JSON Array일테니 일단 for를 치고 본다.

relate_entry라는 이름을 보고 Object로 취급하고 코드를 썼다가 Runtime Error가 나서 갸우뚱 했던 기억이 난다. 결국 변수 이름은 내가 IDE를 접고 브라우저를 켠 다음 Reference 문서를 한 번더 보게 하느냐, 아니면 곧 바로 진행하느냐의 차이를 불러 일으키게 된다. 나는 이러는 것도 귀찮으므로 엄청난 차이라고 생각한다.

🙃 변수 이름 자체로 Type을 표현하려고 movieList 라던지 movieArray, movieObject 처럼 표기하는 방법도 있다. 그러나 잘 쓰이지는 않는 것 같다.

tits

아마 지금까지 본 변수 이름 중에 가장 충격적인 이름이 아닐까? 앞으로도 이 정도의 변수 이름은 볼 수 없을 것이다. Tits은 '가슴'이라는 뜻으로 쓰이는 단어이다. 아니, 다시 솔직하게 말하겠다 가슴이 아니라 '젖탱이', '젖꼭지' 정도로 해석하는게 더 젖절하다. shit 처럼 많이 쓰이는 속어지만 결코 교양있는 표현은 아니다. 이 충격적인 변수 이름에 대해 부서 곳곳을 수소문 해 본 결과 이들의 의도는 'Titles'을 줄여서 Tits이라고 쓴 것이었다.

💡 정 못 미더우면 Google에 'tits'를 이미지 검색 해 보자. 성인 인증이 필요하다.

나는 이것 외에도 Anchor를 줄여서 anc로, Total을 tot이라고 줄여서 쓰는 것을 보았다. 심지어 Python으로 만들어진 서버였다! 거짓말 안 하고 이 모든 걸 섞어서 tit_tot_anc라던지 anc_tot, tot_size_tit 같은 기괴한 변수 이름들이 난무 하는걸 두 눈으로 보았다.

tot_size_anc = 10
tits = "D Cup"
tits += "D Cup plus"

temp = CallDestroyeerFromBasement(tit_tot, anc_tit)

tit_tot = temp

"야! 그럼 index는 왜 idx로 줄이고 count는 cnt라고 줄이겠냐! 😠"

그런 것들은 줄여도 영어의 모음에 해당하는 a, e, i, o, u를 생략하지 개발자 좋을대로 줄이는게 아니다. title은 ttl이 됐어야 그나마 말이 된다. 개인적으로 index나 count는 줄이지 않아도 된다고 생각한다. 이미 충분히 5글자 정도의 짧은 단어기 때문이다. 다만 반복문을 사용할 때 아래와 같이 줄이는 건 또 나름 즐겨 쓴다. ㅋㅋ.

for i in images:
	pass
    
for e in array: # e는 element
	pass

"그렇게 이상하면 니가 저기 A부서랑 B, C 다 가서 바꾸자고 해 그럼. 말도 안 되는 소리 하고 있어. 😡"

한국인들이 tits이라는 단어에 대해서 잘 모르는건 썩 이해가 간다. Netflix의 드라마 중에서도 High Teen 장르를 즐기면서 자막을 유심히 들여다 봐야만 좀 들었을 단어다. 학교에서 정규 교과 과정을 모범적으로 밟으면 이런 단어를 접할 기회는 좀 처럼 없을 것이다. 영어를 모르는건 이상하지 않다. 그러나 상대가 아는걸 이상한 것으로 취급하지 말자.

😢 tits의 번역에 대해서 불쾌하다는 신고를 받아 추가합니다.

제가 뭐 tits뜻을 지어냈거나 또는 tits는 그런 뜻이니까 적극 사용을 권장하는 것이 아니고 오히려 사용을 자제하자는 취지에서 쓴 글입니다.

그런 뜻을 아는 니가 이상하다는 지적도 있었지만 tits는 영미권에서 shit 만큼이나 많이 쓰는 속어입니다.

tit, tits는 국내 유명 웹 사이트에서 개발자 도구를 열어 보면 HTML/CSS 소스에서 많이 보이는 class 이름이기도 합니다. title을 tit으로 줄이는 것이 매우 오래된 관행처럼 보이긴하나 조금만 영어를 아는 사람이었더라면 저 처럼 깜짝 놀랄만한 변수 이름이었습니다. 여러분이 제 글을 읽는 것 처럼요. 설마 이런다고 또 "나는 조금도 영어를 모른다는 말이냐?"라고 반문하시는 분은 없겠죠.

maemul

마지막으로 소개할 변수 이름은 '한글 로마자 표기식' 변수 이름이다. 사내에서 부동산 관련 서비스를 하는 팀의 코드를 살펴보고 있었다.

int maemul = 10;
double pyeung_su = 11;
String type = "One room";

두 눈을 비비고 다시 봐도 변수 이름은 그대로 였다. 부동산 관련 서비스기 때문에 '매물', '평수'와 같은 것들이 전부 한글을 영어로 옮겨 적은 것들이었다. 매물은 'maemul'로 '평수'는 'pyeung_su'로...

이 괴상한 방식의 변수 이름 짓기는 프로젝트 전체에 걸쳐서 쓰이고 있었고 나름대로 부동산 관련 전문 영단어가 오히려 저렇게 쓰는 것 보다 더 어렵겠다는 이해를 해 보려고 했지만 아래 코드에서 주저 앉고야 말았다.

String type = "DanDokJuTak";

이 정도 쯤은 그냥 building 이라는 class 또는 struct를 하나 만들면 되지 않았을까? 귀찮긴 하지만 모든 코드의 변수가 모조리 저런식이니 오히려 영어보다 더 집중해서 "단...독...주...택.... 아 단독 주택!"이라며 수수께끼 풀듯이 진행해야 했다. 너무 일에만 몰두하지말고 좀 웃으라는 배려였을까?

회의에서 이것에 대해 의문을 던졌다가 "그럼 단독 주택이 영어로 뭔데요?"라는 핀잔을 들은 적이 있다. 나는 그냥 가볍게 'solo'라고 하면 되지 않느냐고 답했다. 굳이 어려운 영어를 찾을 필요도 없고 그것을 쓸 이유도 없다. 꽉 막힌채로 '다세대 주택'이 영어로 뭐지?라며 구글에 '다세대 주택 영어로'이런걸 검색 해선 안된다. 간명하게 그냥 'apart', 'villa' 정도면 충분 할 것이다.

📙 구글에 '다세대 주택'을 영어로 번역한 결과를 보면 'Multi-family house'라고 나오는데 이건 도저히 자연스럽지가 않다. 변수 이름으로 쓸 수도 없다. 내가 아는 한 영미권에서 이런 단어를 들어 본 적은 단 한 번도 없다.

영어를 어렵게 생각해서도 안되고 꼭 완벽하게 올바른 영단어를 쓸 필요도 없다. 물론 부동산 서비스의 특성상 건축법에서 규정하는 건물의 용도에 대해 따지기 위해서 이것이 주거용인지 업무용인지를 잘 구분 할 수 있는 좋은 변수 이름을 찾아야 하는데 법리를 고려하며 naming을 하는 것은 쉬운일이 아니다.

그러나 앞서 말한 '단독 주택'과 같은 사례는 간단한 어휘로 대체 할 수 있다. 'solo'라는 단어는 우리 모두 흔하게 일상에서 접하는 것이고 단 4글자에 불과하며 그 뜻도 알기 쉽다. 듣고나면 정말 쉬운 단어이지 않는가? 꼭 영어를 어마어마 하게 잘 해야만, 영미권에서 native와 몇년을 살아야만 이런 어휘력을 구사할 수 있는 것은 아니지 않는가? 어떤 획기적인 신개념 단어를 발견 해 낸 것도 아니다.

🤠 "개발자는 '그렇게까지' 영어 잘 할 필욘 없어 ㅋㅋ"

잘 해야 한다. 개발자가 아니라 자신이 전문적인 직업을 가지고 매일의 일에 종사하는 자부심이 있는 사람이라면 영어든 뭐든 못해서는 결코 안 된다. 특히 30, 40대 개발자들이 이 글을 보고 있다면 주니어에게 이런 소리 좀 안 했으면 좋겠다.

학생들이 "영어 잘 해야해요?"라는 질문을 하면 개발자들은 그저 논문을 읽거나 스택 오버 플로우의 질문/답변을 이해 할 수준의 영어만 구사하면 누구나 개발을 할 수 있다고 말하고 있다. 어차피 회사에서 하는 일이 늘 거기서 거기라면 썩 말이 된다.

🤔 적어도 이런 말 하는 사람 치곤 영어 잘 하는 사람 못 봤다.

어째서 '못해도 돼' 같은 냉소주의가 이 첨단 SW 개발자들에게 자리 잡게 되었을까? 할 줄 아는건데 왜 굳이 하면 안 되는 걸까? 내 아이가 바둑을 잘 두는 천부적인 재능을 타고 났지만 어차피 알파고가 최강이니 그딴거 굳이 배울 필요가 없는걸까? 내 딸이 그림을 잘 그리는데 어차피 카메라가 훨씬 똑같이 담아 내니까 그런거 굳이 할 필요가 없는걸까?

여러분은 어떤가? AI가 통/번역을 지배하게 되는 그 순간이 오면 외국어 배울 필요 없는 건가? 그 AI는 SW 개발자인 니가, 우리가 만든다는 점을 다시 한 번 생각 해 보자. "나는 그런 AI 안 만들 건데요?"라고 말 할거라면 할 말 없다. 그 정도면 영어 못 해도 된다.

'영어'라는 언어가 결코 우리 개발자들이 밥 먹고 사는 정도로만 익히면 충분하다고 생각하지 말자. 영어를 잘 할 수 있으면 잘 하면 되고 뭔가 잘못된거 같으면 다음에는 더 잘하면 된다.

"개발자가 그렇게까지 영어를 그렇게 잘 할 필욘 없어"

"아, 나만 그런게 아니라 전부 그렇게 하고 있잖아"

"왜 굳이?? 그런걸 아는 걔가 이상한거 아닐까?"