Web IDE 마무리
이번 프로젝트는 내게 처음으로 해보는 협업의 경험이었다. 특히 기획단계에서부터 체계적으로 진행하려고 노력했고, 모든 팀원들이 동일한 목표를 가지고 많은 시간을 할애해서 했다는 점이 고무적이었다. 이론기간동안에 배운 이론들을 직접 적용시켜보는 것도 좋은 경험이였다. 이 경험에 대해 정리해보고 내생각을 상세하게 적으면서 리뷰해보려고 한다.
프로젝트 개요
Web IDE 프로젝트는 기본적인 요구사항에 우리 팀에서 생각하는 중요한 기능을 추가해서 진행해보는 프로젝트였다. 그래서 우리는 구름톤 이론기간에 느낀 아쉬운 점을 해결할 수 있는 기능을 추가하려고 했다. 그래서 학습하는 예비 개발자들이 여러가지 질문을 올리고 답할 수 있는 커뮤니티 기능을 추가하는 것을 목표로 했다.
구름톤을 진행하면서 필요했던 기능을 추가한 만큼 구름과 비슷한 단어가 들어간 이름이 였으면 했고, 그래서 우리의 Web IDE는 Groomy IDE가 되었다.
그리고 기능별로 각자의 역할을 선정하고 프로젝트를 시작했다.
프로젝트 요약
- 프로젝트 이름: Groomy IDE
- 프로젝트 기간: 24.01.29 ~ 24.02.26(약 28일)
- 팀 구성 및 역할:
> 프로젝트 인원들의 이름은 혹시 몰라 모자이크 처리했습니다.
Groomy IDE 구조
결과적으로 개발이 완료된 프로젝트는 기획단계에서 설계한 아키텍처와 다른점이 거의 없다.
그러나 기획단계에서 여러가지 라이브러리를 검색해보고 비교해보지 않고 개발단계에서 그때마다 선정해서 진행하는 방식이 되어서 사용된 라이브러리가 많아졌다.
기술 스택
1. Front-End
프레임워크
라이브러리
- Web Socket: SockJS, Stomp, Y-websocket
- Code Editor: Monaco Editor
- File Tree: Material-Tree-View
2. Back-End
프레임워크
라이브러리
- Spring Security
- JWT (JSON Web Token)
- STOMP (Simple Text Oriented Messaging Protocol)
- OAuth2 (구글 인증)
- Validation
- Spring Mail (이메일 인증)
개발 진행
개발을 진행하면서 여러가지 이슈관리와 커뮤니케이션 툴을 여러가지 사용해서 개발 진행을 원활하게 하기 위해서 노력했다.
진행 방식
우리 팀은 이슈 관리 툴로 Jira, 커뮤니케이션 툴로 Discord를 채택해서 사용했다. 이를 최대한 활용하기 위해서 우리는 개발 프로세스를 적립하려고 했다.
- Jira 이슈 등록: 모든 기능 개발에 대한 내용을 Jira에 등록
- Branch 생성: 기능마다 하나의 브런치를 추가해서 개발 진행
- 기능 개발: Branch에서 기능 개발
- Commit & Push: 기능에 대한 상세한 기능 구현 커밋
- Pull Request: 기능개발이 완료된 브런치 Develop 브런치에 PR 작성
- Code Review: PR을 기반으로 코드리뷰를 진행
- Rebase or Merge: Develop 브런치에 병합
- Git Actions: CI/CD 구축으로 병합시에 배포가 되도록 설정
- 에러 제보: 베포된 주소를 통해서 버그 제보
- 에러 수정: 버그 수정
개발 프로세스는 위와 같았고, 진행하면서 최대한 적용시키려고 노력했다. 모든 사람이 이런 프로세스에 익숙한 것은 아니다보니 적용을 실패할 때도 있었지만, 처음 진행하는 것치고 생각보다 팀원들이 잘 지켜서 진행해주었다.
부족했던 점
이슈 관리를 위해서 어떤 작업을 하고 있는지에 대해 서로에게 공유하는 방식을 극대화 시키기 위해서는 시각화 하는 것이 중요하다고 생각했다.특히 시각화 함으로써 다른 팀원들에게 본인이 작업중인 부분을 알리는 것뿐 아니라 본인이 마무리해야 하는 개발이 무엇인지를 인지할 수 있는 좋은 방법이라고 생각했다.내가 개발을 진행하면서 어떤 작업들이 끝났는지, 어떤 상세한 기능 개발을 해야하는지 문서화를 하지 않다 보니깐 하나의 기능 개발을 마치고 진행하는 것이 아니라 여러가지 기능을 왔다갔다 하면서 진행하면서 개발 속도가 늦어졌다.
그래서 팀을 위해 이를 시각화 하거나 문서화 하는 것이 중요하다고 생각했지만 짧은 기간 동안에 이를 적용시키기에는 어려웠다. 모든 팀원들이 100% 기능 개발에 모든 시간을 쏟다보니 그런 이야기를 할 여유가 없었다. 그럼에도 우리 팀은 스크럽 미팅을 통해서 최대한 진행 상황을 공유하려고 노력했다. 오전 시간에 항상 모여서 개발 진행 상황과 개발 예정인 기능을 공유하면서 진행했다.
전체 회고
전반적으로 결과물은 100%의 완성도를 가지고 있진 않았지만, 그래도 짧은 기간 동안 생각보다 좋은 결과물이 나왔다고 생각한다. 회고를 시작할 때 이야기를 했지만, 팀원 모두가 하나의 목표를 위해서 각자의 최선을 다한 결과라고 생각한다. 모두가 오전 10시부터 새벽 1, 2시까지 모든 시간 기능 개발에 몰두 했고, 이부분이 우리 팀이 처음 하는 프로젝트임에도 완성도가 높았던 이유라고 생각한다.
좋았던 점
프로젝트를 끝내고 나면 항상 아쉬웠던 점이 도드라져 보이는 경향이 있다. 그래서 아쉬웠던 부분을 어떻게 하면 고칠 수 있을지에 대한 고찰하는 시간이 많았다. 그럼에도 프로젝트 진행에 있어서 좋은 점이 없었던 것은 아니다. 그리고 좋았던 부분을 생각하지 않으면 다음 프로젝트를 시작하기 어려워진다. 그래서 좋았던 부분을 되돌아 보는 것도 필수라고 생각한다.
웹개발의 구조 학습
이번 프로젝트를 진행하면서 웹개발이 어떻게 이루어지고 특히 CI/CD를 구축하면서 웹 설계가 어떻게 되는지에 대해 많은 것을 배울 수 있었다. 정적 웹이나 프레임워크의 특성에 대해 생각해볼 수 있었고, 웹에 대한 두리뭉실한 이론들을 만들어 보면서 개념이 더 확실해졌다.
팀에서의 소통 방식
팀원간의 소통에 있어서 비대면으로 진행하는 것이 큰 걸림돌이 될 거라고 생각했다. 그러한 이유로 첫 기획회의를 대면으로 진행한 했다. 그러나 생각보다 개발을 진행하면서 비대면으로 의사소통 하는 것이 어려움을 준 적이 없었다.
특히 우리팀은 Discord 에 상주하면서 개발을 진행했기 때문에 필요한 부분에 대해서 Discord 를 통해서 즉각적으로 소통할 수 있었다.
팀원간의 화합
이 회고를 적으면서 정말 많이 강조하고 싶었던 부분이다. 그래서 반복해서 적게 되는 부분인것 같다. 팀이 하나의 목표를 가지는 것은 어렵지 않다고 생각한다. 그러나 하나의 목표에 대해 동일한 열정을 가지는 게 어렵다고 생각하는데 우리 팀은 그부분이 잘 맞았다. 각자의 최선의 노력을 다하려고 했고, 이를 통해서 팀원들의 노력을 보면서 나도 좀 더 열심히 하게 됬다.
아쉬웠던 점
어떤 프로젝트를 진행해도 아쉬운 점은 나오기 마련인것 같다. 이 아쉬운점을 어떻게 발전시켜 나가는 것이 중요하다고 생각한다. 그래서 최대한 아쉬웠던 부분을 비판적으로 이야기 해보려고 한다.
이슈관리
Jira를 통해 관리하려고 했던 이슈관리는 개발이 진행되면서 생각보다 어려웠다. 특히 새로 생기는 이슈에 대해서 이슈를 등록하지 못하고 개발에 들어가는 경우가 많았고, 상태 업데이트가 제때 이루어지지 않는 경우가 많이 생겼다.
이건 이슈 관리 툴에 익숙하지 않은 것도 있지만, 이슈관리 보다 기능개발 속도에 집중하는 경우가 많았다. 그리고 우리가 사용하는 툴이 너무 많다보니 Jira로 들어가는 빈도수가 적었던 것도 하나의 이유가 되는 것 같다.
그래서 기능이 좀 부족하지만 Github issue를 통해서 이슈관리를 하는 것도 해결책이 될 수 있다고 생각한다. 실제로 깊이있게 사용해보지 않았지만, 일단 Github를 들어가는 빈도수는 월등히 높기 때문에 이슈관리도 좀 더 편하게 사용할 수 있을 것이라고 예상한다. 따라서 짧은 프로젝트 진행시에는 Github issue를 사용하는 것을 추천한다.
라이브러리 사용
이부분은 팀에 대한 아쉬움이라기 보다 팀장인 나에 대한 아쉬운 점인것 같다. 처음 프론트 엔드로 개발을 진행하면서 팀장을 맡았지만 라이브러리 사용에 대해서 너무 무지했다. 어떤 방식으로 검색해보고 채택하는 것이 좋은지에 대한 생각을 못했다.
그래서 여러가지 라이브러리를 찾아보지 못하고 팀원간의 회의를 통해서 사용하는 것이 아닌 기능 개발자가 자체적으로 선정해서 적용시키는 방식으로 진행했다. 이는 라이브러리에 대한 공부 부족으로 적용하는 방식에 많은 오류를 일으켰고, 이를 해결하기 위해 정말 많은 노력을 기울여야 하는 어려움을 겪었다.
이러한 부분에 대해 현업자이신 멘토님이 많은 도움을 주셨고, 라이브러리 채택방식에 대해서도 알려주셨다. 프론트의 경우 여러가지 라이브러리의 다운로드를 비교해볼 수 있는 npm trends를 통해 비교해보고, github나 release의 빈도수를 통해서 지속적인 개선이 이루어지는 지를 확인하고 라이브러리를 채택하는 것이 좋다.
Git/Github Convention
git과 github를 통해서 기능 개발을 하면서 commit 이나, PR convention을 매우 강조해서 지켜지길 바랬다. 그래서 팀원분들도 많이 신경써서 진행해주셨지만, git과 github를 처음 써보는 팀원들이 많아서 처음에는 정말 컨벤션을 지키기가 쉽지 않았다. 그래서 지속적으로 고쳐야 할 점을 피드백을 하긴 했지만, 즉각적으로 적용되기가 쉽지 않았던 것 같다.
특히 git branch 전략과 PR을 넣는 방식에 대해서 설명을 충분히 하지 못했던 부분 때문에 이러한 어려움을 겪었던 것 같다. PR 컨벤션을 정해주면 좋겠지만, 팀장으로써 그 부분을 확립시켜주지 못한 부분이 내게 아쉬움으로 남았다.
ToDo
이전에 개발 방식에 대한 챕터에서 이야기 한 부분과 이어지는 부분이다. 이슈에 관련해서 각자의 To-Do가 확립되지 않고 진행된다는 느낌을 받았다. 특히 내가 이러한 부분에서 너무 아쉬웠던 것 같다. 그래서 내 기능 개발의 속도가 생각보다 느리게 진행되었다. 이부분은 기능의 세분화를 하는 능력을 길러가면서 Todo를 작성해보면 큰 도움이 될 것 같다.
주석, 문서화
팀적으로 개발하면서 프론트뿐 아니라 백엔드에 기여하거나, 백엔드분들이 프론트에 기여하는 이상적인 그림을 그리고 프로젝트를 시작했지만 생각보다 이부분이 어려웠다. 특히 개발이 진행된 부분들에 대해서 코드를 이해하고 이를 훼손시키지 않으면서 기여하는 것은 정말 어려운 일이였다. 그래서 백엔드의 작업이 비교적 빨리 끝났지만 프론트에 기여를 하지 못하는 경우가 생겼다.
이를 해소하기 위해서 좋은 방법은 주석 처리와 문서화라고 생각했다. 작성한 코드에 주석을 달면서 다시 코드를 확인하고, 다른 사람들이 기여하기에도 편한 환경을 만들어준다고 생각했다. 이부분을 처음에는 생각하지 못했다. 그리고 프론트의 경우에는 커스텀 훅을 활용하는 경우도 생기는데 커스텀 훅을 재사용하기 위해서 사용법을 md으로 문서화해놓으면 좋을 것 같다는 생각이 들었다.
마지막
이 프로젝트가 끝나자 마자 두번째 자유주제의 웹개발 프로젝트가 시작된다.
이부분에 대해서도 회고를 이어나가려고 한다. 이번 프로젝트에 대한 평점을 내려 보자면… 4.3/5.0정도이지 않을까 생각한다. 첫 프로젝트를 너무 좋은 팀원들과 함께해서 좋았다.
정말 첫 프로젝트를 진행하면서 하루에 12시간 넘게 개발하는 경험은 어디서도 하기 어려운 경험이고, 모두의 열정이 없었다면 불가능했다.
지속해서 프로젝트를 같이한 자바는 커피조 팀에게 말했지만, 부족한 팀장을 믿어주고 같이 노력해준 것에 너무 감사함을 느꼈다. 너무 배려심 많은 팀원들이 모인 팀이여서 재밌게 첫 프로젝트 마무리 했던 것 같다.
댓글남기기