안녕하세요 개발이 취미인 고등학생 입니다. 기술적인 오류나 개념상의 문제점은 댓글로 알려주시면 감사하겠습니다 😁
사건의 발단
6개월간의 애플뮤직 무료체험이 끝나고...
8900원을 내기 싫어 음악 플레이어를 만들기로 결심했다.
라이트 유저인데 음악 앱에 매달 8900원씩 지불하는건 낭비라고 생각한다. 1년동안 구독한다면 106,800원이니 말이다. 따라서 간단하게 듣는 음악만 다운로드 해놓고 재생하기만 하면 무려 10만원 이상을 절약할 수 있다. (절약의 신)
그.러.나 대부분의 아이폰 유저들은 공감하겠지만 아이폰은 음악 재생이 정말 불편하다. 음악을 재생하기 위해서는 아이클라우드를 통해 파일을 업로드해야 하는데, 매번 컴퓨터와 케이블을 이용해서 업로드하기 때문에 참으로 번거롭다. 다행스럽게도 아이폰에는 파일 앱이 있어서 다운로드 시 파일에 저장하기만 하면 약간의 귀찮음만 제외하면 빠른 재생이 가능하다.
파일 앱에서 재생하기 위해서는 앱 클릭 후 폴더를 연 다음 음악을 클릭하고 재생 버튼을 눌러야 한다. 하지만 매번 이런 식으로 음악을 들으니 조금 더 편하게 음악을 감상할 수는 없을까 하는 고민이 들었다. 더군다나 6개월 동안 애플뮤직으로 천국을 맛본 나에게 있어서 다시는 예전 방법으로 회귀하고 싶지는 않았다.
(이렇게 재생하고 있었다..)
그래서 필요한 기능은?
음악 업로드, 앨범 선택, 백그라운드 재생 딱 이 정도다. 앨범을 생성하고 해당 앨범에 음악을 업로드한 다음 음악을 재생하기만 하면 된다. 이 같은 기능을 구현하기 위해 SPA와 PWA와 Web Components를 사용해서 빠르게 필요한 부분만 구현할 수 있었다.
1일차: 기본 구성
깃허브 레포지토리를 만들고 코드를 오픈소스로 공개했다. 오픈소스 프로젝트의 장점은 코드가 공개되어 있으니 아무래도 신경 써서 개발한다는 데에 의미가 있다. 누군가 내 더러운 코드를 밟지 않길 바라는 마음에서..
Node 기반으로 기본적인 프로젝트 구조를 잡았다. 특히 이번 프로젝트의 기술적 목표인 '프레임워크 의존도 낮추기' 를 실현하기 위해 추가적인 프론트엔드 프레임워크를 사용하지 않고 SPA를 구현했다. 물론 성능 면에서나 개발 효율성 면에서는 프레임워크를 사용하는 게 월등할 수는 있겠으나 큰 프로덕트를 개발하는 게 아니기 때문에 도입을 고려하지 않았다.
History API와 더불어 기능 구현 측면에서는 많은 블로그를 참고하면서 개발했다. 글 하단에 링크가 첨부되어 있으니 관심있는 분들은 참고하시길 바란다.
2일차: 환경 구성
어떤 데이터베이스를 선택할지 고민한 끝에 sqlite3를 사용하기로 했다. MySQL을 사용하기에는 가벼운 프로젝트 취지에 맞지 않아 패스했고 sqlite3가 파일 기반 저장소라 불편함이 없어서 선택하게 되었다. 또한 반복되는 디자인 코드는 웹 컴포넌트로 묶고, 웹팩 또한 적용했다. 처음에는 웹 컴포넌트로 개발하는데 HTML 구조를 파악하기 어렵다는 점에서 우려했었지만 변수명만 잘 지어놓으면 오히려 수정이 용이하다.
개인적으로 큰 규모의 프로덕트를 개발하지 않는 이상 프레임워크에 종속될 필요는 없다고 생각한다. 특히 이번 개발을 통해 느꼈던 부분인데 프레임워크는 편하다는 장점도 있지만 그 내부에 동작하는 과정을 세세하게 알 수 없다는 점에서 오히려 성장을 저해할 수 있다는 생각을 하게 되었다. 마찬가지로 마이그레이션 과정과 개발 이후에 기술 부채가 쌓인다는 관점에서도 프레임워크를 굳이 사용해야 하는가에 의문을 가졌다.
내가 탈 프레임워크에 관심을 가지게 된 데에는 jQuery이 공이 컸다. 부트스트랩5부터 jQuery 지원을 중단한다는 소식을 들으면서 프레임워크의 의존하는데 좋은 건 아니구나 하는 생각이 들었다. 제이쿼리를 구글에 검색하면 삼성 SDS의 "제이쿼리(jQuery)를 아직도 사용하나요? - 제이쿼리의 현재와 미래" 라는 글이 나올 정도로 이젠 그 영향력이 점차 줄어들고 있다.
3일차: 앨범 기능 개발
앨범 CRUD는 쉽게 개발했다. 프론트엔드 개발 과정에서 이전에 구축해놓은 디자인 시스템의 도움을 많이 받았다. 반복된 코드를 줄이고 클래스로 같은 동작을 수행하는 함수를 묶어 직관적인 개발을 가능하게 했다.
4일차: 음악 업로드
Multer 모듈을 사용해서 업로드 로직을 구성했다. 업로드 로직은 미들웨어로 분리한 다음 컨트롤러에서 업로드 정보를 데이터베이스에 추가하는 방식으로 개발했다.
이때까지만 해도 백엔드 함수 로직을 개발할때 export async function로 하나하나 export 해주었는데 이번 프로젝트를 기점으로
const musicController = { ... }; export { musicController }; 로 변경하게 되었다. 이에 보다 직관적으로 코드를 파악할 수 있다는 점에서 개발시간 또한 단축할 수 있었다.
 Before |  After |
|---|
5일차: 음악 재생 + 배포 + PWA
백그라운드 음악 재생은 Audio 클래스로 쉽게 만들 수 있다. 사실 관건은 배포인데 이전에 개발한 자동배포 시스템을 활용해서 빠르게 배포할 수 있었다. 이 프로젝트의 배포를 위해 도커 볼륨 기능을 새롭게 추가했는데, 덕분에 도커 컨테이너 휘발성 파일 저장소 걱정 없이 개발하게 되었다.
잠깐 동안 이 자동 배포 시스템을 소개하자면, CI/CD 툴과 흡사하다. 물론 테스트 기능이 없기에 CI/CD라고 부를 수는 없지만 도커 배포 기능과 자동 lets encrypt SSL 적용을 지원한다. (+ 도메인 적용) 덕분에 다른 서비스 간 독립적인 환경을 구성하며 배포에 속을 썩일 필요도 없다.
진작에 해결한 배포 문제를 뒤로하고 PWA구성을 마무리했다. PWA 지원 여부는 구글 크롬에서 제공하는 lighthouse에서 편하게 확인할 수 있었고 공식 문서가 잘 정리되어 있어 개발하는데 큰 문제는 없었다.
최종 결과
최대한 깔끔한 디자인을 추구했다. 불필요한 기능과 디자인 요소를 줄이고 한 눈에 알아볼 수 있도록 직관적인 UI를 개발하게 되었다.
https://github.com/Team-DeVent/devent-musicplayer
깃허브 주소
참고 자료
(SPA 라우팅) https://kdydesign.github.io/2020/10/06/spa-route-tutorial/
