레거시 코드를 C#에서 다시 작성해야 할까요? Derek Comartin의 입장을 자세히 살펴보기
기존 코드를 다시 작성하는 것은 많은 개발자들이 직면하는 딜레마이며, 특히 코드가 투박하고, 시대에 뒤떨어졌거나, 확장이 불가능해 보이는 오랜 프로젝트에서 더욱 그렇습니다. 모든 것을 초기화하고 현대적이고 유지 관리가 용이한 건물을 처음부터 새로 짓는 꿈을 꾸는 것은 매력적인 일입니다. 하지만 이것이 과연 옳은 조치일까요?
이 글에서는 Derek Comartin이 CodeOpinion.com 유튜브 채널의 " 절대 코드를 다시 쓰지 말아야 할까요? "라는 영상에서 자세히 설명한 레거시 시스템을 C#으로 다시 작성하는 복잡성에 대해 살펴보겠습니다. 데릭은 개인적인 경험과 커뮤니티에서 얻은 지혜를 바탕으로 이 주제에 대해 균형 잡힌 시각을 제시하며, 많은 개발자와 기술 관련 의사 결정권자들이 이를 높이 평가할 것입니다.
"절대 코드를 다시 작성하지 마라"라는 원칙
데릭은 소프트웨어 개발에서 흔히 듣는 조언, 즉 코드를 처음부터 다시 작성하지 말라는 말을 언급하며 이야기를 시작합니다. 이러한 생각은 조엘 스폴스키의 유명한 블로그 게시물 "절대 해서는 안 되는 일들"에서 비롯된 것으로, 기존 시스템을 다시 작성하는 것에 대해 강력하게 경고하고 있습니다.
0:32에 데릭은 스폴스키의 글에서 가장 중요한 아이디어를 지적합니다.
"그들은 소프트웨어 회사가 저지를 수 있는 최악의 전략적 실수를 저질렀습니다. 코드를 처음부터 다시 작성하기로 결정한 것입니다."
데릭은 핵심은 이것이라고 설명합니다. 즉, 처음부터 시작할 때 반드시 처음보다 더 나은 결과를 낼 것이라고 장담할 수는 없다는 것입니다. 특히 크고 복잡한 시스템에서는 현재 구현에 내재된 숨겨진 가치를 과소평가하기 쉽습니다.
단순함의 환상
1분 7초에 데릭은 주니어 개발자 시절을 회상합니다. 다른 많은 사람들처럼, 그는 코드가 형편없다고 생각한다는 이유만으로 시스템의 상당 부분을 다시 작성하고 싶어하는 경우가 많았습니다. 하지만 그는 나중에 이러한 믿음이 코드 자체의 본질적인 결함 때문이 아니라 코드를 제대로 이해하지 못한 데서 비롯된 경우가 많다는 것을 깨달았습니다.
그는 누구나 공감할 수 있는 진실을 이야기합니다.
"처음부터 완전히 새롭게 시작하는 것이 기존 코드베이스를 파고들어 모든 복잡성과 예외 상황까지 고려해야 하는 것보다 훨씬 쉽습니다. 후자는 정말 어렵거든요."
본질적으로, "타이어 화재"처럼 보이는 것은 수년간의 진화와 수정을 거쳐 만들어진, 잘못 이해된 논리일 뿐일지도 모릅니다. 개발자들은 종종 익숙하지 않은 것을 나쁜 설계로 오해합니다.
수정이 필요한 경우는 언제일까요?
하지만 데릭은 대본 수정이 항상 나쁜 것만은 아니라고 말합니다. 약 1분 44초쯤부터 그는 미묘한 뉘앙스를 도입하기 시작합니다. 수년간 동일한 코드베이스를 사용해 왔고, 도메인의 복잡성과 시스템의 한계를 모두 이해하고 있는 팀이라면 코드를 다시 작성하는 것이 타당한 선택일 수 있습니다.
"만약 당신이 어떤 시스템에 정말 오랫동안 몸담았다면..." 바로 그 부분에서 미묘한 차이가 드러나는 겁니다. 네, 이건 완전히 엉망진창이고 우리 발목을 잡고 있다고 말할 수 있어요. 어쩌면 다시 쓰는 것이 적절할지도 모르겠습니다.
"나쁜 게 더 낫다"와 80/20 법칙
데릭은 2분 1초에 "더 나쁜 것이 더 낫다"라는 개념을 소개하며 이를 파레토 법칙(80/20 법칙)과 연결합니다. 그는 시스템 가치의 80%가 코드베이스의 단 20%에서 나온다고 주장합니다. 따라서 재작성을 할 때는 모든 것을 복제하는 것이 아니라 진정으로 가치를 제공하는 핵심에 집중해야 합니다.
"기능이 다소 떨어지는 것이 오히려 더 나은 선택이 되는 시점이 있습니다."
그는 단순함과 실용성이 완벽함보다 더 중요한 경우가 많다고 설명합니다. 제한적이지만 사용 가능하고 유지 관리가 용이한 시스템이 방대하지만 유지 관리가 어려운 기존 플랫폼보다 더 나은 결과를 가져올 수 있습니다.
비용 대비 효과 평가
2분 47초에 데릭은 최종 결정은 종종 비용 편익 분석으로 귀결된다고 말합니다. 단순히 다시 쓰기 위한 다시 쓰기는 결코 정당화될 수 없다. 하지만 오래된 코드를 유지 관리하는 비용이나 오래된 기술의 제약을 감수하는 비용이 새로 작성하는 비용보다 크다면, 재작성을 선택하는 쪽으로 논리가 바뀔 수도 있습니다.
그는 구식 플랫폼이나 도구에 갇혀 경쟁력이 저해되는 상황을 예로 듭니다. 이러한 경우, 기술 격차 자체가 재구축의 타당한 이유가 됩니다.
그렉 영에게 배우는 교훈
데릭은 3분 12초에 그렉 영이 쓴 훌륭한 게시물을 언급하는데, 그 게시물에서는 실수로 제품 출시까지 이어진 프로토타입을 다시 작성했다고 합니다. 재작업에 9개월이 걸렸습니다. 결과는?
"9개월 동안 아름다운 아키텍처와 코드 작업을 진행한 결과, 우리는 매달 약 1만 달러의 추가 수익을 올렸습니다."
그렉은 기존 프로토타입을 대대적으로 재건축하는 데 투자하기보다는 새로운 전략을 시험하기 위해 30개의 새로운 프로토타입을 만드는 것이 더 나았을 것이라고 결론지었다. 데릭은 이 결론을 좋아하는데, 그 이유는 기술적 완벽함이 항상 목표라는 가정에 도전하기 때문이다.
때로는 "충분히 좋은" 소프트웨어가 승리하는 경우가 있습니다. 특히 이미 비즈니스 가치를 제공하고 있을 때는 더욱 그렇습니다.
"구식 대 신식"이라는 편견
4분 20초에 데릭은 '옛것은 나쁘고 새것은 좋다'는 일반적인 사고방식에 대해 이야기합니다. 그는 자신의 경험을 예로 들며, 동일한 목적을 가진 두 개의 타사 서비스와 연동한다고 설명합니다. 하나는 최신 JSON을 사용하며 Python으로 작성되었을 가능성이 높습니다. 놀랍게도 다른 하나는 XML을 반환하며 아마도 1990년대에 ColdFusion으로 만들어졌을 것입니다.
둘 다 동등합니다. 안정적입니다. 그들은 나와 내 고객에게 동일한 가치를 제공합니다."*
이는 새로운 것이 항상 더 좋은 것은 아니라는 점을 보여줍니다. 안정성, 신뢰성, 유용성은 기술 스택보다 훨씬 더 중요한 경우가 많습니다.
데릭의 개인적인 재작성 경험
데릭은 마침내 5분 31초에 자신의 이야기를 들려줍니다. 그는 기존 시스템에서 6년 이상 근무한 후 대규모 시스템 개편에 참여했습니다. 시스템 개편에는 약 14개월이 소요되었는데, 이는 주로 최신 전자상거래 도구 및 온라인 서비스와의 통합을 제한하는 기술적 격차 때문이었습니다.
"우리는 이 목적을 위해 정말로 새로운 것을 재건축해야 했습니다."
이것은 단순히 "코드 오류"의 문제가 아니었습니다. 시스템 자체가 근본적으로 진화할 수 없었기 때문에 재구축만이 유일한 해결책이었습니다.
마지막으로
영상 말미인 6분 11초쯤에 데릭은 그 질문에 대한 답이 단순히 "예" 또는 "아니오"가 아니라는 점을 다시 한번 강조합니다.
"명확한 답이 '아니오'라고는 생각하지 않습니다. 상황 맥락이 중요하고, 여러 가지 미묘한 차이가 있기 때문에 신중하게 결정해야 한다고 생각합니다."
기존 C# 코드를 다시 작성하는 것이 필요할 수도 있지만, 이는 상황, 도메인 지식, 가치 전달 및 기술적 제약 조건이 모두 그러한 결정을 뒷받침할 때만 해당됩니다.
결론
데릭 코마틴의 영상은 소프트웨어 개발에서 가장 논쟁적인 주제 중 하나인 "레거시 코드를 다시 작성해야 할까요?"에 대해 균형 잡힌 시각과 경험을 바탕으로 한 의견을 제시합니다. 그의 조언은 독단적이지 않고, 사려 깊고, 현실에 기반을 두고 있으며, 개인적인 통찰력이 풍부합니다.
데릭은 역사적 교훈, 실제 사례, 그리고 "새로운 것이 더 좋다"는 함정을 되짚어보며 시청자들이 소프트웨어 아키텍처에서 가장 중요한 결정 중 하나를 내릴 수 있는 성숙한 틀을 갖추도록 돕습니다.
만약 여러분의 C# 프로젝트에서도 비슷한 선택에 직면했다면, 데릭의 영상을 다시 보고 상황을 신중하게 고려해 보세요. 때로는 레거시 코드가 적이 아니라, 단지 오해받고 있는 것일 뿐입니다.
데릭의 유튜브 채널 에서 더 많은 유익한 영상을 시청하세요. 더 많은 데릭의 콘텐츠를 보려면 CodeOpinion.com을 방문하세요.

