멤버십 과정 첫 주가 마무리 되었습니다. 🥳

멤버십 과정은 실무형 프로젝트를 반복 수행하며 도메인 지식과 기술을 학습하는 학습 스프린트 8주, 팀을 이뤄 기술적으로 완성도 있는 서비스를 만드는 그룹프로젝트 6주로 구성되어 있습니다.

첫 4주는 기본적으로 알아야하는 도메인 지식과 기술을 모두 활용하여 서비스를 만들며 학습하고, 이후 4주는 조금 더 알고 싶은 도메인을 선택하여 더 깊게 학습해보는 과정이 기다리고 있습니다.

그래서 첫 주는 가장 기본적인 형태의 웹 서비스를 바닐라로 만들어 보는 미션이 주어졌어요

아마 기능들이 추가되고, 기존 기능을 개선해보는 미션이 주어지며 점점 더 완성도 높은 서비스로 바꿔가는 흐름으로 진행될 것 같습니다.

챌린지와 다른점

멤버십 과정은 챌린지 과정과는 추구하는 방향은 같지만 진행되는 방식이 조금 달랐습니다.

훨씬 현업과 같은 환경으로 프로젝트를 수행하며 개발에 필요한 내용들을 스스로 학습 방식으로 진행되었어요

데일리 스크럼과 피어세션

학습 스프린트라는 단어를 보고 눈치 채셨을수도 있을 것 같은데요!

챌린지 과정에서는 매일 동료들의 피드백을 받고, 서로의 생각을 공유해보는 피어세션을 가졌다면, 멤버십 과정의 학습 스프린트에서는 애자일 방법론 중 하나인 스크럼을 진행하듯 데일리 스크럼을 진행합니다.

챌린지 과정의 피어세션과는 달리 스터디 그룹의 구성원이 2주간 같이 학습한다는 점도 다른 부분이네요

멤버십 과정의 피어세션은 매주 금요일 아침 3시간 동안 1번만 진행하게됩니다.

데일리 스크럼은 30분 정도 짧은 시간동안 어제 수행한 작업 내용과 오늘 수행할 작업내용 그리고 하면서 발생했던 문제들을 공유하는 시간이었어요

데일리 스크럼에서 그룹원들의 애로사항에 대해 방향성을 제시해주려고 노력했는데, 도움이 많이 되셨다고 말씀해주셔서 뿌듯했습니다 🤩

PR과 코드리뷰

챌린지 과정에서는 당일 오전 9시까지 제출한 결과물을 바탕으로 어느정도 구현했는지, 잘한점, 개선할 점 등을 찾아 피어세션에 공유하였다면, 멤버십 과정에서는 1일 1PR을 만들고 자정에 자동으로 머지되는 방식이었습니다.

PR을 남길 때 어떤 부분을 작업했는지, 어떤 부분들을 학습했는지, 어떤 부분에서 고민이 있었고 어떻게 해결하였는지 꼭 남겨야 했습니다.

그리고 이 PR을 기반으로 시간이 날 때마다 각자 알아서 비동기적으로 코드 리뷰를 진행하는 방향으로 가이드 되었어요

저는 평균적으로 매일 아침 9시부터 데일리 스크럼 전 까지 그룹원들의 코드를 확인하고 코멘트를 남기려 노력했습니다.

퇴사 전에는 출근하고 오전 동안에는 VOC를 확인 후에 코드리뷰하는 것이 루틴이었는데, 오랜만에 출근해서 일하는 느낌이었네요😂

미션

위에서 언급한 것 처럼 조금 더 실무에 가까운 미션들이 주어졌습니다.

Figma 산출물을 직접 분석하고 프로젝트를 설계해야 했었네요

풀스택 개발자로 일 할때는 퍼블리셔 분들이 계셔서 Figma를 볼 일이 잘 없었는데 반가웠습니다😄

매주 월요일에 미션이 공개되는데, 월요일 PR에는 나만의 주간 계획서를 꼭 포함시켜야 한다는 가이드가 있었어요

현업에서는 WBS를 작성했겠지만 조금 과한 것 같아 mermaid를 이용해 gantt 차트를 일 별 작업에 맞추어 그려 주간 계획서를 만들어 봤습니다.

이러한 부분도 협업과 매우 유사하다고 느껴졌어요 ㅎㅎ

이렇게 세운 계획에 맞추어 자신만의 속도로 미션을 수행하면 되었습니다.

학습 내용

첫 4주는 풀스택 과정인 만큼 프론트엔드와 백엔드 모두 구현해야 했습니다.

어떤 내용인지는 비밀이지만🤫 express와 템플릿 엔진, Vanilla JS를 이용하는 고전적인 방식의 SSR로 만들어 보는 것이 목표였습니다.저는 목표대로 안했네요

Figma와 언어 정도를 제외하면 큰 제약이 없어 굉장한 자유도가 주어졌어요

저는 PHP 백엔드에 jQuery를 이용하는 레거시를 운영했었기 때문에 고전적인 방식의 SSR을 구현하는 데 익숙해서 색다르게 Vanilla TS를 활용한 SPA를 시도했습니다.

프론트엔드

HTML/CSS

일단 직접 HTML, CSS를 이용하여 UI를 구현해야 했습니다.

사실 저는 UI 개발 인턴을 경험했기 때문에 마크업이 익숙한 편 이었는데…

풀스택 개발자로 일할 때는 마크업을 직접 구현하지 않아서 그런지 오랜만에 하려니 처음엔 조금 어색하더라구요🥲하지만 금방 익숙해졌어요

적응하는 데 시간이 조금 더 필요했던 부분은 Floxbox 레이아웃이었습니다.

이전 UI 개발 인턴에서는 IE 8 대응을 기본으로 학습했기 때문에 float에 더 익숙했기 때문인데요

Figma도 박스 모델을 기준이 아닌 Flexbox을 기준으로 만들어져 있었습니다.

Flexbox에 익숙해지고 나서야 Figma를 제대로 이해할 수 있었네요…

IE8 대응할 때 사용하지 않던 CSS 변수, 함수등이 적극적으로 사용되어 있어서 처음엔 많이 혼란스러웠습니다.

Vanilla TS

바닐라 타입스크립트로 SPA 방식을 활용하기 위해 Vite를 이용해 개발 환경을 구성하였습니다.

Vite 같은 경우 현업에서 Vue3를 이용하여 프론트엔드 개발할 때 좋았던 경험이 있었고, Vanilla TS 환경을 쉽게 만들 수 있도록 제공해줘서 활용해봤습니다.

백엔드

express를 활용하여 서버를 구성해야했습니다.마스터인 호눅스님이 처음에는 node http로 구현하는 것을 고려하셨다고 하네요

저는 타입스크립트를 활용하여 프로젝트를 구성했는데, 자바스크립트의 자유로움을 제한하고, 타입의 장점을 취하기 위해서였어요

이를 최대한 활용하기 위해 레이어드 아키텍처와 DI를 적극적으로 활용하여 서버를 구성하였습니다.

express에서 라우터를 사용하는 구조가 Laravel, Ruby on Rails와 비슷하다고 느껴서 이를 참고하여 아키텍처를 구성해봤어요

처음에는 데이터베이스를 절대 활용하지 말고 목업 데이터를 활용해서 개발하라는 제약 사항이 있었습니다.

그래서 저는 Spring Data를 참고하여 Repository(Model)을 인터페이스로 구현하고, 더미 데이터를 주입받은 Repository를 구현하여 이후 데이터베이스 연결을 쉽게 적용할 수 있도록 대응해봤습니다.

아쉬웠던 점

테스트 코드

챌린지 과정에서는 TDD 활용하여 미션들을 수행하려했었는데, 이번주 미션에서는 TDD는 커녕 테스트 코드도 작성하지 않았습니다 😅

백엔드 코드는 더미 데이터를 활용하는 단순한 처리였기 때문에 굳이 붙여야 하나? 라는 생각이 들었던 것 같고, 프론트엔드 코드는 처음 고전적인 방식의 SSR에서 SPA로 넘어가는 과정에서 구조 변경이 잦아 마지막 날에야 설계가 확정이 되었습니다.

그리고 FE쪽은 어떻게 테스트를 해야할 지 감이 안오더군요 🥲

이번주에 설계가 확정된 만큼 다음주에는 TDD를 시도해 볼 수는 있을 것 같습니다. TTD 까지는 아니더라도 테스트 코드를 어떻게 붙여야할 지 고민을 많이 해보게될 것 같아요 🙃

커뮤니티 활동

챌린지 과정에서는 Slack에 올라오는 질문이나 의견에 답변을 많이 하려고 노력했었는데, 프론트 개발이 들어가서 그런지 모니터를 Slack에 할당할 수 없어 관심을 많이 못 줬던 것 같습니다.변명

다음주에는 Slack에 조금 더 주의를 기울이려고 의식적으로 노력해봐야겠어요🔥

마무리

데일리 스크럼, 그룹 리뷰, 피어 세션, 코드리뷰에서 제가 아는 모든 것을 공유하려고 열심히 노력했는데 다른 분들에게 도움이 되었을지 궁금하네요

그룹끼리 하는 활동을 넘어 다른 분들에게도 긍정적인 영향을 주고 영감을 주기 위해 더 많은 노력이 필요할 것 같습니다.

남은 기간도 끝까지 모두 화이팅~~~🔥🔥🔥