예측형·반복형·점증형·애자일

1. 같은 예약 서비스를 만들어도 일하는 순서는 달라진다

동네 공방이 전화로 받던 수업 예약을 웹으로 옮기려 한다. 수업 정원과 취소 기한은 이미 정해져 있지만, 고객이 날짜를 먼저 고를지 수업을 먼저 고를지는 아직 모른다. 외부 결제회사와 연결했을 때 중복 결제가 생기지 않을지도 확인해야 한다. 한 프로젝트 안에도 확실한 규칙, 써 보아야 알 수 있는 경험, 기술적으로 먼저 확인할 위험이 함께 있다.

모든 내용을 처음부터 확정하려 하면 화면에 대한 추측을 너무 오래 믿게 된다. 그렇다고 매일 떠오른 생각대로 바꾸면 정원·결제 규칙과 약속한 개업일을 지키기 어렵다. 개발 방법론을 고른다는 것은 이 차이를 보고 무엇을 먼저 정하고, 무엇을 작게 확인하며, 어떤 증거가 있어야 다음 일을 허용할지 정하는 일이다.

먼저 기억할 세 가지

생명주기는 필요 발견부터 개발·운영·변경·종료까지 이어지며, 단계 이름이 일방통행을 강제하지 않는다는 기초는 분석·설계·구현·시험·운영·변경에서 배웠다. 요구는 확인할 수 있는 약속이고, 명세 준수와 실제 필요 충족은 서로 다른 질문이다(이해관계자·문제·요구사항, 검증·확인·운영 피드백). 분석·설계·구현·시험·운영·변경에서 배운 순차·반복·증분을 여기서는 실제 개발 순서와 변경 권한을 고르는 데 적용한다.

방법론은 활동·역할·산출물·판단기준을 함께 정한다

이 교재에서 사용하는 정의는 다음과 같다. 소프트웨어 개발 방법론은 주어진 목표와 제약 안에서 개발활동, 역할, 산출물, 적용 기법과 검토·변경 규칙을 조직하는 체계다. 무엇을 만들지뿐 아니라 누가 결정하고 어떤 증거를 남기며 잘못된 가정을 어떻게 고칠지를 정한다. 방법론을 선택했다면 이름만 적지 말고 우리 프로젝트의 실제 절차와 책임으로 구체화해야 한다.

공방 사례에서는 고객이 날짜를 고르는 흐름은 먼저 확인하고, 결제 결과를 판단하는 기준과 책임자는 개발 전에 정할 수 있다. 짧게 반복한다는 표현만으로는 확인 주기나 변경 권한이 정해지지 않는다. 고객 반응을 2주마다 확인하고, 가격·환불 규칙을 바꿀 때에는 운영 책임자가 영향과 시험 결과를 검토한다까지 내려가야 실행 가능한 선택이 된다. 이 주기는 사례의 선택값이지 모든 개발의 정답은 아니다.

생명주기·프로세스·방법론·프레임워크는 같은 말이 아니다

프로세스(process)는 어떤 입력을 받아 활동을 수행하고 정해진 결과를 만드는 절차다. 여기서는 운영체제의 실행 중인 프로그램을 뜻하는 프로세스와 다르다. 예를 들어 변경 요청을 받아 영향을 분석하고 채택 여부를 정하는 것은 변경 처리 프로세스다. 프레임워크(framework)는 함께 일하는 데 필요한 최소 구조와 규칙을 제시하고 세부 기법을 채울 여지를 남기는 틀이다. 이 절의 프레임워크는 개발팀 운영의 틀이며 웹 프로그램용 라이브러리라는 뜻이 아니다.

실무 자료는 이 말을 넓게 섞어 쓰기도 한다. 이 교재는 이름을 억지로 하나의 계층에 끼워 넣기보다 대상과 역할을 구분한다. 팀 운영 프레임워크를 선택해도 요구 분석 기법, 구체적인 시험 방법, 접근권한 설계가 저절로 정해지는 것은 아니다.

전체 흐름: 불확실성을 확인할 수 있는 약속으로 바꾼다

위 표의 마지막 연결은 관찰 결과에 따라 다음 계획과 작업 방식을 수정한다는 뜻이다. 일을 처음부터 무조건 반복한다는 뜻은 아니다. 고객이 날짜 선택에서 막혔다는 증거가 나오면 화면 가정을 고치고, 결제 중복이 나타나면 결제 처리의 원인과 검증 조건을 고친다. 확인한 사실이 다음 결정의 어느 부분을 바꾸는지가 중요하다.

2. 예측·반복·점증을 한 줄의 반대말로 놓지 않는다

예측형(predictive)은 앞에서 비교적 많은 범위와 실행계획을 정하고 그 기준으로 진행을 통제하는 접근이다. 적응형(adaptive)은 관찰한 결과를 바탕으로 상세 범위와 계획을 짧은 주기로 조정하는 접근이다. 둘의 차이는 계획의 유무가 아니라, 무엇을 언제 얼마나 상세하게 정하고 어떤 증거로 고치느냐에 있다.

반복은 같은 문제나 결과를 다시 살펴 더 잘 이해하고 다듬는 것이고, 점증은 사용 가능한 기능을 누적해 제품의 능력을 넓히는 것이다. 반복·증분의 기초 뜻은 분석·설계·구현·시험·운영·변경을 따른다. 이 교재에서 점증과 증분은 기능을 나누어 누적한다는 같은 맥락의 표현으로 사용한다.

따라서 계획을 먼저 세우고도 여러 증분을 낼 수 있고, 한 증분을 완성하는 동안 여러 번 반복할 수 있다. 단지 매주 회의를 한다고 반복 개발인 것은 아니며, 화면 파일과 서버 코드를 따로 넘겼다고 고객이 쓸 수 있는 점증을 전달한 것도 아니다.

화면을 다시 그리는 일과 기능을 더하는 일

먼저 같은 날짜 선택 화면을 고객 반응에 따라 두 번 고쳤다고 하자. 이해하기 쉬워졌지만 고객이 할 수 있는 일의 범위는 여전히 날짜 선택 하나다. 이는 반복의 예다. 그다음 확정된 수업에 예약을 접수하고 접수 결과를 확인할 수 있게 했다면 제품에 사용할 수 있는 능력이 하나 더해진 점증이다.

사용자 흐름을 끝까지 잇는 작은 기능 조각(vertical slice)은 화면·처리·데이터를 관통해 하나의 사용자 목적을 수행하는 단위다. 공방에서는 수업 하나를 골라 예약하고 내 예약을 확인한다가 작은 기능 조각이 될 수 있다. 버튼만 보이고 예약이 저장되지 않는 결과는 그 목적을 수행하지 못한다. 공개 배포 여부는 별도 판단이지만, 내부 확인용 증분도 자신이 목표로 한 흐름과 품질 기준을 만족해야 한다.

반복에만 머물면 계속 모양을 고치면서 가치를 전달하지 못할 수 있다. 점증만 서두르면 앞 기능과 새 기능의 데이터·규칙이 맞지 않을 수 있다. 다음 반복의 질문과 다음 증분의 사용자 목적을 각각 적으면 두 위험을 구분할 수 있다.

폭포수: 큰 단계의 증거를 확인하고 다음 단계로 이동한다

폭포수 모델(waterfall model)은 요구·설계·구현·시험 같은 큰 단계의 결과를 정리한 뒤 다음 단계로 진행하는 순차적 생명주기 모델이다. 단계 전환 관문(phase gate)은 다음 단계로 넘어갈 준비가 되었는지 검토하고 판단하는 지점이다. 그 판단에 필요한 증거와 통과 조건이 단계 전환 기준이다. 형상 기준선(configuration baseline)은 검토를 거쳐 이후 변경을 통제하기로 한 산출물 집합의 특정 버전이다. 이는 성능 비교에 쓰는 측정 기준선과 용도가 다르다.

정원·취소 규칙이 안정적이고 계약 상대에게 요구와 시험 결과를 단계별로 인계해야 하는 부분에서는 이 구분이 도움이 된다. 승인된 규칙과 시험 기준이 있으므로 변경 전후에 무엇이 달라졌는지 확인하기 쉽다. 다만 승인 도장이 실제 요구의 정확성을 보증하지는 않는다. 날짜 선택처럼 직접 써 보아야 알 수 있는 부분을 문서만 승인한 채 마지막에 확인하면 잘못된 가정을 오래 유지한다.

폭포수의 단계 간 검토와 통제된 되돌아감은 가능하다. 요구를 바꿀 때에는 영향을 받는 설계·구현·시험을 찾아 다시 확인한다. 앞 단계는 절대로 수정할 수 없다는 설명도, 고객 확인은 마지막에 한 번이면 된다는 설명도 선택과 통제의 조건을 놓친다.

V 모델: 정의한 단계에서 확인할 증거도 함께 준비한다

V 모델(V-model)은 요구와 설계를 구체화하는 쪽과 구현 결과를 조립·확인하는 쪽을 대응시켜 개발과 검증의 추적관계를 강조하는 모델이다. 아래는 소프트웨어 사례를 위해 직접 구성한 대응도다. 프로젝트의 분해 수준과 용어는 달라질 수 있으므로 모든 조직이 반드시 이 네 쌍을 써야 한다는 뜻은 아니다.

화살표의 방향과 조건을 따라 연결을 읽습니다.

점선은 같은 행의 정의와 확인 증거가 대응한다는 뜻이다. 시간 흐름이나 모든 시험을 구현 뒤로 미루라는 뜻이 아니다. 본문의 개발·확인 설명과 함께 읽는다.

왼쪽에서 정원이 차면 추가 예약을 막는다를 정할 때 오른쪽에서 어떤 입력과 결과로 확인할지도 준비한다. 구성요소 간 설계에서는 예약 처리와 결제 처리의 연결 실패를 어떻게 관찰할지 정한다. 개별 동작의 확인은 작은 함수 등의 동작을, 연결 확인은 여러 요소 사이의 상호작용을, 전체 확인은 통합된 서비스의 요구를 대상으로 한다. 시험 설계의 상세 기법은 뒤 시험 장에서 다룬다.

그림의 가로선은 요구와 증거의 대응관계이며 테스트를 전부 구현 뒤에 생각하라는 시간표가 아니다. 왼쪽 활동 중에도 검토·분석·필요한 일부를 먼저 만들어 보는 평가를 할 수 있고, 작은 증분 안에서도 같은 대응을 유지할 수 있다. 모든 시험이 통과했지만 고객의 예약 목적 자체가 빠져 있다면 올바른 제품이라고 결론 낼 수 없다는 점도 검증·확인·운영 피드백의 검증·확인 구분과 같다.

나선형: 다음 행동은 큰 위험을 줄일 수 있어야 한다

나선형 모델(spiral model)은 목표와 대안·제약을 정하고, 위험을 분석·줄인 다음, 필요한 결과를 개발·검증하고 다음 진행을 판단하는 과정을 반복하는 위험 중심 모델이다. 위험을 확인하는 데 쓰는 시제품(prototype)은 어떤 가정을 시험하기 위해 필요한 부분을 먼저 만든 결과물이다. 시제품을 운영용 제품으로 계속 사용할지는 품질과 목적을 따져 별도로 정한다.

공방 팀의 가장 큰 위험이 중복 결제라면 화면을 먼저 모두 만드는 것보다 결제 요청과 응답이 끊기는 조건을 작은 시험으로 확인하는 편이 낫다. 시험 결과가 안전하게 처리할 수 있다는 근거가 되면 그 방식을 설계에 반영한다. 근거가 부족하면 대안을 바꾸거나 범위를 줄이며, 위험을 감당할 수 없다면 진행을 중단하는 판단도 가능하다.

나선형은 같은 폭포수 단계를 원형으로 그린 그림과 다르다. 위험에 따라 문서 검토, 시제품, 계산, 실제 개발 중 다음 활동이 달라진다. 위험을 평가할 전문성이 없거나 시제품만 계속 만들면서 다음 투자·진행 조건을 정하지 않으면 비용을 쓰고도 불확실성이 줄지 않는다.

세 모델을 가르는 질문은 통제의 중심이다

폭포수의 단계 검토에 V 모델의 대응관계를 넣거나, 큰 기술 위험을 먼저 줄인 뒤 점증 개발을 진행할 수 있다. 다만 여러 이름을 붙였다는 이유만으로 통제가 강화되지는 않는다. 결제 방식이 바뀌었을 때 누가 요구와 시험 기준을 함께 고치는지까지 연결되어야 한다.

3. 애자일은 계획을 버리는 것이 아니라 학습으로 계획을 고친다

공방 고객이 날짜 선택을 자꾸 되돌린다는 사실을 알게 됐다. 계획에 적혔다는 이유만으로 불편한 화면을 지키기보다는 고객과 원인을 확인하고 다음 결과를 바꾸는 편이 목적에 맞다. 애자일(agile)은 작동하는 결과와 사람 간 협력에서 얻은 피드백을 이용해 변화에 대응하고 가치를 지속적으로 전달하려는 가치·원칙 중심의 접근이다. 특정 회의 하나나 단일 생명주기 모델의 이름이 아니다.

2001년 애자일 선언의 네 가치 비교를 이 교재의 말로 정리하면 다음과 같다. 오른쪽 대상을 무가치하다고 버리는 선언이 아니라, 판단이 충돌할 때 무엇에 더 무게를 두는지에 대한 비교다.

따라서 애자일을 선택해도 필요한 설계·시험·운영 문서와 계약 책임은 남는다. 어떤 문서가 누구의 결정과 유지보수에 필요한지를 따져 적절한 깊이로 작성한다. 빠르게 만든다와 검토 없이 만든다는 다른 말이다.

열두 원칙도 결국 결과·협력·지속성으로 이어진다

선언의 열두 원칙은 네 가치가 일하는 방식으로 나타나야 한다는 뜻이다. 아래 묶음은 원문의 순서를 옮긴 목록이 아니라 회독을 위한 해설이며, 괄호 숫자는 원칙의 원래 순서다.

직접 대화를 중시한 역사적 문구가 원격 협업을 금지한다는 뜻은 아니다. 이 사례에서 중요한 것은 질문에 답이 돌아오고 오해가 풀리는지다. 단순함 역시 반드시 필요한 안전·품질 통제를 빼라는 뜻이 아니라 목적에 기여하지 않는 일을 줄이라는 뜻으로 읽는다.

Scrum: 관찰하고 고치는 일을 빠뜨리지 않게 하는 틀

스크럼(Scrum)은 복잡한 문제에서 가치를 만들기 위해 작은 결과를 확인하고 적응하도록 책임·이벤트·산출물을 정한 경량 프레임워크다. 애자일의 동의어가 아니며 애자일 가치만으로 Scrum의 구체적인 규칙이 모두 결정되는 것도 아니다. 본 절의 Scrum 사실 기준은 2026-09-05에 확인한 공식 Scrum Guide 2020년 11월판이다.

경험주의(empiricism)는 실제 경험과 관찰을 지식·결정의 근거로 삼는 생각이다. Scrum에서는 사실을 함께 볼 수 있게 하는 투명성, 그 결과를 살피는 검사, 배운 사실에 맞춰 행동을 고치는 적응이 연결된다. 예컨대 시험이 끝나지 않은 예약 기능을 완료라고 보고하면 첫 단계인 투명성이 무너져 다음 계획도 잘못된다.

린 사고(lean thinking)는 불필요한 낭비를 줄여 본질적인 가치에 집중하려는 사고다. 공방 팀이 이미 합의한 같은 규칙을 여러 문서에 중복 입력하느라 실제 예약 확인을 미룬다면 무엇이 목적에 기여하는지 돌아볼 수 있다. 필요한 시험을 생략하는 것과 불필요한 중복 작업을 줄이는 것은 다르다.

팀의 약속에 책임지는 태도, 목표에 집중하기, 문제를 숨기지 않기, 서로의 전문성을 존중하기, 어려운 문제를 드러낼 용기는 이 흐름을 지탱한다. 각각 Scrum의 약속·집중·개방·존중·용기라는 다섯 가치에 해당한다. 이름을 외우는 것보다 중복 결제 문제가 드러났을 때 숨기지 않고 함께 해결하는 장면을 떠올리는 편이 정확하다.

Sprint는 회의가 아니라 결과를 만드는 짧은 기간이다

스프린트(Sprint)는 한 달 이하로 길이를 정하고 목표를 향해 필요한 일을 수행하는 기간이다. 공방 팀은 2주를 선택할 수 있지만 2주는 Scrum 전체에 강제되는 규칙이 아니다. 스프린트 안에 계획·개발·확인·개선이 포함되며, 한 스프린트가 끝나면 다음 스프린트가 이어진다.

Scrum Team은 제품의 가치 있는 결과를 함께 책임지는 한 팀이다. 결과에 필요한 전문성을 함께 갖추고 누가 무엇을 언제 어떻게 할지를 내부에서 조정한다. Guide는 의사소통 가능한 작은 팀을 강조하며 보통 10명 이하를 제시한다. 숫자만 맞추는 것보다 외부 팀의 끝없는 인계를 기다리지 않고 필요한 결과를 만들 수 있는지가 중요하다.

예약 화면을 만드는 주, 서버를 만드는 주, 시험만 하는 주를 서로 다른 스프린트로 정해 놓고 각각 완료라고 부르면 이 취지를 놓친다. 매 스프린트에는 사용할 수 있는 결과를 향한 설계·구현·검증이 함께 필요하다.

이 팀의 책무(accountability)는 어떤 활동을 맡는 데서 그치지 않고 결과에 책임진다는 뜻이다. 정리 작업 일부를 다른 사람에게 맡겨도 최종 결과에 답할 책임은 남는다. 다음의 세 구분은 세 직급을 만드는 것이 아니라 그 결과 책임을 분명하게 하는 구분이다.

결정의 책임은 서로 다르지만 상하 지시 계층은 아니다

Product Owner(제품 책임자)는 제품 가치의 극대화와 제품에 필요한 일의 효과적인 관리에 책임진다. Developers(개발을 수행하는 구성원들)은 사용할 수 있는 결과를 만들기 위해 계획하고 품질을 지키며 매일 작업을 조정한다. Scrum Master(스크럼 마스터)는 Scrum을 이해하고 제대로 적용하도록 돕고 팀의 효과성을 높이는 데 책임진다. 여기서 Developers는 프로그래머 직함만을 뜻하지 않는다. 한 Scrum Team은 Product Owner 한 명, Scrum Master 한 명과 Developers로 구성된다.

공방의 취소 기능을 먼저 할지 알림 기능을 먼저 할지에는 제품 가치의 판단이 필요하다. 선택한 기능을 어떻게 안전하게 만들지는 작업하는 구성원이 결정하며, 규칙 질문이 답 없이 며칠씩 막히면 Scrum Master가 장애를 해소하도록 돕는다. Scrum Master를 작업을 일일이 배정하는 상사로 설명하면 스스로 계획을 조정하는 구조와 충돌한다.

2020 Guide가 강조하는 것은 직함보다 결과에 대한 책무다. Product Owner가 정리 작업 일부를 다른 사람에게 맡길 수 있어도 제품 가치와 목록 관리에 대한 책무까지 넘기는 것은 아니다.

전체 제품에서 지금 무엇을 향하고 있는가

Product Backlog(제품 백로그)는 제품을 개선하는 데 필요한 일을 순서 있게 관리하는, 계속 발전하는 목록이다. 단순한 기능 희망사항만이 아니라 결함 수정이나 품질 개선처럼 제품에 필요한 일도 다룬다. Product Goal(제품 목표)는 팀이 계획의 기준으로 삼을 제품의 미래 상태이며 Product Backlog에 연결되는 약속이다.

공방의 제품 목표를 고객이 전화 없이 정원을 확인하고 예약을 확정할 수 있다로 정했다면 수업 조회, 정원 반영, 예약 결과 안내가 그 목표를 향한 후보가 된다. 제품 목표는 모든 세부 기능을 처음부터 확정한 명세가 아니다. Guide에서는 한 제품 목표를 달성하거나 포기한 뒤 다음 목표로 나아가도록 초점을 유지한다.

이번 기간의 목적과 실행계획을 구분한다

Sprint Goal(스프린트 목표)는 해당 스프린트가 달성하려는 하나의 목적이다. Sprint Backlog(스프린트 백로그)는 스프린트 목표, 선택한 Product Backlog 항목, 이를 결과로 만들 실행계획의 묶음이다. Developers가 사용하는 살아 있는 계획이며 배운 사실에 따라 바뀔 수 있다.

예약 가능 여부를 보고 한 건을 확정한다는 목적과 버튼을 세 개 만든다는 작업 목록은 다르다. 화면 표현을 바꾸어도 같은 예약 목적을 더 잘 달성할 수 있다면 세부 작업을 조정할 여지가 있다. 반대로 한꺼번에 판매자 정산까지 넣어 원래 목표를 위태롭게 만들면 단순한 계획 개선이라고 볼 수 없다.

달력이 끝났다고 제품이 완료되는 것은 아니다

Increment(스크럼의 증분)은 기존 결과와 함께 작동하고 사용할 수 있는, 제품 목표를 향한 구체적인 진전이다. 일반적인 점증의 뜻에 더하여 Scrum에서는 품질 기준을 충족해야 한다. Definition of Done(완료의 정의, DoD)는 증분에 요구되는 품질 상태를 모두가 같은 뜻으로 이해하도록 명시한 기준이다.

공방 팀은 정원 초과 방지, 결제 연결 확인, 필요한 접근권한과 시험 증거를 완료 기준에 포함할 수 있다. 이는 사례의 구체적인 품질 조건이며 Guide가 모든 제품에 똑같은 시험 목록을 지정한다는 뜻은 아니다. 제품에 조직의 완료 기준이 있다면 적어도 그 기준을 지켜야 한다.

세 산출물은 각각 초점을 주는 약속과 연결된다. 아래의 목표·품질 조건을 함께 보아야 목록의 항목 수가 실제 진척을 대신하지 않는다.

하나의 스프린트 안에서 여러 증분이 생길 수 있으며, 사용할 수 있는 결과를 기간 종료 전에 전달할 수도 있다. 기준 미충족 작업을 거의 완료라는 이유로 증분에 포함해서는 안 된다. 고객에게 언제 공개할지와 품질 기준을 만족했는지는 관련되지만 같은 질문은 아니다.

계획과 매일의 확인은 무엇을 결정하는가

Sprint Planning(스프린트 계획)에서는 이번 일이 왜 가치 있는지, 무엇을 할 수 있는지, 어떻게 결과를 만들지를 함께 정한다. 그 결과가 목표를 포함한 Sprint Backlog다. Product Owner가 준비한 가치 판단과 Developers가 파악한 작업 가능량이 함께 필요하다.

Daily Scrum(데일리 스크럼)은 Developers가 스프린트의 각 근무일에 같은 시각·장소에서 15분 동안 목표를 향한 진행을 살피고 다음 작업을 조정하는 이벤트다. 휴일을 포함한 모든 달력 날짜에 개최한다는 뜻은 아니다. 공방 팀이 결제회사의 시험 응답을 못 받아 확인이 막혔으니 다른 작업보다 이 연결을 먼저 풀자고 결정하면 목적에 맞다. 상사에게 각자의 바쁜 정도만 보고하고 계획은 그대로 두면 형식만 남는다.

Daily Scrum 이외의 시간에 계획을 조정하거나 더 자세히 논의해도 된다. 매일 정해진 세 질문에 답해야 한다는 형식을 현행 Guide의 필수 규칙으로 외우지 않는다. 중요한 것은 목표에 대한 관찰이 실행 가능한 다음 행동으로 이어지는지다.

결과 검토와 일하는 방식의 개선은 대상이 다르다

Sprint Review(스프린트 리뷰)는 팀과 이해관계자가 결과와 환경 변화를 살피며 다음 제품 방향을 조정하는 자리다. 예약 기능을 함께 보며 취소 가능 시간이 잘 안 보인다는 사실을 발견하면 다음 제품 작업의 우선순위가 바뀔 수 있다. Review는 발표만 하는 자리가 아니며 제품 전달을 허가하는 필수 관문도 아니다.

Sprint Retrospective(스프린트 회고)는 팀이 협력·절차·도구·완료 기준 등을 살피고 품질과 효과성을 개선하는 자리다. 공방 팀이 취소 규칙 질문을 마지막 날에야 해서 시험이 늦었다고 확인하고 다음에는 작업 전에 질문을 풀기로 하는 것은 회고의 결과다. 고객이 어떤 기능을 원하는가와 팀이 어떻게 더 잘 일할 것인가를 구분한다.

Product Backlog refinement(제품 백로그 정제)는 작업 후보를 작고 명확하게 나누고 설명·순서·크기 등을 더 구체화하는 계속된 활동이다. 다음 예약 취소 기능의 규칙을 미리 확인하는 일이 그 예다. 공식적인 별도 여섯 번째 이벤트가 아니다.

Scrum의 다섯 이벤트는 Sprint 자체와 Planning·Daily Scrum·Review·Retrospective다. 한 달 Sprint의 Planning은 최대 8시간, Review는 최대 4시간, Retrospective는 최대 3시간이며 더 짧은 Sprint에서는 보통 더 짧게 한다. 이 상한은 그만큼 반드시 회의하라는 목표가 아니다.

4. 변경을 받는 것과 변경에 끌려다니는 것은 다르다

스프린트 도중 공방 운영자가 날짜 선택 순서를 바꾸자고 요청했다고 하자. 팀은 먼저 고객의 예약 목적을 더 잘 달성하는지, 현재 작업·시험에 어떤 영향이 있는지를 본다. Sprint Goal을 지키면서 해결할 수 있다면 Product Owner와 Developers가 범위를 협의하여 계획을 조정한다. 필요하면 덜 중요한 세부 작업을 뒤로 미룬다.

현재 목표를 위태롭게 하는 새 기능은 Product Backlog에서 다른 후보와 함께 순서를 판단한다. 스프린트 중에는 목표를 위태롭게 하는 변경을 하지 않고 품질을 낮추지 않는다. 목표 자체가 더는 의미 없어진 경우에는 Product Owner만 스프린트를 취소할 권한이 있다. 이는 요청이 마음에 들지 않으면 마음대로 취소한다는 뜻이 아니다.

가격·환불 규칙처럼 이미 합의한 제약을 바꾸려면 해당 결정 권한자와 영향받는 문서·설계·시험을 함께 확인한다. 이 사례의 사업 규칙 승인 절차는 Scrum이 정한 추가 직책이나 이벤트가 아니라 조직이 채워야 할 통제다. Scrum의 권한과 조직의 계약·법적 책임을 혼동하지 않아야 한다. 요구 변경의 상세 추적은 요구 도출·분석·명세·검증·추적에서 이어진다.

통제는 줄이는 것이 아니라 제때 작동하게 배치한다

두 열 모두 책임·증거·변경 기록이 필요하다. 왼쪽도 학습을 반영할 수 있고 오른쪽도 먼저 고정해야 할 규칙이 있다. 개발 방법을 선택할 때에는 어느 통제를 언제 누구에게 적용할지까지 설명한다.

이름은 맞는데 결과가 나빠지는 네 장면

공방이 회의를 빠짐없이 했다는 보고를 받았지만 고객 예약은 여전히 실패할 수 있다. 행사 수는 통제가 작동했다는 증거가 아니다. 다음 표의 관찰값은 사례에 맞춘 편집 예시이며 모든 프로젝트에 같은 숫자를 강제하는 표준 지표가 아니다.

이 사례에서 진척은 고객이 끝까지 예약할 수 있는가와 그 기능의 품질 증거로 확인한다. 개선 효과를 보려면 예약 시작 대비 완료 비율, 사용 중 실패 건수, 완료로 표시했다가 다시 열린 작업과 질문의 대기시간을 함께 볼 수 있다. 관찰 기간·대상·측정 방법을 맞추어 해석해야 한다는 기초는 측정값·지표·목표·기준선을 따른다. 많이 만들었다는 숫자 하나가 고객 가치와 품질을 동시에 보증하지는 않는다.

방법론 활용의 완성형: 조건 → 선택 → 실행 → 검증

개발 방법론의 활용은 모델 이름의 선택에서 끝나지 않는다. 다음은 앞에서 배운 원리를 공방의 실제 개발 계획으로 옮기는 절차다. 각 단계에서 다음 판단에 필요한 결과가 남아야 한다.

1. 조건을 나눈다. 목표·요구의 안정성, 기술 위험, 실패의 영향, 사용자 확인 가능성, 계약·인계 제약을 확인하고 확실한 것과 가정을 구분한다. 결과는 목표와 제약·불확실성 목록이다.
2. 개발 흐름을 고른다. 계획의 상세화 시점, 같은 결과를 개선할 반복, 사용 능력을 늘릴 증분 단위를 따로 정한다. 결과는 생명주기 선택 이유와 고객 확인 시점이다.
3. 일하는 규칙으로 구체화한다. 활동·책임자·산출물·변경 권한을 정하고, Scrum 등을 쓰면 그 핵심 규칙을 지킨다. 결과는 팀과 이해관계자가 공유하는 실행 방식이다.
4. 완료와 진행 조건을 먼저 정한다. 요구·설계와 확인 증거를 연결하고, 중요한 위험을 줄였다는 근거와 단계·증분의 완료 기준을 정한다. 결과는 시험·검토 기준과 진행 판단 조건이다.
5. 작게 수행하며 증거를 남긴다. 실제 결과, 사용자 반응, 시험 결과, 채택·연기한 변경과 이유를 기록한다. 결과는 추측이 아닌 확인 가능한 제품·검증·결정 기록이다.
6. 성과와 부작용을 함께 보고 조정한다. 사용할 수 있는 결과와 품질·재작업·대기시간을 확인하고 범위·순서·작업 방식을 고친다. 결과는 다음 계획과 개선 조치이며, 품질을 낮추어 실적을 맞추지 않는다.

이 절차에서 위험이 크다고 적었다면 어떤 위험을 어떤 증거로 낮출지까지 써야 한다. 애자일을 적용한다고 적었다면 누가 범위를 바꾸며 목표와 품질을 어떻게 지키는지까지 써야 한다. 이것이 정의를 아는 수준에서 비교·선택·통제하는 수준으로 넘어가는 차이다.

읽는 사례: 하나의 공방 프로젝트에 선택을 실제로 연결한다

혼합 접근(hybrid approach)은 서로 다른 조건에 맞는 계획·개발·통제 방식을 일관되게 결합하는 접근이다. 한 이름으로 합친다고 새 규칙이 저절로 생기는 것은 아니므로 결합 지점의 책임과 기준을 명확히 해야 한다. 공방에서는 다음과 같이 선택할 수 있다.

팀은 작은 증분의 협업에 Scrum을 사용하되 취소·정원 규칙과 결제 증거의 대응은 계속 유지한다. 새로운 취소 요구가 오면 제품 가치와 영향을 검토하고, 해당 규칙의 결정 권한자와 관련 요구·시험을 갱신한 뒤 Developers와 가능한 범위를 맞춘다. 스프린트 목표와 품질 기준을 위태롭게 하는 무조건적 추가는 하지 않는다.

전체 화면을 먼저 문서로 확정하는 안은 사용자 불확실성을 늦게 발견하므로 그대로 채택하지 않는다. 매 요청을 즉시 반영하는 안도 목표와 품질을 잃을 수 있어 채택하지 않는다. 결제 시제품만 계속 만드는 안은 다음 진행 조건이 없어 위험 감소를 판단할 수 없다. 선택한 혼합 접근은 이 세 실패를 줄이려는 결정이지 모든 프로젝트에 대한 유일한 정답이 아니다.

이제 결정을 한 단계씩 따라가 보자. 이번 목표가 한 건을 예약하고 확정 결과를 본다이고, 날짜를 먼저 고르게 한 화면에서 고객이 수업을 찾지 못했다면 입력은 관찰된 어려움과 화면 변경 요청이다. 팀은 날짜·수업 선택 순서를 바꾸어도 같은 예약 목적을 지킬 수 있는지, 남은 구현·시험 안에 들어오는지 확인한다. 가능하면 Product Owner와 Developers가 덜 중요한 화면 작업을 미루고 계획을 고친다. 바뀐 상태는 목표는 같고 세부 작업 순서가 달라진 계획이며, 결과는 완료 기준을 충족한 예약 흐름이어야 한다. 변경 요청을 접수했다는 기록만으로 기능이 완료되지는 않는다.

조건을 하나 바꾸어 스스로 판단해 보자. 같은 기간에 판매자 정산 기능까지 요청받았고, 이를 넣으면 예약 확인 시험을 끝낼 수 없다면 무엇을 먼저 바꿀까? 해설은 시험을 생략한다가 아니라 새 정산 기능을 제품 백로그에서 다른 후보와 비교하고 이번 목표를 지킬 범위를 협의한다는 것이다. 목표가 여전히 의미 있으므로 새 요청만으로 스프린트를 취소할 이유도 없다. 변화 대응이니 모두 즉시 추가한다라고 썼다면 이번 기간의 목적과 실행계획과 변경을 검토하는 조건으로 돌아가, 유지할 목표·미룰 일·품질 증거를 한 문장씩 다시 적는다. 이 작은 판단을 할 수 있어야 뒤의 25점 문제에서 조건별 통제를 독립적으로 조합할 수 있다.

혼합할 때 지켜야 할 경계

사용자와 자주 만날 수 없으면 짧은 주기만 정해도 학습은 일어나지 않는다. 대신 대표 사용자와 확인할 시점과 책임을 확보하고, 얻지 못한 피드백은 미확인 가정으로 남겨야 한다. 시스템의 일부만 따로 확인할 수 없을 만큼 연결이 강하면 작은 증분을 나누는 비용도 커진다. 그때에는 연결부 설계와 통합 증거를 더 일찍 준비한다.

외부 승인이 필요한 프로젝트에서도 내부에서 요구를 반복 확인할 수 있다. 반대로 짧게 반복하는 프로젝트에도 계약·안전·품질에 대한 명확한 기준이 필요하다. 혼합의 목적은 양쪽의 문서와 회의를 전부 추가하는 것이 아니라, 조건마다 필요한 증거와 결정을 연결하는 것이다.

Scrum의 일부 행사만 사용한다면 그 요소를 참고한 작업 방식이라고 설명할 수 있다. 그러나 핵심 책임·이벤트·산출물 규칙을 제거한 결과를 공식 Scrum을 온전히 적용했다고 부르지는 않는다. 구체적인 개발·시험·운영 기법을 채우는 것과 프레임워크의 핵심을 없애는 것은 다르다.

독립 연습 — 목표를 보호하면서 무엇을 바꿀 수 있는가

다음은 본문 사례의 조건을 적용하거나 바꾼 자체 연습이다. 먼저 판단과 근거를 적고 풀이를 펼친다.

공방의 이번 목표는 한 건을 예약하고 확정 결과를 보는 것이다. 운영자가 판매자 정산까지 넣어 달라고 요청했지만, 이를 넣으면 예약 확인 시험을 끝내지 못한다. 목표 자체는 여전히 가치 있다. 다음 세 결정을 각각 판단하라. ① 완료의 정의에서 결제 연결 확인을 빼고 둘 다 완료 처리한다. ② 정산 요청을 제품 백로그에 두고 이번 목표를 지킬 범위를 협의한다. ③ 새 요청이 생겼다는 이유만으로 스프린트를 취소한다.

• 채택할 결정과 기각할 두 결정의 이유를 각각 쓰라.
• 이번 기간의 목적, 세부 작업 목록, 공통 품질 기준 중 무엇을 유지하고 무엇을 조정하는지 구분하라.

풀이와 오답 교정 보기

②가 사례의 조건에 맞는다. 정산의 가치와 영향은 제품 백로그의 다른 후보와 비교하며, Product Owner와 Developers가 이번 목표를 보호할 범위를 협의한다. ①은 품질을 낮춰 미완료 작업을 완료로 바꾸는 오류다. ③은 목표가 더는 의미 없어진 상황이 아닌데 새 요청만으로 취소를 결론 낸 오류다. 세부 실행계획을 바꾸는 것과 목표·완료의 정의를 지우는 것은 다르다.

요청을 즉시 받는 것을 변화 대응과 같게 썼다면 목표와 변경 통제, 시험을 생략했다면 증분과 완료의 정의로 돌아가 자신의 결정 문장부터 고친다.

5. 같은 내용을 기술사 답안으로 압축한다

10점 예제 — 개념을 같은 축에서 비교하지 않기

자체 작성 문제

소프트웨어 개발의 예측형·반복형·점증형 접근을 구분하고 애자일과의 관계 및 적용 시 유의사항을 설명하시오.

명령어는 구분하고 설명이다. 세 이름의 정의를 각각 외워 적는 것보다 계획 시점·반복 개선·기능 누적이라는 서로 다른 질문을 먼저 보여야 한다. 그다음 애자일은 가치·원칙 중심 접근임을 연결하고, 계획·문서·품질을 없애지 않는다는 조건으로 마무리한다. 아래 답안은 본문에서 배운 개념만 압축한 읽기 예시다.

10점 풀이와 답안 구성 보기

10점 목차

1. 개발 방법론의 목적과 예측형·적응형의 계획 차이
2. 반복 개선과 점증 전달의 구분·결합
3. 애자일 가치와 선택·변경·품질 통제

10점 답안 도식

서로 다른 축	공방 예	결합 시 지킬 조건
계획 시점: 예측형 ↔ 적응형	상세 계획을 앞에서 정할지 결과로 조정할지	계획의 유무나 우열이 아님
개선 방식: 반복	같은 예약 화면을 다시 평가·개선	반복 횟수보다 관찰과 개선 근거
전달 단위: 점증	조회 → 접수 → 취소 능력을 누적	사용할 수 있는 결과와 품질 기준
세 축은 결합 가능	애자일 가치·피드백과 함께 사용	목표·변경 권한·품질 기준 유지

위 표의 첫 행은 계획을 상세하게 정하는 방식이고 다음 두 행은 개선과 전달의 방식이다. 세 축을 일렬의 우열 관계로 그리지 않는 것이 논점이다.

10점 답안 예시

1. 목적과 계획 방식

개발 방법론은 목표와 제약에 맞게 활동·책임·산출물·검토·변경을 조직하는 체계다. 예측형은 범위와 실행계획을 앞에서 비교적 상세히 정해 통제하며, 적응형은 관찰한 결과로 상세 범위와 계획을 짧은 주기로 조정한다. 계획의 유무가 아니라 상세화 시점과 수정 근거의 차이다.

2. 반복과 점증

반복은 같은 대상을 다시 평가하여 개선하고, 점증은 사용할 수 있는 기능을 누적해 제품 능력을 넓힌다. 예약 화면을 고객 반응으로 고치는 것은 반복이고 조회에 접수·취소 능력을 더하는 것은 점증이다. 예측형에서도 증분 전달이 가능하며 한 증분 안에서 여러 번 반복할 수 있다.

3. 애자일과 통제

애자일은 사람 간 협력, 작동하는 결과, 고객 협력과 변화 대응에 더 무게를 두는 가치·원칙 중심 접근이며 계획·문서·계약을 배제하지 않는다. 요구 안정성·위험·사용자 확인 가능성에 따라 방식을 선택하고, 변경 권한·목표·완료 기준을 명확히 하여 반복이 재작업만 늘리거나 점증이 품질 저하로 이어지는 것을 막아야 한다.

25점 예제 — 조건을 방법·산출물·통제로 연결하기

자체 작성 문제

예약 서비스 개발에서 정원·취소 규칙은 안정적이나 사용자 흐름은 불확실하고 외부 결제 연계 위험이 크다. 폭포수·V 모델·나선형과 애자일 접근을 비교하고, 적절한 개발 방법론 활용 방안 및 변경·품질 통제를 설명하시오.

명령어는 비교하고 방안을 설명이다. 제시된 안정성·불확실성·위험에 각각 이유 있는 선택이 필요하다. 방법 이름만 묶지 말고 책임·산출물·진행 조건과 실패했을 때의 조정을 써야 한다. Scrum을 예로 들면 애자일 전체와 구분하고, 목표 안의 범위 협의와 완료 기준을 실제 통제로 설명한다.

25점 풀이와 답안 구성 보기

25점 목차

1. 개발 방법론 활용 목적과 사례 조건의 분해
2. 폭포수·V 모델·나선형·애자일의 통제 목적 비교
3. 조건별 혼합 선택과 단계별 산출물·진행 조건
4. Scrum을 활용한 책임·목표·변경 통제
5. 완료·품질 증거와 성과·실패 징후 점검

25점 답안의 통제 연결표

조건 → 선택 → 증거	결합과 조정
안정 규칙 → 기준 합의 → 요구 ↔ 확인 증거	사용 가능한 증분에서 함께 작동
사용 불확실 → 작은 흐름 → 사용자 확인 ↔ 반복 개선	제품 가치·목표를 유지
결제 위험 → 대안·위험 시험 → 감소 근거 ↔ 진행 판단	범위 협의와 완료 기준·품질 증거
증분의 결과·재작업·실패·대기 관찰 → 다음 계획	관찰 결과를 다음 범위와 작업 방식에 되먹임

표의 화살표 표기는 조건에 맞는 통제를 고르는 연결을 뜻한다. V 모델의 실제 대응은 앞의 그림에서, 나선형의 위험 분석과 다음 진행 판단은 앞의 본문 설명에서 다시 확인한다. 세 조건에 맞춘 통제는 하나의 서비스에서 함께 작동해야 하며, 마지막 행의 관찰 결과는 다음 범위와 작업 방식에 되먹임된다.

25점 답안 예시

1. 활용 목적과 조건

개발 방법론 활용은 목표·제약에 맞는 생명주기와 활동·책임·산출물·변경 통제를 선택하여 실제 절차로 구체화하는 것이다. 사례는 안정적인 정원·취소 규칙, 사용자 확인이 필요한 흐름, 먼저 줄여야 할 결제 위험으로 나뉜다. 따라서 단일 모델을 획일적으로 적용하기보다 조건별 통제를 결합하고 결합 지점의 책임과 증거를 명확히 한다.

2. 접근별 비교

접근	통제 중심	사례 적용 및 유의점
폭포수	큰 단계 산출물과 전환 조건	안정 규칙의 합의·인계에 활용하되 고객 확인을 마지막으로 미루지 않음
V 모델	요구·설계와 확인 증거의 대응	정원·취소 요구와 개별·연결·전체 확인을 추적하며 목적 누락도 점검
나선형	위험 감소 근거와 다음 진행 판단	결제 실패 조건을 먼저 확인하되 시제품 반복 자체를 성과로 보지 않음
애자일	작동 결과·협력·변화 대응	불확실한 사용자 흐름을 개선하되 계획·문서·품질 통제를 배제하지 않음

3. 선택과 실행 산출물

먼저 목표·제약·불확실성을 정리하고, 안정 규칙은 요구·책임자·시험 기준을 합의한다. 사용자 흐름은 작게 확인하여 반복 개선하고, 조회·접수·확인 등 사용할 수 있는 기능 단위로 증분을 누적한다. 결제 연계는 요청·응답 단절 조건의 시험과 대안 평가로 위험을 줄이며, 근거가 부족하면 방식·범위를 재결정한다. 각 단계에 실행 방식, 요구와 증거의 대응, 위험 평가, 완료·진행 조건, 변경 이유와 결과를 남긴다.

4. 책임과 변경 통제

작은 증분의 협업에는 Scrum을 활용할 수 있으며 이는 애자일의 동의어가 아닌 경량 프레임워크다. Product Owner는 제품 가치와 Product Backlog 관리, Developers는 실행계획·품질·일상 조정, Scrum Master는 올바른 Scrum 적용과 팀 효과성에 책무를 가진다. Sprint Goal을 위태롭게 하지 않는 범위는 Product Owner와 Developers가 협의하여 조정하고 품질은 낮추지 않는다. 목표 자체가 무의미해진 경우에만 Product Owner의 취소 판단을 고려한다. 규칙 변경은 조직의 결정 권한자와 관련 요구·설계·시험을 함께 확인하여 갱신한다.

5. 검증과 개선

증분은 기존 결과와 함께 작동하고 DoD를 충족해야 하며 달력 종료만으로 완료 처리하지 않는다. Review에서는 결과·환경 변화에 따른 제품 방향을 조정하고, Retrospective에서는 작업 방식의 품질과 효과성을 개선한다. Review를 필수 배포 승인 관문으로 보지 않는다. 예약 완료 가능성과 품질 증거, 사용 중 실패·재작업·질문 대기시간을 함께 관찰하여 다음 범위와 작업 방식을 조정한다. 사용자 확인 지연, 사용할 결과의 부재, 목표를 잃는 변경, 품질 저하는 각각 조기 확인·증분 분할·변경 협의·완료 기준 점검으로 통제한다.

결론적으로 모델의 유행보다 요구 안정성·위험·피드백 조건을 기준으로 선택하고, 선택 이유가 역할·산출물·증거·조정 절차까지 이어지게 해야 한다.

6. 다시 읽을 때 남길 세 문장

예측·적응은 계획을 상세하게 정하는 방식, 반복은 같은 대상을 개선하는 방식, 점증은 사용할 능력을 누적하는 방식이므로 함께 조합될 수 있다. 폭포수의 단계 기준, V 모델의 요구·증거 대응, 나선형의 위험 감소, 애자일의 협력·변화 대응은 이름보다 무엇을 통제하는지로 이해한다. 선택한 방식을 책임·산출물·변경 권한·완료 기준으로 구체화하고 실제 결과로 조정해야 개발 방법론을 활용했다고 할 수 있다.

다음 DevOps·CI/CD·가치흐름에서는 이렇게 만든 변화가 개발에서 운영으로 안전하게 이어지도록 하는 전달 흐름을 살펴본다. 이 절의 변경 판단·품질 기준이 그 흐름의 출발점이다.

출처와 현행성

확인 기준일은 2026-09-05다. 애자일 선언과 열두 원칙은 2001년 원문의 가치·원칙을 사실 근거로 사용했다. 본문은 원문의 번역본이나 인용문 모음이 아니라 공방 사례로 직접 구성한 설명이다.

계획·반복·점증의 특성은 PMI의 공개 설명자료를 참고했다. 세 질문으로 나눈 표는 이 교재의 독립적인 비교 구성이다. 기준선의 변경 통제 의미는 NASA Systems Engineering Handbook Rev. 2의 Glossary와 6.5절을 근거로 삼으며 측정 기준선과 구별한다.

Scrum의 핵심 규칙은 Ken Schwaber와 Jeff Sutherland가 쓴 공식 Scrum Guide 2020년 11월판의 본문을 직접 확인했다. 원문은 © 2020 Ken Schwaber and Jeff Sutherland이며 CC BY-SA 4.0으로 제공된다. 원문의 보호받는 표현을 번역·각색하여 공개한다면 저작자·라이선스·변경 표시와 동일조건 등 라이선스 요건을 지켜야 한다. 이 교재는 공방 사례로 독립적인 설명을 작성했지만, 그것만으로 공개 배포용 권리·라이선스 검수가 끝났다는 뜻은 아니다. 원문을 보존하지 못한 보조 해설은 검증 근거에서 제외했다. 공식 배포 안내가 제시하는 현재판도 기준일에 확인했으며, 후속판이 나오면 책임·이벤트·산출물·변경·완료 규칙을 다시 대조해야 한다.

폭포수와 생명주기 선택은 NASA SWE-019의 모델 해설, V 모델의 개발·시험 대응은 Rowley·Ramakrishnan의 논문, 인쇄 130–131쪽, 나선형은 Boehm의 CMU/SEI-2000-SR-008, 1.2·2.2절의 이론 설명을 사용했다. NASA의 해당 페이지는 구판 NPR 7150.2B에 연결된 역사적 해설이므로 현행 의무 규정이나 한국 시험의 공식 요구로 제시하지 않는다. 그림·표·문제·답안은 이 교재가 직접 구성했고 외부 도식을 복제하지 않았다.

직접 연습: 같은 화면의 개선, 증분의 완료, 공개 시점을 나누어 판단한다.

다음 수와 일정은 판단을 위한 자체 사례다. 화면이 잘 보인다는 사실, 사용할 수 있다는 사실, 실제 고객에게 공개했다는 사실을 서로 다른 증거로 적는다.

1. LR-1. 공방은 날짜 선택 시제품을 두 차례 고객에게 보여 주고 같은 화면의 순서를 고쳤다. 고객의 어려움은 줄었지만 예약 저장·정원 초과 방지·접근권한 확인은 아직 없다. 이 시제품은 검증할 화면 가정만 다루며, 팀의 제품 완료 기준은 저장·정원·권한 확인까지 요구한다. 이는 반복인가, 사용할 수 있는 Scrum 증분인가? 앞으로 예약 접수까지 연결할 때 필요한 증거 두 가지를 쓰라.
2. IN-1. 같은 Sprint의 3일째 수업 조회 A가 완료 기준을 충족했다. 7일째 예약 접수 B도 A와 함께 작동하는 확인을 포함해 완료 기준을 충족했다. 취소 C는 필수 확인 10개 중 9개만 통과했고 나머지 하나는 실패했다. 각 확인의 중요도를 점수로 합치는 규칙은 없다. 이번 Sprint Goal은 예약 한 건을 확정하는 것이다. 증분에 포함할 수 있는 결과와 아직 포함할 수 없는 결과를 나누고, C도 90% 완료이므로 증분이다라는 말을 고치라. 조직이 공개를 허용했고 A+B는 고객이 쓸 수 있다면 7일째 전달을 Review가 열릴 때까지 반드시 기다려야 하는가?
3. EV-1. 결제 위험을 줄이는 진행 조건은 응답이 끊긴 뒤 같은 결제 요청을 다시 보내도 중복 결제가 없음을 확인한다이다. 팀은 요청이 한 번 성공하는 화면 시제품만 완성했고, 결제회사 시험 환경을 사용할 수 없어 단절·재전송은 확인하지 못했다. 시제품 완성을 진행 조건 통과로 기록할 수 있는가? 미확인 사실, 다음에 확보할 증거, 그때까지 가능한 판단을 한 문장씩 쓰라.

시제품·완료 기준·공개 시점·위험 증거를 구별하는 풀이

1. LR-1 — 같은 목적을 다듬었지만 제품의 완료 증거는 아직 없다. 같은 날짜 선택 흐름을 고객 반응으로 고쳤으므로 반복에 해당한다. 시제품으로 화면 가정을 배울 수 있어도 정해진 제품 완료 기준을 충족하지 못했으므로 사용할 수 있는 Scrum 증분이라고 기록하지 않는다. 다음에는 예약 접수와 저장 결과가 연결된 증거, 정원 초과·권한 조건을 만족하는 증거 등이 필요하다. 화면 개선과 기능 누적은 함께 일어날 수도 있지만, 이 조건에서는 화면 개선만 확인됐다.

2. IN-1 — 완료된 결과는 누적하고 미완료 결과는 분리한다. A와 A+B는 각 시점에 기존 결과와 함께 사용할 수 있고 완료 기준을 충족했으므로 한 Sprint 안에서도 증분이 생길 수 있다. B가 완료되었을 때 예약 한 건을 확정한다는 목표를 충족했는지도 실제 흐름으로 확인한다. C는 9/10=90%라는 통과 비율을 계산할 수 있지만, 실패한 필수 조건이 있으므로 완료 기준을 충족한 증분에 포함하지 않는다. 비율은 남은 확인을 드러내는 보조 정보이며 품질 충족 여부를 대신하지 않는다.

조직이 공개를 허용한 A+B는 Review 전에 전달할 수 있다. 전달했다고 Review를 생략하는 것은 아니다. Review에서는 그 결과와 환경 변화를 함께 살펴 다음 방향을 조정한다. 공개하지 않은 완료 증분과 공개된 미완료 결과도 혼동하지 않는다. Scrum Guide의 증분과 완료 기준

3. EV-1 — 시험한 조건과 필요한 조건이 다르다. 한 번 성공한 시제품은 단절 뒤 재전송의 중복 방지 증거가 아니므로 진행 조건 통과로 기록하지 않는다. 정상 요청 성공은 확인했고 응답 단절 뒤 재전송은 미확인이라고 구분한다. 시험 환경과 재전송 시나리오, 결제 결과의 중복 여부를 관찰할 방법을 확보한 뒤 정한 조건을 확인해야 한다. 그동안 관련 없는 작업을 진행할지, 대안을 평가할지, 범위·다음 투자를 보류할지는 위험과 의존성에 맞춰 판단한다. 아직 보지 못한 결과를 성공으로 바꾸거나 품질 기준을 지워 진행하는 답은 성립하지 않는다.