2. 애매모호함을 버리자

---

Frustrating

 

우리는 우리가 직접 만든 코드에 대해 엄청난 이해도를 가지고 있다.

의식의 흐름대로 착실히 한 줄 한 줄 써내려갔기 때문에,

다시 위로 스크롤해서 처음부터 읽어도 잘 읽힌다.

 

내 코드에 피드백 올 것들은 아마 디자인 패턴이나 문법적 우려에 기반할 것이다.

어쩌면 병렬 프로세싱에 대한 지적일 수도 있고, 효율적으로 시스템 자원을 사용하지 않아서 그러겠거니 한다.

그리고 이렇다할 피드백이 없으면 역시 더 고칠 게 없었겠거니 생각한다.

 

까지가 우리의 착각이다.

 

인정하자.

그 코드는 안 읽힌다.

그래서 아무도 그 코드를 보려고 하지 않는 것이다.

애정 깊게 쌓아 올린 코드는 결국 나한테도 잊혀져 생명이 다 할 것이다.

 

나는 읽히지 않는 코드는 답답하다고 표현한다.

이렇게 답답했던 경우는 2가지였는데 - 하나는 내가 멍청해서 그런 것이고, 하나는 표현이 이상했기 때문이다.

 

내가 멍청해서 읽히지 않았던 코드는

열심히 공부해서 결국 읽는데 성공하면 

남극에서 사이다를 드링킹한 것처럼 어딘가가 뚫리는 기분이 든다.

그리고 그 지식들은 언젠가 나에게 도움이 크게 된다.

 

표현이 이상해서 읽히지 않았던 코드는

파면 팔수록 자괴감만 든다.

내 인생을 짧을 텐데 이런 걸로 허비했다는 현실을 자각하는 순간

그 경험들은 언젠가 내 수명을 줄여버리는 데 공헌할 것이라고 생각한다.

 

 

옛날에는 답답한 경험을 자주 했었다.

결국에는 첫 부분만 보고도 내가 멍청한 건지, 표현이 이상한 건지 대략 구분할 수 있게 되었다.

그리고 대부분은 애매모호한 이름에서 시작되었다.

 

 

 

 

 

---

Stopword

 

내가 어렸을 때 본 예제가 어렴풋이 기억났다.

첫 시작은 이러했다.

class MyExample:
    name: str
    age: int

 

근데 밑으로 내려보면 더 가관이다.

class MyExample:
    name: str
    age: int
    
    def __init__(self, data):
    	self.name = data['name']
        self.age = data['age']

 

정말 슬픈 일이다.

근데 한 편으로 놀라운 건 개발을 시작하는 사람들은 모두 아무렇지 않게 이런 식으로 쓰고 있었다는 점이다.

그리고 더 놀라웠던 건, data 라는 이름은 실력 불문하고 모두가 한 번쯤 쓰고 있었다는 것이다.

 

이게 어디서부터 잘못된 것인지 모르겠다.

고의든 실수든 재미든, 이런 식으로 풀어진 단추를 꿰메어주면 안된다.

이렇게 교육하는 사람은 학생들의 코드를 절대 안 보고 아마 본인의 지식만 주입하려고 하는 사람일 것이다.

 

언제 어디서 무엇을 하던지 - 분명한 이름은 정말 존재한다.

어떤 프로젝트를 하던지, 심지어 알고리즘 문제를 풀 때도 이름을 만들 수 있다.

그리고 그건 정말 쉬운 일이다.

영어라서 힘들다면, 그냥 구글이나 네이버 번역기를 돌리면 될 일이다.

 

 

my, data 라는 이름은 불용어이다.

중요하지 않은 이름이다.

이걸 한 번 증명해본다면,

class DogExample:
    name: str
    age: int
    
    def __init__(self, dog):
    	self.name = dog['name']
        self.age = dog['age']

class TreeExample:
    name: str
    age: int
    
    def __init__(self, tree):
    	self.name = tree['name']
        self.age = tree['age']

 

그 용어를 빼고 다른 걸 넣어도 위화감이 전혀 없다.

심지어 빼도 말이 된다.

class Example:
    name: str
    age: int
    
    def __init__(self, _):
    	self.name = _['name']
        self.age = _['age']

 

아직도 와닿지 않는다면,

다시 올라가서 내가 만든 처음 예제를 작성한 의도를 생각해보자.

복잡할 것 없이 그냥 data라는 함수 파라미터를 생각해보자.

 

data는 뭘 의미하는 가.
data는 어떤 것이든 될 수 있다.
data는 어차피 우리가 만드는 게 데이터 아닌가.
data는 만물을 표현하는 게 아닌가.
data는 내가 기르던 물고기를 의미하는 건 너무나 당연한 상식 아닌가.
data는 맞다! 내가 어제 산 옷의 데이터를 의미하던 것이었다.

 

이렇게 불용어는 애매모호하게 이름을 짓는 방법 중 가장 쉬운 방법이다.

다시 한 번 말하지만 우리는 어떤 것을 하더라도 이름을 구체적이고 명확하게 지어줄 수 있다.

 

그럼에도 불구하고 이 자리에는 data 라는 이름이 들어가야 될 것이라면, 그건 사실 코드 구조부터 이상하다는 징조이다.

 

 

 

 

 

---

Promise

 

아이러니하게도 불용어를 써도 되는 희귀한 경우가 있다.

여기서 희귀한 경우라고 표현하는 것은, 이 상황이 아니고선 절대 불용어를 사용하지 말라는 경고이기도 하다.

 

그 희귀한 경우은 바로 약속이다.

그렇다. 우리 모두 손가락을 걸고 사용하자고 약속한 용어는 써도 된다.

경험적으로 용어를 약속했던 상황은 다음 두 가지였는데

하나는 기밀을 유지해야 하는 용어고,

다른 하나는 너무 자주 써서 고착화된 용어다.

 

전자는 반론할 여지가 없기 때문에 그 용어를 써야하는 장소를 명확히 정해놓으면 된다.

후자는 오늘봐도 내일봐도 어차피 그게 그런 의미라는 걸 알기 때문에 괜찮았다.

 

사실 후자가 되는 용어를 하나 생각해보면 page가 있었다.

page는 불용어가 맞다. 뭐든 될 수 있었으니까.

이제부터 page를 왜 사용했는 지 설명할 건데,

 

여기서 잠깐 멈추고 그게 뭘까 고민해보자.

그럼 이게 왜 불용어인지 알 수 있다.

(설명을 듣기 전까지 뭔지 모르기 때문이다)

 

 

 

백엔드 프레임워크 중 스프링(Spring)에는 Page라는 구조체가 있는데,

테이블의 모든 행들 조회해서 주는 게 아니라 몇 개 묶음으로 정해서 어떤 페이지를 줄 때 사용한다.

 

쉽게 말하면 이런 식이다

 

이걸 전달받는 프론트엔드 입장에서는 이름을 정할 필요가 있었다.

interface Task {
    ...
}

interface TaskPage {
    tasks: Task[]
    ...
}

 

위에서 먼저 Task를 정의해버리니, 이를 표현할 수단이 마땅치 않았기 때문에 Page를 이름 뒤에 붙였다.

스프링 프레임워크에서 이런 이름으로 정의했기도 했고 의미도 나름 합리적으로 보여 좋다.

 

 

약속은 정말 중요하다.

약속은 깨뜨릴 수 없는 산물이다.

약속만 한다면 어떤 용어든 사용할 수 있다.

 

왜냐하면 나를 포함한 모든 사람이 모여서 이야기함으로써 할 수 있는 행위이기 때문이다.

나는 모여서 어떤 내용을 약속했을 때, 그게 궁극적으로 팀에 해가되는 경우를 거의 본 적이 없다.

(해가 되는 경우는 그냥 혼자 이야기하고 > 정하고 > 끝냈을 때이다)

 

그러니 다같이 시간내서 손가락 걸고 맹세하는 건 유치한 게 아니다.

시간 없다고 도망쳐서 TaskData 같은 이름을 만드는 게 진짜 유치한 것이다.

 

 

 

 

 

 

---

Dictionary

 

약속했든 안 했든

내가 사용했든 남이 사용했든

일단 용어는 어딘가에 정리하는 게 좋다.

 

못생긴 이름을 짓는 건

실력이 없든 있든 개발을 많이 했든 적게 했든 누구나 겪는 일이다.

그러나 반대로 생각해보면 잘생긴 이름을 짓는 것도 마찬가지이다.

 

어느 날은 정말 신이 강림해서 너무나 완벽한 이름을 지을 때가 있다.

이런 건 제발 기록해서 내일, 일주일 뒤, 한 달 뒤, 일년 뒤 본인이 참고했으면 좋겠다.

 

나는 옛날 내가 만든 코드가 부끄러울 때가 많아 별로 보고 싶지 않지만,

지금의 나도 다시 보고 배워야할 옛 시절의 코드도 있다.

대부분 키워드를 떠올려서 찾아보거나, 아니면 따로 잘 정리해둔 문서를 참고한다.

그리고 다시 기억나게 해줘서 이상한 이름을 짓지 않게 도움을 많이 준다.

 

그리고 만일 본인이 힘들게 용어집을 만들었다면 다른 사람에게 공유하는 게 좋다.

물론 남 좋은 일 한다고 배가 아플 수 있다.

그러나 용어집에 어떠한 피드백이나 조언을 해주지 않고 그냥 누리려는 사람들은 별로 없다.

응당 같이 고민해주거나 더 나은 용어를 추천해줄 것이다.

(아닌 사람들 대부분은 어차피 망하거나 정체될 것이기 때문이고, 본인은 더 나아갈 것이기 때문이다)

 

 

 

 

 

---

Summary

 

1. 불용어를 쓰지 말자

2. 용어를 약속하자

3. 용어집을 만들고 공유하자