1. 개인 회고
신승연
웹 프로젝트를 협업하는 경험이 처음이라 깃허브를 사용하는 방법이나, 역할을 분담하는 방법 등 프로젝트에 대한 감이 잡히지 않아서 걱정과 두려움이 컸습니다. 실제로 rebase를 하는 과정에서 실수를 많이 했지만 팀원분들이 친절하게 도와주셔서 잘 해결할 수 있었고 깃에 대해 더 많이 알게 되었습니다.
혼자 토이 프로젝트를 진행하다보면 중간에 어려움이 생기면 포기하기도 하고 적당히 완성 기준을 낮추며 타협하고는 했는데 이렇게 기한과 목표가 확실한 프로젝트를 팀원분들과 진행하다보니 책임감을 갖고 제 몫을 더 제대로 해야겠다는 생각이 저절로 들었습니다..
다른 분들과 같이 작업을 하게 되니 저의 실력에 대해 객관적으로 돌아볼 수 있는 기회가 되었고 팀원분들을 통해 정말 많은 것을 배우고 있습니다.
유승범
역시 가장 어려웠던 부분은 깃헙이였습니다… 깃헙 브랜치 전략 부터 rebase 시 충돌 해결 등 걱정했던 개발보다도 어렵게 느껴졌던 부분이 깃헙이였던 것 같습니다. 그래서 구글링을 열심히 많이 해보아서 기존 보다 많은 git 지식을 얻을 수 있었습니다. (아직 부족하지만)
또 하나의 난관은 airbnb eslint 였습니다…. 생각 보다 많이 빡빡해서 코드 스타일을 eslint에 맞추는데 초기에 시간이 많이 소요 됐습니다. 하지만 조금 익숙해지니 팀원끼리 코드 스타일을 어느 정도 맞출 수 있고 보다 깔끔하게 코드를 짤 수 있었다는 점에서 왜 현업에서 eslint를 통해 협업을 하는지 알게 되었습니다.
프론트엔드 끼리의 협업은 처음인데, 서로 pr에 대한 코드 리뷰도 해주고 피드백도 주면서 한다는 사실이 매우 좋았던 것 같습니다. 이 경험은 추후 최종 프로젝트나 현업에 가서라도 좋은 경험으로 남을 것 같습니다.
마지막으로 그 동안 나는 라이브러리 의존성이 컷다는 사실을 깨우치게 되었던 것 같습니다. 기능 단위, 컴포넌트 단위로 개발을 하게 되면서 라이브러리를 최소화 하여 구현을 해보았고 이점을 깨우치게 되었습니다. 이 점을 탈피하기 위해서 더 열심히 노력해야 겠구나 라고 느끼게 되었습니다…
유용상
같은 직군의 많은 사람과 프로젝트를 하는 게 처음이기 때문에 많은 기대를 품고 시작했습니다.
처음에는 기획하면서 근자감이 많이 차 있었지만, 프로젝트를 시작한 지 얼마 지나지 않아 깃헙이 발목을 잡았습니다.
서로 다른 작업을 하더라도 겹치는 부분이 생겨서 충돌이 발생하거나, 같은 컴포넌트가 필요한 경우가 생겨서 혼자 작업할 때보다 많은 시간이 지연되었습니다.
겹치는 부분은 보통 다른 사람이 만든 컴포넌트를 수정할 때 발생하기 때문에 이런 부분은 사전에 연락을 통해서 전달했고, 같은 컴포넌트가 필요한 경우는 공용 브랜치에 빠르게 구현하여 사용하는 것으로 문제를 어느 정도 해결하였습니다.
아직은 완전히 깃헙을 이해한다고는 할 수 없겠지만, 이번 기회를 통해 협업 스킬이 늘었다고 생각합니다.
정지영
KPT
K: Keep
- 프로젝트 진행 방식 → 프로젝트 기획(디자인) + 협업 사항들 + 구현 시작의 프로젝트 진행 방식에 대해 알 수 있었습니다.
- Git Flow에 대한 이해
→
Git pull, push, fetch, commit, add
등의 명령어 외Git rebase
와branch
를 적극적으로 사용함으로써 Git Flow에 대한 이해가 높아졌습니다.
- 프론트엔드 개발자들끼리의 협업과정이 처음이었습니다. 어떻게 협업을 진행하는지, 어떤 단위로 업무를 나누는지에 대한 사항들을 빠르게 익힐 수 있었습니다.
P: Problem
- 협업 단위를 어떻게 나눌까에 대한 고민
- Git Conflict
→
Git merge, rebase
시 빈번하게 발생하는 충돌
T: Try
- 협업 단위를 어떻게 나눌까에 대한 고민 → 크게는 기능 단위로, 작게는 Component 단위로 나누어 작업 하는 것으로 팀원들과 의논해서 원활한 협업을 진행중입니다.
- Git Conflict
→
vsc
또는 Git 사이트의 web view를 사용하여 충돌을 해결할 수 있었습니다. → 팀원들과의 빠른 소통이 가능했기에 해결할 수 있었습니다. → conflict 시 적용할 수 있는 여러 옵션을 사용해봄으로써 상황에 맞게 어떤 방식을 사용해야 할지 익힐 수 있었습니다.
진연주
KPT
K: Keep
- 빠른 정보와 문제점 공유로 큰 문제 없이 프로젝트를 진행할 수 있었습니다.
- 정해진 role(git commit, 파일 구조)들을 미리 정해놓고 프로젝트를 진행해서 좋았습니다.
- 프로젝트 진행순서
사용 기술 선정 > 아이디어 선정 > 화면 기획 / UI 디자인 > 프로토타입 구현(현단계)
P: Problem
- git rebase confilct
- 처음으로 rebase 명령어를 사용해보았습니다. 때문에 rebase에 대한 정확한 지식이 없어 처음에는 수시로 발생하는 충돌을 해결하는데 많은 시간을 소비하였습니다.
- airbnb eslint
- 다 안돼지만 깔끔한 코드를 구현하는 습관을 들이는데 많은 도움이 되었습니다.
T: Try
- git rebase confilct
- rebase에 대해서 공부하고, 어떤 식으로 진행이 되는지 파악하고 난 이후에 좀 더 유연하게 rebase를 사용할 수 있었습니다.
[잘했던 점]
- 활발한 카카오톡으로 인해 문제점을 바로 공유하고, 다른 팀원분들도 적극적으로 답해주셔서 소통을 원할하게 하고 진행을 빠르게 할 수 있어서 좋았습니다.
- 화면기획서와 figma 디자인이 구체적으로 작성되어 있어서, 프로젝트를 진행함에 있어 어떤 순서대로 진행해야 하는지 쉽게 파악할 수 있었습니다.
[잘못했던 점과 앞으로는 이렇게 하자]
- PR을 자주 올리기는 하지만 언제까지 해야하는지를 정하지 않아, 리뷰를 안 하는 팀원들이 생기고 좀 더 세심하게 확인해 보지 못 해 코드리뷰의 장점이 퇴색되어 가는 것을 느꼈습니다.
→ 코드 리뷰는 모두가 할 수 있지만, 머지 confirm을 2명 이상에게 받으면 바로 merge 하는 것으로
→ 하루 내에 작성된 코드리뷰를 기반으로
→ 반드시 2명은 하루 이내에 코드리뷰를 하고 머지 confirm을 해주는 것으로
→ 동작 잘 하는지를 먼저 체크하고, 이 후 코드 효율성 체크