Velog Dashboard (V.D.) 1주차 회고

❓ 웬 1주차 회고록?

2달만에 돌아와서 쓴 글이 갑자기 뜬금없는 회고록이라 왜인지 궁금해하실 분들도 계실 것 같습니다.
사실은 최근에 Velog Dashboard (V.D.)라는 프젝에 참여하게 됬고, 이에 대한 회고록을 작성하게 되었습니다.

Velog를 자주 읽어보시는 분이라면 이 글을 보셨을 거라고 생각하고, 실제로 벨로그를 자주 읽는 저도 이 글을 봤습니다.

솔직히 말해서 위의 썸네일을 보고 들어온게 가장 큰 것 같은데.. 읽다 보니 스토리도 그렇고, 사용자들이 실제로 사용한다는 프로젝트라는 점에 이끌려 신청하게 되었습니다.

그렇게 신청 하고 어찌 저찌 지내다 보니.. 같이 참여하지 않겠냐는 문자가 도착했습니다.

그렇게 도착한 문자에 참여 의사를 밝히고, 해보고 싶던 프젝에 참여하게 되었습니다.

🤔 첫 회의

그렇게 초대를 받게 되고, 화요일 밤에 프로젝트 첫 회의를 진행하였습니다.

첫 회의인 만큼 프로젝트에 대한 소개와 함께 서로 자기 자신에 대해 소개하는 시간을 가졌습니다.
또한 그라운드 룰, 데일리 스크럼 룰, 회의 일정 확립을 진행하는 등 프로젝트에 대한 많은 걸 정했습니다.

아 그리고 또 기억에 남는 점으로, 구글 Meet이 프리미엄 없이는 1시간 제한이 있어서 하다가 중간에 방이 터지면 5분씩 쉬는 시간을 갖기도 했습니다.

💭 프로젝트에서...

목표는 어떻게 되는가

[North Star] velog 쓰는 모든 사람이 전체 통계를 아주 편하고 빠르게 보게하는 것

현재 저희의 목표는 위와 같습니다.
이를 위해 velog 를 쓰는 모든 사람이 velog dashboard 를 사용하게 만든다. 라는 하위 목표 또한 준비해둔 상황입니다.

스택은 어떻게 되는가

• 기술 스택?
  • 프레임워크 (NextJS)
    NextJS ⇒ 서버 측 자원 관리가 필요하긴 하지만, 최적화 기능도 많고 SEO도 좋음
    ReactJS ⇒ 시작하기 빠르고 단순하지만, SEO가 조금 모자랄 수 있음
    SEO 지원과 배포 용이성을 고려하면 NextJS가 좋을 듯 (100명 목표 달성 기회)
  • 언어 (Typescript)
    Javascript 사용시에 Human Error 발생 가능성 농후
    Typescript를 통해 Human Error 방지 및 데이터 관리의 용이성 보장 (+ 모델링 구조 지정)
  • API 연동 (Fetch + Tanstack Query)
    연동시에 꼭 fetch + Tanstack Query를 써야 할까?
    서버에서 파싱을 위해 GraphQL을 사용한다면, 클라이언트에서도 사용해볼까?
    (다만 기능들을 보면 API가 많지 않을 것으로 보임, 단순한 방식도 괜찮을 듯)
  • 스타일링 (TailwindCSS)
    스프린트가 적용되어 빠르게 개발해야 하는 점, 프론트엔드쪽에 큰 협업이 없다는 것을 고려하면 TailwindCSS가 좋을 듯 (+ NextJS는 TailwindCSS 기본 지원!)

다른 분들이 작성해둔 스크럼과 제 생각을 기반으로 골라본 기술 스택입니다.

또한 선택 과정에서 아래와 같은 이슈가 있었습니다.

• NextJS
  선택 과정에서 현우님이 "단순 CSR이 아니라 SSG로 하는게 어떤지"에 대한 의견을 제안해주셨습니다.
  다만 SSG는 프로젝트를 빌드할 때마다 값이 바뀌는 것으로 기억하고 있었고, ISR을 적용하여 일정 시간(서버에서 데이터를 갱신하는 시간)마다 데이터를 캐싱하는 식으로 적용하자는 제안을 드렸고, 괜찮을 것 같다는 답변을 들어 선택하였습니다.
• TailwindCSS
  교내 프로젝트를 협업 없이 저 혼자 진행한 경험도 많았고, 프로젝트 개발시에 네이밍에 쓸 시간을 줄이면 좋지 않을까 싶어 선택하였습니다.
  다만 이번 프로젝트는 프론트엔드/백엔드의 경계를 비교적 허물어둔 상태로 서로의 코드를 리뷰하며 진행하는 프로젝트였기 때문에 다시 한 번 고민해봐야 했습니다.
  다만 현우님이 TailwindCSS를 사용해본 경험이 있다고 말씀해주셨고, 현 상황에서 이 라이브러리를 대체할 만한 라이브러리가 없다고 판단되어 선택하였습니다.

경험은 어땠는가

뭐, 겨우 1주차밖에 안 된 만큼 기술적으로 새로운 부분을 배우진 못했습니다.
다만 "스타트업의 느낌에 맞춘 프로젝트"를 표방했던 만큼 정말 체계적으로 진행됬고, 이 부분에서 굉장히 새로운 느낌이 많이 들었습니다.

좋았던 점 (K)

• 협업을 위한 쳬계적인 프로젝트 관리
  그라운드 룰, 코드리뷰 룰 등 협업을 위한 규칙 마련이나 매일 매일 진행되는 daily scrum을 통한 정보 공유가 꽤나 인상적이었던 것 같습니다.

• 수평적인 의사소통
  제가 고등학생임에도 불구하고 수평적으로 의사소통하는 경험도 만족스러웠습니다.
  다들 서로를 적절히 높여서 말씀해주시는 것 같고, 어느 한 팀원분이 곧 면접을 보신다고 하니 현우님이 밤늦게 도와주셨던 점도 기억에 남는 일이었습니다.

아쉬웠던 점 (P)

• 용어와 개념에 대한 이해성
  기술적 용어는 고사하고, OKR이나 애자일의 에픽 개념 등 생소한 용어나 개념들이 많아 대화에 집중하기 조금 어려웠던 것 같습니다.
  나름대로 모르는 단어가 나올 때마다 찾아봤다고 생각하긴 하지만, 여전히 부족하긴 한 것 같습니다.

• 협업 경험 그 자체
  위의 문제와 연결되는 문제로, 이해도가 낮아 집중하기 힘들다보니 중간 중간 멍한 느낌이 보이진 않았을까 싶습니다.
  다들 열심히 진행해주셨는데, 중간 중간 멍한 표정을 짓거나 집중을 못 하는 모습을 보여드린 것 같아 조금 죄송스럽습니다.

해결 방법 (T)

• 용어 알아오기
  중간 중간 남는 시간이 있는데, 이 시간마다 노션을 둘러보며 모르는 용어를 찾고, 정리해보는 게 좋을 듯 합니다.
  이 부분을 해결하면 아마 협업 경험 그 자체에 대한 문제도 해결되지 않을까 추측됩니다.

결론적으로

새로운 프젝에 새로운 규칙, 처음 뵙는 분들과의 깊은 협업이 조금 어려운 느낌이긴 합니다.
하지만 이런 부분을 개선해나가며 성장하는게 아닐까 싶습니다.

이번에 많은 걸 정한 만큼, 앞으로 이 규칙들을 따라나가며 V.D.를 잘 완성시키기 위해 노력하자는 생각과 함께 글을 마칩니다.

(아 그리고 이제 내일이면 스크럼 마스터가 바뀔텐데, 만약 제가 된다면.. 과연 제가 스크럼 마스터를 잘 할 수 있을지 좀 걱정됩니다;)