웹사이트 리뉴얼 개발, 기존 시스템을 살릴지 다시 만들지 판단하는 기준

“디자인이 오래돼 보여서 홈페이지를 바꾸고 싶습니다.”

웹사이트 리뉴얼 상담은 보통 이런 요청에서 시작합니다. 첫 화면을 최신 분위기로 바꾸고, 모바일에서도 보기 편하게 만들면 충분할 것처럼 보입니다.

그런데 기존 사이트를 살펴보면 디자인 외의 문제가 함께 발견되는 경우가 많습니다.

담당자가 게시물을 등록하기 어렵습니다.
모바일 화면에서 표와 버튼이 깨집니다.
페이지를 하나 수정하면 다른 화면에 오류가 생깁니다.
회원, 신청, 문의 데이터가 여러 곳에 나뉘어 있습니다.
관리자 계정과 권한이 제대로 구분되지 않습니다.
외부 개발사나 퇴사한 담당자만 구조를 알고 있습니다.
서버와 도메인 계정의 소유 관계가 명확하지 않습니다.
오래된 플러그인이나 라이브러리 때문에 기능 추가가 어렵습니다.
문의 알림이 누락돼 담당자가 관리자 화면을 계속 확인해야 합니다.

이 상태에서 화면만 새롭게 바꾸면 사용자가 보는 모습은 달라지지만 운영 문제는 그대로 남을 수 있습니다.

반대로 기존 시스템의 일부를 활용할 수 있는데도 처음부터 전부 다시 만들면 불필요한 개발 범위가 커질 수 있습니다. 기존 데이터와 운영 기능을 옮기는 과정에서 예상하지 못한 위험도 생깁니다.

웹사이트 리뉴얼 개발을 검토할 때 가장 먼저 결정해야 할 것은 디자인 콘셉트가 아닙니다.

현재 시스템에서 유지할 부분, 개선할 부분, 교체할 부분을 구분하는 것이 먼저입니다.

리뉴얼이라는 말에 서로 다른 프로젝트가 섞여 있습니다

기업 담당자가 말하는 ‘리뉴얼’은 실제로는 여러 종류의 개발을 포함할 수 있습니다.

단순히 디자인만 바꾸는 프로젝트도 있고, 사용자 화면은 유지하면서 관리자 시스템을 새로 만드는 경우도 있습니다. 기존 데이터를 이전해 완전히 새로운 서비스로 재구축하는 프로젝트도 모두 리뉴얼이라고 부릅니다.

개발 범위를 정확하게 판단하려면 먼저 어떤 유형에 가까운지 구분해야 합니다.

| 리뉴얼 유형 | 주요 작업 | 적합한 상황 | |---|---|---| | 디자인 중심 개선 | 레이아웃, 색상, 이미지, 반응형 화면 수정 | 기능과 운영 구조는 괜찮지만 화면이 오래된 경우 | | 프론트엔드 재개발 | 사용자 화면과 화면 동작 재구성 | 백엔드와 데이터는 활용할 수 있지만 사용자 경험 개선이 필요한 경우 | | 관리자 시스템 개선 | 콘텐츠, 회원, 문의, 통계, 권한 관리 재구성 | 고객 화면보다 내부 운영 불편이 큰 경우 | | 일부 기능 교체 | 신청, 결제, 검색, 로그인 등 특정 영역 재개발 | 문제가 특정 기능에 집중돼 있고 기존 구조와 분리할 수 있는 경우 | | 전체 재구축 | 사용자 화면, 서버, DB, 관리자 시스템 재개발 | 기존 기술과 데이터 구조가 확장을 막고 있거나 유지 위험이 큰 경우 | | 단계적 리뉴얼 | 기존 시스템을 운영하면서 기능별로 순차 교체 | 서비스를 중단하기 어렵고 기능이 복잡한 경우 |

이 구분 없이 “홈페이지 리뉴얼 견적을 받고 싶다”고 요청하면 개발사마다 서로 다른 범위를 전제로 견적을 낼 수 있습니다.

한 업체는 디자인 수정만 포함하고, 다른 업체는 관리자와 데이터 이전까지 포함할 수 있습니다. 견적 금액 차이가 크더라도 단순히 어느 업체가 비싼지 비교하기 어려운 이유입니다.

따라서 견적을 비교할 때는 총금액보다 먼저 다음 항목의 포함 여부를 확인해야 합니다.

기존 소스코드 분석
디자인 개편 범위
모바일 반응형 대응
관리자 페이지 개발
기존 데이터 이전
회원 비밀번호 이전
외부 API 재연동
검색 노출 관련 주소 유지
서버 및 배포 환경 구성
테스트와 오류 수정
오픈 당일 전환 작업
기존 시스템 복구 계획
오픈 이후 안정화 지원

디자인이 오래됐다는 이유만으로 전체 재구축할 필요는 없습니다

기존 웹사이트의 핵심 기능이 안정적으로 작동하고, 데이터 구조와 관리자 기능도 현재 업무에 잘 맞는다면 디자인 중심 리뉴얼이 적합할 수 있습니다.

예를 들어 기업 소개, 사업 분야, 포트폴리오, 문의 접수 정도로 구성된 웹사이트라면 기존 관리 기능을 유지하면서 사용자 화면만 개선하는 방법을 검토할 수 있습니다.

이 경우에도 단순히 화면 색상과 이미지만 교체하는 것은 충분하지 않을 수 있습니다.

다음 요소를 함께 확인해야 합니다.

1. 모바일 사용 흐름

PC 화면을 축소한 것처럼 보이는 사이트는 모바일에서 메뉴와 버튼을 사용하기 어렵습니다.

반응형 화면을 적용했더라도 다음과 같은 문제가 남아 있을 수 있습니다.

버튼 사이 간격이 좁아 잘못 누르기 쉬움
표와 이미지가 화면 밖으로 넘어감
상담 신청 입력 항목이 지나치게 많음
팝업이 화면을 가림
중요한 CTA가 페이지 아래에만 있음
전화번호와 주소를 다시 복사해야 함
모바일 메뉴 단계가 너무 깊음

모바일 리뉴얼은 화면 폭을 줄이는 작업이 아니라 사용자가 실제로 정보를 찾고 문의하는 순서를 다시 정리하는 작업에 가깝습니다.

2. 콘텐츠 수정 가능 여부

메인 배너, 서비스 소개, 자주 묻는 질문, 포트폴리오를 바꿀 때마다 개발사에 요청해야 한다면 운영 비용과 대기 시간이 계속 발생합니다.

리뉴얼 전에는 어떤 콘텐츠를 내부 담당자가 직접 수정해야 하는지 구분하는 것이 좋습니다.

모든 문장을 관리할 수 있도록 만들면 관리자 화면이 오히려 복잡해질 수 있습니다. 반대로 수정이 자주 필요한 영역까지 코드에 고정하면 작은 변경에도 개발 작업이 필요합니다.

다음처럼 변경 빈도를 기준으로 나눌 수 있습니다.

자주 변경: 공지, 팝업, 배너, 포트폴리오, FAQ
가끔 변경: 서비스 소개, 담당자 정보, 회사 연혁
거의 변경하지 않음: 페이지 기본 구조, 공통 레이아웃, 시스템 안내 문구

자주 변경되는 항목은 관리자에서 운영하고, 구조와 관련된 항목은 개발 영역으로 남겨두는 방식이 관리하기 편합니다.

3. 기존 검색 주소와 콘텐츠

기존 웹사이트가 오랫동안 운영됐다면 외부 사이트, 검색 결과, 고객이 보관한 문서에 페이지 주소가 남아 있을 수 있습니다.

리뉴얼 과정에서 URL 구조를 모두 바꾸면 기존 링크를 통해 방문한 사용자가 없는 페이지를 보게 될 수 있습니다.

따라서 기존 페이지별로 다음 중 하나를 결정해야 합니다.

같은 주소를 유지한다.
새 주소로 연결한다.
새 사이트의 관련 페이지로 이동시킨다.
더 이상 제공하지 않는 콘텐츠임을 안내한다.
검색 노출 대상에서 제외한다.

사이트 메뉴에서 보이지 않는다고 해서 사용되지 않는 페이지라고 단정하면 안 됩니다. 접속 기록이나 외부 연결 여부를 함께 확인해야 합니다.

이런 상황이라면 전체 재구축을 검토할 수 있습니다

기존 시스템을 계속 수정하는 것이 항상 경제적인 것은 아닙니다.

한 기능을 추가할 때마다 여러 화면에서 오류가 발생하고, 개발자가 구조를 파악하는 데 대부분의 시간을 사용한다면 유지보수의 효율이 낮아질 수 있습니다.

다음 항목이 여러 개 겹친다면 전체 재구축이나 핵심 영역 교체를 검토할 필요가 있습니다.

기존 소스코드를 확보하기 어렵습니다

웹사이트가 정상적으로 열려도 소스코드와 데이터베이스를 확보할 수 없는 경우가 있습니다.

서버에 접속할 수 있지만 최신 소스가 어디에 있는지 알 수 없거나, 외부 솔루션에 종속돼 수정 권한이 제한되기도 합니다.

이때는 먼저 다음 자료를 확인해야 합니다.

프론트엔드 및 백엔드 소스코드
데이터베이스 접속 정보
서버 접속 계정
도메인 관리 계정
파일 저장소
배포 방법과 운영 문서
외부 API 및 결제 계정
이메일과 문자 발송 계정
분석 도구와 검색 관리 계정
디자인 원본 파일

자료가 부족하면 기존 시스템을 이어서 수정하는 것보다 데이터만 정리해 새로 구축하는 편이 현실적인지 판단해야 합니다.

사용 중인 기술의 유지가 어렵습니다

오래된 기술을 사용한다는 이유만으로 반드시 교체해야 하는 것은 아닙니다.

현재 안정적으로 운영되고 있고 보안 업데이트, 서버 운영, 기능 수정이 가능한 상황이라면 무조건 최신 기술로 변경할 필요는 없습니다.

문제는 특정 버전에 강하게 의존해 서버를 업데이트하기 어렵거나, 필요한 개발 인력을 구하기 힘들고, 작은 기능 변경에도 전체 시스템을 다시 테스트해야 하는 경우입니다.

이때는 기술의 출시 연도보다 다음 질문이 더 중요합니다.

현재 운영 환경에서 보안 업데이트를 적용할 수 있는가?
장애가 발생했을 때 원인을 추적할 로그가 있는가?
개발 환경을 새로 구성할 수 있는가?
소스코드를 수정한 뒤 안전하게 배포할 수 있는가?
테스트 서버와 운영 서버가 분리돼 있는가?
담당자가 변경돼도 유지할 수 있는 문서가 있는가?
신규 기능을 기존 기능과 분리해 개발할 수 있는가?

데이터 구조가 현재 업무와 맞지 않습니다

사업 초기에는 회원과 문의만 관리했지만 이후 예약, 결제, 구독, 파트너, 상품, 정산 기능이 추가될 수 있습니다.

이 기능들이 하나의 운영 흐름으로 설계되지 않고 필요할 때마다 별도의 표와 필드로 추가됐다면 데이터가 서로 맞지 않을 수 있습니다.

예를 들어 고객 정보가 회원 테이블, 신청 내역, 결제 내역에 각각 다른 형태로 저장돼 있을 수 있습니다. 같은 고객인데 이메일이나 전화번호 표기가 달라 중복 회원처럼 보일 수도 있습니다.

이런 상태에서는 화면을 새롭게 만들어도 다음 문제가 계속됩니다.

고객별 이용 내역을 한 번에 보기 어려움
취소했지만 결제 상태는 완료로 남음
통계 숫자와 실제 거래 건수가 다름
담당자마다 다른 엑셀 자료를 사용함
개인정보 삭제 요청을 한 번에 처리하기 어려움
새로운 기능을 추가할 때 같은 데이터를 다시 저장함

리뉴얼 전에는 기존 데이터가 얼마나 있는지만 확인할 것이 아니라, 어떤 기준으로 연결돼 있는지 살펴봐야 합니다.

사용자와 관리자 기능이 지나치게 얽혀 있습니다

관리자 페이지의 수정이 사용자 화면 오류로 이어지거나, 사용자 기능을 변경하려면 관리자 전체를 함께 수정해야 하는 구조라면 확장이 어려울 수 있습니다.

특히 관리자 화면이 단순한 데이터 조회 도구가 아니라 실제 업무 처리 시스템이라면 독립적인 운영 흐름을 설계해야 합니다.

예를 들어 상담 신청 관리에는 단순히 신청 목록을 보여주는 것 외에도 다음 기능이 필요할 수 있습니다.

담당자 배정
처리 상태 변경
내부 메모
고객 연락 기록
파일 첨부
미처리 건 필터
담당자별 권한
개인정보 열람 기록
처리 결과 다운로드

기존 관리자에 이런 기능을 추가하기 어렵다면 사용자 화면만 리뉴얼하기보다 운영 시스템을 함께 재설계하는 편이 적합할 수 있습니다.

전면 재구축보다 단계적 리뉴얼이 나은 경우도 있습니다

운영 중인 서비스를 특정 날짜에 한 번에 새 시스템으로 바꾸는 방식은 명확해 보이지만, 기능과 연동이 많을수록 전환 위험이 커집니다.

기존 기능을 모두 새로 만든 뒤 한 번에 교체하려 하면 개발 기간 동안 발생한 신규 요구사항을 반영하기 어렵고, 오픈 시점에 여러 오류가 동시에 발견될 수 있습니다.

이를 줄이기 위해 기존 시스템을 유지하면서 기능을 하나씩 새 시스템으로 옮기는 방법을 사용할 수 있습니다.

예를 들면 다음 순서입니다.

기존 사이트의 사용자 화면을 유지합니다.
신규 문의 관리 기능을 별도 시스템으로 개발합니다.
문의 데이터만 새 관리자에서 처리합니다.
이후 회원, 콘텐츠, 신청 기능을 순서대로 교체합니다.
모든 의존 관계가 정리된 뒤 기존 시스템을 종료합니다.

이와 같이 기존 기능을 한 번에 없애지 않고 신규 기능으로 점진적으로 교체하는 접근은 대규모 시스템 전환의 업무 중단 위험을 줄이는 방법으로 활용됩니다. AWS와 Microsoft의 애플리케이션 현대화 지침에서도 기존 시스템을 운영하면서 기능별로 점진적으로 전환하는 패턴을 안내하고 있습니다. (docs.aws.amazon.com)

다만 단계적 리뉴얼이 항상 더 간단한 것은 아닙니다.

전환 기간에는 기존 시스템과 신규 시스템이 동시에 작동하기 때문에 다음 기준이 필요합니다.

어느 시스템이 원본 데이터를 관리하는가?
기존 시스템에서 수정한 데이터가 신규 시스템에도 반영되는가?
회원은 한 번만 로그인해도 되는가?
동일한 요청이 두 시스템에서 중복 처리되지 않는가?
오류가 발생하면 어느 시스템의 기록을 기준으로 판단하는가?
기존 기능과 신규 기능 사이의 데이터 형식이 다른 경우 누가 변환하는가?
단계별 전환이 완료됐는지 어떤 조건으로 판단하는가?

기존 소스에 접근할 수 없거나 요청을 중간에서 분리하기 어려운 구조라면 점진적 전환이 제한될 수 있습니다. 따라서 단계적 리뉴얼 여부도 현재 코드와 인프라를 확인한 뒤 결정해야 합니다. (docs.aws.amazon.com)

리뉴얼 견적 전에 확인해야 할 핵심 자료

기존 시스템이 있는 프로젝트는 요구사항 문서만으로 정확한 범위를 판단하기 어렵습니다.

새로 만들 기능뿐 아니라 기존 기능, 데이터, 서버, 외부 연동을 함께 확인해야 하기 때문입니다.

가능하다면 개발사 검토 전에 다음 자료를 준비하는 것이 좋습니다.

1. 현재 사이트의 전체 메뉴 목록

사용자에게 보이는 메뉴뿐 아니라 관리자 메뉴도 포함합니다.

페이지 이름 옆에 다음 내용을 표시하면 범위를 구분하기 쉽습니다.

유지
수정
삭제
신규 개발
판단 필요

사용하지 않는 메뉴처럼 보여도 특정 담당자가 월말 업무에 사용하고 있을 수 있으므로 실제 사용자 확인이 필요합니다.

2. 사용자 유형과 권한

회원이라는 하나의 유형만 있는지 확인해야 합니다.

기업용 서비스라면 일반 사용자 외에도 다음 역할이 있을 수 있습니다.

기업 관리자
기업 소속 직원
파트너
판매자
운영 담당자
콘텐츠 담당자
정산 담당자
최고 관리자

리뉴얼 과정에서 역할을 단순히 복사하지 말고 각 역할이 조회하고 수정할 수 있는 데이터 범위를 정리해야 합니다.

3. 관리자 업무 흐름

관리자가 어떤 화면을 사용하는지만 정리하면 실제 개발 범위가 빠질 수 있습니다.

하나의 업무를 시작해서 완료할 때까지의 순서를 적는 편이 좋습니다.

예를 들어 문의 처리 업무라면 다음과 같이 작성할 수 있습니다.

신규 문의 접수 → 담당자 알림 → 관리자 확인 → 담당자 배정 → 고객 연락 → 상담 결과 기록 → 처리 완료 → 월간 현황 다운로드

이 흐름을 확인하면 필요한 상태값, 알림, 권한, 검색 조건, 이력 관리 범위를 파악할 수 있습니다.

4. 외부 서비스 연동 목록

화면에는 보이지 않지만 운영에 필요한 외부 연동이 있을 수 있습니다.

소셜 로그인
결제 서비스
문자 및 알림톡
이메일 발송
지도와 주소 검색
본인인증
ERP 또는 CRM
배송 및 물류
회계 시스템
데이터 분석 도구
외부 상품 정보
AI API
파일 저장소

기존 계정을 계속 사용할 수 있는지, 계약 주체가 누구인지, 신규 도메인에서도 이용할 수 있는지 확인해야 합니다.

5. 서버와 도메인 소유 정보

리뉴얼을 앞두고 의외로 자주 지연되는 부분입니다.

도메인, 서버, 인증서, 이메일 계정이 누구의 명의로 관리되는지 확인해야 합니다. 기존 제작사 계정에 포함돼 있다면 이전 가능 여부도 확인할 필요가 있습니다.

운영에 필요한 주요 자산은 가능하면 발주 기업이 직접 소유하고, 개발사에는 필요한 권한만 제공하는 방식이 관리에 유리합니다.

데이터 이전은 복사 작업이 아니라 정리 작업입니다

리뉴얼 프로젝트에서 기존 DB를 새 DB로 옮기면 데이터 이전이 끝난다고 생각하기 쉽습니다.

하지만 실제로는 기존 데이터의 품질과 구조를 먼저 확인해야 합니다.

예를 들어 회원 정보를 이전할 때도 다음 문제가 발생할 수 있습니다.

같은 이메일로 여러 계정이 존재함
탈퇴 회원이 삭제되지 않고 남아 있음
휴대전화 번호 형식이 제각각임
필수값이 비어 있음
회원 등급의 의미가 현재와 다름
사용하지 않는 상태값이 남아 있음
개인정보 보관 기준이 정리되지 않음
비밀번호 암호화 방식이 달라 그대로 이전하기 어려움

게시물이나 상품 데이터에도 비슷한 문제가 있습니다.

본문 안의 이미지가 기존 서버 주소를 사용하고 있다면 DB만 옮겨서는 이미지가 표시되지 않습니다. 파일을 함께 이전하고 본문 주소를 변경해야 할 수 있습니다.

데이터 이전은 보통 다음 순서로 준비하는 것이 안전합니다.

이전 대상 테이블과 파일을 확인합니다.
삭제하거나 제외할 데이터를 구분합니다.
기존 필드와 신규 필드의 연결표를 작성합니다.
중복과 누락 데이터를 처리할 기준을 정합니다.
일부 데이터를 시험 이전합니다.
관리자와 담당자가 결과를 검수합니다.
전체 이전 시간을 측정합니다.
최종 이전 시점과 서비스 중단 범위를 정합니다.
이전 후 건수와 주요 데이터를 다시 비교합니다.

데이터가 많지 않더라도 시험 이전은 필요합니다. 데이터의 양보다 형식과 예외가 더 큰 영향을 줄 수 있기 때문입니다.

회원 비밀번호는 이전 가능 여부를 별도로 확인해야 합니다

회원 서비스 리뉴얼에서는 기존 계정을 그대로 사용할 수 있는지가 중요한 문제입니다.

비밀번호는 일반적인 문장처럼 복원해서 옮기는 데이터가 아닙니다. 기존 시스템의 저장 방식과 신규 시스템의 인증 구조에 따라 그대로 사용할 수 있는지 판단해야 합니다.

이전이 어렵다면 다음과 같은 대안을 검토할 수 있습니다.

첫 로그인 시 비밀번호 재설정 요청
이메일 또는 휴대전화 인증 후 새 비밀번호 등록
기존 인증 시스템을 일정 기간 함께 운영
기업 회원의 경우 관리자가 계정을 재승인
소셜 로그인 계정의 연결 정보 재확인

이 기준을 오픈 직전에 결정하면 고객 안내, 화면 개발, 메시지 발송 범위가 추가될 수 있습니다.

회원이 많은 서비스라면 리뉴얼 기획 단계에서 인증 전환 방식을 먼저 확인하는 편이 좋습니다.

새 사이트가 완성됐다고 바로 기존 사이트를 종료하면 안 됩니다

개발 서버에서 정상적으로 작동해도 실제 운영 환경에서는 다른 문제가 발생할 수 있습니다.

도메인, 보안 인증서, 외부 API 허용 주소, 이메일 발송 설정, 파일 권한, 실제 데이터 크기 등이 개발 환경과 다르기 때문입니다.

오픈 전에는 최소한 다음 항목을 확인해야 합니다.

사용자 기능

회원가입과 로그인
비밀번호 찾기
주요 메뉴 이동
검색과 필터
신청 및 문의 등록
파일 업로드
모바일 화면
이메일, 문자, 푸시 알림
결제와 취소
오류 발생 시 안내 문구

관리자 기능

운영자 로그인
역할별 접근 권한
콘텐츠 등록과 수정
회원 및 문의 조회
상태 변경
파일 다운로드
통계와 엑셀 데이터
수정 이력
개인정보 접근 범위

운영 환경

도메인 연결
보안 인증서
서버와 데이터베이스 접속
데이터 백업
오류 로그
트래픽 모니터링
외부 API 운영 키
발송 계정
검색 도구 및 분석 도구
장애 발생 시 연락 체계

리뉴얼 오픈 계획에는 복구 기준이 포함돼야 합니다

새로운 시스템에 문제가 발생했을 때 어떤 조건에서 기존 시스템으로 돌아갈지 정해야 합니다.

“문제가 생기면 원복한다”는 문장만으로는 실제 판단이 어렵습니다.

예를 들어 다음과 같이 구체적인 기준이 필요합니다.

로그인이 일정 시간 이상 불가능한 경우
결제 승인과 주문 저장이 일치하지 않는 경우
관리자에서 신규 신청을 확인할 수 없는 경우
주요 데이터 이전 건수가 맞지 않는 경우
외부 API 오류로 핵심 업무를 처리할 수 없는 경우

원복할 때도 오픈 이후 새 시스템에 입력된 데이터를 어떻게 처리할지 결정해야 합니다.

신규 문의가 새 시스템에만 저장된 상태에서 기존 시스템으로 돌아가면 해당 데이터를 별도로 옮겨야 할 수 있습니다. 주문이나 결제가 포함됐다면 더욱 신중해야 합니다.

따라서 전환 계획에는 다음 내용이 포함되는 것이 좋습니다.

기존 시스템의 최종 백업 시점
신규 데이터 입력을 멈추는 시점
데이터 이전 예상 시간
검수 담당자
정상 오픈 판단 기준
원복 결정권자
원복 가능 시간
오픈 이후 신규 데이터 처리 방법
고객 및 내부 담당자 안내 방법

리뉴얼 범위를 줄이면 안 되는 부분과 줄일 수 있는 부분

예산이나 일정이 제한된 경우 모든 기능을 한 번에 구현하기 어렵습니다.

이때 사용자에게 잘 보이지 않는 작업을 먼저 제외하기 쉽지만, 운영 안정성과 직접 관련된 영역은 신중하게 판단해야 합니다.

우선 유지해야 할 가능성이 높은 범위

데이터 백업과 이전 검증
로그인과 권한
개인정보 접근 제한
핵심 업무 상태값
결제 및 외부 연동 오류 처리
관리자 검색과 처리 기능
오류 로그
오픈 및 복구 계획
모바일 핵심 사용 흐름

1차 범위에서 조정할 수 있는 항목

사용 빈도가 낮은 통계 화면
디자인 장식과 복잡한 애니메이션
관리자 대시보드의 일부 시각화
빈도가 낮은 자동화 기능
기존 자료의 일괄 편집 편의 기능
핵심 업무와 무관한 추가 회원 기능
운영자가 수동으로 보완할 수 있는 저빈도 기능

기능을 제외할 때는 단순히 “나중에 개발”이라고 적기보다 1차 운영에서 어떻게 대신 처리할지도 정해야 합니다.

예를 들어 자동 보고서 기능을 2차로 미룬다면 1차에서는 어떤 데이터를 내려받아 누가 보고서를 만드는지 합의해야 합니다.

개발사에 전달하면 좋은 리뉴얼 요청서

긴 기획서를 처음부터 작성하지 않아도 됩니다.

다음 항목을 정리하면 개발사가 현재 상황과 우선순위를 파악하는 데 도움이 됩니다.

기본 정보

현재 웹사이트 주소
리뉴얼을 검토하는 이유
주요 사용자
내부 운영 담당자
희망하는 오픈 시점이 있다면 그 이유

현재 문제

사용자가 불편해하는 부분
관리자가 반복해서 처리하는 업무
오류가 자주 발생하는 기능
신규 기능을 추가하기 어려운 이유
현재 외주사 또는 내부 개발자와의 유지보수 상황

유지할 항목

반드시 유지해야 하는 기능
이전해야 하는 회원과 콘텐츠
계속 사용해야 하는 외부 서비스
변경하면 안 되는 업무 규칙
유지해야 하는 페이지 주소

개선할 항목

새로 필요한 기능
관리자에서 직접 수정하고 싶은 항목
자동화하고 싶은 업무
모바일에서 개선할 흐름
추가하려는 사용자 유형과 권한

보유 자료

소스코드
DB 백업
서버 계정
도메인 계정
외부 서비스 계정
화면 설계서
디자인 원본
기존 유지보수 문서

자료가 모두 준비되지 않았더라도 현재 보유 여부를 표시하면 됩니다. 확인할 수 없는 항목이 무엇인지 아는 것 자체가 리뉴얼 범위를 판단하는 데 도움이 됩니다.

웹사이트 리뉴얼 개발사와 상담할 때 물어볼 질문

리뉴얼 경험을 확인할 때 디자인 시안만 보는 것으로는 부족합니다.

기존 시스템과 데이터를 어떻게 다루는지 확인해야 합니다.

다음 질문을 활용할 수 있습니다.

기존 시스템을 어떤 절차로 분석하나요?
유지, 개선, 교체 범위를 어떤 기준으로 구분하나요?
기존 DB와 파일은 어떻게 이전하나요?
시험 이전과 최종 검수 과정이 있나요?
회원 비밀번호 이전 가능 여부는 언제 확인하나요?
기존 페이지 주소가 바뀌면 어떻게 처리하나요?
운영 중단 시간을 줄일 방법이 있나요?
오픈 실패 시 복구 계획은 어떻게 세우나요?
사용자와 관리자의 권한은 어떤 방식으로 설계하나요?
외부 API 계정과 운영 키는 누가 관리하나요?
개발 완료 후 소스코드와 운영 계정은 어떻게 전달하나요?
오픈 이후 오류 수정과 유지보수 범위는 어떻게 구분하나요?

답변이 구체적일수록 실제 개발 범위도 명확해집니다.

원소프트가 리뉴얼 범위를 검토하는 관점

원소프트는 웹사이트 리뉴얼을 단순한 화면 교체로만 보지 않습니다.

현재 사이트를 사용하는 고객의 흐름뿐 아니라 관리자 운영 방식, 데이터 구조, 외부 연동, 향후 기능 확장 가능성을 함께 검토합니다.

기존 시스템을 활용할 수 있다면 무조건 전체 재개발을 권하기보다 유지 가능한 부분과 교체할 부분을 구분해야 합니다. 반대로 기존 구조가 운영과 확장을 계속 방해한다면 화면 수정만 반복하기보다 재구축이나 단계적 전환이 적합할 수 있습니다.

프로젝트 상황에 따라 Next.js, React, TypeScript, Vue.js 등의 웹 프론트엔드 기술과 NestJS, Node.js, Java/Spring 등의 백엔드 기술을 조합할 수 있습니다. 기존 시스템이 jQuery 기반이라면 현재 구조를 분석해 유지보수할 영역과 신규 개발 영역을 구분하는 방법도 검토할 수 있습니다.

중요한 것은 특정 기술을 먼저 정하는 것이 아니라 다음 질문에 답하는 것입니다.

리뉴얼 이후 사용자가 더 쉽게 목적을 달성할 수 있는가?
관리자의 반복 업무가 줄어드는가?
데이터가 일관된 기준으로 관리되는가?
장애와 오류를 확인할 수 있는가?
새로운 기능을 추가할 때 기존 기능 전체를 다시 수정하지 않아도 되는가?
내부 담당자가 필요한 콘텐츠를 직접 관리할 수 있는가?
개발사가 바뀌어도 시스템을 이어서 운영할 수 있는가?

이 질문에 대한 답을 기준으로 디자인 개선, 일부 기능 교체, 관리자 시스템 개편, 전체 재구축 중 적절한 범위를 결정해야 합니다.

리뉴얼을 검토하고 있다면 먼저 현재 구조부터 정리해보세요

웹사이트가 오래됐다고 해서 모두 새로 만들 필요는 없습니다.

반대로 화면이 정상적으로 보인다는 이유만으로 기존 시스템을 계속 유지하는 것이 적절한 것도 아닙니다.

리뉴얼 범위를 결정하려면 디자인보다 먼저 다음 네 가지를 확인하는 것이 좋습니다.

현재 사용자가 실제로 이용하는 기능
관리자가 업무를 처리하는 과정
반드시 이전해야 하는 데이터
기존 시스템이 향후 기능 추가를 감당할 수 있는지

이 내용을 정리하면 불필요한 재개발을 줄이고, 반드시 개선해야 할 영역에는 충분한 범위를 배정할 수 있습니다.

원소프트는 경기도 화성시 동탄순환대로 823, 영천동 에이팩시티에 위치한 웹·앱 개발사입니다. 기존 웹사이트의 소스코드, 관리자 기능, 데이터와 운영 흐름을 바탕으로 디자인 개선이 적합한지, 일부 기능 교체나 전체 재구축이 필요한지 함께 검토할 수 있습니다.

현재 사이트의 주소와 불편한 업무, 유지해야 할 기능을 정리해 전달해주시면 리뉴얼 범위를 구체화하는 데 도움이 됩니다.

제목 후보

웹사이트 리뉴얼 개발, 기존 시스템을 살릴지 다시 만들지 판단하는 기준
홈페이지 리뉴얼 견적 전 확인해야 할 데이터·관리자·서버 체크리스트
웹사이트 리뉴얼, 디자인 수정과 전체 재구축은 어떻게 구분할까요?
기존 홈페이지를 새로 만들어야 할까? 단계적 리뉴얼 판단 기준
기업 웹사이트 리뉴얼 개발에서 놓치기 쉬운 데이터 이전과 오픈 계획

메인 키워드

웹사이트 리뉴얼 개발

서브 키워드

홈페이지 리뉴얼
웹사이트 재구축
레거시 시스템 리뉴얼
데이터 마이그레이션
관리자 페이지 개발

썸네일 문구

기존 사이트, 살릴까 다시 만들까?
웹사이트 리뉴얼 판단 기준
디자인보다 먼저 확인할 것

글 요약

웹사이트 리뉴얼은 디자인을 바꾸는 작업부터 시작하기보다 기존 기능, 관리자 업무, 데이터 구조와 외부 연동을 먼저 분석해야 합니다. 디자인 개선, 일부 기능 교체, 단계적 전환, 전체 재구축을 구분하는 기준과 데이터 이전 및 오픈 전 체크리스트를 정리했습니다.

CTA 후보

현재 사이트의 주소와 운영 중 불편한 업무를 전달해주시면 유지할 영역과 교체할 영역을 구분하는 데 필요한 항목부터 함께 정리해드릴 수 있습니다.
전체 재구축이 필요한지 판단하기 어렵다면 기존 기능, 관리자 화면, 데이터 이전 범위를 기준으로 리뉴얼 방향을 검토해보세요. 원소프트가 요구사항 정리를 도와드릴 수 있습니다.

다음에 작성하면 좋은 연관 글

관리자 페이지 리뉴얼, 화면보다 업무 상태와 권한을 먼저 정해야 하는 이유
데이터 마이그레이션 개발, 회원·게시물·파일 이전 전에 확인할 체크리스트
개발 유지보수 업체 변경 전 소스코드와 서버 계정을 확인하는 방법