1. 들어가며
최근 들어서 연구실에서 새로운 프로젝트를 시작하여 블로그 글을 작성하는게 뜸해졌다. 생각한 기능을 구현하고자 바쁘게 움직이면서 무의식적으로 글을 작성하는 과정을 미뤄왔던 것 같다. 프로젝트가 어느정도 기능이 구현되어 할 일이 줄어들어 지금까지 있었던 여러 고난과 극복과정을 앓음다운 글로 작성해보면서 그 동안의 팀 리더로서의 경험을 정리하고자 한다. 아직 많이 미숙하지만 이 글이 새로운 프로젝트를 시작하려는 모든 이에게 도움이 되었으면 좋겠다.
2. 새로운 프로젝트
새로운 프로젝트의 이름은 DSMP(Dicom Service Mangement Project)로 Dicom이라는 의료용 디지털 영상 데이터를 관리한다는 의미를 가지고 있다. 의료영상을 베이스로 머신러닝을 연구하는 연구실이다 보니 의료 영상을 관리하는 작업이 필요했다. 이 과정에서 환자 개인정보를 지우는 익명화 작업, 서로 다른 병원에서 얻은 Dicom의 PatientID가 중복되는 문제 식별 및 수정 등의 여러 작업과 문제가 있었다. 반복적인 작업과 문제를 해결하기 위해서 시스템이 필요하게 되었는데 이를 위해 개발하기로 한 것이 DSMP이다.
3. 개발 방법론
3.1 실패
지금까지 진행했던 프로젝트는 워터폴 방식으로 진행했었다. 이 방법은 공모전이나 단기 프로젝트 같은 방식에는 별로 문제가 발생하지 않았었지만, 실제로 고객 요구사항에 맞춰 개발할 때는 엄청난 독이 되었었다. 예를 들어, 스타트업 외주를 담당하게 된 적이 있었는데, 매 주 회의를 할 때마다 저번주에 정한 요구사항이 변경되는 경우가 다반사였다. 그러다 보니 개발을 시작하려고 하면 다시 요구사항 정의로 돌아가기를 반복하기 일수였기에 굉장히 스트레스를 많이 받은 적이 있었다.
3.2 도전
따라서 이번 프로젝트 또한 그런 상황을 방지하고자 애자일 개발 방법론을 공부하고 선택했다. 국내, 국외의 여러 포스트들을 검색하고 읽으며 학교 도서관에서 PM에 도움이 될만한 책들을 여러 권 읽어가며 실패하지 않는 개발 방법론을 실천하겠다고 다짐했다. 애자일에 대해서 알고 싶은 사람들에겐 로버트.C.마틴의 클린 애자일을 추천한다. 장 수는 별로 없는 것에 반해 굉장히 인상 깊게 읽었었다. 또한 이 과정에서 교수님이 스타트업 대표님과 개발 팀장님을 소개시켜주셨는데 굉장히 현실적인 조언들을 많이 해주셔서 배운점이 많았다.
3.3 구현
공부를 통해서 스프린트, 에픽, 테스크 등 개념에 대해서 공부하고 PM과 Wiki를 구축하기 위한 툴을 선택했는데 맨 처음에는 Jira와 Confluence를 선택했다. 그러나 결국 Github Project와 Notion으로 대체 했는데 그 이유는 아래와 같다.
1. 편의성 vs 기능성
Jira의 경우 Confluence와 Github Repository와의 연결 기능을 제공하고 있고 로드맵이나 애자일 보드 등 유용한 기능들이 많아 잘 사용한다면 개발을 빠르고 유연하게 진행할 수 있을 것 같았다.
그러나 처음 팀원들에게 이를 알려주었을 때, 기능을 사용하는게 굉장히 복잡하다는 피드백을 받았다. 나는 처음 사용하기에 그럴 수 있다고 생각했지만, 다시 곰곰히 생각해보니 5명 단위의 프로젝트였기 때문에 사실 복잡한 기능들을 모두 사용할 필요가 없다고 느꼇다. 따라서 Issue Tracking, Automated Kanban 등 기본적인 기능을 제공하며 편의성이 Jira에 비해서 높은 Github Project를 사용하게 되었다.
2. 불필요한 Description
개발을 진행하면서 결국 Github Issue를 사용했는데, 이슈에도 Description을 작성하고 이와 관련된 Jira 테스크에도 같은 Descriptiondn을 작성하는 경우가 다반사였다. 처음에는 Jira 테스크에 내용을 기술하고 링크를 Github Issue에 추가했으나 뭔가 잘못된것 같은 느낌이었다. 결국 과감히 Jira 사용을 포기함으로서 Desciption을 한 곳에만 집중하여 기술할 수 있어 오기입을 줄이고 편의성을 높일 수 있었다.
3. Commit Tracking
Github에서는 커밋을 작성할 때, 이슈 태그를 기술하면 이슈에 해당 커밋 내용이 자동으로 추가되고 만약 또 다른 커밋을 언급했다면 자동으로 링크가 형성되는데 이 기능이 팀원과 소통하는데 굉장히 도움이 많이 되었다. 물론 Jira에도 이와 비슷한 기능이 있지만, 이를 설정하고 이용하는데 Github에 비해서 번거롭기 때문에 Github에서 사용하는것 이 도움이 많이 되었다.
3.4 후기
내가 느낀 애자일을 한 단어로 말하자면 "분할 정복"이라고 생각한다. 작은 계획이 모여 결과를 만들어 내는 과정이 알고리즘의 분할 정복과 비슷한 느낌이었기 때문이다(엄밀히 말하면 다르지만). 사실 아직도 애자일을 제대로 알고 있는지는 모르겠다. 그러나 워터폴 방식에 비해서 확실히 좋았던 점이 많았던 것 같고 새로운 개발방법론을 적용하면서 많을 공부가 되었다. 지금 느끼는 거지만 모듈화와 함수형 프로그래밍 방식을 적용했다면 더욱 효율적이지 않았을까 생각이 자주 든다(이와 관련된 포스트는 따로 작성예정). 또한 이와 관련된 툴은 생각보다 엄청 많으며 자신의 프로젝트에 어떤 것이 적합한지 판단하는 능력이 중요하다고 생각했다. 무턱대고 기능이 더 많고 좋아보이는 툴이 자신의 프로젝트에 비해 오버 스펙인 경우가 있을 수 있기 때문이다. 그러나 프로젝트를 진행하면서 복잡성이 증가하고 이에 따라 새로운 기능이 필요하다면 열린 마음으로 새로운 툴을 선택할 수 있어야 한다고 생각한다.
'Computer Science > Project Management' 카테고리의 다른 글
| 복잡한 정책을 고려한 코드 작성법 (0) | 2024.12.23 |
|---|---|
| 새로운 프로젝트에 관하여 - 3. Github Project 활용법 (0) | 2022.02.10 |
| 새로운 프로젝트에 관하여 - 2. 문제 정의 (0) | 2022.02.01 |