레거시 코드를 바라보는 겸손한 시선 "나쁜 코드도 돌아가면 성공이다"

'모든 코드는 레거시 코드'라는 말을 들어본 사람이 있을 것이다. 이 명제는 유용한 원칙이며 반면 인정하고 싶지 않은 사실이기도 하다.

모든 코드가 레거시 코드라면 우리 모두는 유지 관리자다. 세상을 돌아가게 하는 코드의 대부분을 묵묵히 유지보수하는 부지런하고 헌신적인 코더의 광활한 바다를 머릿속에 그려본다. 필자가 바로 그런 코더 중 한 명이기 때문이다.
 

ⓒ Getty Images Bank

지난 15년 동안 필자는 30년 된 코드를 직접 유지 관리하거나 유지 관리 개발자를 관리해 왔다. 해커 뉴스 같은 사이트에서 최첨단 주제를 놓고 토론하는 모든 개발자들 중 7~8명은, 실행 중인 코드의 상당 부분이 1987년 터보 파스칼 3.0으로 작성되었음에도 불구하고 현재 버전의 윈도우에서 인벤토리 시스템을 계속 실행하기 위해 조용히 애쓰고 있다.

“내가 아는 최악의 프로그래머는 6개월 전의 나"라는 말도 있다. 하지만 필자는 그보다 더 나쁜 프로그래머를 알고 있다. 바로 37년 전에 그 코드를 작성한 개발자(아마도 필자 본인이었을 것이다)이다.

필자는 그 사람이 한 일을 해독하기 위해 꽤 많은 시간을 보냈다. 도대체 무슨 생각을 한 걸까? 13개의 중첩된 if 문이 좋은 생각일까? 다섯 개의 연동 불리언(Boolean) 조건이 네 번째 중첩 문에 들어가야 한다고 결정한 사람은 누구일까? 설명 변수에 대해 들어본 적도 없었을까? 리터럴 값 4는 도대체 무슨 뜻일까? 프로시저 하나에 9280줄은 좀 많은 것 같지 않나?

그래서 고개를 갸우뚱거리며 퍼즐을 맞추고 버그를 수정한다. 아니면 수천 줄의 코드 프로시저에 새로운 기능을 끼워 넣기도 한다. 그리고 그 코드가 여전히 실행되고, 여전히 (대부분) 작동하며, 여전히 살아 있다는 사실에 놀라움을 금치 못한다.

물론 당시 개발자가 했던 미친 짓을 비웃을 수도 있다. 하지만 약간의 겸손함이 필요하다는 생각이 들었다. 지난 수십 년의 지혜가 담긴 현대의 눈에는 그 코드가 끔찍해 보일 수 있다. 하지만 그 당시에는 더 나은 방법을 몰랐을 수도 있다.
 

거인의 어깨 위에 서다

당시의 도구는 오늘날 우리를 움찔하게 만드는 코드를 작성하도록 자연스럽게 권장했다. 우리가 유지 관리하는 코드의 대부분은 'onClick' 시대에 만들어진 것이다. 1990년대에는 “신속한 애플리케이션 개발”(RAD)이 대세였고, 비즈니스 로직을 사용자 인터페이스에 긴밀하게 연결하는 것이 요구됐다. 버튼을 두 번 클릭하고 코딩을 시작하라! 이보다 더 좋을 수 있을까?

당시에는 관리 보조자가 RAD 도구를 사용해 개발자를 퇴출시킬까 봐 모두 걱정했다. 이제 그 자리는 인공지능이 차지했다. 숙련된 개발자 일자리를 잃게 할 다음 대상이 무엇이 될지 생각하고 싶지도 않다. (그런 일이 일어날 것이라고 믿지는 않지만 그렇다고 전문가들이 겁을 주는 것을 막지는 못한다.)

터보 파스칼과의 어색한 춤은 우리가 지금 작성하는 코드가 37년 후 어떤 개발자(어쩌면 여러분이 될 수도 있다)에게는 똑같은 방식으로 보일 수 있다는 사실을 상기시킨다.

프로그래머라는 직업은 성장하고 발전하며 더 나은 방법을 찾아낸다. 우리는 거인의 어깨 위에 서 있다. 마틴 파울러, 로버트 C. “밥 삼촌” 마틴, 켄트 벡, 마이클 페더스, 그레이디 부치 같은 소프트웨어 엔지니어는 오늘날 모두가 당연하게 여기는 관행을 발견하고 성문화한 사람들이다.

예를 들어, 객체 지향 프로그래밍(OOP)은 코드 작성 방식에 혁명을 일으켰다. 하지만 오늘날의 OOP 방식은 10년 또는 15년 전과는 크게 달라졌다.

우리는 수많은 OOP 코드를 작성하면서 “상속보다 구성을 선호한다”, “캡슐화가 가장 중요한 기둥이다”와 같은 원칙을 알아냈다. 밥 마틴이 2000년에 SOLID 원칙을 개발한 것은 힘든 경험을 통해 얻은 것이었다.

벡은 2000년대 초반이 되어서야 테스트 중심 개발을 통해 더 나은 코드를 작성하는 방법을 가르치기 시작했다. 파울러는 2004년에야 “의존성 주입”이라는 용어를 도입했다. 오늘날에도 사람들은 추상화에 대해 충분히 코딩하지 않는다. 모두가 더 나은 방법을 찾기 전에 결합된 다중 책임 추상 코드가 많이 작성되었지만, 우리는 여전히 이러한 방식이 옳은지, 이러한 방식이 실제로 코드를 더 좋게 만드는지에 대해 논쟁을 벌이고 있다.
 

다시 처음으로

다시 현재 상황으로 돌아와 보자. 필자는 수년 동안 코드에 대해 징징대고 불평했음을 고백하지 않을 수 없다. 어떻게 이런 엉터리 코드를 작성할 수 있는지 의아해하며 고개를 절레절레 흔들곤 했죠. 모든 코드를 다시 작성해야 하는데 도대체 이게 어떻게 작동할 수 있냐고 생각했다.

하지만 어느 순간 이런 코드도 잘 작동한다는 것을 깨닫게 되었다. 기업의 컴퓨터에서 실제로 작동한다는 사실을 말이다. 그리고 필자는 그 점을 존중하기로 결정했다. 물론 문제를 고치는 데는 생각보다 많은 시간이 걸리고 기능을 추가하면 '나쁜' 코딩 관행이 강화되는 경우가 많지만, 궁극적인 목표는 코드가 작동하는 것이기 때문이다.

“더 좋게 만들려면 다시 작성해야 해"라고 말하고 싶은 유혹이 강하고, 어쩌면 그것이 장기적으로 더 나은 해결책일 수도 있다. 말로 하기는 어려운 경우가 많다. 하지만 ‘오래된’ 코드의 경우 “버그를 수정하고 무슨 일이 있어도 올바르게 작동하도록 만드는 것”이 일종의 ‘더 나은’ 방법일 수도 있다. 때로는 버그를 수정하고 1500줄짜리 프로시저에 10줄의 코드를 더 추가하는 것이 옳은 방법일 수도 있다.

그래서 필자는 현대인의 눈에는 거의 이해가 되지 않는 코드를 작업하면서 그 코드가 작성되었을 때는 아마 멋지고 혁신적이며 흥미로웠을 것이라는 점을 기억하려고 노력한다. 그 코드를 작성한 사람은 자신이 가진 것과 아는 것을 가지고 최선을 다했을 것이다.

그리고 언젠가 오늘 작성한 새롭고 현대적이며 멋진 코드를 보고 “어떻게 저런 코드를 작성할 수 있었을까?”라며 경이로움과 약간의 혐오감을 느끼며 고개를 저을 8살짜리 아이가 분명히 있다는 것을 기억하려고 노력한다.

어쩌면 지금 내가 아는 최악의 프로그래머는 바로 나일지도 모른다.
editor@itworld.co.kr