소규모 클래스 신청·정원 관리 서비스 — 문제정의

원데이 클래스를 열기로 했습니다. 일정과 장소를 정하고, 소개 글을 올리고, 마지막에 이렇게 적습니다.

“참여를 원하시면 메시지로 신청해 주세요.”

처음에는 간단합니다. 신청한 사람에게 답장하고, 이름을 적어두면 됩니다. 그런데 신청과 문의가 섞이고, 취소나 변경까지 들어오면 확인해야 할 것이 늘어납니다.

이 사람은 문의만 했을까요, 신청까지 했을까요? 취소한 사람을 명단에서 뺐을까요? 지금 한 명을 더 받아도 될까요?

이번 달에는 이 상황을 출발점으로 소규모 클래스 신청·정원 관리 서비스의 MVP를 만들어봅니다. 예를 들어, 혼자 운영하는 공방에서 정원 6명의 원데이 클래스를 연다고 가정해봅시다. SNS에 일정과 장소를 안내하고, 메시지로 신청받습니다.

이번 사례는 실제 회원의 제출문이나 인터뷰를 바탕으로 한 사례가 아니라, 학습을 위해 설정한 가상 사례입니다. 공방과 정원은 접수 상황을 이해하기 위한 설정이며, 아래의 불편과 해결 방향은 실제 운영자를 통해 확인해야 할 가설입니다.

1. ‘클래스 관리가 어렵다’는 말부터 좁혀봅니다

처음 떠올릴 수 있는 아이디어는 넓습니다.

“클래스 운영을 편하게 해주는 서비스를 만들자.”

하지만 클래스 운영에는 홍보, 일정 조율, 신청 접수, 결제, 취소, 수업 준비, 후기 관리까지 포함됩니다. 이 모든 일을 한꺼번에 해결하려고 하면 첫 버전에 무엇을 만들어야 할지 판단하기 어려워집니다.

그래서 이번에는 신청을 받고, 누가 참여하는지 확인하는 과정에 집중합니다.

핵심 사용자는 혼자 소규모 클래스를 운영하며 메시지로 신청받는 운영자입니다. 신청자는 운영자와 연결된 또 하나의 사용자이지만, 출발점은 운영자의 접수 관리 문제로 잡습니다.

운영자가 접수 결과를 정확하게 관리할 수 있어야 신청자에게도 “신청이 완료됐다”는 안내를 일관되게 제공할 수 있기 때문입니다.

2. 메시지 자체보다, 메시지 이후의 일을 봅니다

가상 사례의 현재 접수 과정을 따라가봅시다.

1. 과정운영자가 하는 일확인할 문제신청 메시지를 받는다 → 문의인지 신청인지 읽고 판단한다 → 신청 의사가 명확하게 전달되는가?

2. 신청을 접수한다 → 이름과 연락처를 별도 명단에 적는다 → 옮겨 적는 과정에서 누락·중복이 생기는가?

3. 남은 자리를 확인한다 → 현재 명단과 정원을 비교한다 → 최신 신청과 취소가 반영돼 있는가?

4. 취소 요청을 받는다 → 명단을 수정하고 자리를 다시 계산한다 → 대화만 처리하고 명단 수정은 잊는가?

5. 추가 신청을 받는다 → 접수 가능 여부를 판단하고 답장한다 → 실제 잔여석과 안내가 일치하는가?

이 흐름에서 주목할 부분은 같은 신청 정보를 여러 번 다룬다는 것입니다.

메시지에서 신청을 확인하고, 명단에 다시 적고, 취소가 오면 다시 수정합니다. 신청 여부와 참여 인원이 대화와 명단에 나뉘어 있으면 운영자는 두 곳을 비교해야 합니다.

따라서 지금의 문제 가설은 단순히 “메시지가 많아서 불편하다”가 아닙니다.

신청·취소 정보를 별도 명단에 수동으로 반영해야 해서, 현재 참여자와 남은 자리를 확인하는 과정이 불안정할 수 있다는 것입니다.

메시지를 보기 좋게 정리하는 기능과 신청 상태를 명단에 바로 반영하는 기능은 서로 다른 문제를 해결합니다. 우리가 줄이려는 행동이 무엇인지에 따라 해결 방향도 달라집니다.

3. 모든 불편을 첫 문제로 선택하지는 않습니다

이 사례에서는 여러 문제를 떠올릴 수 있습니다.

• 같은 질문에 반복해서 답하는 일

• 신청자 정보를 명단에 옮겨 적는 일

• 입금 여부를 확인하는 일

• 취소 후 남은 자리를 다시 계산하는 일

이번 첫 MVP에서는 신청·취소 결과가 명단·잔여석에 정확히 반영되지 않는 문제를 우선 확인합니다.

접수 결과가 정확해야 누구에게 참여 안내를 보낼지, 추가 신청을 받을 수 있는지 판단할 수 있습니다. 신청부터 명단 반영까지 하나의 흐름으로 연결하면, 별도로 옮겨 적는 과정도 줄일 수 있습니다.

반복 안내도 운영자의 시간을 쓰게 합니다. 하지만 같은 질문에 답하는 일을 줄여도 신청 누락이나 잔여석 불일치는 남을 수 있습니다. 그래서 이번에는 접수 결과를 정확하게 관리하는 문제를 먼저 확인하고, 반복 안내는 뒤로 미룹니다.

입금 확인을 함께 다루면 결제 전후의 자리 확보, 미입금 처리, 환불 등 추가 판단이 필요합니다. 이번 학습 사례는 온라인 결제 없이 신청 완료 시 자리를 확보하는 접수 방식을 제작 조건으로 두고 시작합니다. 이는 문제의 중요성을 검증한 결과가 아니라, 접수와 명단 반영의 연결을 살펴보기 위해 정한 조건입니다.

이 선택에는 적용 조건이 있습니다. 실제 운영자가 입금 완료를 기준으로 참여를 확정한다면, 이번 접수 방식이 맞지 않을 수 있습니다. 인터뷰에서는 불편의 크기뿐 아니라 언제 한 자리가 확정되는지도 확인해야 합니다.

4. 서비스가 필요한지부터 확인합니다

여기까지 생각했다고 해서 새로운 서비스가 필요하다고 결론 내릴 수는 없습니다.

운영자가 이미 신청 폼과 스프레드시트로 문제없이 관리하고 있다면, 별도 서비스를 사용할 이유가 약할 수 있습니다. 실제로 가장 큰 부담이 입금 확인이라면 우리가 선택한 문제의 우선순위도 달라집니다.

그래서 “이런 서비스가 있으면 쓰실 건가요?”보다 최근 운영 경험을 묻는 편이 좋습니다.

• 가장 최근 클래스에서는 어떤 경로로 신청받았나요?

• 신청 메시지를 받은 뒤, 명단에는 어떻게 반영했나요?

• 취소가 생겼을 때 어떤 정보를 어디에서 수정했나요?

• 참가자의 자리는 어느 시점에 확정했나요? 신청을 받았을 때인가요, 입금을 확인했을 때인가요?

• 마지막 한 자리가 남았을 때 접수 가능 여부를 어떻게 확인했나요?

• 누락이나 인원 착오가 있었다면, 언제 발견했고 어떻게 처리했나요?

• 이미 신청 폼을 쓴다면 어떤 일을 여전히 수동으로 하고 있나요?

가능하다면 개인정보를 가린 신청 내역과 명단을 함께 보며 과정을 확인합니다.

이때 찾을 근거는 막연한 불만보다 구체적인 행동입니다. 같은 정보를 두 번 입력하는지, 취소를 여러 곳에 반영하는지, 자리를 확인하려고 대화와 명단을 반복해서 오가는지를 봅니다.

그 행동이 확인돼야 무엇을 줄일지 판단할 수 있습니다.

5. 이번 주의 문제정의

현재 단계의 문제정의는 다음과 같습니다.

메시지로 소규모 클래스 신청을 받는 1인 운영자는 신청·취소 내용을 별도 명단에 직접 반영해야 한다. 이 과정에서 최신 참여자와 잔여석을 확인하려고 대화와 명단을 다시 대조하며, 누락이나 인원 착오가 생길 가능성이 있다.

이는 가상 사례를 바탕으로 작성한 문제 가설입니다. 여기에서 첫 MVP가 검증할 해결 가설을 연결합니다.

신청·취소 결과가 하나의 명단과 잔여석에 바로 반영되면, 운영자가 정보를 옮겨 적고 다시 대조하는 일을 줄일 수 있을 것이다.

실제 운영자가 기존 신청 폼만으로 명단과 정원을 충분히 관리하고 있다면, 새로운 서비스의 필요성은 약해집니다. 가장 큰 부담이 접수보다 입금 확인이라면 문제의 우선순위도 다시 잡아야 합니다. 인터뷰에서는 우리의 가설을 뒷받침하는 경험과 함께, 이 가설이 맞지 않는 조건도 확인하겠습니다.

첫 버전에서 기대하는 핵심 경험도 이 가설에 맞춥니다.

신청자는 접수 결과를 바로 확인하고, 운영자는 별도의 명단을 다시 만들지 않아도 현재 참여자를 확인한다.

다만 이것은 아직 기대하는 결과입니다. 실제로 일이 줄었는지, 기존 방식보다 사용하기 쉬운지는 구현 후 확인해야 합니다. 기존 접수 방식과 비교해 명단으로 옮겨 적는 행동과 대화·명단을 다시 대조하는 행동이 줄었는지 살펴보겠습니다.

6. 처음 아이디어에서 무엇을 남겼을까요?

처음에는 클래스 운영 전반을 편하게 만드는 서비스를 생각했습니다. 이번 주에는 그중 신청·취소 내용을 명단에 반영하고, 현재 참여 인원을 확인하는 문제로 좁혔습니다.

이번 사례는 결제 없이 신청 완료 시 자리를 확보하는 조건으로 시작합니다. 그 조건 안에서 어떤 행동을 연결해야 할지는 다음 주 사용자 흐름에서 살펴봅니다. 신청·취소와 명단 반영을 위해 필요한 세부 기능은 그 흐름을 기준으로 3주차에서 판단하겠습니다.

남긴 것은 신청과 운영 명단 사이의 연결입니다. 운영 전반으로 넓히는 것은 미뤘습니다. 첫 버전이 해결할 문제를 분명하게 하기 위해서입니다.

7. 여러분의 아이디어에도 적용해보세요

자신의 아이디어를 다음 네 문장으로 적어보세요.

1. 누가: 어떤 일을 하는 사람인가?

2. 언제: 어느 상황에서 문제가 생기는가?

3. 현재: 지금은 어떤 순서와 도구로 처리하는가?

4. 손실: 그 과정에서 무엇을 다시 하거나 놓치는가?

“프리랜서를 위한 업무 관리 앱”처럼 넓게 적었다면, 최근 업무 하나를 골라 실제 행동으로 좁혀보세요.

그리고 해결책을 적기 전에 질문해보세요.

이 문제가 있다는 근거는 무엇이고, 아직 내 추측인 부분은 무엇인가요?

문제정의는 아이디어를 그럴듯하게 설명하는 문장이 아닙니다. 첫 버전에서 무엇을 확인할지 정하는 기준입니다.

이번 주에 남긴 것

이번 사례에서는 다음 기준을 남겼습니다.

• 핵심 사용자: 메시지로 신청받는 소규모 클래스의 1인 운영자

• 문제 가설: 신청·취소와 명단이 분리되어 수동 반영과 재확인이 필요하다.

• 해결 가설: 접수 결과를 명단·잔여석에 연결하면 옮겨 적기와 대조를 줄일 수 있다.

• 사전 제작 조건: 운영자 한 명, 클래스 한 개, 온라인 결제 없이 신청 완료 시 자리 확보

• 확인할 근거: 실제 접수 과정, 수동 반영 행동, 착오 경험, 자리 확정 기준

다음 주에는 이 문제정의를 사용자 흐름으로 바꿉니다.

운영자는 무엇을 준비하고, 신청자는 어떤 행동을 하며, 어느 순간 접수가 완료됐다고 확신할 수 있을까요?

그 흐름을 먼저 정한 뒤 필요한 화면을 찾아보겠습니다.

이번 주 한 장 실습

여러분이라면 어떤 문제 하나를 먼저 살펴볼까요?

내 상황이나 본문의 가상 클래스 사례 중 하나를 골라 아래 세 칸을 채워보세요. 앞에서 살펴본 문제정의 방법을 한 장에 정리하는 실습입니다.

1. 장면: 누가, 언제, 어떤 순서와 도구로 일을 처리하나요?

2. 문제: 그 과정에서 반복하거나 놓치는 일을 문제 문장 하나로 적어보세요.

3. 근거: 확인한 사실과 추측을 구분하세요. 아직 모른다면 ‘미확인’과 다음 확인 질문을 남겨도 됩니다.

막히면 본문의 ‘취소 요청을 받은 운영자’를 골라, 지금 고치는 정보와 도구부터 적어보세요. 본문 사례는 가상 설정이므로 실제로 확인한 사실과 구분해 적습니다.

PDF를 인쇄하거나 태블릿에서 필기해보세요. 사용자·상황·현재 행동이 드러나고, 문제 하나와 근거·미확인 사항을 구분했다면 이번 실습의 초안이 완성됩니다.

여러분이라면 이 운영자의 접수 과정에서 어떤 문제를 가장 먼저 확인하고 싶나요? 신청 누락, 취소 반영, 잔여석 확인 중 하나와 이유를 댓글로 남겨주세요. 워크북에 적은 판단을 한 문장으로 공유해도 좋습니다. 🙌