홈페이지 제작과 웹 서비스 개발은 무엇이 다른가요?

두 말은 어디에서 갈리나요?

홈페이지 제작은 회사와 상품을 설명하는 것이 목적이고, 웹 서비스 개발은 사용자가 그 안에서 무엇을 처리하게 만드는 것이 목적입니다. 소개, 오시는 길, 공지, 문의 양식까지가 홈페이지이고, 사용자가 신청하고 결제하고 자신의 내역을 확인하는 순간부터 웹 서비스입니다.

겉보기에는 둘 다 브라우저로 여는 웹사이트여서 구분이 잘 안 됩니다. 그래서 견적과 일정이 크게 달라지는 지점을 알아 두면 "회원 기능만 붙이면 되죠"라는 대화에서 생기는 오해를 줄일 수 있습니다.

경계가 애매한 경우도 있습니다. 소개 페이지에 예약 버튼 하나만 있는 사이트가 그렇습니다. 이때는 그 버튼을 누른 뒤 자료가 어디에 쌓이고 누가 그 자료를 보며 일하는지를 보면 어느 쪽인지 정해집니다. 메일로 받아 사람이 처리하면 홈페이지 범위에 가깝고, 예약 현황을 화면에서 관리해야 하면 웹 서비스입니다.

기술적으로 무엇이 달라지나요?

웹 개발 문서는 이 차이를 정적 사이트와 동적 사이트로 설명합니다. 정적 사이트는 특정 주소를 요청할 때마다 서버에 미리 저장된 같은 내용을 그대로 돌려주는 사이트입니다. 회사 소개 페이지는 누가 열어도 같은 글이 나오므로 여기에 해당합니다.

동적 사이트는 응답의 일부를 필요한 순간에 만들어 냅니다. 보통 데이터베이스에 있는 값을 화면 틀에 끼워 넣어 페이지를 구성하고, 같은 주소라도 사용자가 입력한 정보나 저장된 설정에 따라 다른 내용을 돌려줍니다. 응답을 만드는 과정에서 알림을 보내는 것처럼 다른 동작을 함께 처리할 수도 있습니다. 이런 동작을 담은 코드는 대부분 서버에서 실행되며, 이 영역을 서버 사이드 프로그래밍이라고 부릅니다.

즉 웹 서비스는 보이는 화면 외에 데이터를 보관하고 처리하는 쪽이 함께 있어야 성립합니다. 로그인한 사람에게 자기 신청 내역만 보여 주는 화면은 겉보기에 한 장이지만, 누가 요청했는지 확인하고 그 사람의 자료만 골라 내보내는 처리가 서버에 있어야 만들어집니다. 이 부분이 견적서에서 화면 수로 드러나지 않는 비용입니다.

그래서 무엇을 더 만들어야 하나요?

구분	홈페이지	웹 서비스
데이터	페이지에 적힌 내용	회원·신청·결제 내역을 저장하고 조회
사용자 구분	구분하지 않음	로그인한 사람에 따라 다른 화면과 권한
운영 화면	게시글 등록 정도	접수 확인, 상태 변경, 취소·환불 처리
실패 처리	페이지가 안 열리는 경우	결제 중단, 중복 신청, 알림 미발송까지 정의

표의 아래 두 줄이 기획 단계에서 가장 많이 빠집니다. 사용자가 보는 화면은 그려지는데, 접수된 신청을 누가 어떤 화면에서 처리하는지가 정해지지 않은 상태로 개발이 시작되는 경우입니다.

예를 들어 같은 신청 양식이라도

상담 신청 양식을 하나 만든다고 하겠습니다. 홈페이지라면 입력값을 담당자 메일로 보내는 것으로 끝납니다. 양식이 다섯 칸이든 열 칸이든 구조는 같습니다.

웹 서비스라면 같은 양식이 다르게 동작합니다. 신청 내역이 저장되고, 신청자는 로그인해 진행 상태를 확인하고, 담당자는 접수·확인·완료로 상태를 바꾸며, 같은 사람이 중복 신청하면 어떻게 처리할지 정해져 있어야 합니다. 화면은 한 장이지만 그 뒤에 저장 구조와 상태 규칙, 운영 화면이 함께 생깁니다.

공개한 뒤에 달라지는 일

홈페이지는 공개 후 할 일이 글과 이미지를 고치는 쪽에 몰려 있습니다. 담당자가 공지와 소개 문구를 바꾸고, 문의 메일을 확인하면 운영이 돌아갑니다.

웹 서비스는 사람의 업무가 함께 붙습니다. 접수된 건을 처리하는 담당자가 있어야 하고, 결제나 알림이 실패한 건을 찾아 다시 처리하는 절차가 필요하며, 저장한 개인정보를 언제까지 보관하고 어떻게 지울지도 정해야 합니다. 화면이 멈췄을 때의 영향도 다릅니다. 소개 페이지가 잠시 안 열리는 것과 접수 중이던 신청이 사라지는 것은 다른 사고입니다.

그래서 웹 서비스 견적을 볼 때는 개발 비용과 함께 공개 이후의 서버 비용, 외부 서비스 사용료, 장애 대응 담당을 같이 확인하시는 편이 좋습니다.

자주 보이는 오해

첫째는 반응형으로 만들면 앱이 필요 없다고 보는 것입니다. 화면 크기에 맞춰 보이는 것과, 푸시 알림이나 카메라처럼 기기 기능을 쓰는 것은 다른 문제입니다. 앱과 웹 중 무엇을 먼저 만들지는 유입 경로와 재방문 빈도를 함께 보고 정합니다.

둘째는 홈페이지에 기능을 하나씩 붙여 웹 서비스로 키우려는 계획입니다. 저장 구조와 권한을 처음부터 염두에 두지 않았다면, 회원과 결제를 더하는 시점에 기존 화면을 다시 만드는 일이 생깁니다. 지금은 홈페이지만 필요하더라도 2년 안에 사용자가 직접 처리할 업무가 생길지는 미리 적어 두시는 편이 좋습니다.

지금 확인할 한 가지

만들려는 사이트에서 사용자가 "읽고 나가는가, 아니면 무엇을 남기고 가는가"를 한 줄로 적어 보시기 바랍니다. 남기는 것이 있다면 그 자료를 누가 어느 화면에서 처리하는지까지가 이번 개발 범위입니다.

그 범위를 정리한 뒤 요구사항으로 옮기는 단계가 어렵다면, 현재 업무에서 주고받는 양식과 처리 순서를 모아 네오렉트에 보내 주시면 됩니다.