SDLC Models & Agile Dynamics

1. Overview

SDLC 모델과 애자일 역학(SDLC Models & Agile Dynamics)은 코드만 짜면 끝인 줄 알았던 주니어의 환상을 부수고, 소프트웨어가 탄생하고 죽기까지의 전체 생명주기(Software Development Life Cycle)를 지배하는 거대한 프로세스와 협업의 물리학을 해부합니다.

학습자는 고객이 요구사항을 바꿀 때마다 설계와 코드를 처음부터 다시 뒤엎어야 했던 폭포수(Waterfall) 모델의 비극을 뜯어봅니다. 나아가 거대한 코끼리 같은 프로젝트를 2주짜리 작은 덩어리(Sprint)로 썰어내어, 변화하는 시장에 미친 듯이 빠르게 대응하는 애자일(Agile)과 스크럼(Scrum)의 점진적(Iterative) 개발 철학을 장악합니다. 마지막으로, 개발자(Dev)와 운영자(Ops)가 서로 책임을 떠넘기던 장벽을 부수고, 코드 커밋부터 배포까지를 하나의 자동화된 파이프라인으로 연결하는 데브옵스(DevOps) 문화의 태동 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Waterfall Model: 요구사항 분석 $\rightarrow$ 설계 $\rightarrow$ 구현 $\rightarrow$ 테스트 $\rightarrow$ 유지보수의 엄격한 순차적 흐름과 그 한계.
• Agile & Scrum: 스프린트(Sprint), 스크럼 마스터, 프로덕트 오너(PO), 데일리 스크럼, 회고(Retrospective).
• Iterative & Incremental: 완성도를 서서히 높여가는 점진적(Iterative) 모델과, 기능 덩어리를 하나씩 붙여나가는 증분적(Incremental) 모델의 결합.
• DevOps Culture: 개발과 운영의 사일로(Silo) 타파, CI/CD 자동화 사상의 기초.

Out-of-Scope

• CI/CD 파이프라인 구현(Jenkins, GitHub Actions): 파이프라인 스크립트를 짜는 구체적 기술 $\rightarrow$ 09-05 DevOps & Reliability 영역으로 위임.
• 객체지향 설계(SOLID) 및 디자인 패턴: 코드 레벨의 아키텍처 설계 $\rightarrow$ 09-03 Architecture & Design 영역으로 분리.

Boundaries

• Waterfall vs Agile: 폭포수(Waterfall) 모델은 건축과 같습니다. 아파트를 다 짓고 나서 "안방 위치를 바꿔주세요"라고 하면 건물을 부숴야 합니다(요구사항 변경 불가). 반면 애자일(Agile)은 레고 조립과 같습니다. "이번 주에는 거실만 먼저 만들어서 보여드릴게요. 마음에 안 들면 다음 주에 고치죠." 이처럼 '변경에 대한 저항'과 '변경에 대한 수용'이라는 프로세스의 근본적 태도 차이에 명확한 경계를 긋습니다.

3. Counterexample

• 빅뱅 릴리즈의 폭망 (Big-Bang Release): 1년간 폭포수 모델로 쇼핑몰을 개발했습니다. 개발팀은 기획서에 적힌 대로 완벽하게 만들었다고 자부하며 오픈(Big-Bang Release)했습니다. 그러나 1년 사이 시장 트렌드가 바뀌어 고객들은 모바일 페이를 원하는데, 쇼핑몰은 구형 카드 결제만 지원했습니다. 고객 피드백 없이 지하 창고에서 1년을 허비한 끝에 수십억짜리 프로젝트가 오픈 당일 쓰레기통으로 직행한 폐쇄적 프로세스의 재앙입니다.
• 가짜 애자일(Fake Agile)과 번아웃: 회사에서 "오늘부터 애자일 한다!"라며 매일 아침 데일리 스크럼을 시작했습니다. 그런데 2주짜리 스프린트 안에 기획이 수시로 바뀌고, 프로덕트 오너(PO)는 "애자일이니까 내일 당장 이 기능 추가해"라며 폭군처럼 군림합니다. 문서도 없고, 설계도 없이 코드만 땜질하다가 스파게티 코드가 쌓였습니다. 애자일을 '계획 없는 막무가내 개발'로 오해하여 기술 부채(Tech Debt)가 폭발하고 개발자들이 번아웃에 빠진 프로세스 붕괴입니다.

4. Prerequisites

• 소프트웨어 공학의 위기 (Basic): 1960년대 소프트웨어 위기와 공학적 접근의 필요성.
• 협업과 형상 관리 (Basic): Git 등을 이용한 다수 개발자의 협업. (09-01-04 Construction)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 기획 무결성의 환상 (The Waterfall Trap)

• Why to Learn: 건축업에서 빌려온 '폭포수 모델'이 눈에 보이지 않는 소프트웨어 개발에서는 왜 치명적인 결함을 가지는지, 그 태생적 한계를 깨닫고 현대적 프로세스의 필요성을 통찰하기 위함입니다.
• What to Learn:
  • Concepts: Waterfall Model, Requirement Analysis, Sequential Flow, Big-Bang Integration, Cost of Change.
  • Skills: 프로젝트 후반부(테스트 단계)에 고객이 "기획이 잘못됐어, A 기능 빼고 B 기능 넣어"라고 요구했을 때 발생하는 재설계/재코딩의 끔찍한 시간과 매몰 비용(Cost) 차트 도해.
• How to Learn:
  • 1단계: 일방통행의 폭포수: 물은 위에서 아래로만 떨어집니다. 요구사항 정의 -> 설계 -> 구현 -> 테스트 -> 배포. 각 단계는 이전 단계가 '완벽히' 끝나야만 다음으로 넘어갑니다.
  • 2단계: 뒤늦은 통합의 지옥 (Big-Bang): 개발자들이 각자 6개월 동안 자기 컴퓨터에서 코드를 짰습니다. 배포 한 달 전, 이 코드들을 처음으로 하나로 합칩니다(통합). 수백 개의 에러가 뻥뻥 터집니다. "내 컴퓨터에선 됐는데?"라며 싸웁니다.
  • 3단계: 변경 비용의 폭발: 개발 초기에 기획을 바꾸는 건 문서 한 줄 지우면 끝입니다($10). 하지만 테스트 단계에서 기획을 바꾸면, DB 설계, 백엔드 로직, 프론트 화면, 테스트 코드를 다 뜯어고쳐야 합니다($10,000). 변경을 억누르는 이 굳건한 벽을 해부합니다.
• Implement: 폭포수 프로세스 실패 모사 시뮬레이터. Months 1-2: 완벽한 100페이지 기획서 작성. Months 3-5: 코드 구현 (고객은 코드 못 봄). Month 6: 통합 및 첫 데모 시연. 고객 피드백: "이거 내가 원하던 거 아닌데요?" $\rightarrow$ [SYSTEM HALTED] 타임라인 롤백 불가능 판정 렌더링.

Recommended

Core Topic 02: 2주의 전력 질주, 스크럼 (Agile & Scrum Physics)

• Why to Learn: 1년 뒤의 완벽한 실패보다 2주 뒤의 불완전한 성공을 누적시켜, 변화하는 시장 요구에 민첩하게 대응(Agile)하는 현대 IT 기업의 표준 생존법을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Agile Manifesto, Scrum Framework, Sprint, Product Owner (PO), Scrum Master, Daily Scrum, Sprint Retrospective.
  • Skills: 100개의 기능 리스트(Product Backlog) 중, 가장 가치가 높은 5개를 뽑아내 2주 동안 완성할 수 있는 스프린트 백로그(Sprint Backlog)로 추산(Story Point)하고 분배하는 협업 설계.
• How to Learn:
  • 1단계: 거대한 문서를 찢어라: 애자일은 '문서보다 작동하는 소프트웨어'를 중시합니다. 기획서 100페이지를 쓰는 대신, 지금 당장 필요한 로그인 화면을 2주 만에 만들어서 고객에게 보여주고 욕(피드백)을 먹는 걸 택합니다.
  • 2단계: 스크럼의 3역할: Product Owner(PO)는 "무엇(What)을 만들까?" 우선순위를 정합니다. 개발팀은 "어떻게(How) 만들까?"를 고민하며 달립니다. Scrum Master는 이들이 싸우지 않고 잘 달리도록 방해물을 치워줍니다.
  • 3단계: 2주의 심장 박동 (Sprint): 2주 동안 맹렬히 달려서(Sprint) 무조건 '동작하는 결과물' 하나를 뱉어냅니다. 끝나면 회고(Retrospective)를 통해 "이번 2주간 우리가 뭘 삽질했지? 다음 2주는 어떻게 개선할까?"라며 팀 스스로 진화하는 메커니즘을 뜯어봅니다.
• Implement: 스프린트 번다운 차트(Burndown Chart) 추적기. Sprint Day 1: 50 Story Points 남음. Day 5: 예기치 못한 버그 발생 $\rightarrow$ 포인트 차감 정체. Day 10 (End): 10 포인트 못 끝냄. 회고 로직: 남은 10 포인트를 다음 스프린트로 이월하고, "왜 버그 산정에 실패했는가?" 원인을 분석하여 다음 스프린트의 벨로시티(Velocity)를 40으로 하향 조정하는 자기 객관화 시각화.

Practical

Core Topic 03: 점진과 증분, 진화의 두 축 (Iterative vs Incremental)

• Why to Learn: "애자일은 대충 빨리 짜는 것"이라는 주니어의 치명적 오해를 바로잡고, 스케치를 구체화하는 '점진성'과 블록을 쌓아 올리는 '증분성'의 차이를 이해하여 아키텍처 진화의 방향타를 쥐기 위함입니다.
• What to Learn:
  • Concepts: Iterative (점진적/반복적), Incremental (증분적), Minimum Viable Product (MVP), Agile Evolution.
  • Skills: 모나리자를 그릴 때 (1) 점진적: 전체 윤곽선 스케치 $\rightarrow$ 흑백 명암 $\rightarrow$ 컬러 입히기 방식과 (2) 증분적: 머리 완벽히 완성 $\rightarrow$ 몸통 완성 $\rightarrow$ 다리 완성 방식의 차이를 인프라 구축(MVP) 모델에 대입하여 비교 분석하기.
• How to Learn:
  • 1단계: Incremental (블록 쌓기): 쇼핑몰을 만듭니다. 스프린트 1에서 '회원가입'을 완벽하게(DB, API, 보안 다 챙겨서) 만듭니다. 스프린트 2에서 '결제'를 완벽하게 만듭니다. 레고 블록을 하나씩 붙이는 겁니다. 문제는, 3달 뒤 결제 모듈이 완성되기 전까지는 쇼핑몰에서 돈을 벌 수 없습니다.
  • 2단계: Iterative (해상도 높이기): 일단 전체 그림을 대충 그립니다(MVP). 스프린트 1에서 '로그인 안 됨, 무통장 입금만 됨, UI 구림' 상태로 일단 런칭해서 물건을 팝니다. 스프린트 2에서 UI를 예쁘게 고칩니다. 스프린트 3에서 카드 결제를 붙입니다. 애자일은 이 Iterative(점진)와 Incremental(증분)을 결합하여, 가장 뼈대가 되는 가치(MVP)를 먼저 던지고 끊임없이 깎아 나가는 예술적 엔지니어링을 해부합니다.
• Implement: MVP 기반 Iterative 배포 시뮬레이션. 목표: 유저 간 채팅 앱 만들기. Iteration 1 (MVP): 소켓 통신 없는 단순 HTTP 새로고침 게시판 (1주 완성, 즉각 고객 반응 확인). Iteration 2: 유저의 불만(새로고침 귀찮다) 수집 후 WebSocket 적용. Iteration 3: 이모티콘 기능 추가. 처음부터 WebSocket과 이모티콘을 3달간 깎고 앉아있는 폭포수 장인 정신을 박살 내는 피드백 루프 렌더링.

Advanced

Core Topic 04: 사일로를 부수는 망치, 데브옵스 (The Dawn of DevOps)

• Why to Learn: 개발(Dev)과 운영(Ops)이 서로 남 탓을 하며 대립하던 이기주의의 벽을 허물고, "내가 짠 코드는 내가 서버에 올리고 내가 책임진다"는 궁극의 엔지니어링 문화, DevOps의 태동을 장악하기 위함입니다.
• What to Learn:
  • Concepts: Silo Effect, DevOps, Continuous Integration (CI), Continuous Deployment (CD), You Build It You Run It (Werner Vogels).
  • Skills: 개발자가 코드를 던지면 운영자가 야근하며 배포하던 '수동 배포' 파이프라인의 고통을 나열하고, 이를 Git Commit 한 방에 자동 배포되도록 엮어야 하는 조직 문화적 필요성 도출.
• How to Learn:
  • 1단계: 사일로(Silo)의 전쟁: 개발자는 '새로운 기능 추가'가 목표입니다. 코드를 미친 듯이 만들어 운영팀 담장 너머로 집어 던집니다. 운영자는 '서버 안정성'이 목표입니다. 툭하면 서버를 죽이는 개발자의 새 코드가 꼴도 보기 싫어 배포를 한 달에 한 번으로 막아버립니다. 둘은 영원한 원수입니다.
  • 2단계: You build it, You run it: 아마존 CTO의 선언입니다. "네가 짠 코드, 네가 서버에 올려서 운영해." 개발팀과 운영팀을 한 팀(DevOps)으로 합칩니다.
  • 3단계: 고통의 자동화: 내가 짠 코드를 내가 배포해야 하니, 배포하다 에러 나면 내가 새벽에 일어나야 합니다. 너무 빡치니까 배포 과정을 자동화(CI/CD)하고, 에러 모니터링을 스크립트로 짜기 시작합니다. 이기주의를 부수기 위해 인프라를 코드로 다루기 시작한(IaC) 데브옵스 철학의 위대한 첫걸음을 뜯어봅니다.
• Implement: Dev vs Ops 핑퐁 디버깅 롤플레잉 모사. Developer: "새로운 AI 기능 배포 파일(app.zip) 넘깁니다." Operator: "압축 풀고 서버 띄웠는데 에러 나네요. 롤백합니다." Developer: "제 로컬 맥북에선 잘 되는데요? 서버 환경(OS) 설정 잘못하신 거 아님?" Operator: "님 코드가 메모리 누수 낸 거임." 이 끔찍한 며칠 간의 핑퐁 낭비를 Docker와 CI/CD 한 방으로 없애버리는 인프라 통합 파이프라인 구조도 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Software Engineering (SE) - Software Processes (Agile, Waterfall)
• [P5] SFIA - Project Management (PRMG) - Agile Development and DevOps

Secondary

• [The Mythical Man-Month] Frederick P. Brooks Jr. - System Development Models
• [Scrum: The Art of Doing Twice the Work in Half the Time] Jeff Sutherland - Sprint and Roles

Industry

• [Agile Manifesto] - Principles behind the Agile Manifesto
• [AWS DevOps Architecture] - What is DevOps? Culture and Practices

9. Final Checklist

Primary

• 요구사항 정의부터 유지보수까지 일방통행으로 흐르는 폭포수(Waterfall) 모델에서, 프로젝트 후반부에 요구사항이 변경되었을 때 발생하는 기하급수적인 수정 비용(Cost of Change)을 설명할 수 있는가?
• 짧은 주기(Sprint)로 동작하는 소프트웨어를 고객에게 던져주고 피드백을 수용하는 애자일(Agile) 철학이, 시장 변화에 따른 불확실성 리스크를 어떻게 낮추는지 증명할 수 있는가?

Secondary

• 스크럼 프레임워크에서 "무엇을 만들지" 결정하는 Product Owner(PO)와, "어떻게 잘 달릴지" 조력하는 Scrum Master의 역할을 명확히 분리하여 팀 내 권력 충돌을 방어하는 메커니즘을 해부할 수 있는가?
• 완벽한 자동차 바퀴를 먼저 만드는 증분적(Incremental) 방식 대신, 킥보드 $\rightarrow$ 자전거 $\rightarrow$ 오토바이 $\rightarrow$ 자동차 순으로 진화시키는 점진적(Iterative) MVP 전략의 비즈니스적 타당성을 평가할 수 있는가?

Industry

• 개발(Dev) 부서는 잦은 배포를 원하고 운영(Ops) 부서는 시스템 안정을 원하여 발생하는 사일로(Silo) 대립을, 데브옵스(DevOps) 문화가 어떻게 하나의 목표(빠르고 안전한 가치 전달)로 통합해 내는지 논증할 수 있는가?
• 스프린트가 끝날 때마다 진행하는 회고(Retrospective) 회의에서, 남 탓(Blaming)을 배제하고 프로세스 자체의 문제점(예: "이번 2주간 왜 예상 스토리 포인트를 달성하지 못했는가?")을 찾아내어 다음 스프린트의 벨로시티(Velocity)를 튜닝하는 자기 주도적 개선을 설계할 수 있는가?