
블로그 작성법
목표 > 공부한 내용 > 얻었고, 앞으로 이걸 해봐야지 적기
지금 우리 팀 프로젝트의 개발 방법론(모델)은 무엇일까?
두가지 큰 방법론으로 애자일과 폭포수 모델이 있다.
두가지 방법론에 대해서 제대로 알아야 겠다. 방법론을 적용하기 위한 구체적인 실행은 어떻게 할 수 있을까?
장점
소프트웨어 개발 프로세스 단계들이 다 분리가 되어있다.
그러므로, 한 단계 한 단계 완성도 높은 단계를 만들어 낼 수 있으므로,
이 높은 완성도를 기반으로 다음 단계를 진행할 수 있다.
단점
하나의 단계를 기한 내에 마치지 못할 경우 다음 단계로 넘어갈 수가 없어서, 기한 내에 프로젝트를 완성하지 못하는 경우가 발생한다.
장점
폭포수 모델의 단점을 통해 등장한 개념으로써
하나의 스프린트라는 기간을 정함으로써 (ex> 6개월이면 1달 1달 1달,, 이런식으로 쪼갬)
하나의 스프린트 동안 리뷰, 오늘 뭐할건지, 내일 뭐할건지
매일 매일 한 바퀴 한 바퀴 돌면서 한 달 스프린트를 채움.
그러므로, 모자라더라도 산출물이 생긴다.
회고 도 이 개념에서 등장한 개념이다.
모든 회사가 모든 프로젝트에 애자일 개념을 적용하기 시작했고,
많은 회사, 부트캠프에서 회고, TIL 등을 하도록 한다.
단점
빠른 변화와 유연성에 적응할 수 있어야 하며, 대규모 프로젝트의 경우에는 적용이 어려울 수 있다.
폭포수 모델은 하나의 단계만 집중해서 한다면, 사시미 모델은 앞 단계를 조금씩 보완하면서 현재 단계를 진행하는 폭포수 모델을 개선한 모델이다.
위 두 가지 방법론을 구체적으로 실행하기 위해 어떻게 나아가야 할 지 나의 생각을 간단하게 정리해보았다.
폭포수 방법론
폭포수 방법론을 프로젝트에 적용하기 위해서는 다음과 같이 해보면 좋을 것 같다.
폭포수 방법론은 순차적인 접근 방식을 중요시 하는 방법론이다.
지금 진행하는 단계가 완료되어야 다음 단계로 넘어갈 수 있다.
이 방법론의 실행을 위해서는 다음과 같은 단계들을 완성하며 나아가는 것이 필요하다고 생각한다.
첫 번째는 요구사항 분석이다.
우리가 진행하고자하는 프로젝트가 어떠한 미션을 목표로 하는지 생각해보자. 그러면 먼저 큰 그림이 그려질 것 같다.
큰 그림이 그려진다면 이제 이를 완성하기 위해 어떠한 것들이 필요할 지 필요사항 들에 대해 자료 조사를 해볼 것 같다.
그리고 우리 프로그램을 사용할 사용자들의 요구사항 에 대해 데이터 지표, 논문 등을 찾아볼 것이다.
두 번째는 설계 이다.
위 요구사항 분석 단계를 완성하였다면 이제는 프로젝트를 설계하는 것이 필요하다.
우리 프로젝트의 시스템을 어떠한 아키텍처로 구성할 것인지 시스템의 설계도를 작성해본다.
아키텍처를 구성한 후, 각 기능 별로 컴포넌트를 명세할 것이다.
컴포넌트가 갖춰졌다면 컴포넌트에서 필요한 인터페이스, 추상클래스들을 그려볼 것이며, 데이터는 어떠한 데이터 형태를 어떻게 주고 받을지 DTO, DAO, ERD 등을 설계할 것이다.
세 번째는 구현 이다.
설계 단계에서 정의한 명세들을 기반으로 개발 단계에 돌입할 것이다.
네 번째는 통합 및 테스팅 이다.
설계 단계에서 명세한 것들을 기반으로 실제 구현을 하였어도, 많은 오류와 로직의 개선이 필요한 경우가 발생할 것이다.
이를 위해, 우선 개발한 각 컴포넌트를 통합하고, 이 통합된 프로그램을 테스팅하여 개선 사항들을 찾아낼 것이다.
다섯 번째는 배포 이다.
컴포넌트를 통합하고, 테스트 단계를 거친 후에는 이제 우리의 프로그램을 사용자에게 선보일 차례이다.
따라서, 배포를 하는 과정이 필요하다.
여섯 번째는 유지보수 이다.
다수의 사용자가 프로그램을 경험하면서 겪은 많은 에러 사항들을 피드백 하여 프로그램을 업데이트하는 과정이 필요하다. 이러한 과정들을 통해 프로그램의 완성도를 높일 수 있을 것이다.
애자일 방법론
애자일 방법론을 앞으로 진행할 프로젝트에 적용하기 위해서는 다음과 같은 구체적인 과정이 필요하다고 생각한다.
첫 번째는 프로젝트 계획 이다.
폭포수 모델과는 약간의 차이가 있다고 생각한다. 프로젝트의 전반적인 규모, 미션을 수립하는 것은 맞으나 변화 시킬 수 있고 유연하게, 빠르게 진행하기 위해 대략적으로 수립하는 것이 필요하다고 생각한다.
두 번째는 스프린트 계획 이다.
계획을 대략적으로 하였으면, 앞으로 진행할 작업들을 한 달 정도의 기간을 단위로 잡아 스프린트로 나눈다.
그리고, 각 스프린트에서 우리가 어디까지 구현해 낼지 목표를 수립하고, 각 목표를 이루기 위해 어떠한 작업들이 필요할지 리스트로 정리해본다.
세 번째는 스크럼 이다.
스크럼은 매일 하는 것이 중요하다.
짧은 회의를 통해 오늘 각 팀원들이 무엇을 했으며, 앞으로 무엇을 할 것인지, 그리고 앞으로 해나갈 것에 있어 어떠한 장애물이 있는지를 서로 공유해보자.
네 번째는 스프린트 실행 이다.
위 단계들에서 앞으로 무엇을 할지 작업들을 정했다면, 항목들을 기반으로 개발 작업을 진행하자.
다섯 번째는 스프린트 검토 및 회고 이다.
한달 간의 스프린트가 진행된다면, 하나의 스프린트가 끝나간다면,
팀원들과 어느 작업까지 완료하였는지 검토하고, 팀이 어떻게 개선할 수 있을지 논의하자.
나는 애자일과 폭포수 방법론 중 애자일 이 더 선호되는 것 같다.
그 이유는 두 가지이다.
첫 번째는 프로젝트는 완성도가 중요하다고 생각한다. 기한 내에 산출물을 완성해 내는 것이 중요하다고 생각하며, 그렇기에 애자일이 더 선호되는 것 같다.
두 번째는 앞 단계의 지체가 뒷 단계에 영향을 주기 때문이다.
폭포수 방법론은 앞 단계를 완성하지 못한다면, 다음 단계로 넘어가지 못하는 것이 완성도가 중요한 프로젝트에서는 장점이라고 생각하나, 프로젝트를 진행할 때 완성도가 조금은 부족하더라도 다음 단계를 먼저 진행하는 것을 선호하는 편이다.
설계가 중요할까 개발이 중요할까
내 생각은 설계가 더 중요하다고 생각한다.
하나의 프로그램에 대해 먼저 이 프로그램이 어떻게 구성될지, 어떻게 동작할지 팀원들과 소통하며 설계를 먼저 진행한 후에, 그에 핏하게 개발을 하게 된다면 모두가 원하는 산출물을 도출해 낼 수 있을 것 같다.
이 주제에 대해 알아보던 도중에 다음과 같은 글귀가 인상 깊었다.
설계는 변경의 비용이 높은 결정을 미리 잘 내리는 것이다
위 글귀에서 프로젝트를 진행하면서 느꼈던 것들이 떠올랐다.
첫번째는, DB를 설계하면서 느꼈었다. 프로젝트를 해보면서 느꼈던 것은 DB를 미리 잘 설계하는 것이 매우 중요하다는 것을 느꼈다. 중간에 DB를 수정할 일들이 있었는데, 다시 설계를 하면서 테이블 명, 컬럼 등을 짜고 그에 대한 데이터를 수집하고 저장해놓는 것은 시간적인 비용이 많이 소모되었었다.
두번째는, 프로젝트의 아키텍처를 제대로 설계하지 않고 개발을 하면서 느꼈었다. 예전에 알고리즘으로 배틀을 하는 프로젝트를 진행하면서, 유저간에 실시간으로 통신을 할 기능이 필요하여 처음으로 WebSocket을 사용할 일이 생겼다. RestAPI에 대한 설계 방법에 대해서는 배웠지만, WebSocket은 어떻게 설계해서 진행해야 할지 잘 알지 못하여 일단은 구현을 하면서 프로젝트를 진행하였었다. 그러나, 프로젝트가 진행될 수록 코드와 아키텍처의 복잡성이 증가하였고, 후에 다시 구조를 고치는 작업을 진행하였다. 이는 시간적으로 많은 비용을 소모하는 작업이었다. 다행히 진행한 프로젝트의 규모가 소규모이었기에 혼자서 진행이 가능하였지만, 대규모 프로젝트의 경우 중간에 구조를 변경시키는 것은 많은 비용이 필요할 것이라는 생각이 들었다.
오늘은 소프트웨어 개발 방법론의 대표격이라 볼 수 있는 폭포수 모델과 애자일 방법론에 대해서 배우게 되었다. 앞으로 학원에서 자바, 스프링을 이용한 프로젝트들이 예정 되어있는데, 프로젝트를 진행하면서 팀원들과 방법론에 대해 토론한 후, 적합한 방법론을 우리의 프로젝트에 적용하여 진행해보고 싶다.