레거시 코드 앞에서 '클린 코드' 타령만 하는 당신을 위한 제언

솔직히 말해봅시다. 입사 첫 주, 인수인계받은 코드를 열어보고 마음속으로 욕 안 해본 개발자 있습니까? 저는 그랬습니다. 청주 웹 에이전시 시절, 3개월치 월급이 밀려가며 유지보수하던 그 쇼핑몰 코드는 그야말로 '지옥'이었습니다. 변수명은 a, b, temp가 난무했고, 비즈니스 로직은 JSP 파일 안에 스파게티처럼 엉켜 있었죠. 그때 제 반응은 딱 하나였습니다.

"어떤 놈이 코드를 이따위로 짰어?"

우리는 흔히 '클린 코드'를 배우고, 우아한 아키텍처를 꿈꿉니다. 그리고 현실의 '더러운 코드(Dirty Code)'를 마주하면 혐오감을 드러내죠. 하지만 최근 읽은 찰스 다윈에 관한 글을 보며, 저는 10년 전 제 오만함을 뼈저리게 반성했습니다. 다윈은 위대한 과학자였지만, 동시에 지독한 편견에 사로잡힌 '그 시대의 사람'이었거든요.

오늘 이야기는 다윈의 실수에서 배우는 '레거시 코드 정글에서 살아남는 법'입니다.

1. '문명인'의 시선으로 '야만'을 평가하지 마십시오

다윈은 비글호를 타고 전 세계를 여행하며 위대한 발견을 했지만, 그의 일기장을 보면 기가 막힌 대목들이 나옵니다. 그는 뉴질랜드를 보고 "불쾌한 곳"이라며 얼른 떠나고 싶어 했고, 원주민들을 보며 자신과 같은 '문명인'과 비교해 '야만인'이라고 단정 지었습니다. 자신의 영국식 가치관이 절대적인 기준이었던 겁니다.

뉴질랜드 사람을 보면 자연스럽게 타히티 사람과 비교하게 된다. (중략) 한 번만 쳐다봐도 확신이 든다. 한쪽은 야만인이고, 다른 한쪽은 문명인이다.

우리도 똑같지 않나요? 최신 프레임워크와 MSA(Microservices Architecture)로 무장한 '문명인'의 시선으로, 10년 전 선배들이 짠 모놀리식(Monolithic) 코드를 '야만' 취급합니다.

하지만 기억하십시오. 그 '야만적인' 코드가 벌어들인 돈으로 지금 당신의 월급이 나오고 있습니다. 그 코드는 당시의 비즈니스 상황, 촉박한 데드라인, 부족한 리소스 속에서 '생존'해낸 결과물입니다.

Action Item:

비난 대신 존중을 먼저 표하십시오. git blame을 치고 욕하기 전에, 그 커밋이 작성된 날짜를 보십시오. 2018년의 크리스마스 이브였을 수도 있습니다.
맥락(Context)을 파악하십시오. 왜 여기에 if 문이 10개나 중첩되어야 했는지, 기획팀과 당시의 히스토리를 먼저 물어보십시오. 기술적 우월감은 문제 해결에 아무런 도움이 되지 않습니다.

2. '관찰자'가 아니라 '보전주의자'가 되십시오

다윈은 생태학적 통찰력이 뛰어났습니다. 그는 쥐나 잡초 같은 외래종이 토착 생태계를 파괴하는 것을 목격했습니다. 하지만 놀랍게도 그는 그걸 보고만 있었습니다.

(호주 동물들이) 완전히 멸종되기까지는 시간이 걸리겠지만, 그들의 운명은 정해졌다.

그는 생태계의 파괴를 슬퍼하면서도, 그것을 막기 위해 손가락 하나 까딱하지 않았습니다. 그저 "운명"이라 치부하고 기록만 남겼죠.

개발자들도 비슷합니다. 우리는 프로젝트의 '기술 부채(Technical Debt)'를 기가 막히게 찾아냅니다. "이거 구조가 엉망이라 나중에 터질 텐데요?" "이 라이브러리 지원 종료돼서 보안 이슈 생길 겁니다."

이렇게 진단만 내리고, "언젠가 갈아엎어야 한다"는 말만 반복하며 방치합니다. 그사이에 코드는 썩어가고, 결국 유지보수 불가능한 '멸종' 단계에 이릅니다. 다윈처럼 "이 프로젝트의 운명은 정해졌다"고 냉소적으로 말하면서 말이죠.

Action Item:

보이스카우트 규칙을 적용하십시오. 거창한 리팩토링 일정을 잡지 마십시오. 변수명 하나, 함수 분리 하나라도 좋으니 '내가 발견했을 때보다 아주 조금만 더 깨끗하게' 만드십시오.
비즈니스를 설득하십시오. "코드가 더러워서 못 해 먹겠어요"가 아니라, "이 부분을 지금 수정하지 않으면, 다음 달 이벤트 트래픽을 감당할 때 서버 비용이 2배로 듭니다"라고 말하십시오. 관찰자가 아니라, 숲을 지키는 관리자가 되어야 합니다.

3. 당신도 결국 '그 시대의 사람'임을 인정하십시오

다윈이 노예제 폐지를 주장하면서도, 동시에 인종차별적인 시각을 가졌던 것은 그가 '빅토리아 시대'의 한계 속에 있었기 때문입니다. 그는 시대를 앞서갔지만, 동시에 시대에 갇혀 있었습니다.

지금 당신이 작성하는 그 '완벽한' 클린 코드도, 3년 뒤에 들어올 신입 개발자에게는 "어떤 멍청이가 짠 레거시"가 될 것입니다. 기술 트렌드는 변하고, 비즈니스 요구사항은 코드를 더럽힙니다. 우리는 모두 불완전한 인간이고, 한정된 시간과 자원 속에서 최선을 다할 뿐입니다.

찰스 다윈은 새로운 통찰과 구식 사고가 뒤섞인 이상한 혼합체였다.

이 문장은 다윈뿐만 아니라, 우리 모두에 대한 설명입니다. 우리는 완벽한 신이 아닙니다. 버그를 만들고, 똥 코드를 쌉니다. 중요한 건 그 사실을 인정하고 끊임없이 개선하려는 태도입니다.

Action Item:

자신의 코드에 겸손해지십시오. 내가 짠 로직도 언젠가 레거시가 된다는 사실을 받아들이면, 과거의 코드를 대하는 태도가 유연해집니다.
문서화를 습관화하십시오. 3년 뒤의 후배가 나를 욕하지 않게 하려면, '왜' 이렇게 짰는지에 대한 주석과 문서를 남기십시오. 그것이 당신을 방어해 줄 유일한 무기입니다.

마치며: 정글에서 살아남는 건 '평론가'가 아니라 '해결사'입니다

제가 쌍용정보통신 파견 시절, 공공기관 프로젝트에서 배운 게 하나 있습니다. 코드를 보고 혀를 차며 "이건 쓰레기야"라고 평론하는 명문대 출신 개발자는 금방 지쳐서 나갔습니다. 하지만 그 진흙탕 같은 코드 속에서 어떻게든 비즈니스를 굴러가게 만들고, 야금야금 개선해 나갔던 잡초 같은 개발자들은 끝까지 살아남아 인정받았습니다.

다윈은 완벽하지 않았지만, 어쨌든 위대한 유산을 남겼습니다. 우리도 마찬가지입니다. 완벽한 코드는 없습니다. 살아남아 작동하는 코드가 있을 뿐입니다.

내일 출근해서 마주할 그 끔찍한 레거시 코드, 욕 한번 시원하게 하고 다시 키보드에 손을 올립시다. 우리는 숭고한 학자가 아니라, 진흙탕을 뒹구는 엔지니어니까요.