레거시 코드를 '깔끔하게' 재작성하려는 당신, 그건 회사를 망치는 지름길입니다

솔직히 말해서, 개발자라면 누구나 한 번쯤은 그런 충동을 느낍니다. 입사하자마자 마주한 스파게티 코드를 보며 "이거 싹 다 갈아엎어야겠는데요?"라고 말하고 싶은 충동 말입니다. 저도 청주의 웹 에이전시에서 일할 때, 사수도 없는 환경에서 10년 된 PHP 코드를 보며 밤새 욕을 했습니다. 그때는 그게 정의인 줄 알았습니다. 냄새나는 코드를 클린 코드로 바꾸는 것이 개발자의 사명이라고 믿었죠. 하지만 지금 와서 돌이켜보면, 그건 혈기만 앞선 오만이었습니다. 오늘은 제가 최근에 발견한 오픈소스 도구 하나를 통해, 왜 우리가 '더러운 해결책'을 사랑해야 하는지 이야기해보려 합니다.

최근 깃허브에서 amifuse라는 재미있는 프로젝트를 하나 발견했습니다. 1980~90년대를 풍미했던 아미가(Amiga) 컴퓨터의 파일시스템을 현대의 윈도우, 맥, 리눅스에서 읽고 쓸 수 있게 해주는 도구입니다. 보통 이런 도구를 만든다면 어떻게 접근할까요? 아마 대부분의 명문대 출신 '엄친아' 개발자들은 이렇게 생각할 겁니다. "파일시스템의 바이너리 구조를 완벽하게 역공학(Reverse Engineering)해서, 파이썬이나 C로 깔끔하게 재구현하자." 논리적이고 멋진 접근입니다. 하지만 이 프로젝트는 완전히 다른 방식을 택했습니다.

이 도구는 파일시스템을 새로 구현하지 않았습니다. 대신 m68k CPU 에뮬레이터를 내장해버렸습니다. 무슨 소리냐고요? 30년 전 아미가에서 돌아가던 원본 파일시스템 드라이버 바이너리를 그대로 가져와서, 가상의 CPU 위에서 돌려버린 겁니다. FUSE(Filesystem in Userspace)를 통해 운영체제와 연결만 해두고, 실제 데이터를 읽고 쓰는 복잡한 로직은 30년 전의 '레거시 코드'에게 그대로 맡겨버린 셈입니다.

누군가는 이걸 보고 "비효율적이다" 혹은 "지저분하다"고 비난할지도 모릅니다. 하지만 저는 이 방식에 감탄을 금치 못했습니다. 파일시스템이라는 것은 조금만 실수해도 데이터가 깨지는 치명적인 영역입니다. 수십 년간 검증된 원본 드라이버를 사용하는 것보다 더 안전하고 확실한 방법이 있을까요? 역공학을 통해 새로 짠 코드는 필연적으로 버그를 동반합니다. 하지만 이 '더러운' 에뮬레이션 방식은 원본의 완벽한 호환성을 보장합니다. 비즈니스 관점에서 보자면, 개발 리소스를 최소화하면서도 가장 리스크가 적은 방법을 택한 것입니다.

설치와 사용법도 지독하게 실용적입니다. 파이썬 환경에서 amitools와 vamos 같은 에뮬레이션 라이브러리를 설치하고, amifuse를 깔면 끝입니다. 맥에서는 macFUSE, 리눅스에서는 FUSE 패키지만 있으면 됩니다. 사용자는 그저 amifuse mount disk.hdf라고 명령어를 치면 됩니다. 그러면 내부적으로 가상 머신이 돌아가고, 옛날 드라이버가 깨어나 하드디스크 이미지를 해석해 줍니다. 사용자는 그 복잡한 내부 사정은 알 필요도 없이, 파인더나 탐색기에서 파일을 복사하고 붙여넣으면 됩니다.

SI 프로젝트 현장에서 굴러보신 분들은 아실 겁니다. 고객사는 코드가 얼마나 우아한지에는 관심이 없습니다. "그래서 옛날 데이터 열립니까?" 이게 전부입니다. 제가 야놀자에서 레거시 청산 TF에 있을 때도 마찬가지였습니다. 무조건적인 재작성보다는, 기존 로직을 안전하게 감싸서(Wrapping) 격리하는 방식이 훨씬 더 생존 확률이 높았습니다. amifuse는 그 생존 본능을 극단적으로 보여주는 사례입니다. pfs3aio 같은 고성능 파일시스템 핸들러를 다운로드받아 연결만 해주면, 현대의 OS가 30년 전의 유물과 완벽하게 대화할 수 있게 됩니다.

물론, 이 방식은 실험적인 '읽기-쓰기' 모드 같은 기능에서 조심해야 할 부분도 있습니다. 하지만 핵심은 그게 아닙니다. 우리가 마주하는 레거시 시스템, 소위 '똥 코드'라고 부르는 것들 안에는 수년간 쌓인 비즈니스의 정수와 예외 처리들이 녹아 있습니다. 그걸 무시하고 처음부터 다시 짜겠다고 덤비는 건, 지뢰밭에 맨몸으로 들어가는 것과 같습니다. 때로는 이 도구처럼, 레거시를 혐오의 대상이 아니라 '도구'로 바라보고 활용하는 유연함이 필요합니다.

개발은 예술이 아니라 생존 기술입니다. 화려한 아키텍처보다 중요한 건, 당장 돌아가는 서비스와 데이터의 무결성입니다. 만약 여러분의 팀장이 "이거 구조가 마음에 안 드니 싹 갈아엎자"라고 한다면, 조용히 이 amifuse의 사례를 떠올려보세요. 그리고 생각해보십시오. 우리가 지금 해야 할 일이 예술 작품을 만드는 것인지, 아니면 비즈니스를 굴러가게 만드는 것인지 말입니다. 1,000만 사용자가 쓰는 앱의 백엔드를 지키는 입장에서 장담하건대, 후자가 훨씬 더 어렵고 가치 있는 일입니다.