도대체 레거시 코드의 정체는 무엇일까? 난 여태 이 말을 제대로 정의도 하지 않고 사용해 왔다. 좀더 엄밀히 정의해 보면 레거시 코드는 다른 사람한테서 가져온 코드다. 우리 회사가 다른 회사로부터 코드를 얻어 왔을 수도 있고 원래 팀에 있던 사람들이 다른 프로젝트로 옮겨가서 코드를 얻어 왔을 수도 있다. 이처럼 레거시 코드는 단순히 다른 사람이 작성한 코드를 말하지만 프로그래머 입장에서 말하자면 이 말은 사실 그 이상을 의미한다. 시간이 지날수록 그 의미와 중요성에 대해 생각하게 만드는 용어다.

레거시 코드라는 말을 처음 들었을 때 어떤 생각이 들었는가? 당신이 나와 같은 생각을 했다면, 여기저기 얽힌 난해한 구조를 가져 제대로 알 수는 없지만 변경시켜야 하는 코드를 떠올렸을 것이다. 쉬울 것으로 생각했던 특징들을 추가하느라 며칠 밤을 지샌 추억을 떠올릴 수도 있고, 더 이상 어떻게 할 수 없는 코드에 질려 사기가 저하된 당신을 떠올릴 수 있다. 이런 경우 당신의 모든 노력은 무가치해 보인다. 레거시 코드의 정의는 누가 그 코드를 작성했는가와는 무관하다. 코드가 나빠지는 길은 여러 갈래가 있고, 실제로 그 중 대부분은 코드가 다른 팀에서 왔는지 여부와는 무관하다.

업계에서 레거시 코드는 이해할 수 없고 변경시키기 힘든 코드를 지칭하는 용어로 종종 사용된다. 하지만 지난 수년간 여러 팀들과 함께 작업하고 그 팀들이 여러 가지 심각한 코드 문제들을 해결하는 데 도움을 주면서 마침내 난 또 다른 정의에 다다르게 되었다.

내게 있어서 레거시 코드는 테스트 루틴이 없는 단순한 코드일 뿐으로서, 난 이 정의에 대해 유감을 가져왔다. 과연 코드 불량 여부와 테스트 루틴은 어떤 관련이 있을까? 내게 이 질문에 대한 답은 그다지 어렵지 않으며 이 책 전반에 걸쳐 난 이 점에 대해 상술할 것이다.

코드가 얼마나 훌륭하게 작성되어 있는지 여부와는 상관없이 테스트 루틴이 없는 코드는 불량 코드다. 얼마나 멋지게 작성되어 있는가와 객체지향의 사용 여부, 그리고 캡슐화의 정도도 참작 요소가 전혀 되지 못한다. 테스트 루틴이 있으면 코드의 동작을 빠르고 검증 가능하게 변경시킬 수 있다. 하지만 테스트 루틴이 없으면 실제로 우리 코드가 더 나아지는지 더 나빠지는지를 알 수 없게 된다.

지금까지는 심각한 경우를 설명했다. 깨끗한 코드인 경우에는 어떨까? 코드 베이스가 매우 깨끗하고 잘 정의된 구조를 가진다면 충분하지 않겠는가? 아마 실수를 저지르지는 않게 될 것이다. 난 깨끗한 코드를 좋아한다. 내가 아는 대부분의 사람들보다 훨씬 더 좋아할 것이다. 하지만 깨끗한 코드만으로는 충분하지 않다. 팀들은 테스트 루틴 없이 대규모 변경을 가하는 경우에 중대한 도전에 직면하게 될 것이다. 이것은 마치 안전그물망 없이 공중 곡예를 하는 것과 비슷하다. 이 작업은 엄청난 기술과 각 단계에서 어떤 일이 일어날지에 대한 명확한 이해를 필요로 한다. 당신이 변수 몇 개를 변경시켰을 때 어떤 일이 일어날지를 정확히 아는 것은 마치 당신이 공중에서 재주를 넘었을 때 다른 동료가 당신 팔을 잡아줄지 말지를 미리 아는 것과 같다. 당신이 깨끗한 코드를 가지고 일하는 팀의 일원이라면 다른 대부분 프로그래머보다 훨씬 더 좋은 상황에서 일하는 셈이다. 필자는 일하는 동안 모든 코드를 명쾌하게 이해하고 작업하는 팀들을 거의 본 적이 없다. 그들은 마치 통계적 예외사항인 것처럼 보인다. 그리고 당신이 지원 테스트 루틴 없이 작업한다면 코드 변경은 기존 방법에 비해 더 느리게 수행될 것이다.

어떤 팀들은 점점 나아지고 좀더 깨끗한 코드를 작성하기 시작할 수 있다. 하지만 오래된 코드가 깨끗해지는 데는 시간이 오래 걸린다. 그리고 많은 경우에 완전히 깨끗해지기란 거의 불가능하다. 그렇기 때문에 나는 레거시 코드를 테스트 루틴 없는 코드라고 정의할 수 있다. 이것은 현재 사용되는 정의이며 해결책을 지시하기도 한다.

난 지금까지 테스트 루틴에 대해 이야기해 왔으나 이 책은 테스트에 대해 얘기하지는 않을 것이다. 이 책은 어떤 코드 베이스에서도 확신을 가지고 변경을 가할 수 있는 방법을 다룬다. 여러 장에 걸쳐서 코드를 이해하고 코드를 테스트 루틴 하에 두며 코드를 리팩토링하고 특징을 추가하는 기법을 설명할 것이다.

여러분이 이 책을 읽어가는 데 있어서 유의해야 할 점 중 하나는 이 책이 훌륭한 코드에 대해 설명하는 책은 아니라는 사실이다. 나는 고객과의 비밀유지 협정을 맺고 일하기 때문에 이 책에서 사용한 예제들은 모두 책에 넣기 위해 특별히 새로 만들었다. 하지만 대부분 예제에서 나는 현업에서 보아 왔던 정신을 코드에 그대로 유지하려고 애썼다. 모든 예제들이 상황에 맞는 대표적인 것들인지슴 장담할 수 없다. 분명히 이것들보다 훨씬 훌륭한 코드가 많을 것이고, 반대로 내가 사용한 예제보다 훨씬 못한 코드들도 있을 것이다. 고객 비밀유지 사항에 대한 고려 이외에도, 내용이 너무 지루해 눈물이 날 지경에 이르거나 세부내용의 늪에 빠져 허우적거리지 않도록 내용을 채우는 데 애썼지만 실제로는 그렇게 저술할 수밖에 없었다. 결과적으로 몇 개의 예제들은 상대적으로 간결해졌다. 그 중 몇 개를 들여다 보면 "아니야, 이 친구는 내가 작업하는 메소드들이 여기에 있는 것들보다 훨씬 더 거대하고 훨씬 더 고약하다는 걸 이해하지 못하고 있군"이라는 생각이 들 수도 있다. 하지만 예제가 단순해 보이더라도 제발 제시하는 충고를 액면 그대로 받아들이고 그 충고가 어떻게 적용되는지를 살펴보라.

여기에 제시하는 기법들은 내가 꽤 큰 코드 조각들에 테스트해 왔던 것들로, 책 포맷의 제약으로 인해 예제를 작게 만들었을 뿐이다. 특히 여러분이 다음과 같이 코드 조각 내에서 생략 기호(…)를 보게 되면 "500줄에 이르는 코드가 더 있겠구나"라고 생각하면 된다.

m_pDispather->register(listener);
…
m_nMargins++;

이 책이 훌륭한 코드에 대한 책이 아니듯이 훌륭한 설계에 대한 책은 더더욱 아니다. 훌륭한 설계는 우리 모두가 추구하는 목표이긴 하지만, 레거시 코드에서는 몇 단계를 거치면 다다르게 되는 것이다. 몇개 장에서는 기존 코드 베이스에 새로운 코드를 추가하는 법과 훌륭한 설계 기법을 염두에 두고 코드를 추가하는 방법을 설명했다. 여러분은 레거시 코드 베이스 안에 있는 우수한 코드 부분에서 시작해 그 부분을 확대해 나가는 식으로 작업을 시작할 수 있다. 하지만 변경을 가하는 데 필요한 단계들을 밟다 보면 약간의 코드가 더 보기 흉하게 될 수도 있는데 그렇다고 놀라지는 말자. 이러한 작업은 외과 수술과 같다. 여러 곳을 절개해야만 하고 내장 사이를 관통해야 하며 미학적인 판단은 유보해야 할지도 모른다. 이 환자의 주요 기관과 내장은 이전보다 나아질 수 있을까? 물론이다. 환자의 긴급한 문제에 대해서는 잊어버리고 절개부위를 봉합한 후에 환자에게 잘 먹고 꾸준한 운동을 하라고 말한다. 물론 이렇게 할 수도 있으나 우리에게 진정 필요한 것은 환자를 있는 그대로 보고 그가 가진 문제를 고쳐 좀더 건강한 상태가 되도록 이끄는 것이다. 다시는 국가대표 육상선수가 되지는 못하겠지만 '최상의 상태'가 '더 나빠지지'는 않게 할 수 있다. 코드 베이스는 더 건강하고 작업하기 쉽게 변경될 수 있다. 환자가 더 낫다고 느낀다면, 그 때가 바로 환자가 좀더 건강한 라이프 스타일을 약속할 수 있도록 도와줄 만한 적기인 것이다. 이것이 바로 우리가 레거시 코드를 가지고 달성하려는 바이다. 우리는 편안함을 느끼는 지점에까지 다다르려고 노력한다. 그 지점에 이를 때까지 열심히 노력하고 또한 코드 변경이 용이해지도록 노력한다. 팀 내에 이러한 정신을 계속 주입한다면 설계는 향상될 것이다.

여기에 소개하는 기법들은 동료들이나 고객들과 일하면서 발견하고 그들에게서 배운 것이다. 오랜 기간 고객들과 일하면서 규칙 없이 짜여진 코드 베이스들에 대한 제어를 만드는 과정에서 나온 것이다. 나는 우연하게 이러한 레거시 코드에 대해 주목하기 시작했다. 처음으로 오브젝트 멘토(Object Mentor)와 관련된 일을 했을 때, 나는 많은 중요한 문제를 가진 팀들이 고품질 코드를 정기적으로 인도하는 단계에 이를 때까지 그들의 기술과 상호작용하는 법을 개발하면서 많은 경험을 쌓았다. 우리는 종종 팀들이 각자의 작업을 제어하고 서로 잘 협력하며 인도하는 데 도움을 주고자 익스트림 프로그래밍(XP, Extreme Programming) 방법론을 사용했다. 난 종종 XP는 훌륭한 소프트웨어를 2주마다 릴리스해야 하는 임무를 가진 잘 훈련된 팀을 만드는 데 사용되기보다는 소프트웨어를 개발하는 데 사용할 수 있는 방법이라고 느낀다.

하지만 처음부터 문제가 하나 있었다. 초창기 XP 프로젝트의 상당수는 '그린필드(Greenfield)' 프로젝트들이었다. 내가 만나는 고객들은 엄청나게 거대한 코드 베이스들을 가지고 있었고 그들은 문제에 직면해 있었다. 그들은 자신들의 작업을 제어하고 제품을 인도하게 해주는 방법을 필요로 했다. 시간이 지나면서 내 자신이 고객들과 동일한 일을 반복하고 있음을 깨달았다. 결국 이런 인식은 그 당시 함께 일하던 금융기업 팀과의 작업에 어떤 영향을 주었다. 내가 오기 전까지만 해도 그들은 단위테스트는 훌륭하다고 생각해 왔다. 하지만 그들이 가지고 있던 테스트 루틴은 데이터베이스에 여러 번 접근해 큰 덩어리의 코드를 돌리는 작업을 하면서 시나리오 전체를 실행하고 있었다. 테스트 루틴들은 작성하기 힘들었고 그 팀은 실행하는 데 너무 긴 시간이 걸린다고 생각해서 테스트 루틴을 자주 돌리지는 않고 있었다. 의존관계를 깨기 위해 그들과 같이 앉아 ?은 코드 덩어리를 테스트 하에 두자 갑자기 데자뷰(d?j? vu), 즉 기시감(旣視感)을 느끼게 되었다. 마치 이 같은 작업을 지금까지 만났던 모든 팀들과 해온 듯한 묘한 기분을 느꼈는데, 이는 그 어떤 사람도 원치 않는 그런 감정이었다. 그것은 코드를 제어해야 할 때 필요한 중노동에 가까운 작업이다. 그래서 나는 이러한 문제들을 어떻게 해결했는지 책으로 남겨 어려움에 처한 팀들이 코드를 더 쉽게 활용하도록 돕기로 결심했다.

이 책에 사용된 예제들은 자바, C++, C 등 다양한 프로그래밍 언어로 작성됐다. 먼저 자바는 가장 많이 사용되는 언어이다. C++ 는 레거시 환경에서 맞닥뜨릴 수 있는 여러 가지 도전과제들을 보여준다. 또한 C 언어는 절차형 레거시 코드에서 나타나는 여러 가지 문제를 강조하는 데 도움을 준다. 많은 언어 중 위에 언급한 언어들은 레거시 코드에서 발생할 수 있는 여러 가지 관심범위를 포함한다. 당신이 사용하는 언어가 예제에 사용되지 않았다고 해도 예제를 한번 보길 바란다. 예제에서 사용한 여러 가지 기법들은 델파이(Delphi), 비주얼 베이직(Visual Basic), 코볼(COBOL), 포트란(FORTRAN)과 같은 다른 언어들에도 활용할 수 있다.

이 책에 있는 기법들이 많은 도움이 되고 또한 당신이 프로그래밍에 재미를 느끼는 데 좋은 계기가 되길 바란다. 프로그래밍은 매우 보람 있고 즐거운 작업이다. 일상에서 아직까지 이런 기분을 느끼지 못했다면 부디 이 책에서 제공한 기법들에서 보람과 즐거움을 찾게 되길 바란다.

--- 저자 서문

최근에 코드 개선과 유지보수 편의를 위한 많은 혁신적인 프로그래밍 언어들과 개발 기법들이 새롭게 만들어져 소개되고 있습니다. 이런 훌륭한 도구들을 사용해 작업하는 데도 아직 많은 개발자들은 기존에 있던 레거시 코드를 변경하고 유지보수하는 일에 많은 시간과 비용을 쏟으며 개선하는 일이 "어렵다"고 호소하고 있습니다. 이 책에서도 집중적으로 다루는 내용이지만, 대부분 기존 소프트웨어는 레거시 코드에서 매우 중요한 개념인 감지(sensing), 분리(separation), 봉합(seams) 같은 개념들을 염두에 두지 않고 작성되었기 때문에 변경하고 유지보수하는 일이 큰 골칫덩어리로 남아 있습니다.

이 책은 조직 내 요구사항의 변화와 외부환경 변화에 부응하기 위해 새로운 특징을 추가하고 버그를 고치고 소프트웨어 설계를 개선하고 자원 이용률을 최적화할 목적으로, 소프트웨어를 잘게 나누고 다시 통합해서 테스트를 위한 코드를 추가하는 등 소프트웨어를 변경하는 데 관련된 내용을 광범위하게 다루고 있습니다. 특히 소프트웨어를 효과적으로 고치는 데 필요한 다양한 기법을 C++, 자바, 루비 코드 예제로 설명하고 있어서 독자가 관련 기법을 쉽게 익힐 수 있도록 도와주고 있습니다. 부디 이 책을 통해 독자 여러분들이 좀더 많이 배우며 생각함으로써 발전하고, 그로 인해 생산성이 높아져 우수한 소프트웨어를 개발할 수 있게 되기를 바랍니다.