소프트웨어 개발 방법론

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• 소프트웨어 생명주기(SDLC)의 각 단계와 단계별 주요 산출물을 설명할 수 있습니다.
• 폭포수·프로토타입·나선형·애자일 모델의 특징, 장단점, 적합한 프로젝트를 비교할 수 있습니다.
• XP(익스트림 프로그래밍)의 12가지 실천법을 나열하고 핵심 가치를 설명할 수 있습니다.
• 스크럼의 3대 역할·5대 이벤트·3대 아티팩트를 정확히 구분할 수 있습니다.
• 기출에서 자주 출제되는 방법론 유형을 파악하고 정확히 구분할 수 있습니다.

📚 소프트웨어 생명주기(SDLC) 개요

이 섹션에서는 소프트웨어 개발 방법론의 토대가 되는 SDLC 개념과 단계별 산출물을 살펴보겠습니다.

소프트웨어 생명주기(Software Development Life Cycle, SDLC)란 소프트웨어가 기획되어 개발되고 최종적으로 폐기될 때까지의 전체 과정을 정형화한 프레임워크입니다. SDLC를 따르는 이유는 명확합니다. 대규모 소프트웨어를 체계 없이 개발하면 요구사항 누락, 일정 지연, 품질 저하, 유지보수 불가 등의 문제가 발생하기 때문입니다. SDLC는 각 단계에서 무엇을 해야 하는지, 무엇을 산출해야 하는지를 명확히 정의해 이러한 혼란을 방지합니다.

일반적인 SDLC는 다음 5단계로 구성됩니다. 각 단계의 핵심 활동과 주요 산출물을 함께 알아두어야 합니다.

단계	핵심 활동	주요 산출물
요구사항 분석	고객 요구사항 수집·분석·명세화	요구사항 명세서(SRS), 유즈케이스
시스템 설계	아키텍처·모듈·인터페이스·DB 설계	설계 명세서, ERD, 아키텍처 다이어그램
구현(코딩)	설계 기반 소스 코드 작성	소스 코드, 단위 테스트 결과
테스트	결함 발견, 품질 검증	테스트 계획서, 테스트 결과 보고서
유지보수	오류 수정, 기능 개선, 환경 적응	변경 요청서, 패치 노트

정보처리기사 시험에서는 각 단계의 이름뿐 아니라 해당 단계에서 생산되는 산출물(Output)을 묻는 문제가 자주 출제됩니다. 예를 들어 "요구사항 명세서(SRS)는 어느 단계의 산출물인가?"처럼 출제되므로, 단계와 산출물의 연결을 반드시 암기해야 합니다. 또한 유지보수 유형도 기출에 자주 등장합니다. 유지보수는 목적에 따라 수정(Corrective) — 오류 수정, 적응(Adaptive) — 환경 변화 대응, 완전(Perfective) — 성능·기능 개선, 예방(Preventive) — 미래 오류 예방으로 구분됩니다.

🌊 폭포수 모델 — 가장 고전적인 방법론

이 섹션에서는 소프트웨어 공학의 출발점인 폭포수 모델의 특징과 한계를 살펴보겠습니다.

폭포수 모델(Waterfall Model)은 1970년 Winston Royce가 제안한 가장 오래된 공식 SDLC 모델입니다. 이름처럼 폭포가 위에서 아래로 흐르듯, 각 단계가 완전히 완료된 후에만 다음 단계로 진행하는 순차적·선형적 개발 방법론입니다. 한 번 완료된 단계로는 되돌아갈 수 없거나 매우 어렵다는 것이 핵심 특성입니다.

폭포수 모델의 장점은 단순성과 이해 용이성입니다. 각 단계가 명확히 구분되어 진행 상황 파악이 쉽고, 문서 기반으로 진행되어 단계별 검토와 승인이 용이합니다. 소규모 프로젝트나 요구사항이 명확하게 고정된 경우에 적합합니다. 단점은 유연성 부족입니다. 개발 중반에 요구사항이 변경되면 처음 단계로 돌아가야 해 비용이 폭발적으로 증가합니다. 고객이 최종 제품을 테스트 단계에서야 처음 볼 수 있어 요구사항 불일치 리스크가 높습니다.

기출에서는 "폭포수 모델의 특징으로 옳은 것은?" 유형이 자주 출제됩니다. 핵심 키워드는 "선형 순차", "단계 간 피드백 없음", "문서 중심", "전 단계 완료 후 다음 단계"입니다. 반드시 암기하세요.

🔄 프로토타입·나선형 모델

이 섹션에서는 폭포수 모델의 한계를 극복하기 위해 등장한 프로토타입 모델과 나선형 모델을 살펴보겠습니다.

프로토타입 모델(Prototype Model)은 고객에게 시제품(Prototype)을 먼저 보여주고, 피드백을 반영해 요구사항을 정제하면서 개발하는 방법론입니다. 요구사항이 불명확하거나 고객이 원하는 것을 정확히 표현하기 어려운 경우에 효과적입니다. 초기에 빠르게 프로토타입을 만들어 고객에게 제시하고, 평가와 수정을 반복하다가 최종적으로 제품을 완성합니다.

장점은 고객과의 소통이 원활해 요구사항 오해를 조기에 발견할 수 있다는 것입니다. 단점은 고객이 프로토타입을 최종 제품으로 오해하거나, 불필요한 기능이 계속 추가되는 기능 확장(Scope Creep) 문제가 발생할 수 있다는 것입니다. 또한 급하게 만든 프로토타입 코드를 실제 제품에 그대로 사용하려는 유혹이 생겨 품질이 저하될 수 있습니다.

나선형 모델(Spiral Model)은 1988년 Barry Boehm이 제안한 방법론으로, 폭포수 모델과 프로토타입 모델을 결합하고 여기에 위험 분석(Risk Analysis)을 추가한 것이 핵심입니다. 나선형처럼 반복적으로 사이클을 돌면서 시스템을 점진적으로 완성해 나갑니다. 각 사이클은 계획 → 위험 분석 → 개발 및 검증 → 고객 평가의 4단계로 구성됩니다.

나선형 모델의 가장 큰 특징은 위험 관리(Risk Management)를 개발 프로세스에 공식적으로 포함했다는 점입니다. 대형 프로젝트나 리스크가 높은 프로젝트에 적합합니다. 단점은 모델 자체가 복잡하고, 위험 분석 전문가가 필요하며, 소규모 프로젝트에는 과도한 오버헤드가 발생한다는 것입니다. 기출 키워드: "위험 분석 중심", "점진적 개발", "대형 시스템에 적합".

모델	핵심 특징	적합한 상황	기출 키워드
폭포수	선형 순차, 단계 간 피드백 없음	요구사항 고정, 소규모	선형, 문서 중심
프로토타입	시제품 반복 평가, 요구사항 정제	요구사항 불명확	시제품, 피드백
나선형	위험 분석 + 점진적 개발	대형 시스템, 고위험	위험 분석, 점진적
애자일	짧은 반복 사이클, 변화 수용	요구사항 변동 잦음	스프린트, 자기 조직화

⚡ 애자일과 XP — 변화에 유연하게 대응

이 섹션에서는 현대 소프트웨어 개발의 주류인 애자일 방법론과 그 대표 구현체인 XP를 살펴보겠습니다.

애자일(Agile)은 2001년 "애자일 소프트웨어 개발 선언(Agile Manifesto)"으로 공식화된 소프트웨어 개발 철학입니다. 핵심은 짧은 반복 주기(이터레이션)로 동작하는 소프트웨어를 빠르게 제공하고, 변화하는 요구사항을 적극 수용한다는 것입니다. 애자일 선언의 4가지 핵심 가치를 반드시 기억하세요.

1. 개인과 상호작용 > 프로세스와 도구
2. 동작하는 소프트웨어 > 포괄적인 문서
3. 고객과의 협력 > 계약 협상
4. 변화에 대응 > 계획 준수

이 4가지 가치에서 주의할 점은 ">"가 "더 중요하게 여긴다"는 의미이지, 오른쪽 항목을 완전히 무시한다는 뜻이 아닙니다. 기출에서 오른쪽 항목을 "전혀 중요하지 않다"로 서술한 오답이 자주 등장하므로 주의하세요.

XP(Extreme Programming)는 켄트 벡(Kent Beck)이 제안한 애자일 방법론의 구체적인 실천 프레임워크입니다. XP의 5가지 핵심 가치는 의사소통(Communication), 단순성(Simplicity), 피드백(Feedback), 용기(Courage), 존중(Respect)입니다. 이 가치들을 실천하기 위한 12가지 실천법은 시험 빈출 항목입니다.

구분	실천법	설명
계획	계획 게임(Planning Game)	고객과 개발자가 함께 릴리즈 계획 수립
	소규모 릴리즈(Small Release)	짧은 주기로 자주 배포
	메타포(Metaphor)	시스템을 쉬운 비유로 공유된 이해 형성
	지속 가능한 속도(Sustainable Pace)	초과 근무 없이 지속 가능한 개발 속도 유지
설계	단순한 설계(Simple Design)	현재 요구사항만 충족하는 가장 단순한 설계
	리팩토링(Refactoring)	기능 변경 없이 코드 구조 개선
	CRC 카드(CRC Cards)	클래스·책임·협력 카드로 설계 논의
	스파이크 솔루션(Spike Solution)	기술적 위험 탐구를 위한 빠른 실험 코드
코딩	고객 상주(On-site Customer)	고객이 개발팀 옆에서 즉시 피드백 제공
	코딩 표준(Coding Standards)	팀 전체가 따르는 코딩 규칙
	페어 프로그래밍(Pair Programming)	두 사람이 한 컴퓨터에서 함께 코딩
	집단 코드 소유(Collective Ownership)	모든 팀원이 모든 코드를 수정할 수 있음
테스팅	테스트 주도 개발(TDD)	코드 작성 전 테스트 먼저 작성
	지속적 통합(Continuous Integration)	자주 코드 통합하고 빌드·테스트 수행

기출에서는 "XP의 실천법이 아닌 것은?" 또는 "XP의 실천법에 해당하는 것은?" 유형으로 출제됩니다. 특히 페어 프로그래밍, TDD, 리팩토링, 지속적 통합, 고객 상주는 빈출 실천법이므로 꼭 암기하세요.

🏃 스크럼 — 역할·이벤트·아티팩트

이 섹션에서는 현재 가장 널리 사용되는 애자일 프레임워크인 스크럼의 구성 요소를 살펴보겠습니다.

스크럼(Scrum)은 제프 서덜랜드와 켄 슈와버가 1990년대에 정립한 애자일 프레임워크입니다. 이름은 럭비에서 팀이 뭉쳐 전진하는 "스크럼" 대형에서 따왔습니다. 스크럼은 복잡하고 불확실한 문제를 다룰 때 경험주의(Empiricism)를 기반으로, 즉 실제로 해보고 검토하고 적응하는 방식으로 접근합니다.

스크럼은 3대 역할(Role), 5대 이벤트(Event), 3대 아티팩트(Artifact)로 구성됩니다. 이 구성은 시험에서 매우 자주 출제되므로 모두 암기해야 합니다.

3대 역할(Roles)

• 제품 책임자(Product Owner, PO): 제품 백로그를 관리하고 우선순위를 결정합니다. 비즈니스 가치를 최대화하는 것이 주요 책임이며, 고객과 개발팀 사이의 가교 역할을 합니다. "무엇을 만들지"를 결정하는 사람입니다.
• 스크럼 마스터(Scrum Master): 스크럼 프로세스가 올바르게 진행되도록 팀을 지원하는 코치이자 퍼실리테이터입니다. 장애물(Impediment)을 제거하고 팀이 자기 조직화할 수 있도록 돕습니다. 팀의 관리자가 아닌 서번트 리더입니다.
• 개발팀(Development Team): 스프린트마다 동작하는 제품 증분을 만들어내는 3~9명의 자기 조직화된 팀입니다. 기획자·디자이너·개발자·테스터 등 모든 기능을 갖춘 크로스 펑셔널(Cross-functional) 팀입니다.

5대 이벤트(Events)

• 스프린트(Sprint): 1~4주 길이의 반복 개발 주기입니다. 스프린트 내에서 동작 가능한 제품 증분이 만들어집니다. 스크럼의 핵심 이벤트로, 다른 모든 이벤트는 스프린트 안에 포함됩니다.
• 스프린트 계획(Sprint Planning): 스프린트 시작 시 팀이 모여 이번 스프린트에서 무엇을 달성할지 계획하는 회의입니다. 제품 백로그에서 항목을 선택해 스프린트 백로그를 만듭니다.
• 일일 스크럼(Daily Scrum): 매일 15분 동안 진행하는 개발팀의 동기화 회의입니다. "어제 무엇을 했는가, 오늘 무엇을 할 것인가, 장애물은 무엇인가"의 3가지를 공유합니다.
• 스프린트 검토(Sprint Review): 스프린트 종료 시 완성된 증분을 이해관계자에게 시연하고 피드백을 받는 회의입니다. 제품 백로그를 업데이트하는 계기가 됩니다.
• 스프린트 회고(Sprint Retrospective): 팀이 스프린트 프로세스를 돌아보고 개선점을 찾는 회의입니다. "잘 된 것, 개선할 것, 실행할 것"을 논의합니다. 스프린트 검토 후, 다음 스프린트 계획 전에 진행합니다.

3대 아티팩트(Artifacts)

• 제품 백로그(Product Backlog): 제품에 필요한 모든 기능·요구사항·개선사항·수정사항의 우선순위가 정렬된 목록입니다. 제품 책임자가 소유하고 관리합니다. 살아있는 문서로 지속적으로 갱신됩니다.
• 스프린트 백로그(Sprint Backlog): 현재 스프린트에서 완료할 제품 백로그 항목들과 그것을 달성하기 위한 계획입니다. 개발팀이 소유합니다.
• 증분(Increment): 스프린트가 끝날 때마다 완성되는 동작 가능한 소프트웨어입니다. 이전 모든 스프린트 증분의 합계이며, "완료의 정의(Definition of Done)"를 만족해야 합니다.

📝 핵심 요약과 기출 유형 분석

1강에서 배운 내용을 정리하고 자주 출제되는 기출 유형을 살펴보겠습니다.

모델/방법론	핵심 암기 키워드	빈출 기출 포인트
폭포수	선형 순차, 이전 단계 완료 필수	피드백 없음, 문서 중심
프로토타입	시제품, 요구사항 불명확 시 적합	기능 확장 위험, 의사소통 향상
나선형	위험 분석, 4단계 반복(계획→위험→개발→평가)	대형 시스템, 위험 관리 포함
XP	12가지 실천법 전체	페어프로그래밍·TDD·리팩토링·고객 상주
스크럼	3역할·5이벤트·3아티팩트	PO vs SM 역할 구분, 이벤트 순서

기출 빈출 함정 패턴을 정리해 보겠습니다. 첫째, "스크럼 마스터는 팀의 관리자이다" — 오답입니다. 스크럼 마스터는 서번트 리더이지 관리자가 아닙니다. 둘째, "XP의 핵심 가치는 4가지이다" — 오답입니다. 의사소통·단순성·피드백·용기·존중으로 5가지입니다. 셋째, "애자일은 문서를 전혀 작성하지 않는다" — 오답입니다. 포괄적인 문서보다 동작하는 소프트웨어를 더 중요시하지만, 문서가 불필요하다는 것이 아닙니다. 넷째, "나선형 모델은 폭포수 모델과 프로토타입 모델을 결합한 것이다" — 정답입니다. 여기에 위험 분석을 추가한 것이 나선형 모델입니다.

다음 강인 2강 — 요구사항 분석과 UML에서는 시스템 개발의 첫 번째 핵심 단계인 요구사항 분석 기법과, 소프트웨어 구조를 시각화하는 UML 다이어그램 5종을 완전히 익힙니다. 기출에서 가장 많이 출제되는 유즈케이스 다이어그램의 관계 표기법을 집중적으로 학습합니다!