[소프트웨어공학] - 프로세스와 방법론

1. 프로세스가 없다면

소프트웨어 개발을 진행할 때, 프로세스 없이 시작한다고 가정해보자. 이러한 상황에서는 초기 개발 속도가 매우 빠르게 느껴질 수 있다. 마치 나무를 심고 싹이 트는 단계까지만 보면 금방 자라는 것처럼 보이는 것과 같다.

 

하지만 소프트웨어 개발은 단순히 나무 하나를 키우는 것이 아니라 전체 숲을 설계하는 과정이다. 나무의 성장 크기나 간격을 고려하지 않고 무작정 촘촘하게 심는다면, 결국 건강한 숲을 만들지 못하게 된다.

 

소프트웨어 개발도 마찬가지로, 프로세스가 없다면, Code and Fix(단순 코드 개발과 수정의 반복)만 이루어지며, 다음과 같은 문제점들이 발생하게 된다.

• 작업 설계의 중요성을 인식하지 못한다.
• 계획이 구체화되지 않아 작업 목표가 불명확하다.
• 체계적인 테스트/품질 보증 활동이 없다.
• 유지보수 시 구조가 없어 점점 코드가 망가진다.

즉, 처음에는 빠른 것 같지만, 결국 가장 비효율적인 방식이다.

---

2. 프로세스와 방법론

그렇기에 필요한 것이 프로세스이며, 이번 글에서는 프로세스와 그 프로세스를 실행하는 여러가지 방법들에 대해서 정리해 볼 예정이다.

 

먼저, 프로세스와 방법론은 서로 대체하는 관계가 아니다. 즉, 둘 중 하나만 선택해서 소프트웨어 개발을 진행하는 것이 아니라 프로세스 + 방법론을 함께 적용해서 진행해야 한다.

프로세스	방법론
- 단계적인 작업의 틀을 정의한 것 - 무엇을 할 것인가 (What to do) - 결과물 표현 방식은 정의하지 않음 - 패러다임에 독립적 - 전체 흐름 중심	- 프로세스 각 단계의 구체적인 수행 방법 - 어떻게 할 것인가 (How to do) - 결과물 표현 방식까지 정의 - 패러다임에 종속적 - 실제 구현 중심
예시 - 폭포수 프로세스 - 나선형 프로세스 - 프로토타이핑 프로세스 - Unified 프로세스 - 애자일 프로세스	예시 - 구조적 분석 - 설계 방법론 - 객체지향 방법론 - 컴포넌트 - 애자일 방법론

+) 결과물 표현 방식을 정의하지 않는다는 것은 무엇을 할지만 정의하고, 결과물을 어떤 형태로 만들지는 신경 쓰지 않는다는 것을 의미한다.

++) 패러다임에 독립적이라는 것은 개발 방식에 독립적이라는 것이고, 프로세스는 어떤 언어로 개발하든 각 단계에서 서로 다른 방법으로 접근 가능하다는 것을 의미한다.

---

3. 소프트웨어 생명주기

소프트웨어 개발은 하나의 프로세스가 아나리ㅏ 여러 서브 프로세스들의 집합이다.

 

개발 모델별로 컴포넌트 프로세스, 부프로세스가 존재한다. 각 프로세스의 의미는 다음과 같다.

• 컴포넌트 프로세스(Component Process): 하나의 개발 모델 안에서 핵심 흐름을 구성하는 메인 프로세스
  • ex) 폭포수 모델 기준: 요구사항 분석 > 설계 > 구현 > 테스트 > 유지보수
• 부프로세스(Subprocess): 컴포넌트 프로세스를 수행하기 위해 필요한 세부 활동
  • ex) 요구사항 분석 안에서의 사용자 인터뷰, 요구사항 문서 작성, 요구사항 검증 등

---

4. 프로세스

4.1. 프로세스 정의

앞서 간단히 정리했던 프로세스에 대해서 조금 더 자세히 정리해보려고 한다.

 

프로세스는

• 소프트웨어 시스템을 구축하기 위해 수행되는 작업의 단계이며,
• 소프트웨어 개발에 대한 기술적, 관리적 이슈를 다루는 작업의 흐름이다.

프로젝트 명세를 다음 그림을 통해 한 번 확인해보자.

프로세스의 일반적인 흐름은 다음과 같다.

• 요구사항 분석
• 설계
• 구현
• 테스트
• 설치 및 운영

즉, 하나의 프로젝트는 위와 같은 단계들을 순차적으로 거치면서 완성된다.

 

프로세스 모델 예시를 다음 그림을 통해 한 번 살펴보자.

위 사진은 여러 프로세스 모델 중 하나를 나타낸 것으로, 위 프로세스 모델은 다음과 같은 특징을 가진다.

• 계획 > 요구 분석 > 설계 > 구현 > 테스트 > 인수/설치 단계로 진행된다.
• 각 단계는 이전 단계의 결과물을 기반으로 수행된다.
• 문제가 발생하면 이전 단계로 돌아가 수정 후 다시 진행 가능하다.

위 프로세스 모델은 단순한 일방향 흐름이 아니라 피드백을 통해 반복적으로 개선되는 구조라고 이해하면 된다.

 

프로세스는 또한 다음 요소들이 명확하게 정의되어야 한다.

• 작업 내용 (What)
• 수행 방법 (How)
• 진입 조건 (Entry condition)
• 종료 조건 (Exit condition)
• 결과물 (Artifact)
• 검증 기준 (Validation)

이러한 요소들이 명확하지 않으면 다음과 같은 문제가 발생한다.

• 작업 시작 기준이 불명확 > 언제 시작해야 하는지 모름
• 작업 종료 기준이 없음 > 끝났는지 판단 불가
• 결과물이 불명확 > 다음 단계 진행 불가
• 책임 소재 불명확 > 프로젝트 전체 혼란

즉, 프로세스 정의가 명확하지 않으면 프로젝트가 꼬이는 상황에 노출되기 쉽다. 다음 그림을 통해 개발 프로세스 정의를 더 쉽게 이해할 수 있다.

4.2. 프로세스의 종류

소프트웨어 프로세스는 역할에 따라 크게 프로젝트 중심 프로세스와 지원 프로세스로 나눌 수 있다.

4.2.1. 프로젝트 중심 프로세스(직접 개발을 수행하는 핵심 작업)

프로젝트 중심 프로세스는 실제로 소프트웨어를 만들고, 프로젝트를 운영하는 핵심 과정이다.

• 개발 프로세스: 실제로 프로그램을 만드는 과정
  • ex) 요구사항 분석, 설계, 구현(코딩), 테스트
• 관리 프로세스: 프로젝트가 제대로 돌아가게 관리
  • ex) 일정 관리, 인력 관리, 비용 관리, 리스크 관리

4.2.2. 기타 프로세스(지원 역할)

지원 프로세스는 개발이 원활하게 이루어지도록 보조하는 역할을 수행한다

• 형상 관리 프로세스: 코드/문서 변경을 체계적으로 관리
  • ex) Git 버전 관리, 변경 이력 관리, 릴리즈 관리
• 프로세스 관리 프로세스: 개발 방법 자체 관리하고 개선하는 과정
  • ex) 개발 방법 개선, 프로세스 정의, 품질 관리 기준 수립

위에서 정리한 분류는 다음 그림과 같이 더 구조적으로 정리할 수 있다.

그림에 대해서 설명하면 다음과 같다.

• 소프트웨어 프로세스는 다음 2가지 프로세스로 분류된다.
  • 프로덕트 엔지니어링 프로세스: 실제 소프트웨어 제품을 만들기 위한 프로세스
    • 개발 프로세스
    • 프로젝트 관리 프로세스
    • 소프트웨어 형상 관리 프로세스
  • 프로세스 관리 프로세스: 전체 개발 프로세스를 관리하고 개선하는 프로세스
    • ex) 프로세스 정의, 프로세스 개선, 품질 기준 관리

4.3. 좋은 프로세스의 특성

좋은 소프트웨어 프로세스는 단순히 단계가 있는 것이 아니라, 프로젝트를 안정적으로 성공시키기 위한 몇 가지 중요한 특성을 만족해야 한다. 대표적인 특성은 다음과 같다.

1. 예측 가능성
   • 결과(일정, 비용, 품질)를 미리 예측할 수 있는 정도
     • 프로젝트를 진행하기 전에 언제 끝날지, 비용이 얼마나 들지, 품질이 어느 수준일지 예측 가능해야 한다.
2. 테스팅과 유지보수 용이성
   • 테스트하기 쉽고, 나중에 수정하기 쉬운 구조
     • 이를 위해서는 코드 모듈화, 테스트 케이스 작성 용이, 기능 수정 시 영향 범위가 작아야 한다.
3. 변경 지원
   • 요구사항 변경에 유연하게 대응할 수 있는 구조
     • S/W 변경사항이 많기 때문에(고객 요구 변경, 기능 추가, 정책 변경 등) 쉽게 대응이 가능해야 한다.
4. 결함 제거(아래 그래프 참고)

위 그래프에 대해서 정리하면 다음과 같다.

• Y축: 결함 수정 비용
• X축: 개발 단계(요구사항 > 설계 > 코드(구현) > 개발 테스트 > 운영)
• 그래프 해석
  • 결함이 늦게 발견될수록 수정 비용이 급격하게 증가한다.
  • 초기 단계(Requirements ~ Design)
    • 결함 수정 비용: 1 ~ 5정도
    • 이유: 문서만 수정하면 되기 때문
  • 중간 단계(Code ~ Development test)
    • 결함 수정 비용: 10 ~ 50정도
    • 이유: 설계 오류가 코드 구조 변경으로 이어짐
  • 후반 단계(Acceptance test ~ Operations test)
    • 결함 수정 비용: 100 ~ 1000까지 상승
    • 이유: 코드 수정, 재테스트, 재배포, 고객 대응, 신뢰도 하락 등등의 문제
  • 파란색 점선: 규모가 작은 프로젝트
  • 파란색 실선: 규모가 큰 프로젝트

따라서, 결함은 초기에 최대한 잡는 것이 중요하다.

 

+) Brooks 법칙

Brooks 법칙은 다음과 같다.

• 늦어진 프로젝트에 인력을 추가하면 오히려 더 늦어진다.

그 이유는사람이 늘어나면 소통해야 할 경우의 수가 급증하게 된다.

 

예를 들어 초기에 5명의 인원이 소프트웨어 프로젝트를 진행한다고 가정하면, 초기에는 10개의 관계만 발생하게 된다. 그 후, 프로젝트 후기에 인원이 2명이 투입된다면, 21개의 관계가 형성되며, 인원이 조금만 늘어나도 소통 비용이 폭발적으로 증가하게 된다.

 

추가로, 새로 들어온 사람은 바로 일에 투입되지 못하고 교육 및 인수인계 기간이 필요하기 때문에 소프트웨어 프로젝트에 늦게 인력을 추가해도 개발이 빨라지는 것이 아닌 오히려 더뎌질 수 있다는 것이 Brooks 법칙이다.

---

5. 프로세스 모델의 종류 - 소프트웨어 개발 중심

5.1. 폭포수(Waterfall) 모델

폭포수 모델은 가장 오래되고 전통적인 소프트웨어 개발 프로세스 모델이다. 각 단계가 위에서 아래로 흐르는 구조를 가지며, 물이 떨어지느 폭포와 같다고 해서 붙여진 이름이다.

위 그림과 같이 폭포수 모델을 정리하면 다음과 같다.

• 각 단계까 순차적으로 진행된다.
• 이전 단계까 완료되어야 다음 단계로 진행이 가능하다.
• 단계 간 중복이나 병행 작업이 거의 없다.
• 각 단계마다 명확한 산출물(결과물)이 존재한다.
  • ex) 계획서, 요구분석서, 설계서, 원시코드, 실행파일 테스트 보고서

이 폭포수 모델의 장단점은 다음과 같다.

• 장점
  • 구조가 단순하여 이해하고 적용하기 쉽다.
  • 단계별 산출물이 명확하여 관리가 용이하다.
  • 구현 전에 충분한 분석과 설계를 수행하기 때문에 초기 안정성이 확보가 가능하다.
• 단점
  • 불필요하게 많은 문서를 생성할 가능성이 존재한다.
  • 요구사항이 불명확한 경우 전체 프로젝트가 흔들릴 수도 있다.
  • 변경에 매우 취약하다. 즉, 요구사항 수정이 어렵다.
  • 테스트가 후반에 이루어져 결함 발견이 늦어지게 된다.

또한 폭포수 모델은 다음 단계로 진행되었을 때, 전 단계로 돌아가는 비용이 매우 큰 치명적인 단점이 존재한다. 즉, 요구 분석이 끝나 요구 분석서를 만들어 설계 단계로 넘어가면 되돌아가는 비용이 매우 크다는 단점이 존재한다.

5.2.  V모델

폭포수 모델의 단점을 보완하기 위해 등장한 모델이 V 모델이다. V 모델은 각 개발 단계에 대응하는 테스트 단계를 연결하여, 검증(Verification)을 강화한 프로세스 모델이다.

 

V 모델은 개발 단계와 테스트 단계가 V자 형태로 대응된다.

• 개발 단계(왼쪽)
  • 요구사항 분석, 시스템 설계, 상세 설계, 구현(코딩)
• 개발 단계(오른쪽)
  • 단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트
• 단계별 대응 관계
  • 코드 ↔ 단위 테스트
    • 모듈(함수/클래스) 단위 검증
  • 상세 설계 ↔ 통합 테스트
    • 모듈 간 인터페이스 검증
  • 시스템 설계 ↔ 시스템 테스트
    • 전체 시스템 동작 검증
  • 요구사항 분석 ↔ 인수 테스트
    • 고객 요구사항 만족 여부 검증

V모델의 장단점은 다음과 같다.

• 장점
  • 각 단계별 테스트가 명확하여 결함을 조기에 발견 가능하다.
  • 테스트 계획을 초기에 수립 가능
  • 품질 관리가 체계적이다.
• 단점
  • 기본 구조가 폭포수 기반이므로 변경 대응이 어렵다.
  • 요구사항이 변경되면 전체 구조에 영향
  • 여전히 후반으로 갈수록 결함 수정 비용 증가

5.3. 프로토타이핑 모델

다음으로 알아볼 프로세스 모델은 프로토타이핑 모델이다. 모델에 대해서 정리하기 전에, 프로토타이핑이라는 개념을 한 번 정리하면, 다음과 같다.

• 프로토타이핑: 요구 사항에 대한 피드백을 받기 위해 시스템의 일부를 실험적으로 구현하여 사용자에게 보여주고 평가받는 방법

프로토타입은 시스템의 실제 동작을 단순화하여 시뮬레이션한 모델이다. 즉, 전체 시스템이 아닌 일부 기능을 구현하여 사용자에게 미리 보여주는 것을 의미한다.

이때 화면 생성기나 다양한 프로토타이핑 도구를 활용하면 비교적 빠르게 구현할 수 있다.

 

프로토타입의 목적은 다음과 같다.

• 요구사항 명확화
  • 사용자로부터 모호한 요구사항을 구체적으로 도출하기 위함이다.
  • ex) 구현된 프로토타입을 보고 사용자 마음에 들지 않는다면 해당 부분 코드를 폐기한다.
• 타당성 및 실현 가능성 검증
  • 개발 과정에서 시스템을 실제로 구현할 수 있는지 기술적, 구조적으로 판단할 수 있다.
  • 즉, 아이디어 수준이 아니라 실제 소프트웨어로 구현이 가능한지 확인하는 과정이다.

프토타이핑 모델은 다음 그림과 같다.

 

프로토타이핑 모델은 다음과 같은 반복 구조를 가진다.

• 요구사항을 분석한다.
• 요구사항을 기반으로 프로토타입을 개발한다.
• 사용자에게 프로토타입을 보여주고 평가 및 피드백을 받는다.
• 피드백을 반영하여 요구사항을 수정하고 프로토타입을 개선한다.

위 과정을 반복적으로 수행하면서 점점 요구사항을 명확히 해 나간다. 최종적으로는 프로토타입에 대한 사용자 반응이 충분히 만족스러운 수준에 도달하면, 이후 실제 구현 단계로 넘어가 전체 시스템을 개발 및 통합하게 된다.

 

프로토타이핑 모델의 장단점은 다음과 같다.

• 장점
  • 사용자 의견 반영이 용이하다.
    • 실제 동작하는 프로토타입을 기반으로 피드백을 받기 때문에 요구사항을 보다 명확하게 정의할 수 있다.
  • 사용자 참여도가 높아진다.
    • 사용자가 개발 과정에 직접 참여하게 되므로 시스템에 대한 이해도가 높아지고, 요구사항 도출의 정확성이 향상된다.
• 단점
  • 완성된 제품으로 오인할 가능성이 있다.
    • 사용자가 프로토타입을 실제 완성된 시스템으로 착각하여 과도한 기대를 가질 수 있다.
  • 추가 비용이 발생할 수 있다.
    • 프로토타입을 반복적으로 개발하고 수정하는 과정에서 시간과 비용이 증가할 수 있다.

따라서 프로토타이핑 모델은 다음과 같은 상황에서 적용할 수 있다.

• 개발 착수 시점에 요구가 불투명할 때
• 실험적으로 실현 가능성을 타진해 보고 싶을 때
• 혁신적인 기술을 사용해 보고 싶을 때

5.4. 나선형(Spiral) 모델

나선형 모델은 소프트웨어의 기능을 나누어 점증적으로 개발하면서 각 단계마다 위험 분석을 수행하는 프로세스 모델이다. 이 모델은 Barry Boehm이 제안하였다.

위 그림에서 확인할 수 있듯이 나선형 모델은 하나의 사이클(나선)을 반복하면서 시스템을 점점 확장해 나간다. 각 사이클은 다음 네 단계로 구성된다.

1. 목표, 방법, 제약 조건 결정 (Planning)
   • 해당 단계에서의 목표, 개발 방법, 제약 조건을 정의한다.
2. 위험 요소 분석 및 해결
   • 잠재적인 위험 요소를 식별하고, 이를 해결하기 위한 방안을 검토한다. 필요 시 프로토타입을 통해 위험을 검증한다.
3. 개발과 평가
   • 실제 기능을 구현하고 테스트를 수행한다.
4. 다음 단계 계획
   • 사용자 또는 이해관계자의 평가를 받고, 다음 단계 진행 여부 및 계획을 수립한다.

나선형 모델의 가장 큰 특징은 위험(Risk) 중심 개발이다. 다른 모델과 달리 개발 초기부터 반복적으로 위험을 분석하고 대응함으로써 실패 가능성을 줄인다.

 

이러한 나선형 모델의 장단점은 다음과 같다.

• 장점
  • 대규모 시스템 개발에 적합하다.
  • 위험 요소를 사전에 식별하고 대응할 수 있다.
  • 반복적인 개발과 검증을 통해 품질과 안정성이 향상된다.
  • 한 사이클에 추가하지 못한 기능은 다음 단계에 추가가 가능하다.
• 단점
  • 관리가 복잡하다.
    • 각 단계마다 위험 분석과 평가가 필요하기 때문에 관리 부담이 크다.
  • 위험 분석에 대한 의존도가 높다.
    • 위험을 잘못 판단하면 오히려 비용과 일정이 크게 증가할 수 있다.
  • 성공 사례가 많이 알려지지 않았다.

따라서 이러한 나선형 모델은 다음과 같은 상황에 적용할 수 있다.

• 재정적 또는 기술적으로 위험 부담이 큰 경우
• 새로운 기술을 도입하는 고위험 프로젝트

5.5. 진화적 모델

진화적 모델은 소프트웨어를 한 번에 완성하는 것이 아니라, 핵심 기능부터 점진적으로 개발하고 지속적으로 개선해 나가는 프로세스 모델이다.

 

앞서 살펴본 프로토타이핑 모델에서는 요구사항이 불명확한 부분을 중심으로 프로토타입을 만들어 검증하는 데 목적이 있다.

반면, 진화적 모델에서는 실제 사용 가능한 시스템의 일부 기능을 먼저 개발하고, 이를 점진적으로 확장하여 최종 시스템으로 발전시키는 것이 핵심이다.

이러한 진화적 모델은 위 그림에서도 알 수 있듯이, 짧은 개발 사이클을 반복하면서 소프트웨어를 점차 발전시킨다.

• 핵심 기능을 중심으로 초기 버전(MVP) 개발
• 실제 사용자에게 배포
• 사용자 피드백을 반영하여 기능 개선 및 확장
• 다음 버전을 다시 배포

위 과정을 반복하면서 시스템을 점진적으로 완성해 나간다. 즉, MVP 기반의 반복적 릴리스 방식이라고 볼 수 있다.

 

이런 릴리스 방법에는 두 가지 방식이 있는데, 다음과 같다.

1. 점증적 방법: 기능을 나누어 단계쩍으로 추가하는 방식이다.
   • ex) 로그인 → 게시판 → 결제 기능 순서로 확장
2. 반복적 방법: 동일한 기능을 반복적으로 개선하여 완성도를 높이는 방식이다.
   • ex) UI/성능/안정성 지속 개선

진화적 모델의 장단점은 다음과 같다.

• 장점
  • 몇 가지 기능이 부족하더라도 초기부터 동작하는 소프트웨어를 제공할 수 있다.
  • 사용자 요구사항을 빠르게 반영할 수 있다.
  • 시장에 빠르게 진입(Market Entry)할 수 있다.
  • 운영 중 발생하는 문제를 지속적으로 개선할 수 있다.
• 단점
  • 프로젝트 관리가 복잡해지기 때문에 큰 프로젝트에는 부적합하다.
  • 전체 구조 설계가 약해질 수 있다.
  • 개발 종료 시점이 불명확해질 수 있다.

5.6. Unified 프로세스

Unified 프로세스는 반복적이고 점진적인 개발을 특징으로 하는소프트웨어 개발 프로세스이다. 전체 시스템을 한 번에 개발하는 것이 아니라 여러 개의 사이클을 반복하며 점진적으로 완성해 나간다. Unified 프로세스는 다음 그림과 같이 알아보자.

Unified 프로세스는 위 그림처럼 여러 개의 사이클로 구성된다.

 

Unified 프로세스에서도 하나의 사이클에 다음 네 단계가 포함된다.

1. 도입(Inception)
   • 1, 2회 정도 반복으로 도입 단계가 진행된다.
   • 프로젝트의 목표와 범위를 정의한다.
   • 간단한 유스케이스 모델과 소프트웨어 구조, 프로젝트 계획을 작성한다.
2. 정교(Elaboration)
   • 여러 번의 반복 과정으로 이루어진다.
   • 대부분의 유스케이스를 구체화하며 시스템의 핵심 아키텍처를 확정한다.
   • UML 다이어그램을 통해 설계를 명확히 한다.
3. 구축(Construction)
   • 실제 기능 구현 단계이다.
   • 남아있는 유스케이스를 구현하고 시스템에 통합한다.
   • 반복적으로 기능을 추가하며 점진적으로 완성도를 높이는 단계이다.
4. 전환(Transition)
   • 시스템을 배치하는 작업을 한다.
   • 사용자를 교육하고 메뉴얼을 제공하며 베타 테스팅을 통해 결함을 수정하고 기능을 개선한다.

Unified 프로세스는 위 사이클을 반복하며 유스케이스를 식별하여 시스템을 개발 계획에 활용하는 데 초점을 둔다. 즉, Unified 프로세스는 유스케이스 중심의 프로세스라는 특징을 가진다.

 

Unified 프로세스는 다음과 같은 장단점을 가진다.

• 장점
  • 방법론과 프로세스에 대한 문서화가 잘 되어 있다.
    • 프로세스와 산출물이 체계적으로 정의되어 있어 학습과 적용이 용이하다.
  • 요구사항 변경에 강하다.
    • 반복 개발 구조이기 때문에 변경 사항을 다음 사이틀에 반영할 수 있다.
  • 통합을 위한 노력과 시간을 줄일 수 있다.
    • 초기에 아키텍처를 확정하고 반복적으로 통합하기 때문에 마지막에 한 번에 통합하는 문제를 피할 수 있다.
  • 쉽고 빠르게 코드를 재사용할 수 있다.
    • 컴포넌트 기반 개발을 지향하기 때문에 구조가 모듈화되고 재사용성이 높아진다.
• 단점
  • 프로세스가 너무 복잡하고 이해하기 어려울 뿐 아니라 정확히 적용하기 어렵다.
  • 소프트웨어 프로젝트 참여자들의 협동, 의사소통에대한 가이드가 없다.
  • 조직화되지 않은 개발로 완전히 알려지지 않은 형태의 소프트웨어 개발로 이어질 수 있다.

5.7. 애자일 프로세스

기존의 프로세스 모델들은 개발 도중 고객의 요구사항이 변경될 경우 이를 반영하고 통합하는 데 많은 비용과 시간이 소요되는 문제가 있었다.

 

애자일 프로세스 모델은 이러한 문제를 해결하기 위해 빠른 피드백과 반복적인 개발을 기반으로 하는 방식이다.

 

애자일 프로세스는 일반적으로 2~6주의 짧은 주기(Iteration 또는 Sprint)로 개발을 반복하며, 각 반복마다 실행 가능한 소프트웨어를 만들어 점진적으로 시스템을 완성해 나간다.

 

이러한 특징 때문에 애자일은 점진적이고 반복적인 개발 방식이라고 할 수 있다.

 

이러한 애자일 프로세스는 애자일 선언을 통해 정립되었으며, 다음과 같은 가치를 중심으로 한다.

1. 형식적인 문서보다는 개인 상호작용(커뮤니케이션)을 중시한다.
2. 문서보다 실행되는 소프트웨어를 통해 요구사항을 검증한다.
3. 계약보다 고객과의 협력을 중요하게 생각한다.
   • 즉, 사용자의 요구가 비즈니스 환경에 따라 프로젝트 중간에 바뀔 수 있음을 고려한다.
4. 계획을 따르기보다 변화에 유연하게 대응한다.
   • 즉, 짧은 주기 동안 요구정의에서 구현, 테스트까지 이루어지며 각 반복 주기의 반성 의견을 다음 계획에 포함한다.

5.7.1. 익스트림 프로그래밍(XP)

익스트림 프로그래밍은 대표적인 애자일 방법론 중 하나이다. XP는 요구사항 변경이 빈번하고 불확실성이 높은 프로젝트 환경에서 효과적으로 대응하기 위해 고안된 개발 방법이다.

 

XP는 짧은 개발 주기와 빠른 피드백, 그리고 높은 코드 품질 유지를 목표로 하며, 이를 위해 개발의 핵심 활동들을 극단적으로 적용하는 특징을 가진다.

 

XP는 다음과 같은 주요 특징을 가진다.

1. 사용자 스토리
   • 전통적인 요구사항 문서를 작성하는 것이 아닌 간단한 사용자 스토리를 작성한다.
   • 사용자 스토리는 기능의 비즈니스 가치와 우선순위를 정한 것으로, 짧고 이해하기 쉬운 문장으로 표현된다.
2. 매일 빌드와 통합
   • 실행되는 시스템을 항상 준비하기 위해 개발한 것을 매일 빌드하고 통합한다.
   • 매일 빌드 통합이 이루어져도 commit은 신중히 해야 한다.
3. 테스트 주도 개발(Test-Driven Development)
   • 실제 코들르 작성하기 전에 테스트 코드(테스트 시나리오)를 먼저 작성한다.
   • 테스트를 통과하기 위한 최소한의 코드를 구현한 후, 이후 리팩토링을 통해 코드 품질을 개선한다.
4. 페어 프로그래밍
   • 두 명의 개발자가 하나의 작업을 함께 수행한다.
   • 한 명은 코드를 작성하고, 다른 한 명은 이를 검토하여 즉각적인 피드백과 품질 향상을 유도한다.

다음 그림을 통해 XP의 개발 흐름을 살펴볼 수 있다.

그림에 대해서 정리하면 다음과 같다.

• 사용자 스토리를 기반으로 요구사항을 정의하고 릴리스 계획을 수립한다.
• 테스트 시나리오를 먼저 작성한 후 구현을 진행한다.
• 반복적인 개발 사이클을 통해 기능을 점진적으로 개선한다.
• 인수 테스트를 거쳐 고객의 승인을 받고 소규모 릴리스를 수행한다.

5.7.2. 스크럼

스크럼(Scrum)은 대표적인 애자일 방법론 중 하나로, 개발팀이 지속적으로 소통하고 협업하여 짧은 주기(스프린트)를 반복하여 소프트웨어를 개발하는 방식이다.

 

스크럼은 변화에 유연하게 대응하기 위해 반복적이고 점진적인 개발을 기반으로 하며, 각 주기마다 실행 가능한 소프트웨어를 만들어내는 것을 목표로 한다.

 

스크럼에서는 백로그를 기반으로 우선순위를 정하고, 짧은 개발 주기인 스프린트(Sprint)를 통해 개발을 진행한다.

 

또한 정해진 미팅을 통해 지속적으로 진행 상황을 점검하고 개선한다.

그림에 대해서 설명하면 다음과 같다.

• 프로덕트 백로그에서 우선순위를 정한다.
• 스프린트 계획을 통해 스프린트 백로그를 구성한다
• 스프린트(2~4주) 동안 개발을 수행한다
• 매일 데일리 스크럼을 통해 진행 상황을 점검한다.
• 스프린트 종료 후, 배포 가능한 소프트웨어(증분)가 생성된다.

---

6. 프로세스 종류 - 개발 지원 프로세스

이전까지 살펴본 프로세스들은 소프트웨어 개발을 직접 수행하는 핵심 프로세스였다. 이러한 개발이 원활하게 이루어지기 위해서는 이를 보조하고 지원하는 프로세스가 필요하며, 이를 개발 지원 프로세스라고 한다.

 

다음 그림을 한 번 살펴보자.

위 그림은 ISO/IEC 12207 기준 프로세스 모델을 그룹으로 나눈 것이다.

 

위 그림 기준에서 지원 시각(Support Process)으로 분류되는 프로세스는 다음과 같다.

1. 문서화 프로세스
   • 개발 과정에서 필요한 문서를 작성 및 관리하는 프로세스
   • ex) 요구사항 명세서, 설계서, 테스트 문서
2. 형상관리 프로세스
   • 소프트웨어의 변경 사항을 관리하는 프로세스(버전 관리, 변경 이력 관리 등)
   • ex) Git
3. 품질 보증 프로세스(QA)
   • 프로세스와 프로덕트에 대한 품질을 관리하고 향상시키는 프로세스
   • 인스펙션 같은 활동을 통해 개발 경과에서 결함을 발견하고 예방한다.
     • 인스펙션 프로세스는 정의된 프로세스에 따라 동료 그룹이 작업 결과를 검사하는 것을 의미한다.
   • 프로세스 관리 프로세스
     • 소프트웨어 프로세스는 정적인 요소가 아니기 때문에 프로세스도 지속적으로 변한다.
     • 변화하는 프로세스를 관리하기 위한 프로세스가 바로 프로세스 관리 프로세스이다.
4. 문제 해결 프로세스
   • 개발 및 운영 중 발생하는 문제를 처리하는 프로세스(원인 분석 및 해결)

---

7. 방법론

이제 프로세스의 각 작업을 어떻게 수행할 것인지에 대한 구체적인 방법론(Methodology)에 대해 정리해 보자. 대표적인 방법론으로는 다음 세 가지가 있다.

• 구조적 방법론
• 정보공학 방법론
• 객체지향 방법론

7.1. 구조적 방법론

구조적 방법론은 분리와 정복(divide and conquer)원리를 적용하여 시스템을 계층적으로 분해하고 설계하는 방법이다.

 

이 방법론에서는 시스템을 작은 단위의 기능(=모듈)으로 나누고, 각 기능 간의 관계를 구조적으로 표현하여 전체 시스템을 이해하고 개발한다.

또한 위 그림과 같이 자료 흐름도를 이용하여 데이터의 흐름을 표현하고 이를 기반으로 구조도를 설계하여 모듈 간의 호출 관계를 정의한다.

7.2. 정보공학 방법론

정보공학 방법론은 기업의 정보 시스템을 체계적으로 개발하기 위해 사용되는 방법론으로, 비즈니스와 소프트웨어를 통합적으로 고려하는 특징을 가진다..

 

정보 공학 방법론의 특징은 다음과 같다.

1. 기업 중심
   • 적용 대상이 기업의 비즈니스 중심이다.
2. 전략적 시스템 계획 중심
   • 경영층의 요구를 반영하기 위해 장기적인 계획이 필요하다.
3. 데이터 중심
   • 비즈니스 프로세스는 변하지만 데이터는 상대적으로 안정적이므로, 데이터 중심으로 설계한다.
4. 분할과 정복
   • 비즈니스 문제 영역을 세분화하여 분석한다.
5. 공학적 접근
   • 분석, 설계를 철저히 수행한 후 CASE 도구를 활용하여 자동화한다.
6. 사용자의 적극적 참여
   • 개발 과정에서 사용자의 의견을 지속적으로 반영한다.

 

정보공학 방법론은 다음과 같은 단계로 진행된다.

그림에 대해 정리하면 다음과 같다.

1. 정보전략 계획(ISP)
   • 조직 전체의 정보 시스템 방향을 수립
2. BAA(비즈니스 영역 분석)
   • 요구사항 명세서가 만들어진다.
3. BSD(비즈니스 시스템 설계)
   • 논리 ERD와 프로세스 구조도, 흐름도를 생성한다.
4. SC(시스템 구축)
   • 물리 ERD, UI, 프로그램 코드가 산출된다.

7.3. 객체지향 방법론

다음으로 살펴볼 방식은 객체지향 방법론이다.

 

객체지향 방법론은 현실 세계의 객체를 모델링하여 소프트웨어를 설계하고 개발하는 방법으로, 데이터와 기능을 하나의 단위인 객체로 묶어 시스템을 구성한다.

 

객체지향 방법론은 객체지향 언어의 특성을 기반으로 하며, 대표적인 특징은 다음과 같다.

1. 캡슐화
   • 데이터와 메서드를 하나의 객체로 묶고 외부 접근을 제한
2. 추상화
   • 핵심적인 요소만 표현하여 단순화
3. 상속
   • 기존 객체의 특성 재사용 가능
4. 다형성
   • 동일한 메시지에 대해 객체마다 다른 방식으로 동작

객체지향 방법론에서는 데이터와 함수를 하나의 객체로 묶고, 객체 간 메시지 전달을 통해 상호작용하며 기능을 수행한다. 또한 클래스와 객체를 중심으로 시스템을 설계하며, 이를 통해 재사용성, 유지보수성, 확장성을 향상시킬 수 있다.