-
Notifications
You must be signed in to change notification settings - Fork 0
1주차 개인 회고
이번주부터 그룹프로젝트를 시작했다. 첫 주라 팀 빌딩과 프로젝트 기획을 팀원들과 함께했다.
팀 빌딩에서 팀 규칙과 깃 컨벤션을 결정하였다. 여태 혼자만 개발공부를 해보았기 때문에 이러한 규칙을 정하고 컨벤션을 정하는 것이 처음 겪는 경험이였다.
프로젝트 기획은 우리의 프로젝트가 기존에 있던 프로젝트를 변형 하는 프로젝트기 때문에 큰 틀이 기획되어 있었다. 우리 팀의 프로젝트는 leetrooms라는 익스텐션을 국내의 백준 사이트에 맞게 바꾼 프로젝트이다. 덕분에 큰 틀을 기획할 필요는 없지만, leetrooms가 이용하는 사이트인 leetcode와 백준이 완전히 동일하게 작동하는 사이트가 아니기 때문에 우리 프로젝트에 맞게 바꿔야할 부분이 많았다. 이 부분들을 팀원들과 회의를 통해 기술적인 부분과 사용자 경험 부분을 생각하며 결정하였다.
이번주는 이렇게 팀 빌딩과 프로젝트 기획을 하며 팀원들과 계속 줌 회의나, 오프라인 회의를 통해 진행하였다. 처음 겪어보는 경험이다 보니 다른 팀원들보다 적극적으로 참여하지 못했던거 같았다. 그래도 이번주 경험을 통해 협업에 대해 어느정도 느낌을 알 게된 것 같다. 좋은 팀원들을 만나서 배울것이 정말 많은 것 같다. 앞으로 남은 기간동안 팀원들과 적극적으로 의사소통하고, 문제를 해결해 나가며 좋은 개발자로 성장할 수 있는 계기가 되었으면 좋겠다.
한마디로, 내가 이 프로젝트를 하는 목적이 무엇일까 이다. 여태 백엔드 코드만을 계속 짜왔다. nest와 typeorm을 어떻게 쓰는지 배우는 건 아마도 오래걸리지 않을 것이다. 다만, 어떻게하면 잘 쓸 수 있을까는 조금 다른 문제이긴 하지만 말이다.
그렇다면 여기서 내가 배우고 싶은 건 어떤 부분일까. 우선 배포를 배우고 싶다. 어떤 프로세스로 클라우드 환경에 배포를 할 수 있는지 알고 싶다. docker, vpc, linux 등 알아야 할 것들이 너무나도 많다. 그 다음으로는 웹소켓 또는 폴링 방식으로 한번도 만들어보지 않았던 채팅 기능을 만들어보고 싶다. 아무래도 이 두 개가 내 기술적인 도전이 될 것 같다. 기술적인 도전이라고 하기도 뭐하지만 새로운 배움의 영역이라고 말할 수 있을 것 같다.
추가적으로 HTTPS, CI/CD, 테스트코드, 스트레스 테스트 등에 대해서도 고민을 할 것이다. 각 기술들에 대해서 일주일에 하나씩 배워도 양이 많겠지만 말이다.
비 개발적 배움의 영역에서는, 태도인 것 같다. 왜 이렇게 짜야하지 왜 이걸 써야하지 하는 고민말이다. 물론 처음 배우는 기술에 대해서는 특히 docker나 cloud 같은 것들은 내가 왜 써야 하는지 아직 답을 못할 수도 있다. 사실 문제를 겪고 써봐야 제일 좋지만 그냥 써보고 싶을 수도 있지않나. 그런 부분에 대해서는 일단 편안하게 한번 써보고 되는 걸 본 다음 다른 기술과 비교를 해보는 게 좋을 것 같다.
- nest js docker 등의 수준의 기술도 쓰는 이유를 알아야 하나 → 알면 좋다
- 깃헙 패키지에서 도커 이미지 저장할 수 있다
- nest는 스웨거를 데코레이터만으로 만들 수 있다
- 채점만 트래킹하는 서버를 따로 둘 수도 있을 것 같다
- 관찰을 통한 이유 파악이 있어야 최적화를 할 수 있다
벌써 6주간의 그룹프로젝트 일정 중 첫번째 주가 지나버렸다. 근데 사실 조를 구성한게 2주정도 되어서 1주차의 느낌은 아니고.. 팀원들끼리도 많이 친해진 것 같다.
이번주는 팀빌딩과 각종 그룹 룰을 정하고 기획을 확정했다. 우리팀은 leetrooms를 국내에 맞게 포팅해서 서비스하는 것을 목표로 하고 있어서, 기획을 짜는데 큰 어려움이 없었다. (없을 줄 알았다.) leetrooms의 기능을 거의 가져오고, 백준과 맞지 않는 부분을 수정하고, 부족하거나 아쉬운 부분들을 보강 할 예정이다. 완전히 새로운 서비스를 만드는게 아니고, 기존에 있는 서비스를 국내의 실정에 맞게 포팅해오는 것이다보니, 기획에 큰 어려움이 없을 줄 알았는데, 생각보다 세세한 내용들이 다른 것이 많아서, 익스텐션 기능의 활용 범위와 권한을 정의하는 것에 약간 애를 먹었다. 우리는 우선 최소한의 기능 구현을 목표로하고, 이를 달성 한 뒤 경과를 보면서 기능을 추가하는 것으로 결정했다.
그 다음은 그라운드룰을 정하는데, 팀원분들과 이해가 잘 맞고 다들 적극적으로 참여해주어서 큰 무리 없이 팀의 철학과 규칙들을 정할 수 있었다. 그룹프로젝트에서는 기술적 성장도 당연히 중요하지만, 이러한 협업의 기술들을 배워가는 것이 제일 중요하다고 생각한다. 앞으로 플젝을 진행하면서 당연히 의견충돌과 갈등이 있을 수 있지만, 잘 해결해나가면서 서로의 성장을 이루어 나가고 싶다.
이번 주차는 저희 프로젝트의 첫 주차였다. 주로 기획 회의에 집중했는데, 이미 정해진 기획이 있어서 기능 상세를 결정하는 부분은 비교적 빠르게 진행되었다. 그러나 이번 주차에서 가장 중요한 과제는 리트코드와 백준과 같은 다양한 온라인 코딩 플랫폼의 문제를 해결할 때 나타나는 기술적인 어려움을 극복하기 위한 기술 가능성 검증이었다.
기획이 이미 정해져 있어서 기술 가능성 검증에 집중할 수 있었던 것은 다행이지만, 이러한 기술적인 과제들은 개발자로서의 역량을 향상시키는 데 큰 기여를 한다는 생각이 들었다. 이러한 도전적인 과제들을 해결해 나가는 과정은 개발자로서의 성장이 있을 것 같다는 생각이 들었다.
팀의 문화와 협업을 위한 중요한 부분을 다루었다. 팀원들과 의견 교류를 통해 팀의 문화를 정하고, 개발 과정에서 필요한 규칙과 컨벤션을 마련하는 작업을 진행했다. 이를 통해 팀원 간의 원활한 소통과 협업을 위한 기반을 구축하고자 노력했다.
작은 규칙부터 이슈 처리 방식, 커밋 메시지 형식, 브랜치 관리 방법, PR(Pull Request) 작성 규칙 등을 상의하여 정하였다. 이러한 규칙과 컨벤션은 향후 프로젝트를 진행하면서 생기는 다양한 문제를 빠르게 해결하고, 개발 속도를 높이는 데 큰 도움이 될 것으로 믿는다.
또한, 5명의 팀원으로 구성된 팀에서는 각자의 의견을 존중하고 취합하는 것 뿐만 아니라, 다른 팀원의 의견을 잘 따라가주는 팔로워십도 중요하다는 점을 깨달았다. 팀원 간의 신뢰와 협력은 팀의 성과에 큰 영향을 미치고, 좋은 결과 뿐 아니라 좋은 관계를 남길 것으로 기대한다.
라이브러리 선택은 문제 해결을 위한 중요한 단계이다. 그러나 라이브러리를 마법같이 기대하지 말고, 사용 이유와 작동 원리를 이해하고 적절한 기술 스택을 선택해야 한다. 수준에 맞게 적절한 기술 스택을 관리하자.