매일 쓰는 웹앱을 만듭니다

홈페이지는 보여주는 쪽에 무게가 있고 웹앱은 데이터가 본체입니다. 회원이 가입하고 글이 쌓이고 주문과 정산 기록이 매일 늘어나는 서비스라면 화면 디자인보다 데이터 구조를 먼저 잡아야 합니다. 테이블을 어떻게 나누고 어떤 기록을 남길지가 이후 몇 년의 운영을 좌우하기 때문입니다.

권한 설계도 홈페이지에는 없는 숙제입니다. 관리자와 직원, 일반 회원이 볼 수 있는 화면과 만질 수 있는 데이터가 각각 다르고 조직이 커지면 부서 단위 권한도 필요해집니다. 노바랩은 이 구조를 개발 착수 전에 그림으로 정리해 고객 확인을 받은 뒤에 시작합니다. 권한이 꼬이면 나중에 고치기가 가장 어렵기 때문입니다.

처음부터 모든 기능을 넣으면 일정과 비용이 함께 불어납니다. 그래서 첫 버전에는 서비스가 성립하는 최소 기능만 담기를 권합니다. 예약이 핵심이면 예약 접수와 알림까지, 커뮤니티가 핵심이면 글쓰기와 댓글까지가 1차 범위가 되는 식입니다. 범위가 좁을수록 빨리 열고 빨리 배웁니다.

대신 구조는 다음 단계를 내다보고 짭니다. 결제를 2차로 미루더라도 주문 데이터는 처음부터 결제를 붙일 수 있는 모양으로 설계해 두는 식입니다. 이렇게 하면 기능을 늘릴 때 처음부터 다시 만드는 일이 없고 첫 버전에 쓴 돈이 그대로 자산으로 남습니다. 다음 버전은 검증된 토대 위에 얹기만 하면 됩니다.

웹앱 견적은 화면 수보다 화면 뒤에서 움직이는 것들로 정해집니다. 같은 열 페이지짜리 서비스라도 단순 조회 위주인지, 여러 사용자의 입력이 실시간으로 얽히는지에 따라 개발량이 몇 배로 벌어집니다. 데이터 흐름과 연동, 권한 구조가 값을 정하는 실제 변수입니다. 견적서를 비교할 때도 이 지점을 봐야 합니다.

그래서 상담 때는 만들고 싶은 화면 목록보다 지금 업무가 어떻게 돌아가는지 들려주시는 편이 좋습니다. 엑셀로 관리하던 흐름과 사람이 손으로 하던 확인 절차, 반복해서 놓치는 지점을 듣고 나면 어디까지 자동화할지, 규모가 어느 정도일지가 잡힙니다. 화면은 그 다음에 그려도 늦지 않습니다.

• ·권한 단계 수 — 회원 등급과 관리자 권한이 늘수록 화면 분기가 늘어납니다
• ·외부 연동 — 결제·문자·기존 시스템 API 연결은 각각 별도 개발 항목입니다
• ·실시간 요구 — 알림이나 동시 편집처럼 즉시 반영돼야 하는 기능
• ·데이터 이관 — 쓰던 엑셀이나 구시스템의 데이터를 옮겨야 하는지