First Project 회고
2주간 열나게? 달린 첫 프로젝트...
결과물을 보고 있으면 뭔가 부족한 점이 많아서 부끄러우면서도, 그래도 계속 보다보니 볼만하다는 마음이 상반된다.
첫 계획은 원대하였으나, 프로젝트가 진행되고 점점 마감? 압박에 시달리면서 열심히 기능을 가지치기
하고 뼈대도 수정했던 것 같다.
보잘 것없는 결과물?일 수도 있지만, 아무 것도 없는 백지에서 기존에 배운 기술들을 복습하고 적용한다는 점에서 의미 부여를 할 수 있는 프로젝트였다
배포 링크는 없지만, 발표 자료로 흔적을 남겨보았다.
Keep(지킬 점)
첫 프로젝트를 하면서 좋았던 점, 지켜야할 점을 생각해 보았다
gather.town
게더타운
이라는 메타버스 기반 화상 회의 앱을 사용해서 마치 한 사무실에서 작업을 하듯이 프로젝트를 진행할 수 있어 좋았다- 마치
모각코
하는 느낌?
- 지속적인 소통
- 게더타운 뿐 아니라 디스코드로도 계속적인 소통을 하였다는 점
- 기본적인 소통이 잘 되어서 프론트엔드와 백엔드 양 사이드에서 구현해줘야 하는 기술적 부분에 대해 피드백이 잘 되었고, 양 사이드가 이해할 수 있또록 기술적인 설명도 잘 이루어져서 좋았다
- 좋은 분위기
- 프로젝트 마감 시한이 다가오게 되면서 어쩔수 없는 야간 작업이 진행되었는데도, 얼굴 붉히지 않고 다들 프로젝트에 노력을 다하고 끝까지 쿠션어와 분위기 환기 타임을 가져간 점!
Problem(문제점, 개선할 점)
프로젝트를 하면서 문제였던 점, 개선해야 할 점을 생각해 보았다
- 불완전한 기획
- 첫 프로젝트다보니, 초기 단계인 기획 단계에서 서툰 부분이 많았다. 그에 따라 프로젝트를 진행하면서 계속 수정/보완해갔는데(특히 DB스키마!), 이에 대한 중복적인 시간 소모가 잦았다
- 임무 분배
- 태스크카드를 잘 활용했어야 했는데, 이 부분을 잘 활용하지 못해 임무 분배을 제대로 하지 못하였고, 그때 그때 작업 분배를 결정하게 됨으로써
손만 빨고 있는 시간
이 발생하게 되었다(작업 능률 및 생산성 감소)
- 태스크카드를 잘 활용했어야 했는데, 이 부분을 잘 활용하지 못해 임무 분배을 제대로 하지 못하였고, 그때 그때 작업 분배를 결정하게 됨으로써
- Branch 활용 미숙
- git workflow에 따라 각 기능별로 feature를 따서 dev에 올리는 방식으로 작업해야 했는데, 작업 상 편의로 인해 계속 dev branch만을 이용하여 작업을 진행하게 되었다. 이로 인해 간혹 발생하는 병합 충돌 및 코드 에러 등을 바로 잡는 불필요한 작업이 진행되었다
Try(다음에 시도할 부분)
- GitHub 기능 활용
- 앞에 문제점으로도 적었었지만, GitHub의 기능을 잘 활용하지 못했던 것 같다. 특히 태스크카드 및 projects 칸반보드, 마일스톤 등을 효과적으로 쓰지 못했다. 여러 사람이 협업하다보면 기본 작업 시간 외에 추가적인 코딩 작업을 할 때, 각자 가능한 작업 시간이 다를 수 있다(식사 시간, 개인의 라이프사이클, 그외 긴급한 일). 태스크카드와 칸반보드를 잘 활용했다면 이런 부분을 잘 커버할 수 있을 것 같다(ex.
작업 진행중
->작업 완료
로 카드 옮기기 등)- Git Workflow를 잘 지켜서 진행해야겠다. Branch 관리를 안하고 작업을 한다면 특히나 개발 환경에서 잘못하면 프로젝트 전체 데이터를 날려버리는
대참사
가 발생할 수도 있을 것 같다.코드 안전장치
라는 개념으로1차 비번
이 dev라면2차비번
인 feature 브랜치를 반드시 따서 진행해야겠다
- Git Workflow를 잘 지켜서 진행해야겠다. Branch 관리를 안하고 작업을 한다면 특히나 개발 환경에서 잘못하면 프로젝트 전체 데이터를 날려버리는
- 앞에 문제점으로도 적었었지만, GitHub의 기능을 잘 활용하지 못했던 것 같다. 특히 태스크카드 및 projects 칸반보드, 마일스톤 등을 효과적으로 쓰지 못했다. 여러 사람이 협업하다보면 기본 작업 시간 외에 추가적인 코딩 작업을 할 때, 각자 가능한 작업 시간이 다를 수 있다(식사 시간, 개인의 라이프사이클, 그외 긴급한 일). 태스크카드와 칸반보드를 잘 활용했다면 이런 부분을 잘 커버할 수 있을 것 같다(ex.
- AWS 배포 프로세스
- 프로젝트 기본 기능 구현에 우선 순위를 두다보니, 막판 시간 부족으로 AWS를 통한 배포 및 실제 운영 구현을 하지 못했다. 아무리 개발을 잘해도 사용자들이 접근해서 쓸 수 있어야 그 서비스가 의미가 있다. 반드시 배포 과정을 겪어보고, 에러 핸들링도 처리해봐야겠다.
https
부분을 고려하여 cloudfront, 로드밸런서도 쓰는 방향으로 구현하고 싶은 원대한 계획은 있다. 계획은 그렇다는 점...
- 프로젝트 기본 기능 구현에 우선 순위를 두다보니, 막판 시간 부족으로 AWS를 통한 배포 및 실제 운영 구현을 하지 못했다. 아무리 개발을 잘해도 사용자들이 접근해서 쓸 수 있어야 그 서비스가 의미가 있다. 반드시 배포 과정을 겪어보고, 에러 핸들링도 처리해봐야겠다.
총평
현재 나의 능력의 부족함을 절실히 깨닫게 되는 프로젝트였다. 기본적인 기능 구현조차도 매번 다 기존의 실습 자료들을 찾아보고 선배 기수 분들의 코드를 뜯어보면서 겨우겨우 우리 프로젝트에 맞게 바꾸면서 했던거 같다. 게다가 처음 했던 계획과는 다르게 하루하루 프로젝트를 진행하다보니 쳐낼 것을 계속 쳐내서 앙상한 기둥만 남은 나무처럼 되어서, 우리 프로젝트의 Kick
이 제대로 나타나긴 하는걸까 걱정이 된 점도 있다.
짧은 프로젝트 기간이었지만, 다른 팀들의 작품을 보니 퀄리티가 대단한 작품들이 많아서 개인적으로 위축되는 느낌도 받긴 했다. 그래도 사람이 어떻게 첫술에 배부르랴...
부족한 점은 부족하다고 인정하고, 이제 다시 시작되는 프로젝트에서는 첫 프로젝트를 반면교사
삼아서 부족한 점은 채우고, 또 살을 채워가면 될 거라 생각한다. 이번에 키울 나무(프로젝트)는 반드시 이파리를 살려서 꽃을 피우게 하겠다는 목표로 해보겠다.
'Project 주저리' 카테고리의 다른 글
[Error Handling] Oauth 로그인 시 CORS 에러 (0) | 2022.01.31 |
---|---|
[Project] First Project 시작 (0) | 2021.12.13 |
[Project] 프로젝트 진행 Tip (0) | 2021.12.13 |