프로젝트

S-HOOK - 좋은 서비스를 위한 길 [Week 5 ~ 6]

Creative_Lee 2023. 8. 5. 22:15

눈 깜짝할 사이 시간이 흘러 3차 데모데이를 진행했습니다.

이번 스프린트에서는 어떤 일이 있었는지 한번 돌아봅시다!


1. 이전 데모데이 피드백 반영

이번에도 역시 지난 데모데이 피드백을 반영했습니다.


1-1. 플로우에 혼동이 생기는 여러 요소

2차 데모 플로우에서는 사용자에게 만족감을 주려던 목적으로

등록 후 자신이 등록한 킬링파트의 순위에 따른 메세지를 보여주거나, 득표수를 보여주었는데요!

 

이에 대해

'등록과 공유라는 핵심 가치외의 부가적인 가치를 제공하기 위한 수단이 플로우에 혼동을 준다'는 피드백을 받았습니다.     

또한 '등록과 투표라는 용어의 혼동이 있다'는 의견도 있었어요.

이후 만족감이라는 가치가 현 상태의 S-HOOK에서 고려되어야 하는 가치인지 깊이있게 생각해 보았습니다.

회의 끝에 핵심 가치 관련 기능이 모두 개발 된 이후에 만족감과 같은 부가 가치를 고려하기로 결정했습니다.

 

최종적으로 위 사진처럼 모달에서 애매한 만족감을 주는 문구를 삭제하였고, 용어를 통일했습니다.

 


2. 스프린트 진행

 

 

이번 스프린트에서는 크게 다음과 같은 작업을 진행했습니다.

  • 테스트 전략 수정 및 자동화
  • 웹접근성 개선 및 개발
  • AWS EC2 + Nginx 환경에 배포

2-1. 테스트 전략 수정

프론트 파트는 크게 유닛테스트와 단일 컴포넌트 테스트를 진행했었습니다.

매 스프린트가 진행되면서 기획과 디자인의 변경이 이루어 졌는데요!

이에 따라 컴포넌트 수정이 불가피했고, 자연스레 테스트 케이스에 대한 수정 리소스가 증가했습니다.

배보다 배꼽이 더 큰 상황이 발생한거죠.

 

이런 문제점들을 해결하기 위해 테스트 전략 회의를 진행했고, 단일 컴포넌트의 기능테스트를 작성하지 않기로 했습니다.

또, 이런 단일 컴포넌트들이 여러개 조합되어 동작하는 기능에 대한 통합 테스트를 추후 고려해보기로 했습니다. 


2-2. 테스트 자동화

테스트를 통과하지 못했거나, 빌드가 실패하는 작업물을 merge하면 안되겠죠.

이런 과정들을 매번 수동으로 확인하는 것은 매우 귀찮은 일입니다.

 

 

 

이번 스프린트에서는 merge를 위한 코드 확인 과정을 자동화했습니다.

PR을 작성하면 github actions에 등록한 CI task가 돌아가면서 

Lint → 테스트 케이스 → build 순으로 확인합니다. 이 중 하나라도 실패한다면 수정 후 재시도 하도록 설정했습니다.

이제 코드 병합 과정을 보다 간편하고 안전하게 진행할 수 있게 되었습니다!


2-3. 웹접근성 고려

다양한 사용자를 위해 접근성도 개선했습니다.

제일 기본적인 접근성 관련 속성을 적용하고 시멘틱하지 못한 태그를 수정했어요. (현재 진행형입니다.__.)

여기에 저시력자를 위한 명도 대비 기준을 준수하기 위해 프로젝트의 primary 컬러를 조정했어요.

프로젝트가 다크모드 기반이라(검정 배경 흰 글씨) 명도 기준을 만족하기는 어렵지 않았습니다.

 

접근성 관련 학습을 하면서 접근성이 장애를 가진 사용자만을 위한 것은 아니라는 것을 알게 되었습니다.

예시로 마우스 없이 키보드만 사용하는 유저는 focusable한 요소가 없는 서비스를 사용하지 못하고 떠나버린다는 거죠.

여태까지 접근성 관련 개선을 미뤄왔던것을 반성하는 계기가 되었습니다. 


2-4. 개발

이번 스프린트는 투표와 공유라는 핵심 가치가 제공되는 상태에서

더 다양한 노래를 제공하고, 킬링파트를 소비하도록 하는것이 중점이라고 생각했습니다.

따라서 '인기있는 노래를 빠르게 접하고 소비할 수 있도록 하자' 를 목표로 했어요.

 

 

 

이에 따라 위와 같은 기능을 도출하고 개발했습니다.

 


2-5. AWS EC2 + Nginx 환경에 배포

프론트엔드 배포관련 설정을 팀 협업으로 진행했습니다.

 

빌드 결과물(정적 파일)을 EC2 내부에 위치시키고 이를 Nginx가 서빙하도록 했습니다.

EC2는 무엇인지, 배포 과정 중에 Nginx는 어떤 역할을 수행 하는지 이해할 수 있게 되었습니다.


3. 데모데이 및 피드백

이 모든 내용을 담아 3차 데모데이를 진행했습니다.

서비스 플로우 관련 피드백이 주를 이뤘는데요! 정리하면 다음과 같습니다. 

 

- 특정 기능을 귀찮다고 느낄 사용자들에게 확실하게 소비시키려면 어떻게 해야할지 고민해보기
- 이미 갖추어진 컨텐츠를 더 많이 소비하게끔 개선하기
- 서비스 이용이 더 편하게, 더 자연스럽게  개선하기

 

이번에 받은 피드백을 통해 다음 4차 데모데이에는 사용자 경험을 위주로 개선해야겠습니다. 


4. Week 5 ~ 6  돌아보기🙂

웹 표준, AWS, Nginx, CI, 개발까지..!

머리속으로 들어오는 정보가 많아 꼭꼭 눌러 담느라 쉽지 않았던 3번째 스프린트였습니다.😅

한편으로는 그만큼 성장한거라고 생각합니다.

 

또, 한정된 시간안에 서비스를 개발하는데 있어서 기존의 코드를 개선하는 일새로운 기능을 개발하는 것.

둘을 어느정도 비율로 가져가야 할지 깊게 생각해보기도 했네요.

(이 부분에 대해서는 느낀점이 많아 리팩터링 과정과 더불어 별도의 포스팅으로 다뤄보겠습니다.)

 

 

 

Week 5~6 회고는 여기까지 입니다.

4차 데모 데이 내용으로 다시 만나요!