6. 쓰다가 마는 건 용납하지 못한다

---

Shorthand

 

이 글은 솔직히 시작부터 신난다.

그 이유 많 사람 해 ㅋ

 

 

 

아. 읽었는가.

조금 짜증나지만 뭘 말하는 지 대략 알 것 같다.

사실 사람들에게 이런 기분을 느끼게 해주는 걸 즐기는 타입은 아니다.

내가 겪은 고통을 돌려줄 때 조금 기쁜 타입이다.

 

 

내가 손가락만 빨고 있을 시절에는 글자 하나 하나가 비용을 차지하기 때문에,

이렇게 극단적으로 글자 길이를 줄이려는 노력을 했었다고 한다.

 

솔직히 공감과 이해가 하나도 안된다.

조금 공감해보자면 - 지금은 이렇게 글자 길이를 줄이는 시대는 이미 멀리 지났다.

솔직해지자면 - 글자 크기 줄여가며 저장 용량을 줄이는 것보다

글자 자체를 누구나 쉽게 이해하고 표현하여 업무 시간을 효율적으로 쓰는 것이 몇 백 배 낫다.

 

 

 

 

 

 

---

Initials of word

 

이름이 너무 길어 불편할 때, 가장 쉽게 다가오는 유혹은 각 단어의 이니셜로 이름을 짓는 것이다.

나는 이게 너무 싫다.

 

그렇다. 정말로 싫다.

 

 

지금까지 이니셜을 사용하는 행태를 보면 대부분 그룹을 표현할 때였다.

그게 조직이 되었든 프로젝트 이름이 되었든 간에, 어떤 코드가 속해야 할 그룹을 이니셜로 줄여버리는 것이다.

예를 들어 데이터 분석 지원팀이 있다고 하면 daa 로 짓는 것이다.

# daa_database_connector.py
class DaaDatabaseConnector(...) :
	...

 

심지어 디렉터리나 파일 이름도 그렇게 사용한다.

탐정도 아니고... 내가 입사해서 제일 먼저 한 일은 내 팀의 코드를 찾는 일이었다.

 

하지만 이게 사업적으로 유용하다는 건 안다.

소통할 때 '데이터 분석 지원팀이에요' 보다는 'daa팀이에요' 가 더 간결하고 심플해 보인다는 것도 안다.

많은 경영학 용어나 팀 이름이 이니셜 형식으로 커뮤니케이션하고 - 우리끼리의 효율적인 의사소통을 돕는다.

그러나 처음 보는 사람들 100%는 daa 라고 하면 무슨 말인지 모른다.

혹시 pcm이 어떤 것인지 아는가?

 

정말 미안하지만 - 나는 이게 말장난에 지나지 않는다고 생각한다.

솔직히 유치하고 멋없다.

뭐... 우리 세상에서도 이니셜 용어를 찍어내고 싶으면 다 찍어낼 수 있다.

SOLID나 DI, DIP ...

그러나 나는 1-2초의 시간을 줄이자고 절대로 용어를 줄여서 말하지 않는다.

예를 들어 이런 면접 질문보다

SOLID가 무엇일까요?

 

다음 질문을 사용한다.

객체 지향 프로그래밍에서 지켜야할 대표적인 개발 원칙 5가지가 무엇일까요?

 

답변이 '아 SRP, OCP, ... 요?' 라고 하면 우선 눈쌀을 찌푸린다.

이런 사람은 미래에도 코드에도 이렇게 글자를 줄일 게 뻔하고, 소통하면서도 머리가 아플 것 같다.

이런 버릇을 마주치는 순간 - 최소 구글 검색창이나 팀 위키를 옆에 켜두어야 한다.

 

반면 답변이 '한 클래스가 하나의 책임만 가져야...' 이렇게 서술하면 너무 좋을 것이고

심지어 '하나의 단위는 하나의 책임만 가져야 합니다.' 이렇게 해도 얼추 좋아할 것이다.

이런 사람은 코드 자체도 자기가 뭔지 충분히 표현할 것이다.

하지만 그 표현이 미숙하거나 애매한 순간이 올 수 있지만 - 그 순간을 마주한다는 것 자체가 행운이다.

그 분야에 대해 잘 모른다는 말을 반증하기 때문에 더 공부할 수 있는 기회가 있기 때문이다.

 

이니셜은 절대 본인의 지식을 자랑하는 수단이 아니다.

오히려 본인의 무지를 증명하는 수단이다.

 

 

다른 이야기로 넘어가서,

내가 살면서 후회되는 이름 중 하나는, 처음 신입일 때 만든 이니셜 이름들이다.

나름 변명을 하자면 나는 그게 진짜 이름 그 자체고 약어라고 생각하지 않았다.

예를 들면 dm(direct message)과 같다.

사람들이 dm, dm 이렇게 말하길래 나는 진짜 그런게 메시지 이름인 줄 알았던 것이다.

그래서 다음과 같은 끔찍한 일까지 발생했다.

class Dm:
	...
    
dms = [Dm(), Dm()]

 

 

명심하자.

코드는 너무 당연하게도 읽을 수는 있게는 만들어야 한다.

이때 이니셜은 읽을 수 없게 만드는 일등 공신이다.

 

 

 

 

 

 

---

Shorten

 

줄임말은 양날의 검이다.

의미있어서 만든 줄임말은 득이 되고, 귀찮아서 만든 줄임말은 해가 된다.

 

그러나 의미있어서 만든 줄임말은 그 경우가 희귀하다.

대표적으로는 구현체 클래스 이름을 나타내는 Impl이다.

Custom Repository Implementations :: Spring Data JPA

 

공식 문서에서도 Impl 이름을 사용한다.

Implementation으로 풀어서 사용해야 응당 맞다.

그러나 사용 빈도가 정말로 많고, 줄여도 그 의미가 충분히 전달된다면 이렇게 4글자로 줄여두는 게 더 좋다.

지금 생각해보면 config, s3도 있었다.

 

하지만 이게 끝이다.

나는 심지어 이제는 config도 될 수 있으면 configuration으로 짓는다.

줄임말을 사용하고 싶다면 다음 두 가지 관문을 통과하면 된다.

1. 공식 문서에서 사용하라고 한다.
2. 그 코드를 읽는 99%의 개발자들이 이해할 수 있다.

아니라면, 줄이지 말자.

 

 

자 이제 줄임말의 폐해에 대해 알아보겠다.

def compPricesByDistOnEx(firstWon: int, secondDollar: int):
	...

 

미안한데, 죽었다 깨어나도 단어들을 뭘 어떻게 줄인 건지 알려줄 수 없다.

이 상황에서 본인이 개발자라고 하자.

외부 라이브러리에 저 함수가 있다.

 

자신있게 호출하겠는가?

 

 

희한하게도 comp와 dist는 코드에 자주 목격한다.

이것도 최초에 누가 퍼뜨렸는 지 모르겠지만, 알면 무조건 신고해야 된다.

 

어떠한 변명도 통하지 않는다.

그냥 읽는 사람을 놀리는 목적으로 다 귀결될 것이기 때문이다.

comp -> compare 처럼 최소한 예의를 갖추자.

 

 

 

 

 

---

Summary

 

1. 이니셜을 사용하지 말자
2. 줄임말을 사용하지 말자