분석·설계·구현·시험·운영·변경

코드를 쓰기 전과 배포한 뒤에도 소프트웨어 일은 계속된다

요청받은 기능을 곧바로 코딩하면 처음에는 빨라 보인다. 그러나 누구의 어떤 문제가 해결되어야 하는지, 실패했을 때 무엇을 복구할지, 운영 중 누가 고칠지 정하지 않으면 완성 뒤의 비용이 커진다. 소프트웨어는 한 번 만들어 끝나는 물건이 아니라 필요를 발견하고, 구조를 선택하고, 구현을 확인하고, 실제 사용에서 배우며 바뀌는 생명주기를 가진다.

먼저 되짚기: 피드백과 통제

피드백 통제는 실제 결과를 목표와 비교하고 차이를 다음 행동에 반영하는 순환이다. 측정과 비교가 늦으면 잘못된 방향으로 진행한 뒤에야 차이를 발견한다. 생명주기의 각 단계는 앞선 가정을 결과로 확인해 다음 판단을 고치는 피드백 지점이 된다.

소프트웨어 생명주기

소프트웨어 생명주기는 문제와 필요의 발견부터 분석, 설계, 구현, 시험, 배포, 운영, 변경과 종료까지 소프트웨어가 거치는 활동과 피드백의 흐름이다. 분석은 무엇이 필요한지와 제약을 밝히고, 설계는 그 필요를 만족할 구조와 책임을 정한다. 구현은 설계를 실행 가능한 코드와 설정으로 만들고, 시험은 결과가 기준을 만족하는지 증거를 모은다. 운영은 실제 환경에서 서비스를 제공하고 관찰하며, 변경은 새 필요·결함·환경 변화에 맞춰 앞 활동을 다시 수행한다. 단계는 책임을 구분하는 이름이지 반드시 한 번씩 직선으로 지나야 하는 고정 순서는 아니다.

각 활동은 질문과 증거를 다음 활동에 넘긴다

활동 사이에는 추적 가능한 연결이 필요하다. 요구 하나가 어떤 설계결정과 구현, 시험으로 이어졌는지 찾을 수 있어야 누락을 발견하고 변경 영향을 계산할 수 있다. 작은 결과물을 일찍 보여 주면 분석 가정은 사용자 피드백으로, 설계 가정은 실험과 시험으로, 운영 가정은 실제 지표로 확인된다. 틀린 가정을 앞에서 발견할수록 이미 만든 코드와 데이터, 교육과 계약을 되돌리는 비용이 줄어든다.

순차·반복·증분은 피드백 배치 방식이 다르다

세 방식은 서로 배타적이지 않다. 전체 예산과 승인에는 순차적인 통제점을 두고, 각 증분 안에서는 반복적으로 설계와 시험을 수행할 수 있다. 선택 기준은 요구 변동성, 실패 영향, 규제 증거, 배포 가능성, 이해관계자의 피드백 속도다.

단계 이름만 있고 피드백이 없으면 생명주기가 아니다

문서를 승인받는 행위가 실제 위험 확인을 대신하면 단계는 통과했지만 틀린 제품을 만들 수 있다. 분석 결과와 시험이 연결되지 않으면 중요한 요구가 시험 없이 배포되고, 운영 담당자가 설계에 참여하지 않으면 감시·복구·용량 조건이 뒤늦게 드러난다. 빠른 반복도 품질 기준과 변경 기록이 없으면 같은 결함을 되풀이한다.

각 통제점에서는 무엇을 알게 되었는가, 어떤 가정이 틀렸는가, 다음 단계에 넘길 증거가 충분한가를 묻는다. 변경은 작은 수정이라도 요구·설계·코드·시험·운영 문서 중 무엇에 영향을 주는지 확인한다. 종료할 때는 데이터 보존과 이관, 접근권한 제거, 의존 시스템 분리까지 생명주기의 일부로 다룬다.

단계보다 질문과 피드백의 연결을 본다

상자 안의 대상과 화살표의 조건을 함께 읽으세요. 좁은 화면에서는 같은 관계를 세로로 재배치한 도식을 보여 줍니다.

활동 이름은 책임의 구분이다. 첫 증분의 날짜선택 오류 4/10은 요구 v2로 환류하고, 같은 유형의 사용자 과제 10/10과 동시예약·취소 회귀를 모두 충족할 때 제한 시범배포한다. 작은 표본은 모든 사용자의 이해를 보증하지 않는다.

종료 시에도 데이터 이관·보존·폐기, 접근권한 제거와 의존 시스템 분리를 확인한다. 분석·설계·구현·시험으로 돌아오는 경로는 운영 증거에 따라 선택하며 모든 단계를 매번 같은 순서로 반복한다는 뜻은 아니다.

사례: 결과를 일찍 보여 위험을 조기에 확인한다

새 예약 기능의 요구가 불확실하다고 하자. 전체 구현 뒤 한 번에 확인하지 않고 먼저 핵심 예약 흐름과 수용기준을 정해 작은 증분을 만든다. 설계 단계에서는 동시예약 충돌을 실험한다. 구현 뒤에는 날짜 검사 같은 개별 코드 단위를 확인하는 단위시험, 예약과 저장소가 함께 동작하는지 확인하는 통합시험, 조회부터 취소까지 전체 흐름을 확인하는 시스템시험으로 범위를 넓힌다. 변경 뒤 기존 동작이 깨지지 않았는지 다시 확인하는 회귀시험도 수행하며, 시범운영에서는 실제 취소율·오류·문의 이유를 관찰한다.

여기서 사용자 인터페이스(UI)는 사용자가 정보를 보고 조작하는 화면과 상호작용 방식이다. 사용자가 날짜선택을 이해하지 못하면 요구·UI 설계로 되돌아가고 부하에서 충돌이 늘면 구조와 동시성 통제를 다시 검토한다. 조기 피드백은 단계를 없애는 것이 아니라 잘못된 가정의 증거를 더 일찍 얻는 방법이다.

첫 증분은 “남은 시간대 조회→본인 예약 1건 확정→확정내역 조회→출발 전 취소”까지 한 사용자가 끝낼 수 있는 흐름으로 한정한다. 결제와 반복예약은 이후 증분이다. 빈 슬롯이 하나일 때 두 사용자가 동시에 신청해도 확정은 하나여야 하며, 취소 뒤에는 같은 슬롯이 다시 열리는지를 수용기준으로 둔다.

한 회차의 자체 관찰에서는 예약·취소 상태 시험은 통과했지만 시제품 이용자 10명 중 4명이 날짜를 하루 잘못 골랐다. 팀은 이를 “시험 통과”로 닫지 않고 날짜·요일·시간대와 확인 화면을 요구 v2에 추가한다. 재구현 뒤 같은 유형의 과제에서 10명 모두 의도한 날짜를 선택하고 동시예약·취소 회귀도 통과한 경우에만 제한 시범배포한다. 작은 표본 결과는 모든 사용자의 이해 증명이 아니다. 시범 중 이중확정이 한 번이라도 나오면 신규예약을 중단하고 이전 판본으로 복구하되 이미 확정한 예약 기록은 대조·보존한다.

자체 10점 문제

소프트웨어 생명주기의 주요 활동과 활동 간 추적·피드백 방안을 설명하고 순차·반복·증분 접근의 적용기준을 제시하시오.

요구어는 설명과 제시다. 단계명 암기보다 각 단계의 질문·산출물·증거와 변경 피드백을 연결하고, 접근 방식은 변동성·실패영향·증거의무·배포가능성으로 비교한다.

10점 풀이 방향과 모범답안 보기

10점 답안 목차

1. 생명주기 정의
2. 분석·설계·구현·시험·운영의 책임
3. 요구–설계–시험–운영 추적
4. 단계 사이 피드백
5. 순차·반복·증분 적용기준

10점 답안 도식

분석의 요구가 설계·구현·시험·운영까지 추적되고, 시험·운영의 증거와 변경 영향이 필요한 앞 활동으로 돌아온다. 예약 증분 그림에서 날짜 오류는 요구·UI 변경으로, 이중확정은 중단·복구로 연결되는 이유를 설명한다.

기술사 답안으로 전환하기

예상문제: “소프트웨어 생명주기의 주요 활동과 활동 간 추적·피드백 방안을 설명하고 순차·반복·증분 접근의 적용기준을 제시하시오.”

소프트웨어 생명주기는 문제·필요의 발견부터 분석, 설계, 구현, 시험, 배포, 운영, 변경과 종료까지 이어지는 활동과 피드백의 흐름이다. 분석은 필요한 것과 제약을 밝히고 설계는 구조와 책임을 정한다. 구현은 실행 가능한 결과를 만들고 시험은 기준 충족 증거를 모으며 운영은 실제 가치와 위험을 관찰한다. 단계명은 책임을 나누는 논리적 구분이며 반드시 한 번씩 직선으로 지나야 하는 순서는 아니다.

각 요구에는 설계결정, 코드·설정, 시험과 운영지표를 연결해 누락과 변경 영향을 찾는다. 작은 결과를 일찍 보여 분석 가정을 사용자 반응으로 확인하고, 설계 가정은 실험·시험으로, 운영 가정은 실제 지표로 확인한다. 변경과 종료도 데이터 이관·보존, 권한 제거와 의존성 분리까지 포함한다.

순차 접근은 계약·규제 산출물과 큰 승인 경계가 중요할 때, 반복 접근은 해법의 불확실성을 학습해야 할 때, 증분 접근은 일부 가치를 일찍 전달할 수 있을 때 유리하다. 세 방식을 결합할 수 있으며 요구 변동성, 실패 영향, 증거 의무, 배포 가능성과 피드백 속도로 선택한다. 문서 승인만 하고 가정을 확인하지 않거나 운영·복구를 뒤로 미루는 실패는 단계별 질문·증거·책임과 추적성으로 통제한다.

자체 25점 문제

요구 변동이 큰 예약 서비스의 분석·설계·구현·시험·운영을 작은 증분으로 연결하고 조기 피드백으로 위험을 줄이는 생명주기 운영안을 설계하시오.

요구어는 설계다. 단계 제거가 아니라 각 단계에서 확인할 가정·증거·되돌림 조건과 배포 단위를 명시한다.

25점 풀이 방향과 모범답안 보기

25점 답안 목차

1. 목표·불확실성·실패영향
2. 요구와 수용기준
3. 최소 설계·위험 실험
4. 작은 구현 증분
5. 자동·통합·사용자 시험
6. 시범배포와 운영지표
7. 증거 기반 요구·설계 변경
8. 종료·이관·보존 조건

25점 답안 도식

다음 증분으로 이어질 연결	예약 사례의 확인
가설 → 작은 요구 → 설계실험	슬롯 1개에 확정 1건, 동시예약·복구 위험
설계실험 → 증분 구현 → 시험증거	조회·예약·조회·취소 종단 흐름과 회귀
시험증거 → 시범배포 → 운영학습	사용자 과제와 회귀 충족 뒤 실제 오류·문의 관찰
운영학습 → 다음 요구·설계 변경	증거가 가설·기준을 벗어나면 영향분석·새 판본

예약 피드백 그림과 아래 첫 증분 선택 결과를 대조한다.

25점 모범답안

예약 서비스의 목표와 요구 변동성, 실패 시 피해, 규제·승인 의무를 먼저 정한다. 사용자 가치와 가장 불확실한 가정을 기준으로 작은 기능증분과 수용기준을 만들고, 설계 단계에서는 동시예약·권한·복구처럼 되돌리는 비용이 큰 위험을 먼저 실험한다.

구현은 추적 가능한 작은 변경으로 만들고 단위·통합·회귀시험과 사용자 확인을 단계적으로 수행한다. 시범배포에서는 실제 부하·오류·취소율·문의 이유를 관찰해 설계 가정과 사용가치를 확인한다. 증거가 기준을 벗어나면 요구·설계·시험으로 되돌아가 새 기준선과 증분을 만든다.

순차 접근은 큰 승인경계와 고정 산출물이 중요할 때, 반복 접근은 해법 불확실성을 줄여야 할 때, 증분 접근은 일부 가치를 안전하게 먼저 제공할 수 있을 때 유리하다. 세 방식을 혼합할 수 있으며 배포 가능성·피드백 속도·실패영향으로 결정한다. 종료 시 데이터 이관·보존·권한 제거·의존성 해제까지 생명주기에 포함한다.

이 설계의 첫 증분은 조회·예약확정·확정조회·취소의 종단 흐름이고, 날짜선택 실패 4/10을 요구 v2와 확인화면 변경으로 환류한다. 사용자 과제 재시험과 동시예약 회귀를 모두 충족하면 제한 배포하며 이중확정 1건이면 신규예약 중단·복구를 선택한다. 개발 내부에서 화면을 여러 번 수정하는 반복과 사용 가능한 첫 흐름을 전달하는 증분을 구분한다.

출처와 적용 경계

분석·설계·구현·시험·운영·변경의 생명주기와 순차·반복·증분 구분은 안정된 소프트웨어공학 기초개념이다. 예약 서비스 사례는 조기 피드백을 연습하기 위한 자체 예이며 특정 방법론의 전체 규칙을 재현하지 않는다.

자기교정과 조건 변경

배포가 연 1회 승인만 가능하다면? 내부 반복·시험은 유지하되 외부 배포증분과 승인증거를 큰 경계에 맞춘다.

요구가 거의 고정되고 규제 산출물이 많다면? 순차적 승인경계를 더 활용하되 위험실험과 검증 피드백을 뒤로 미루지는 않는다.

시범운영에서 사용가치가 없다고 나오면? 구현완료를 성공으로 보지 말고 필요·목표와 우선순위를 재검토한다.

30초 정리

1. 생명주기는 필요 발견부터 분석·설계·구현·시험·운영·변경·종료까지의 활동과 피드백 흐름이다.
2. 각 활동은 고유한 질문과 증거를 가지며 요구부터 운영 결과까지 추적되어야 한다.
3. 순차·반복·증분은 피드백을 배치하는 방식이며 상황에 맞춰 함께 쓸 수 있다.
4. 산출물 승인보다 가정 확인과 빠른 증거가 중요하고, 운영과 종료도 처음부터 설계해야 한다.