그럼에도 불구하고

들어가며

Github은 Git Remote Repository로 사용하는데 아주 대중적인 웹사이트다. Github에는 프로젝트 관리를 위한 다양한 기능을 가지고 있어서 이번 포스트에는 이를 우리 프로젝트에서 활용한 방법에 대해서 간략하게 소개하겠다. 

1. 선택이유

지난 포스트에서도 말했듯, PM(Project Management)를 위한 툴은 여러가지가 있다. 그러나 용도에 따라 서로 분산된 툴을 사용해야 하고 이를 연동하는 과정이 가벼운 프로젝트를 시작하는 사람들에게는 오히려 짐이 된다. 그런데 Github Repository에는 Issue, Milestone, Actions, Project, Wiki 등 다양한 프로젝트 관리 도구가 한 곳에 존재하기 때문에 따로 설정할 필요가 없어 편의성이 좋다. 물론, 더 복잡하고 큰 프로젝트를 관리하기 위해서는 부족한 기능이 몇 가지 있다. 하지만, 5명 정도의 팀원이 운영하기에는 충분한 기능을 제공하였기에 Github의 PM 기능을 선택하게 되었다.

2. 새로운 프로젝트 생성하기

새로운 Repository를 만들고 Github Project 기능에 들어간 후, 새로운 프로젝트 생성 버튼을 클릭하면 아래와 같은 창이 나온다. 

여기서 프로젝트에 관한 설명을 기록할 수 있고 Project Template를 정할 수 있는데 이 부분이 중요하다.

프로젝트는 기본적으로 칸반 형식을 제공하는데, Automated kanban을 사용하게 되면 프로젝트에 포함된 이슈를 닫거나, PR을 merge하게 되는 경우 자동으로 칸반의 상태를 변경한다. 예를 들어서, "버그 수정하기" 이슈를 프로젝트에서 TODO 상태로 정한 후, 버그 수정이 완료되어 이슈를 Close하면 자동으로 Done 상태로 이동 된다. 이러한 기능덕에 우리 프로젝트에서는 Automated kanban을 선택하여 지금까지 관리하고 있다.

프로젝트를 생성할 때는 Description에 해야할 내용을 간략하게 작성하여, 이 프로젝트에서 해야할 일을 정의한다. 아래의 경우, 3주차 스프린트에서 프론트엔드와 벡엔드에서 진행해야할 내용을 간단하게 서술한 예시이다.

프로젝트를 생성하고 들어가면, 처음에는 아래와 같이 Todo, In progress, Done 세 가지 형식의 Colum이 자동으로 생성될 것이다. 여기서 팀원들이 어떤 이슈를 해결중인지 파악할 수 있어 프로젝트 진행과정을 공유하기에 용이하다. 간혹, 이슈 상태를 업데이트 하지 않은 경우가 있는데, 이러면 이슈가 해결되었는지 파악할 수 없어 개발과정이 지체되는 경우가 있었으니 주의해야 한다.

여기에서 바로 이슈를 생성할 수도 있고, 이슈에서 연관된 프로젝트를 설정할 수도 있다. 아래 사진에서 우측 하단을 보면 프로젝트를 설정할 수 있는 것을 볼 수 있다.

또한 Pull Request에서 프로젝트와 관련있는 이슈를 연결했을 때, 프로젝트 보드에서 이슈와 Pull Request를 자동으로 묶어 보여주기 때문에 PR의 상태까지 한번에 확인 할 수 있다.

마치며

이 글을 쓰면서 이슈와 PR 활용법에 대해서도 적어야겠다는 생각이 들어, 조만간 작성할 예정이다. 왜냐하면 커밋 코드를 리뷰하거나, 링크를 통해서 간단하게 참조하는 법 등, 유용한 기능들이 아직 많이 남아있기 때문이다. 만약 본인이 팀원들과 새로운 프로젝트를 시작하는데 Jira, Confluence같은 툴을 사용하는데 어려움을 느낀다면 Github Project를 사용해보는 것을 적극적으로 권장한다.

들어가며

지난 포스트에는 개발방법론과 이를 실현하기 위한 툴들에 대한 내용을 작성하였다. 이번에는 새로운 프로젝트에서 문제를 정의한 과정에 대해서 알아보도록 하겠다.

1. 시작

교수님께서 소개해주신 스타트업 대표님과 개발팀장님께 자문을 받았을 때 가장 인상깊었던 말씀은 클라이언트, 팀원들 간의 생각 차이를 줄이는게 가장 중요하다는 것이었다. 자세히 말하면 같은 내용을 얘기하고 있어도 미묘하게 비즈니스 로직이나 유저 스토리에 대한 이해에 차이가 발생할수 있으며 이를 바로잡지 않으면 나중에 개발을 진행할 때 문제 정의로 회귀하여 다시 개발을 진행할 수도 있는 나비효과가 발생한다는 것이었다. 따라서 이번 프로젝트에서는 생각 차이를 줄이는데 집중하여 아래와 같이 3가지 문제정의 방법을 사용하고 검증했다.

2. User Story

가장 처음에는 영상의학과 교수님들과 대학원생 분들과의 미팅에서 구현되었으면 하는 요구사항을 정리하고자 User Story를 아래와 같이 작성했다.

각자의 User Story에는 개발 시 구현 방안을 간단하게 노트로 작성했고 구체적인 내용을 테스크로 정의하고 내부 페이지에 작성하였다.

3. 디자인

이 후에는 User Story를 바탕으로 디자인 초안을 작성했다. 이를 작성할 때는 Figma를 선택했는데, 그 이유는 Kakao oven, Sketch 등과 달리 Google에서 사용하는 다양한 Material UI Component를 무료로 이용할 수 있었기 때문이다. 그리고 Material UI Component를 사용한 이유는 향후 프론트 프레임워크를 React를 사용할 예정이었는데 React MUI 라이브러리에 이미 Material UI를 준수하는 Component들이 만들어져 있어 디자인보다 로직에 집중 할 수 있었기 때문이다. (실제로 1.0.0 버전의 프론트 코드에는 CSS와 관련된 코드가 거의 작성하지 않아 로직에 집중된 코드를 작성할 수 있었다.)

또한 디자인을 통해서 다시 클라이언트와 소통할 때, 잘못 이해한 User Story를 바로잡을 수 있었고 개발 방향을 다시 점검 할 수 있었다.

4. 비즈니스 로직

본인은 이 부분이 문제정의에서 가장 중요한 부분이라고 생각한다. 왜냐하면 개발 코드를 작성하는데 직접적으로 연관이 있기 때문이다. 유즈케이스 다이어그램과 비슷하게 비즈니스 로직을 UML로 구성하였는데 이 부분에서 효율적인 개발을 위한 토론이 가능했고 또 역할 할당이나 협업 방식등을 정리하기에도 수월했다. 그리고 디자인에서도 점검한 유저 스토리에 대한 논리적인 오류를 발견하여 개발전 빠른 조치까지 가능했다. (나중에 개발을 할 때, 이 부분은 무슨일이 있어도 작성해야겠다고 다짐했다.) 또한 한눈에 프로그램의 동작과정을 파악 할 수 있었기 때문에 개발 팀원들간의 생각 차이를 줄이는데도 한몫했다.

UML형태로 작성한 비즈니스 로직의 또 다른 장점은 확장성이다. 애자일 형식으로 개발할 때는 스프린트 형태로 주마다 새로운 기능을 추가하는 형태로 개발했는데, 이 때 UML 컴포넌트를 기존의 비즈니스 로직에 추가하여 쉽게 확장 내용을 기술 할 수 있었으며 다시 논리적인 오류를 검증하여 기존 기능과의 병합을 안정적으로 진행할 수 있었다.

5. 후기

유저 스토리, 디자인 그리고 비즈니스로직을 작성하면서 클라이언트의 요구를 점검하는 과정들을 통해 실제 프로젝트를 개발하는데 오류를 줄이고 개발방향을 확고히 함으로써 코드 재작성이나 수정 과정을 대폭 줄이는 효과를 얻을 수 있었다. 그러나 이런 과정도 완벽하지는 못하다. 중간까지의 개발과정에서 클라이언트의 요청이 아예 변경될 수도 있기 때문이다. 실제로 그런 경우가 있었고 이미 작성한 기능을 삭제하거나 수정해야 했다. 앞으로는 이런 상황에도 대비하기 위한 문제정의 방법을 계속 공부하거나 개발해야 할 것 같다. 

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 후기

내가 느낀 애자일을 한 단어로 말하자면 "분할 정복"이라고 생각한다. 작은 계획이 모여 결과를 만들어 내는 과정이 알고리즘의 분할 정복과 비슷한 느낌이었기 때문이다(엄밀히 말하면 다르지만). 사실 아직도 애자일을 제대로 알고 있는지는 모르겠다. 그러나 워터폴 방식에 비해서 확실히 좋았던 점이 많았던 것 같고 새로운 개발방법론을 적용하면서 많을 공부가 되었다. 지금 느끼는 거지만 모듈화와 함수형 프로그래밍 방식을 적용했다면 더욱 효율적이지 않았을까 생각이 자주 든다(이와 관련된 포스트는 따로 작성예정). 또한 이와 관련된 툴은 생각보다 엄청 많으며 자신의 프로젝트에 어떤 것이 적합한지 판단하는 능력이 중요하다고 생각했다. 무턱대고 기능이 더 많고 좋아보이는 툴이 자신의 프로젝트에 비해 오버 스펙인 경우가 있을 수 있기 때문이다. 그러나 프로젝트를 진행하면서 복잡성이 증가하고 이에 따라 새로운 기능이 필요하다면 열린 마음으로 새로운 툴을 선택할 수 있어야 한다고 생각한다.