한 때 "좋은 코드가 굳이 필요할까?" 생각 했었다.

시간이 지날 수록 (총 코드량이 늘수록) 생산성은 떨어지는 마법

나는 처음 개발 공부를하고 개인 프로젝트를 만들면서 굳이 클린코드? 좋은코드?라는게 필요한가?라는 생각이 항상 있었다. 그 프로젝트는 팀원이 2명이였는데도 그닥 필요성을 느끼지 못했다. 하지만 지금 만 9개월동안 프론트엔드로 일하다가 느낀바로는 클린코드는 무조건 필요하다.

생각이 달라진 이유

그 때와 지금이 다른 점이 무엇일까 생각해보면 현업을 경험하고나서 내가 내린 클린코드의 정의가 달라졌다. 처음 개발을 배우면서 클린코드라는 단어를 들었을 때 내가 받아드린 정의는 그저 깨끗한 코드였다. 어떤 기능을 하는 메소드인지 한 눈에 보면 딱 알 수 있고 그러한 함수들로만 이루어진 코드 들. 그러한 코드들을 짜기 위해 마치 가내 수공업 하듯이 한땀 한땀 메소드을 만드는 것. 그저 사람이 보기 이쁜 코드를 짜는 것. 딱 사람이 보기 이쁘고(?) 알고리즘으로 가장 빠르게 만든 코드들이라고 받아드렸었다. 하지만 지금은 조금은 다르다.

현업에서 프로젝트를 진행하다 보면 요구 사항이 수시로 변경되고 추가된다. 어제의 요구 사항과 오늘의 요구 사항이 다르고 심지어는 어제 없앴던 기능을 다음 주에 다시 부활하는 경우도 있었다. 이러한 경우에 만약 중구난방으로 짜여진 코드들로 대응을 한다면 어떨 까? 예상 그대로 지옥이다. 기능 구현에 급급해지며 정해진 코드 베이스 없이 스파게티 코드가 되어 버린다. 결국 안 쓰는 레거시 코드들도 정리도 못하고 커대한 진흙이 되어버리는 것이다.

그래서 지금은?

지금 현 시점에서 내가 다시 내린 좋은 코드의 정의는 요구 사항이 수시로 변경되고 추가될 때 무난하게 대응할 수 있는 생산성 있는 코드들이 아닐까 싶다. 이러한 코드들은 프로젝트를 진행하는 개발자끼리 서로 코드를 어떻게 써내려갈지 컨밴션이 있어야 하고 언제든지 확장하거나 축소할 수 있는 구조로 가야 할 것 이다. 그러므로 요구 사항이 수시로 변경 되는 현업에서의 상황으로 볼 때 클린코드, 좋은코드는 필수적이라고 생각한다.

지금의 나는

현재 회사에서 만 9개월 차 나와 똑같은 연차의 개발자분과 프론트엔드 프로젝트를 돌리고 있어 코드리뷰나 클린코드에 대한 시도는 미비하나 이제 생산성있는 코드를 짜볼려고 OOP라든지 테스트코드 작성법이라는지를 공부하고 있다. 아직 좋은코드가 무엇인지, 어떻게 해야할지는 감도 잘 못잡고 있지만 다음번 이직 때는 코드리뷰가 있고 사수가 있는 회사로 이직하고 싶다. 그래야 좀 더 빠르게 습득 할 수 있을 것 같다.