한빛출판네트워크

저자: 임백준
출처: 임백준의 소프트웨어 산책(2005, 한빛미디어) 중 제3장 리팩토링



* 리팩토링(1) - 과거와 대결하는 프로그래머의 무기
* 리팩토링(2) - 복잡성에 대한 두려움
* 리팩토링(3) - 단순함의 미학

컴퓨터 프로그래밍 세계에서 명멸한 많은 개념과 아이디어들은 공동의 작업을 통해서 탄생한 경우가 많다. 그렇게 공동의 작업 속에서 자연스럽게 탄생한 개념에 대해서 특정한 개인을 ‘창시자’로 꼽는 것은 쉬운 일이 아닐 뿐만 아니라 별로 의미도 없다. 예를 들어서 절차적(procedural) 프로그래밍의 한계를 혁명적으로 돌파한 ‘객체’ 개념의 경우에는 굳이 누구 한 사람을 창시자라고 꼽기는 어렵다. 그래서 프로그래밍 세계에서는 어떤 개념을 처음에 ‘창안’한 사람이 누구인가보다는, 그 개념을 프로그래머 사회가 받아들일 수 있도록 잘 설득하고 전파한 사람이 누구인가가 중요한 경우가 더 많다.

리팩토링에 대해서 말하자면 80년대에 스몰토크(Smalltalk) 프로그래머였던 와드 커닝험(Ward Cunningham)과 켄트 벡(Kent Beck)이 처음으로 ‘개념’을 정립한 사람에 해당했다. 스몰토크는 C나 C++ 같은 언어에 비해서 컴파일(compile), 링크(link), 그리고 실행에 이르는 주기가 더 짧았기 때문에 다른 언어보다 상대적으로 동적인 프로그래밍 환경을 제공했다. (코딩에서 실행에 이르는 과정이 더 빨랐다는 의미이다.) 그와 같은 동적인 환경은 커닝험과 벡이 리팩토링의 핵심을 이루는 ‘코딩하고’, ‘테스트하고’, ‘코딩하고’, ‘테스트하는’ 경쾌한 리듬을 반복하는 프로그래밍 습관을 기르는데 도움이 되었다. 그들은 그러한 리듬을 몸에 익히면서 이미 코딩한 프로그램을 다시 고치는 행위를 자연스럽게 여기는 리팩토링의 개념을 정립해 나갔다.

그렇지만 리팩토링이라는 개념이 처음으로 고개를 내밀던 순간에는 그것이 스몰토크를 이용하는 소수의 프로그래머 사회에 제한되어 있었다. 그것을 제한된 공간에서 끄집어내어 C++와 같이 보다 대중적인 언어를 사용하는 다수에게 보급한 것은 당시 일리노이 주립대학에서 박사논문을 준비하고 있던 윌리엄 옵다이크(William Opdyke)였다. 옵다이크는 현재 일리노이주에 있는 감리교단의 대학인 노스 센트럴 대학(North Central College)에서 컴퓨터 과목을 강의하는 교수로 재직하면서 프로그래밍도 수행하고 있다.

그가 당시에 쓴 박사 논문의 주제는 리팩토링을 중심으로 하는 프레임워크(framework)의 개발 방법론과 자동화 도구(automated tool)에 관한 것이었다. 마틴 파울러가 쓴 리팩토링의 고전 <리팩토링(Refactoring)>의 13장인 “리팩토링, 재사용, 그리고 현실(Refactoring, Reuse, and Reality)"에서 옵다이크가 밝힌 바에 의하면 그가 소프트웨어의 유지보수를 돕는 프레임워크와 리팩토링에 관심을 갖게 된 이유는 벨연구소(Bell Labs)에서 다년간 프로그래머로 근무하면서 겪었던 ‘실전 경험’에 뿌리를 두고 있었다.

“소프트웨어 제품의 생명주기는 보통 수십 년에 이르렀다. 이런 시스템을 개발하는 비용의 대부분은 초기 버전(release)을 개발하는데 들어가는 것이 아니라 시간이 흐르면서 시스템을 수정하고 변경하는데 들어갔다. 그러한 수정을 좀 더 용이하게 만들고 비용도 적게 들어가게 만든다면 회사의 입장에서 보았을 때 큰 이익을 남길 수 있으리라는 점은 분명했다.”
(<리팩토링> p380)

그가 처음에 관심을 가졌던 부분은 사실 리팩토링이 아니라 C++와 같은 객체 지향 언어로 작성된 코드를 쉽게 수정하도록 만드는 도구나 프레임워크의 개발이었다. 옵다이크는 한때 벨연구소에서 네트워크 장비인 스위치(switch)에 들어가는 프로그램을 개발했다. 지금은 루슨트 테크놀로지스사의 연구소이지만 당시에는 AT&T사의 연구소였던 벨연구소는 C, C++ 언어와 유닉스의 산실로 잘 알려져 있다. 그 곳에서 5년을 근무한 필자는 네트워크 장비 안으로 들어가는 소프트웨어를 개발한 것이 아니라, 네트워크 토폴로지(topology)를 관리하는 프로그램을 개발했기 때문에 분야가 다르긴 하지만, 귀에 들려오는 풍월을 통해서 네트워크 장비 내부로 들어가는 소프트웨어 코드가 어떤 모습을 하고 있는지 대충은 짐작하고 있었다.

지금도 그렇지만, 당시 벨연구소에는 유닉스, C, C++에 관한한 둘째가라면 서러워할 고수들이 차고 넘치고 있었기 때문에 그들이 작성한 소프트웨어는 기능이나 성능 면에서 뛰어난 품질을 자랑했다. 하지만 그들이 작성한 코드는 대개 오직 그들만이 관리할 수 있었다. 문제는 바로 그것이었다. 그들과 비슷한 수준의 초 절정 ‘고수’가 아닌 (필자와 같은) 평균적인 수준의 프로그래머에게는 그들이 작성한 코드에 새로운 기능을 추가하거나 버그를 잡는 일이 쉬운 일이 아니었다. ‘단순함의 미학’을 알지 못했거나, 어쩌면 알았더라도 내심 경멸했을 가능성이 농후한 ‘해커’ 지향적인 철학을 품고 있었던 그들은 누구나 읽고 이해할 수 있는 코드를 작성하는 대신 두꺼운 양피지 위에 신비하고 이국적인 주술로 가득 찬 낯선 문자를 써내려갔다.

한 줄의 코드를 수정하기 위해서 10줄, 100줄에 이르는 코드를 덩달아 고쳐야 하는 상황에서 고민하던 옵다이크는 복잡한 코드를 편하게 청소하는 방법에 대해서 연구했다. 그리고 그 연구는 그를 리팩토링의 개념으로 이끌었다. 옵다이크는 해마다 열리는 “객체 지향 프로그래밍, 시스템, 언어, 그리고 어플리케이션(Object-Oriented Programming, Systems, Languages, and Applications)”의 1992년 콘퍼런스에서 마틴 파울러를 만났다. 차 한 잔을 함께 마시는 동안 그는 리팩토링에 대한 자신의 구상을 파울러에게 설명했다. 하지만 그의 설명을 들은 파울러의 반응은 미지근한 격려에 불과했다. 오늘날 리팩토링 군단의 야전 사령관 역할을 맡고 있는 사람이 바로 파울러라는 점을 생각하면 당시에 보였던 그의 반응은 다소 놀라운 것이었다. 파울러는 훗날 그 순간에 대해서 이렇게 회상했다.

“빌은 나에게 자기의 연구 주제를 열심히 설명했다. 그러나 내 느낌은 그저 그랬다. 재미있는 구상이긴 하지만, 글쎄, 그게 그렇게 중요할 것 같지는 않은데, 라는 정도였다. 세상에. 나의 예상은 그 정도로 빗나갔다!”
(<리팩토링> p72)

예상이 빗나간 것은 파울러만이 아니었다. 박사 학위를 받고 벨연구소로 돌아온 옵다이크는 그곳에 있는 동료 프로그래머들에게 리팩토링의 의미심장함에 대해서 역설하기 시작했다. 하지만 그들이 보인 반응은 파울러처럼 미지근한 정도도 아니고 아예 냉담했다. 파울러는 적어도 리팩토링의 의미를 이해하기라도 했지만, 벨연구소의 프로그래밍 고수들은 리팩토링이라는 엉뚱하고 지루한 절차에 대해서 거의 관심조차 기울이지 않았다. 프로그램을 수정하는 기상천외한 방법들이 이미 머리 안에 차고 넘치도록 들어있는 고수들에게는 프로그램을 수정하는 방법을 체계화하려는 시도가 아무 의미 없는 시간 낭비로밖에 보이지 않았다.

하지만 객체 지향 언어의 사용이 광범하게 확산되고, 끓는 물처럼 제멋대로인 복잡한 시스템을 길들여야 하는 프로그래머의 필요성이 증대하면서 리팩토링의 중요성은 주목을 받게 되었다. 파울러나 켄트 벡 같은 ‘객체지향 개발 방법론’의 전도사들이 리팩토링 진영에 속속 참여하면서 리팩토링은 차츰 진지한 주제로 인정받기 시작했다. 프로그래밍의 고수들은 머릿속에 들어있던 리팩토링의 초식을 밖으로 꺼내어 심각하게 토론했고, 공통의 틀을 마련해서 프로그래밍을 돕는 도구로 전환시키려고 노력했다. 그러한 노력을 통해서 파울러, 켄트 벡, 옵다이크 등이 리팩토링의 초식을 집대성한 <리팩토링>을 만들어냈다. 그 책은 출판됨과 동시에 프로그래밍 세계의 필독서로 자리를 잡게 되었다.