어떤 팀들은 점점 나아지고 좀더 깨끗한 코드를 작성하기 시작할 수 있다. 하지만 오래된 코드가 깨끗해지는 데는 시간이 오래 걸린다. 그리고 많은 경우에 완전히 깨끗해지기란 거의 불가능하다. 그렇기 때문에 나는 레거시 코드를 테스트 루틴 없는 코드라고 정의할 수 있다. 이것은 현재 사용되는 정의이며 해결책을 지시하기도 한다.
난 지금까지 테스트 루틴에 대해 이야기해 왔으나 이 책은 테스트에 대해 얘기하지는 않을 것이다. 이 책은 어떤 코드 베이스에서도 확신을 가지고 변경을 가할 수 있는 방법을 다룬다. 여러 장에 걸쳐서 코드를 이해하고 코드를 테스트 루틴 하에 두며 코드를 리팩토링하고 특징을 추가하는 기법을 설명할 것이다.
여러분이 이 책을 읽어가는 데 있어서 유의해야 할 점 중 하나는 이 책이 훌륭한 코드에 대해 설명하는 책은 아니라는 사실이다. 나는 고객과의 비밀유지 협정을 맺고 일하기 때문에 이 책에서 사용한 예제들은 모두 책에 넣기 위해 특별히 새로 만들었다. 하지만 대부분 예제에서 나는 현업에서 보아 왔던 정신을 코드에 그대로 유지하려고 애썼다. 모든 예제들이 상황에 맞는 대표적인 것들인지는 장담할 수 없다. 분명히 이것들보다 훨씬 훌륭한 코드가 많을 것이고, 반대로 내가 사용한 예제보다 훨씬 못한 코드들도 있을 것이다. 고객 비밀유지 사항에 대한 고려 이외에도, 내용이 너무 지루해 눈물이 날 지경에 이르거나 세부내용의 늪에 빠져 허우적거리지 않도록 내용을 채우는 데 애썼지만 실제로는 그렇게 저술할 수밖에 없었다. 결과적으로 몇 개의 예제들은 상대적으로 간결해졌다. 그 중 몇 개를 들여다 보면 "아니야, 이 친구는 내가 작업하는 메소드들이 여기에 있는 것들보다 훨씬 더 거대하고 훨씬 더 고약하다는 걸 이해하지 못하고 있군"이라는 생각이 들 수도 있다. 하지만 예제가 단순해 보이더라도 제발 제시하는 충고를 액면 그대로 받아들이고 그 충고가 어떻게 적용되는지를 살펴보라.
여기에 제시하는 기법들은 내가 꽤 큰 코드 조각들에 테스트해 왔던 것들로, 책 포맷의 제약으로 인해 예제를 작게 만들었을 뿐이다. 특히 여러분이 다음과 같이 코드 조각 내에서 생략 기호(…)를 보게 되면 "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)과 같은 다른 언어들에도 활용할 수 있다.
이 책에 있는 기법들이 많은 도움이 되고 또한 당신이 프로그래밍에 재미를 느끼는 데 좋은 계기가 되길 바란다. 프로그래밍은 매우 보람 있고 즐거운 작업이다. 일상에서 아직까지 이런 기분을 느끼지 못했다면 부디 이 책에서 제공한 기법들에서 보람과 즐거움을 찾게 되길 바란다.
레거시 코드란 무엇일까? 지금까지 이 단어의 뜻을 정의하지 않고 사용했다. 엄밀히 말하면, 레거시 코드는 다른 누군가로부터 이어받은 코드라고 정의할 수 있다. 회사 차원에서 다른 회사로부터 구입한 코드일 수도 있고, 부서 이동으로 인해 다른 팀원에게 인계된 코드일 수도 있다. 이처럼 레거시 코드는 다른 누군가의 코드를 의미하지만, 프로그래머들에게 이 단어는 그 이상의 의미를 갖고 있다. 레거시 코드라는 단어는 시간의 흐름과 함께 더 많은 의미와 무게를 갖게 된 것이다.
레거시 코드라는 말을 들으면 여러분은 어떤 생각이 드는가? 나와 비슷한 생각이 든다면, 여기저기 얽힌 난해한 구조 때문에 제대로 이해하지 못하면서도 수정해야만 하는 코드가 떠오를 것이다. 겉보기에는 쉬워 보였던 기능을 추가하느라 며칠 밤을 지샌 추억이 떠오를 수도 있고, 더 이상 어떻게 할 수 없는 코드에 질려서 무력감에 빠진 모습이 떠오를 수도 있다. 이런 상황에서 당신의 노력은 무가치한 일처럼 느껴진다. 레거시 코드의 정의는 사실 누가 그 코드를 작성했는가와 무관하다. 코드는 다양한 방법으로 부패하며, 대부분의 경우 다른 팀으로부터 가져온 코드인지 여부와는 무관하다.
소프트웨어 업계에서 레거시 코드란 이해할 수 없고 수정하기도 힘든 코드를 지칭하는 속어처럼 사용될 때가 많다. 하지만 지난 수년간 고객들과 심각한 코드 문제들을 해결하는 공동 작업을 통해 나는 레거시 코드를 다르게 정의하게 됐다.
내게 레거시 코드란, 단순히 테스트 루틴이 없는 코드다. 다만 이 정의는 다소 불완전하다. 코드의 좋고 나쁨이 테스트와 어떤 관계가 있을까? 이 질문에 대한 답은 간단하다. 이것이 바로 이 책 전반에 걸쳐 자세히 설명할 핵심이다.
이 책은 어떤 코드베이스에서도 확신을 갖고 수정 작업을 하는 방법을 설명하는 책이다. 이 책의 각 장은 코드를 이해하고, 테스트 루틴을 사용하며, 리팩토링을 수행하고, 기능을 추가하는 기법들을 설명할 것이다.
고객들은 대규모의 코드베이스 작업에 어려움을 겪고 있었기 때문에 개발 작업을 통제하고 제품을 정상적으로 인도할 수 있는 방법론을 필요로 했다. 하지만 시간이 흐르면서, 고객이 바뀌어도 내가 하는 작업은 매번 비슷하다는 사실을 깨닫게 됐다. 이런 느낌은 어느 금융 회사 개발 팀과 협업하면서 최고조에 달했다. 내가 합류하기 전부터 이 개발 팀은 단위 테스트의 필요성을 인식하고 있었지만, 실제 사용 중이던 테스트 루틴은 데이터베이스에 몇 번이나 접근해서 대규모의 코드를 실행하는 전체 시나리오 테스트였다. 당연히 테스트 루틴을 작성하기가 쉽지 않았고, 실행에 너무 오랜 시간이 걸리기 때문에 이 개발 팀은 테스트 루틴을 자주 실행하지 않고 있었다. 이런 현실을 개선하기 위해 팔을 걷어붙이고 테스트 코드의 크기를 줄이는 작업을 하다가 나는 데자뷰(기시감)를 느끼게 됐다. 지금까지 함께 일했던 모든 팀들과 이런 종류의 작업을 했던 것 같았으며, 이 작업은 코드를 적절히 통제하기 위해 어쩔 수 없이 거쳐야만 하는 단순 반복적이고 지루한 작업이었다. 그래서 나는 이러한 문제를 어떻게 해결했는지 책으로 남김으로써, 비슷한 어려움에 처한 다른 팀들이 코드를 좀 더 편하게 개선할 수 있도록 도울 필요가 있다는 결론을 얻었다.
이 책에 사용된 예제들은 대부분 자바, C++, 혹은 C로 작성됐다. 이 언어들을 선택한 것은 자바는 가장 많이 사용되는 언어이기 때문이고, C++는 레거시 환경에서 특별한 도전 과제를 던지는 언어이기 때문이며, C는 절차형 레거시 코드에서 자주 볼 수 있는 문제들을 배울 수 있게 해주는 언어이기 때문이다. 이를 통해 레거시 코드에서 발생하는 문제점의 대부분을 포괄할 수 있다. 독자가 이 언어들을 사용하지 않더라도 예제는 도움이 될 수 있다. 델파이, 비주얼 베이직, 코볼, 포트란 등의 언어들에서도 활용 가능한 기법들이기 때문이다.
이 책의 기법들이 현업에 도움이 될 뿐 아니라 프로그래밍의 재미를 회복하는 계기도 되길 바란다. 프로그래밍은 매우 보람 있고 즐거운 작업이다. 현업의 일상 업무에서 이런 기분을 느끼지 못하고 있다면, 이 책에서 제공되는 기법들을 통해 재발견하고 팀 전체에 전파하기를 희망한다.
