
배경과 목표
어떤 문제에서 시작했나요?
리모델링 주택사업을 진행하는 아파트 단지에서 이주계획 안내와 신탁등기·이주비 대출 상담을 위해 세대별 방문 일정을 받아야 했다. 날짜와 시간대마다 받을 수 있는 인원이 달라 사무소가 일정을 직접 조율해야 했고, 예약한 세대와 먼저 내방한 세대가 겹치면 현장에서 대기가 생겼다. 개발완료 보고서는 이 시스템의 목적을 "아파트 방문 예약을 온라인으로 간소화하고, 관리자 측에서 예약 현황을 효율적으로 관리"하는 것으로 적고 있다.
목표: 세대가 별도 가입 없이 동·호수만으로 예약할 수 있게 하고, 날짜별로 다른 가능 인원을 데이터로 관리한다. 관리 사무소는 전체 예약을 한 화면에서 조회·검색·취소하고, 예약 명단을 엑셀로 내려받아 기존 사무 업무에 이어 쓸 수 있게 한다.
네오렉트의 역할
어디까지 수행했나요?
네오렉트가 예약 페이지와 관리자 페이지 2종의 화면 설계와 프론트엔드 개발, 데이터베이스 설계와 백엔드 로직, 배포까지 수행했다. 예약 슬롯·예약 내역 테이블을 설계하고 Supabase의 RPC·트리거로 잔여 좌석과 예약 상태를 처리했으며, 두 웹을 Vercel에 배포해 단지에 적용했다. 자료에 외부 협력사 참여 기록은 없다.
주요 기능
무엇을 만들었나요?
- 동·호수 기반 예약 가능 여부 확인
- 날짜별 예약 가능 시간대와 잔여 좌석 조회
- 예약 생성과 예약 성공 내역 확인
- 세대의 예약 내역 조회·변경·취소
- 관리자 로그인과 전체 예약 조회
- 동·호수 검색과 날짜 필터
- 관리자 예약 취소(CANCELLED 처리)
- 전체 예약 데이터 엑셀 다운로드
해결 과정
제약을 어떻게 풀었나요?
제약 1
세대가 별도 계정을 만들지 않고 예약해야 했다.
의사결정: 사용자 테이블과 로그인·세션을 두지 않고, 동·호수와 예약 슬롯 조합으로 예약을 식별하기로 했다.
구현: 예약 테이블을 동·호수 + 슬롯 기준으로 설계하고 상태값을 CONFIRMED·CANCELLED 두 가지로만 운영했다.
제약 2
날짜와 시간대마다 받을 수 있는 인원이 달랐다.
의사결정: 시간대별 좌석 수를 데이터로 관리하고, 관리자가 마감 상태를 직접 바꿀 수 있게 했다.
구현: 예약 슬롯 테이블에 날짜·시간대별 좌석 수와 마감 상태를 두고, Supabase RPC·트리거로 잔여 좌석을 계산해 화면에 노출했다.
제약 3
첫 버전에는 예약 조회·취소가 없어 "예약 완료 후 변경 불가" 안내만 띄워야 했다.
의사결정: 단지에 적용하는 버전에서는 세대가 직접 예약을 조회·수정·취소할 수 있게 범위를 넓혔다.
구현: 예약 조회 입력 화면과 예약 내역 화면을 추가하고, 예약 변경·취소를 세대 화면에서 처리하도록 했다.
제약 4
사무소는 예약 명단을 기존 엑셀 업무와 함께 대조해야 했다.
의사결정: 관리자 화면 안에서 끝내지 않고 전체 예약 데이터를 파일로 꺼낼 수 있게 했다.
구현: 관리자 페이지에 전체 예약 엑셀 다운로드를 붙여, 사무소에서 VLOOKUP 등으로 기존 명단과 맞춰 볼 수 있게 했다.
화면
실제 화면과 구조




사용 기술
발행 2026.09.30
함께 보면 좋은 콘텐츠
비슷한 프로젝트를 준비 중이신가요?
배경과 제약 조건을 알려주시면 이 사례의 경험을 바탕으로 진행 방식과 예상 범위를 제안드립니다.