캡스톤 프로젝트란?
캡스톤 프로젝트란 서울시립대학교 컴퓨터과학부 전공 교과과정을 통하여 얻은 이론적 지식을 바탕으로 스스로 도출한 공학문제의 해결을 시도하는 프로젝트이다. 지도교수를 선정하고 3~4명 단위의 팀 단위로 스스로 설계하고 이를 구현한다. 총 5개의 보고서(프로젝트 제안서, 경쟁력 분석 보고서, 개념 설계 보고서, 상세 설계 보고서, 최종보고서)와 최종 결과물을 산출하여 한 학기동안 진행한다.
주제 선택
우리 팀이 개발 과제 주제 선택에 있어서 초점을 맞춘 것은 다음과 같다.
- 사회기여형
- 공공의 이익
- 우리가 불편함을 느끼고 있는 것
- 순수아이디어
이 네 가지를 충족시켜 결정한 주제는 “서울특별시 폐수거함 위치 정보 제공 서비스”이다.
평상시에 우리는 쓰레기와 폐수거함에 관하여 불편함을 가지고 있었다. 또한 사회환경적으로 문제가 있는 폐수거함에 대한 인식으로부터 주제 선정이 시작되었다. 지난 1995년 서울시 쓰레기통 종량제에 시행된 설치 갯수는 약 7607개였지만, 서울시는 2007년을 시작으로 약 3707개 가량 줄이게 되었다. 대중교통 이용시에도 뚜겅이 없는 음료나 음식이 승차 거부 되었고 폐수거함에 대한 위치 정보가 부족해서 시민들이 찾아버리기 귀찮다는 것을 이유로 종량제 봉투에 버리거나 하수구에 배출하는 일이 빈번하게 일어나는 것을 포착하였다.
그래서 이에 대한 해결방안으로 폐수거함을 찾지 못하는 서울 시민과 폐수거함을 관리하는 지자체에게 제공함으로써 프로젝트 방향을 설정하였다.
애자일 방법론 도입
애자일이란?
위키피디아에서는 애자일 방법론의 정의를 다음과 같이 소개하고 있다.
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).
한 문장으로 써있어서 내용이 조금 길지만, 애자일 소프트웨어 개발은 self-organizing(팀원 스스로가 효율적인 업무 분담을 담당하는)팀이나 cross-functional(서로 다른 기능적 전문성을 지닌 사람들이 공통의 목표를 향해 노력하는) 팀이 협업의 노력을 통해서 요구사항과 해결책을 발전시키는 소프트웨어 개발방식이다.
우리팀의 애자일 도입 계기
서울시립대학교 컴퓨터과학부 전공 3학년 교과과정에는 “소프트웨어공학” 과목이 포함되어있고 팀원 모두가 이 과목을 수강하였다. 이 과목에서 소프트웨어 개발 전 과정에 지속적으로 적용할 수 있는 방법에 대한 소프트웨어 개발 방법론을 배웠고, 효율적인 프로젝트 진행을 위하여 효율적인 방법론을 선택하기로 하였다.
그래서 절차보다는 사람이 중심이 되고 변화에 유연하고 신속하게 대응하며 효율적으로 개발할 수 있는 애자일 방법론을 도입하여 개발할 수 있게끔 하였다.
공공의 이익과 사회기여를 위한 서비스를 선택하였기 때문에 사람이 중심이 되는 애자일 프로세스가 적합하다고 생각하였고, 지도교수님과 캡스톤 담당 교수님의 매주 피드백을 적극적으로 반영하기 위해서 유동적으로 개발하기 위하여 애자일이 적합하다고 생각하였다.
우리팀의 애자일 실천 방법
학기를 병행하며 진행하는 캡스톤 프로젝트이기 때문에 잘 동작하는 애자일 법칙과 팀원들이 같이 논의하여 우리 팀만의 효율적인 실천 방법을 적용하여 애자일을 실천하였다.
우리팀을 애자일 실천 방법을 크게 프로젝트 관리 측면과 프로그래밍 측면으로 나누었다.
프로젝트 관리 측면
- 스크럼 프로세스
- 유저스토리와 MosCow
스크럼 프로세스
9월부터 12월까지 약 4개월 간의 캡스톤 프로젝트 기간동안 협업을 일정한 단위로 쪼개서 진행하였다. 여기서 말하는 일정한 단위는 일정한 주기를 바탕으로 반복되는 개발 주기를 의미하는데, 이것을 스프린트라고 부른다.
우리팀은 프로젝트 특성상 짧은 기간 내의 기획부터 개발, 테스트, 배포 운영까지 이루어져야 하기 때문에 큰 릴리즈는 1~2번으로 가정하고 스프린트는 1~2주 간격으로 진행함으로써 애자일 스크럼 방법론을 적용하였다. 그리고 팀 구성원은 모두가 Project Owner이자 개발자의 역할을 수행하였다.
우리팀이 정의한 스크럼 프로세스는 다음과 같다.
- 프로덕트 기능 목록 작성
- 개발할 제품에 대한 요구사항 목록을 작성한다.
- 요구사항의 목록들을 각각 유저 스토리 형태로 작성한다.
- 유저 스토리 형태로 작성한 후 스토리의 중요도와 우선순위를 확인할 수 있도록 MosCow를 이용한다.
- 스프린트 플래닝
- 스프린트 기간동안 어떻게 우리 일을 해 나갈지, 모든 팀원이 모여서 스프린트 첫날에 작업 계획을 공유하고 소통한다.
- 프로세스
- MosCow를 기반으로한 Task를 백로그화하여 쌓는다.
- Github 마일스톤을 생성
- 백로그들을 Github Issue로 등록
- 스프린트
- 우리가 설정한 스프린트가 끝날 때까지 본격적으로 스프린트를 시작한다.
- 주 2회 스크럼을 실시한다.
- GitHub Projects를 확인하며 전체 진행상황을 공유한다.
- 프로세스
- Issue 담당자 지정
- Issue 상태를 In Progress로 변경하고 작업 시작
- 작업이 완료되면 PR과 코드 리뷰를 실시한다.
- Approve를 받게 되면 Main 브랜치에 머지하고, Issue 상태를 Done으로 바꾸고, Issue를 닫는다.
- 스프린트 리뷰, 회고
- 스프린트를 끝내고, 다음 스프린트는 어떻게 효율적으로 진행할지 이야기한다.
- 다음 스프린트 시작
- 다 마치고 나면 처음으로 돌아가 새로운 스프린트를 시작한다.
위에서 정의한 우리 팀의 애자일 스크럼 프로세스를 잘 적용하기 위해서 사용한 개발 인정 관리 툴은 GitHub Projects와 GitHub Issus이다.
GitHub Project의 kanban 스타일을 통해 팀 구성원들이 현재 진행하고 있는 작업과 완료한 작업들을 한 눈에 파악할 수 있었다.
개발해야 할 기능이나 해야 할 작업들을 Issue로 등록하였다. 프로젝트 기간동안 총 122개의 Issue가 등록되었다.
유저 스토리와 MosCow
애자일 프로세스는 사람이 중심으로 이루어진다. “서울특별시 폐수거함 위치 정보 제공 서비스”을 이용하는 사용자들의 행위의 관점에서 유저스토리를 추출하고 이에 대한 요구사항 목록을 작성해보았다.
유저 스토리를 쓰는 이유는 다음과 같다.
- 고객/사용자의 니즈를 중심으로 서비스를 만들기 위함
- 미처 생각하지 못했던 부분들이 눈에 들어오면서 더 많은 정리가 가능함
- 효율적인 의사소통
우리 팀이 유저 스토리를 기술한 방법은 일반적인 유저 스토리 기술 방식이다.
기술 방법: [고객/사용자]는 [목적/목표]를 위해 [필요/욕구]를 원한다.
예시: 사용자는 ID와 PW를 통해 로그인하여 서비스를 이용할 수 있다.
위와 같이 유저 스토리를 작성한 후 스토리의 중요도와 우선 순위를 확인할 수 있도록 MosCow 방법론을 이용하였다.
- Must Have: 이번 프로젝트에서 반드시 여기까진 다 해야한다.
- Should Have: 혹시라도 여력이 된다면 여기까지도 한번 해보자.
- Could Have: 여기까지 할 수 있다면 정말 좋겠지만, 못해도 괜찮다.
- Won’t Have: 이건 이번 프로젝트에 할 수 있는게 아니니 괜히 미련 갖지 말자.
프로그래밍 측면
- 코드 리뷰
- CI/CD
- 단위 테스트
코드 리뷰
우리 팀은 백엔드 2명과 프론트엔드 2명으로 이루어져 있다. 한 프로젝트를 여러 사람이 개발할 때 코드의 안정성은 굉장히 중요하다. 코드 리뷰를 적극 도입하여 코드 변경 사항을 보면서 문제점이나 개선점 등을 논의하였다. 그 결과, 다른 사람이 작성한 코드라도 문제점을 발견하면 자발적으로 고치고 같이 책임질 수 있었고 더 좋은 구조에 대해서 생각해볼 수 있었다.
CI/CD
지속적 통합과 지속적 전달 및 배포의 전 과정은 애자일 프로세스와 밀접한 관련이 있다. 프로세스에서 가능한 한 많은 과정을 자동화함으로써 빠른 피드백을 제공하여 사용자에게 서비스를 릴리스하는 데 걸리는 시간을 줄이는 것을 목표로 하였다. 또한 기능을 작은 단위로 나누어서 “일찍, 자주 커밋”하는 방식으로 작업을 진행하였다.
CI/CD 구축하는 데에 사용한 툴은 GitHub Actions와 AWS S3, CodeDeploy이며, 내가 맡은 부분은 CI 구축이였다.
단위 테스트
유저 스토리를 바탕으로 BDD를 도입하여 단위 테스트를 작성하였다. 각 기능이 제대로 동작하는지를 보장하는 코드를 작성하고 리팩토링이나 기능 추가 등으로 인해서 기존 기능이 갑자기 동작하지 않은 상황을 방지하기 위해 단위 테스트를 충실하게 작성하였다.
백엔드에서 단위 테스트를 작성한 예시는 다음과 같다.
모델링과 유스케이스
우리 팀은 서울 시민들의 불편함과 문제점을 해결하기 위해 다양한 방법을 통해서 문제와 요구사항을 분석하였다. 실질적인 개발 혹은 구현에 앞서서 해결책을 잘 이해하기 위해서 소프트웨어공학 수업에서 배운 모델링 기법을 도입하였다.
먼저 엑터(actor)을 정의하였다. 엑터란 시스템 외부에 존재하며 시스템과 상호작용 하는 모든 것들을 나타내는데, 우리 서비스 시스템을 사용할 엑터는 3가지로 분류된다.
다음은 유스케이스 다이어그램을 정의하였다. 시스템에서 제공해야하는 기능이나 서비스를 명세하는 단계로 사용자와 시스템 사이의 상호작용을 보여주었다.
시스템이 어떤 기능을 제공하는지를 표현하는 것으로 타원형으로 표시하며 단순하고 명료하게 기술해주었다.
“예비 수거함 투표” 기능은 “폐수거함 위치 제보” 기능에서 새롭게 만들어지기 때문에 화살표를 점선으로 연결하고 <>로 표기하였다. “폐수거함 상세 조회” 기능은 사용자가 폐수거함 종류를 선택하는 경우에만 실행되기 때문에 “폐수거함 지도 조회” 방향으로 화살표를 점선으로 연결한 후 <>로 표기하였다.
3가지 종류의 엑터가 해당 유스케이스의 목적을 달성하기 위해서 시스템과 상호작용 하는 과정을 유스케이스 시나리오를 통해 구체적으로 묘사하였다.
이에 대한 한 가지 예시는 다음과 같다.
느낀점
이 글을 쓰는 시점은 개발이 모두 완료된 상태이고 캡스톤 프로젝트가 마무리된 상태이다.
사회 문제를 파악하여 주제 선정을 하고 유저 스토리와 MosCow를 통해 시스템의 기능 설명을 사용자 관점에서 정의하고 우선순위를 정하여 개발을 하였다. GitHub Projects와 Issue 그리고 스프린트, CI/CD를 적절히 활용하면서 지도 교수님과 다른 수강생들의 빠른 피드백을 적극적으로 반영하며 유동적으로 개발을 진행하였다.
결과적으로 프로젝트에 반드시 필요한 기능을 모두 구현하였고 만족스러운 완성을 하였지만, 애자일과 소프트웨어공학론 적용을 추진한 사람으로서 아쉬운 점은 많이 남아있었다.
첫 번째로 애자일 준비과 모델링에 많은 시간이 소요되었다. 스프린트 플래닝에서 모든 이슈들에 대해 모든 팀원들이 의견을 조율하고 합의를 거치는 과정이 생각보다 시간이 오래 걸렸고 여러 스프린트를 거치면서 지속적으로 일정한 시간이 소모되었다. 두 번째로 현실과 동떨어진 해결책이다. 유저 스토리와 스프린트 기간들을 예측하더라도 막상 작업을 하다보면 다여러 원인으로 예측과 빗나가는 경우가 있었다. 애자일에서 이런 문제점은 회고를 통해서 고쳐나가는데, 매번 “다음 번에 더 잘하면 되지” 와 같은 피드백이 전부였다.
많은 기업에서 애자일을 쓰고 있다 고 주장하지만, 흐지부지되는 경우도 빈번하게 일어날 수 있을 것 같다고 생각했다. 왜냐하면 애자일이라는 것이 이상적인 경우에 한해서만 높은 효율을 달성할 수 있기 때문이다. 아무리 팀에서 철저하게 애자일을 준비하고 잘 따른다고 하더라도 외부의 영향에 따라 효율이 반감될 수도 있기 때문에 충분히 고려하여 도입을 결정하는 것이 좋다고 생각한다.
나는 애자일스러운 개발과 소프트웨어공학론에서 배운 전공 지식들을 활용하면서 팀 프로젝트에 대한 개인의 태도가 바뀌었다. 단순히 프로젝트의 효율성만을 생각하였는데, 팀 구성원 간의 소통과 존중을 중시하는 더 깊은 측면에서 접근하도록 노력해야겠다는 계기가 되었다.
