개발 프로세스 모델의 선택

진행자는 취소 정책을 아직 정하지 못했고 운영자는 저장 오류가 가장 걱정됩니다. 신청부터 모든 설계를 확정하고 한 번에 구현할지, 작은 흐름을 보여 주며 결정할지 선택해야 합니다.

개발 프로세스는 요구·설계·구현·검증·운영 활동을 조직하는 방식이고, 프로세스 모델은 그 활동의 순서와 피드백 관계를 단순화한 표현입니다. 모델 이름만 고르는 것보다 이 프로젝트의 불확실성을 어디에서 줄일지가 중요합니다.

순차 모델과 대응 검증

폭포수 모델은 단계별 산출물을 검토한 뒤 다음 단계로 진행하는 관점을 강조합니다. 규칙이 비교적 안정되고 승인 증거가 중요한 상황에서 계획을 명확히 하는 데 유용합니다. 취소 정책을 늦게 알게 되면 요구·설계·테스트를 함께 고칠 비용이 생깁니다. 순차 모델도 현실에서는 오류와 변경을 앞 단계로 돌려보냅니다.

V 모델은 요구와 인수 검증, 시스템 설계와 시스템 검증, 상세 설계와 단위 검증처럼 개발 활동과 대응 검증을 연결합니다. 테스트를 마지막에 처음 생각하지 않도록 돕습니다. V 모양을 쓴다는 이유만으로 요구 오류가 자동으로 발견되거나 반복 개발이 불가능해지는 것은 아닙니다.

반복·증분·프로토타입 구분

증분 개발은 신청→취소→저장처럼 사용할 수 있는 기능을 조금씩 추가합니다. 반복 개발은 같은 부분을 피드백으로 다시 다듬습니다. 신청 안내를 먼저 만들고 사용자의 오해를 보고 문구를 고치는 것은 반복이고, 취소를 추가하는 것은 증분입니다. 두 방식은 함께 사용할 수 있습니다.

프로토타입은 불확실한 질문에 답하기 위한 시제품입니다. 화면 목업으로 “마감 뒤 취소” 안내가 이해되는지 확인할 수 있습니다. 빠른 화면 실험의 저장·보안·오류 처리가 충분하지 않다면 운영 코드로 그대로 승격하지 않습니다. 폐기형과 점진 개선형 중 어느 의도인지 먼저 합의합니다.

나선형 모델은 반복마다 목표·대안·위험을 살피고 위험을 줄이는 검증을 강조합니다. 모임의 실제 서비스에서는 동시 신청과 복구를 먼저 시험할 이유가 있을 수 있습니다. 이 교재의 단일 프로세스 예제는 그 위험을 해결했다고 주장하지 않습니다.

RAD는 시간 제한과 사용자 참여, 재사용·도구를 이용한 빠른 개발을 강조하는 접근입니다. 통합 프로세스(UP)는 유스케이스·아키텍처·반복을 중심으로 시작·정련·구축·전이 단계의 관심사를 조직합니다. 기간을 짧게 잡거나 이름을 붙이는 것만으로 성공하지 않습니다. 담당자의 참여와 실행 증거가 필요합니다.

작은 흐름으로 차이를 관찰

examples/ch6.mjs를 실행하면 신청, 취소와 기존 ID 검사, 마감을 작은 흐름으로 확인합니다.

import assert from "node:assert/strict";
import { createSession, register, cancel, closeSession } from "../core.mjs";

// Each increment leaves an executable user flow and checks old behavior.
let meeting = createSession({ id: "book-1", title: "첫 책", capacity: 2 });
meeting = register(meeting, "min").state;
assert.deepEqual(meeting.participants, ["min"]);
console.log("increment 1 registration PASS");

meeting = cancel(meeting, "min").state;
assert.equal(register(meeting, "hana").code, "REGISTERED");
assert.equal(register(meeting, "").code, "INVALID_MEMBER");
console.log("increment 2 cancellation and regression PASS");

meeting = closeSession(meeting);
assert.equal(register(meeting, "jun").code, "CLOSED");
console.log("increment 3 closing PASS");

각 increment ... PASS는 해당 코드의 단언이 통과한 결과입니다. 전체 사용자 검토가 끝났다는 뜻은 아닙니다. 취소 정책이 바뀌면 두 번째 흐름의 수락 조건부터 수정합니다.

독립 문제: 무엇을 먼저 확인할까?

모임 앱을 외부 행사에 쓰기로 했습니다. 참가자 수는 적지만 참가비 환불 규칙이 자주 바뀌고 결제 실패의 영향이 큽니다. 순차·증분·위험 중심 접근을 어떻게 조합할지와 첫 검증의 질문을 제시하세요.

“반복 개발은 계획이 없다”거나 “폭포수는 테스트가 없다”는 설명은 틀립니다. 어떤 방식이든 목표·근거·남은 위험을 기록해야 합니다. 다음 문서는 실제 팀의 작업 규칙을 정합니다.