학회·학술대회 운영 시 숙박과 교통 안내 업무를 비오케이솔루션 개발 범위서로 정리하는 방법을 소개합니다. 시스템화 항목과 사무국 수동 운영 항목을 나누고, 협력호텔·셔틀 데이터를 개발사에 전달하는 명세 작성법까지 단계별로 정리했습니다.
- 결론 요약: 숙박·교통 안내는 '시스템화할 것'과 '사무국 수동 운영으로 남길 것'을 먼저 나눈다
- 결론: 시스템화할 것과 남길 것을 먼저 나눈다
결론 요약: 숙박·교통 안내는 '시스템화할 것'과 '사무국 수동 운영으로 남길 것'을 먼저 나눈다
결론: 시스템화할 것과 남길 것을 먼저 나눈다
숙박·교통 안내를 개발 범위서에 옮기기 전에 가장 먼저 할 일은 기능 나열이 아니라 업무 분리입니다. 참가자가 직접 조회하고 신청하는 업무와, 사무국이 상황을 보고 판단해야 하는 업무를 나누는 것—이 선이 그어져야 개발사에 전달할 범위도, 예산도, 운영 계획도 함께 정리됩니다.
| 항목 | 시스템 개발 범위 | 사무국 수동 운영 |
|---|---|---|
| 협력호텔 | 요금·객실 수·예약 마감 안내 게시 | 계약 조건 협상, 긴급 숙소 변경 대응 |
| 셔틀 | 시간표 조회 | 당일 유연 운행 판단 |
| 픽업 | 공항 픽업 신청폼 접수 | 기사·차량 배차 확정 |
| 문의 | 접수 폼 + 알림톡 안내 | 개별 답변, 예외 케이스 처리 |
기준은 하나입니다. "참가자 입력 → 데이터 축적 → 자동 안내" 흐름이 만들어지는가입니다. 만들어진다면 시스템 범위이고, 사람의 판단이 매번 끼어들어야 한다면 관리자 페이지에서 상태만 확인하는 수동 운영으로 남기는 게 맞습니다.
이 분리가 끝나면 요금제 선택은 자연스럽게 좁혀집니다. - 라이트 관리형(월 5만원부터): 1~5페이지 반응형 홈페이지, 서버·SSL·기본 유지관리 포함.
준비물·전제조건: 협력호텔·교통 데이터를 개발사가 이해할 수 있는 형태로 모으기
협력호텔 조건표를 엑셀 어딘가에 흩어놓은 채로 상담에 들어가면, 개발사는 그걸 다시 읽고 재질문합니다. 그 질문 몇 통이 오가는 동안 견적은 부풀어 있기 십상이에요. 그래서 이 단계에서 가장 먼저 할 일은 호텔 데이터를 표 한 장으로 압축하는 겁니다.
칼럼은 이렇게 잡아보세요. | 호텔명 | 객실타입 | 행사요금 | 배정 수량 | 마감 조건 | 업데이트 주기 |
금액 칸은 여기에 비워뒀어요. 공개 자료만으로는 단정할 수 없는 값이니, 실제 협의 단가를 받는 대로 채우면 됩니다. 핵심은 "마감 조건"과 "업데이트 주기"인데, 이 두 칸이 비어 있으면 개발사는 예약 시스템의 재고 관리 로직을 설계할 수 없습니다. "선착순인가, 마감일이 있는가, 남은 방 수를 실시간 보여줘야 하는가" — 이게 예약 화면 구조를 갈라놓는 질문이에요.
셔틀버스는 노선 / 운행 시각표 / 탑승 위치 세 쌍으로 묶고, 주차권은 발급 방식(사전 신청 vs 현장 배부)을 명시하세요. 여기에 더해 견적에 직접 영향을 주는 조건을 미리 확정해둬야 합니다.
단계별 절차: 범위 확정 → 데이터 명세 → 견적 비교 → 연동 설계까지 4단계 문서화
행사 2주 전 사무국 메일함을 가장 많이 채우는 것이 "숙소는 어디로 잡나요", "공항에서 행사장까지 어떻게 가나요" 문의다. 이걸 답장으로 하나씩 처리하다 보면 안내가 사람마다 달라지고, 그 불일치가 현장에서 다시 불만으로 돌아온다. 범위서는 이 문의를 미리 흡수하는 장치다. 4단계로 나눠 문서화해보자.
행사 규모보다 먼저 볼 것이 해외 참가자 비율이다. 이 비율에 따라 페이지 언어와 픽업 신청 포함 여부가 갈린다. | 항목 | 국내 위주·소규모 | 해외 참가 비율 높음 |
| 언어 | 한국어 안내 페이지 | 영어 안내 페이지 포함 |
|---|---|---|
| 공항 이동 | 문의 접수 후 수동 안내 | 공항 픽업 신청폼을 개발 범위에 포함 |
| 문서화 초점 | 안내 콘텐츠 항목 | 신청·접수 프로세스 |
2단계 — 데이터 명세: "누가, 언제 고치나"부터 정한다
호텔 객실 상황과 셔틀 시간표는 행사가 가까워질수록 계속 바뀐다. 그래서 명세의 핵심은 디자인이 아니라 수정 권한과 갱신 주기다.
흔한 실수 vs 권장 기준: 견적 오차와 운영 문제를 만드는 항목 비교
행사 2주 전, "셔틀 승차장이 어디냐"는 문의가 이메일로 쌓이고 숙소를 바꾸려는 참가자 메일은 답장 사이에 묻히는 장면. 견적 오차와 운영 문제는 대부분 이렇게 범위서 한 장에서 시작됩니다. 항목별로 무엇을 정해두느냐가 갈림길입니다.
| 항목 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 숙박 안내 범위 | "호텔 안내만 넣어달라"는 막연한 요청 | 호텔별 필드(객실 유형·요금·거리·예약 조건 등)까지 정의된 데이터 명세 |
| 지도 API | 기본 포함으로 가정 | 유료 API 사용 여부·호출량 사전 확정 |
| 변경 문의 처리 | 이메일로 수동 처리 | 관리자 시스템에서 숙소 변경·셔틀 탑승 문의 접수·처리 이력 관리 |
| 폼 구조 | 등록 데이터와 숙박 신청을 별도 폼으로 분리 | 연동으로 중복 입력 제거 |
| 다국어 | 행사 확정 후 사후 추가 | 초기 범위에 포함해 재개발 비용 방지 |
왜 견적이 갈리는가
비용 구조를 알면 2번이 왜 위험한지 보입니다. 비오케이솔루션 기준 문자 발송비·외부 유료 API·PG 수수료·도메인 비용은 구독료에 포함되지 않고 별도입니다. 지도 API는 '외부 유료 API'에 해당하니, 호출량을 정하지 않으면 견적이 나중에 흔들립니다. 게다가 최소 이용기간 12개월을 권장하므로 대충 잡은 범위의 오차가 1년 내내 따라옵니다.
산출물 체크리스트와 마무리: 화면 정의서·데이터 명세·운영 매뉴얼을 갖추고 상담하기
행사 두 달 앞으로 다가오면 "숙소 정보 어디서 보나요?", "셔틀 몇 시에 출발하나요?" 같은 문의가 먼저 쏟아집니다. 그때 안내 화면을 만들기 시작하면 이미 늦었다는 신호이고, 산출물을 정리해둔 팀만 상담 한 번으로 페이지를 띄울 수 있습니다.
범위서에 반드시 담을 산출물 4가지
- 참가자용 화면 정의서 — 숙박 안내, 교통·셔틀 안내, 주차, 픽업 신청 화면별로 "무엇을 보여주고 무엇을 입력받는지" 한 줄씩 적기
- 데이터 명세와 업데이트 주기 — �