shook

많은 개발자들이 새로운 서비스를 만드는 것을 좋아하는 만큼 좋은 팀 문화에서 일을 하는 것을 고대합니다. 이번 팀 프로젝트를 진행하기에 앞서서 팀원들과 함께 건강한 팀에 대해 이야기를 나누고 우리 팀만의 문화를 정립하는 시간을 가졌습니다. 좋은 팀 문화를 생각하기에 앞

프로젝트를 진행하면 많은 것들을 정해야 하고 모든 과정이 중요하지만 그 중에서도 가장 중요하다고 생각하는 것은 팀원들과 주제에 대한 생각의 Sync를 맞추는 것이라고 생각합니다. 그 이유는 사람들은 같은 것으로 보아도 다르게 생각하기 때문에 같은 주제에 대해 생각하는

이번 시간에는 프로젝트 개발에서 앞서서 git 브랜치 전략을 정하는 시간을 가졌습니다.git branch 전략은 프로젝트의 개발 진행 흐름을 효과적으로 관리하기 위한 work-flow입니다. 사실 서비스를 하나의 브랜치에서 작업을 하고 배포를 진행해도 되지만 여기서 발

7월 7일(금)에 2주간 진행했던 사항을 코치님 및 크루들에게 설명하는 데모데이 시간을 가졌습니다. 이번 데모데이는 지금까지 개발한 사항을 공유하는 시간은 아니었습니다. 팀이 처음 구성된 만큼 프로젝트의 핵심가치 및 팀문화와 같이 개발에 본격적으로 들어가기에 앞서서 저

스프링 부트의 버전을 정하는 것이 모든 팀들에게 핫 포테이토 였습니다. 그 이유는 스프링 3.X 버전은 자바 17버전 이상부터 지원하기 때문입니다. 즉, 팀원들 모두 익숙하게 이용했던 자바 11버전을 이용하지 못하게 되는 것이었습니다. 그럼에도 이번 프로젝트에서는 3.

팀 작업을 진행하면서 각자 맡은 부분이 생기고 이를 나누어서 작업을 진행하다보니 이를 통합(통합 속에는 빌드를 하는 과정과 테스트를 하는 과정이 포함됩니다.)하는 과정이 필요했습니다. 이를 수행하기 위해서 CI(Continuos Integration)작업이 필요했고

시가이 지났지만 2차 데모데이를 회고해 보려고합니다. 2차 데모데이가 진행된 날은 7/21이었습니다. ㅎㅎ…이번 데모데이의 핵심은 핵심 페르소나의 변경과 더불어 사용자가 직접 킬링파트를 등록하고 사람들에게 공유할 수 있는 기능을 소개하는 시간이었습니다.먼저 1차 데모데

사용자 UX 글쓰기 이번 시간에는 사용자에게 우리 서비스를 설명하는 글을 써보는 시간을 가져보았습니다. 글을 써보는 목적은 우리의 서비스를 나타내보면서 화면을 보여주지 않고도 사용자에게 매력적으로 다가올 수 있는 서비스인지를 파악해보는 시간을 가지는 것입니다. s-

문제 사항 저희 서비스는 JPA를 이용하고 있습니다. Song의 상세페이지를 조회하게 되면 KillingPart에 대한 정보와 KillingPart의 좋아요 수가 필요한데 이 때 의도하지 않았던 Query가 발생하는 문제가 발생했습니다. 현재 위의 사진과 같이

저희팀 프론트 크루들 중에 ec2를 이용하는 것에 익숙하지 않은 크루들이 있어 프론트앤드 크루들과 함께 서비스 환경을 구축하는 시간을 가졌습니다. 현재 저희 팀은 3개의 인스턴스를 이용할 수 있는 상황이었고 이를 통해서 운영환경과 개발환경을 구축하고자 했습니다. (여

3차 데모데이 시간이 돌아왔다 사실 이 글을 쓰기 시작한 것은 8월 7일인데 업로드 하는 시간이 좀 걸린 것 같습니다. 3차 데모데이는 나와 프론트 크루인 도밥이 함께 진행했습니다. 오랜만에 사람들 앞에서 이야기를 하려고 하니 많이 떨렸습니다.3차 데모데이의 핵심은 프

shook 서비스에서 사용자의 편의성을 높이기 위해서 노래를 조회하는 방법에 변화를 주었습니다.기존 서비스에서 사용자가 여러 노래의 킬링파트를 듣기 위해서는 다음과 같은 일련의 과정을 거쳐야 했습니다.위의 그림과 같이 사용자는 노래 선택 → 킬링 파트 듣기 → 노래 목

shook 서비스에서 인증 기능을 도입하기로 했습니다. 인증 과정이 추가됨에 따라 서비스에 진입 장벽이 생긴다고 팀원들 모두가 생각했습니다. 하지만 저희 서비스에서 신뢰있는 킬링파트 정보를 수집하는 것과 추후에 마음에 드는 킬링파트를 아카이빙 할 수 있는 기능이 필요하

S-HOOK 서비스의 핵심은 사용자들이 노래의 킬링파트를 빠르게 접할 수 있다는 것입니다. 이는 서비스 회원(로그인을 한 사용자) 뿐만아니라 비회원 모두 이용할 수 있는 기능이어야 합니다. 이 부분에서 발생했던 문제점이 있었습니다. 이는 같은 요청(노래 상세페이지)에

현재 S-HOOK 서비스는 유튜브 쇼츠와 인스타 릴스와 같이 스와이프를 통해 노래 듣기 기능의 편의성을 높였습니다. 스와이프를 구현하기 위해 사용자가 하나의 노래를 클릭하면 좋아요 개수를 기준으로 사용자가 선택한 노래 앞뒤 10개를 미리 가져와야 했습니다.사용자가 특정

이번 s-hook 프로젝트에서 소셜 로그인을 진행하는 과정에서 refreshToken을 보내줄 때 cookie를 활용해서 전송해주었습니다. 이 과정에서 springboot 내 cookie를 활용하는 법에 대한 학습이 필요했고 이를 정리하고자 합니다. Cookie란?

팀원들과 현재 저희 서비스의 시스템 구조도를 보면서 대량의 요청에 대해서는 어떤 문제점이 발생할 수 있는지 파악하고 이에 대해서 어떻게 확장할 수 있을지에 대해서 고민하는 시간을 가졌습니다. 현재 S-hook의 운영서버 시스템 구조도는 아래와 같습니다. 현재 서비스

소셜 로그인(OAuth) 도입기 글에 이어서 작업한 내용으로 확장성 있는 소셜 로그인 시스템을 구축한 과정에 대해서 정리하고자 합니다.이 코드는 당시 구글 소셜 로그인을 구축할 때 구현할 코드입니다. 이후 카카오 소셜 로그인을 추가하려다 보니 기존 구조에 문제가 있음을