나는 미래가 있는 코드가 좋은 코드라고 생각한다. feat 기술 부채

2024. 6. 25. 17:14개발관련 잡담

결국 다른 사람 모두가 하는 말과 다를바 없을 수 있지만,

직접 경험해 보고 그 필요성을 깨우친건 또 다른 이야기니까 이에 대해 이야기를 해볼까 한다.

 

내가 코딩을 처음 배우던 시절, 날 가르쳐 주던 선생님은 모듈화와 단일책임원칙, 캡슐화의 중요성에 대해서 거듭 강조하셨다.

그래서 최대한 객체지향적인 코드를 작성할 수 있도록 꽤나 습관을 들이려고 했었다.

하지만, 취업 후 많은 레거시 코드를 보았었다.

함수하나가 3000줄을 넘어가는 코드에서 리팩토링과 원인분석을 하는건 진짜 지옥 그 

잡채....!!!!!!!!!!

 

아무튼 이러다 보니 객체지향적인 프로그래밍 그것을 넘어서

어떤 개발자가 와도 로직의 의도를 파악할 수 있고 유지보수하기 편리한 환경을 염두하는,

"미래"가 있는 코드를 작성해야한다는 생각으로 확장하게 되었다. 

 

모든 개발의 발자취는 축적된다. 이 축적은 기능과 프로그램의 디테일도 있겠지만,

잠재된 위험성과 유지보수가 어려운 구조 또한 축적된다는 것이다.

글을 쓰다 알게 되었는데, 내가 말한 이런 축적을 "기술 부채"라고 이미 부르는 용어가 있다고 한다.

역시 사람들 경험하고 생각하는건 똑같구나...

 

https://ko.wikipedia.org/wiki/%EA%B8%B0%EC%88%A0_%EB%B6%80%EC%B1%84

 

기술 부채 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 기술 부채(technical debt, design debt[1], code debt)는 현 시점에서 더 오래 소요될 수 있는 더 나은 접근방식을 사용하는 대신 쉬운(제한된) 솔루션을 채택함으로써 발

ko.wikipedia.org

 

당장은 작은 일처럼 보이기에 이정도 불편함또한 괜찮다하고 넘어가 버리면 

그것은 점차 부채로 쌓여 미래에 내가 되었든 다른 누군가가 되었든 그것을 감당해야 한다.

그렇다면 어떻게 될까? 정해진 자본력으로 낼 수 있는 돈은 한계가 있고,

이미 충분한 이자가 붙은 프로그램은 돌이킬 수 없다.

이를 해결하기 위해선 카드 돌려막기와 같은 또 다른 기술 부채를 불러와야만 하고,

결국 감당가능한 자본력을 부채가 뛰어넘어 버릴 것이다.

종국엔 이러한 프로그램은 미래가 불투명하지 않을까. 난 그렇게 생각한다.

 

레거시 코드를 보면서 안타까웠던 순간들 중 하나가 바로 10분이면 잡을 수 있을 난이도의 문제가

이런 기술 부채로 인해 너무 많은 리팩토링 과정이 있어야 했고, 리팩토링조차도 디버깅 과정들이 필요했기에 10분이 2시간이고 이틀이고 늘어나 버리는 상황들 이었다.

 

난 이게 담당하는 개발자, 관리자, 회사 전체에게 좋지 않은 상황이라 생각한다.

개발자는 기술 부채로 인해 감당해야 할게 많으니 사소한 일에도 많은 리소스가 답답하고,

관리자는 업무순환이 되어야 하는데 문제 해결이 너무 더디니 개발자가 답답하고,

회사입장에선 비즈니스적 문제로 야기 될 수 있기에 이런 상황들이 답답하다.

결국 그 누구도 행복할 수 없고, 피해자만 존재하는 상황들이 오게 된다는 것이다.

너무 오버하는거 아니냐고?

난 그게 오버가 아니라는걸 알고 싶지 않았다...

 

서로가 답답한 상황...

 

뭔가 "미래"가 있는 코드를 이야기 하는데, 기술부채에 대해서만 이야기 하고 있으니 핀트가 어긋나 보일 수도 있지만,

이것이 핵심이다.

기술 부채를 최소화 하는 것이 앞서 말한 "어떤 개발자가 와도 로직의 의도를 파악할 수 있고 유지보수하기 편리한 환경을 염두해야한다"를 이루기 위한  초석이 된다.

 

기술 부채가 쌓이는 것을 막을 수는 없을 것이다.

우리는 아직 이것을 완벽히 이루지 못하였기에 개발 패러다임은 항상 변화하고 있으니까 말이다.

그러나 코드를 짤때 언제나 미래를 염두하면, 이를 최소화 할 수는 있다.

나는 코드를 짤때 만일 미래의 누군가가 내 코드를 본다면, 러닝커브를 어느만큼 최소화 할 수 있을까를 생각한다.

물론, 그렇게 생각해도 이런 나만의 원칙이 지켜지기는 어렵지만, 그런 시도가 들어간 코드와 손을 놔버린 코드는 또 다른 것 같다.

 

이러한 이유들로 난 미래가 있는 코드야 말로 정말 좋은 코드가 아닐까 생각한다.

거창해 보이지만, 누구나 함수의 의도를 파악할 수 있는 네이밍을 한다면, 그것도 미래에 열려있다고 할 수 있지 않을까?

 

사소해 보였던 부채가 불어나 닫힌 미래를 만든다는 것은 한 편으론

사소한 디테일이 모여 열린 미래를 만들어 나간다는 근거가 되니까 말이다.