🚀 2026 스타트업 컨퍼런스

New maps reveal post-flood migration patterns across the US

New maps reveal post-flood migration patterns across the US

Poooling·2026년 1월 6일·3

홍수 피해 지역의 주택 매입 리포트를 통해 살펴본 기술 부채와 레거시 코드의 위험성, 그리고 지속 가능한 개발 습관에 대한 고찰.

제목

당신이 덮어둔 레거시 코드, 3년 뒤 연봉 협상 테이블에서 발목 잡습니다

최근 라이스 대학교(Rice University)의 도시 연구소에서 발표한 흥미로운 리포트를 하나 읽었습니다. 홍수 피해가 잦은 지역의 집주인들이 정부의 주택 매입(Buyout) 프로그램을 통해 아예 그 땅을 자연으로 돌려보내기보다는, 위험을 숨기거나 축소한 채 다른 사람에게 집을 팔고 떠나는 비율이 압도적으로 높다는 내용이었습니다.

이 기사를 읽는데 등골이 서늘해지더군요. 홍수 난 집을 남에게 떠넘기고 도망가는 집주인의 모습이, 마치 감당 안 되는 레거시 코드(Legacy Code)를 엉망으로 짜놓고 "나는 이제 이직하니까 몰라"라며 떠나버렸던 저의 부끄러운 과거와 겹쳐 보였기 때문입니다.

솔직히 고백하자면, 저도 스타트업 시절엔 '생존'이라는 핑계로 폭탄 돌리기 식 개발을 했습니다. 당장 기능이 돌아가는 게 중요했지, 6개월 뒤 트래픽이 몰릴 때 발생할 동시성 이슈(Concurrency Issue)나 데이터 무결성 문제는 제 알 바 아니라고 생각했으니까요. "어차피 그때쯤이면 난 여기 없을 수도 있어"라는 무책임한 마음도 한구석에 있었습니다. 마치 침수된 지하실을 벽지로 대충 가리고 집을 내놓는 집주인처럼 말이죠.

그런데 대기업으로 이직해 더 큰 규모의 시스템을 다루다 보니 뼈저리게 느낍니다. 누군가 떠넘기고 간 그 '위험한 부동산'이 결국 팀 전체의 생산성을 박살 내고, 장애 대응(On-call)으로 밤잠을 설치게 만든다는 사실을요.

리포트에서는 정부가 1달러를 들여 위험한 집을 매입하고 철거하면, 미래의 재난 복구 비용 4~6달러를 아낄 수 있다고 합니다. 소프트웨어 개발도 똑같습니다. 지금 당장 일정을 핑계로 덮어두는 기술 부채(Technical Debt)는 나중에 이자까지 붙어 거대한 장애로 돌아옵니다. 그때 가서 수습하려면 리소스는 4배, 5배가 아니라 10배 이상 들어갑니다.

제가 겪었던 가장 아찔한 순간은 3년 차 때였습니다. 결제 모듈에서 가끔 발생하는 간헐적 오류를 로그 더미 속에 파묻어두고 퇴사했는데, 나중에 전 직장 동료에게 들으니 블랙프라이데이 행사 때 그 부분이 터져서 DB 데드락(Deadlock)이 걸리고 서비스가 2시간 동안 마비됐다고 하더군요. 그 이야기를 듣는데 얼굴이 화끈거려 쥐구멍에라도 숨고 싶었습니다. 그건 단순한 실수가 아니라, 제가 동료들에게 던진 시한폭탄이었습니다.

그 이후로 저는 개발 습관을 완전히 바꿨습니다. 코드를 짤 때 '나만 알아볼 수 있는 코드'가 아니라, '누가 와서 봐도 유지보수 가능한 집'을 짓기 위해 노력합니다.

구체적으로는 '적극적 철거(Buyout)' 전략을 취합니다.

더 이상 사용하지 않는 API나 불필요하게 복잡한 로직은 주석 처리로 남겨두지 않고 과감하게 삭제합니다. 레거시를 리팩토링할 때는 단순히 코드만 고치는 게 아니라, 왜 이렇게 고쳤는지 ADR(Architecture Decision Records)을 남겨 후임자가 맥락을 이해하도록 돕습니다.

최근에는 AI 도구도 적극적으로 활용합니다. Cursor나 Claude 같은 도구를 이용해 복잡한 스파게티 코드를 분석시키고, 가독성을 높일 수 있는 리팩토링 제안을 받습니다. 단순히 AI에게 코딩을 시키는 게 아니라, 이 코드가 미래에 어떤 부작용(Side Effect)을 일으킬지 시뮬레이션해보는 용도로 씁니다. "이 함수에서 예외 처리가 누락되면 어떤 연쇄 작용이 일어날까?"를 AI와 따져보는 과정 자체가 견고한 집을 짓는 기초 공사가 되더군요.

물론, 비즈니스 속도를 무시하고 하루 종일 리팩토링만 할 수는 없습니다. 하지만 적어도 내가 만든 코드가 다음 사람에게 '저주'가 되어서는 안 됩니다.

홍수 위험이 있는 집을 팔고 떠나면 당장은 홀가분할지 모릅니다. 하지만 그 지역 사회(Community)는 점점 더 취약해지고, 결국 그 피해는 돌고 돌아 우리 생태계 전체의 수준을 떨어뜨립니다.

여러분이 지금 작성하고 있는 그 코드, 다음 사람이 기분 좋게 입주할 수 있는 집인가요, 아니면 언제 물이 샐지 모르는 부실 공사인가요?

떠날 때 박수받는 개발자는 엄청난 기능을 만든 사람이 아니라, 후임자가 안심하고 잠들 수 있는 환경을 만들어준 사람이라는 걸 8년이 지나서야 조금씩 깨닫고 있습니다. 우리, 적어도 폭탄은 남기지 맙시다.

Poooling
PooolingAuthor

Poooling님의 다른 글

댓글 0

첫 번째 댓글을 남겨보세요!