[면접] 개발 방법론이란?

 

 

이번에는 제가 면접때 답변하지 못한 질문들을 정리하는 시간을 가지려고 합니다.

 

개발 방법론은 이전에도 처음 정처리기사 필기시험 당시에 들었던 내용입니다.

개발 밥범론을 정의하고 적는일이야 간단하지만 개념을 보면서도 이해가 되지 않고 이런 생각이 들었습니다.

 

개발 방법론이라는게  도대체 왜 생긴거고 정확히 무엇일까?

 

 

개발 방법론을 알기 이전에 먼저 소프트웨어 개발이 무엇인지 정확히 알고 넘어갈 필요가 있습니다.

 

 

말그대로 '소프트웨어(software)를 개발한다'라는 내용입니다.

 

풀어서 예기해보면 

 

"소프트웨어 개발(software development)은 시장 목표나 사용자의 요구를 소프트웨어 제품으로 만드는 과정을 말합니다."

 

 

여기서  소프트웨어를 개발하려면 어떻게 해야할까요?

개발자만 많다고, 실력 있는 개발자들이 모였다고 좋은 소프트웨어 개발이 가능할까요?

 

아니에요.

소프트웨어 개발에는 순서가 존재합니다.

 

 

소프트웨어 개발 순서는 다음과 같습니다.

•  시장 탐구
•  제안된 비즈니스 솔루션을 위한 요구 사항 수집
•  문제 분석
•  소프트웨어 기반 솔루션을 위한 계획 및 디자인 수립
•  소프트웨어 코딩
•  소프트웨어 테스트
•  개발
•  유지 및 버그 수정

 

 

 

이렇게 우리가 어떤 것을 만들지, 어떤식으로 개발할지 먼저 예기해보고 정리한다음 계획대로 만드는게 훨씬 좋을겁니다.

 

여기서!!

사람들은 소프트웨어를 이때까지 사람들이 몇개나 만들어왔을까요? 

컴퓨터가 개발된 후를 가정해도 무수히 많은 소프트웨어가 존재할 거에요.

 

이때까지 사람들이 소프트웨어를 개발하면서

 

 

"야, 우리가 이런식으로 계획하고 만드니까 좋더라 이런식으로 개발해보는건 어떤거 같아?"

 

"어 진짜 좋네!! 이 방법대로 소프트웨어를 만드는게 진짜 좋은거같아"

 

"이 소프트웨어 개발 모델을 ~~개발 모형(모델)이라고 칭하자"

.

 

소프트웨어마다 성향이 다르니 모두 똑같이 개발 모형을 잡고 개발을 할수는 없습니다.

때문에 정말 다양하고 많은 개발 모형들이 나오게 된거고

 

이 개발모형에서 여러분야에서 많이 나타난 유명한 

"폭포수 모델"이나 "나선형 모델"이 나타나게 됩니다.

여기서 나타난 모형이

현재 유명하게 사용되는 2가지 모형인 스크럼, 애자일 개발 모형입니다.

 

 

1. 애자일 개발 모형(모델) 

 

먼저 이 애자일 개발모형을 알려면 폭포수 모델을 알아야 할 필요가 있습니다.

 

 

 

 

한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 

 소프트웨어 개발도 각 단계를 확실히 매듭짓고,

  다음 단계로 넘어간다는 의미에서 붙여진 명칭이에요

 

 

각 단계가 명확하여 관리가 용이하지만,

폭포수 모델을 따르기 위해서는

 완전히 순차적으로 한 단계, 한 단계를 진행해 나가야 하죠.

 예를 들어, 가장 먼저 요구사항 기술을 진행하여 이를 확정하여야 하며, 

그런 이후에 설계를 진행할 수 있습니다. 

 

 

즉, 폭포수 모델은 전 단계가 수행되어 완료되기 전에는 

다음 단계로 진행할 수 없도록 제한되는게 가장 큰 특징입니다.

 

 

그러므로 요구 분석에 상당한 시간이 소요되며, 

일단 분석이 끝나면 수정이 어렵다는 단점을 지니게 돼요.

 

 또 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려우며, 

규모가 크고 복잡한 시스템에는 적합하지 않습니다.

 

 

이 폭포수 모델에 비판적인 견해를 가진 사람들이 많은데 그 이유는

주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지입니다. 

 

의미있는 규모의 프로젝트에서는 

다음 단계에 대한 이해나 경험 없이,각 단계를 완벽히 마무리한 후 

다음 단계를 진행하는 것이 불가능하다는 것이죠. 

 

예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 

정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있겠죠?

 

또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 제어하는것은 어려운 일이라 생각합니다.

 

만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 

설계는 새로운 요구사항을 위해 변경되어야 하고

그때까지 투입된 시간은 무로 돌아가게 되겠죠.

 

 

또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기는 어렵습니다.

 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 생기는거죠.

 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 

재설계를 택하는 것이 향후 발생할 수 있는 

더 큰 문제 상황을 방지하는 데 나은 선택이 될 수 있습니다.

 

 

그리고 

 

이 폭포수 모델을 보완해서 나오게 된게

바로 애자일 개발 프로세스(애자일 모델)입니다.

 

애자일? 폭포수와 다르게 사실 들어도 저는 아무생각이 들지 않았어요..ㅋㅋㅋ

처음 들어보는 영어 단어이기도 해서....

 

Agile

- 날렵한, 민첩한

 

이라는 뜻입니다. 

]

 

 

애자일 모델과 위 폭포수 모델의 가장 큰 차이점은

 "less document-oriented"

즉 문서를 통한 개발 방법이 아니라, code-oriented.

실질적인 코딩을 통한 방법론이라는 점입니다.

 

애자일 개발 프로세스는  

계획을 통해서 주도해 나갔던 과거의 방법론(폭포수 모델)과는 다르게 

앞을 예측하며 개발을 하지 않고, 

 

일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 

그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style 이라고 할 수 있습니다.

 

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 

"애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것)

 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말이다.

 

애자일을 간단하게 정리하면 아래와 같습니다.

 

 

• 1. 개발자와 고객 사이의 지속적 커뮤니케이션을 통하여 변화하는 요구사항을 수용한다.
• 2. 고객이 결정한 사항을 가장 우선으로 시행하고, 개발자 개인의 가치보다 팀의 목표를 우선으로한다. 
• 3. 팀원들과 주기적인 미팅을 통해 프로젝트를 점검한다.
• 4. 주기적으로 제품 시현을 하고 고객으로 부터 피드백을 받는다.
• 5.  프로그램 품질 향상에 신경쓰며 간단한 내부 구조 형성을 통한 비용절감을 목표로한다. 

 

2. 스크럼 개발 모형(모델) 

 

그리고  애자일 개발 프로세스로 불리는 개발 방법론 중 하나가 바로

스크럼입니다. 

 

스크럼(scrum)은 원래 

원래 럭비 경기에서 사용되던 용어입니다.

럭비에는 스크럼(scrum)과 라인 아웃(line out)이라는 

두 가지 기본 대형이 있습니다. 

이 중 스크럼은 반칙으로 인해 경기가 중단됐을 때 쓰는 대형이에요. 

반칙이 행해진 장소에 되도록 가까운 곳에서, 양 팀의 7∼8명이 서로 밀집하여 팔을 꼭 끼고 하나의 집단을 형성해 상대 팀을 앞으로 밀치는 대형을 말합니다.

 

 

이렇게 럭비 경기에서 쓰이던 용어가 

소프트웨어 개발 프로세스에서 사용되는 것은 

"팀이라는 단어가 주는 의미를 개발 팀에 적용하여 

효율적인 성과를 얻기 위해서"라고 합니다.

 

 

스크럼 프로세스도 '프로세스'이기 때문에 과정이 존재할 겁니다.

 

 

위 그림이 스크럼 개발 프로세스를 보여주는 좋은 예시입니다..

 

1. 제품 기능 목록 작성

 

개발할 제품에 대한 요구 사항 목록( 제품 기능 목록) 작성.제품 기능 목록은 우선순위가 매겨진, 사용자의 요구 사항 목록이라고 할 수 있어요.이 제품기능 목록은 사용자와 계속 미팅하면서 목록이 완성되게 됩니다. 한 번 결정된 제품 기능 목록은 확정된 것이 아니고 개발 중이라도 수정이 가능하지만, 일반적으로 한 주기가 끝날 때까지는 제품 기능 목록을 수정하지 않습니다.
2. Sprint Backlog각각의 스프린트 목표에 도달하기 위해 필요한 작업목록

제품 기능 목록이 사용자가 원하는 우선순위가 부여된 제품의 기능 목록이라면, 
스프린트 구현 목록은 각각의 스프린트 주기에서 개발할 작업 목록을 말합니다. 
작업 목록에는 
1. 세부적으로 어떤 것을 구현해야 하는지에 대한 세부 작업 항목2 .작업자3. 예상 작업 시간 
등에 관한 정보를 작성합니다. 이와같은 자료를 기반으로 스프린트를 개발하는 데 걸리는 일정을 계산할 수 있고, 필요한 자원도 확보하여 최종적으로는 개발이 어떻게 진행되고 있는지 진척상황을 파악할 수 있습니다. 스프린트 구현 목록을 스프린트 계획 회의에서 결정하며, 이 작업 목록 하나하나가 개발이 완료되면 스프린트 주기는 완성됩니다. 

3. Sprint 
위에서 계속 스프린트, 스프린트라고 그래서 "스프린트가 도대체 뭐야?"라고 생각하셨을 것 같아요.
스프린트는 영어단어로,

Sprint

- (짧은 거리를) 전력질주하다.

- 전력질주 

 

라는 뜻을 가지고 있습니다.

 전력 질주가 마라톤 같은 장거리 달리기가 아닌 단거리 달리기에서 가능한 것처럼, 스프린트는 작업량으로 볼 때 그렇게 많지 않고, 개발 기간도 짧습니다. 

즉, 스크럼 모델에서의 스프린트 뜻은 

"반복적인 개발 주기"를 의미합니다. 

 

 

예를 들어서, 내가 한달동안 문제를 

3~5일에 5개씩 총 40개를 푸는 것으로 계획을 세웠다면, 

3~5일의 단위가 반복되면서 문제들을 풀어나가게 됩니다.

여기서 3~5일 단위가 반복 주기이고,

스크럼에서는 이것(3~5일 단위)을

스프린트라고 합니다. 

 

 

 

스크럼에서 반복 주기의 기간은 스프린트 계획 회의를 통해 결정하는데,

보통은 2~4주 정도로 수행합니다.

요구사항이 안정적이고, 

개발 팀이 애자일 방법에 대해 지식과 경험이 풍부하다면 

2주 정도의 짧은 기간을 스프린트 주기로합니다.

 

 

그러나 요구사항의 변화가 많고, 

개발팀의 역량이 낮다면 4주정도의 기간을 스프린트 주기로 합니다. 

 

 

스프린트 주기가 결정되면, 

개발 팀은 팀원의 역량에 맞게 

스프린트에 배정된 작업을 중간에 멈추는 일이 없이 

모든걸 끝내야 합니다.

 

 

그러려면 

결정된 스프린트의 목표과 내용이 개발 도중에 바뀌지 않아야 하고, 

그 누구도 팀원들의 동이 없이 바꿀 수 없다는 원칙을 지켜야합니다.

 

 

즉, 스프린트를 간단하게 요약하자면,

작은 단위의 개발 업무를 단기간 내에 전력 질주하여 개발한다

는 뜻으로 보면 될 것 같습니다. 

 

 

이 스크럼 모델에는 특징이 하나 있는데요, 

위 그림에서 볼 수 있듯이

매일 일일 스크럼 회의를 진행합니다.

 

 

4. 일일 스크럼 회의 (Daily Scrum Meeting)

 

이 일일 스크럼 회의는 스프린트 기간에 하는 회의로, 아래와 같은 특징을 가지고 있습니다.

 

---

 

• 매일 한다.
• 서서 한다.
• 약속된 시간에 한다.
• 짧게(15분 정도) 한다.
• 진행 상황만 점검한다.
• 스프린트 작업 목록을 잘 개발하고 있는지 확인한다.
• 모든 팀원이 참석한다.
• 한 사람씩 어제 한 일을 이야기한다.
• 한 사람씩 오늘 할 일을 이야기한다. 
• 한 사람씩 문제점 및 어려운 점 정도만 이야기한다. 
• 매일 완료된 세부 작업 항목을 완료 상태로 옮겨 스프린트 현황판을 업데이트한ㄷ.
• 개별 팀원에 대한 진척 상태를 확인힌다.
• 그날의 남은 작업량을 소멸 차트에 표시한다. 

 

---

 

 

5. 제품완성과 스프린트 검토회의 

 

모든 스프린트 주기가 끝나면 제품 기능 목록에서 개발하려고 했던 제품(finished work)이 완성되게 됩니다.

 

이 최종 제품이 나오게되면 스프린트 검토 회의(sprint review)란 것을 

하게 되는데요, 우리가 만든 최종 제품이 처음에 계획했던, 

즉 고객이 요구했던 사항에 얼마나 부합하는지 

참석자(고객포함)들 앞에서 시연합니다. 

그러고 나서 개선할 점 등에 관해 피드백을 받죠. 

 

 

 

6. 스프린트 회고(spring retrospective)

 

회고는 지나간 일을 돌이켜 생각해보는 것이죠? 

그러므로 스프린트 회고는 

그동안 스프린트에서 수행한 활동과 개발한 것을 되돌아 보고, 

개선점은 없는지, 팀이 정한 규칙이나 표준을 잘 준수했는지

 등을 검토하는 것이에요. 

이때 팀의 단점을 찾기보다는 강점을 찾아 더 극대화하는 데 주안점을 둡니다. 또한 문제점에 대한 해결 방안을 찾는 회의가 아니므로 

문제점을 확인하고 기록하는 정도로만 진행합니다. 

그리고 추정 속도와 실제속도를 비교해보고, 차이가 크면 

그 이유를 분석해보지만, 프로세스 품질은 측정하지 않습니다. 

 

 

여기까지가 스크림 모델의 프로세스입니다.

 

 

이제는 스크럼모델을 사용했을 떄 장점과 단점을 알아 보겠습니다.

 

---

스크럼 방식의 장점

 

• 반복주기(스프린트)마다 생산되는 실행 가능한 제품을 통해  사용자와 충분히 의견을 나눌 수 있다.
• 일일회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능.
• 일일 회의 시 직접 자신의 일정을 발표함으로써 
• 업무에 집중할 수 있는 환경이 조성된다.
• 다른 개발 방법론들에 비해 단순하고 실천지향적이다. 
  
• 스크럼 마스터는 개발 팀원들이 목표달성에 집중할 수 있도록 팀의 문제를 해결한다. 
• 프로젝트 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능.
  

 

스크럼 방식의 단점

 

• 추가작업 시간 필요 
• 반복주기(스프린트)가 끝날 때 마다 실행가능하거나 테스트할 수 있는 제품을 만들어야한다. 이 작업이 많아지면, 그만큼 작업 시간이 더 필요하다. 
• 일일 스크럼 회의를 15분 안에 마쳐야함
• 투입에 대한 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 확인이 어렵다.
• 프로세스 품질 평가 불가 : 스크럼은 프로젝트 관리에 무게중심을 많이 둔 방법입니다
  

 

 

이제 스크럼 모델을 정리 해보겠습니다.

 

 

 

스크럼 모델은

애자일 개발 방법론 중 하나로, 

회의를 통해 '스프린트'라는 개발 주기를 정한 뒤,

이 개발 주기마다 회의때 정했던 계획들을 구현합니다. 

그리고 이 하나의 개발주기(스프린트)가 끝날 때 마다 

스프린트 검토 회의를 통해 

생산되는 프로토타입을 통해 사용자들의 피드백을 받으며 

더 나은 결과물을 구현해낼 수 있습니다.