[레벨 3 회고] 하루스터디 3주차 회고

벌써 하루스터디 협업을 시작한지 3주가 지났습니다. 시간이 참 빠르다고 느껴지는데 이번에도 어김없이 회고를 하면서 무엇을 했는지, 앞으로는 무엇을 해야하는지를 작성해보겠습니다. 🥸

 

서비스에서 도구로

사실 이번주에는 대대적인 변경 작업이 있었습니다. 결론부터 말씀드리면, 1차 데모데이때 설명드렸던 기능들을 거의 90% 이상 갈아엎었습니다. 서비스 정체성은 유지하면서 기능은 전부 대체했는데요, 왜 그렇게 되었는지를 아래에 작성하고자 합니다.

 

하루스터디의 모토는 '짧은 주제의 스터디를 짧고 빠르게, 부담없이' 입니다. 그렇기에 제가 초기에 기획했던 모델은 스터디 모집 서비스였습니다. 짧은 주제의 스터디(쿠키와 세션 스터디 등)는 기존 스터디 패러다임과는 전혀 다르니 용기있게 짧은 주제의 스터디를 개설할 '장'을 마련해줘야 한다고 생각했기 때문입니다.

 

하지만 서비스를 계속 구체화하면서, 저를 포함한 팀원들은 모두 무언가 애매하다는 느낌을 많이 받았습니다. '우리 서비스가 기존의 서비스와 다른 점은 무엇일까?', '기존 서비스로 충분히 대체할 수 있지 않을까?' 와 같은 고민을 정말 많이 했습니다. 그렇지만 명확한 해답이 나왔던 적은 없었습니다. 또한 모집 기능을 서비스의 핵심 가치로 내세웠을 때 사용자가 유익한 경험을 할 것 같지도 않았습니다. 

 

그래서 팀원들과 심사숙고 끝에 기획을 전환하기로 결심했습니다. 그 과정에서 반대 의견도 있었는데(사실 저도 반대였습니다), 결국 기획을 변경하는 쪽으로 조율이 되었습니다.

 

뜨거운 토론

새로운 하루스터디는 모집 기능 + 스터디룸 + 프로필 기능을 다 날려버리고 '짧은 스터디를 진행하기 위한 도구' 로 탈바꿈할 예정입니다. 만약 저희 서비스를 사용하는 사람이 많아진다고 한다면, 그 시점에서부터는 모집 기능을 고려해봐도 좋을 것 같습니다. 하지만 당장은 고려하지 않을 예정입니다.

 

실제 사용자 되어보기

하루스터디는 짧은 스터디를 진행하는 것을 돕기 위해 '뽀모도로 템플릿'을 제공합니다. 뽀모도로란, 집중력 향상이 목적인 하나의 학습 방법론입니다. 25분 일하고 5분 쉬는 것을 4번 반복하여 2시간이 지난 다음에는 30분간을 쉬어주는 학습 방법으로, 이미 효율성이 검증된 방법 중 하나입니다.

 

하루스터디에서는 이런 뽀모도로 템플릿을 이용해서 스터디를 다른 사람들과 진행하게 되는데, 이런 스터디 방식이 효율적인지도 검증되지 않은 채 사용자에게 전달되면 안될 것 같아 팀원들 모두 월요일 저녁에 남아 뽀모도로 스터디를 진행했는데요. 스터디가 끝난 뒤, 모든 팀원들이 '이 스터디 방식 좋은데?' 라고 이야기 할 정도로 뽀모도로 스터디는 효율적이었습니다.

 

이렇게 직접 스터디를 진행하면서 사용자의 입장이 되어 보니, 보다 사용자 관점에서 서비스를 상상할 수 있어서 좋았던 것 같습니다. 그리고 직접 하루스터디의 흐름을 맛보고 나니, 빨리 하루스터디를 배포하고 싶다는 생각도 들었습니다 😄

 

 

브랜치 전략 + 기능 목록 도출 + API 설계

그리고 이번주에는 개발을 위한 준비단계를 많이 진행했던 것 같습니다.

 

일단 브랜치 전략을 구상했는데요, 하루스터디의 브랜치 전략은 Gitlab flow에서 hotfix 브랜치가 추가된 방식입니다(Git flow에 보다 가까운 것 같긴 하네요). 아직 해당 flow에 익숙하지는 않아서 개발할 때 유의해야 할 것 같습니다. 실수로 브랜치를 날리거나 한다면 큰일이니까요.

 

그리고 기능 목록 도출 및 API 설계를 진행했습니다. 이 과정에 있어서 제일 힘들었던 부분은 기능이 이전까지 진행했던 미션들과는 비교가 안될 정도로 볼륨이 크다는 것이었습니다. 따라서 문서 관리하기도 어려웠고, 도메인 용어가 계속 혼용되는 바람에(멤버를 유저로 쓴다든가) 어려움을 겪기도 했습니다.

 

API 설계도 생각보다는 쉽지 않았는데요. REST에 대한 테코톡 발표도 맡았던 적이 있고, 나름 자료조사도 철저하게 했다고 자부하지만 실제로 실무 관점에서 API를 바라보았을 땐 포기해야 하는 부분이 꽤 있었습니다. 스터디 진행 특성 상, 행위를 표현하는 API가 생길 수 밖에 없어서 URI에 어쩔 수 없이 동사를 넣었던 기억이 납니다. 물론 컨트롤 URI가 항상 피해야하는 대상은 아니지만, 자원으로 표현할 수 없다는 것이 참 아쉬웠습니다.

 

 

 

데이터베이스 설계 + 엔티티 설계

기능 목록과 API 설계가 진행되고 난 뒤, 목요일부터 데이터베이스 설계를 시작했습니다. 사실 전통적인 Layered Architecture 방식의 개발은 처음인데(이전까지는 도메인 먼저 설계했습니다.. 항상) 나름 새롭고 재밌었던 것 같습니다.

 

그렇게 도출된 ERD를 기반으로 엔티티도 설계했는데, JPA를 쓰니까 도메인 엔티티 구조와 테이블 구조가 동일해지는 것 같아 사실 어색함이 조금 많습니다. 레벨 1, 레벨 2에서는 '도메인과 테이블의 강결합이 유지보수하기 어려운 소프트웨어로 이어질 수 있다' 라는 철학을 갖고 있었는데, 앞으로 어떤 시나리오가 나올지는 조금 지켜보고자 합니다. 궁금하긴 하네요!

 

 

되돌아보기

체력 관리를 더 잘해보자!

3주차는 체력 관리를 제대로 하지 못했던 것 같습니다. 피곤한 날이 대부분이었고 커피 + 핫식스로 연명하는 날이 대부분이었습니다. 잠은 충분히 많이 자는 것 같은데, 앞으로 체력관리가 중요할 것 같다는 생각이 듭니다. 가벼운 운동이라도 시작해볼까(걷기 등) 하는데 시간적 여유가 없어서 고민이 되긴 합니다.

 

시간을 보다 잘 쓰자!

이제 알고리즘 + CS를 병행하느라 시간이 많이 없는데, 어떻게하면 시간을 효율적으로 사용할 수 있을지에 대한 전략도 필요해보입니다. 이런 생각이 들어서 얼마 전 TO-DO 리스트 어플리케이션을 깔았는데, 매일 목표를 설정하니 효과가 좋았습니다. 이런 학습 보조수단을 조금 더 찾아봐야겠습니다.