wisePocket

[Flask] Team Project(GameInsight) 03 전반적인 프로젝트 관리에 대한 회고, 아쉬운점 본문

Python&Flask Tutorials, AWS EB/Flask_Team_Project_GameInsight

[Flask] Team Project(GameInsight) 03 전반적인 프로젝트 관리에 대한 회고, 아쉬운점

ohnyong 2023. 8. 12. 11:51

프로젝트를 어제 종료했고, 아쉬운 부분도 많이 남아있다.

전날 밤새 오류와의 싸움때문에 잠을 못자서 오늘 아침부터 회고를 작성하고자 한다. 팀 프로젝트는 종료되었지만, 너무 아쉬운 부분이 많다. 더 하고 싶다. 이대로 보내주기가 싫다. 너무 기간이 짧았다. 하지만 다음 프로젝트에서 이 회고들을 참고하고 더욱 발전된 완성도 높은 프로젝트를 완료하고 싶다. 무조건 그래야 한다.

https://youtu.be/Szj9XZU_7gE

우선 내가 맡은 부분은 다음과 같이 요약 할 수 있다.

  • 전체적인 프로젝트의 아이디어 구체화, 서비스 기획
더보기
팀원과 회의를 통해 나온 아이디어로 부터 서비스 레퍼런스 탐색 및 기능 제안
일정 및 기초 컨벤션, 그라운드 룰 지정 및 공지
로드맵 작성은 생략했지만 간략화 시킨 일정에 대한 공지(짧은 기간이기에 시간여유 없음)
  • 프론트엔드 부분을 담당
더보기

HTML 표준 레이아웃 구성(Header-Nav-Content(Section-Aside)-Footer 형태)
부트스트랩 활용하여 시간 대비 빠르게 디자인 구성을 완성하고 기능 구현에 집중 할 수 있도록 유도

  • Github 원격 저장소를 이용한 형상 관리를 팀원에게 소개 및 형상 관리 마스터 역할
더보기
  • Git과 Github 에 대한 설정과 팀원들에게 지시한 과정은 다음과 같다.
    • 팀원들에게 기초적인 Git 지식이나 사용 방법을 인지하고 있는지 파악
    • 이해도를 확인하기 위하여 테스트용 원격 저장소를 생성, 로컬과 연결 시켜두었으며
    • 팀원들에게 테스트 원격 저장소에 "Push"해서 "Merge"요청하기를 지시
    • Pull-Request 생성과 Master를 관리하는 나와 Pull-Request 요청자 팀원과의 코드 리뷰 및 병합 후 테스트 확인
    • 실제 프로젝트 진행 할 로컬 Master 저장소 생성 및 원격 저장소 생성 및 연결 후
    • 기초 개발 환경 구축 버전 생성(초기 환경 설정, README, 기초 dependency 임포트 문 작성, 기초 flask 이니시부분 작성
    • 팀원 Collaborator 초대
    • 위 기초 배포 개발 환경 구축 버전을 팀원들에게 클론 및 Branch 생성 지시
    • 나 또한 Master 보호를 위하여 작업 Branch 생성
    • 이후 개인 기능 구현 위치 설명, 공통 부분에 대한 충돌 가능성에 대한 원인과 이유, 그리고 작업에서 유의해야 할 부분들을 공지
    • 개인 작업 시작
    • 개인 작업 완료 후 Commit Message 작성 요령(컨벤션) 통일의 필요성과 git log -oneline으로 보여지는 화면 설명
    • 기능 구현 완료 후 프로젝트 병합과 충돌 과정에 대한 코드 리뷰, 기타 로직에 대한 커뮤니케이션 진행, 병합 충돌 부분 해결
    • 1차 최종 버전 병합 후 AWS EB배포

아이디어 회의 시간 이후 곧바로 내가 먼저 꺼낸 이야기는 이것이다.

깃허브 사용해보신분? Push를 해보신분?
아니라면 부끄러워 하지 마시고 지금 빠르게 알려주세요. 바로 알려드릴게요.

특히 Git, Github 활용 과정은 협업에서 필수적이었기 때문에 참여를 하고 안하고를 떠나서 팀원들의 피드백이 필요했다. 백업용으로만 로컬에서만 사용해본 사람도 있기 때문에 Push까지 해본 경험이 있어야 정확하게 판단 할 수 있었다.

사용해보지 못한 팀원들이 있었기 때문에 팀원들에게 쉽게 이해시키려고 또한 빠르게 이해시키려고 노력했다. 분명히 입문 사용법은 알려 주더라도 왜 이렇게 하지라는 물음이 생길 부분에 대해서 설명해주었다.


1. 프론트엔드 입장에서의 아쉬운 부분

기초적인 CSS와 부트스트랩을 사용했다.
하지만 부트스트랩 테마를 사용했으면 더 쉽게 다가갔을 수 있었을텐데, 그 부분을 직접 구성하려다보니 시간을 많이 사용했다.
생각해보니 이전 프로젝트에서도 사용했엇는데 왜 HTML을 직접 작성했는지 나도 내가 이해가 안된다.

https://startbootstrap.com/
https://themewagon.com/theme-framework/bootstrap-5/
https://bootstrapmade.com/

물론 다시 한번 기초 HTML을 작성해보고 구조를 다시 생각해보고 검색해보면서 도움은 되었다. 하지만 시간적 제약이 있는 경우였고, 디자인에 자신없던 상황이면 최대한 경험을 활용했으면 좋았을 텐데 기획 과정에서 이 부분을 놓친 것이 아쉽다. 

다음 팀 프로젝트에서는 Front-end 담당자와 디자이너가 붙겠지만 내가 혼자 구현하고자하는 개인 프로젝트의 경우 이 테마들을 잘 활용하면 나 또한 깊은 이해도가 없어도 충분히 깔끔한 홈페이지를 구성 할 수 있을것이라 믿는다. 

또한 이 블로그의 소스를 일부 수정하면서 느낀것들이지만 백엔드를 공부하더라도 프론트엔드에 대한 이해도가 필요했다. 어떤 강의에서들은 적 있다. "관리자 페이지는 백엔드의 꽃" 백엔드라해서 프론트엔드 전혀 안하는게 아니다. 기본적으로 관리자 페이지는 만들 줄 알아야 되고 그 관리자 페이지를 사용하는 사람도 사람이다. 사용성을 생각해야 한다는 것이고 그것은 UX/UI에 대한 고려도 들어가야 한다는 것이다. 이 개발블로그는 사실 누가 보는지 상관없다. 결국 가장 많이 들어오는 사람은 "나"다. 관리자란 말이다. 관리자 페이지가 모바일에서도, 어느 웹에서도 잘 보이게 해야 내가 글쓰기가 편하다. 그래서 나는 HTML을 조금 뜯어고치면서 "나"의 만족 = 관리자의 만족을 위해서 소스를 살펴보았고 문제들을 고쳐나가보았다.

또한 Notion 페이지를 만들어보면서 Notion에서 얼마나 많은 사용자 고려가 있었는지도 파악 할 수 있었다. Notion페이지 만드는것도 아주 재밌는 일이라 블로그를 옮겨볼까 생각중이다. 내부적으로 Database도 쉽게 구성 할 수 있고, 갤러리, 임베드 등 너무 많은 기능들이 편리하다. 일단 반응형으로 잘 작동한다는 것이 얼마나 많은 기능들이 숨겨져있는지 존경스러울 뿐이다. Notion같은 프로그램 만들 수 있을까? 만들고 싶다.

특히 @Media라는 어노테이션을 사용하는것에 관심이 있었다. 초급 CSS과정에선 배우지 않은 부분이었는데 반응형 웹과 관련된 태그였다. 마치 java의 if문처럼 활용되서 나도 이해하는데 편리했고, 실제로 적용시켜보는 테스트를 블로그를 통해서 진행해봤었다. 나는 건축과 출신이라 그런지 생각보다 디자인 감수성이 높지만 CSS의 높은 이해도가 부족한게 아쉽다. 지금은 기능 구현의 기본기에 충실할 때지만 시간이 되면 프론트엔드와 관련된 지식들도 꾸준히 사이드로 겸비할 필요성을 느꼈다.

 

2. 형상 관리 관리자로써의 아쉬운 부분

아직도 아쉬운 점은 "기능별" Branch 생성이다. 아직까지도 day_1, day_2처럼 전체적으로 영향을 주는 형상관리를 진행하고 있었다. 이는 당장 급하게 형상관리에 대하여 팀원들에게 알려주는데 급급해서 해당 부분을 인지했음에도 버릇처럼 실수해버렸다. 물론 팀원별로 애초에 기능을 구분했기 때문에 이름으로 구분하는것 자체가 그 기능에 대한 branch생성으로 우회해서 생각 할 수 있지만 근본적으로 좀 더 "branch의 목적"에 맞게끔 사용했어야 했다. 나 또한 Login, Logout, Join 처럼 기능을 분리해서 관리했어야 했다. 다음 프로젝트에서는 무조건 "기능"에 따라서 Branch를 관리해야 겠다.
Branch를 이렇게 하지 마라! 기능으로 구분하자!! Branch명 = 기능!! ex) Login Branch를 Merge하면 Master에 Login 기능이 생기는 것이다!
 
아직도 궁금한 점은 실무자들이 현업에서 이러한 형상 관리 부분을 어떻게 진행하는지, Pull-Request에 대한 메시지를 어떻게 작성하는지 실제 실무자들의 진행 과정을 어깨넘어로 보고 싶은 궁금증이 생겼다.

인터넷으로 찾아보면 회사마다 다르다, 어느정도 템플릿은 있다. 뭐 이정도의 답변이 많아서 어떤 것이 맞는 정보인지 분별이 되지 않았다.

주변에 있는 멘토님들을 잘 활용해서 실제 프로젝트 Github를 또는 가장 유사한 프로젝트의 원격 저장소의 커뮤니케이션 모습을 참고할만한 곳을 소개받아야 겠다. 

특히 실무에서 사용되고 있는것을 알아보고 싶은 것은 다음과 같다.

Branch의 기준
 - 이런 강의 프로젝트에서는 대부분 그냥 매일 저장용으로 사용되는데, 예전부터 인터넷에 찾아보았던 내용과 멘토님의 말씀에 따르면 "기능 구현" 에 따라 나눈다고 알고 있다. 그 기능의 범위가 어느정도인지 실무자들의 Github를 보고 싶다.

Commit Message의 형태 및 Commit 시점
 - 지금은 배우는 과정이기 떄문에 쓸모없는 메시지가 많이 들어가고 있다. 실제로는 어떤 내용들이 들어가는지, 그럼 부족한 내용들은 세부 설명에다 기록하긴 하는데, Commit Message의 범위가 어느정도인지 알고 싶고, 초과하는 범위는 따로 기록을 하는 것인지 궁금하다.

Pull-Request와 Merge의 진행
 - 단순히 내가 하고 있는 방법은 각 브랜치(나 및 팀원) 들이 Commit 후 Push를 진행하면, Github에서 해당 Branch로부터 변동사항이 파악되면서 'Create Pull-Request' 가 생성된다. 이 말은 Master(형상 관리자)인 내가 Pull-Request를 하고 있는 상황인데,
이 Create Pull-Request는 작업자(요청자) 가 해야 하는 것인지, 그리고 말그대로 요청문이기 때문에 팀원이 해야 되는 것이 맞다고 생각한다. 그 이전에 단순 Collaborator로 들어와도 Github에 접속하면 Master에 접근 할 수 있고 나 말고도 초대자들도 Default로 Master Branch를 잡고 있던데, Collaborator의 Master 접근을 막을 수 있는지, 또한 팀원에게는 Pull-Request 요청 권한만 줄 수 있는지, Master만이 그 요청을 수락하고 Merge를 진행 할 수 있는지 이런 세부적인 사항이 궁금하다.

Master의 Merge이후 
현재는 1개의 프로젝트에 기록용으로 사용하기 때문에 위에서 언급한 Branch를 기능 보다는 팀원의 이름으로 한다던지 이런식인데, 기능으로 구분한다면 (ex: Branch1 name : Login, Branch2 name : Logout, Branch3 name : Join) 

https://ohnyong.notion.site/GameInsight-536ac8bfbd5445f19dff65eeddd385b4?pvs=4 

 

GameInsight

게임인사이트는 간편한 게임 관련 정보를 제공하는 서비스 페이지입니다.

ohnyong.notion.site

https://www.youtube.com/watch?v=Szj9XZU_7gE