brunch

You can make anything
by writing

C.S.Lewis

by 이경종 Apr 13. 2022

코드 리팩토링에 대해

한권의 책은 분명 쓰는 것보다 읽는 것이 더 쉽습니다. 

하지만 그냥 일기나 낙서로 책 한권을 쓰는 것보다는 한권의 고전을 읽는게 더 어려울 수 있습니다.

아무 생각없이 지저분한 막코딩을 하는 것이 낙서나 일기를 쓰는 수준이라면, 그렇게 막코딩된 코드를 이해하는 것이 고전을 읽는 난이도일 것입니다. 코드를 독해하는 것은 단순히 문자를 읽는 것 이상입니다. 재개발을 하는 경우나 유지보수에 있어  원본 코드의 품질은 개발 리소스에 심대한 영향을 주게 됩니다.


리팩토링은 프로그램 코드를 사람이 이해하기 좋게 바꾸는 작업입니다.

제 졸저 <개발자 오디세이아>에서도 리팩토링에 대해  이야기를 늘어놓은 바 있는데요.

https://brunch.co.kr/@lkj28/92

언급했다시피 코드가독성은 소프트웨어 품질속성 중 유지보수성과 재사용성에 지대한 영향을 미치는 요인입니다. 프로젝트를 하면서 남이 짜놓은 코드를 보며 속으로 욕 한 번 안 해본 개발자분들은 아마 없을 겁니다. 어떤 개발자들은 코드를 쓸데없이 일부러 복잡하게 짜기도 하죠. 그러면 더 있어 보인다고 생각한다면 정말 오산이죠. 메모리와 성능을 쥐어짜기 위해 의도적으로 코딩하는 경우를 제외한다면 코드라는 것은 복잡할 이유가 하나도 없습니다. 마틴 파울러 선생도 말했지만, 보통 개발자는 컴퓨터가 이해하는 코드를 짜지만, 현명한 개발자는 사람이 이해하는 코드를 짭니다.


리팩토링의 주체

리팩토링을 해야 하는 주체는 누구일까요? 

첫번째는 해당 코드를 작성한 개발자입니다. 

두번째는 해당 코드로 개발 프로젝트를 수행하는 또다른 개발자입니다. 

실제 코드를 만들고 그 코드로 작업을 하는 개발자들은 불행하게도 많이 바쁩니다. 제가 20년동안 개발자 생활을 하면서 정상적인 개발자중에 안 바쁜 개발자는 거의 본 적이 없습니다. 속내는 어떨런지 몰라도 다 바쁩니다. 리팩토링은 사치라고 생각하면서 똥 싸질르듯 코딩을 해댑니다. 그렇다고 리팩토링을 프로젝트와 무관한 사람이 진행하는 것은 안 하느니만 못 한 결과를 낳을수 있습니다. 하기는 할 수 있겠습니다만, indent 간격 맞추고 일부 코딩컨벤션 정도 고치는 수준에 그치기 십상입니다. 능력에 따라 수준 높은 리팩토링도 가능하겠으나,  엄청난 노력과 시간이 요구될 수 밖에 없습니다. 그런 고급인력들을 남이 만들어놓은 걸레를 세탁해서 수선하는데 소모하는 것은 엄청난 낭비일수 있습니다. 


리팩토링이 어려운 두가지 이유가 있습니다. 

첫번째는 코드 가독의 문제입니다. 몇년만 지나도 본인이 직접 짠 코드조차 이해하기 쉽지 않습니다. 남이 짜놓은 코드는 더 이해하기 어렵죠. 다른 사람이 책을 써놓았는데, 암호로 써놓았다고 생각해봅시다. 암호해독표도 없습니다. 설상가상 매 페이지마다 암호가 다 다릅니다. 이것은 실제 많은 회사에서 흔하게 일어나는 일들입니다. 이해하지 못하는 코드를 가지고 그 위에 다른 코드를 짜놓으니 엎친데 덮친 격입니다. 개발용어로 스파게티 코드라고 하죠.  이런 코드는 리팩토링 할수 없습니다. 그냥 버리고 새로 짜는게 모든 면에서 이롭습니다.


실무자가 아닌 제3자가 리팩토링을 하면 안되는 두번째 이유는 현실과 이상의 괴리때문입니다. 실무자는 현실에 치우쳐 있고, 비실무자는 이상에 치우쳐있습니다. 현실에 치우쳐 있으면 지엽에 매달리기 쉽고, 이상에 치우쳐 있으면 사상누각을 짓기 쉽습니다. 하지만 사상누각은 신기루가 태반이니(현업에서 별 쓰잘데기 없다는 얘기죠), 일부분이라도 코드가 실제 개선되는 편이 결과적으로 낫습니다.


어떻게 리팩토링을 해야 하는가에 대한 사항을 잠시 짚어보자면, 기술적인 부분만 살펴보면 리팩토링은 어렵지 않은 작업입니다. 안 쓰이는 코드를 삭제하고, 변수나 함수명을 적절히 변경하고, 중복 코드를 제거하는등의 작업을 하면 됩니다. 하지만 실상 리팩토링은 어려운 작업입니다. 특히나 걸레같은 원본코드 앞에 아무런 히스토리도 알지 못하는 개발자에게는 더욱 그렇습니다.


워드에서 오타, 띄어쓰기, 단락 나누기는 기본입니다. 코드로 치자면 언뜻 보기에 그냥 외관상 좋은 정도가 되겠죠.  한권의 책을 예로 들면, 실제  스토리를 훼손하지 않으면서 읽기 편하게 바꾸려면 글의 내용을 완벽히 이해하고 있어야 합니다. 마찬가지로 실제 코드안으로 딥다이빙해서 코드를 완벽하게 이해하지 못하면 제대로 된 리팩토링을 할 수 없습니다.  전체 소프트웨어의 구조와 블록 다이어그램이라는 대관(大觀)으로부터 함수 하나하나의 실질적인 동작을 파악하는 세찰(細察)의 단계까지 필요한 것입니다.


리팩토링의 실제적인 방법에 대해서는 차차 얘기할 기회가 있을 것 같네요.


http://www.yes24.com/Product/Goods/108462627







매거진의 이전글 이슈에 대한 이슈, 두려움에 대한 두려움
작품 선택
키워드 선택 0 / 3 0
댓글여부
afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari