한빛출판네트워크

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



“리팩토링은 소프트웨어 시스템의 원래 기능은 그대로 두면서 내부의 구조를 개선하는 것을 의미한다. 그것은 버그의 가능성을 최소화하기 위해서 코드를 깔끔하게 정리하는 엄정한 방법이다. 한마디로 리팩토링을 한다는 것은 이미 작성된 코드의 설계를 나중에 개선하는 것이다.”
([Refactoring] 서문)

지난해인 2004년 봄 무렵에 컴퓨터 월간지 [마이크로소프트웨어]에 ‘프로그래밍은 예술이다’라는 제목의 칼럼을 기고한 적이 있었다. 재미있는 책과 글을 쓰는 프로그래머인 폴 그레이엄(Paul Graham)의 <해커와 화가(Hackers & Painters)>라는 글을 읽고 떠오른 영감을 토대로 쓴 칼럼이었는데, 도발적인 제목 때문이었는지 글을 읽은 사람들의 피드백이 적지 않았다.

컴퓨터 프로그래머로서 성공을 거둔 다음 ‘화가’의 길로 전향한 그레이엄은 프로그래밍에 있어서 ‘이론’을 학습하는 것보다는 코딩과 같은 구체적인 ‘행위’가 더 중요하다고 보았다. 피아니스트가 피아노의 내부구조와 악보를 이론적으로 학습하는 것보다는 직접 건반을 두드리면서 열정을 뿜어내는 것이 더 중요한 것처럼, 프로그래머가 키보드를 두드려서 열정과 상상력을 분출하는 것은 컴퓨터의 내부나 복잡한 이론을 학습하는 것보다 중요하다고 본 것이다. 그래서 그레이엄은 프로그래밍이라는 것이 엄격한 공학이나 과학보다는 자유분방한 예술적 행위에 더 가깝다고 생각했다. 즉, 그에게 프로그래밍은 ‘예술’이었다.

인공지능 언어인 LISP에 관한 교과서를 저술할 정도로 깊은 내공을 갖춘 프로그래머였던 그레이엄이 고백한 스스로의 프로그래밍 스타일은 마치 화가가 붓을 놀려서 그림을 완성해 나가는 것과 같은 점진적이고 반복적인 과정으로 이루어져 있었다. 그는 프로그래밍을 할 때 전체적인 설계를 마치고나서 코딩을 시작하기보다는 캔버스에 그림을 그릴 때처럼 조금씩 반복되는 작업을 통해서 코드에 살을 붙여 나갔다. 이 과정에서 키보드는 붓이 되고 모니터는 캔버스가 되었다. 이와 같은 그레이엄의 스타일에 대해서 필자는 ‘프로그래밍은 예술이다’에서 다음과 같이 말했다.

“뛰어난 프로그래머였던 그레이엄은 자기 자신도 프로그래밍을 할 때 키보드를 붙잡고 코딩부터 시작한다고 고백했다. 그가 밝힌 방법은 우선 가볍게 키보드를 두드리면서 코드의 전체 윤곽을 잡고, 다시 처음으로 돌아가서 조금씩 각 부분의 디테일을 살려 나가는 방식으로 프로그램을 작성하는 것이었다. 그는 코딩이 설계에 앞서는 이와 같은 방식을 조금도 이상하게 여기지 않았다. 오히려 그는 모든 예술적 창조가 대개 이와 비슷한 과정을 거치면서 이루어지며 그림을 그리는 과정도 이와 다르지 않다고 말했다. 그리고 미술에서는 그것을 ‘스케치’라는 자연스러운 이름으로 부른다고 지적했다.”

프로그래머 중에서 이와 같은 점진적인 방식으로 프로그래밍을 해본 적이 한 번이라도 없는 사람이 있을지 궁금하다. 필자가 말하고 싶었던 것은 설계와 코딩의 순서에 대한 것이 아니었다. 그것은 프로그래밍이라는 것이 이론적이고 관념적인 추론이 아니라 구체적이고 실질적인 행위를 중심으로 이루어지기 때문에 설계와 코딩의 구분에 지나치게 집착할 필요는 없다는 것이었다. 하지만 어떤 사람들은 이 글이 ‘코딩’이 ‘설계’에 앞서야 한다고 말하는 것으로 오해하고 비판을 가하기도 했다. 그건 오해지만 솔직히 말하자면 필자는 설계와 코딩을 인위적으로 구분할 수 있는 것인지, 혹은 그것이 바람직한 것인지 여부를 잘 모르겠다. 프로그래밍 경험이 쌓여갈수록 어쩐지 필자는 설계와 코딩을 엄격하게 구분할 필요가 없다고 느끼게 되는데, 게을러져서인지 아니면 정말 그럴 필요가 없기 때문인지 분명하지 않다.

하지만 설계와 코딩의 전통적인 관계를 좀 더 유연하게 바라보기 원했던 사람을 찾아보는 것은 어려운 일이 아니다. 사실 설계와 코딩의 관계는 소프트웨어의 개발을 효율적으로 만들기 위해서 사람들이 인위적으로 설정한 관계일 뿐이다. 만약 전통적인 소프트웨어 개발 방법론보다 더 효과적인 개발 방법론이 발견된다면 설계는 코딩의 뒤에 가서 줄을 서게 될지도 모르는 일이다. 이번 장에서 논의할 ‘리팩토링(refactoring)’의 ‘전도사’인 마틴 파울러(Martin Fowler)는 이러한 프로그래밍 방법론과 관련해서 다음과 같이 말했다.

“리팩토링이 코딩에 앞선 설계(upfront design)를 대체할 수 있다는 주장도 존재한다. 리팩토링을 염두에 둔다면 여러분은 설계를 할 필요가 전혀 없다. 머릿속에 가장 먼저 떠오르는 생각을 대충 코드로 구현한 다음, 그것이 제대로 동작하도록 수정하고, 리팩토링을 통해서 제대로 된 모양을 갖추도록 만들어 나간다. 사실 이와 같은 방법은 아무 문제가 없다. 나는 이러한 방법을 통해서 대단히 잘 설계된 소프트웨어를 완성한 사람들을 본 적이 있다.”
([리팩토링: 현존하는 코드의 설계를 개선하기 (Refactoring: Improving The Design Of Existing Code)] p67)

말하자면 집을 어떻게 짓더라도 고칠 방법은 있으니까 아직 눈에 보이지도 않는 집을 가지고 고민 하지 말고 일단 짓기부터 하라는 이야기이다. 진짜 집을 짓는 사람에게 이런 말을 한다면 엉뚱한 사람이라고 핀잔을 받겠지만 중력의 영향을 받지 않는 사이버 세계에서는 가능한 이야기이다. 이와 같은 프로그래밍 방법론을 체계적으로 정리한 예가 최근에 주목을 받고 있는 XP(eXtreme Programming)라고 볼 수 있다. 리팩토링과 XP는 하나의 철학을 공유하고 있는데, 그것은 세상의 모든 것이 변한다는 사실을 전제로 삼는 것이다. 프로그래머에게 세상의 모든 것이란 사용자의 요구사항과 이미 존재하는 코드, 이렇게 두 개일 뿐이다.

디즈니 만화가 전 세계적으로 누리는 상업적 성공에도 불구하고 문화 비평가들의 비판을 받는 이유 중의 하나는 내용이 너무나 비현실적이기 때문이다. 디즈니 만화에서 소재로 삼는 선과 악의 선명한 대립은 세상을 너무나 단순하게 구분하는 것이기 때문에 아이들에게 현실에 대한 잘못된 인식을 심어준다는 이야기이다. 그러나 프로그래밍의 세계에서 사용자의 요구사항과 이미 작성된 코드가 고정불변의 대상이라고 생각하는 것은 디즈니 만화의 비현실성을 훌쩍 뛰어넘는다. 현실 세계와 마찬가지로 프로그래밍의 세계에서 변하지 않는 것은 아무 것도 없기 때문이다.

설계가 이루어지는 동안 요구사항이 변하거나 코딩을 하는 동안 설계가 달라져야 하는 경우는 얼마든지 있을 수 있다. 그것은 엄연한 현실이다. 따라서 세상은 변하지 않으며 설계는 언제나 코딩의 앞에 존재해야 한다는 믿음은 중세의 형이상학이고 시간과 공간의 상대성을 인식하지 못한 뉴튼의 세계관이다. 그레이엄의 철학과 리팩토링의 관점은 이러한 점에서 중세의 형이상학을 극복하고 있다. 모든 것은 끊임없이 변화하며 시간과 공간은 상대적이라고 파악하는 리팩토링은 현대 철학이다. 설계와 코딩이라는 사이클이 단 한 번 돌아서 이루어지는 프로그래밍은 있을 수 없다는 사실을 정확하게 인식하고 있는 것이다.

그래서 리팩토링은 새로운 코드를 만들면서 미래를 향해 나아가는 프로그래밍이 아니라, 이미 존재하는 코드를 부수면서 과거로 뛰어드는 프로그래밍이다. 마치 미래의 전쟁에서 승리하기 위해서 과거로 뛰어든 영화 터미네이터의 주인공처럼 프로그래머는 과거로 돌아가서 미래를 코딩한다. 그 때 그들의 손에 들린 무기가 바로 리팩토링이다.