소프트웨어 개발 방법론

책마루는 어떤 순서로 개발해야 할까

2장에서 짚은 오해 중 하나가 "그냥 코드부터 짜면 된다"였다. 그렇다면 코드를 짜지 않는 시간에는 무엇을, 어떤 순서로 해야 할까? 이 질문에 대한 답이 바로 개발 방법론이다. 책마루 온라인 주문 시스템을 만들 때 요구사항부터 확정하고 한 번에 끝까지 갈지, 일단 화면 하나 만들어보고 사장님 반응을 볼지, 아니면 2주 단위로 조금씩 기능을 늘려갈지 — 이 선택이 프로젝트 전체의 리듬을 결정한다.

방법론은 "무엇을 어떤 기법으로 만들 것인가(개발 방법)"와 "그 개발을 어떤 절차로 통제할 것인가(개발 관리)"를 하나로 묶은 틀이다. 이번 장에서는 대표적인 방법론 여섯 갈래 — 폭포수, 원형, 나선형, 4세대 기법, 애자일(과 그 대표 격인 XP), 컴포넌트 기반 개발 — 를 책마루 프로젝트에 대입해 비교한다.

폭포수 모델 — 정해진 순서대로, 한 방향으로

폭포수 모델은 요구사항 분석 → 설계 → 구현 → 테스트 → 유지보수 순서로, 앞 단계가 끝나야 다음 단계로 넘어가는 가장 오래된 방법론이다. 각 단계의 산출물(요구사항 명세서, 설계 문서 등)이 확정되고 나서야 다음 단계가 시작된다는 점에서, 진행 상황을 관리하기가 상대적으로 쉽다는 장점이 있다.

책마루 프로젝트를 폭포수 모델로 진행한다면 이런 순서가 된다.

1. 요구사항 분석: 사장님·직원·손님의 요구를 모아 명세서로 확정
2. 설계: 주문-재고 데이터 구조, 화면 흐름을 문서로 확정
3. 구현: 확정된 설계대로 코딩
4. 테스트: 재고 차감이 정확한지, 결제가 제대로 되는지 검증
5. 유지보수: 오픈 후 발생하는 문제 대응

문제는 실제로 이 순서가 한 방향으로만 흐르지 않는다는 데 있다. 구현 단계에서 "배달 가능 지역 판단 로직이 설계와 안 맞는다"는 게 드러나면 설계 단계로 되돌아가야 한다. 그리고 무엇보다 사장님이 실제로 동작하는 화면을 보는 시점이 프로젝트 후반부라서, "생각했던 것과 다르다"는 피드백이 나오면 이미 늦은 경우가 많다. 요구사항이 처음부터 뚜렷한 소규모 프로젝트에는 잘 맞지만, 책마루처럼 사장님도 "정확히 어떤 화면이 좋을지" 확신이 없는 프로젝트에는 위험 부담이 크다.

원형 패러다임 — 일단 만들어서 보여준다

사장님이 "배달 가능 지역 표시가 어떤 모습일지 감이 안 온다"고 말한다면, 설계 문서를 백날 설명하는 것보다 화면 시제품(prototype) 하나를 보여주는 편이 빠르다. 원형 패러다임은 정식 개발에 들어가기 전에 핵심 기능만 담은 간단한 시제품을 빠르게 만들어 사용자 반응을 확인하고, 그 반응을 반영해 다시 다듬는 과정을 반복한다.

책마루라면 우편번호를 입력하면 배달 가능 여부가 뜨는 화면 하나만 먼저 만들어 사장님에게 보여줄 수 있다. 사장님은 이걸 보고서야 "배달 불가 지역은 이렇게 안내하지 말고 다른 매장으로 연결해달라"는, 애초 요구사항 명세서에는 없었던 요구를 새로 떠올릴 수 있다. 시제품은 이렇게 말로는 끌어내기 어려운 요구사항을 구체화하는 도구다.

다만 원형 패러다임에는 함정이 있다. 시제품은 빠르게 만드는 데만 초점을 맞추기 때문에 오류 처리나 성능은 대충 구현된다. 그런데 사장님 눈에는 "화면이 이미 돌아가고 있으니 거의 다 된 것 아니냐"로 보일 수 있다. 시제품과 완제품 사이의 거리를 처음부터 분명히 해두지 않으면, 완성 시점에 대한 오해가 생기기 쉽다.

나선형 모델 — 위험을 관리하며 한 바퀴씩

나선형 모델은 폭포수와 원형의 장점에 "위험 분석"이라는 요소를 더한 방법론이다. 계획 → 위험 분석 → 개발 → 고객 평가의 네 단계를 한 바퀴로 삼아, 이 나선을 여러 번 돌면서 점점 완성된 시스템에 가까워진다. 매 바퀴마다 이 프로젝트를 계속 진행할지, 여기서 멈출지를 위험 수준에 따라 판단한다는 점이 특징이다.

이 모델은 비용이 크고 실패 위험이 높은 대형 시스템(공공기관의 대규모 정보시스템 같은)에 어울리는 접근이다. 책마루처럼 예산 500만원, 8주짜리 소규모 프로젝트에 나선형 모델의 절차를 그대로 적용하면 오히려 관리 자체가 프로젝트 규모보다 무거워진다 — 매 바퀴 위험 분석 회의를 여는 데만 소규모 팀의 시간을 다 쓰게 될 수 있다. 나선형 모델을 아는 게 중요한 이유는 책마루에 쓰라는 뜻이 아니라, 프로젝트 규모와 위험 수준에 맞는 절차의 무게를 고르는 감각을 길러주기 때문이다.

4세대 기법 — 자동화가 대신해줄 수 있는 것과 없는 것

**4세대 기법(4GT)**은 요구사항을 사람이 이해할 수 있는 수준으로 정리해두면 도구가 그걸 실행 코드로 자동 생성해주는 접근이다. 데이터베이스 스키마를 정의하면 기본적인 입력·조회 화면이 자동으로 만들어지는 로우코드 도구를 떠올리면 된다. 책마루의 상품 등록·재고 관리 화면처럼 정형화된 입력·조회 기능이라면 이런 도구로 상당 부분을 절약할 수 있다.

다만 배달 가능 지역 판단처럼 책마루만의 고유한 로직이 들어가는 부분까지 자동 생성에 기대기는 어렵다. 4GT는 반복적이고 정형화된 부분의 생산성을 끌어올리는 보조 수단이지, 설계와 판단을 대신하는 만능 해법은 아니다.

애자일 방법론 — 계획보다 변화 대응

폭포수·나선형 모델은 공통적으로 "처음에 계획을 잘 세우고 그대로 실행한다"는 전제를 깐다. 애자일 방법론은 이 전제를 뒤집는다. 애자일 선언문은 이렇게 말한다.

포괄적인 문서보다 제대로 작동하는 소프트웨어에, 계약 협상보다 고객과의 협력에, 계획을 따르기보다 변화에 대응하는 것에 더 가치를 둔다.

책마루 프로젝트에 적용하면, 8주 전체 일정과 전체 기능 목록을 처음부터 완벽하게 확정하려 애쓰는 대신, 2주 단위의 **이터레이션(iteration)**을 반복하면서 "이번 2주엔 주문·장바구니만", "다음 2주엔 결제만" 하는 식으로 조금씩 완성해나간다. 매 이터레이션이 끝날 때마다 사장님에게 실제로 동작하는 화면을 보여주고 피드백을 받아 다음 이터레이션 계획에 반영한다.

기술적 부채와 리팩토링

애자일처럼 빠르게 반복하며 개발하다 보면 "일단 되게만 만들고 나중에 정리하자"는 판단을 자주 하게 된다. 이렇게 당장의 속도를 위해 미뤄둔 정리 작업을 **기술적 부채(technical debt)**라고 부른다. 책마루 시스템에서 재고 차감 로직을 급하게 짜느라 여러 화면에 똑같은 코드를 복사해 붙였다면, 이건 갚아야 할 부채를 진 셈이다. 부채이니만큼 쌓일수록 이자가 붙는다 — 나중에 재고 정책이 바뀌면 복사해둔 코드를 전부 찾아 고쳐야 하고, 하나라도 빠뜨리면 버그가 된다.

이 부채를 갚는 작업이 **리팩토링(refactoring)**이다. 겉으로 보이는 동작은 그대로 두면서 내부 코드 구조만 개선하는 작업으로, 애자일 개발에서는 별도의 일정으로 떼어두지 않고 매 이터레이션의 구현 작업 속에 자연스럽게 포함시킨다. 책마루의 중복된 재고 차감 코드라면, 여러 화면에 흩어진 로직을 하나의 공용 함수로 뽑아내는 것이 전형적인 리팩토링이다.

익스트림 프로그래밍(XP) — 애자일을 실천하는 구체적 방법

애자일이 방향을 제시하는 선언이라면, **익스트림 프로그래밍(XP)**은 그 방향을 구체적인 실천 방법으로 옮긴 것이다. XP는 의사소통·단순함·피드백·용기·존중이라는 다섯 가치를 바탕으로, "고객에게 가장 중요한 가치를 가장 빨리 전달한다"는 목표를 좇는다.

XP에서 요구사항은 두꺼운 명세서 대신 **사용자 스토리(user story)**라는 짧은 카드로 표현된다. 책마루라면 이런 식이다.

사용자 스토리는 뒤에서(11장) 다룰 유스케이스와 비슷해 보이지만 다르다. 유스케이스는 "기본 흐름 → 대안 흐름"까지 상세하게 미리 기술하는 문서인 반면, 사용자 스토리는 대화의 출발점 역할을 하는 짧은 문장일 뿐이다. 스토리 카드에 적힌 한두 줄만으로는 부족한 세부사항이, 개발자와 사장님이 그 스토리를 놓고 나누는 대화 속에서 채워진다 — "우편번호 앞 세 자리로 판단할까요, 전체 주소로 판단할까요?" 같은 질문과 답이 오가면서 요구사항이 구체화되는 식이다.

이 대화에서 나온 세부 조건은 테스트 케이스로 옮겨진다. S01 스토리라면 "지원하지 않는 우편번호를 입력하면 안내 문구가 뜬다" 같은 조건이 테스트 케이스가 된다. XP는 이 테스트 케이스를 고객과 개발자가 함께 작성하고, 개발이 끝나면 그 테스트를 통과하는지로 완료 여부를 판단한다 — 테스트가 요구사항 명세서의 역할을 대신하는 셈이다.

이 대화와 테스트 케이스 작성이 끝나면, 스토리는 다시 더 작은 작업(task) 단위로 쪼개진다. S01 스토리는 "우편번호 입력 화면 구현", "배달 가능 지역 판정 로직 구현", "미지원 지역 안내 문구 처리" 같은 작업으로 나뉘고, 개발자는 이 작업 각각에 걸리는 시간을 추정한다. 이렇게 쪼갠 작업 시간을 모두 더하면 그 스토리를 구현하는 데 걸리는 시간이 되고, 이는 다음 이터레이션에 어떤 스토리를 담을 수 있을지 판단하는 근거가 된다. 요구사항을 크게 뭉뚱그려 추정하는 폭포수식 계획과 달리, XP는 이렇게 작은 단위로 쪼개 추정하기 때문에 오차가 누적되어도 다음 이터레이션에서 바로 조정할 수 있다.

컴포넌트 기반 개발(CBD) — 부품을 조립하듯

**컴포넌트 기반 개발(CBD)**은 소프트웨어를 처음부터 다 짜지 않고, 이미 검증된 부품(컴포넌트)을 조립해서 만드는 접근이다. 컴포넌트는 잘 정의된 인터페이스만 지키면 내부 구현을 몰라도 가져다 쓸 수 있는 독립적인 단위다.

책마루 프로젝트에서 결제 기능을 예로 들면 이렇다. 결제 로직을 처음부터 직접 짜는 대신, PG사가 제공하는 결제 컴포넌트(SDK)를 가져다 붙인다. 개발팀은 그 컴포넌트 내부가 어떻게 카드 승인을 처리하는지 몰라도, "결제 요청을 보내면 승인 결과를 돌려준다"는 인터페이스만 알면 충분하다. 배달 주소 검증에 쓸 우편번호 조회 컴포넌트도 마찬가지로 외부에서 가져다 쓸 수 있다. 검증된 부품을 재사용하면 그만큼 직접 개발하고 테스트할 범위가 줄어든다 — 책마루처럼 예산과 인력이 빠듯한 프로젝트일수록 이 절약의 효과가 크다.

책마루에는 어떤 방법론이 맞을까

지금까지 살펴본 방법론 중 어느 하나가 절대적으로 우월한 건 아니다. 선택은 프로젝트의 성격에 달려 있다. 책마루처럼 예산과 기간이 짧고, 사장님도 정확한 요구사항을 처음부터 다 갖고 있지 않은 소규모 프로젝트라면, 처음엔 원형으로 화면 감을 잡고, 이후에는 애자일 방식으로 2주 단위 이터레이션을 돌며 사장님의 피드백을 계속 반영하는 조합이 현실적이다. 결제나 배달 지역 조회처럼 이미 검증된 외부 부품이 있는 영역은 CBD 방식으로 가져다 쓰고, 나선형 모델의 절차 전체를 흉내 내는 무거운 방법론은 굳이 끌어올 필요가 없다.

핵심 정리

• 방법론은 "무엇을 어떻게 만들지(개발 방법)"와 "그 과정을 어떻게 통제할지(개발 관리)"를 하나로 묶은 틀이며, 프로젝트 성격에 맞게 선택해야 한다.
• 폭포수 모델은 관리는 쉽지만 요구사항이 처음부터 뚜렷하지 않은 프로젝트에는 위험하고, 원형 패러다임은 그 위험을 시제품으로 줄여주는 대신 완성도에 대한 오해를 남길 수 있다.
• 나선형 모델은 위험 분석을 더해 대형 프로젝트에 적합하지만, 소규모 프로젝트에는 절차 자체가 무거울 수 있다.
• 애자일은 계획보다 변화 대응에 가치를 두고 짧은 이터레이션을 반복하며, 그 과정에서 쌓이는 기술적 부채는 리팩토링으로 갚아나간다.
• XP는 애자일을 사용자 스토리·테스트 케이스 같은 구체적 도구로 실천하는 방법론이고, CBD는 검증된 부품을 조립해 개발 범위 자체를 줄이는 접근이다.

다음 장(4장)에서는 이렇게 고른 방법론을 실제 프로젝트로 옮기기 위한 첫 단계 — 프로젝트를 어떻게 관리하고 착수하는지를 다룬다.