제목
인수합병 실사 팀이 절대 말해주지 않는 '레거시 코드' 평가 기준 3가지
본문
최근 흥미로운 기사 하나를 읽었습니다.
그린란드 빙하 아래 어마어마한 광물 자원이 숨겨져 있다는 내용이었죠.
미국 대통령까지 나서서 그 땅을 사고 싶어 할 정도로 매력적이지만, 수천 미터 얼음 아래 묻힌 자원을 캐내는 건 보통 일이 아니라는 겁니다.
이 기사를 보는데, 묘하게 등골이 서늘해지더군요.
마치 제가 지금 몸담고 있는 대기업의 거대한 '레거시 시스템'을 보는 것 같았습니다.
솔직히 고백하겠습니다.
저는 스타트업 시절, 소위 '야생'에서 굴렀습니다.
빠르게 만들고, 빠르게 부수고, 또 새로 만드는 게 미덕인 줄 알았죠.
그러다 지금 회사로 이직하고 나서 처음 마주한 건, 10년 묵은 거대한 모놀리식(Monolithic) 코드 덩어리였습니다.
마치 그린란드의 그 두꺼운 빙하처럼요.
처음엔 패기가 넘쳤습니다.
"이거 너무 낡았는데요? 싹 갈아엎고 MSA(Microservices Architecture)로 가시죠."
팀장님께 호기롭게 제안했었죠.
마치 그린란드를 단숨에 사들이겠다는 트럼프의 제안처럼, 저도 이 복잡한 시스템을 '돈(리소스)'과 '시간'으로 단번에 해결할 수 있다고 믿었습니다.
하지만 그건 제 오만이었습니다.
입사 3개월 차, 작은 결제 모듈 하나를 리팩토링하다가 서비스 장애를 냈습니다.
단순한 중복 코드인 줄 알고 지웠던 5줄짜리 로직이, 알고 보니 특정 카드사의 예외 처리를 담당하는 핵심 비즈니스 로직이었던 겁니다.
식은땀이 줄줄 흘렀습니다.
그때 뼈저리게 느꼈습니다.
우리가 '똥 코드'라고 부르는 그 레거시 안에는, 회사가 10년 동안 생존하며 쌓아온 '돈 버는 규칙(Business Value)'이 화석처럼 박혀 있다는 사실을요.
그린란드 기사에서도 그러더군요.
얼음 아래에는 희토류만 있는 게 아니라, 지구의 역사가 담긴 지질학적 기록이 있다고요.
개발자로 치면 git blame으로도 추적 안 되는, 7년 전 퇴사자의 고뇌가 담긴 커밋들이겠죠.
그린란드의 지도를 완성하는 데 200년이 걸릴 거라는 전문가의 말은, 우리에게 시사하는 바가 큽니다.
우리는 너무 쉽게 '재개발'을 꿈꿉니다.
하지만 지질학자들이 빙하를 걷어내기 위해 수십 년간 지도를 그리듯, 우리도 먼저 '코드 지도'를 그려야 합니다.
무작정 최신 스택인 Go나 Rust로 재작성하는 게 능사가 아닙니다.
저는 태도를 바꿨습니다.
'갈아엎기' 대신 '탐사'를 시작했습니다.
요즘 저는 Cursor 에디터나 Claude 같은 AI 도구를 적극적으로 활용합니다.
단순히 코드를 짜달라고 하는 게 아닙니다.
"이 3000줄짜리 레거시 클래스의 의존성을 분석해서 다이어그램으로 그려줘"라고 요청합니다.
혹은 이해가 안 되는 복잡한 분기문을 AI에게 던져주고, 역으로 테스트 케이스를 생성해달라고 하죠.
마치 최첨단 장비로 빙하 속을 스캔하듯이 말입니다.
그렇게 분석해보니, 비효율적으로만 보였던 코드 덩어리들이 왜 그렇게 짜여있는지 보이기 시작했습니다.
그 안에는 우리 회사가 고객을 놓치지 않기 위해 발버둥 쳤던 치열한 흔적이 있었습니다.
그걸 이해하지 못한 채 진행하는 리팩토링은 폭력이나 다름없었습니다.
주니어 분들이나 이직을 준비하는 분들에게 꼭 해주고 싶은 말이 있습니다.
화려한 신기술 스택보다 더 중요한 건, '빙하를 뚫고 자원을 찾아내는 인내심'입니다.
면접관들이 "레거시를 어떻게 다루시나요?"라고 물을 때,
"다 밀어버리고 새로 짭니다"라고 답하면 빵점입니다.
"기존 시스템이 주는 가치를 먼저 파악하고, 점진적으로 개선하겠습니다."
이게 진짜 정답입니다.
그린란드의 얼음이 하루아침에 녹지 않듯, 좋은 소프트웨어도 하루아침에 만들어지지 않으니까요.
오늘도 저는 곡괭이 대신 키보드를 들고, 우리 회사의 빙하 속을 탐험하러 갑니다.
함께 하시겠습니까?
