웹사이트 개발
반응형 웹부터 웹앱까지 만드는 방법
상담은 보통 "회사 소개 페이지를 새로 하고 싶다"에서 시작합니다. 그러다 로그인, 결제, 관리자 화면, 외부 시스템 연동까지 필요해지는 경우가 많습니다. 이 페이지는 여우비 디지털이 웹 프로젝트의 범위를 어떤 기준으로 나누고, 어떤 기술과 연동을 다루는지 설명합니다.
웹사이트와 웹앱을 나누는 기준
정적 페이지 몇 장으로 끝나는 사이트와, 사용자가 데이터를 만들고 바꾸는 웹앱은 설계 난이도가 다릅니다. 이 구분을 처음에 명확히 해두면 일정 산정이 훨씬 정확해집니다.
아래 두 줄은 실제 상담에서 가장 먼저 확인하는 질문입니다. 어느 쪽에 가까운지에 따라 필요한 기술과 일정이 달라집니다.
정보를 보기만 하는 사이트
정적 페이지 중심
빠르고 유지비가 적습니다
계정을 만들고 저장·결제·신청하는 웹앱
데이터와 권한 관리
백업 정책까지 함께 설계
두 성격이 섞인 경우
1차·2차로 분리 진행
먼저 공개하고 확장합니다
후자에 가깝다면 데이터베이스, 권한 관리, 예외 처리, 백업 정책이 함께 필요해집니다. 반대로 정보 제공이 목적이라면 정적 페이지 구조가 더 빠르고 유지비도 적습니다.
모바일 화면 우선, 데스크톱으로 확장
반응형 웹은 기본값입니다
한국에서는 모바일 유입 비중이 높아 데스크톱 화면만 맞춰 만드는 경우가 거의 없습니다. 저희는 모바일 화면을 먼저 잡고 데스크톱으로 확장하는 순서로 작업하는 편이 오류가 적다고 봅니다. 해상도별로 확인해야 할 지점이 다르기 때문입니다.
기존 사이트를 개편하는 경우에는 새로 만드는 것보다 먼저 확인할 것이 있습니다. 현재 트래픽이 어디서 들어오는지, 어떤 화면에서 이탈이 많은지를 먼저 봅니다. 그 데이터에 따라 손댈 화면과 그대로 둘 화면이 갈립니다.
- 좁은 화면에서 먼저 레이아웃이 깨지지 않는지 확인합니다
- 터치 조작 기준으로 버튼 크기와 간격을 잡습니다
- 이미지와 폰트 로딩이 느린 회선에서도 견디는지 봅니다
자주 쓰는 기술 스택
프런트엔드는 React 계열, 백엔드는 Node.js 또는 Spring 계열이 국내 프로젝트에서 많이 선택됩니다. 다만 스택은 유행보다 유지보수 주체가 누구인지가 결정에 가장 큰 영향을 줍니다.
프런트엔드
React 계열이 국내 프로젝트에서 가장 많이 선택됩니다. 화면 전환이 많은 관리자 도구나 대시보드형 화면에서 특히 유리합니다. 이미 다른 팀이 Vue 기반으로 운영 중이라면 굳이 바꾸지 않는 편이 낫습니다.
백엔드
Node.js는 프런트엔드와 언어를 맞출 수 있어 소규모 팀에 적합하고, Spring 계열은 기존 사내 시스템이 Java 기반일 때 운영에 유리합니다. 새 스택을 도입하는 비용보다 기존 인력이 익숙한 쪽을 고르는 편이 낫습니다.
CMS
콘텐츠 수정 권한을 누가 가질지에 따라 선택이 갈립니다. 마케팅 담당자가 직접 고치는 구조라면 편집 화면의 사용성이 중요하고, 개발팀이 관리한다면 배포 자동화가 더 중요합니다.
유지보수를 누가 할 것인지가 스택 결정에 가장 큰 영향을 줍니다. 그래서 저희는 기술 목록보다 담당자와 운영 시간을 먼저 묻습니다.
국내 결제·인증·물류 연동
국내 웹 프로젝트에서 반드시 설계해야 하는 부분이 결제, 본인인증, 배송 추적입니다. 이 세 가지는 나중에 끼워 넣으면 구조를 다시 손봐야 하는 경우가 많습니다.
결제
카드사와 PG사 정책, 환불 처리 흐름까지 함께 정합니다. 결제 수단을 나중에 늘리면 주문 상태 값과 관리자 화면을 다시 만들어야 하므로 기획 단계에서 정하는 편이 낫습니다.
본인인증
서비스 성격에 따라 필요한 수준이 다릅니다. 회원 가입 단계에서 한 번 확인하면 되는 경우도 있고, 결제나 신청 시점마다 다시 확인해야 하는 경우도 있습니다.
물류·배송
택배사 연동 방식과 배송 상태 표시 규칙을 정합니다. 상태 이름을 몇 단계로 보여줄지, 고객에게 언제 알림을 보낼지도 화면 설계에 포함됩니다.
관리자 화면과 운영 도구
관리자 화면은 실제로 매일 쓰는 사람의 업무 순서를 기준으로 만드는 게 좋습니다. 통계 화면은 보기 좋아도 실제로 안 쓰이면 유지 비용만 남습니다. 저희는 운영 담당자가 하루에 몇 번, 어떤 순서로 접속하는지를 먼저 확인합니다. 그 흐름에 맞춰 목록과 필터를 배치합니다.
예를 들어 주문을 확인한 뒤 바로 배송 상태를 바꾸는 업무라면, 주문 목록에서 상태 변경까지 두 번의 클릭 안에 끝나야 합니다. 화면을 예쁘게 만드는 것보다 이 동선을 줄이는 일이 운영 시간을 줄입니다.
성능과 접근성
이미지 최적화, 캐싱, 코드 분할 같은 기본 작업은 처음부터 반영합니다. 접근성은 키보드 탐색과 대체 텍스트, 색 대비를 기준으로 점검합니다.
- 이미지 용량과 지연 로딩 여부를 확인합니다
- 키보드만으로 주요 기능을 쓸 수 있는지 봅니다
- 색 대비와 대체 텍스트를 함께 점검합니다
국내에서도 공공·금융 관련 프로젝트라면 접근성 기준을 맞춰야 하는 경우가 있습니다. 어떤 기준을 적용할지는 프로젝트 시작 시 합의합니다.
기존 시스템과의 통합
이미 ERP, CRM, 그룹웨어를 쓰고 있다면 새 웹이 그 데이터와 어떻게 연결될지 정해야 합니다. 연동 방식은 API 연동, 배치 동기화, 수동 업로드 등 여러 가지가 있고, 각각 실시간성과 비용이 다릅니다.
모든 것을 실시간으로 맞추는 게 항상 좋은 선택은 아닙니다. 하루 한 번 동기화로 충분한 데이터라면 그 편이 장애 지점이 적고 운영도 단순합니다. 어느 항목이 실시간이어야 하는지를 업무 기준으로 나눕니다.
일정과 범위 관리
웹 프로젝트가 늘어지는 가장 흔한 이유는 기능 추가입니다. 저희는 1차 릴리스에 들어갈 기능과 2차로 미룰 기능을 문서로 나눠 관리합니다. 각 항목이 일정에 어떤 영향을 주는지 함께 확인합니다.
이 과정을 거치면 "왜 늦어지는지"를 서로 설명할 수 있게 됩니다. 기능을 빼자는 이야기가 아니라, 먼저 공개할 범위와 나중에 붙일 범위를 같은 문서 위에서 확인하는 절차입니다.
납품과 인수인계
코드 저장소
브랜치 전략과 커밋 기록을 정리해 넘깁니다. 누가 어떤 기준으로 리뷰했는지 남아 있으면 이후 수정이 빨라집니다.
배포 스크립트
서버에 올리는 절차를 문서로 남깁니다. 배포 과정이 사람 손에만 의존하면 담당자가 바뀔 때 위험해집니다.
환경 설정 문서
개발·검수·운영 환경의 차이를 표로 정리합니다. 사내 개발팀이 이어받을 경우에는 별도 세션으로 구조를 설명합니다.
인수인계 범위는 계약 단계에서 정합니다. 어디까지 문서로 넘기고 어디부터 별도 지원이 필요한지를 미리 합의해 두면, 오픈 이후 문의가 훨씬 줄어듭니다.
자주 받는 질문
상담에서 반복해서 나오는 세 가지 질문을 정리했습니다. 상황에 따라 답이 달라지는 부분은 상담에서 함께 확인합니다.
회사 소개 사이트도 웹앱처럼 만들어야 하나요?
아닙니다. 정보 제공이 목적이라면 정적 페이지 구조가 더 빠르고 유지비도 적습니다. 로그인이나 신청 기능이 필요한 시점에 웹앱 구조로 확장하는 편이 낫습니다.
기존 사이트를 개편할 때 데이터는 어떻게 되나요?
기존 콘텐츠와 회원 데이터를 먼저 확인하고, 이전 가능한 항목과 새로 정리해야 할 항목을 나눕니다. 옮길 수 없는 항목은 이유를 함께 정리해 알려드립니다. 이전 범위는 개편 시작 전에 합의합니다.
국내 결제 연동은 어느 단계에서 정하나요?
기획 단계에서 정합니다. 결제 흐름과 환불 정책이 화면 구조에 직접 영향을 주기 때문에, 나중에 정하면 재작업이 생깁니다.
함께 보면 좋은 서비스
웹 프로젝트는 다른 채널과 함께 진행되는 경우가 많습니다. 모바일 앱, 이커머스, AI 기능이 함께 필요하다면 각 페이지에서 범위를 확인하실 수 있습니다.
지금 만들려는 웹의 범위를 함께 정리해 보겠습니다
화면 수, 필요한 기능, 연동 대상만 알려주시면 1차와 2차 범위를 나눠 정리해 드립니다. 상담은 평일 09:00 - 18:00에 진행하며, 주말과 공휴일은 휴무입니다.
여우비 디지털
서울특별시 마포구 양화로15안길 19, 2층 디테일에이 114호 (서교동), 대한민국
평일 09:00 - 18:00 (주말 및 공휴일 휴무)