소프트웨어 공학 — 1강: 소프트웨어 개발 프로세스와 SDLC

소프트웨어 공학(Software Engineering)이란?

소프트웨어 공학의 정의 (IEEE):
→ 소프트웨어의 개발, 운용, 유지보수에
  체계적이고 훈련된 공학적 접근 방법 적용

소프트웨어 위기 (Software Crisis, 1968):
→ 소프트웨어 개발의 복잡성 증가로
  비용 초과, 일정 지연, 품질 저하 문제 발생
→ 이 문제를 해결하기 위해 소프트웨어 공학 탄생

소프트웨어의 특성:
→ 비가시성: 눈에 보이지 않음
→ 유연성: 물리적 제약 없이 수정 가능
→ 복잡성: 매우 복잡한 구조
→ 변화 종속성: 환경 변화에 따라 지속 변화

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

SDLC (Software Development Life Cycle):
→ 소프트웨어의 탄생부터 소멸까지의 전체 과정

주요 단계:

1. 요구사항 분석 (Requirements Analysis):
→ 고객이 원하는 것 파악
→ 기능적 요구사항 + 비기능적 요구사항
→ 산출물: 소프트웨어 요구사항 명세서 (SRS)

2. 설계 (Design):
→ 시스템 아키텍처, 데이터베이스, 인터페이스 설계
→ 상위 설계 (아키텍처) → 하위 설계 (모듈)

3. 구현 (Implementation/Coding):
→ 실제 코드 작성
→ 코딩 표준, 코드 리뷰

4. 테스트 (Testing):
→ 단위 테스트 → 통합 테스트 → 시스템 테스트
→ 결함 발견 및 수정

5. 배포 (Deployment):
→ 운영 환경 릴리스

6. 유지보수 (Maintenance):
→ 버그 수정, 기능 개선, 환경 변화 대응
→ 전체 비용의 60~80% 차지

폭포수 모델 (Waterfall Model)

특징:
→ 각 단계가 순차적으로 진행
→ 이전 단계 완료 후 다음 단계 시작
→ 각 단계의 결과물이 다음 단계 입력

장점:
→ 단계별 명확한 산출물
→ 대규모 프로젝트 관리 용이
→ 문서화 체계적

단점:
→ 요구사항 변경 어려움
→ 초기 단계 오류 발견이 늦으면 비용 증가
→ 고객이 최종 단계에서야 결과 확인

적합한 경우:
→ 요구사항이 명확하고 변화 적은 프로젝트
→ 우주항공, 국방, 대형 인프라 시스템

반복·점진적 모델

프로토타이핑 (Prototyping):
→ 초기에 프로토타입(시제품) 개발
→ 고객 피드백 후 개선 반복
→ 요구사항 불명확한 경우 적합

나선형 모델 (Spiral Model, Boehm):
→ 계획 → 위험 분석 → 개발 → 평가를 반복
→ 위험 관리 강조
→ 대규모·고위험 프로젝트 적합

점진적 개발 (Incremental):
→ 전체 기능을 작은 증분(Increment)으로 나눠 개발
→ 각 증분마다 작동하는 소프트웨어 제공
→ 우선순위 기능을 먼저 개발

애자일 방법론 (Agile)

애자일 선언 (2001년):
→ 개인·상호작용 > 프로세스·도구
→ 작동하는 소프트웨어 > 포괄적 문서
→ 고객 협력 > 계약 협상
→ 변화 대응 > 계획 따르기

핵심 원칙:
1. 짧은 반복 주기 (Sprint/Iteration): 2~4주
2. 지속적 고객 참여
3. 팀 자율성
4. 변화 수용
5. 작동하는 소프트웨어 우선

전통적 vs 애자일 비교:
항목     | 전통적(폭포수) | 애자일
--------|--------------|--------
문서     | 상세 문서 중심  | 작동 코드 중심
변경     | 변경 어려움     | 변경 환영
고객 참여| 초기·최종      | 지속적 참여
팀 규모  | 대규모 가능     | 소규모 (5~9명)

스크럼 (Scrum)

스크럼 역할:

1. 제품 책임자 (Product Owner):
→ 백로그 관리, 우선순위 결정
→ 비즈니스 가치 극대화

2. 스크럼 마스터 (Scrum Master):
→ 스크럼 방법론 코치·촉진자
→ 장애물 제거

3. 개발팀 (Development Team):
→ 실제 소프트웨어 개발
→ 자기 조직화, 5~9명 권장

스크럼 프로세스:

제품 백로그 (Product Backlog):
→ 개발해야 할 기능 목록 (우선순위 정렬)

스프린트 계획 (Sprint Planning):
→ 스프린트 백로그 선택 및 계획

스프린트 (Sprint): 1~4주 개발 주기
→ 매일 스탠드업 미팅 (15분): 어제·오늘·장애물

스프린트 리뷰: 완성된 기능 시연
스프린트 회고: 프로세스 개선 논의

요구사항 공학 (Requirements Engineering)

요구사항 유형:

1. 기능적 요구사항 (Functional Requirements):
→ 시스템이 해야 할 기능
→ "사용자는 로그인할 수 있어야 한다"
→ "시스템은 PDF 파일을 생성해야 한다"

2. 비기능적 요구사항 (Non-functional Requirements):
→ 품질 특성 (성능, 보안, 신뢰성)
→ "응답 시간은 3초 이내여야 한다"
→ "시스템 가용성 99.9% 이상"

요구사항 명세 기법:
→ 유스케이스 (Use Case): 사용자-시스템 상호작용
→ 사용자 스토리 (User Story): "사용자로서 ~을 하고 싶다"
→ SRS (Software Requirements Specification)

요구사항 검증:
→ 완전성: 모든 요구사항이 명시되었는가?
→ 일관성: 상호 모순이 없는가?
→ 검증 가능성: 테스트 가능한가?
→ 추적 가능성: 출처와 구현을 추적할 수 있는가?

소프트웨어 품질

소프트웨어 품질 특성 (ISO 25010):

1. 기능 적합성: 요구 기능을 올바르게 수행
2. 성능 효율성: 자원 사용 최소화
3. 호환성: 다른 시스템과 상호 운용
4. 사용성: 배우기 쉽고 효율적 사용
5. 신뢰성: 오류 없이 안정적 동작
6. 보안성: 무단 접근으로부터 보호
7. 유지보수성: 수정·개선 용이
8. 이식성: 다른 환경으로 이동 용이

테스트 유형:
→ 단위 테스트: 개별 함수/모듈
→ 통합 테스트: 모듈 간 인터페이스
→ 시스템 테스트: 전체 시스템
→ 인수 테스트: 고객이 요구사항 충족 확인

자주 묻는 질문

Q. 애자일과 스크럼은 같은 것인가요? A. 다릅니다. 애자일은 소프트웨어 개발에 대한 철학과 가치관(방법론 집합)이고, 스크럼은 애자일 원칙을 구현하는 구체적인 프레임워크입니다. 스크럼 외에도 칸반(Kanban), XP(Extreme Programming) 등 다양한 애자일 방법론이 있습니다.

Q. 소프트웨어 유지보수 비용이 왜 그렇게 높나요? A. 소프트웨어는 처음 개발 후 환경(OS, 하드웨어, 규정) 변화에 따른 수정, 사용자 피드백 기반 기능 추가, 버그 수정이 지속적으로 필요합니다. 또한 코드 복잡도가 높아질수록 이해와 수정에 드는 비용이 기하급수적으로 증가하는 경향이 있습니다.

OIYO 편집부