May 24, 2023
예전에 개인 프로젝트를 할 때는 그냥 깃허브 하나 뚫고 대충 올리면서 했었다.
근데 그렇게 하면 추후 프로젝트 관리 시 문제가 생겼다.
그리고 프로젝트의 목적이나 버전 스토리 등도 뭉게지고 이력도 확인하기 어렵다.
그래서 이런 것을 막기 위해서는 프로젝트 문서화 및 체계를 잡고 하는게 중요하다고 생각한다.
좋은 코드를 작성하고, 빠르게 결과물을 내는 것도 중요하지만 이런 체계를 어느정도 잡고 가는 것도 중요하다 생각하는 1인이다.
그래서 내가 개인적으로 개발했던 MyMeLink나 흑우집합소는 어느정도 관리를 하면서 진행했다.
이번 TIL에는 내가 개인 프로젝트를 어떻게 관리하고 개발하는지를 포스팅으로 남겨보려 한다.
PS : 이건 정답은 아니며, 각자 처한 환경, 프로젝트에 따라 알맞게 하면 된다.
이거 안쓰는 사람도 있지만…
난 초창기부터 아주 잘 쓰고 있다.
무튼 이 노션으로 어떻게 쓰냐?
메인 페이지는 위와 같다.
로드맵, 버전 구현 노트, 기능 보고서, 개발일지 등이 있다.
이렇게 프로젝트를 진행하기 전, 진행하면서, 진행 이후 시점에 대한 각 문서들이 있다.
뭐 이게 정답은 아니지만 개인 프로젝트도 이런 체계와 시스템을 갖추고 진행하면 추후 관리면에서 용이하다.
이런건 내가 삼성전자에 있을 때 따로 배운건 아닌데 하다보니 그쪽 시스템과 나만의 시스템을 결합해서 체계를 만들었다.
각 항목에 대해 간단히 소개해본다.
일종의 전체 개발일정?
이 프로젝트의 최종 목표, 각종 버전 진행 내역, 버전 보고서 이슈 및 리포트 등을 관리한다.
내 흑우집합소의 경우 최종 목표는 저렇다.
정말 많다 -_-;;
뭐 하나씩 완성해가면 할 수는 있는 것들이다.
최종 목표가 있어야 프로젝트가 산으로 가지 않고 정해진 목적지를 향해 잘 갈수 있다.
그리고 저 항목들 안에는 엄청 디테일 하지는 않지만 어느정도 세부 사항을 정해서 둔다.
그리고 저기 버전별 보고서는 다음에 소개할 버전 구현 노트쪽으로 들어갔다.
아무래도 로드맵은 오버뷰 성향으로 된 것이라서 복잡하면 안되고 간단하면서도, 목적을 제공하는 페이지에서 끝을 냈다.
여기는 프로젝트 버전별 노트다.
여기는 개발 버전에 따른 정리 문서다.
흑우집합소의 경우 아래와 같은 버전 규칙이 있다.
X.Y.Z
X : 대규모 업데이트 및 전환점에 사용하는 버전 코드
Y : 중간 규모의 업데이트에 사용하는 버전 코드
Z : 작은 규모의 업데이트에 사용하는 버전 코드
뭐 예전에 어디서 본게 있어서 대충 나한테 맞게 정했다.
보통 Z 버전의 경우 1~2주 정도 소요를 맞춰서 진행했다.
X, Y의 경우 크게 잡는다기 보다는 Z 버전 일정 안에 녹여서 진행했다.
주요 목표는 해당 버전에 대한 가시적 주요 목표다.
뭔가 버그가 있거나, 목표한 기능이 들어간다.
Issue 현황의 경우 깃허브에 등록된 이슈와 함께 물고 들어간다.
이 부분은 아래 Github에서 다시 소개하겠다.
그냥 현재 내가 어떤 이슈를 할당받고, 진행하며, 처리했는지를 나타낸다.
근데 개인 프로젝트라 셀프 이슈할당, 진행, 완료를 한다 -_-;;
업무 진행 내역은 하루에 뭐 했는지를 쓰는 부분이다.
이거는 일종의 자기관리용?
이거 안하면 내가 언제 이걸 했는지 망각하거나 루즈하게 갈 수 있다.
보고서는 버전 배포 이후 사후 관리용이다.
일종의 회고같은?
이번 버전을 진행하며 주요 목표 달성내역, 그리고 추가적으로 진행한 오버런 내역을 작성한다.
처리한 이슈는 위에 테이블에서 하는거랑 같은 기능이라 지금은 안쓴다.
그리고 학습하며 배운점 및 기타는 개발하며 배우거나 알게 된 내용을 정리하는 공간이다.
일단 링크나 간단한 코드 등을 모아두고, 시간이 될 때(?) 이렇게 블로그로 정리해둔다.
사실 아직도 정리 못한 내용이 많…다.
굵직하거나 주요 기능에 대한 보고서다.
이걸 왜 만들었냐 하면 기능에 대한 정의 및 구현 내역의 히스토리가 필요할 것 같아서 넣었다.
대략 이런 식이다.
근데 이 기능 보고서는 여기에 두고 다른 페이지에 만들었다.
거기가 초창기 버전 문서다.
저기 안에 기능 보고서를 대충 뼈대만 만들어둔 게 있는게 그걸 하나씩 옮겨야 한다.
근데 이것도 일이라서… 조만간 노션 정리를 할 때 다 옮겨야 겠다.
이거는 원래 TIL 용으로 썼는데 이거는 버전 노트에서 들어간 내용이라 현재는 deprecated된 상태…
사실 개발하며 배우는 부분이 갈 수록 늘어나는 것 같아서 일일히 정리하려 했지만…
이걸 하면서 개발을 하면 속도가 너무 느려져서 일단 대단원 잡고 해당 내용에 대한 간단 코멘트와 링크를 남기는 형태로 가게 되었다.
대략 이런 느낌?
그래서 추후 기능 개발을 할 때 참고하거나, 구현 후 개발 블로그에 정리할 때 참고하는 식으로 사용한다.
다음은 Github 활용에 대해 소개해본다.
뭐 따로 깃허브에 대해 설명은 하지 않겠다.
아무래도 개인 프로젝트이고, 추후 상용화 또는 개인 자산이기에 Private Repo로 지정하고 작업을 한다.
전에는 Yona를 사용했는데 깃헙이 개인 레포를 무료로 풀어서 이리로 옮겼다.
지금도 집에 Yona를 돌리던 nas에는 내 iOS 프로젝트들이 있어서 가끔 추억 회상용(?)으로 본다. -_-;;
무튼 다시 돌아와서…
깃헙에서 내가 주로 쓰는건 몇 개 안된다.
그중 중요한 것은 브런치 전략이랑 이슈관리 및 풀 리퀘스트(PR), 그리고 마일스톤정도가 있다.
매우 중요한 전략이다.
브런치를 어떻게 관리하느냐에 따라 코드에 문제가 생겼을 때 이력 추적을 하기 쉽거나 어려워진다.
이 브런치 전략은 사람마다, 그리고 프로젝트 성향마다 달라진다.
내 경우 아래와 같은 원칙을 세우고 브런치 전략을 수립했다.
메인 브런치
운영 브런치
이슈 브런치
핫픽스 브런치
배포 통합용 브런치
뭔가 복잡해 보이는데 사실 해보면 별거 없다.
그냥 용도에 맞게끔 맞춰서 하는게 끝이다.
더 나은 전략도 있겠지만, 소규모 프로젝트에서는 이게 제일 좋은 방법인 것 같다.(주관적 의견)
뭐 정말 작은 프로젝트고 하면 그냥 원 브런치 전략으로 가도 된다.
하지만 나의 경우 백엔드 레포와 프론트 레포를 나눠 쓰며, 각 기능들이나 이슈들도 상당히 세분화 해서 사용한다.
그래서 이게 나에게 있어서 최선의 브런치 전략인 것 같다.
이슈는 깃허브에서 이슈 또는 다양한 용도로 사용할 수 있는 기능이다.
여기선 이것에 대해 자세히 다루는 것 보단 내가 어떤 식으로 사용하는지 설명한다.
이건 프론트 쪽 이슈다.
보면 Feature, CR등 다양한 접두사들이 붙어있고, 라벨도 있다.
한참 예전에 등록한 이슈들도 있고…-_-;;
위에서 살짝 언급했지만 기능 덩어리를 하나의 이슈로 등록한다.
너무 큰 기능의 경우 또 세부적으로 나눠서 이슈 등록 후 구현한다.
난 Labels를 나의 프로젝트에 맞게끔 바꿨다.
원래 더 나눌까 하다가 관리도 어렵고 개인 프로젝트인데 더 빡세게 할 필요도 없어서 대충 저 정도로 나눴다.
Bug
Code-Refactoring
Feature
Hotfix
Sub-Feature
release
Pull-Request
이렇게 라벨과 이슈를 묶어서 사용하면 구분하기도 편하고, 이 이슈가 하나의 기능 리포트,
또는 버그 해결을 처리한 리포트 문서가 될 수도 있다.
물론 오픈 소스를 개발할 경우 이런 라벨링은 좋은 형태는 아니다.
하지만 개인 프로젝트나 소규모 프로젝트를 할 때 기본 뼈대로 사용하기엔 좋은 것 같다.
Pull-Request의 경우 브런치 전략에서 언급한 바와 같이 메인 브런치를 기준으로 PR을 한다.
그리고 운영 배포를 할 경우 Release 태그를 붙여서 함께 사용한다.
대충 PR은 이런 형태를 띄게 된다.
이정표인데 노션의 버전 노트랑 성향이 비슷하다.
그래서 나는 대충 적었다. -_-;;
원래는 노션 노트와 동기화 해야 하지만…
깃허브 정리도 한번 해야 할 듯 싶다.
이 마일스톤을 통해서 이슈를 언제까지 어느 버전에서 처리할 것인지를 관리할 수 있다.
만약 노션을 안쓰게 되면 이 마일스톤을 잘 활용하면 될 듯 싶다.
지금까지 내가 쓰는 개인 프로젝트 관리 방법을 공유해봤다.
사실 나도 계속 바꾸고 적용해본다.
이 방법은 1인보다는 2~5인 사이의 규모에서 쓰기 좋은 것 같다.
하지만 내가 이렇게 하는 이유는 조만간 다시 직장을 구하게 되면(?) 이런 협업 시스템이나,
체계화 된 시스템을 몸에 계속 익혀 두는게 좋을 것 같아서 그렇다.
뭐 성격상 저렇게 하는 것을 좋아하는 것도 있고…
일단 지금은 1인 개발인데 혼자 하게 되면 코드 팔로우나 이슈 트래킹이 생각보다 어렵다.
지금 하는 흑우집합소의 규모가 아주 조금 큰 것도 있고,
사람은 항상 기록을 해야 추후에 쫒기 편하다.
혹시 이런 것에 대해 고민하고 방법을 아직 못 찾은 분이라면 이런 방법도 있구나 라고 보면 좋을 것 같다.
물론 이것보다 더 나은 방법을 쓰는 분들도 많을 것이다.
그런 분들 중에 혹시 보완할게 보인다면 댓글로 글을 남겨주시면 감사하겠다.
너무 오랜만에 블로그 포스팅을 안하다 글을 쓰려니 좀 더뎌졌다.
앞으로는 좀 부지런하게 글을 써봐야 할 듯 싶다.