여러 지점이 쓰는 앱, 본사 공통 설정과 지점별 설정은 어떻게 나눌까요?

개발을 의뢰하기 전에는 항목마다 공통으로 쓸 값, 지점이 바꿀 수 있는 범위, 변경을 적용할 시점을 정해 두는 것이 좋습니다. ‘지점별 설정이 가능하다’는 한 문장보다 이 세 가지가 있어야 개발업체와 같은 결과를 확인할 수 있습니다.

아래는 가상의 체험 클래스 운영 앱으로 정책을 나누는 방법을 설명한 예시입니다.

이 예시에서는 모든 지점이 같은 신청 항목과 진행 상태를 사용합니다. 이름·연락처·프로그램·희망 시간을 받고, 신청 접수와 이용 확정을 구분합니다. 지점마다 다른 화면을 만들기보다 공통 흐름 안에서 필요한 값만 바꾸는 방향입니다.

이 구분은 모든 앱에 맞는 정답이 아닙니다. 프로그램을 지점이 직접 만들 수 있어야 한다면 그 권한과 확인 절차가 추가됩니다. 처음부터 모든 화면·문구·상태를 자유롭게 바꾸도록 만들기보다 실제로 다른 항목을 먼저 고르는 것이 목적입니다.

기존 업무의 처리량과 예외부터 정리해야 한다면 기존 업무를 앱으로 바꾸기 전 측정할 7가지를 함께 확인할 수 있습니다.

지금 표시된 시간이 같은 것만으로는 두 상태를 구분할 수 없습니다. A지점이 본사 값을 따르는 것인지, 우연히 같은 시간을 직접 입력한 것인지 알아야 다음 변경의 결과를 예상할 수 있습니다.

본사가 기본 종료 시간을 오후 7시로 바꿀 때도 기준이 필요합니다. 이 예시에서는 적용일 이후 A·C는 새 기본값을 따르고, 별도값을 쓰는 B는 오후 8시를 유지하도록 설계합니다. 모든 지점을 자동으로 덮어쓰는 방식도 가능하지만, 그것을 원한다면 예외를 없애는 조건과 변경 전에 확인할 대상을 따로 정해야 합니다.

운영 화면에는 최소한 다음 내용을 확인할 수 있게 요청해 보세요.

기본값으로 되돌리면 현재 표시만 바뀌는지, 이미 접수한 예약에도 영향을 주는지까지 이어서 확인해야 합니다.

하루만 다른 시간이 필요하다면 ‘행사 날짜에는 오후 1시 시작, 다음 날부터 기본 운영시간 사용’처럼 기간이 있는 예외로 처리할지 검토할 수 있습니다. 이 경우 예외가 끝난 뒤 본사 기본값으로 돌아가는지, 원래 지점 별도값으로 돌아가는지도 정해야 합니다.

이 예시의 C지점은 평소 본사 기본값을 따르므로 예외가 끝나면 그날 유효한 본사 운영시간을 사용합니다. 행사 기간에 본사 종료 시간이 오후 7시로 바뀌었다면 다음 날부터 오전 9시~오후 7시가 적용됩니다. 평소 별도값을 쓰는 지점이라면 그 별도값으로 돌아가도록 정할 수 있습니다.

첫 버전에 기간 설정 기능이 꼭 필요한 것은 아닙니다. 드문 예외를 수동으로 처리하기로 했다면 변경·복구 담당과 확인 방법을 운영 기준에 남기면 됩니다. 다만 화면에 종료 날짜가 있다는 이유만으로 자동 복구 기능까지 포함됐다고 가정해서는 안 됩니다.

휴무일과 운영시간 예외가 동시에 있으면 무엇이 우선인지도 확인하세요. 이 예시에서는 휴무일에는 신청 가능한 시간대를 만들지 않고, 다른 날에만 시간 예외를 적용하는 기준을 선택할 수 있습니다. 실제 서비스의 운영 방식에 맞춰 같은 날짜의 결과를 검수해야 합니다.

예를 들어 본사가 예약 변경 마감을 ‘시작 2시간 전’에서 ‘4시간 전’으로 바꾸고, 10월 20일 오전 0시부터 서버에 접수된 새 예약에 적용하기로 했다고 해보겠습니다. 예시의 날짜·시간은 한국시간 기준입니다.

이 예시에서는 표시된 변경 마감 시각까지 서버에 접수된 변경 요청을 허용하고, 그 시각을 넘으면 제한합니다. 고객이 화면에서 버튼을 누른 시각과 서버 접수 시각 중 무엇을 기준으로 삼는지도 개발업체와 정해야 합니다.

이렇게 하려면 예약마다 어떤 기준을 적용했는지 다시 확인할 수 있는 기록이 필요합니다. 최신 설정값만 보고 모든 예약의 마감을 다시 계산하면, 먼저 예약한 고객에게 안내했던 조건과 달라질 수 있습니다.

기존 예약까지 바꾸는 정책을 선택할 수도 있습니다. 그 경우에는 영향받는 예약 목록, 안내할 내용, 담당자의 확인과 변경 처리 방법을 함께 정해야 합니다. 이미 진행 중인 접수를 어떻게 다룰지 빼고 ‘즉시 반영’만 요구하지 않는 것이 중요합니다.

운영시간을 줄일 때도 같은 원칙입니다. 기존 예약이 새 시간 범위 밖에 남는지 먼저 보고, 설정 변경과 예약별 처리를 구분하세요. 설정 저장만으로 예약 취소나 고객 통보까지 완료됐다고 표시하면 안 됩니다.

정한 정책을 화면·처리·검수 조건으로 옮기는 방법은 운영 정책을 앱 기능과 검수 조건으로 바꾸는 방법에서 이어 볼 수 있습니다.

역할·담당 업무에 따라 허용할 대상을 나누는 설명은 로그인했다고 모든 정보를 볼 수 있는 것은 아닙니다에 정리돼 있습니다.

누가 요청하고, 누가 확정하며, 누가 적용 결과를 확인할지 항목별로 정해 보세요.

이 예시는 모든 변경에 본사 승인을 강제하는 권고가 아닙니다. 현장에서 바로 처리해야 하는 항목은 직접 변경하도록 정할 수 있습니다. 중요한 것은 기능 이름에 ‘설정 관리’가 있다는 사실보다 그 사람이 바꿀 수 있는 대상과 변경 후 확인 책임입니다.

지점이 추가·종료될 때도 같은 기준을 사용합니다. 새 지점은 어떤 기본값으로 시작할지, 지점 이름이나 담당자가 바뀌어도 기존 예약을 어떻게 찾을지, 종료 지점의 기록은 누가 확인할지 정합니다. 지점 종료와 관련 기록 삭제를 같은 행동으로 묶지 않습니다.

검수할 때는 정상 변경만 보지 마세요. 지점 담당자가 다른 지점의 값을 바꾸려는 경우, 임시 예외가 끝난 경우, 본사 기본값이 바뀌었는데 별도값을 쓰는 지점은 유지돼야 하는 경우도 함께 확인합니다.

지금 운영 중인 지점 두 곳을 골라 “같아야 할 값 하나, 달라도 되는 값 하나, 이미 접수한 건에 영향을 주는 값 하나”를 적어 보세요. 그 세 항목의 담당·적용 시점·확인 결과가 정해지면 개발 범위를 훨씬 구체적으로 설명할 수 있습니다.