9. 이름은 하나다

---

Consistency

 

내가 실무에 있으면서 가장 좋아하고 많이 사용하는 용어는 일관성이다.

물론 일관성에 대한 사전적 정의가 있지만, 개인적으로 어떤 상황과 장소에 있든 지 똑같은 것이라고 정의한다.

 

예를 들어 물을 생각해보자.

일반적으로 물은 Water이다.

그러나 본인이 화학자라면 H2O라고도 부를 수 있다.

 

여기서 일관성을 찾자면, 당신이 누구든 간에 그냥 water라는 이름으로 통일하라는 말이 아니라

본인이 이름을 한 번 정했으면 죽을 때까지 그 이름으로 부르라는 이야기이다.

 

경험적으로 대다수의 코드는 정해진 범위 안에서 이름에 대한 일관성을 너무 잘 지킨다.

그러나 조금만 벗어나거나, 다른 서비스를 개발할 때는 다소 깨진다.

똑같은 의미임에도 다른 이름을 쓰거나, 다른 의미임에도 똑같은 이름을 쓰기 때문이다.

 

 

 

 

 

---

Change Names

 

나는 이름을 바꾸는 것 자체가 잘못되었다고는 절대 생각하지 않는다.

첫 번째 이유는 시간은 흐르기 때문에 어떤 이름의 의미 자체가 바뀔 수도 있는 것이고

두 번째 이유는 그렇지 않더라도 지금에 와서 본인이 그 이름을 다르게 느낄 수 있기 때문이다.

어쨌든 이름이 지금 이런 상황에 쓰기에 뭔가 잘못되었다고 느낀다면, 당연히 그 이름을 사용하면 안된다.

 

그렇다. 바로 이 시점에서 일관성이 깨진다.

자. 문제 상황은 단 두 가지로 명료하다.

• 애시당초 잘못 지었거나
• 다른 상황이거나

해결책 또한 너무 명료하다.

• 처음부터 다시 짓거나
• 다른 이름을 쓰거나

 

대다수는 이 해결책을 따르지 않는데,

그 예시로 만일 본인이 생수 판매 업체에게 제공할 서비스를 개발한다고 하자.

물을 정의한다면 water로 만들 수 있다.

 

이제 생수 판매 가격이라는 이름을 만들어보자.

water_sale_price = 3000

 

너무 자연스럽고 이해하기 쉬운 이름이다.

그러니 이런 이름들은 절대 쓰면 안된다.

h2o_sale_price = 3000
fluid_sale_price = 3000

 

 

이제 시간이 많이 지나면서 본인이 생수 뿐 아니라 기름도 판매한다고 해보자.

판매 기술이 흐르는 유체를 판매하는 데 공통화되어 있기 때문에

물과 기름의 판매 가격을 계산하는 과정에서 다수의 중복 코드가 발생한다고 한다면

결국 water 용어 대신 fluid 라는 용어 하나로 묶어 코드 구조를 개편할 수 있다.

 

자, 이제부터 fluid로 쓰겠습니다 한다면

fluid 라는 이름으로 처음부터 다시 지으면 된다.

fluid_sale_price = 3000

 

그러나 많은 개발자들은 여기서 본인의 가치관과 혼동하기 시작한다.

그동안 개발했던 코드가 아깝기도 하고, 어쨌든 변경에는 닫혀 있어야 하기 때문에 기존 코드에 대한 수정을 꺼려하기 때문이다.

처음부터 기름을 판매할 걸 염두에 두고 있었다면 추상화 전략을 잘 세웠겠지만

그 누가 생수 팔다가 기름 팔 걸 생각이나 했겠는가

 

그렇다.

그 시절에 물이 이미 엎질러졌는데 지금와서 이것 저것 분리해보고 조합해봤자 코드는 더러워질 뿐이다.

물론 퍼사드 패턴이든 데코레이더 패턴이든 구조 패턴을 가져와 적용해볼 수 있다.

그러나 결국 처음 썼던 이름은 거기 그대로 남아있기 때문에

어떤 범위 안에서는 쭉 water로 쓰고 어느 시점에서 fluid로 바뀔 것이다.

 

다시 한 번 말하지만 대다수의 코드는 정해진 범위 안에서 이름에 대한 일관성을 너무 잘 지킨다.

여기서 한 번 굳어진 이름을 바꾸기란 쉽지 않고,

혼자 개발하는 것이 아닌 여럿이 개발하는 경우에 최초 정했던 이름을 바꾸면 충돌 문제도 야기한다.

 

그러나 나는 이름을 통일하라고 자신있게 주장한다.

기존 코드를 버리든 고치든 구조 개편을 하든 뭘 하든 간에 그냥 이름은 하나로 써야된다.

water_sale_price를 버리고 fluid_sale_price로 갈아타야 한다.

코드의 역사를 몸소 체험한 본인만이 이름들을 구분해서 사용할 수 있기 때문이다.

 

맞는 게 맞는거다.

그리고 그게 그거면 그냥 하나로 써야 된다.

어느 누가 와도 이름 때문에 헷갈리지 않는다면 그냥 써도 되지만, 결국 다른 이름은 다르게 쓰기 마련이다.

 

 

다른 이야기를 해보자.

본인이 생수 생산 업체에게 제공할 서비스를 개발한다고 하자.

생수에는 원소 단위로 정제해야 하는 과정이 있어, 헷갈리지 않게 물을 h2o로 만들 수 있다.

 

판매 서비스든 생산 서비스든 물이라는 건 둘 다 동일하지만

서로 다르게 사용하기 때문에 water와 h2o 처럼 다른 이름으로 불러도 된다.

 

가장 애석한 고집은 바로 내가 ~ 했었기 때문에 ~ 가 맞다는 주장이다.

본인이 어떤 경험을 했고 어떻게 이름을 지어왔는 지 관심 없다.

water로 개발해서 판매 서비스 런칭에 성공했기 때문에 생산 서비스에서도 water로 불러야 한다는 건 말도 안된다.

 

만일 수소와 산소를 분리한다고 했을 때

decomposed_hydrogen_and_oxygen = water.decompose()

보다

decomposed_hydrogen_and_oxygen = h2o.decompose()

 

가 사용자 입장에서 더 잘 읽히면 이렇게 써야 한다.

 

 

 

 

 

---

Trivial Name

 

가끔 코드를 보면 이전 장에서 말했던 경우가 아닌,

똑같이 사용하고 있지만 다른 이름을 사용하는 걸 종종 목격한다.

이럴 때마다 솔직히 이름을 잘못 지었다는 느낌보다는 이름이 더럽다는 느낌을 받는다.

 

몇 가지 꺼내보자면

1. 접두사나 접미사가 있거나 없거나

apple_vo = AppleVo()

apple = AppleVo()

 

2. 이름의 결을 맞추려고 하는 노력을 하거나 안 하거나

apple_contents = list(AppleVo())
apple_page = ApplePage(contents = apple_contents, ...)

apples = list(AppleVo())
apple_page = ApplePage(contents = apples, ...)

 

3. 단순 통일하지 않거나

APPLE_TEXT = "달고 맛있는 사과"

APPLE_TITLE = "달고 맛있는 사과"

 

 

위 예시들이 잘못된 건 딱 하나다.

하려면 다 하고, 안 하려면 다 안 해야되지만 그렇지 않다는 것이다.

읽기에는 문제 없지만 께름칙한 부분은 어쩔 수 없는 것 같다.

 

 

 

 

---

Summary

 

• 이름을 일관성 있게 짓자
• 이름 짓는 방식을 통일하자