초록
"고쳐 쓸까, 새로 지을까"는 견적을 받기 전에 의뢰인이 먼저 정해 오는 것으로 취급되지만, 실제로는 견적을 받아 봐야 판단이 서는 종류의 질문입니다. 그리고 이 질문이 어려운 이유는 취향이나 예산 때문이 아니라, 리뉴얼이라는 말이 서로 다른 네 가지 작업을 뭉뚱그리고 있기 때문입니다. 이 글은 리뉴얼을 "기존 자산의 계승"으로 정의한 뒤, 계승 가능한 자산을 코드·정보구조·데이터·검색 네 가지로 분해합니다. 그런 다음 각 축에서 계승률이 떨어질 때 비용이 어떻게 움직이는지를 비용 구성표로 보이고, 리뉴얼 견적이 신규 구축을 역전하는 조건을 명시합니다. 이어서 현장에서 자주 만나는 세 가지 출발 상황별로 판단이 어떻게 갈리는지, 그리고 리뉴얼 견적에서 습관적으로 누락되는 항목이 무엇인지를 정리합니다. 마지막으로 업체에 묻기 전에 내부에서 순서대로 답해야 할 질문 목록을 제시합니다. 특정 CMS나 프레임워크의 우열은 다루지 않으며, 도구가 바뀌어도 유지되는 판단 구조에 초점을 맞춥니다.
1. 서론
리뉴얼은 직관적으로 싸 보입니다. 이미 있는 것을 고치는 일이니까요. 그런데 실무에서 리뉴얼 견적이 신규 구축과 비슷하게 나오거나 더 비싸게 나오는 경우가 드물지 않고, 그때 의뢰인이 받는 인상은 대개 "업체가 바가지를 씌운다"입니다.
이 인상이 생기는 이유는 양쪽이 다른 것을 세고 있어서입니다. 의뢰인은 화면을 셉니다. 페이지 수가 그대로고 기능도 그대로니 새로 만드는 것보다 적게 들어야 한다고 봅니다. 개발 쪽은 작업을 셉니다. 기존 코드를 읽고, 어디가 왜 그렇게 짜였는지 파악하고, 건드리면 안 되는 부분을 식별하는 시간이 새로 짜는 시간보다 길어질 수 있다는 것을 압니다.
둘 다 틀리지 않았습니다. 다만 "리뉴얼"이라는 한 단어가 최소 네 가지 서로 다른 작업을 덮고 있고, 그중 어느 것을 말하는지가 합의되지 않은 채 견적이 오갑니다.
여기에 구조적인 문제가 하나 더 있습니다. 이 질문에 답하는 데 필요한 정보 대부분이 의뢰인 쪽에 있는데, 그 정보를 해석할 능력은 개발 쪽에 있다는 것입니다. 소스가 어디 있는지, 계정 권한이 누구에게 있는지, 데이터가 몇 건인지는 회사 안에 있는 정보입니다. 그런데 그 정보가 "코드를 계승할 수 있다/없다"로 번역되려면 개발 쪽이 봐야 합니다. 그래서 판단이 겉돌고, 결국 "일단 견적부터 받아 보자"로 흘러갑니다.
이 글은 그 번역 규칙을 미리 공개하는 데 목적이 있습니다. 규칙을 알면 견적을 받기 전에 어느 쪽인지 대략 짐작할 수 있고, 짐작이 서면 견적서의 숫자가 읽히기 시작합니다.
2. 리뉴얼이 실제로 가리키는 네 가지 작업
같은 단어로 불리지만 비용 구조가 완전히 다른 네 가지가 있습니다.
첫째, 표면 교체. 화면 디자인만 바꾸고 뒤쪽 구조와 데이터는 그대로 둡니다. 페이지 주소도, 관리자 화면도, 저장된 글도 그대로입니다. 가장 싸고 가장 빠릅니다. 비용의 대부분이 디자인과 퍼블리싱에 몰리고, 데이터 이관과 검색 자산 이전은 0에 가깝습니다.
둘째, 구조 재편. 메뉴와 페이지 구성을 바꿉니다. 있던 페이지가 사라지고, 없던 분류가 생기고, 주소가 달라집니다. 화면 작업량은 첫째와 비슷할 수 있지만 주소가 바뀌는 순간 검색 자산 이관이라는 별도 작업이 붙고, 기획 비용이 신규 구축 수준으로 올라갑니다.
셋째, 기반 이전. 만들어진 도구 자체를 바꿉니다. 워드프레스에서 직접 개발로, 혹은 그 반대로. 화면이 똑같아 보여도 안쪽은 전부 새로 짜입니다. 여기서부터 "리뉴얼"이라는 말은 사실상 신규 구축에 데이터 이관을 얹은 것에 가까워집니다.
넷째, 기능 확장. 기존 사이트에 없던 것을 붙입니다. 결제, 회원, 예약, 연동 같은 것들입니다. 기존 코드를 계승하느냐는 여기서 비용을 줄이는 요인이 아니라 제약 조건으로 작동합니다. 새로 짜면 자유롭게 설계할 것을, 기존 구조에 맞춰 끼워 넣어야 하기 때문입니다.
의뢰서에 "리뉴얼"이라고만 쓰면 업체마다 이 중 다른 것을 가정하고 견적을 냅니다. 견적이 두세 배로 갈리는 흔한 원인입니다.
그리고 실무에서는 이 넷이 섞여서 들어옵니다. "디자인도 바꾸고, 메뉴도 정리하고, 문의 폼도 제대로 만들고 싶다"가 한 문장으로 들어오면 첫째·둘째·넷째가 동시에 걸립니다. 이때 견적을 하나의 총액으로 받으면 어느 항목이 얼마인지 알 수 없고, 예산이 부족할 때 무엇을 뺄지 판단할 근거도 없습니다.
3. 계승 자산이라는 기준
리뉴얼과 신규 구축을 가르는 실질적 기준은 하나입니다. 기존 사이트에서 실제로 넘어오는 것이 무엇인가. 넘어오는 것이 많으면 리뉴얼이고, 적으면 이름만 리뉴얼입니다.
넘어올 수 있는 자산은 네 종류입니다.
3-1. 코드
기존 코드를 읽고 이어서 쓸 수 있는가입니다. 이것은 코드가 좋으냐 나쁘냐의 문제라기보다 읽을 수 있느냐의 문제입니다. 판단 재료는 세 가지입니다.
- 어떤 도구로 만들어졌고, 그 도구의 지원이 아직 살아 있는가
- 코드가 한곳에 모여 있고 버전 기록이 남아 있는가
- 만든 사람이 남긴 설명이 있는가, 혹은 만든 사람과 연락이 되는가
셋 다 있으면 계승이 쉽고, 하나만 있어도 어렵지 않습니다. 셋 다 없으면 — 예를 들어 파일이 서버에 직접 올라가 있고 버전 기록이 없고 만든 업체와 연락이 끊긴 경우 — 새로 짜는 편이 읽는 것보다 빠릅니다. 이 판단은 업체가 오만해서 내리는 것이 아니라, 읽기 비용이 쓰기 비용을 넘어서는 지점이 실재하기 때문입니다.
읽기 비용이 특히 커지는 조건이 몇 가지 있습니다. 여러 업체가 순차로 손댄 흔적이 있는 경우, 같은 기능이 두세 군데에 중복으로 구현된 경우, 그리고 어떤 코드가 실제로 실행되고 있는지 알 수 없는 경우입니다. 마지막 조건이 가장 나쁩니다. 지우면 안 되는 코드와 지워도 되는 코드를 구분할 수 없으면, 아무것도 지우지 못한 채 위에 얹기만 하게 되고, 그 상태로는 어떤 작업도 예측 가능하지 않습니다.
3-2. 정보구조
메뉴와 페이지의 뼈대입니다. 이것이 그대로라면 기획 단계 상당 부분이 생략됩니다. 반대로 뼈대를 다시 짜야 한다면 화면이 아무리 적어도 기획 비용은 신규와 같아집니다.
여기서 흔한 오해가 있습니다. "페이지 수가 같으니 기획은 필요 없다"는 것입니다. 그런데 리뉴얼을 결심하는 계기 자체가 대개 "지금 구조로는 원하는 걸 못 보여준다"입니다. 즉 리뉴얼을 하려는 이유가 이미 정보구조 변경을 함의하고 있는 경우가 많습니다.
정보구조가 바뀌는지 아닌지를 가르는 간단한 시험이 있습니다. 지금 메뉴를 그대로 두고 원하는 변화를 설명할 수 있는가. "제품 페이지를 더 잘 보이게"는 메뉴를 안 바꿔도 됩니다. "제품이 늘어서 분류가 필요하다"는 메뉴가 바뀝니다. 후자면 기획을 새로 하는 것이고, 그 비용은 신규 구축과 같습니다.
3-3. 데이터
쌓여 있는 글, 이미지, 회원, 주문 기록입니다. 이것은 거의 항상 넘겨야 하고, 넘기는 비용은 양이 아니라 형태의 일치도로 결정됩니다.
같은 형태로 옮기면 양이 많아도 자동으로 처리됩니다. 형태가 달라지면 — 예를 들어 하나의 본문 덩어리를 제목·요약·본문·태그로 쪼개야 한다면 — 양에 비례해서 사람 손이 들어갑니다. 글 500건을 옮기는 작업이 50건 옮기는 작업의 열 배가 아니라 백 배가 되는 구간이 여기입니다.
형태 불일치가 생기는 전형적인 경우는 이렇습니다.
| 지금 상태 | 새 구조 | 결과 |
|---|---|---|
| 본문 HTML 안에 이미지가 박혀 있음 | 대표 이미지를 별도 필드로 관리 | 건당 수작업 |
| 분류 없이 시간순 목록만 | 카테고리·태그 도입 | 건당 분류 지정 |
| 제목과 본문만 존재 | 목록에 노출할 요약문 필요 | 건당 요약 작성 |
| 이미지가 원본 크기로 업로드됨 | 반응형 이미지 세트 생성 | 자동화 가능하나 검수 필요 |
이 표에서 위 세 줄은 자동화가 어렵고, 마지막 줄은 자동화가 됩니다. 자동화 가능 여부가 비용의 자릿수를 바꿉니다.
3-4. 검색 자산
가장 자주 누락되는 항목입니다. 지금 사이트가 검색에서 어느 정도 노출되고 있다면, 그 노출은 개별 주소 단위로 쌓인 것입니다. 주소가 바뀌면 그 축적은 자동으로 따라오지 않습니다.
주소 하나하나를 새 주소로 연결해 주는 작업(리다이렉트)이 필요하고, 이것은 페이지가 많을수록, 그리고 구조가 많이 바뀔수록 늘어납니다. 이 작업을 건너뛰면 오픈 직후 검색 유입이 눈에 띄게 떨어지고, 회복에는 몇 달이 걸립니다. 리뉴얼에서 가장 조용하게 비싼 항목입니다.
규칙으로 처리되는 경우와 그렇지 않은 경우를 구분하면 규모가 가늠됩니다. /board/123 형태가 /blog/123으로 일괄 변환된다면 규칙 하나로 끝납니다. 반면 옛 주소가 /bbs/view.php?id=123 같은 형태이고 새 주소가 글 제목을 쓴다면, 옛 번호와 새 주소를 짝지어 놓은 대응표가 있어야 합니다. 대응표는 건수에 비례해 만들어야 하고, 이 작업은 보이지 않는데 시간이 듭니다.
4. 계승률을 숫자로 놓고 보기
네 축의 계승 여부에 따라 비용 구성이 어떻게 달라지는지를, 신규 구축을 100으로 놓고 상대 비율로 표시하면 이렇게 됩니다. 실제 단가가 아니라 구성비의 형태를 보기 위한 도식입니다.
| 항목 | 신규 구축 | ① 표면 교체 | ② 구조 재편 | ③ 기반 이전 |
|---|---|---|---|---|
| 기획·정보구조 | 20 | 3 | 20 | 20 |
| 디자인 | 25 | 25 | 25 | 25 |
| 개발·구현 | 45 | 15 | 30 | 45 |
| 기존 코드 파악 | 0 | 5 | 10 | 10 |
| 데이터 이관 | 5 | 0 | 8 | 15 |
| 리다이렉트·검색 이전 | 0 | 0 | 10 | 10 |
| 합계 | 95 | 48 | 103 | 125 |
읽어야 할 것은 세 가지입니다.
첫째, ①은 확실히 쌉니다. 절반 수준입니다. 리뉴얼이 싸다는 통념은 이 칸에서만 성립합니다.
둘째, ②에서 이미 신규 구축을 넘어섭니다. 기획을 다시 하는데 기존 코드 파악과 리다이렉트가 추가되기 때문입니다. 개발 항목이 줄어든 만큼을 나머지가 상쇄합니다.
셋째, ③은 명백히 더 비쌉니다. 신규 구축의 모든 항목을 그대로 치르면서 이관 작업이 얹히기 때문입니다. 이 경우 "리뉴얼"이라는 이름은 비용에 대해 아무것도 설명하지 못합니다.
여기서 나오는 실무적 결론이 하나 있습니다. ③이라는 판정이 나왔다면, 그 시점에 던져야 할 질문은 "리뉴얼 비용을 어떻게 줄이지"가 아니라 **"이관해야 할 데이터를 정말 다 가져가야 하나"**입니다. 5년 치 공지 중 실제로 열람되는 것이 최근 1년 치뿐이라면, 나머지를 옮기지 않는 결정만으로 이관 비용이 크게 줄어듭니다. 이것은 업체가 먼저 제안하기 어려운 종류의 결정입니다. 자료를 버리자는 제안이기 때문입니다.
5. 비용이 역전하는 조건
앞의 표를 조건문으로 바꾸면 이렇습니다.
코드 계승이 불가능하면 셋째 유형(기반 이전)이 되고, 이 시점에서 리뉴얼과 신규 구축의 구축 비용은 거의 같아집니다. 다른 점은 리뉴얼 쪽에 데이터 이관과 리다이렉트가 추가로 붙는다는 것뿐입니다. 즉 이 경우 리뉴얼이 구조적으로 더 비쌉니다.
정보구조를 다시 짜야 하면 기획 비용이 신규와 같아집니다. 화면 작업만 줄어듭니다.
데이터 형태가 바뀌면 이관 비용이 데이터 양에 비례해 늘어납니다. 오래된 사이트일수록 이 항목이 큽니다. 역설적으로 자산이 많이 쌓인 사이트일수록 리뉴얼이 비싸집니다.
검색 노출이 있으면 리다이렉트 작업이 추가됩니다. 노출이 없으면 이 항목은 0이고, 이때는 미련 없이 새로 짓는 편이 대개 낫습니다.
정리하면 이렇습니다. 리뉴얼이 확실히 싼 경우는 표면만 바꾸는 경우 하나뿐입니다. 그 외에는 계승되는 항목을 하나씩 세어 봐야 알 수 있고, 세어 본 결과가 신규 구축보다 비싸게 나오는 것은 이상한 일이 아닙니다.
6. 자주 나오는 세 가지 출발 상황
현장에서 만나는 상황은 대개 아래 셋 중 하나입니다.
상황 A — 오래된 워드프레스, 플러그인이 많이 붙어 있음
계승 판단이 갈리는 전형적인 경우입니다. 워드프레스 자체는 지원이 살아 있으니 코드 계승이 원칙적으로 가능합니다. 문제는 플러그인입니다.
플러그인이 10개 넘게 붙어 있고 그중 몇 개가 업데이트가 끊긴 상태라면, 그 기능들을 어떻게 처리할지가 먼저 정해져야 합니다. 대체 플러그인을 찾을지, 직접 구현할지, 아니면 그 기능을 포기할지입니다. 이 결정을 안 하고 견적을 요청하면 업체는 최악을 가정합니다.
권장 순서는 이렇습니다. 관리자 화면에서 플러그인 목록을 뽑고, 각각에 대해 "이게 없으면 어떤 화면이 안 되는가"를 적습니다. 답이 안 나오는 것은 안 쓰는 플러그인일 가능성이 높고, 그것들을 목록에서 빼는 것만으로 범위가 줄어듭니다.
상황 B — 자체 개발했는데 소스와 담당자가 없음
가장 자주 나오고 가장 답이 명확한 경우입니다. 소스가 서버에만 있고 버전 기록이 없고 만든 사람과 연락이 안 되면, 사실상 ③(기반 이전)입니다.
이때 아껴야 할 것은 코드가 아니라 데이터와 주소입니다. 코드를 살리려는 시도에 시간을 쓰는 대신, DB 백업을 확보하고 주소 목록을 뽑는 데 시간을 쓰는 편이 낫습니다. 서버 접근 권한이 확인되지 않는다면 그것부터가 프로젝트의 첫 과제입니다.
한 가지 덧붙이면, 이 상황에서 "일단 지금 사이트를 그대로 두고 새로 만들자"는 선택이 가능합니다. 기존 사이트를 끄지 않은 채 새 주소에서 만들고, 완성된 뒤에 도메인을 옮기는 방식입니다. 중단 위험이 낮아지는 대신 두 사이트를 잠시 동시에 유지하는 비용이 듭니다.
상황 C — 임대형 솔루션을 쓰다가 벗어나려는 경우
카페24, 아임웹, 윅스 같은 임대형에서 직접 개발로 옮기는 경우입니다. 여기서는 코드 계승이라는 개념 자체가 성립하지 않습니다. 코드에 접근할 수 없으니 처음부터 ③입니다.
대신 데이터는 대체로 내보내기 기능이 있어 확보가 쉽고, 주소 구조도 규칙적인 편이라 리다이렉트가 규칙으로 처리되는 경우가 많습니다. ③ 중에서는 비교적 순한 편입니다.
여기서 진짜 판단해야 할 것은 비용이 아니라 방향입니다. 임대형을 벗어나면 매달 나가던 사용료가 사라지는 대신 유지보수 책임이 생깁니다. 이 교환이 유리한지는 총소유비용 관점에서 따로 다룬 적이 있습니다.
7. 그런데도 리뉴얼을 고르는 이유
비용만 놓고 보면 신규 구축이 유리한 구간이 넓은데, 실무에서 리뉴얼을 선택하는 데에는 비용 밖의 이유가 있습니다.
중단 없는 운영. 기존 사이트를 띄워 둔 채로 작업할 수 있습니다. 신규 구축도 그렇게 할 수 있지만, 전환 시점의 위험은 리뉴얼 쪽이 대체로 낮습니다.
검증된 것을 건드리지 않기. 몇 년 동안 문제없이 돌아간 결제나 폼이 있다면, 그것을 그대로 두는 선택에는 값이 있습니다. 새로 짜면 다시 검증해야 하고, 검증 비용은 견적서에 잘 안 잡힙니다.
조직의 학습 자산. 담당자가 익숙한 관리 화면을 유지하면 교육 비용이 들지 않습니다. 관리자가 여러 명이고 이직이 잦은 조직일수록 이 항목이 큽니다.
이 세 가지가 중요한 상황이라면, 리뉴얼이 더 비싸더라도 합리적인 선택입니다. 비싸다는 것과 틀렸다는 것은 다릅니다. 다만 비싸다는 사실은 알고 고르는 편이 낫습니다.
8. 리뉴얼 견적에서 자주 빠지는 항목
견적서를 받았을 때 아래 항목이 안 보이면 물어보세요. 대부분 나중에 추가 비용으로 돌아옵니다.
리다이렉트 설정. 3-4에서 다룬 항목입니다. "SEO 최적화"라는 한 줄로 뭉뚱그려져 있으면 무엇을 포함하는지 확인이 필요합니다.
이미지 경로 정리. 본문 안에 옛 주소로 박힌 이미지 링크가 남으면 새 사이트에서 깨집니다. 건수가 많으면 일괄 치환이 필요하고, 이것은 별도 작업입니다.
폼 수신처 이전. 문의 폼이 어디로 가는지, 그 계정이 누구 것인지입니다. 기존 폼이 특정 개인 메일로 가고 있었다면 이번에 정리해야 합니다.
외부 연동 재설정. 애널리틱스, 검색 콘솔, 광고 태그, 채팅 위젯 같은 것들입니다. 새 사이트에 다시 붙여야 하고, 붙이는 것보다 어떤 것이 붙어 있었는지 찾아내는 일이 더 오래 걸립니다.
기존 사이트 종료 처리. 언제 내릴지, 백업을 얼마나 보관할지, 서버 계약을 언제 해지할지입니다. 이걸 안 정하면 몇 달 동안 두 곳에 돈이 나갑니다.
오픈 후 안정화 기간. 오픈 직후 며칠은 반드시 문제가 나옵니다. 그 대응이 계약에 포함인지 별도인지가 정해져 있어야 합니다.
9. 판단 절차
업체에 묻기 전에 내부에서 순서대로 답하면, 견적을 받았을 때 그 숫자가 왜 그런지 읽힙니다.
첫째, 지금 사이트를 왜 바꾸려 하는가를 한 문장으로 씁니다. "낡아 보여서"와 "문의가 안 들어와서"와 "제품이 늘어서 구조가 안 맞아서"는 전혀 다른 작업으로 이어집니다. 첫 번째는 ①, 세 번째는 ②입니다.
둘째, 넘어와야 하는 것을 목록으로 적습니다. 글, 이미지, 회원, 주문, 특정 페이지 주소. 각 항목 옆에 대략의 개수를 적습니다. 개수를 모르면 그것부터 확인합니다.
셋째, 지금 코드에 접근할 수 있는지 확인합니다. 소스가 어디 있는지, 계정 권한이 누구에게 있는지, 만든 곳과 연락이 되는지. 이 세 가지가 확인되지 않으면 어떤 업체도 정확한 리뉴얼 견적을 낼 수 없습니다. 모른다는 사실 자체가 견적을 올립니다.
넷째, 지금 검색 유입이 있는지 봅니다. 없다면 리다이렉트 부담이 사라지고 선택지가 넓어집니다. 있다면 유입 상위 주소 목록을 뽑아 둡니다.
다섯째, 옮기지 않아도 되는 것을 정합니다. 4장에서 언급한 결정입니다. 오래된 게시물, 안 쓰는 페이지, 사용하지 않는 기능을 이번에 버릴지 정하면 범위가 줄어듭니다.
여섯째, 그 다음에 견적을 요청합니다. 이때 "리뉴얼"이라고 쓰지 말고 2장에서 나눈 네 유형 중 무엇인지를 적습니다. 같은 조건에서 받은 견적끼리는 비교가 됩니다.
이 여섯 가지를 정리하는 데 걸리는 시간은 대개 반나절입니다. 그리고 이 반나절이 견적 편차를 가장 크게 줄입니다. 항목별 확인 방법은 지금 사이트 진단하기에 절차로 정리해 두었습니다.
10. 결론
리뉴얼이 싸다는 통념은 표면 교체에만 해당합니다. 그 밖의 경우에는 계승되는 자산을 코드·정보구조·데이터·검색 네 축으로 세어 봐야 하고, 계승률이 낮을수록 리뉴얼은 신규 구축에 이관 비용을 얹은 것이 됩니다. 자산이 많이 쌓인 오래된 사이트일수록 이 역전이 잘 일어납니다.
그러니 순서를 바꾸는 편이 낫습니다. "리뉴얼할까 새로 만들까"를 먼저 정하고 견적을 받는 대신, 무엇이 넘어오는지를 먼저 세고 그 결과로 둘 중 하나가 결정되게 하는 것입니다. 이 순서를 지키면 견적서의 숫자가 협상 대상이 아니라 설명 가능한 결과로 보이기 시작합니다.
그리고 한 가지 더. 리뉴얼 결정에서 가장 큰 비용 절감은 값을 깎는 데서 나오지 않고 범위를 줄이는 데서 나옵니다. 무엇을 옮기지 않을지, 무엇을 이번에 하지 않을지를 정하는 것이 협상보다 효과가 큽니다. 그 결정은 업체가 대신 해 줄 수 없습니다.
대략의 범위를 먼저 가늠하고 싶다면 외주 개발 비용 계산기에서 페이지 수와 필요한 기능만 골라 예상 구간을 확인할 수 있습니다. 연락처를 남기지 않아도 결과는 그대로 보입니다.