시간 레버리지는 빨리돌아왔다

시간 레버리지 이야기

시간레버리지

내가 정의한 시간 레버리지는, 고민하는 시간을 최소화 하고, 결과물에 초점을 맞추어 개발하여, 개발시간을 단축하는 것을 말한다.
곧 출시를 앞둔 서비스에서 이 레버리지를 쭈욱 끌어당겨 사용했다. 그리고 레버리지를 끌어당긴 만큼, 시간이 빨리 지나갔다.
하지만 이렇게 레버리지를 끌어당긴 만큼, 레버리지가 빨리 돌아왔다. 이렇게 빨리 돌아올 줄은 몰랐다.

빠르게 쌓여가는 이자

생각보다 이자가 썠다... 고민을 짧게한 만큼 변화에 너무 취약했다.
한 컴포넌트를 만들더라도, 어떻게 변화하고 또 활용할 수 있을지에 대한 고민을 충분히 하지 못해, 중복을 피할 수 없었다.
중복 조차 일관성 있어야 한다는 생각이 들었고, 그래야 수정할 때, "중복의 규칙" 을 찾아가면 그나마 나을 거라고 생각이들었다.

이 구조에서 서비스의 변경사항은 중복한 만큼의 수정이 필요했다.
하지만 난 또 일관성을 유지하고자 했다. 어느정도 서비스의 윤곽이 자리잡혔을 때, 중복을 제거하기 위해서였다. 그래야 큰 틀을 보고서 설계가 될것 같았다.
그렇게 중복에 중복, 꼬임에 꼬임이 연속되면서 드디어 완성됐다. "나만 이해할 수 있는 코드 !"

모를때가 더 깔끔했다

이렇게 완성된 코드를 보니, 뭔가 이상했다. 코드의 가독성, 퀄리티가 퇴행한 것 같았다.
그래서 오랜만에 1년전의 코드를 보니, 술술 읽혔다. 반대로 지금의 코드를 보면, 함수, 클래스가 정의된 곳으로 타고타고.. 여행을 다녀야만이 그 끝을 알 수 있었다.
이런저런 방법론, 패턴 들을 명확히 흡수하지 않은 상태에서 적용해보려고 했던 것이 문제였다.

주변의 조언을 듣고서 아차 싶었다. 간지나는 코드보다는 간단할 수록 좋은 코드라는 사실이다.
또 어떤 방법론을 사용하는 이유에 대해서도 다시 생각했다. "이번에 써봐야지" 라는 자세보다는, "문제를 해결하기 위해 이 방법이 적절하겠다".

테스트 코드

테스트 코드야 말로 "유형의 레버리지" 가 아닐까 생각한다.
맨 처음 시간레버리지의 정의를 고민하는 시간을 최소화한다 고 했는데, 이 부분은 사람마다 다르고, 경험이 쌓일 수록 더 이상 레버리지가 아니라,
점점 빠르게 생각할 수 있고, 미래를 대비하는 능력이 늘어나면서 사라질 수 있다. 그렇기에 "무형의 레버리지" 라 할 수 있고, 누구에게 하소연 하기도 쉽지않은 녀석이다.

비로소 드디어, 테스트 코드의 필요성을 뼈저리게 느꼈다. 이 순간을 정말 기다렸다.
테스트 코드는 기능의 명세서가 될 뿐 아니라, 개발 시간을 제곱 단위로 줄여 준다.
처음부터 전체적인 구조를 레고처럼 딱딱 맞춰뒀으면 모르지만, 그렇지 않은 상황에서 내 코드를 장담할 수 없는 상황의 연속이었다.
상태가 워낙 많고, 그 상태가 서로 연관되어 있어서, 하나의 수정이 다른 곧에 미치는 영향을 직접 테스트해보지 않고서야 보장 이 안됬다.
결국 개발한는 시간과 테스트하는 시간이 거의 동일했고, 처음에 테스트코드를 작성하면서 개발했으면, 테스트 코드를 작성하면서 보낸 시간보다 더 많은 시간을 얻을 수 있었을 것이고,
테스트를 위한 코드를 짜면서 구조도 좋아질 수 밖에 없었을 것이다.

더 나아졌구나

나는 메타인지를 자주 하려고 노력하는데, 그 중에 하나는 "내가 몸소 겪지 않은 것은, 믿지도 하지도 않는다."는 성격이다.

똥인지 된장인지는 먹어보기전엔 모르니까...? 사실 내가 똥을 더 좋아할 수 도..? 무튼 모든 가능성을 연다는 의미이다.

이번엔 이론적으로만 알고 있었던 테스트코드, 간결한코드, TDD, SOLID 원칙, Open-Closed Principle, Design Pattern 의 실제적인 필요성을 느꼈다.
이것들을 받아들이는 시간이 너무 반갑고, 이 프로젝트를 통해 더 나아진 나를 만나게 해준 것 같다.