brunch

You can make anything
by writing

C.S.Lewis

by 백명석 Aug 14. 2016

다시 만들면 잘 만들 수 있다.

그 말을 어떻게 믿지?

자신이 만들지 않은 코드를 유지보수(기능 추가 혹은 변경 등) 해야  하는데 어려움을 겪는 일은 매우 흔한 일이다. 이런 상황이 발생했을 때 그 사람에게 그 코드는 개판이니 이해하려고 노력하는 것보다 다시 만드는 것이 나을 것이다라고 조언을 하는 사람을 본 적이 있다. 심지어 그분은 컴퓨터공학 박사 학위를 가지고 있는 분이었다. 단언컨대 그분은 소프트웨어 공학을 전공하진 않았을 것 같다. 또 그런 상황을 겪은 개발자 스스로 이건 다시 만들어야 한다고 얘기하는 것도 많이 봤다.


아래와 같은 이유로 다시 만드는 것은 성공하기 어렵다.

새로 만드는 개발자는 이전의 개발자보다 개발 역량이 압도적으로 높아서 슥슥 코드를 작성하면 가독성이 뛰어나고 후에 변경이 용이한 코드를 작성할 수 있을까?

새로 만드는 개발자는 이전 개발자가 겪었던 개발 진행 후(심지어 배포 후)에 요구사항 변경(일정 지연이나 소프트웨어 품질 저하를 유발할 수 있는)을 안 겪을 안전장치(미래를 예측할 수 있는 마법의 수정구 ???)를 가지고 있을까?

새로 만들 때 일정은 잘만들 수 있을 만큼 여유 있게 주어질까?

새로 만드는 동안 기존 시스템의 필수적인 요구사항 변경이 들어온다면 기존 시스템 변경과 신규 시스템 개발을 같이 해야 할 텐데... 분신술이라도 있어야 하나 ㅠㅠ


나도 어떤 코드를 보면 다시 만들고 싶거나, 매우 공격적으로 한 번에 많이 리팩터링을 시도한 적이 있다. 사실 최근에도(수개월 전) 후배가 작성한 코드를 보고 하루 정도의 시간을 들여서 리팩터링을 해 본 적이 있다. 하지만 이렇게 큰 범위로 작업한 경우 서비스 코드에 반영하는 것이 수월치 않다. 적용했을 때 어떤 버그가 나올지 걱정이 되기 때문이다.


이런 상황이 발생했을 때 제일 좋은 방법은 매일 조금씩 개선하는 것이다. 이런 개선을 하기 위해서는 

의존성 제거 기법(Working Effectively with Legacy Code 참고)을 행해서 수정/개선하려는 코드가 테스트 가능하고, 변경할 수 있도록 만들 수 있어야 하고, 

다양한 리팩터링 기법(Refactoring: Improving the Design of Existing Code 참고)을 행할 수 있어야 하고,

TDD를 행할 수 있어야 하고,

좋은 설계를 할 수 있어야

한다. 


그래서 신규 시스템을 빨리 개발하는 것과는 다른 종류의 기술에 대한 지식과 행할 수 있는 능력이 필요다. 어럽다. 그래서 쉬운 방법으로 여겨지는 다시 만드는 방법이 솔깃하다. 하지만 언제까지 그렇게 피할 수 있을까? 요즘은 40이 넘은 개발자를 어렵지 않게 볼 수 있다. 15년 차 정도 된... 이런 개발자들이 똑똑하고 열심히고, 체력도 좋은 4~8년 차 개발자와 차별점을 갖는다면 새로 만드는 기술이 아니라 매일 조금씩 개선하는 기술이라고 생각한다. 매일 조금씩 개선하는 기술들은 지식도 지식이지만 오랜 기간의 경험(연습)도 필요하기에 절대적으로 시간이 필요한 부분이다. 4~8년 차의 뛰어난 역량을 가진 개발자들도 잘할 수 있겠지만 15년 이상 이 분야에서 일하면 관련된 지식을 체계적으로 쌓고, 수행을 하며 경험을 쌓은 시니어 개발자가 더 잘할 수 있는 부분이라고 생각한다.


물론 모든 경우에 위에서 피력한 의견이 맞다고는 생각하지 않는다. 어떤 때는 다소 퀄리티가 떨어지더라도 빠르게 만들어야 할 때가 있고, 정말 한번 쓰고 버릴 시스템을 만들 경우도 있다. 이럴 경우 적절한 기술을 사용해서 적절한 퀄리티를 갖도록 하는 것이 맞다. 하지만 만약에 후에 변경이 필요할 수도 있으니 고칠 수 있을 만큼의 퀄리티는 유지되어야 한다. Quick and Dirty이지만 clean 해질 수 있을 만큼 Dirty 하게... 그리고 다른 개발자가 아니라 본인이 clean 하게 개선할 수 있는 역량을 가져야 한다.


어떤 문제에 봉착하면 이 문제를 제일 쉽게 해결하는 방법은 다른 방법으로 시도하는 것이다. 하지만 이것은 원천적인 해결책이 되지 못한다. 바늘 허리에 메어 한두 번은 면피할 수 있지만, 그런 경험을 쌓은 개발자를 시니어 개발자로 존중하기는 어렵다. 다소 느리더라도 문제를 원천적으로 해결하는 것이 시니어 개발자들이 가져야 할 역량 중 하나로 생각한다.

작가의 이전글 TDD의 Test 작성 기법들
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari