콘텐츠로 바로가기
HY_TECH_BASE

SDLC & Process

소프트웨어의 기획부터 폐기까지의 전체 생애 주기를 효율적으로 관리하기 위한 프로젝트 과정 모델과 애자일/린 엔지니어링 프로세스를 배웁니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

엔지니어링 라이프사이클 및 방법론(Engineering Lifecycle & Methodology, ELM)은 단순한 코딩을 넘어 소프트웨어가 비즈니스 가치를 창출하는 전 과정을 과학적으로 관리하는 체계를 다룹니다.

소프트웨어 개발은 수많은 요구사항의 변화와 기술적 불확실성 속에서 진행됩니다. 학습자는 폭포수(Waterfall) 모델의 구조적 안정성과 애자일(Agile) 방법론의 유연한 대응 전략을 물리적으로 비교하고, 요구사항 추출, 설계, 구현, 검사, 설치의 단계별 필수 산출물과 책임을 배웁니다. 이를 통해 프로젝트의 규모와 성격에 최적화된 프로세스를 설계하고, 예측 가능한 소프트웨어 공급 체계를 구축하는 능력을 갖춥니다.

2. Scope & Boundaries

In-Scope

  • Software Process Models: Waterfall, Incremental, Spiral, Agile(Scrum, Kanban) 물리
  • Requirements Engineering: 요구사항 도출(Elicitation), 명세화(Specification), 검증
  • Project Governance: 일정 관리, 리스크 분석, 팀 내 역할 정의 및 협업 물리
  • Maintenance & Evolution: 레거시 관리, 리팩토링의 공학적 주기 및 품질 변화

Out-of-Scope

  • 구체적인 테스트 자동화 코드 작성 (09-02 Testing 영역으로 위임)
  • 클라우드 인프라 프로비저닝 (09-03 DevOps 영역으로 위임)

Boundaries

  • ELM vs. Systems Development: ELM은 '소프트웨어 제품 자체'의 생애 주기에 집중하며, 하드웨어를 포함한 전체 '시스템' 엔지니어링 단계와 협력 관계를 유지합니다.

3. Counterexample

  • 단순히 JIRA 보드를 관리하거나 스크럼 회의를 하는 것은 ELM 학습이 아닙니다. 왜 특정 프로젝트에서 **요구사항 변경(Requirements Volatility)**이 발생하는지 그 물리적 근본 원인을 분석하고, 선택한 방법론이 그 변경을 어떻게 수용하며 전체 소프트웨어 **신뢰성(Reliability)**을 유지하는지 논리적으로 설명할 수 있어야 합니다.

4. Prerequisites

  • 컴퓨터 과학 및 공학 루트 (Basic): 공학적 사고방식과 분류 체계에 대한 이해가 필요합니다. (ROOT)
  • 정보 모델링 기초 (Recommended): 도메인 요구사항을 데이터 구조로 추상화하는 능력이 권장됩니다. (06. DPG)

5. Learning Map

  1. Defining the Needs: 모호한 비즈니스 아이디어를 명확한 엔지니어링 요구사항으로 변환하는 절차를 익힙니다.
  2. Process Navigation: 개발 팀이 따르는 다양한 로드맵(프로세스 모델)의 물리적 특성을 배웁니다.
  3. Collaboration Dynamics: 개인의 숙련도를 넘어 조직 전체가 동일한 품질의 소프트웨어를 생산하는 협업 메커니즘을 이해합니다.
  4. Iterative Flow: 한번 배포된 소프트웨어가 지속적으로 진화하며 품질을 유지하는 유지보수 역학을 탐구합니다.

6. Learning Topics

Basic

Core: SDLC 모델과 프로세스 기초 (Lifecycle Models)

  • Why to Learn: 프로젝트 환경에 맞는 표준 개발 절차를 선택하여 시행착오를 줄이기 위함입니다.
  • What to Learn:
    • SDLC(Software Development Life Cycle)의 단계별 정의
    • 순차적 모델 vs 반복적/점진적 모델의 물리적 차이
    • 소프트웨어 개발 표준(ISO/IEC 12207 등) 개념
  • How to Learn:
    • 소규모 토이 프로젝트와 대규모 금융 시스템의 개발 절차를 각각 상상하여 다이어그램으로 비교
    • '요구사항 분석' 단계가 누락되었을 때 최종 제품에서 발생할 수 있는 물리적 손실 시나리오 작성
  • Implement: 특정 프로젝트 환경에 따른 적정 SDLC 모델 선정 이유서

Core: 요구공학 및 명세화 (Requirements Engineering)

  • Why to Learn: '무엇을 만들 것인가'를 명확히 정의하여 재작업(Rework) 비용을 물리적으로 최소화하기 위해서입니다.
  • What to Learn:
    • 기능적 vs 비기능적 요구사항의 구분 및 물리적 제약
    • 유스케이스(Use Case) 및 사용자 스토리(User Story) 작성 원리
    • 요구사항 추적성(Traceability) 매트릭스 구성
  • How to Learn:
    • 실제 앱(예: 배달 앱)의 기능을 분석하여 기능적/비기능적 요구사항으로 분류하는 실습
    • 모호한 문장(예: "성능이 좋아야 함")을 측정 가능한 지표(예: "응답 지연 100ms 이내")로 치환
  • Implement: 특정 도메인의 핵심 기능에 대한 요구사항 명세서(SRS)

Practical

Core: 애자일 방법론과 팀 협업 (Agile & Team Dynamics)

  • Why to Learn: 빠르게 변화하는 요구사항에 대응하고 팀의 생산성을 극대화하기 위함입니다.
  • What to Learn:
    • 애자일 선언문의 4가지 가치와 12가지 원칙의 공학적 배경
    • 스크럼(Scrum) 프레임워크: 스프린트, 백로그, 회고의 물리적 주기
    • 칸반(Kanban): WIP(Work In Progress) 제한을 통한 리드 타임 최적화
  • How to Learn:
    • 칸반 보드를 직접 구성하고 작업의 병목(Bottleneck) 구간을 찾아 시각화하는 연습
    • 특정 기능을 스프린트 단위로 어떻게 분할하여 점진적으로 인도할지 계획 수립
  • Implement: 2주간의 가상 스프린트 운영 계획 및 작업 분할 분석표

Advanced

Core: 프로세스 개선 및 품질 거버넌스 (Process Improvement)

  • Why to Learn: 조직의 엔지니어링 성숙도를 높이고 지속 가능한 고품질 개발 체계를 구축하기 위해서입니다.
  • What to Learn:
    • CMMI 또는 SPICE 모델을 통한 프로세스 성숙도 평가
    • 재공학(Re-engineering) vs 역공학(Reverse Engineering)의 물리적 차이 및 시점 선택
    • 기술 부채(Technical Debt)의 정량적 측정 및 관리 전략
  • How to Learn:
    • 레거시 코드의 복잡도 변화 수치를 관측하고 적절한 리팩토링 배포 시점 제안 연구
    • 오픈소스 프로젝트의 커뮤니티 거버넌스와 기여 프로세스 분석
  • 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

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)
  • 팀 내의 기술 부채가 임계점을 넘었음을 알리는 지표(배포 속도 저하, 버그 발생률 증가 등)를 식별하고 관리 전략을 제안 가능한가?

Concepts & Tags

#sdlc#agile#lean#kanban#scrum