웹사이트 리뉴얼, 지금 해야 할까 — 고칠 것과 다시 만들 것을 가르는 기준

웹사이트 리뉴얼을 검토하기 시작하는 시점은 회사마다 놀라울 만큼 비슷합니다. 5년 전에 만든 사이트가 아직 돌아가기는 합니다. 다만 모바일에서 표와 이미지가 깨지고, 첫 화면이 뜨는 데 몇 초가 걸립니다. 관리자 페이지는 만들어 준 개발사만 손댈 수 있어서, 카테고리 하나를 추가하려면 메일을 보내고 이틀을 기다립니다. 영업팀이 요청한 상담 신청 폼 하나를 붙이는 데 처음 들었던 금액보다 높은 견적이 돌아옵니다. 그 개발사는 이미 담당자가 두 번 바뀌었고, 지금 남아 있는 사람은 이 시스템을 처음 설계한 사람이 아닙니다.

그래서 회의를 잡습니다. 그리고 그 회의는 대개 결론 없이 끝납니다. 지금 있는 것을 고쳐 쓸 것인지, 아니면 아예 다시 만들 것인지 판단할 기준이 회사 안에 없기 때문입니다.

이것은 취향의 문제가 아니라 예산의 문제입니다. 똑같이 “리뉴얼”이라고 부르지만, 부분 개선과 전면 재구축 사이에서 비용은 열 배까지 벌어집니다. 그리고 대부분의 회사는 이 판단을 내린 다음에 발주하는 것이 아니라, 발주한 다음에 판단하게 됩니다. 비용이 통제되지 않는 진짜 이유가 여기에 있습니다.

이 글은 고칠 것과 다시 만들 것을 가르는 기준, 그리고 그 기준을 누가 세워야 하는지를 정리합니다. 이미 웹 개발 외주를 검토 중이시라면, 발주서를 쓰기 전에 먼저 읽어 보시기 바랍니다.

디비컨설팅은 100건 이상의 프로젝트를 수행했고, 50개 이상의 글로벌 파트너사와 함께 프로젝트별 개발팀을 구성합니다. 고객 만족도는 98%입니다. 삼성물산 홈닉(주거 플랫폼 앱), GS건설 엘리시안 리조트(리조트 웹·앱 통합 구축), 직방 호갱노노(부동산 데이터 서비스), LS일렉트릭 테크스퀘어(산업 B2B 거래 플랫폼) 등 국내 대기업의 실서비스를 함께 만들어 왔습니다. 디비컨설팅은 시원스쿨(Siwon School) 계열사입니다. 회사에 대한 자세한 내용은 디비컨설팅 소개에서 확인하실 수 있습니다.

리뉴얼 프로젝트의 견적은 왜 계속 올라가는가

리뉴얼이 실패하는 방식은 몇 가지로 정해져 있습니다. 기술이 부족해서가 아니라, 발주 구조가 같은 자리에서 반복해서 무너지기 때문입니다. 신규 개발에서도 같은 구조적 문제가 반복되지만, 리뉴얼에서는 기존 시스템이라는 변수가 하나 더 붙습니다.

리뉴얼의 범위를 발주 전에 아무도 정의하지 않습니다

대부분의 리뉴얼은 “디자인만 좀 바꾸면 된다”에서 출발합니다. 그런데 새 디자인을 얹으려면 지금의 화면 구조로는 안 된다는 사실이 드러납니다. 화면 구조를 바꾸려니 데이터가 그 형태로 저장되어 있지 않습니다. 결국 처음에는 손댈 생각이 전혀 없었던 데이터 구조까지 열게 됩니다.

이 확장은 개발사가 욕심을 부려서 생기는 것이 아닙니다. 범위가 처음부터 정의된 적이 없기 때문에, 작업을 시작한 뒤에야 하나씩 발견되는 것입니다. 발주사 입장에서는 요청한 적 없는 일이 계속 추가되는 것처럼 보이고, 개발사 입장에서는 하지 않으면 완성이 안 되는 일입니다. 양쪽 다 맞는 말이라서 협상으로 풀리지 않습니다.

기존 시스템을 만든 개발사가 문서를 남기지 않았습니다

리뉴얼은 신규 개발과 다릅니다. 이미 돌아가고 있는 시스템을 읽는 일부터 시작합니다. 그런데 API 명세도, DB 스키마도, 배포 절차도 문서로 남아 있지 않은 경우가 많습니다. 남아 있는 것은 코드뿐이고, 그 코드를 쓴 사람은 이미 회사에 없습니다.

그러면 새 개발사는 견적에 “분석 기간”을 넣습니다. 그 기간은 정확히 예측되지 않기 때문에 넉넉하게 잡히고, 그럼에도 부족해서 다시 늘어납니다. 초기 견적의 1.5배가 되는 일은 드물지 않습니다. 앞선 프로젝트가 문서를 남기지 않았다는 이유 하나로, 이번 프로젝트의 예산이 올라가는 구조입니다. 서비스 개발에서 가장 비싼 비용이 사람을 관리하는 시간인 이유도 같은 자리에 있습니다.

고칠 것과 다시 만들 것을 섞어서 발주합니다

가장 비용이 많이 드는 실수입니다. 유지보수로 충분한 영역과 재구축이 필요한 영역이 하나의 발주서 안에 섞여 들어갑니다. 개발사는 어느 쪽 기준으로 견적을 내야 할지 알 수 없으므로, 리스크를 얹어서 산정하거나 일단 낮게 부르고 진행 중에 조정합니다.

어느 쪽이든 발주사에게는 같은 결과입니다. 견적이 계속 움직이고, 일정이 밀리고, 회사 안에서 “그래서 이 프로젝트 얼마짜리냐”에 답할 수 있는 사람이 없어집니다. 이것이 문제가 개발사가 아니라 구조에 있다고 말씀드리는 이유입니다.

선택지는 셋입니다 — 그리고 진짜 쟁점은 개발 단가가 아닙니다

	국내 개발사	해외 직접 발주	한국 PM + 글로벌 개발팀
개발 단가	높음	낮음	낮음
요구사항 정의 책임	개발사	발주사 본인	한국 PM
커뮤니케이션 언어	한국어	영어	한국어
발주사 담당자 투입 시간	보통	매우 많음	적음
재작업 리스크	낮음	높음	낮음
총비용 관점	비쌈	기대만큼 안 싸다	실질 절감

표에서 가장 중요한 줄은 개발 단가가 아니라 “요구사항 정의 책임”입니다. 해외 직접 발주가 기대만큼 저렴해지지 않는 이유가 정확히 여기에 있습니다. 시간당 단가는 분명히 내려가지만, 무엇을 만들 것인지 정의하는 일이 통째로 발주사에게 넘어옵니다. 화면 단위로 기능을 쪼개고, 예외 상황을 정리하고, 산출물을 검수하고, 시차를 넘겨 가며 커뮤니케이션하는 일을 발주사 담당자가 직접 해야 합니다.

사내에 개발팀과 PM이 있는 회사라면 가능합니다. 그러나 개발 조직이 없는 회사가 해외 개발팀을 직접 운영하는 것은 사실상 불가능에 가깝습니다. 요구사항을 정의할 사람이 없는 상태에서 개발이 시작되면, 저렴한 단가로 잘못된 것을 빠르게 만들게 됩니다. 그리고 재작업 비용은 단가가 낮다고 해서 낮아지지 않습니다. 오히려 커뮤니케이션 비용이 붙어서 국내 발주보다 총비용이 커지는 경우도 있습니다. IT 외주개발 비용이 견적보다 항상 더 나오는 구조에서 같은 패턴을 확인하실 수 있습니다.

그래서 실제 의사결정 문제는 “인도냐 베트남이냐”가 아닙니다. “요구사항을 누가 정의하고, 그 결과에 누가 책임지는가”입니다. 세 번째 선택지, 즉 한국인 PM이 한국어로 요구사항을 정의하고 검수까지 책임지면서 글로벌 개발팀이 구현을 맡는 구조가 유일하게 이 질문에 답합니다. 발주사는 국내 채용 대비 평균 40~60%의 비용 절감을 가져가면서도, 커뮤니케이션과 정의 책임은 국내 발주와 동일한 조건으로 유지합니다. 디비컨설팅의 IT 아웃소싱이 제공하는 것이 이 구조입니다.

디비컨설팅이 리뉴얼을 통제하는 5단계

1. 상담 및 요구 분석

비즈니스 목표와 기술 요구사항을 한국어로 문서화합니다. 어느 영역을 고치고 어느 영역을 다시 만들지, 이 단계에서 문장으로 확정합니다. 앞서 이야기한 재작업의 대부분은 여기서 사라집니다. 범위가 문서로 있으면 개발 중에 발견되는 일이 아니라 계약 전에 합의되는 일이 되기 때문입니다.

2. 개발팀 구성

확정된 요구사항에 맞춰 전담팀을 2~4주 내에 구성합니다. 필요한 역할만 넣습니다. 범위가 먼저 정해졌기 때문에 팀을 과하게 잡을 이유도, 부족하게 잡아 중간에 늘릴 이유도 줄어듭니다.

3. 프로젝트 개발

애자일 방식으로 진행하며 진행 상황을 투명하게 공유합니다. 발주사 담당자는 영어로 개발자와 조율하지 않습니다. 한국인 PM하고만 한국어로 이야기하고, 산출물을 확인하고, 다음 스프린트 우선순위를 정합니다. 담당자가 하루를 커뮤니케이션에 쓰지 않는 것이 이 구조의 목적입니다.

4. 테스트 및 배포

QA 프로세스를 거친 뒤 릴리스합니다. 리뉴얼은 기존 사용자와 기존 데이터가 있는 상태에서 전환하는 작업이므로, 기능 검증만이 아니라 전환 자체를 검증합니다.

5. 운영 및 유지보수

문서와 함께 인계합니다. API 명세, DB 스키마, 배포 절차를 남기고 장기 지원을 이어갑니다. 이번 리뉴얼이 비쌌던 이유가 앞선 개발사가 문서를 남기지 않은 것이었다면, 다음 리뉴얼에서 같은 일이 반복되지 않도록 하는 것이 이 단계의 역할입니다.

실제 수행 프로젝트

• GS건설 엘리시안 리조트 — 리조트 웹·앱 통합 구축
• LS일렉트릭 테크스퀘어 — 산업 B2B 거래 플랫폼
• 직방 호갱노노 — 부동산 데이터 서비스
• 가천대학교 — 학사관리 시스템
• 센터필드·센트로폴리스·그랑서울 — 프라임 오피스 빌딩 관리 시스템
• 하나투어 하나오픈챗 — 여행 상담 채팅 서비스

교육, 금융·핀테크, 헬스케어, 제조·물류, 이커머스, 스마트빌딩·IoT 영역에서 실서비스를 운영 중인 기업들과 함께 진행한 프로젝트입니다. 전체 목록은 포트폴리오에서 보실 수 있습니다.

이런 기업에 적합합니다

• 웹사이트나 웹 서비스가 오래되어 리뉴얼이 필요하지만, 사내에 개발팀이나 PM이 없는 기업
• 기존 개발사에서 문서를 넘겨받지 못해 인수인계가 막혀 있는 기업
• 해외 개발 비용을 검토했지만 직접 관리할 인력이 없어 실행하지 못한 기업
• 개발 예산을 줄여야 하지만 커뮤니케이션 품질은 국내 발주 수준으로 유지해야 하는 기업
• 리뉴얼 이후에도 기능 추가와 운영이 계속 이어질 서비스를 가진 기업

반대로, 권하지 않습니다

• 사내에 개발팀과 PM이 이미 있고 요구사항을 직접 정의할 수 있는 기업이라면, 이 구조는 굳이 필요하지 않습니다. 파트너 없이 해외 인력을 직접 운영하시는 편이 낫습니다.
• 2주 안에 끝내야 하는 단순 페이지 수정이나 배너 교체라면 과한 구조입니다. 기존 유지보수 업체에 맡기시는 것이 빠르고 저렴합니다.
• 요구사항을 문서로 정의하는 과정 자체를 생략하고 바로 개발부터 시작하기를 원하신다면, 저희와는 맞지 않습니다. 저희가 비용을 줄이는 방식이 정확히 그 단계에 있기 때문입니다.

자주 묻는 질문

해외 개발자와 직접 소통해야 하나요?

아닙니다. 발주사는 한국인 PM하고만 한국어로 소통합니다. 요구사항 정의, 일정 관리, 산출물 검수는 모두 PM의 책임입니다. 개발팀과의 커뮤니케이션은 PM이 처리하므로, 발주사 담당자가 영어로 회의에 들어가거나 시차를 맞출 일은 없습니다.

비용은 어떻게 산정됩니까?

투입 인력의 등급별 단가와 투입 기간을 기준으로 산정합니다. 기획, 디자인, 개발, QA, 배포, 유지보수를 항목별로 구분해 제시하므로 어느 단계에 얼마가 들어가는지 확인하실 수 있습니다. 범위가 바뀌면 어느 항목이 얼마나 움직이는지도 같은 기준으로 설명드립니다.

기획서가 없는데 견적을 받을 수 있나요?

가능합니다. 해결하려는 문제, 주요 사용자, 반드시 필요한 기능 3~5개, 그리고 일정과 예산 범위만 정리되어 있으면 개략 견적을 드릴 수 있습니다. 상세 기획은 1단계인 상담 및 요구 분석에서 함께 문서로 만듭니다.

프로젝트 중간에 팀 규모를 조정할 수 있나요?

가능합니다. 전담팀, 장기 협업, 인력 단위, 프로젝트 단위 중에서 선택하실 수 있고, 진행 중에도 범위와 일정에 맞춰 인원을 조정합니다. 리뉴얼은 초기 단계에 설계·기획 비중이 크고 후반에 개발·QA 비중이 커지므로, 실제로 조정이 필요한 경우가 많습니다.

소스코드 소유권은 누구에게 있습니까?

발주사에 귀속됩니다. 코드뿐 아니라 API 명세, DB 스키마, 배포 절차 문서까지 함께 인계합니다. 이번 리뉴얼의 비용이 올라간 원인이 앞선 개발사가 아무 문서도 남기지 않은 것이었다면, 그 상황을 다시 만들지 않는 것이 저희 계약의 기본 조건입니다. 다음 개발사가 누가 되든, 시스템을 읽는 데 다시 몇 주를 쓰지 않아도 되도록 넘겨드립니다.

정리

웹사이트 리뉴얼에서 예산을 결정하는 것은 개발 단가가 아니라 요구사항 정의입니다. 고칠 것과 다시 만들 것을 발주 전에 문서로 가르면 견적은 움직이지 않고, 가르지 못하면 어떤 단가로 발주해도 비용은 올라갑니다. 그리고 사내에 개발팀이 없는 회사가 이 정의를 혼자 해내기는 어렵습니다. 한국인 PM이 한국어로 범위를 확정하고 검수까지 책임지며, 검증된 글로벌 개발팀이 구현을 맡는 구조가 필요한 이유입니다. 지금 사이트의 어느 부분을 고치고 어느 부분을 다시 만들어야 할지 판단이 서지 않으신다면, 그 판단부터 함께 정리해 드립니다.