레벨3 3~4주차 회고

하루스터디의 새로운 방향

1~2주 차의 하루 스터디는 하루만 진행하는 스터디를 모집하는 플렛폼의 역할을 하는 서비스였다. 하지만 1차 데모데이가 끝난 후, 팀원들과 하루 스터디의 방향, 핵심 가치에 대해 많은 고민을 가졌다. 본질적으로 모집 - 진행 - 관리가 사용자에게 빠르게 핵심가치를 전달해 줄 수 있을까?라는 의문점을 가지게 되었다. 어느 서비스에서나 가능한 기능이기에 하루 스터디만의 뾰족한 무언가가 필요했다.

 

1차 데모데이 직후 준의 피드백의 바탕으로 3주차 첫 날인 7월 10일에 팀원들끼리 직접 스터디를 진행 보았다. 스터디의 순서는 다음과 같다.

 

1. 목표 설정

2. 학습 진행

3. 회고

 

두 번의 싸이클을 돌고 나서 가장 크게 느꼈던 점은 '엄청난 집중력으로 학습 목표를 달성하기 위해 노력했다'라는 것이다. 학습 진행 시간이 굉장히 짧았다. 한 싸이클에서의 학습 진행 시간이 30분 정도였기 때문에 이전에 설정한 목표를 달성하기 위해 최대한 집중을 했기 때문이다. 하지만 목표를 꼭 달성하지 않아도 괜찮았다. 회고를 통해 내가 설정한 목표를 되돌아보며 다음 학습의 목표를 재설정할 수 있었기 때문이다. 목표를 달성했다면 나름대로 의미 있는 학습이었다고 생각하여 성취감을 느낄 수 있었다.

 

즉, 이런 스터디의 최고 장점은 '효용성있는 스터디 경험 제공'이었다. 이런 스터디를 제공하기 위해 기획을 다시 처음부터 하게 되었다.

---

모집 플렛폼에서 스터디 도구 제공 서비스

모집은 다양한 플랫폼에서 진행할 수 있다. 하지만 그들이 사용하는 스터디 도구는? 매우 다양할 것이다. 이를 타깃으로 잡고 우리는 스터디를 진행하는 사람들에게 스터디 도구를 제공하기로 하였다.

 

이런 과정에서 로그인은 꼭 필요한 기능이 아니다. 때문에 로그인 기능은 2차 데모데이의 핵심 기능이 아니었다. 보다 쉽게 스터디 방을 만들고 사람들이 참여할 수 있고 목표 설정 - 학습 진행 - 회고를 경험할 수 있도록 하는 것이 핵심 기능이었다. 이를 바탕으로 무엇이 필요한지 팀원들과 3~4일 동안 의논을 하였다. 2차 데모데이에 목표란 핵심 기능을 간단히 소개하면 다음과 같다.

 

1. 스터디 개설하기 - 스터디장이 스터디방을 만들고 참여코드를 스티디원들에게 나누어준다.

2. 스터디 참여하기 - 참여코드를 바탕으로 스터디에 참여한다.

3. 스터디 진행하기 - 목표 설정, 학습 진행, 회고의 순서로 스터디가 진행된다.

4. 스터디 기록 - 설정한 싸이클동안 작성한 목표와 회고의 기록을 보여준다.

 

기획과 함께 새로운 API도 만들어지고 디자인도 만들어졌다. 1~2주 차 동안 진행한 기획보다 더 짧은 3~4일 동안의 기획이 훨씬 알찼고 앞으로 하루스터디가 나아갈 방향을 더욱 탄탄하게 다질 수 있는 시간이었다. 역시 주변에 도움을 청하는 것이 혼자 끙끙 앓고 있는 것보다 가치가 있다. 진작에 그랬다면 시간을 더욱 아낄 수 있었겠지만 지금도 만족한 결과이기 때문에 후회하진 않는다.

---

하루스터디의 디자인

하루스터디의 방향, 기획이 바뀌었기 때문에 디자인도 확 바뀌었다. 메인홈에는 '스터디 개설하기', '스터디 참여하기' 버튼만 있을 뿐 다른 것들은 필요하지 않다. 때문에 어떻게 채워야 할지 많이 고민하였다. 다음은 이번에 새롭게 디자인한 메인페이지이다

하루스터디 메인페이지

공고게시물로 꽉 차있던 이전 디자인보다 훨씬 깔끔해졌기 때문에 너무 만족한다. 

 

스터디 진행은 총 3개의 단계로 구성되어 있기 때문에 각각의 테마 색깔을 정하였다. 이 부분도 굉장히 깔끔하다고 생각하여 마음에 든다.

012

스터디 진행 페이지

이 외에도 개설하기, 참여하기, 기록 페이지가 있다. 모두 만족한 디자인여서 얼른 개발에 들어가고 싶었다. 

---

프론트엔드 개발 시작

드디어 기획이 끝났고 기능 개발에 들어갔다. 확실히 기획하는 것보다 코드를 작성하며 화면에 어떤 컴포넌트, 페이지가 만들어지는 보는 것이 훨씬 행복하다. 지금까지 기획한 과정이 불필요했다는 것은 아니다. 엉성한 기획을 바탕으로 개발을 하는 것보다 팀원 모두가 만족하고 핵심가치를 들어낼 수 있는 서비스를 개발하는 것이 더욱 공동의 목표를 달성하기에 충분한 동기부여가 되었기 때문이다. 만약 기획에 계속 의문을 가지고 있었다면 즐거운 개발은 할 수 없었을 것이다.

컴포넌트 그리고 페이지 개발

2차 데모데이까지 목표로 잡은 기능을 구현하기 위해 룩소, 엽토와 역할을 나누었다. 일단 페이지가 명확하게 나누어져 있었기 때문에 각자가 어떤 페이지를 개발할지 정했다. 나는 렌딩페이지, 기록페이지를 맡게 되었다. 페이지별로 나누었다 해서 페이지를 바로 개발하는 것이 아니라 common 컴포넌트를 먼저 생각하여 이를 먼저 개발하였다. 내가 2차 데모데이까지 개발한 common 컴포넌트는 다음과 같다.

 

1. Button

2. Menu

3. Accordion

4. Tabs

 

페이지를 개발하는 것도 재밌지만 컴포넌트를 재사용할 수 있도록 만드는 것이 더 재미있다. 특히 이번에는 합성 컴포넌트를 활용하여 common 컴포넌트를 만들어봤는데, 어려우면서 재밌는 과정이었다. 앞으로 합성 컴포넌트에 대해 더 자세히 알아보고 고도화를 진행해 보도록 하자. 물론 현재 만든 합성 컴포넌트에 대한 글도 올릴 생각이다. 

webpack 설정

컴포넌트, 페이지 개발 뿐 아니라 프로젝트 초기다 보니 기본적인 설정을 추가하거나 설정을 수정하는 것도 필요했다. 특히 webpack을 많이 수정하였다. 다음은 이번 2차 데모데이까지 수정한 웹팩의 내용이다.

 

1. 폰트 적용을 위한 css-loader, style-loader 설정 추가

2. png, jpg와 같은 asset 파일 빌드를 위한 웹팩 설정 추가

3. 중첩 라우팅 해결을 위한 publicPath 설정 추가

4. path alias 적용을 위한 웹팩 설정 추가

 

위와 같은 내용도 팀 블로그에 정리할 계획이다. 기본적인 웹팩 설정도 함께! (이렇게 보면 할 건 많다 😭)

path alias

지난 레벨2에서 path alias을 설정하여 깔끔한 import 순서를 지켰다. 이를 하루스터디 프로젝트에서도 적용하고 싶었다. 때문에 내가 맡아서 이를 설정하였다. 다른 설정(eslint, webpack)은 보다 path alias을 설정하는 것이 훨씬 재미있게 느껴진다. 코드에서 바로 적용된 모습이 깔끔해서 그런가?

 

물론 과정은 순탄치 않았다. 직접 webpack 설정을 해야 했기 때문이다. 또한 경로 또한 문제가 되었다. 레포에 backend, frontend 파일이 따로 있었기 때문에 이를 고려하여 eslint의 parserOptions의 project 값을 수정해야 했기 때문이다.

 

결국엔 storybook, jest에도 path alias가 잘 적용을 할 수 있었다. 이 과정도 팀 블로그에 작성하여 공유를 해야겠다. (벌써 써야 할 글이 3개이다.)

벌써 트러블 슈팅이...

스타일 컴포넌트의 카멜케이스... 왜 $를 붙여야만 에러가 안 날까 😭

케멀 케이스 에러

`isLoading`이라는 변수를 props로 전달하는 것에서 에러가 등장한다. 모두 소문자로 하거나 앞에 $를 붙여야 해당 에러가 해결된다. 하지만 과연 그렇게 해결하는 게 맞을까?라는 의문이 든다. 기존에는 전혀 보지 못한 에러이기 때문에 근본적인 문제를 해결하고 싶다. 아직 해결책을 찾아가는 과정이고 이를 해결할 수 있는 방법을 찾으면 정리해서 트러블 슈팅으로 정리할 계획이다.

---

7월 21일 2차 데모 데이

1차 데모 데이가 끝난지 엊그제 같은데 벌써 2주가 흘러 2차 데모 데이가 찾아왔다. 이번 데모 데이의 발표는 테오와 룩소가 맡게 되었다. 때문에 자연스럽게 다음 데모 데이 발표는 내가 하기로 결정되었다. 이거마저 떨리네

 

2차 데모 데이까지의 목표는 사용자들이 하루 스터디 서비스를 실제로 사용할 수 있을 정도로 개발을 하고 배포를 하는 것이다. 하지만 이는 완벽하게 끝내지 못하였다. 대신 새롭게 바뀐 기획안에 대한 설명, 하루 스터디의 핵심 가치와 CI/CD 구축한 내용 그리고 완벽하진 않지만 현재까지 배포된 하루 스터디를 발표하였다.

 

확실히 1차 데모 데이 때보다 서비스의 핵심가치를 전달할 수 있었기 때문에 1차 데모 데이보다 좋은 피드백을 받을 수 있었다. 다만, 앞으로 추가로 기획한 기능에 소켓이 필요한데 이에 대해 '반드시 필요한가?'라는 피드백에 대해선 앞으로 팀원들과 이야기를 나누어 봐야 할 듯하다. 굳이 소켓이 아니더라도 다른 방법으로 스터디 동기화를 할 수 있는 방법에 대해 찾아보고 적용해 봐야겠다.