개인 프로젝트 관리에 관하여...

예전에 개인 프로젝트를 할 때는 그냥 깃허브 하나 뚫고 대충 올리면서 했었다.
근데 그렇게 하면 추후 프로젝트 관리 시 문제가 생겼다.

그리고 프로젝트의 목적이나 버전 스토리 등도 뭉게지고 이력도 확인하기 어렵다.

그래서 이런 것을 막기 위해서는 프로젝트 문서화 및 체계를 잡고 하는게 중요하다고 생각한다.
좋은 코드를 작성하고, 빠르게 결과물을 내는 것도 중요하지만 이런 체계를 어느정도 잡고 가는 것도 중요하다 생각하는 1인이다.

그래서 내가 개인적으로 개발했던 MyMeLink나 흑우집합소는 어느정도 관리를 하면서 진행했다.
이번 TIL에는 내가 개인 프로젝트를 어떻게 관리하고 개발하는지를 포스팅으로 남겨보려 한다.

PS : 이건 정답은 아니며, 각자 처한 환경, 프로젝트에 따라 알맞게 하면 된다.

노션 (Notion)

이거 안쓰는 사람도 있지만...
난 초창기부터 아주 잘 쓰고 있다.

무튼 이 노션으로 어떻게 쓰냐?

메인 페이지는 위와 같다.

로드맵, 버전 구현 노트, 기능 보고서, 개발일지 등이 있다.
이렇게 프로젝트를 진행하기 전, 진행하면서, 진행 이후 시점에 대한 각 문서들이 있다.

뭐 이게 정답은 아니지만 개인 프로젝트도 이런 체계와 시스템을 갖추고 진행하면 추후 관리면에서 용이하다.
이런건 내가 삼성전자에 있을 때 따로 배운건 아닌데 하다보니 그쪽 시스템과 나만의 시스템을 결합해서 체계를 만들었다.

각 항목에 대해 간단히 소개해본다.

로드맵

일종의 전체 개발일정?
이 프로젝트의 최종 목표, 각종 버전 진행 내역, 버전 보고서 이슈 및 리포트 등을 관리한다.

내 흑우집합소의 경우 최종 목표는 저렇다.
정말 많다 -_-;;

뭐 하나씩 완성해가면 할 수는 있는 것들이다.
최종 목표가 있어야 프로젝트가 산으로 가지 않고 정해진 목적지를 향해 잘 갈수 있다.
그리고 저 항목들 안에는 엄청 디테일 하지는 않지만 어느정도 세부 사항을 정해서 둔다.

그리고 저기 버전별 보고서는 다음에 소개할 버전 구현 노트쪽으로 들어갔다.
아무래도 로드맵은 오버뷰 성향으로 된 것이라서 복잡하면 안되고 간단하면서도, 목적을 제공하는 페이지에서 끝을 냈다.

버전 구현 노트

여기는 프로젝트 버전별 노트다.

여기는 개발 버전에 따른 정리 문서다.
흑우집합소의 경우 아래와 같은 버전 규칙이 있다.

X.Y.Z

• X : 대규모 업데이트 및 전환점에 사용하는 버전 코드
  • 서비스 내 많은 변경이 있거나 UI 및 UX가 완전히 변할 때
• Y : 중간 규모의 업데이트에 사용하는 버전 코드
  • 신규 기능인데 새로운 형태의 기능이 추가되거나 할 때
• Z : 작은 규모의 업데이트에 사용하는 버전 코드
  • 자잘한 버그 및 핫픽스 처리
  • 신규 또는 기존 기능의 하위 기능이 추가되거나 변경될 때

뭐 예전에 어디서 본게 있어서 대충 나한테 맞게 정했다.
보통 Z 버전의 경우 1~2주 정도 소요를 맞춰서 진행했다.

X, Y의 경우 크게 잡는다기 보다는 Z 버전 일정 안에 녹여서 진행했다.

주요 목표는 해당 버전에 대한 가시적 주요 목표다.
뭔가 버그가 있거나, 목표한 기능이 들어간다.

Issue 현황의 경우 깃허브에 등록된 이슈와 함께 물고 들어간다.
이 부분은 아래 Github에서 다시 소개하겠다.
그냥 현재 내가 어떤 이슈를 할당받고, 진행하며, 처리했는지를 나타낸다.

근데 개인 프로젝트라 셀프 이슈할당, 진행, 완료를 한다 -_-;;

업무 진행 내역은 하루에 뭐 했는지를 쓰는 부분이다.
이거는 일종의 자기관리용?
이거 안하면 내가 언제 이걸 했는지 망각하거나 루즈하게 갈 수 있다.

보고서는 버전 배포 이후 사후 관리용이다.
일종의 회고같은?

이번 버전을 진행하며 주요 목표 달성내역, 그리고 추가적으로 진행한 오버런 내역을 작성한다.

처리한 이슈는 위에 테이블에서 하는거랑 같은 기능이라 지금은 안쓴다.
그리고 학습하며 배운점 및 기타는 개발하며 배우거나 알게 된 내용을 정리하는 공간이다.

일단 링크나 간단한 코드 등을 모아두고, 시간이 될 때(?) 이렇게 블로그로 정리해둔다.
사실 아직도 정리 못한 내용이 많....다.

기능 보고서

굵직하거나 주요 기능에 대한 보고서다.
이걸 왜 만들었냐 하면 기능에 대한 정의 및 구현 내역의 히스토리가 필요할 것 같아서 넣었다.

대략 이런 식이다.
근데 이 기능 보고서는 여기에 두고 다른 페이지에 만들었다.
거기가 초창기 버전 문서다.

저기 안에 기능 보고서를 대충 뼈대만 만들어둔 게 있는게 그걸 하나씩 옮겨야 한다.
근데 이것도 일이라서... 조만간 노션 정리를 할 때 다 옮겨야 겠다.

개발 일지

이거는 원래 TIL 용으로 썼는데 이거는 버전 노트에서 들어간 내용이라 현재는 deprecated된 상태...

사실 개발하며 배우는 부분이 갈 수록 늘어나는 것 같아서 일일히 정리하려 했지만...
이걸 하면서 개발을 하면 속도가 너무 느려져서 일단 대단원 잡고 해당 내용에 대한 간단 코멘트와 링크를 남기는 형태로 가게 되었다.

대략 이런 느낌?
그래서 추후 기능 개발을 할 때 참고하거나, 구현 후 개발 블로그에 정리할 때 참고하는 식으로 사용한다.

다음은 Github 활용에 대해 소개해본다.

Github

뭐 따로 깃허브에 대해 설명은 하지 않겠다.
아무래도 개인 프로젝트이고, 추후 상용화 또는 개인 자산이기에 Private Repo로 지정하고 작업을 한다.

전에는 Yona를 사용했는데 깃헙이 개인 레포를 무료로 풀어서 이리로 옮겼다.
지금도 집에 Yona를 돌리던 nas에는 내 iOS 프로젝트들이 있어서 가끔 추억 회상용(?)으로 본다. -_-;;

무튼 다시 돌아와서...
깃헙에서 내가 주로 쓰는건 몇 개 안된다.
그중 중요한 것은 브런치 전략이랑 이슈관리 및 풀 리퀘스트(PR), 그리고 마일스톤정도가 있다.

브런치 전략

매우 중요한 전략이다.
브런치를 어떻게 관리하느냐에 따라 코드에 문제가 생겼을 때 이력 추적을 하기 쉽거나 어려워진다.

이 브런치 전략은 사람마다, 그리고 프로젝트 성향마다 달라진다.
내 경우 아래와 같은 원칙을 세우고 브런치 전략을 수립했다.

• 메인 브런치
  • 통합용으로 현재 개발하여 최종적인 결과물이 유지되는 브런치다.
  • 개발용 및 테스트 용으로 쓰이며, 각 이슈 브런치들의 기준점이 되는 브런치

• 운영 브런치
  • 실제 운영을 하는 버전 브런치
  • 메인 브런치는 최신 브런치지만 기능이 빠지거나 만들어지는 단계라면, 운영 브런치는 스테이블 된 브런치다.
  • 이 브런치는 가급적 건들지 않고, 배포 시에만 pull을 땡겨오는 용도로 사용한다.
  • 보통은 직접 이곳으로 Pull Request를 하지 않는다. (단 핫픽스 제외)

• 이슈 브런치
  • 깃허브의 이슈를 등록하면, 그 이슈를 기반으로 만드는 브런치
  • 보통 이름은 그냥 issueXX 로 정한다.
  • 이슈는 아래에서 자세히 언급하겠지만, 너무 방대한 기능이 아닌 하나의 작은 기능이 하나의 이슈가 된다.

• 핫픽스 브런치
  • 배포 이후 급하게 처리를 해야 하는 이슈가 생길 때 사용한다.
  • 이 브런치도 이슈 브런치와 유사하지만, Pull Request를 두 곳에 진행한다. (메인, 운영)

• 배포 통합용 브런치
  • 이슈 브런치를 통합하여 메인 브런치가 운영용으로 배포할 때 사용하는 브런치
  • release_1.0.2 형태로 만들어진다.
  • 만약 나눠서 배포해야 한다면 1.0.2.1 이런식으로 하나의 필드가 추가된다.
  • 메인 브런치를 기준으로 하며, Pull Request를 운영 브런치에 하는 용도로 사용된다.

뭔가 복잡해 보이는데 사실 해보면 별거 없다.
그냥 용도에 맞게끔 맞춰서 하는게 끝이다.

더 나은 전략도 있겠지만, 소규모 프로젝트에서는 이게 제일 좋은 방법인 것 같다.(주관적 의견)
뭐 정말 작은 프로젝트고 하면 그냥 원 브런치 전략으로 가도 된다.

하지만 나의 경우 백엔드 레포와 프론트 레포를 나눠 쓰며, 각 기능들이나 이슈들도 상당히 세분화 해서 사용한다.
그래서 이게 나에게 있어서 최선의 브런치 전략인 것 같다.

이슈관리 및 풀 리퀘스트

이슈는 깃허브에서 이슈 또는 다양한 용도로 사용할 수 있는 기능이다.
여기선 이것에 대해 자세히 다루는 것 보단 내가 어떤 식으로 사용하는지 설명한다.

이건 프론트 쪽 이슈다.
보면 Feature, CR등 다양한 접두사들이 붙어있고, 라벨도 있다.

한참 예전에 등록한 이슈들도 있고...-_-;;
위에서 살짝 언급했지만 기능 덩어리를 하나의 이슈로 등록한다.

너무 큰 기능의 경우 또 세부적으로 나눠서 이슈 등록 후 구현한다.
난 Labels를 나의 프로젝트에 맞게끔 바꿨다.

원래 더 나눌까 하다가 관리도 어렵고 개인 프로젝트인데 더 빡세게 할 필요도 없어서 대충 저 정도로 나눴다.

• Bug
  • 문제점
  • 뭔가 버그가 제보되거나, 내가 찾은 경우 이 라벨을 붙여서 등록한다.
  • 정말 긴급 이슈는 Hotfix로 넘어가며, 같이 태깅 된다.

• Code-Refactoring
  • 기능 우선 개발을 하다보면 코드가 엉망이 되길 마련이다.
  • 또한 코드의 품질 개선 및 더 나은 방향으로 작성해야 할 때 사용하는 라벨이다.
  • 등록은 많이 하지만... 사실 시간 부족으로 우선 순위가 많이 밀리는 라벨이다.

• Feature
  • 하나의 기능을 담당한다.
  • 뭐 예를 들면 데이터를 가져와서 테이블에 뿌리는 작업을 의미한다.
  • 물론 더 큰 기능을 지칭하기도 하는데 세부적인 것은 Sub-Feature로 나눠서 하기도 한다.

• Hotfix
  • 긴급 패치용 브런치
  • 만약 배포를 하거나 버그를 찾았는데 매우 긴급한 경우 사용하는 라벨.
  • Bug 라벨과 함께 쓰일 수 있다.

• Sub-Feature
  • Feature에서 너무 큰 경우 이 라벨을 통해서 분리할 수 있다.
  • Feature랑 함께 사용한다.

• release
  • 메인 브런치에서 배포용 브런치를 딴 후 운영 브런치에 Pull-Request 할 때 사용하는 라벨

• Pull-Request
  • 일반적으로 PR시 사용하는 라벨

이렇게 라벨과 이슈를 묶어서 사용하면 구분하기도 편하고, 이 이슈가 하나의 기능 리포트,
또는 버그 해결을 처리한 리포트 문서가 될 수도 있다.

물론 오픈 소스를 개발할 경우 이런 라벨링은 좋은 형태는 아니다.
하지만 개인 프로젝트나 소규모 프로젝트를 할 때 기본 뼈대로 사용하기엔 좋은 것 같다.

Pull-Request의 경우 브런치 전략에서 언급한 바와 같이 메인 브런치를 기준으로 PR을 한다.
그리고 운영 배포를 할 경우 Release 태그를 붙여서 함께 사용한다.

대충 PR은 이런 형태를 띄게 된다.

마일스톤

이정표인데 노션의 버전 노트랑 성향이 비슷하다.

그래서 나는 대충 적었다. -_-;;
원래는 노션 노트와 동기화 해야 하지만...
깃허브 정리도 한번 해야 할 듯 싶다.

이 마일스톤을 통해서 이슈를 언제까지 어느 버전에서 처리할 것인지를 관리할 수 있다.
만약 노션을 안쓰게 되면 이 마일스톤을 잘 활용하면 될 듯 싶다.

정리

지금까지 내가 쓰는 개인 프로젝트 관리 방법을 공유해봤다.
사실 나도 계속 바꾸고 적용해본다.

이 방법은 1인보다는 2~5인 사이의 규모에서 쓰기 좋은 것 같다.
하지만 내가 이렇게 하는 이유는 조만간 다시 직장을 구하게 되면(?) 이런 협업 시스템이나,
체계화 된 시스템을 몸에 계속 익혀 두는게 좋을 것 같아서 그렇다.

뭐 성격상 저렇게 하는 것을 좋아하는 것도 있고...
일단 지금은 1인 개발인데 혼자 하게 되면 코드 팔로우나 이슈 트래킹이 생각보다 어렵다.

지금 하는 흑우집합소의 규모가 아주 조금 큰 것도 있고,
사람은 항상 기록을 해야 추후에 쫒기 편하다.

혹시 이런 것에 대해 고민하고 방법을 아직 못 찾은 분이라면 이런 방법도 있구나 라고 보면 좋을 것 같다.
물론 이것보다 더 나은 방법을 쓰는 분들도 많을 것이다.

그런 분들 중에 혹시 보완할게 보인다면 댓글로 글을 남겨주시면 감사하겠다.

너무 오랜만에 블로그 포스팅을 안하다 글을 쓰려니 좀 더뎌졌다.
앞으로는 좀 부지런하게 글을 써봐야 할 듯 싶다.