[TIL][CS] 소프트웨어 개발 방법론

오늘은! 소프트웨어 공학에서 다루는 내용 중 하나인 '소프트웨어 개발 방법론'에 대해 공부했다. 공부한 내용에 대해 다시 쓰면서 외우기도 하고, 사실 전에 개발을 제대로 시작하기 전에 정처기 필기시험 볼 때 공부를 했었는데, 지금 개발을 제대로 시작한 후 볼 때와 느낌 자체가 달라서 회고도 적을 겸 포스팅해본다.

 

✏️ 소프트웨어란?

• 컴퓨터 하드웨어에게 동작 방법을 지시하는 명령어 집합인 프로그램과, 프로그램의 수행에 필요한 절차, 규칙, 관련 문서를 정리해 놓은 것 
• 분류 : 시스템 소프트웨어, 응용 소프트웨어, 미들웨어 소프트웨어
• 우리가 일반적으로 생각하는 프로그램, 소프트웨어라고 불리는 것들은 대체로 응용 소프트웨어에 해당이 된다.

 

  🔹 시스템 소프트웨어 (System Software)

• 소프트웨어 작동 환경을 구성하고 하드웨어를 관리해주는 역할을 함
• ex) 운영체제, 가상머신, SaaS, 컴파일러, 라이브러리, 디버거
• 일반적으로 우리가 쓰는 컴퓨터, 스마트폰에 들어가는 운영체제가 시스템 소프트웨어에 해당이 됨

  🔹 응용 소프트웨어 (Application Software)

• 사용자가 원하는 업무를 수행하는 소프트웨어
• ex) 그래픽디자인, 영상 편집 프로그램, 문서 프로그램, 음성 처리 프로그램
• 우리가 쓰는 앱, 게임들 같은 것도 응용 소프트웨어에 해당이 됨

  🔹 미들웨어 (Middleward)

• 미들과 소프트웨어의 합성어
• 소프트웨어를 연결해 추가적인 서비스를 제공해주는 역할을 함
• (소프트웨어와 소프트웨어를 연결해주는 기능이라고 보면 됨)
• ex) DB, 웹 어플리케이션 서버

 

✏️ 소프트웨어 공학이란?

• 소프트웨어를 개발, 운용, 유지보수하는 생명 주기의 전반을 다루는 학문
• "소프트웨어 위기에 관해서 주의를 기울이자!"  =>  탄생 배경
• 목적: 소프트웨어의 품질과 생산성을 향상시키고 효율적으로 소프트웨어를 개발하는 것

 

✏️ 소프트웨어 개발 수명 주기 (SDLC; Software development Life Cycle)

• 소프트웨어 개발에 필요한 과정을 단계별로 나눈 것
• 목적: 단계별로 나눈 후, 소프트웨어 요구 사항을 분석해 최상의 소프트웨어를 개발하는 것
• 일반적으로 분석, 설계, 개발, 테스트, 배포 및 유지보수로 구성
• 소프트웨어 생명 주기 모델 : 폭포수 모델, 프로토타입 모델, 나선형 모델, 애자일
• 소프트웨어 개발 생명 주기를 활용하면
  프로젝트를 쉽게 계획/관리 가능, 효율적인 업무 진행 가능, 리스크 관리 가능하게 해줌

  🔹 폭포수 모델 (Waterfall Model)

폭포수 모델

• 이미지에서 보다시피 폭포수처럼 아래를 향해 순차적으로 내려가는 방식
• 선형 순차적 모델로, 가장 전통적인 개발 프로세스 ( = 한 단계가 완전히 끝나야, 다음 단계로 넘어갈 수 있음)
• 장점) 한 단계가 완전히 끝나야 다음 단계로 넘어갈 수 있기 때문에, 예측이 가능하고 효율적임 
• 단점) 한번 오류가 발생하면, 이전 단계로 다시 돌아가서 작업하는 프로세스이기 때문에, (다시 하는데 비용이 또 드니까) 쉽게 쉽게 변화를 반영하기는 어려움

 

🔹 프로토타입 모델 (Prototype Model)

프로토타입 모델

• 요구사항 분석 단계에서, 프로토타입을 만들면서 최종 결과물을 미리 예측하는 모델
• 폭포수 모델의 '이전 단계로 다시 돌아가기가 어렵다'는 단점을 보완하기 위해 탄생함
• 프로토타입을 통해 결과물을 간접적으로 접할 수 있음  →  요구사항 반영과 변경이 쉽게 가능
• 장점) 결과적으로 개발 시간과 비용을 절감할 수 있음 
• 단점) 프로토타입에서 얼마나 시간을 쓸지 알 수 없어서, 프로토타입을 위한 비용 산정이 어려움

 

🔹 나선형 모델 (Spiral Model)

나선형 모델

• 그림처럼 나선형으로 돌아가면서 단계 진행을 하기 때문에 나선형 모델임
• 위험 분석이 추가된 점진적 모델
• 폭포수 모델과 프로토타입 모델의 장점을 가져온 모델로, 요구사항이나 아키텍처가 어려운 경우 적합한 방식임
• 장점) 변경되는 요구사항을 구체적으로 반영할 수 있고, 결과물의 품질이 높음
• 단점) 프로젝트 관리가 조금 복잡하고, 상대적으로 오래 걸림
• 단점2) 위험 분석 단계에서 위험관리 능력에 따라서 제품의 품질이 영향을 많이 받음

 

🔹 애자일 (Agile)

애자일

• 스프린트(Sprint) 혹은 이터레이션(Iteration)이라고 불리는 주기를 반복하는 방법론
• 주기는 대체로 1~4주
• 반복적이고 점진적으로 진행  →  빠른 개발과 빠른 출시 가능
• 그렇기에 주기마다 고객의 평가 요구를 반영할 수 있음 
• 요즘 스타트업에서 많이 사용하는 방법
• 장점이자 단점) 고객 참여가 가능함. 
• 고객 참여가 미흡하면? 요구 사항을 알 수가 없어서 오히려 이 프로세스가 독이 될 수도 있음 
• 단점2) 빠른 개발에만 집중하다 보면 기술 부채가 쌓일 가능성이 있음
• 기술 부채(ex. 급하게 하드코딩, 정리하지 않은 코드, ... )가 쌓였을 때, 다음 스프린트로 넘어가게 되면 쌓인 기술 부채는 어떻게 관리할 것인가?
• 애자일 ex) 스크럼, XP, 칸반, 린 

 

[🔎 소프트웨어 개발 방법론  中 .. ]

✏️ 익스트림 프로그래밍  (XP; eXtreme Programming)

• 반복적으로 진행해서 소프트웨어를 신속하게 제공하는 방법론
• 변동이 심한 요구사항에 대응하기 위해 고객의 참여와 개발 과정을 짧고 반복적으로 진행함
• 목적 : 핵심 가치를 바탕으로 고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것
• 그렇다면 핵심 가치는? 의사소통, 단순성, 피드백, 용기, 존중 (의피존용단으로 외웠다 ㅎ..)
• 다른 애자일 방법론과 차이점은, TDD⭐라고 하는 Test-Driven Development를 실천해서 지속적인 테스트를 진행한다는 것

 

🔹 XP 실천  (XP Practices)

- 총 12가지로 구성

 

  [Fine-scale feedback]

• Pair Programming ⭐ : 두 명의 개발자가 하나의 작업을 공동 수행하면서 코드에 대한 책임을 공유 (번역: 짝 개발 :-) )
• Planning game: 게임처럼 하나의 목표를 두고 기획 진행
• TDD: 단위 테스트를 작성 후 개발 진행
• Whole team: 프로젝트에 참여하는 팀원을 의미하며 가장 중요한 팀원은 사용자
  

 

  [Continuous process]

• Continuous integration(CI): 프로젝트는 항상 빌드 및 배포 가능한 상태로 유지
• Refatoring: 필요한 기능만 유지하고 코드를 항상 간결, 깔끔하게 유지
• Small releases: 빠르게 자주 배포

등등등

 

 

✏️ 스크럼 (Scrum)

사담이지만 필자가 제일 좋아하는 방법론이기도 합니다.

• 요구사항 변경에 대처하기 위한 점진적인 모델
• 스프린트 단위로 팀원 간 활발하게 커뮤니케이션과 협업 진행
• 목표 : 스프린트 단위로 신속하고 반복적으로 동작하는 소프트웨어를 제공하는 것 
• 가치 : 전념(Commitment), 용기(Courage), 집중(Focus), 정직(Openness), 존중(Respect) (전용집정존 으로 외웠ㅎ..)
• 스프린트 플래닝 미팅 → 스프린트 진행 (보통 2, 3주)하며  1일 1 데일리 스크럼 미팅 → 스프린트 리뷰 → 스프린트 회고(Retro)

스크럼

🔹 스크럼 구성원 역할

• 스크럼은 팀원 스스로가 프로세스를 만들어나가는 자기 조직화가 중요
• 즉, 모든 구성원이 중요한 역할을 갖고 있다고 보면 됨 
• 제품 책임자(Product Owner) : 제품 백로그 작성, 백로그 우선순위 관리, 스프린트 계획까지의 업무만 담당
  * 제품 백로그란: 제품에 어떤 기능을 넣을지, 어떤 요구사항이 있는지를 관리하는 백로그
• 스크럼 마스터(Scrum Master) : 스크럼이 잘 수행될 수 있도록 도와주는 역할. 팀원 코딩, 프로젝트 장애 해결, 업무 배분, 목표 결정 업무를 담당
• 스크럼 구성원 : 제품 책임자와 스크럼 마스터를 제외한 모든 사람들. 스프린트 결과물 전달 

 

---

📌 마치며

이러한 방법론들을 공부하면서 각 방법론의 장/단점을 이해하고 어떤 상황에서 어떤 방법론을 적용해야 하는지에 대해 고민해봤다.

프로젝트의 특성과 요구사항을 여러 방면에서 고려해서, 적절한 방법론을 선택하고 효과적으로 프로젝트를 관리하는 것이 중요하겠다라는 생각이 들었다.

확실히 이론도 중요하다고 느낀 게, 개발 방법론이라는 걸 모르고 개발할 때와 알고 개발할 때의 경험은 정말 다를 것이라고 확신했다. 오늘 배운 이론은 소프트웨어 개발에 대해서 넓고 심층적인 이해를 하게 도와줬다.

앞으로도 다양한 방법론을 더 공부하고 앞으로 할 프로젝트에 적용해서 최상의 소프트웨어를 개발하고 싶어졌다.

이상!!