정보처리기사 실기 소프트웨어 개발 생명주기 SDLC

---

1. 정의

1-1. 소프트웨어 개발 생명주기란?

소프트웨어 개발 생명주기는 소프트웨어를 개발할 때 거치는 전체 과정을 말한다.

영어로는 SDLC라고 한다.

SDLC는 Software Development Life Cycle의 약자다.

• Software = 소프트웨어
• Development = 개발
• Life Cycle = 생명주기

생명주기는 어떤 대상이 시작되고, 만들어지고, 사용되고, 수정되고, 끝나는 전체 흐름을 뜻한다.

따라서 SDLC는 소프트웨어를 처음 계획하는 단계부터 분석, 설계, 구현, 테스트, 배포, 유지보수까지 이어지는 전체 개발 흐름이다.

1-2. 소프트웨어란?

소프트웨어는 컴퓨터나 스마트폰에서 실행되는 프로그램이다.

예를 들면 다음이 모두 소프트웨어다.

• 웹사이트
• 모바일 앱
• 쇼핑몰
• 게시판
• 은행 앱
• 병원 예약 시스템
• 회사 업무 관리 시스템
• 학교 학사 관리 시스템

1-3. 소프트웨어 개발이란?

소프트웨어 개발은 사용자가 원하는 문제를 해결하기 위해 프로그램을 만드는 작업이다.

단순히 코드를 작성하는 것만 개발이 아니다.

개발에는 다음 작업이 모두 포함된다.

• 무엇을 만들지 정하는 작업
• 필요한 기능을 분석하는 작업
• 화면과 데이터 구조를 설계하는 작업
• 실제 코드를 작성하는 작업
• 기능이 제대로 동작하는지 테스트하는 작업
• 사용자가 사용할 수 있게 배포하는 작업
• 배포 후 오류를 수정하고 기능을 개선하는 작업

1-4. 소프트웨어 개발 생명주기를 쉽게 이해하기

게시판을 만든다고 가정한다.

바로 코드를 작성하면 안 된다.

먼저 무엇을 만들지 정해야 한다.

• 회원만 글을 쓸 수 있는가
• 비회원도 글을 볼 수 있는가
• 댓글 기능이 필요한가
• 첨부파일 기능이 필요한가
• 관리자 기능이 필요한가
• 검색 기능이 필요한가

그다음 화면을 설계한다.

데이터베이스 구조를 설계한다.

서버 기능을 만든다.

기능이 제대로 동작하는지 테스트한다.

완성된 프로그램을 실제 서버에 배포한다.

배포 후 오류를 고치고 기능을 개선한다.

이 전체 흐름이 소프트웨어 개발 생명주기다.

---

2. 필요한 이유

2-1. 개발을 순서대로 진행하기 위해 필요하다

소프트웨어 개발은 단순히 코드를 작성하는 일이 아니다.

실제 개발에서는 여러 사람이 함께 작업한다.

• 기획자
• 디자이너
• 프론트엔드 개발자
• 백엔드 개발자
• 데이터베이스 담당자
• 테스터
• 보안 담당자
• 운영 담당자

개발 순서가 없으면 각자 다르게 이해하고 작업할 수 있다.

그 결과 필요한 기능이 빠질 수 있다.

불필요한 기능을 만들 수도 있다.

오류가 많은 상태로 배포될 수도 있다.

SDLC는 개발 단계를 정리해서 이런 문제를 줄여준다.

2-2. 요구사항을 정확히 반영하기 위해 필요하다

요구사항은 사용자가 시스템에 원하는 기능이나 조건이다.

예를 들어 사용자가 “회원만 글을 작성할 수 있어야 한다”고 요구했다고 하자.

그런데 개발자가 비회원도 글을 작성할 수 있게 만들면 잘못된 개발이다.

이런 문제를 막기 위해 개발 초기에 요구사항을 확인하고 분석한다.

2-3. 개발 비용과 시간을 줄이기 위해 필요하다

개발 초기에 잘못된 방향으로 만들면 나중에 다시 고쳐야 한다.

이미 만든 기능을 다시 고치는 작업은 시간이 많이 든다.

데이터베이스 구조를 잘못 설계하면 수정이 더 어렵다.

시스템 구조를 잘못 잡으면 기능을 추가할 때마다 코드가 계속 꼬일 수 있다.

그래서 SDLC는 개발 전에 분석과 설계를 중요하게 본다.

2-4. 품질을 높이기 위해 필요하다

품질은 소프트웨어가 요구사항에 맞게 안정적으로 동작하는 정도를 말한다.

테스트 없이 배포하면 오류가 사용자에게 바로 노출된다.

보안 검토 없이 배포하면 개인정보가 유출될 수 있다.

성능 검토 없이 배포하면 사용자가 많아졌을 때 시스템이 느려질 수 있다.

SDLC는 테스트와 유지보수 과정을 포함해서 소프트웨어 품질을 높인다.

2-5. 실제 개발에서 해결하는 문제

• 무엇을 만들어야 하는지 불명확한 문제
• 개발 중 요구사항이 계속 바뀌는 문제
• 설계 없이 개발해서 코드가 복잡해지는 문제
• 테스트 부족으로 오류가 발생하는 문제
• 배포 후 장애 원인을 찾기 어려운 문제
• 문서가 없어 유지보수가 어려운 문제
• 보안 검토가 부족해 취약점이 생기는 문제

---

3. 핵심 개념

3-1. SDLC 기본 단계

SDLC는 일반적으로 다음 단계로 구성된다.

1. 계획
2. 요구사항 분석
3. 설계
4. 구현
5. 테스트
6. 배포
7. 유지보수

계획

계획은 소프트웨어 개발의 목표와 범위를 정하는 단계다.

무엇을 만들지, 왜 만들지, 언제까지 만들지, 어떤 인원이 필요한지 정한다.

예를 들어 게시판을 만든다면 회원 게시판인지, 공지사항 게시판인지, 관리자 게시판인지 정한다.

요구사항 분석

요구사항 분석은 사용자가 원하는 기능과 조건을 정리하는 단계다.

요구사항은 기능 요구사항과 비기능 요구사항으로 나눌 수 있다.

기능 요구사항은 시스템이 제공해야 하는 기능이다.

예를 들면 로그인, 회원가입, 글 작성, 검색 기능이 있다.

비기능 요구사항은 기능은 아니지만 시스템이 만족해야 하는 조건이다.

예를 들면 보안, 성능, 안정성, 사용성, 접근성이 있다.

설계

설계는 요구사항을 바탕으로 시스템 구조를 정하는 단계다.

화면 구조, 데이터베이스 구조, 프로그램 구조, API 구조를 정한다.

API는 프로그램끼리 데이터를 주고받기 위한 약속이다.

구현

구현은 설계한 내용을 실제 코드로 작성하는 단계다.

개발이라고도 한다.

프론트엔드, 백엔드, 데이터베이스 작업이 이 단계에서 이루어진다.

테스트

테스트는 만든 기능이 요구사항대로 동작하는지 확인하는 단계다.

오류를 찾고 수정하기 위해 필요하다.

배포

배포는 완성된 소프트웨어를 실제 사용자가 사용할 수 있는 환경에 올리는 단계다.

개발자 컴퓨터에서만 실행되는 상태는 배포가 아니다.

유지보수

유지보수는 배포 후 소프트웨어를 수정하고 개선하는 단계다.

오류 수정, 기능 추가, 성능 개선, 보안 패치가 포함된다.

---

3-2. 개발 방법론

개발 방법론은 소프트웨어를 어떤 순서와 방식으로 개발할지 정한 절차다.

SDLC는 개발 전체 흐름이다.

개발 방법론은 그 흐름을 실제로 진행하는 방식이다.

대표적인 개발 방법론은 다음과 같다.

• 폭포수 모델
• 프로토타입 모델
• 나선형 모델
• 애자일 모델
• 스크럼
• XP

---

3-3. 폭포수 모델

폭포수 모델은 개발 단계를 위에서 아래로 순서대로 진행하는 전통적인 개발 방법론이다.

영어로는 Waterfall Model이라고 한다.

폭포수가 위에서 아래로 떨어지듯이 이전 단계가 끝나면 다음 단계로 넘어간다.

일반적인 순서는 다음과 같다.

1. 요구사항 분석
2. 설계
3. 구현
4. 테스트
5. 배포
6. 유지보수

폭포수 모델은 단계가 명확하다.

문서화가 잘 된다.

요구사항이 명확한 프로젝트에 적합하다.

하지만 개발 중간에 요구사항이 바뀌면 대응하기 어렵다.

폭포수 모델 장점

• 단계가 명확하다.
• 관리하기 쉽다.
• 문서화가 잘 된다.
• 요구사항이 명확할 때 안정적으로 진행할 수 있다.

폭포수 모델 단점

• 요구사항 변경에 약하다.
• 사용자가 결과물을 늦게 확인한다.
• 초기 분석이 잘못되면 후반 수정 비용이 커진다.

---

3-4. 프로토타입 모델

프로토타입 모델은 본격 개발 전에 시제품을 먼저 만들어 사용자 의견을 확인하는 개발 방법론이다.

프로토타입은 완성품이 아니라 미리 만들어보는 임시 버전이다.

사용자가 요구사항을 정확히 설명하기 어려울 때 유용하다.

예를 들어 사용자가 “쓰기 쉬운 관리자 화면이 필요하다”고 말할 수 있다.

하지만 “쓰기 쉬운 화면”은 사람마다 다르게 이해할 수 있다.

이때 간단한 화면 시안을 먼저 만들어 보여주면 사용자의 의견을 더 정확히 받을 수 있다.

프로토타입 모델의 일반적인 흐름은 다음과 같다.

1. 기본 요구사항 수집
2. 프로토타입 제작
3. 사용자 평가
4. 요구사항 보완
5. 본격 개발

프로토타입 모델 장점

• 사용자 요구사항을 빠르게 확인할 수 있다.
• 사용자가 결과물을 미리 볼 수 있다.
• 요구사항 오류를 초기에 줄일 수 있다.

프로토타입 모델 단점

• 사용자가 시제품을 완성품으로 오해할 수 있다.
• 시제품을 만드는 데 추가 시간이 필요하다.
• 임시로 만든 구조를 그대로 사용하면 품질이 떨어질 수 있다.

---

3-5. 나선형 모델

나선형 모델은 반복 개발과 위험 분석을 결합한 개발 방법론이다.

영어로는 Spiral Model이라고 한다.

나선형 모델은 계획, 위험 분석, 개발, 평가를 반복한다.

여기서 위험은 프로젝트 실패 가능성을 높이는 요소다.

예를 들면 다음이 위험 요소가 될 수 있다.

• 새로운 기술을 사용해야 하는 경우
• 요구사항이 불명확한 경우
• 개발 기간이 부족한 경우
• 예산이 부족한 경우
• 보안 요구사항이 높은 경우

나선형 모델의 일반적인 흐름은 다음과 같다.

1. 계획 수립
2. 위험 분석
3. 개발 및 검증
4. 고객 평가
5. 다음 반복 진행

나선형 모델 장점

• 위험을 줄이면서 개발할 수 있다.
• 대규모 프로젝트에 적합하다.
• 반복적으로 개선할 수 있다.

나선형 모델 단점

• 관리가 복잡하다.
• 비용이 많이 들 수 있다.
• 위험 분석 능력이 부족하면 효과가 떨어진다.

---

3-6. 애자일 모델

애자일 모델은 짧은 주기로 개발하고 빠르게 피드백을 반영하는 개발 방법론이다.

영어로는 Agile이라고 한다.

Agile은 민첩하다는 뜻이다.

애자일은 처음부터 모든 요구사항을 완벽하게 정하고 시작하지 않는다.

작은 기능을 빠르게 만들고, 사용자나 고객의 피드백을 반영하면서 개선한다.

애자일은 요구사항 변경이 많은 프로젝트에 적합하다.

애자일의 핵심은 다음과 같다.

• 짧은 개발 주기
• 빠른 피드백
• 변화 수용
• 고객과의 협력
• 동작하는 소프트웨어 중심

애자일 모델 장점

• 요구사항 변경에 빠르게 대응할 수 있다.
• 사용자 피드백을 자주 받을 수 있다.
• 작은 기능 단위로 빠르게 결과물을 만들 수 있다.

애자일 모델 단점

• 문서화가 부족해질 수 있다.
• 팀원 간 소통이 부족하면 혼란이 생길 수 있다.
• 전체 일정과 범위 관리가 어려울 수 있다.

---

3-7. 스크럼

스크럼은 애자일 개발 방법론 중 하나다.

작은 팀이 짧은 주기로 기능을 개발하고 점검하는 방식이다.

스크럼에서는 일정 기간을 정해서 개발을 진행한다.

이 기간을 스프린트라고 한다.

스프린트는 보통 1주에서 4주 정도의 짧은 개발 주기다.

스크럼의 주요 구성 요소는 다음과 같다.

• 제품 책임자 = 제품의 방향과 우선순위를 정하는 사람
• 스크럼 마스터 = 팀이 스크럼을 잘 수행하도록 돕는 사람
• 개발팀 = 실제 기능을 개발하는 팀
• 제품 백로그 = 개발해야 할 기능 목록
• 스프린트 백로그 = 이번 스프린트에서 개발할 작업 목록
• 일일 스크럼 = 매일 짧게 진행 상황을 공유하는 회의
• 스프린트 리뷰 = 스프린트 결과물을 확인하는 회의
• 스프린트 회고 = 다음 작업을 더 잘하기 위해 개선점을 찾는 회의

스크럼은 실무에서 많이 사용되는 애자일 방식이다.

---

3-8. XP

XP는 eXtreme Programming의 약자다.

XP는 애자일 개발 방법론 중 하나다.

고객 요구 변화에 빠르게 대응하기 위해 좋은 개발 실천 방법을 강조한다.

XP의 핵심 실천 방법은 다음과 같다.

• 짝 프로그래밍 = 두 명이 함께 하나의 코드를 작성하는 방식
• 테스트 주도 개발 = 테스트 코드를 먼저 작성하고 기능 코드를 작성하는 방식
• 리팩토링 = 기능은 유지하면서 코드 구조를 개선하는 작업
• 지속적 통합 = 코드를 자주 통합하고 오류를 빠르게 찾는 방식
• 고객 상주 = 고객이 개발 과정에 가까이 참여하는 방식
• 작은 릴리즈 = 작은 기능 단위로 자주 배포하는 방식

XP는 코드 품질과 빠른 피드백을 중요하게 본다.

---

4. 주변 기초 개념

4-1. 방법론

방법론은 어떤 일을 체계적으로 수행하기 위한 절차와 방법이다.

개발 방법론은 소프트웨어를 어떤 순서와 방식으로 만들지 정한 틀이다.

4-2. 모델

모델은 복잡한 대상을 이해하기 쉽게 단순화한 구조다.

폭포수 모델, 프로토타입 모델, 나선형 모델은 개발 과정을 설명하기 위한 모델이다.

4-3. 요구사항

요구사항은 사용자가 시스템에 원하는 기능이나 조건이다.

요구사항은 개발 방향을 결정하는 기준이다.

4-4. 산출물

산출물은 개발 과정에서 만들어지는 문서나 결과물이다.

예를 들면 요구사항 명세서, 설계서, 테스트 케이스, 사용자 매뉴얼이 있다.

4-5. 반복 개발

반복 개발은 한 번에 완성하지 않고 여러 번 반복하면서 기능을 개선하는 방식이다.

애자일, 나선형 모델에서 중요하게 사용된다.

4-6. 점진적 개발

점진적 개발은 기능을 조금씩 추가하면서 완성도를 높이는 방식이다.

처음에는 핵심 기능만 만들고, 이후 부가 기능을 추가한다.

4-7. 위험 분석

위험 분석은 프로젝트 실패 가능성이 있는 요소를 미리 찾고 대응하는 작업이다.

나선형 모델에서 특히 중요하다.

4-8. 피드백

피드백은 결과물에 대한 의견이다.

애자일에서는 사용자나 고객의 피드백을 빠르게 반영한다.

4-9. 릴리즈

릴리즈는 소프트웨어의 특정 버전을 사용자에게 제공하는 것이다.

작은 릴리즈는 작은 기능 단위로 자주 배포하는 방식이다.

4-10. 유지보수

유지보수는 배포 후 소프트웨어를 계속 수정하고 개선하는 작업이다.

오류 수정, 기능 추가, 성능 개선, 보안 패치가 포함된다.

4-11. 프론트엔드

프론트엔드는 사용자가 직접 보는 화면 영역이다.

웹사이트의 버튼, 입력창, 메뉴, 화면 배치가 프론트엔드에 해당한다.

4-12. 백엔드

백엔드는 서버에서 동작하는 기능 영역이다.

로그인 처리, 데이터 저장, 권한 확인, API 응답 같은 작업을 담당한다.

4-13. 데이터베이스

데이터베이스는 데이터를 체계적으로 저장하는 공간이다.

회원 정보, 게시글, 댓글, 주문 내역 같은 데이터를 저장한다.

4-14. API

API는 프로그램끼리 데이터를 주고받기 위한 약속이다.

예를 들어 게시글 목록을 가져오는 API는 서버에 게시글 데이터를 요청하는 통로다.

---

5. 실제 흐름

5-1. SDLC 전체 흐름

1. 개발 목표와 범위를 정한다.
2. 사용자의 요구사항을 분석한다.
3. 화면, 데이터베이스, 프로그램 구조를 설계한다.
4. 설계 내용을 바탕으로 코드를 작성한다.
5. 기능이 제대로 동작하는지 테스트한다.
6. 사용자가 접근할 수 있는 환경에 배포한다.
7. 배포 후 오류 수정과 기능 개선을 진행한다.

5-2. 폭포수 모델 흐름

1. 요구사항을 모두 정리한다.
2. 요구사항을 바탕으로 설계한다.
3. 설계한 내용을 코드로 구현한다.
4. 구현된 기능을 테스트한다.
5. 완성된 소프트웨어를 배포한다.
6. 배포 후 유지보수한다.

폭포수 모델은 순서가 명확하다.

하지만 중간에 요구사항이 바뀌면 앞 단계로 돌아가야 해서 비용이 커질 수 있다.

5-3. 프로토타입 모델 흐름

1. 사용자의 기본 요구사항을 듣는다.
2. 간단한 시제품을 만든다.
3. 사용자에게 보여준다.
4. 사용자 피드백을 받는다.
5. 요구사항을 수정한다.
6. 본격적으로 개발한다.

프로토타입 모델은 요구사항이 불명확할 때 유용하다.

5-4. 나선형 모델 흐름

1. 계획을 세운다.
2. 위험 요소를 분석한다.
3. 개발하고 검증한다.
4. 고객 평가를 받는다.
5. 다음 반복을 진행한다.

나선형 모델은 반복하면서 위험을 줄인다.

5-5. 애자일 흐름

1. 개발할 기능 목록을 만든다.
2. 우선순위가 높은 기능을 선택한다.
3. 짧은 기간 동안 개발한다.
4. 작동하는 결과물을 확인한다.
5. 피드백을 받는다.
6. 다음 기능을 개발한다.

애자일은 변화에 빠르게 대응하는 방식이다.

5-6. 스크럼 흐름

1. 제품 백로그에 개발할 기능을 정리한다.
2. 스프린트 계획 회의에서 이번에 할 일을 고른다.
3. 스프린트 동안 기능을 개발한다.
4. 매일 일일 스크럼으로 진행 상황을 공유한다.
5. 스프린트 리뷰에서 결과물을 확인한다.
6. 스프린트 회고에서 개선점을 찾는다.

5-7. XP 흐름

1. 사용자 이야기를 바탕으로 기능을 정한다.
2. 테스트 코드를 먼저 작성한다.
3. 기능 코드를 작성한다.
4. 코드를 자주 통합한다.
5. 리팩토링으로 코드 구조를 개선한다.
6. 작은 단위로 자주 릴리즈한다.

---

6. 예시

6-1. 게시판 시스템을 폭포수 모델로 개발하는 예시

1. 요구사항 분석
- 회원은 글을 작성할 수 있다.
- 회원은 자신의 글을 수정할 수 있다.
- 관리자는 모든 글을 삭제할 수 있다.

2. 설계
- 글 목록 화면을 설계한다.
- 글 작성 화면을 설계한다.
- posts 테이블을 설계한다.

3. 구현
- 글 작성 화면을 만든다.
- 게시글 저장 기능을 만든다.
- 게시글 조회 기능을 만든다.

4. 테스트
- 회원이 글을 작성할 수 있는지 확인한다.
- 비회원이 글을 작성할 수 없는지 확인한다.

5. 배포
- 완성된 게시판을 운영 서버에 올린다.

6. 유지보수
- 오류를 수정한다.
- 검색 기능을 추가한다.

6-2. 게시글 저장 SQL 예시

아래 SQL은 게시글 데이터를 데이터베이스에 저장하는 예시다.

INSERT INTO posts (title, content, writer)
VALUES ('SDLC 정리', '소프트웨어 개발 생명주기 설명입니다.', 'user01');

6-3. 애자일 방식의 작업 목록 예시

제품 백로그
- 회원가입 기능
- 로그인 기능
- 게시글 작성 기능
- 게시글 수정 기능
- 댓글 기능
- 검색 기능

이번 스프린트 작업
- 로그인 기능
- 게시글 목록 조회 기능

---

7. 코드 또는 설정 설명

7-1. 절차 예시 설명

요구사항 분석은 무엇을 만들지 정하는 단계다.

설계는 어떻게 만들지 정하는 단계다.

구현은 설계한 내용을 실제 코드로 작성하는 단계다.

테스트는 만든 기능이 제대로 동작하는지 확인하는 단계다.

배포는 실제 사용자가 사용할 수 있는 환경에 올리는 단계다.

유지보수는 배포 후 오류를 수정하고 기능을 개선하는 단계다.

7-2. SQL 예시 설명

INSERT INTO posts (title, content, writer)

INSERT INTO는 데이터베이스 테이블에 새 데이터를 추가하는 SQL 명령어다.

posts는 게시글을 저장하는 테이블 이름이다.

title은 게시글 제목을 저장하는 컬럼이다.

content는 게시글 내용을 저장하는 컬럼이다.

writer는 작성자를 저장하는 컬럼이다.

VALUES ('SDLC 정리', '소프트웨어 개발 생명주기 설명입니다.', 'user01');

VALUES는 실제로 저장할 값을 지정하는 부분이다.

'SDLC 정리'는 title 컬럼에 저장된다.

'소프트웨어 개발 생명주기 설명입니다.'는 content 컬럼에 저장된다.

'user01'은 writer 컬럼에 저장된다.

7-3. 애자일 작업 목록 설명

제품 백로그는 앞으로 개발해야 할 전체 기능 목록이다.

이번 스프린트 작업은 이번 짧은 개발 기간 동안 처리할 작업 목록이다.

애자일에서는 전체 기능을 한 번에 만들지 않는다.

우선순위가 높은 기능부터 작은 단위로 개발한다.

---

8. 주의점

8-1. SDLC와 개발 방법론을 구분해야 한다

SDLC는 소프트웨어 개발 전체 흐름이다.

개발 방법론은 그 흐름을 어떤 방식으로 진행할지 정한 방법이다.

즉, SDLC는 큰 틀이고, 폭포수 모델이나 애자일은 그 틀을 수행하는 방식이다.

8-2. 요구사항 분석과 설계를 구분해야 한다

구분	의미	예시
요구사항 분석	무엇을 만들지 정함	회원은 글을 작성할 수 있어야 한다.
설계	어떻게 만들지 정함	posts 테이블에 title, content, writer 컬럼을 둔다.

8-3. 폭포수 모델과 애자일을 구분해야 한다

구분	폭포수 모델	애자일
진행 방식	단계별 순차 진행	짧은 주기 반복 진행
요구사항 변경	변경이 어려움	변경을 비교적 잘 반영함
중심	문서와 절차 중심	피드백과 개선 중심
적합한 경우	요구사항이 명확한 프로젝트	요구사항 변경이 많은 프로젝트

8-4. 프로토타입 모델과 나선형 모델을 구분해야 한다

프로토타입 모델은 사용자의 요구사항을 확인하기 위해 시제품을 만든다.

나선형 모델은 위험 분석을 반복하면서 개발한다.

프로토타입의 핵심은 시제품이다.

나선형 모델의 핵심은 위험 분석이다.

8-5. 스크럼과 XP를 구분해야 한다

스크럼은 팀 관리와 반복 개발 절차에 초점이 있다.

XP는 코드 품질과 개발 실천 방법에 초점이 있다.

스크럼의 핵심은 스프린트, 백로그, 일일 스크럼이다.

XP의 핵심은 짝 프로그래밍, 테스트 주도 개발, 리팩토링, 지속적 통합이다.

8-6. 예전 방식과 최신 방식을 구분해야 한다

예전 방식은 폭포수 모델처럼 단계별 순차 진행을 많이 사용했다.

요구사항을 처음에 많이 정리하고, 문서를 만든 뒤, 설계와 구현을 진행했다.

최신 방식은 애자일처럼 짧은 주기로 개발하고 피드백을 빠르게 반영하는 방식이 많이 사용된다.

하지만 폭포수 모델이 무조건 나쁜 방식은 아니다.

요구사항이 명확하고 변경이 적은 프로젝트에서는 폭포수 모델도 적합할 수 있다.

8-7. 실무에서는 하나의 방식만 쓰지 않을 수 있다

실무에서는 폭포수 모델과 애자일을 섞어서 쓰기도 한다.

큰 일정과 계약은 폭포수처럼 관리하고, 실제 개발은 애자일처럼 짧게 반복할 수 있다.

시험에서는 각 모델의 특징과 차이를 구분하는 것이 중요하다.

---

9. 요약

소프트웨어 개발 생명주기는 소프트웨어를 계획부터 유지보수까지 체계적으로 개발하는 전체 흐름이다.

SDLC의 기본 단계는 계획, 요구사항 분석, 설계, 구현, 테스트, 배포, 유지보수다.

폭포수 모델은 순차적으로 개발하는 방식이다.

프로토타입 모델은 시제품을 먼저 만들어 요구사항을 확인하는 방식이다.

나선형 모델은 위험 분석을 반복하면서 개발하는 방식이다.

애자일은 짧은 주기로 개발하고 피드백을 빠르게 반영하는 방식이다.

스크럼은 애자일 방법론 중 하나로 스프린트와 백로그를 중심으로 진행된다.

XP는 애자일 방법론 중 하나로 짝 프로그래밍, 테스트 주도 개발, 리팩토링 같은 개발 실천 방법을 강조한다.

정보처리기사 실기에서는 각 개발 방법론의 특징, 장점, 단점, 적합한 상황, 차이점을 구분해야 한다.

---

10. 핵심 용어 정리

SDLC = 소프트웨어를 계획부터 유지보수까지 체계적으로 개발하는 전체 흐름

소프트웨어 = 컴퓨터나 스마트폰에서 실행되는 프로그램

생명주기 = 시작부터 종료까지 이어지는 전체 과정

계획 = 개발 목표, 범위, 일정, 인력, 비용을 정하는 단계

요구사항 = 사용자가 시스템에 원하는 기능이나 조건

요구사항 분석 = 사용자가 원하는 기능과 조건을 정리하는 단계

기능 요구사항 = 시스템이 반드시 제공해야 하는 기능

비기능 요구사항 = 성능, 보안, 안정성처럼 기능 외에 만족해야 하는 조건

설계 = 개발 전에 시스템 구조와 동작 방식을 정하는 단계

구현 = 설계한 내용을 실제 코드로 작성하는 단계

테스트 = 소프트웨어가 요구사항대로 동작하는지 확인하는 단계

배포 = 완성된 소프트웨어를 실제 사용 환경에 올리는 단계

유지보수 = 배포 후 오류 수정, 기능 개선, 성능 개선을 수행하는 단계

산출물 = 개발 과정에서 만들어지는 문서나 결과물

개발 방법론 = 소프트웨어를 어떤 방식으로 개발할지 정한 절차

폭포수 모델 = 개발 단계를 순서대로 진행하는 전통적인 개발 방식

프로토타입 모델 = 본격 개발 전에 시제품을 만들어 요구사항을 확인하는 방식

프로토타입 = 본격 개발 전에 만드는 임시 버전 또는 시제품

나선형 모델 = 위험 분석을 반복하면서 점진적으로 개발하는 방식

위험 분석 = 프로젝트 실패 가능성이 있는 요소를 미리 찾고 대응하는 작업

애자일 = 짧은 주기로 개발하고 피드백을 빠르게 반영하는 개발 방식

스크럼 = 스프린트와 백로그를 중심으로 진행하는 애자일 방법론

스프린트 = 짧은 기간 동안 정해진 기능을 개발하는 반복 주기

제품 백로그 = 개발해야 할 기능 목록

스프린트 백로그 = 이번 스프린트에서 개발할 작업 목록

일일 스크럼 = 매일 짧게 진행 상황과 문제를 공유하는 회의

스프린트 리뷰 = 스프린트 결과물을 확인하는 회의

스프린트 회고 = 다음 스프린트를 개선하기 위해 문제점과 개선점을 찾는 회의

XP = 코드 품질과 빠른 피드백을 강조하는 애자일 개발 방법론

짝 프로그래밍 = 두 명의 개발자가 함께 하나의 코드를 작성하는 방식

테스트 주도 개발 = 테스트 코드를 먼저 작성한 뒤 기능 코드를 작성하는 방식

리팩토링 = 기능은 유지하면서 코드 구조를 개선하는 작업

지속적 통합 = 코드를 자주 통합해 오류를 빠르게 찾는 방식

릴리즈 = 소프트웨어의 특정 버전을 사용자에게 제공하는 것

프론트엔드 = 사용자가 보는 화면 영역

백엔드 = 서버에서 데이터 처리와 핵심 기능을 담당하는 영역

데이터베이스 = 데이터를 체계적으로 저장하는 공간

API = 프로그램끼리 데이터를 주고받기 위한 약속