"3년 뒤, 여러분의 그 깔끔한 아키텍처는 반드시 쓰레기가 됩니다."

최근 흥미로운 영상을 하나 봤습니다. 'Residues: Time, Change and Uncertainty in Software Architecture'라는 제목이었는데, 한국어로 굳이 번역하자면 '잔재: 소프트웨어 아키텍처 속에 남겨진 시간과 변화의 찌꺼기들' 정도가 되겠네요. 제목을 보자마자 제 척추를 타고 서늘한 감각이 흘렀습니다. 왜냐고요? 이 '잔재'라는 단어야말로 우리 개발자들이 애써 외면하고 싶은, 그러나 매일 마주해야 하는 지옥 같은 현실이기 때문입니다.

많은 주니어 개발자들이 입사해서 가장 먼저 하는 말이 뭔지 아십니까? "CTO님, 레거시 코드가 너무 지저분해요. 싹 다 갈아엎고 마이크로서비스로 새로 짜면 안 될까요?"입니다. 그럴 때마다 저는 속으로 깊은 한숨을 삼키며 이렇게 말해주고 싶습니다. "네가 지금 짜려는 그 '깔끔한' 코드도 3년 뒤면 누군가가 욕하면서 갈아엎고 싶어 할 흉물스러운 레거시가 될 거야."

소프트웨어 아키텍처를 마치 영원불멸한 건축물처럼 생각하는 경향이 있습니다. 처음 설계할 때 완벽하게 구조를 잡으면, 그 위대함이 영원히 지속될 거라 착각하죠. 하지만 현실은 건축보다는 생물학에 가깝습니다. 아니, 더 정확히 말하면 '퇴적층'에 가깝습니다. 비즈니스 요구사항은 시시각각 변하고, 그때마다 우리는 원래의 우아한 설계를 조금씩 비틀고, 땜질하고, 덧붙입니다.

이 과정에서 필연적으로 발생하는 게 바로 '잔재(Residue)'입니다.

예를 들어볼까요? 2년 전, 당근마켓에 있을 때의 일입니다. 피드 추천 시스템을 최적화하겠다고 최신 논문에 나온 복잡한 모델 구조를 도입했습니다. 당시엔 그게 최선(SOTA)이었고, 우리 팀은 환호했습니다. 하지만 딱 6개월 지났을 때, 비즈니스 목표가 '정확도'에서 '실시간성'과 '비용 절감'으로 바뀌었습니다. 그러자 우리가 공들여 쌓아 올린 그 무거운 모델은 순식간에 시스템의 발목을 잡는 거대한 족쇄가 되어버렸습니다. 그 모델을 걷어내려고 하니, 이미 데이터 파이프라인 곳곳에 그 모델을 위한 전처리 로직들이 껌딱지처럼 달라붙어 있었습니다. 그게 바로 잔재입니다.

우리는 불확실성을 통제할 수 있다고 믿지만, 사실 우리가 통제할 수 있는 건 아무것도 없습니다. 오늘 짠 코드는 내일의 비즈니스 피봇팅 앞에서 무력합니다.

그러니 제발 '완벽한 아키텍처'라는 환상에서 깨어나십시오. 학구파 엔지니어들이 흔히 저지르는 실수가, 미래의 모든 변화를 예측해서 유연하고 범용적인 설계를 하려 든다는 점입니다. "나중에 혹시 A라는 기능이 추가될 수도 있으니, 인터페이스를 추상화해두자." 이거야말로 최악의 접근입니다. YAGNI(You Aren't Gonna Need It)라는 말이 괜히 있는 게 아닙니다.

오히려 좋은 아키텍처는 '변화에 강한 것'이 아니라, '버리기 쉬운 것'이어야 합니다.

저는 팀원들에게 항상 강조합니다. "이 코드가 1년 뒤에 삭제될 때, 얼마나 깔끔하게 떨어져 나갈 수 있을지를 고민해라." 비용 효율화의 관점에서도 마찬가지입니다. 거대한 GPU 클러스터를 전제로 한 모놀리식 AI 모델보다는, 언제든지 더 싸고 가벼운 모델로 갈아끼울 수 있는 모듈화 된 파이프라인이 훨씬 가치 있습니다. 기술적 부채는 갚아야 할 빚이지만, 기술적 잔재는 그냥 쓰레기입니다. 쓰레기는 쌓이면 썩고 냄새가 납니다.

여러분이 지금 작성하고 있는 그 코드, 3년 뒤에 후배가 봤을 때 "도대체 이 사람은 무슨 생각으로 이렇게 짠 거야?"라는 소리를 듣지 않으리란 보장이 있습니까? 그 비난을 피하는 유일한 방법은, 미래를 예측하려 들지 말고 현재의 문제를 가장 단순하고 명확하게 해결하는 것입니다. 그리고 언제든 내 코드가 폐기될 수 있음을 겸허히 받아들이는 태도입니다.

코드는 자산이 아니라 부채입니다. 우리가 작성하는 모든 라인은 유지보수 비용을 발생시키는 잠재적 잔재일 뿐입니다. 그러니 화려한 패턴이나 최신 유행 기술 스택에 집착하지 마세요. 대신, 시간이 지나고 비즈니스가 변해도 살아남을 수 있는 '본질'에 집중하세요. 아니면 적어도, 나중에 치우기라도 쉽게 만들어 두세요. 그게 진짜 엔지니어링 실력입니다.

오늘도 0.1%의 성능 향상보다, 내일 팀원이 겪을 삽질을 1시간 줄여주는 설계를 고민하는 하루가 되길 바랍니다.