사용자·문제·범위
이해관계자의 불편과 해결 수단을 분리하고 이번 버전의 범위·제약·타당성 판단을 작성합니다.
진행자가 “모임 앱에 AI 추천과 결제를 넣어 주세요”라고 말했습니다. 바로 기능 목록으로 옮기기 전에 어떤 불편을 해결하려는지 묻습니다. 추천보다 중복 신청과 엑셀 정원 계산을 먼저 해결해야 할 수도 있습니다.
이 문서의 목표는 누구의 어떤 문제를 해결할지, 무엇을 이번에 제외할지 근거와 함께 정하는 것입니다.
문제·목표·수단 구분
이해관계자는 결과의 영향을 받는 사람입니다. 참가자는 신청 성공 여부를 알아야 하고 진행자는 명단을 믿어야 하며 운영자는 장애 뒤 데이터를 복구해야 합니다. 비용을 승인하는 사람은 개발 시간을 중요하게 생각합니다. 요청한 사람 한 명의 말이 모든 관점을 대표하지는 않습니다.
문제 진술은 현재 불편을 말하고, 목표는 개선 여부를 관찰할 기준을 말하며, 해결 수단은 목표를 달성하는 방법의 후보입니다.
| 구분 | 모임 사례 |
|---|---|
| 현재 문제 | 같은 ID가 중복 명단에 들어가 정원이 잘못 계산된다. |
| 목표 | 같은 모임에 같은 ID가 두 번 집계되지 않는다. |
| 수단 후보 | 종이 대조, 스프레드시트 규칙, 작은 신청 프로그램 |
인터뷰에서는 “편리하게 해 드릴까요?” 대신 최근 중복 신청을 어떻게 처리했는지 묻습니다. 문서 분석은 기존 신청 양식을, 관찰은 진행자의 명단 수정 순서를 확인합니다. 사례가 충돌하면 담당자와 우선순위를 다시 정합니다. 빈 ID·취소·마감 뒤 신청 같은 예외를 정상 신청과 함께 수집합니다.
이번 버전의 경계
범위는 이번 작업에 포함할 능력이고 제약은 반드시 지켜야 할 조건입니다. 모임 하나, ID로 참가자 구별, 정원 검사, 신청·취소·마감을 첫 범위로 정합니다. 결제·실명 확인·메일 발송·여러 서버에서 동시 신청은 제외합니다. 제외했다는 것은 앞으로도 필요 없다는 뜻이 아니라 이번 검증에서 다루지 않는다는 뜻입니다.
데이터는 교육용 가상 ID만 사용하고, 외부 서비스 없이 Node.js 한 프로세스로 실행한다는 제약을 둡니다. 실제 서비스의 인증·동시성·개인정보 보관을 해결했다고 주장할 수 없습니다.
타당성은 구현 가능성, 비용과 효과, 실제 업무 적용 가능성 등을 검토하는 판단입니다. 외부 결제가 핵심이라면 기술보다 계약과 운영의 불확실성이 먼저 문제가 될 수 있습니다. 작은 프로그램부터 확인하는 선택은 이 모임의 규모와 학습 목표에 맞춘 결정입니다.
이름과 유효한 값 결정
모임을 만들 때 무엇을 입력받을지 정합니다. 다음 코드를 create-check.mjs에 저장하여 실행합니다.
function createSession({ id, title, capacity }) {
if (typeof id !== "string" || !id.trim() ||
typeof title !== "string" || !title.trim()) {
throw new TypeError("id and title must be non-empty strings");
}
if (!Number.isInteger(capacity) || capacity < 1 || capacity > 100) {
throw new RangeError("capacity must be an integer from 1 to 100");
}
return { id, title, capacity, status: "OPEN", participants: [] };
}
console.log(createSession({ id: "book-1", title: "첫 책", capacity: 2 }));typeof는 값의 종류를, trim()은 양끝 공백을 제거한 문자열을 반환합니다. ||는 어느 하나가 참이면 거절 조건을 만족한다는 뜻입니다. throw는 잘못된 입력을 예외로 알립니다. 정원 0이나 1.5는 이 모임 정책에서 유효하지 않습니다. 100이라는 상한은 이 실습이 선택한 규칙이며 모든 신청 시스템의 보편적 상한이 아닙니다.
status: "OPEN"과 빈 배열은 초기 상태입니다. 이후 본문에서는 이 상태를 임의로 바꾸지 않고 함수를 통해 새 상태를 얻습니다.
독립 문제: 요청이 충돌할 때
참가자는 마감 뒤 취소를 원하고 진행자는 마감 명단을 확정하고 싶어 합니다. 문제를 “취소 버튼 추가”로만 쓰면 무엇을 놓치나요? 추가로 물을 두 질문과 가능한 범위 결정을 제안하세요.
힌트
버튼은 수단입니다. 취소 뒤 새 신청을 받을지와 명단 보존 목적을 나누어 봅니다.
해설
마감의 뜻이 새 신청 금지인지 명단 수정 전체 금지인지 놓칩니다. “마감 뒤 취소한 자리를 다른 사람이 신청할 수 있나요?”, “확정 명단 이력은 왜 필요한가요?”를 묻습니다. 이 교재는 취소는 허용하되 모임을 다시 열지 않는 정책을 선택합니다. 출석·감사 목적의 이력 보존은 별도 요구로 남깁니다. 다른 선택도 가능하지만 근거와 후속 테스트가 달라져야 합니다.
요청 개수가 많다는 이유만으로 사업 가치가 높다고 보지 않습니다. 다음 문서에서 이번 정책을 결과로 확인할 수 있는 조건으로 바꿉니다.