폭포수 방법론에서 애자일까지

Eric·2022년 1월 15일
0
post-thumbnail

해당 게시글은 존 손메즈 저자의 <커리어 스킬>에서 일부 내용을 참고해 작성되었습니다.
(일부 내용에는 오류가 있을 수도 있습니다, 양해 부탁드립니다 ㅜㅜ)

📖 개요

소프트웨어를 개발하는 방법을 일컫는 개발론은 매우 중요할 뿐더러, 지난 수십년 간 수많은 사람들에게 논쟁의 대상이 되어왔습니다. 오늘은 이 말도 많고 복잡하게 생긴, 개발론이 도대체 뭔지 알아보도록 하겠습니다.

✔️ 배경지식

소프트웨어 개발 방법론이란?

앞서 언급한 것처럼 소프트웨어 개발 방법론소프트웨어의 제작 절차를 일컫습니다. 이러한 방법론 중에서는 간단한 규칙들만 지키면 되는 것들도 있는 반면, 수많은 규칙들을 지켜야 하는 복잡한 것들도 존재합니다.

SDLC의 정의

SDLC는 Software Development Life Cycle의 약자로, 소프트웨어 개발 생명주기를 말합니다. 일반적으로 이러한 생명 주기는 다음과 같이 이루어집니다 :

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

🌊 폭포수(Waterfall) 방법론

폭포수 방법론이란?

폭포수 방법론은 폭포에서 떨어지는 물이 한 곳으로 떨어진 뒤, 다시 다른 곳으로 차례대로 떨어지는 것과 비슷하다고 하여 붙여진 이름입니다.

폭포수 방법론에서는 앞에서 언급한 SDLC를 전체 과정에 적용한다고 생각하면 됩니다. 이러한 조건 탓에 다음과 같은 특징을 지닙니다 :

  • 설계를 다 끝내놓고 개발에 착수
  • 문제가 생기면 다시 돌아가서 피드백
  • 후에 새로운 변경이 생기지 않을 때 사용하면 좋음

이러한 폭포수 방법론은 후술할 애자일 방법론이 나오기 이전까지 주류로 사용되어 왔습니다. (그리고 현재도 일부 개발자나 팀은 이 방식을 사용하고 있습니다)

폭포수 방법론의 과정

위에서 언급한 내용처럼, 폭포수 방법론은 SDLC를 순차적으로 1회 실행하는 방식입니다. (왜 "1회"라는 단어를 굳이 강조하는지는 애자일 방법론에서 설명하겠습니다)

  1. 요구사항 분석 :
    • 고객의 요구사항을 판단
    • 폭포수 방법론 특성상, 설계에 들어가기 전에 다 알아내야 함
  2. 설계 :
    • 요구사항을 바탕으로 시스템과 아키텍처 구상
    • 폭포수 방법론에서는 방대한 사전 설계(big upfront design) 방식을 사용함
      • 방대한 사전 설계 : 세부 사항 대부분에 대한 계획을 낮은 수준까지 설계 단계에서 정해두는 것
  3. 구현 :
    • 설계사항을 코드로 구현하는 과정
  4. 테스트 :
    • 테스터는 테스트 케이스 등을 이용해 "가능한 많은 버그"를 찾고, 개발자는 이를 수정해야 함
  5. 배포 :
    • 개발한 프로그램이 실제로 동작하는지 확인해야 함
    • 만약 별도로 개발한 컴포넌트가 여러개라면, 이를 하나로 묶어야 함
      • 이를 통합이라고 말한다
  6. 유지보수 :
    • 소프트웨어는 출시 이후에도 지속적으로 지원해야 함
    • 고객이 버그를 발견하면, 이를 수정해야 함
    • 새로운 기능을 추가해야 함

단점

  • 앞서 언급한 신규 요구사항 수용의 어려움
  • 이로 인한 변화가 생기면 소프트웨어를 갈아엎거나, 이 요구사항을 거절해야 한다

🔃 애자일(Agile) 방법론

애자일 방법론이란?

애자일 방법론은 SDLC 1회를 전체 과정으로 삼는 폭포수 방법론과는 달리, SDLC를 여러번 반복하면서 요구사항을 더하거나 수정해 나가는 방식입니다. 덕분에 다음과 같은 특징들을 지닙니다 :

  • 짧은 개발 주기를 강조
  • 변경이 잦은 곳에서 사용하면 좋음

사실 엄밀히 말하자면, 폭포수 방법론에 비해 비교적 추상적인 의미를 지니기에 이를 실질적으로 구현하는 여러가지 방법론이 존재합니다. (객체 지향으로 비유하면, 애자일은 Interface고 방법론들은 이를 구현하는 Class 정도?) 이에 대해서는 잠시 후에 스크럼/칸반/익스트림 프로그래밍으로 설명하도록 하겠습니다.

애자일 선언문의 12가지 원칙

애자일 선언문은 2001년에 17명의 개발자가 모여 만든 선언문으로, 애자일 방법론의 시작을 알리는 글이기도 합니다. 애자일 선언문의 원문은 여기서 확인이 가능합니다. 🔗애자일 소프트웨어 개발 선언

이 선언문에는 다음과 같은 12가지 원칙이 존재합니다 :

  1. 우리는 가치있는 소프트웨어를 빠르게 그리고 지속적으로 제공해서 고객을 만족시키는 것을 목표로 한다.
  2. 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해서 고객의 경쟁력을 높이는 데 기여한다.
  3. 새로운 소프트웨어는 몇 주나 몇 달의 주기로 자주 제공하라. 간격은 짧을수록 좋다.
  4. 프로젝트가 진행되는 동안 사업부서 사람들과 개발자는 매일 만나서 함꼐 일해야 한다.
  5. 의욕 있는 사람들 위주로 팀을 구성하라. 그들이 필요로 하는 환경과 지원을 제공하고 그들이 맡은 일을 완수할 거라고 믿어라.
  6. 개발팀으로, 혹은 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 서로 얼굴을 보고 하는 소통이다.
  7. 업무 진척을 측정하는 기본 척도는 작동하는 소프트웨어다.
  8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 후원자, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
  9. 기술적 우수성과 좋은 설계에 대한 꾸준한 관심이 기민성을 높인다.
  10. 해야 할 일의 양을 최소화하는 단순성이 꼭 필요하다.
  11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 나온다.
  12. 팀은 정기적으로 더 효과적으로 일할 방법을 고민하고 이를 통해 이른 결론에 따라서 팀이 어떻게 움직일지 조율하고 조정한다.

스크럼(scrum) 방법론

스크럼의 직책

  • 제품 책임자 : 고객과 소통하고, 작업의 우선순위를 결정하는 일 담당
  • 개발팀 : 개발은 물론, 분석/설계/테스트/배포 등 전반적인 일 담당
  • 스크럼 마스터 :
    • 팀이 하는 일을 지연시키는 장애물을 제거
    • 제품 책임자와의 소통
    • 스크럼 프로세스가 문제없이 진행될 수 있도록 돕는, 개발팀의 코치 역할

스크럼의 용어들

  • 스크럼 팀(scrum team) : 각 스프린트를 담당하는 팀
    • 담당하던 스프린트가 끝나면 필요한 인력을 보충하거나 내보낼 수 있음
  • 증분(increment) : 매 스프린트에서 팀이 개발한 제품 기능
  • 스프린트(sprint) : 소프트웨어 개발을 작은 반복 주기로 나눈 것
    • 정해진 기간 내에 해야할 일들이 존재함
      • 일반적으로 1~2주 단위임
      • 기한 안에 구현하지 못한 일은 미완료 처리되고 백로그로 돌아감
      • 백로그에서 우선순위에 따라 할 일들을 가져옴
    • 스프린트가 완료되어 나온 증분(increment)은 고객에게 전달됨
  • 백로그(sprint backlog) :
    • 소프트웨어에 들어가야 할 모든 기능들을 기록하는 곳
    • 각 기능들은 우선순위를 지님

스크럼의 진행 방식

  1. 제품 책임자가 고객의 요구사항을 받아 백로그에 기능을 기록하고 우선순위를 매긴다.
  2. 스크럼 팀은 백로그에서 작업할 기능들을 배정받아 새 스프린트를 시작한다.
  3. 시작할 즈음에 계획 회의를 연다.
    • 처리할 백로그 항목을 달성하기 위해 필요한 노력의 수준을 추산한다
  4. 개발이 시작되면 매일 스크럼 회의를 연다.
    • 모두가 모여 자신이 진행하는 업무에 대해 짧게 공유(브리핑)한다.
    • 업무 진행 상황을 공유하고, 업무를 지연시키는 장애물을 제거하는 것이 목적이다.
    • 스크럼 회의의 필수 질문 :
      1. 어제는 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 했는가?
      2. 오늘은 팀의 스프린트 목표 달성에 도움이 될 만한 어떤 일을 할 것인가?
        • 개인적 헌신을 요구하는 것이 좋음
          • 오늘은 팀의 스프린트 목표를 달성하는데 도움이 될 만할 어떤 일에 헌신할 것인가?
      3. 본인이나 팀의 스프린트 목표 달성을 막는 장애물이 있는가?
    • 업무 진행 상황과 속도를 추적하기 위해 소멸 차트를 이용한다
      • 남은 시간, 스토리 포인트, 업무 난이도 등 남은 업무를 확인할 때 필요한 것들을 가능한 많이 추적
  5. 스프린트가 끝나면 완료한 목표들을 관계자에게 보여주는 리뷰를 수행한다.
  6. 지난 스프린트를 되돌아보고 다음 스프린트에 대한 아이디어를 구상하는 회고 회의를 연다.

스크럼 방법론의 문제점

  1. 현실에서는 제대로 수행하기 힘든 경우가 있다.
  2. 스크럼 팀원이 실패를 때우거나(벌충), 변칙을 쓰는 경우 잘 돌아가지 않는다.
    • 실제로 스크럼이 성공적으로 구현되지 못하는 가장 큰 이유는 헌신이 부족해서이다.
    • 헌신하지 못한다면 스프린트에 들어간 백로그는 아무 의미가 없어진다.

칸반(kanban) 방법론

칸반 보드를 통해서 프로젝트에서 해야 하는 일을 시각화하고, 동시에 진행하는 업무의 양을 제한하는 방법

칸반 방법론에 대해서는 저도 이해가 부족해서 자세히 설명하지 못한 점, 양해 부탁드립니다.

익스트림 프로그래밍

익스트림 프로그래밍은 TDD(테스트 주도 개발)를 이용하는 매우 엄격한 방법론입니다.

익스트림 프로그래밍의 용어들

  • TDD(테스트 주도 개발) : 각 기능별로 테스트를 먼저 만들고, 이를 통과하는 코드를 작성하는 개발 방법
  • 페어 프로그래밍 : 개발자 두명이 함께 앉아서 공동으로 작업해 모든 코드를 만드는 것

익스트림 프로그래밍의 진행 방식

  1. 해야 할 일 지정
  2. 각 일들의 완료 기준(테스트 코드 생성)
  3. 테스트 코드를 통과하는 코드 작성

익스트림 프로그래밍의 특징

  • 미래보다는 현재의 필요를 염두에 두고 기능을 최대한 단순하게 설계해서 구현하는 것을 목표로 함
  • 리팩토링을 지속적으로 해야 함
  • 점층적 계획
  • 단순한 설계
  • 지속적 통합 : 특정 작업에 대한 업무가 끝나면 바로 통합되어야 하며, 모든 유닛 테스트를 통과해야 함
  • 고객의 참여 : 고객은 개발팀에게 요구사항을 전달할 책임이 있음
  • 유지할 수 있는 속도 : 많은 양의 초과근무를 허용하지 않음
  • 기타 등등..

👏 마무리하며

사실 방법론의 세계에서, 가장 중요한 것은 어떤 방법론을 고르느냐가 아닌 반복 가능한 프로세스를 갖추었느냐라고 합니다. (존 손메즈 저자의 주장)

또한 그는 책에서 다음과 같이 조언하였습니다 :

  • 특정 방법론을 선택해 이를 상황에 맞게 꾸준하게 실천해 나갈 것
  • 또는 일부를 가져다가 팀의 상황에 맞게 고유한 방법론을 만드는 것도 좋음
    • 단, 스크럼 방법론 등의 경우 변명 등을 허용하는 것은 금지!
  • 내용이 잘 정리되어 있고, 반복이 가능한 프로세스를 갖추는 것이 핵심!

뿐만 아니라 스크럼이나 칸반, 익스트림 프로그래밍 방법론이 아니라고 해서 부적합한 방법론인 것도 아니라고 저자는 강조했습니다. 저는 이러한 방법론을 완벽하게 수행하지는 못할 수 있더라도, 최소한 과정은 숙지하는 것이 개발자로 살아가면서 필요한 역량이라고 생각합니다.

더 높은 곳을 향해 오늘도 달려나가는 개발자 지망생분들의 꿈을 응원합니다.
감사합니다.

profile
Backend Engineer | 코드로 우리의 세상을 어떻게 바꿀 수 있는지 고민합니다

0개의 댓글