개발 프로세스 모델의 선택

진행자는 마감 뒤의 취소 정책을 아직 정하지 못했고, 운영자는 저장 오류를 가장 걱정합니다. 이런 상황에서 모든 설계를 먼저 확정하고 한 번에 구현할지, 작은 흐름을 만들어 보여 주며 하나씩 결정해 갈지 정해야 합니다. 요구, 설계, 구현, 검증, 운영 같은 활동을 어떤 순서와 주기로 진행할지 정한 방식을 개발 프로세스(software process)라 하고, 그 순서와 피드백의 관계를 단순하게 나타낸 것을 프로세스 모델(process model)이라고 합니다. 이 글에서는 대표적인 모델을 비교하되, 모델의 이름을 고르는 것보다 이 프로젝트의 불확실한 부분을 어디에서 먼저 줄일지를 기준으로 고르는 방법을 다룹니다.

단계를 차례로 밟는 순차 모델

폭포수 모델(waterfall model)은 요구 분석, 설계, 구현, 테스트를 차례로 진행하면서, 각 단계의 산출물을 검토하고 승인한 뒤 다음 단계로 넘어가는 방식입니다. 규칙이 비교적 안정되어 있고 단계마다 승인 기록을 남기는 것이 중요한 프로젝트에서는 계획을 분명하게 세울 수 있다는 장점이 있습니다. 반면 취소 정책처럼 중요한 요구를 늦게 알게 되면 요구, 설계, 테스트를 함께 고쳐야 해 비용이 커집니다. 실제로 순차 모델을 쓰는 팀도 뒤 단계에서 찾은 오류나 변경을 앞 단계로 되돌려 보내며 진행합니다.

V 모델(V-model)은 개발의 각 단계를 그 결과를 확인하는 검증 단계와 짝지어, 왼쪽으로 내려가며 만들고 오른쪽으로 올라가며 확인하는 V자 모양으로 나타냅니다. 이렇게 짝을 지어 두면 테스트를 개발이 끝난 뒤에야 처음 생각하는 일을 막을 수 있습니다.

다만 V자 모양으로 계획을 세웠다고 요구의 오류가 저절로 드러나는 것은 아니며, V 모델을 쓴다고 반복해서 개발할 수 없는 것도 아닙니다. 짝지은 검증을 실제로 준비하고 실행해야 그 효과를 얻습니다.

더 깊이: 폭포수 모델의 원전은 한 번에 끝내라고 하지 않았다

폭포수 모델의 출발점으로 흔히 꼽히는 글은 Winston W. Royce가 1970년 8월 IEEE WESCON에서 발표한 "Managing the Development of Large Software Systems"입니다. 그런데 이 논문에는 '폭포수'라는 말이 나오지 않고, 단계를 한 번씩 차례로 밟는 그림을 그린 바로 뒤에 Royce는 그 개념을 믿지만 그대로 구현하는 것은 위험하고 실패를 부른다고 적습니다. 타이밍과 저장 공간 같은 문제는 개발의 끝인 테스트 단계에서야 처음 실제로 겪게 되고, 그때 요구를 어기는 문제가 드러나면 설계를 크게 바꾸어야 해서 일정과 비용이 100%까지 넘칠 수 있다는 것이 이유였습니다.

Royce는 이 위험을 줄이려고 기본 방식에 다섯 가지를 더하라고 제안합니다. 설계를 먼저 하고, 설계를 문서로 충분히 남기고, 처음 만드는 시스템이라면 핵심 부분을 작은 규모로 한 번 먼저 만들어 보는 "두 번 하라(do it twice)", 테스트를 계획하고 관리하고, 고객을 정해진 시점마다 공식적으로 참여시키라는 것입니다. 원전이 이미 앞 단계로 돌아가는 피드백과 시제품, 고객의 참여를 강조했다는 점에서, 폭포수 모델을 "한 번에 끝까지 내려가는 방식"으로만 기억하는 것은 원래의 주장과 다릅니다.

조금씩 쌓고 다듬는 방식

증분 개발(incremental development)은 신청, 취소, 저장처럼 쓸 수 있는 기능을 조금씩 더해 가는 방식이고, 반복 개발(iterative development)은 이미 만든 부분을 피드백을 받아 여러 번 다듬는 방식입니다. 신청 안내를 먼저 만들어 보여 주고, 사용자가 잘못 이해한 부분을 보고 문구를 고치는 것은 반복이고, 그 뒤에 취소 기능을 더하는 것은 증분입니다. 두 방식은 함께 쓰는 경우가 많습니다.

프로토타입(prototype)은 불확실한 질문에 답하려고 빠르게 만드는 시제품입니다. 예를 들어 화면 목업을 보여 주며 "마감 뒤에도 취소할 수 있습니다"라는 안내를 사용자가 이해하는지 확인할 수 있습니다. 확인이 끝나면 버리는 폐기형 프로토타입인지, 다듬어 실제 제품으로 키워 갈 진화형 프로토타입인지를 처음에 정해 두어야 합니다. 저장, 보안, 오류 처리를 대충 만든 시제품을 그대로 운영에 쓰면 그 빈틈이 그대로 제품의 결함이 되기 때문입니다.

위험을 먼저 줄이는 모델과 그 밖의 모델

나선형 모델(spiral model)은 개발을 여러 번의 주기로 나누고, 주기마다 목표와 대안을 정한 뒤 가장 큰 위험을 분석하고 줄이는 활동을 먼저 하도록 강조합니다. 실제로 서비스할 모임 앱이라면 여러 사람이 동시에 신청하는 상황이나 장애 뒤의 복구를 먼저 시험해 볼 이유가 있습니다. 이 교재의 예제는 프로세스 하나에서 차례로 실행되므로 그런 위험을 해결했다고 말할 수 없습니다.

RAD(rapid application development)는 개발 기간을 짧게 정해 두고 사용자를 적극적으로 참여시키며, 재사용할 수 있는 부품과 도구로 빠르게 만드는 접근입니다. 통합 프로세스(unified process, UP)는 유스케이스를 중심으로 요구를 다루고 아키텍처를 일찍 정하며 반복해서 개발하는 방식으로, 전체 과정을 도입(inception), 정련(elaboration), 구축(construction), 전이(transition)의 네 단계로 나눕니다. 어느 모델이든 기간을 짧게 잡거나 이름을 붙이는 것만으로는 성공하지 않으며, 사용자가 실제로 참여하고 각 단계의 결과를 실행해 확인해야 합니다.

불확실한 질문에 맞추어 검증을 고른다

모델을 고를 때는 먼저 이 프로젝트에서 아직 모르는 것이 무엇인지 적어 봅니다. 아래 그림은 아직 정하지 않은 취소 정책과 저장 실패라는 서로 다른 두 질문을 찾고, 질문마다 알맞은 작은 검증을 고른 뒤, 확인한 것과 아직 남은 위험을 나누어 다음 작업을 정하는 과정을 보여 줍니다.

정책에 대한 질문은 사용자의 반응을 보아야 답할 수 있으므로 프로토타입 검토가 어울리고, 저장 실패라는 기술 위험은 오류를 일으켜 보는 작은 통합 실험이 어울립니다. 이처럼 프로젝트 하나에서도 질문마다 알맞은 방식이 다를 수 있습니다. 상황에 따라 어울리는 방식을 정리하면 다음과 같습니다.

증분마다 실행할 수 있는 흐름을 남긴다

증분 개발에서는 증분 하나가 끝날 때마다 실행해 확인할 수 있는 흐름이 남아 있어야 합니다. 다음 코드는 신청, 취소, 마감을 세 증분으로 보고, 각 증분이 끝날 때의 흐름과 앞서 만든 기능을 함께 확인합니다. reading-lab/examples/ch6-1.mjs로 저장해 실행합니다.

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

// 증분 1: 신청
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");

// 증분 2: 취소, 그리고 앞서 만든 신청 규칙의 회귀 확인
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");

// 증분 3: 마감
meeting = closeSession(meeting);
assert.equal(register(meeting, "jun").code, "CLOSED");
console.log("increment 3 closing PASS");

increment 1 registration PASS
increment 2 cancellation and regression PASS
increment 3 closing PASS

둘째 증분은 취소한 자리에 새 신청을 받는지 확인하면서, 첫째 증분에서 만든 아이디 형식 검사가 여전히 동작하는지도 함께 확인합니다. 증분을 더할 때마다 앞의 증분을 다시 확인하는 이 습관이 통합·인수·회귀 테스트의 회귀 테스트입니다. 각 줄의 PASS는 그 증분의 단언이 모두 통과했다는 뜻일 뿐, 진행자가 결과를 검토해 받아들였다는 뜻은 아닙니다. 나중에 취소 정책이 바뀐다면 둘째 증분의 수락 조건부터 고쳐 나갑니다.

정리

• 개발 프로세스는 개발 활동의 순서와 주기를 정한 방식이고, 프로세스 모델은 그 순서와 피드백을 단순하게 나타낸 것입니다.
• 폭포수 모델은 단계별 승인을, V 모델은 개발 단계와 검증 단계의 짝을 강조하며, 둘 다 실제로는 앞 단계로 돌아가는 피드백이 있습니다.
• 증분 개발은 기능을 조금씩 더하고 반복 개발은 같은 부분을 여러 번 다듬으며, 프로토타입은 폐기형인지 진화형인지 먼저 정합니다.
• 나선형 모델은 주기마다 가장 큰 위험을 먼저 줄이며, RAD와 통합 프로세스도 이름이 아니라 실제 참여와 실행 결과로 효과를 냅니다.
• 모델은 프로젝트에서 아직 모르는 질문과 큰 위험을 기준으로 고르고, 질문마다 다른 방식을 함께 쓸 수 있습니다.

연습 문제

1. 무엇을 먼저 확인할까

모임 앱을 참가비를 받는 외부 행사에 쓰기로 했습니다. 참가자는 많지 않지만 환불 규칙이 자주 바뀌고, 결제가 실패했을 때의 피해가 큽니다. 순차, 증분, 위험 중심의 방식을 어떻게 섞을지 제안하고, 가장 먼저 확인할 질문을 적으세요.

2. 두 프로젝트의 모델 고르기

다음 두 프로젝트에 어울리는 방식을 고르고 이유를 설명하세요. 첫째는 학교 규정으로 정해진 성적 처리 규칙을 그대로 옮기는 프로그램으로, 감사를 위해 단계별 승인 기록이 필요합니다. 둘째는 새로 만드는 동아리 앱으로, 회원들이 어떤 기능을 자주 쓸지 아무도 모릅니다.

3. 흔한 오해 바로잡기

"반복 개발은 계획 없이 만드는 것이다", "폭포수 모델에는 테스트가 없다"는 두 설명이 왜 틀렸는지 설명하세요.

어떤 모델을 고르든, 실제 팀은 기능을 어떻게 나누고 언제 검토할지 같은 작업 규칙을 정해야 합니다. 다음 글 방법론과 반복 개발에서는 분석과 설계의 관점, 애자일과 스크럼의 작업 단위, 반복을 기록하는 방법을 다룹니다.