Blog·인사이트

리뉴얼 해야 할 때 vs 새로 만들어야 할 때

··7분 읽기
요약

"서비스가 느려요." "새로운 기능을 추가하려는데 구조가 안 받쳐줘요." "디자인이 오래돼서 리뉴얼하고 싶어요."

"서비스가 느려요." "새로운 기능을 추가하려는데 구조가 안 받쳐줘요." "디자인이 오래돼서 리뉴얼하고 싶어요."

이런 상황에서 두 가지 선택지가 있습니다. 기존 코드 위에 수정하는 리뉴얼과, 처음부터 새로 만드는 리빌드. 어느 쪽이 맞는지는 상황에 따라 완전히 다릅니다.

리뉴얼이 맞는 경우

기존 코드 기반을 유지하면서 부분적으로 개선하는 방식입니다.

이런 상황이라면 리뉴얼

  • 코드 품질이 나쁘지 않다: 구조가 잡혀있고, 다른 개발자가 읽고 이해할 수 있는 수준
  • 기술 스택이 현역이다: React, Vue, Django, Spring 같은 메인스트림 기술을 쓰고 있음
  • 문제가 특정 부분에 집중돼 있다: 전체가 아니라 일부 기능이나 화면만 수정하면 됨
  • 데이터가 많이 쌓여있다: DB 구조 자체는 괜찮고, 마이그레이션 리스크를 피하고 싶음
  • 시간이 부족하다: 전체를 새로 만들 여유가 없고, 부분 개선으로 효과를 볼 수 있음

리뉴얼의 장점은 비용과 시간입니다. 기존에 잘 동작하는 부분은 그대로 두고, 문제가 되는 부분만 고칩니다. 리스크도 상대적으로 적습니다.

리빌드가 맞는 경우

기존 코드를 버리고 처음부터 다시 만드는 방식입니다. 비용과 시간이 많이 들지만, 필요한 순간이 분명히 있습니다.

이런 상황이라면 리빌드

  • 코드를 아무도 이해 못 한다: 원래 개발자가 떠났고, 문서도 없고, 코드 구조가 엉망
  • 기술 스택이 수명을 다했다: PHP 4, jQuery 기반 레거시, 더 이상 보안 패치도 안 나오는 프레임워크
  • 부분 수정이 전체에 영향을 준다: 하나를 고치면 다른 곳이 터지는 스파게티 구조
  • 비즈니스 모델이 바뀌었다: B2C였던 서비스를 B2B로 전환, 단순 정보 제공에서 거래 플랫폼으로 변경
  • 확장이 구조적으로 불가능하다: 동시 접속 100명을 기준으로 설계된 서비스에 1만 명이 들어와야 하는 상황

리빌드는 비용이 크지만, 잘못된 기반 위에 계속 덧붙이는 것보다 결과적으로 저렴할 수 있습니다.

리빌드 직전까지 갔던 사례

앱 서비스를 리뉴얼 해달라는 의뢰가 들어온 적이 있습니다. 열어보니 상태가 심각했습니다. 사용하고 있던 주요 의존 모듈(코덱, 미디어 라이브러리 등)이 deprecated되어 더 이상 업데이트가 제공되지 않았고, 앱이 타겟하는 OS 최소 버전도 크게 올라가면서 기존 코드가 최신 OS에서 빌드 자체가 위태로운 상태였습니다.

보통 이런 경우 리빌드를 권하는 개발사가 많습니다. deprecated된 모듈을 대체하려면 해당 모듈에 의존하는 코드를 전부 뜯어고쳐야 하고, OS 타겟 버전을 올리면 호환이 안 되는 API 호출이 줄줄이 터지니까요. 하나를 고치면 열 개가 깨지는 상황.

객관적으로 보면 리빌드가 맞는 상태였습니다. 그런데 저희는 리뉴얼로 진행했습니다.

이유가 있었습니다. 클라이언트가 6년 전에 만든 앱이었고, 이걸 되살려서 실서비스를 운영하려는 게 아니었습니다. 투자 유치를 위한 PoC(개념 증명) 목적이었습니다. 투자사에 가져가서 "이 서비스가 동작한다"를 보여주기 위한 것이지, 수만 명이 쓰는 안정적인 서비스를 만드는 게 목표가 아니었습니다.

이 목적이라면 리빌드는 과한 선택입니다. 시간도 비용도 몇 배로 들고, PoC에 필요한 건 "동작하는 데모"이지 "완벽한 아키텍처"가 아니니까요. deprecated된 모듈을 하나씩 대체하고, 영향 범위를 추적하면서 순차적으로 수정해서, 최소한의 비용으로 동작하는 상태까지 끌어올렸습니다.

다만 이건 타이밍이 간신히 맞았던 케이스입니다. 앱스토어는 특정 주기마다 최소 지원 OS 버전을 올립니다. 이 프로젝트는 마지막 주기에 걸려 있었고, 만약 한 버전만 더 올라갔으면 리빌드밖에 답이 없었습니다. 그만큼 아슬아슬한 상황이었습니다.

결국 리뉴얼이냐 리빌드냐는 "얼마나 망가져 있느냐"와 "타이밍을 놓치지 않았느냐"의 문제입니다. 방치하는 기간이 길어질수록 리뉴얼의 선택지는 사라지고, 리빌드만 남게 됩니다.

클라이언트는 리뉴얼을 원하고, 개발사는 꺼린다

클라이언트 입장에서 리뉴얼은 매력적입니다. "조금만 고치면 되는 거 아니야?" 기존에 만든 것이 있으니까, 거기서 살짝 수정해서 운영 가능한 수준이면 된다고 생각합니다.

반면 외주 개발사 입장에서 리뉴얼은 꺼리는 작업입니다. 다른 사람이 작성한 코드를 분석하는 시간 대비 수익이 나오지 않고, 기존 코드를 신뢰할 수 없다는 근본적인 불안감이 있습니다. 내가 작성하지 않은 코드에서 언제 어디서 버그가 터질지 모르는데, 리뉴얼을 맡는 순간 그 모든 버그를 뒤집어써야 합니다. "이거 원래 있던 버그예요"라고 해도, 클라이언트 입장에서는 "당신이 고친 뒤에 생긴 거 아니에요?"가 됩니다.

그래서 "리뉴얼해주세요"라고 하면 "새로 만드는 게 낫습니다"라고 답하는 개발사가 많습니다. 진짜 리빌드가 맞아서 그런 경우도 있지만, 리스크를 피하고 싶어서인 경우도 솔직히 있습니다.

저희가 리뉴얼을 맡을 때는 범위의 선을 명확하게 긋습니다. "이번에 수정하는 범위는 여기까지이고, 기존 코드에서 발생하는 기존 버그는 별도 범위입니다." 이걸 사전에 합의하지 않으면 리뉴얼 프로젝트는 반드시 분쟁이 생깁니다. 다만 현실에서는 선을 그었다고 끝이 아닙니다. 기존 코드에서 장애가 터지면, 누구 잘못이냐를 따지기 전에 일단 급하게 해결해야 합니다. 서비스가 멈춰있는데 "이건 제 범위가 아닙니다"라고 할 수는 없으니까요. 리뉴얼 프로젝트가 개발사에게 부담이 큰 이유입니다.

왜 외주 개발사에 리뉴얼/리빌드를 맡기게 되는가

리뉴얼이나 리빌드 의뢰가 들어오는 배경을 보면, 다양한 사정이 있습니다.

  • 인하우스 개발자를 내보내고 외주로 전환하려는 경우: 개발자 채용, 연봉 협상, 퇴사 관리, 기술 역량 평가 — 내부 개발 인력을 관리하는 것 자체가 만만치 않은 일입니다. 이 부담을 줄이기 위해 외주로 전환하려는 목적
  • 이전 개발사와 관계가 틀어진 경우: 소통 문제, 품질 문제, 비용 분쟁 등으로 기존 개발사와 더 이상 일할 수 없는 상태
  • 내부 개발자들이 지쳐있는 경우: 자체 인력이 있지만, 레거시 코드를 만지는 작업을 너무 오래 해서 팀이 지쳐있고, 그 프로젝트를 외부에 넘기고 싶어함
  • 원래 만든 사람이 아무도 없는 경우: 퇴사, 폐업 등으로 코드를 아는 사람이 사라진 상태

각각의 상황에 따라 리뉴얼이 맞을 수도, 리빌드가 맞을 수도 있습니다. 중요한 건 "왜 이 상황이 됐는지"를 정확히 파악하는 것입니다. 원인을 모른 채 작업을 시작하면, 같은 문제가 반복됩니다.

"리뉴얼해주세요"인데 실제로는 리빌드인 경우

상담에서 가장 많이 겪는 상황입니다.

"리뉴얼해주세요"라고 오시는 분의 절반 이상이, 실제로는 리빌드가 필요한 상태입니다. 클라이언트 입장에서는 "기존 것을 좀 고치면 되지 않나?" 싶지만, 코드를 열어보면 이야기가 달라집니다.

실제 사례들:

  • 디자인만 바꾸고 싶다고 했는데, 프론트엔드와 백엔드가 분리되지 않은 구조라 디자인만 바꾸는 게 불가능
  • 기능 몇 개 추가하고 싶다고 했는데, 기존 DB 구조가 새 기능을 수용할 수 없음
  • 속도를 개선하고 싶다고 했는데, 근본적인 아키텍처 문제라 튜닝으로는 해결 불가

이런 경우 "리뉴얼 비용"으로 시작했다가, 중간에 "이건 새로 만들어야 합니다"로 바뀌면 프로젝트가 꼬입니다. 처음부터 현실적인 진단이 필요합니다.

판단 기준 5가지

리뉴얼과 리빌드 사이에서 고민이라면, 아래 기준으로 판단해보세요.

1. 코드 품질

  • 다른 개발자가 코드를 읽고 이해할 수 있는가?
  • 테스트 코드가 있는가?
  • 코드에 일관된 패턴이 있는가?

코드를 아무도 이해하지 못하면, 리뉴얼 비용이 리빌드 비용을 초과할 수 있습니다.

2. 기술 스택

  • 프레임워크의 최신 버전이 아직 지원되는가?
  • 보안 패치가 나오고 있는가?
  • 해당 기술을 다룰 수 있는 개발자를 구할 수 있는가?

개발자를 구하기 어려운 기술 스택이면, 유지보수 자체가 어렵습니다.

3. 수정 범위

  • 전체의 30% 이하를 수정하면 되는가 → 리뉴얼
  • 전체의 70% 이상을 건드려야 하는가 → 리빌드

애매한 50% 구간이 가장 어렵습니다. 이때는 코드 품질과 기술 스택을 함께 고려해야 합니다.

4. 비즈니스 변화

  • 서비스의 핵심 기능이 바뀌었는가?
  • 타겟 사용자가 바뀌었는가?
  • 수익 모델이 바뀌었는가?

비즈니스 자체가 바뀌었으면, 기존 구조로는 담을 수 없는 경우가 많습니다.

5. 데이터 마이그레이션

  • 기존 데이터를 새 구조로 옮길 수 있는가?
  • 데이터 손실 없이 전환이 가능한가?

리빌드를 하더라도 데이터는 이전해야 합니다. 이 부분의 난이도가 의사결정에 큰 영향을 줍니다.

정리

  • 리뉴얼: 코드 품질이 괜찮고, 기술 스택이 현역이고, 부분 수정으로 해결 가능할 때
  • 리빌드: 코드를 이해할 수 없고, 기술이 노후화됐고, 비즈니스 자체가 바뀌었을 때
  • 핵심: "리뉴얼해주세요"라고 오시더라도, 코드를 먼저 진단해야 정확한 판단이 가능합니다

잘못된 판단은 비용을 두 배로 만듭니다. 리뉴얼해야 할 것을 리빌드하면 시간과 돈을 낭비하고, 리빌드해야 할 것을 리뉴얼하면 끝없는 수정의 늪에 빠집니다.

*기존 서비스의 리뉴얼 또는 리빌드 판단이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 코드 진단 후 현실적인 방향을 안내드립니다.*


리뉴얼,리빌드,레거시,기술부채
다른 포스팅
Blog·인사이트

리뉴얼 해야 할 때 vs 새로 만들어야 할 때

··7분 읽기

"서비스가 느려요." "새로운 기능을 추가하려는데 구조가 안 받쳐줘요." "디자인이 오래돼서 리뉴얼하고 싶어요."

이런 상황에서 두 가지 선택지가 있습니다. 기존 코드 위에 수정하는 리뉴얼과, 처음부터 새로 만드는 리빌드. 어느 쪽이 맞는지는 상황에 따라 완전히 다릅니다.

리뉴얼이 맞는 경우

기존 코드 기반을 유지하면서 부분적으로 개선하는 방식입니다.

이런 상황이라면 리뉴얼

  • 코드 품질이 나쁘지 않다: 구조가 잡혀있고, 다른 개발자가 읽고 이해할 수 있는 수준
  • 기술 스택이 현역이다: React, Vue, Django, Spring 같은 메인스트림 기술을 쓰고 있음
  • 문제가 특정 부분에 집중돼 있다: 전체가 아니라 일부 기능이나 화면만 수정하면 됨
  • 데이터가 많이 쌓여있다: DB 구조 자체는 괜찮고, 마이그레이션 리스크를 피하고 싶음
  • 시간이 부족하다: 전체를 새로 만들 여유가 없고, 부분 개선으로 효과를 볼 수 있음

리뉴얼의 장점은 비용과 시간입니다. 기존에 잘 동작하는 부분은 그대로 두고, 문제가 되는 부분만 고칩니다. 리스크도 상대적으로 적습니다.

리빌드가 맞는 경우

기존 코드를 버리고 처음부터 다시 만드는 방식입니다. 비용과 시간이 많이 들지만, 필요한 순간이 분명히 있습니다.

이런 상황이라면 리빌드

  • 코드를 아무도 이해 못 한다: 원래 개발자가 떠났고, 문서도 없고, 코드 구조가 엉망
  • 기술 스택이 수명을 다했다: PHP 4, jQuery 기반 레거시, 더 이상 보안 패치도 안 나오는 프레임워크
  • 부분 수정이 전체에 영향을 준다: 하나를 고치면 다른 곳이 터지는 스파게티 구조
  • 비즈니스 모델이 바뀌었다: B2C였던 서비스를 B2B로 전환, 단순 정보 제공에서 거래 플랫폼으로 변경
  • 확장이 구조적으로 불가능하다: 동시 접속 100명을 기준으로 설계된 서비스에 1만 명이 들어와야 하는 상황

리빌드는 비용이 크지만, 잘못된 기반 위에 계속 덧붙이는 것보다 결과적으로 저렴할 수 있습니다.

리빌드 직전까지 갔던 사례

앱 서비스를 리뉴얼 해달라는 의뢰가 들어온 적이 있습니다. 열어보니 상태가 심각했습니다. 사용하고 있던 주요 의존 모듈(코덱, 미디어 라이브러리 등)이 deprecated되어 더 이상 업데이트가 제공되지 않았고, 앱이 타겟하는 OS 최소 버전도 크게 올라가면서 기존 코드가 최신 OS에서 빌드 자체가 위태로운 상태였습니다.

보통 이런 경우 리빌드를 권하는 개발사가 많습니다. deprecated된 모듈을 대체하려면 해당 모듈에 의존하는 코드를 전부 뜯어고쳐야 하고, OS 타겟 버전을 올리면 호환이 안 되는 API 호출이 줄줄이 터지니까요. 하나를 고치면 열 개가 깨지는 상황.

객관적으로 보면 리빌드가 맞는 상태였습니다. 그런데 저희는 리뉴얼로 진행했습니다.

이유가 있었습니다. 클라이언트가 6년 전에 만든 앱이었고, 이걸 되살려서 실서비스를 운영하려는 게 아니었습니다. 투자 유치를 위한 PoC(개념 증명) 목적이었습니다. 투자사에 가져가서 "이 서비스가 동작한다"를 보여주기 위한 것이지, 수만 명이 쓰는 안정적인 서비스를 만드는 게 목표가 아니었습니다.

이 목적이라면 리빌드는 과한 선택입니다. 시간도 비용도 몇 배로 들고, PoC에 필요한 건 "동작하는 데모"이지 "완벽한 아키텍처"가 아니니까요. deprecated된 모듈을 하나씩 대체하고, 영향 범위를 추적하면서 순차적으로 수정해서, 최소한의 비용으로 동작하는 상태까지 끌어올렸습니다.

다만 이건 타이밍이 간신히 맞았던 케이스입니다. 앱스토어는 특정 주기마다 최소 지원 OS 버전을 올립니다. 이 프로젝트는 마지막 주기에 걸려 있었고, 만약 한 버전만 더 올라갔으면 리빌드밖에 답이 없었습니다. 그만큼 아슬아슬한 상황이었습니다.

결국 리뉴얼이냐 리빌드냐는 "얼마나 망가져 있느냐"와 "타이밍을 놓치지 않았느냐"의 문제입니다. 방치하는 기간이 길어질수록 리뉴얼의 선택지는 사라지고, 리빌드만 남게 됩니다.

클라이언트는 리뉴얼을 원하고, 개발사는 꺼린다

클라이언트 입장에서 리뉴얼은 매력적입니다. "조금만 고치면 되는 거 아니야?" 기존에 만든 것이 있으니까, 거기서 살짝 수정해서 운영 가능한 수준이면 된다고 생각합니다.

반면 외주 개발사 입장에서 리뉴얼은 꺼리는 작업입니다. 다른 사람이 작성한 코드를 분석하는 시간 대비 수익이 나오지 않고, 기존 코드를 신뢰할 수 없다는 근본적인 불안감이 있습니다. 내가 작성하지 않은 코드에서 언제 어디서 버그가 터질지 모르는데, 리뉴얼을 맡는 순간 그 모든 버그를 뒤집어써야 합니다. "이거 원래 있던 버그예요"라고 해도, 클라이언트 입장에서는 "당신이 고친 뒤에 생긴 거 아니에요?"가 됩니다.

그래서 "리뉴얼해주세요"라고 하면 "새로 만드는 게 낫습니다"라고 답하는 개발사가 많습니다. 진짜 리빌드가 맞아서 그런 경우도 있지만, 리스크를 피하고 싶어서인 경우도 솔직히 있습니다.

저희가 리뉴얼을 맡을 때는 범위의 선을 명확하게 긋습니다. "이번에 수정하는 범위는 여기까지이고, 기존 코드에서 발생하는 기존 버그는 별도 범위입니다." 이걸 사전에 합의하지 않으면 리뉴얼 프로젝트는 반드시 분쟁이 생깁니다. 다만 현실에서는 선을 그었다고 끝이 아닙니다. 기존 코드에서 장애가 터지면, 누구 잘못이냐를 따지기 전에 일단 급하게 해결해야 합니다. 서비스가 멈춰있는데 "이건 제 범위가 아닙니다"라고 할 수는 없으니까요. 리뉴얼 프로젝트가 개발사에게 부담이 큰 이유입니다.

왜 외주 개발사에 리뉴얼/리빌드를 맡기게 되는가

리뉴얼이나 리빌드 의뢰가 들어오는 배경을 보면, 다양한 사정이 있습니다.

  • 인하우스 개발자를 내보내고 외주로 전환하려는 경우: 개발자 채용, 연봉 협상, 퇴사 관리, 기술 역량 평가 — 내부 개발 인력을 관리하는 것 자체가 만만치 않은 일입니다. 이 부담을 줄이기 위해 외주로 전환하려는 목적
  • 이전 개발사와 관계가 틀어진 경우: 소통 문제, 품질 문제, 비용 분쟁 등으로 기존 개발사와 더 이상 일할 수 없는 상태
  • 내부 개발자들이 지쳐있는 경우: 자체 인력이 있지만, 레거시 코드를 만지는 작업을 너무 오래 해서 팀이 지쳐있고, 그 프로젝트를 외부에 넘기고 싶어함
  • 원래 만든 사람이 아무도 없는 경우: 퇴사, 폐업 등으로 코드를 아는 사람이 사라진 상태

각각의 상황에 따라 리뉴얼이 맞을 수도, 리빌드가 맞을 수도 있습니다. 중요한 건 "왜 이 상황이 됐는지"를 정확히 파악하는 것입니다. 원인을 모른 채 작업을 시작하면, 같은 문제가 반복됩니다.

"리뉴얼해주세요"인데 실제로는 리빌드인 경우

상담에서 가장 많이 겪는 상황입니다.

"리뉴얼해주세요"라고 오시는 분의 절반 이상이, 실제로는 리빌드가 필요한 상태입니다. 클라이언트 입장에서는 "기존 것을 좀 고치면 되지 않나?" 싶지만, 코드를 열어보면 이야기가 달라집니다.

실제 사례들:

  • 디자인만 바꾸고 싶다고 했는데, 프론트엔드와 백엔드가 분리되지 않은 구조라 디자인만 바꾸는 게 불가능
  • 기능 몇 개 추가하고 싶다고 했는데, 기존 DB 구조가 새 기능을 수용할 수 없음
  • 속도를 개선하고 싶다고 했는데, 근본적인 아키텍처 문제라 튜닝으로는 해결 불가

이런 경우 "리뉴얼 비용"으로 시작했다가, 중간에 "이건 새로 만들어야 합니다"로 바뀌면 프로젝트가 꼬입니다. 처음부터 현실적인 진단이 필요합니다.

판단 기준 5가지

리뉴얼과 리빌드 사이에서 고민이라면, 아래 기준으로 판단해보세요.

1. 코드 품질

  • 다른 개발자가 코드를 읽고 이해할 수 있는가?
  • 테스트 코드가 있는가?
  • 코드에 일관된 패턴이 있는가?

코드를 아무도 이해하지 못하면, 리뉴얼 비용이 리빌드 비용을 초과할 수 있습니다.

2. 기술 스택

  • 프레임워크의 최신 버전이 아직 지원되는가?
  • 보안 패치가 나오고 있는가?
  • 해당 기술을 다룰 수 있는 개발자를 구할 수 있는가?

개발자를 구하기 어려운 기술 스택이면, 유지보수 자체가 어렵습니다.

3. 수정 범위

  • 전체의 30% 이하를 수정하면 되는가 → 리뉴얼
  • 전체의 70% 이상을 건드려야 하는가 → 리빌드

애매한 50% 구간이 가장 어렵습니다. 이때는 코드 품질과 기술 스택을 함께 고려해야 합니다.

4. 비즈니스 변화

  • 서비스의 핵심 기능이 바뀌었는가?
  • 타겟 사용자가 바뀌었는가?
  • 수익 모델이 바뀌었는가?

비즈니스 자체가 바뀌었으면, 기존 구조로는 담을 수 없는 경우가 많습니다.

5. 데이터 마이그레이션

  • 기존 데이터를 새 구조로 옮길 수 있는가?
  • 데이터 손실 없이 전환이 가능한가?

리빌드를 하더라도 데이터는 이전해야 합니다. 이 부분의 난이도가 의사결정에 큰 영향을 줍니다.

정리

  • 리뉴얼: 코드 품질이 괜찮고, 기술 스택이 현역이고, 부분 수정으로 해결 가능할 때
  • 리빌드: 코드를 이해할 수 없고, 기술이 노후화됐고, 비즈니스 자체가 바뀌었을 때
  • 핵심: "리뉴얼해주세요"라고 오시더라도, 코드를 먼저 진단해야 정확한 판단이 가능합니다

잘못된 판단은 비용을 두 배로 만듭니다. 리뉴얼해야 할 것을 리빌드하면 시간과 돈을 낭비하고, 리빌드해야 할 것을 리뉴얼하면 끝없는 수정의 늪에 빠집니다.

*기존 서비스의 리뉴얼 또는 리빌드 판단이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 코드 진단 후 현실적인 방향을 안내드립니다.*


리뉴얼,리빌드,레거시,기술부채
다른 포스팅
WebGL프로젝트 상담