1. 재작성 논의가 팀의 동력을 저해하는 방식
대부분의 팀은 재작성을 공식적으로 선언하거나 예산을 배정하지 않은 채, 슬랙(Slack)에서의 농담이나 회의 중 가벼운 언급을 통해 ‘언젠가는 재작성할 것’이라는 분위기를 형성합니다. 이러한 ‘잠정적 상태’가 지속되면 개발자들은 자기도 모르게 현재 시스템에 대한 투자를 줄이기 시작합니다. 이는 나태함이 아니라, 곧 사라질 시스템에 에너지를 쏟지 않으려는 자기방어 기제에 가깝습니다.
- 리팩토링의 지연: “어차피 바꿀 건데”라는 생각에 작은 개선들이 뒤로 밀리며 시스템의 경직성이 강화됩니다.
- 문서화의 부재: 임시 시스템이라는 인식 때문에 지식 공유와 기록이 소홀해지며 운영 리스크가 증가합니다.
- 책임감의 분산: 깊은 수준의 문제 해결보다는 당장의 장애를 막는 임시방편 위주의 작업이 주를 이루게 됩니다.
2. 재작성 질문의 건강함과 결정의 부재
시스템의 노후화에 따라 재작성 필요성을 검토하는 것 자체는 매우 건강한 과정입니다. 문제는 질문을 던지는 것이 아니라, 그 질문에 대한 답을 내리지 않고 ‘미결’ 상태로 두는 것입니다. 많은 팀이 재작성을 검토한 후 ‘현재로서는 유지보수가 가장 실용적이다’라는 결론에 도달하지만, 이를 문서화하거나 공유하지 않습니다. 그 결과, 새로 합류한 팀원이 다시 재작성 이야기를 꺼내면 팀은 또다시 불확실성의 늪으로 빠지게 됩니다. 결정에는 ‘척추(spine)’가 필요합니다. 왜 재작성하지 않는지, 대신 무엇에 집중할 것인지 명확히 선언해야 팀의 ‘표류(drift)’를 막을 수 있습니다.
3. AI 시대가 가져온 재작성의 환상
최근 생성형 AI의 발전은 재작성에 대한 유혹을 더욱 강화하고 있습니다. 리더들은 AI가 코드를 빠르게 생성해주니 재작성 비용이 낮아졌다고 착각하기 쉽습니다. 하지만 AI는 코드 작성을 도울 뿐, 도메인의 복잡성을 이해하거나, 수년간 쌓인 엣지 케이스(edge case)를 처리하거나, 안전한 데이터 마이그레이션을 보장해주지 않습니다. AI는 재작성의 가장 어려운 부분들을 해결해주지 못함에도 불구하고, 팀이 현재 시스템에 대한 책무(stewardship)를 회피할 수 있는 그럴듯한 명분만을 제공할 위험이 있습니다.
4. 리더를 위한 새로운 프레임워크: 시스템에 다시 거주하기
기술적 노후화를 탓하기 전에 리더는 팀에게 다음과 같은 질문을 던져야 합니다. 우리 팀은 이 소프트웨어를 정말로 ‘거주하고 있는 공간’으로 대우하고 있는가? 팀이 당연하게 받아들이고 있는 일상의 마찰(friction)은 무엇인가? 재작성이 없다고 가정할 때, 삶의 질을 높이기 위해 당장 고쳐야 할 것은 무엇인가? 이 질문들은 아키텍처가 아닌 ‘경험’에 집중하게 합니다. 재작성이라는 거창한 계획보다, 개발자들이 매일 겪는 불편함을 제거하고 안전한 배포 환경을 구축하는 것이 훨씬 더 효과적인 로드맵이 될 수 있습니다.