SDLC & Process

1. Overview

SDLC 및 프로세스(Software Development Life Cycle & Process, SDLC)는 소프트웨어라는 무형의 제품이 어떻게 기획되어 태어나고, 성장하며, 결국 폐기되는지 그 전 생애를 지배하는 엔지니어링의 거시적 관리 체계를 다룹니다.

과거에는 생각나는 대로 키보드를 두드리는 '코딩 앤 픽스(Code & Fix)' 방식이 만연했지만, 현대 소프트웨어 공학은 건물을 짓는 것과 같은 정교한 공정(Process)을 요구합니다. 학습자는 폭포수(Waterfall) 모델의 예측 가능성과 애자일(Agile)의 기민성을 비교하고, 기획 $\rightarrow$ 요구사항 분석 $\rightarrow$ 설계 $\rightarrow$ 구현 $\rightarrow$ 테스트 $\rightarrow$ 유지보수에 이르는 각 단계의 목적과 산출물을 이해합니다. 나아가 칸반(Kanban), 스크럼(Scrum) 등 실무적인 협업 프레임워크를 통해 수십 명의 개발자가 하나의 유기체처럼 소프트웨어를 찍어내는 공정 제어 역량을 획득합니다.

2. Scope & Boundaries

In-Scope

소프트웨어 수명 주기 모델 (SDLC Models): 폭포수(Waterfall), 나선형(Spiral), V-모델(V-Model), 반복/점진적(Iterative/Incremental) 모델.
애자일과 린 철학 (Agile & Lean): 애자일 선언문, 스크럼(Scrum) 프레임워크(스프린트, 백로그, 데일리 스크럼), 칸반(Kanban)과 WIP(Work In Progress) 제한.
프로세스 관리 및 거버넌스 (Process Management): 소프트웨어 프로세스 성숙도 평가(CMMI, SPICE), 기술 부채(Technical Debt)의 정량화.
개발 생태계 융합: SDLC와 DevOps(CI/CD) 파이프라인의 논리적 결합 지점.

Out-of-Scope

세부적인 클래스 다이어그램 그리기: UML을 이용한 상세 시스템 설계 기법 $\rightarrow$ 09-03. Architecture & Design 영역으로 위임.
배포 파이프라인 스크립트 작성: Jenkins나 GitHub Actions를 이용한 파이프라인 물리적 구축 $\rightarrow$ 09-05. DevOps & Reliability 영역으로 위임.

Boundaries

SDLC vs. Project Management (PMP): PMP가 '인력 할당, 예산 삭감, 외주 계약' 같은 비즈니스 관점의 관리를 다룬다면, SDLC는 '이 코드가 어떤 엔지니어링 단계를 거쳐 품질을 확보하고 프로덕션으로 넘어갈 것인가'라는 **기술적 공정(Technical Process)**에 집중합니다.

3. Counterexample

"애자일은 계획이 없는 것이다"라는 오해 (Agile Fallacy): "우리는 애자일이니까 일단 코딩부터 하고 설계 문서는 나중에 쓸게"라고 말하는 주니어. 진정한 애자일은 무계획이 아니라, 극단적으로 촘촘한 **단기 계획(Sprint)**의 연속입니다. 폭포수 모델이 1년 치 계획을 한 번에 세운다면, 애자일은 2주 단위의 설계-구현-테스트-회고의 사이클을 26번 돌리는 초정밀 공정입니다. 설계와 테스트 게이트를 생략하는 것은 애자일이 아니라 재앙을 예약하는 기술 부채(Technical Debt) 축적일 뿐입니다.
문서를 위한 문서 작성 (Documentation Fallacy): 개발은 이미 다 끝났는데, 감리를 통과하기 위해 요구사항 정의서와 시스템 아키텍처 문서를 사후에 끼워 맞추어 소설을 쓰는 행위. SDLC에서 산출물(Artifacts)은 다음 단계로 넘어가기 위한 '검증의 잣대(Verification)'이자 '소통의 도구'입니다. 문서가 구현을 리드하지 못하고 사후 처리가 되는 순간, 해당 조직의 프로세스는 완전히 붕괴된 상태임을 의미합니다.

4. Prerequisites

컴퓨터 과학 개론 (Basic): 소프트웨어가 코드 덩어리가 아니라 요구사항-설계-테스트의 산물이라는 기초적인 공학적 마인드셋이 필요합니다. (ROOT)
버전 관리 시스템 (Recommended): SDLC의 각 단계가 Git 브랜치 전략(GitFlow 등)과 어떻게 맞물려 돌아가는지 이해하는 것이 권장됩니다. (09-05. DevOps)

5. Learning Map

Sequence	Core Cluster	Objective & Description	Evidence (BoK)
1	Defining SDLC	주먹구구식 개발을 버리고, 설계도면(요구사항)부터 철거(폐기)까지의 체계적인 공정을 확립합니다.	P2
2	Process Models	다리 건설처럼 돌이킬 수 없는 폭포수 모델과, 진흙을 빚어가는 애자일 모델의 물리적 차이를 분석합니다.	Industry
3	Agile Dynamics	2주 단위로 스프린트를 돌며 돌아가는 소프트웨어를 찍어내는 스크럼(Scrum) 공장의 돌아가는 메커니즘을 배웁니다.	Industry
4	Process Improvement	우리 팀의 개발 속도가 왜 느려졌는지 기술 부채를 정량화하고, 공정(Process) 자체를 리팩토링합니다.	P5

6. Learning Topics

Basic

Core Topic 01: 소프트웨어 생명 주기 모델 (SDLC Fundamentals)

Why to Learn: 대충 만들고 고치는 짓을 반복하다가 프로젝트가 파산하는 것을 막고, 통제 가능한 일정을 확보하기 위함입니다.
What to Learn:
- Concepts: SDLC 단계 (요구사항 추출 $\rightarrow$ 분석 $\rightarrow$ 설계 $\rightarrow$ 구현 $\rightarrow$ 테스트 $\rightarrow$ 유지보수).
- Skills: 폭포수(Waterfall), V-모델(V-Model), 반복/점진적(Iterative/Incremental), 나선형(Spiral) 모델의 철학 및 비교.
- Tools: SDLC 템플릿, 간트 차트(Gantt Chart).
- Trade-offs: 처음부터 모든 것을 설계하고 시작하는 폭포수의 '명확한 비용 예측' vs 요구사항이 중간에 바뀌면 프로젝트 전체가 붕괴되는 '극악의 경직성'.
How to Learn:
- 1단계: 은행 코어 뱅킹 시스템(무결성 중요)과 틴더 같은 데이팅 앱(유행 중요)을 만들 때 각각 어떤 SDLC 모델(V-모델 vs 애자일)을 선택해야 하는지 트레이드오프를 도식화합니다.
- 2단계: V-모델에서 단위 테스트, 통합 테스트, 시스템 테스트가 설계 단계의 어느 산출물(상세 설계, 아키텍처, 요구사항)과 1<1> 매핑되어 검증(Verification)을 수행하는지 추적합니다.
Implement: 현재 자신이 진행 중인 토이 프로젝트가 어느 단계에 있는지 점검하고, 폭포수 모델을 기준으로 다음 단계로 넘어가기 위해 필요한 산출물 체크리스트 작성.

Why to Learn: 시장의 변화 속도가 계획의 속도를 앞지를 때, 문서를 쓸 시간에 '작동하는 소프트웨어'를 먼저 던져보고 피드백을 받기 위함입니다.
What to Learn:
- Concepts: 애자일 선언문(Agile Manifesto)의 4가지 가치, 린(Lean) 7원칙, 낭비(Waste) 제거.
- Skills: 스크럼(Scrum) 프레임워크 (스프린트, 백로그, 플래닝, 스탠드업, 회고), 사용자 스토리(User Story) 작성, 스토리 포인트 산정.
- Tools: Jira, Trello, Linear.
- Trade-offs: 고객의 피드백을 즉시 반영하여 쓸모없는 기능을 안 만들어도 되는 '극강의 효율' vs 매일매일 이어지는 데일리 미팅과 회고로 인한 '극심한 피로도(Agile Fatigue)'.
How to Learn:
- 1단계: "시스템은 성능이 빨라야 한다"라는 폭포수식 요구사항을, "나는 [바쁜 직장인]으로서 [주문 버튼을 눌렀을 때] [3초 이내에 결제가 완료]되길 원한다"라는 애자일 User Story(As a... I want to... So that...) 형식으로 치환해 봅니다.
- 2단계: 2주간의 가상 스프린트를 설정하고, Product Backlog에서 우선순위가 높은 작업을 가져와 Sprint Backlog로 옮기고 번다운 차트(Burndown Chart)를 그리는 스크럼 시뮬레이션을 수행합니다.
Implement: 특정 기능 구현을 위해 팀원들과 '플래닝 포커(Planning Poker)'를 진행하여 작업의 난이도(Story Point)를 산정하고, 이를 기반으로 2주짜리 스프린트 보드 구성안 작성.

Practical

Core Topic 03: 칸반 흐름 제어와 병목 관리 (Kanban Mechanics)

Why to Learn: 개발자가 한 번에 10개의 태스크를 끌어안고 어느 것 하나도 끝내지 못하는 상황을 물리적으로 차단하기 위해서입니다.
What to Learn:
- Concepts: 칸반(Kanban), 시각화(Visualization), 리드 타임(Lead Time)과 사이클 타임(Cycle Time).
- Skills: WIP(Work In Progress) 제한 설정, 누적 흐름도(Cumulative Flow Diagram, CFD), 병목(Bottleneck) 식별 및 해소.
- Tools: Jira Kanban Board.
- Trade-offs: 스크럼처럼 2주마다 강제로 끊지 않고 물 흐르듯 개발하는 편안함 vs 일정이 뚜렷하게 보이지 않아 제품 출시일 예측이 스크럼보다 어려워질 수 있는 위험.
How to Learn:
- 1단계: 칸반 보드에서 'In Progress(개발 중)' 단계를 진행하는 개발자는 3명인데 꽂혀 있는 티켓이 15개인 상황을 가정합니다. 컨텍스트 스위칭으로 인해 모든 티켓의 완료 속도가 1/5로 떨어지는 물리를 분석합니다.
- 2단계: 'In Progress' 컬럼의 WIP(진행 중 제한)를 엄격히 '3'으로 설정합니다. 앞 단계의 개발이 끝나도 다음 단계(QA)가 꽉 막혀있으면 개발자가 코딩을 멈추고 QA를 돕게 만들어 병목을 뚫어내는 칸반의 강제적 협업 모델을 시뮬레이션합니다.
Implement: 과거 프로젝트 경험에서 가장 작업이 지연되었던 단계를 파악하고, 이를 해결하기 위해 각 파이프라인 단계별 WIP 한도를 수학적으로 계산하여 설정한 칸반 보드 제안서.

Advanced

Core Topic 04: 기술 부채 관리와 프로세스 성숙도 (Technical Debt & Maturity)

Why to Learn: 오늘 밤을 새워 복붙(Copy & Paste)으로 구현한 코드가, 1년 뒤 회사 전체의 개발 속도를 0으로 수렴하게 만드는 파산(Bankruptcy)을 막기 위해서입니다.
What to Learn:
- Concepts: 기술 부채(Technical Debt), 리팩토링(Refactoring)의 경제학, 소프트웨어 위기(Software Crisis).
- Skills: 기술 부채의 사분면(무지한 부채 vs 신중한 부채) 분류, 코드 스멜(Code Smell) 정량화, 프로세스 성숙도 모델(CMMI).
- Tools: SonarQube, 프로세스 감사(Audit).
- Trade-offs: "일단 돌아가게 만들고 내일 출시하자"며 지는 빚(시장 선점) vs "아키텍처를 완벽히 짤 때까지 한 달 더 미루자"며 갚는 이자(시장 도태의 위험).
How to Learn:
- 1단계: 워드 커닝햄(Ward Cunningham)이 제안한 기술 부채의 메타포를 금융 부채와 비교합니다. 원금(지저분한 코드)을 갚지(리팩토링) 않으면, 이자(새 기능 추가 시 드는 잉여 시간)가 복리로 불어나 결국 파산(개발 불가능 상태)에 이르는 과정을 수학적으로 모델링합니다.
- 2단계: SonarQube 같은 정적 분석 도구를 프로젝트에 연결하고, "이 코드의 복잡도를 낮추려면 10일의 작업이 필요하다"라는 식의 기술 부채 지표(Technical Debt Ratio)를 읽고 백로그에 상환 계획(Refactoring Sprint)을 어떻게 녹일지 논의합니다.
Implement: 현재 개발 중이거나 과거에 작성한 프로젝트의 코드를 분석하여 기술 부채(예: 테스트 코드 부재, 중복 로직) 목록을 작성하고, 이를 상환하기 위한 점진적 리팩토링 마일스톤 계획서.

7. Terminology

Term (EN / ko, abbr)	1문장 정의	단계(기본/권장/실무/심화)	역할/맥락	관련 개념	유사/대비/함께 사용	오해 포인트	Evidence(Primary/Secondary/Industry)	Flags(core)
SDLC	소프트웨어의 생성부터 소멸까지의 전 과정을 정의한 표준화된 단계적 절차입니다.	기본	관리 체계	Waterfall	Agile	단순히 '코딩 순서'로 오해	P2:SWEBOK	core
Non-functional Req	기능 외에 성능, 가용성, 보안성 등 시스템의 품질 특성을 결정하는 물리적 제약 조건입니다.	추천	품질 정의	Constraints	Functional Req	부수적인 것으로 오해	P2:SWEBOK	core
Sprint	애자일 개발에서 일정량의 작업을 완료하는 데 주어진 짧고 정해진 시간 단위입니다.	실무	업무 주기	Scrum	Backlog	단순히 '마감 시간'으로 오해	Industry Guide	core
Technical Debt	빠른 배포를 위해 타협한 품질이 나중에 추가적인 수정 비용으로 돌아오는 현상을 말합니다.	심화	품질 관리	Refactoring	Interest	단순히 '버그'와 혼동	P2:SWEBOK	core

8. References

Primary References

[P2] SWEBOK v4.0 - Software Requirements / Process — Engineering standards.
[P5] SFIA - Software Development / Project Management — Industry professional skills.

Secondary References

[Software Engineering: A Practitioner's Approach] Roger S. Pressman — The classic overview.
[The Mythical Man-Month] Frederick P. Brooks — Critical insights on software management.

Industry References

[Agile Alliance - Agile 101] — Practical methodology basics.
[IEEE Std 830 - Software Requirements Specifications] — Professional documentation standard.

9. Final Checklist

Primary Checklist

소프트웨어 프로젝트의 성격(예: 생명 유지 장치 vs 단순 SNS)에 따라 폭포수와 애자일 중 어떤 모델이 물리적 위험을 더 잘 통제할지 논증 가능한가? (P2)
요구사항 정합성 검토 시 '완전성'과 '일관성'의 공학적 차이를 설명하고 결함을 찾아낼 수 있는가? (P2)

Secondary Checklist

비즈니스 가치가 높은 사용자 스토리를 우선순위에 따라 백로그에 배치하고 추정(Estimation)하는 과정을 주도할 수 있는가?
유지보수 단계에서 코드를 수정했을 때, 기존 기능의 영향도를 평가하는 영향도 분석(Impact Analysis) 절차를 숙지하고 있는가?

Industry Checklist

실제 개발 현장에서 JIRA나 Linear 같은 도구를 요구공학 원리에 기반하여 구성하고 팀의 작업 흐름을 통제할 수 있는가? (SFIA)
팀 내의 기술 부채가 임계점을 넘었음을 알리는 지표(배포 속도 저하, 버그 발생률 증가 등)를 식별하고 관리 전략을 제안 가능한가?