<aside> ⚙ 뮤팟에서 백엔드 개발을 맡고 있는 이노입니다~! 정중하게 인사드립니다. 🙇

</aside>

  Bing AI로 생성된 이미지 입니다.

Bing AI로 생성된 이미지 입니다.

적응하는 햇병아리 이노 🐣


작년 2023년 1월 초에 입사하여 다시 1월이 돌아왔다. 처음 입사했을때도 지금처럼 추웠는지 기억이 잘 안난다. 아마도 새로운 곳이니 긴장을 하느라 추운줄도 모른 것 같다. 🤔

나는 백엔드 파트를 맡은 개발자로 뮤팟에서 일을 시작하게 되었다. 사실 백엔드만 전문적으로 맡아서 개발을 해본 적이 없다. 그렇지만 스스로 개발 분야를 가리지 않기에 어떤 파트를 맡아도 열심히 할 자세가 있었다. 기존에는 SPA*(Single Page Application)* 기반 프론트엔드 개발에 익숙했고, 뮤팟은 Ruby on Rails(이하 RoR)라는 익숙하지 않은 언어와 프레임워크를 사용하여 내가 경험한 개발 환경과 차이가 있었다. 그리고 프론트엔드 파트는 .erb 라는 확장자 파일로 Rails **에 의해 HTML 파일이 동적으로 생성되는 환경이었다. 물론 RoR이 전통적이고 정석적인 웹 서비스 개발 방식이다. 또한, JavaScript로 DOM을 제어할때는 JQuery를 사용하고 있어서 이 부분 역시 적응해야했다.

제일 처음에 수행한 일은 서비스 되고 있는 기능이 아닌 관리자가 사용하는 페이지에서 특정 기능이나 통계를 구현하는 일이었다. 잘 모르는 Ruby on Rails의 ActiveAdmin, ActiveRecord를 이용해 특정 기능을 구현하고 UI를 표시했고 SQL과 ORM으로 통계를 가져와서 처리했다. 그리고 Chart.js 라이브러리를 V2.9.4에서 V4.1.1으로 업데이트를 진행하면서 바뀐 부분을 수정하기도 하였다. 처음에 부담이 적은 관리자 기능부터 구현하니 뮤팟이 사용하는 기술에 대한 이해도가 생겼고 개발에 대한 즐거움도 가득했다. (그러나 이 즐거움은 추후 변하기 시작한다. 😂 )

음악을 정리하는 이노 🎶


이제 뮤팟 서비스에서 wav 파일을 제공해야하는 일이 다수 발생하여 기존 곡과 신규 곡에 wav 파일을 추가해야했다. 기존에는 mp3 파일만 AWS S3에 업로드 되어있었고, 이제 기존곡의 mp3 파일과 동일한 음악을 가진 wav 파일을 찾아야 했다. 다행히 3000+여곡은 엑셀 시트로 잘 정리가 되어 있어서 백업 하드에서 잘 찾아 업로드 배치 코드를 작성해서 S3에 올렸다. 그러나 고통은 나머지 곡에서 시작한다. 엑셀 시트에 정리되어 있지 않은 파일들이 간혹 이름이 다르거나, 버전 표기가 다르거나, 또 파일이 없는 경우 등으로 처음에는 백업 하드에서 폴더를 이리저리 찾아가며 음악이랑 숨박꼭질을 했다.

“ 음악아 어디있니 ? ” 🧐

  넷플릭스에서 가져왔습니다.

넷플릭스에서 가져왔습니다.

백업 하드에서 파일을 이리저리 찾다가 일종의 패턴을 발견하고는 바로 코드를 짜서 곡을 찾아 업로드를 진행했다. 그리고 평균적으로 3GB 정도되는 ZIP 파일을 압축해제하고 파일을 찾는건 너무 느려서 압축을 해제하지 않고 파일이름을 검색할 수 있는 방법을 찾아서 코드를 작성해보기도 했다. 이러한 wav 업로드 작업을 3주 동안 했는데 스크립팅을 정말 많이 했다. 이때 루비라는 언어가 스크립팅에 매우 유리한 언어로 느껴져서 이 언어를 좋아하게 되는 계기가 되기도 했다. 결국 300+여곡 정도는 손으로 찾아서 업로드를 했고 또 뮤팟 초창기에 업로드된 곡들은 wav 파일이 존재하지도 않아서 결국 mp3 파일을 wav 파일로 변환하여 구색만 맞추기도 했다. 그래도 결과적으로 기존 모든 곡에 대한 wav 파일을 업로드하는 긴 작업을 마무리했다.

뮤팟을 갈아엎는 이노 💣


  Bing AI로 생성된 이미지 입니다.

Bing AI로 생성된 이미지 입니다.

뮤팟에 익숙해질때 쯔음인 3월 Ruby on Rails에서 Node.js 기반으로 마이그레이션을 진행한다는 말을 케빈으로부터 들었다. 굉장히 갑작스러웠던 이유는 이제 Rails에 적응하고 RoR을 더 심층적으로 공부 해볼 참이었기 때문이다. 아쉬움을 뒤로 한채 케빈이 먼저 Next.js를 기존 Rails 프로젝트에 모노레포 방식으로 구성을 하였고, 나는 Next.js만으로 서버를 구성하기에는 자유도와 Node.js의 서버측 라이브러리와의 통합이 쉽지 않을 것 같다고 느꼈다. 미디엄에서 좀 찾아보니 Next.js에 커스텀 서버로 Express.js를 붙여서 사용하는 사례가 있었고 케빈과 상의해서 Express.js를 연동하기로 했다. 몇 번의 삽질 끝에 매끄럽게 Next.js와 Express.js를 연동시켰다. 🙆

하지만 단순히 Express.js만 연동했다고 끝이 아니었다. 제일 먼저 로그인과 회원가입을 구현 해야했는데 Ruby on Rails에는 존재하지만 Express.js에는 존재하지 않는게 많았다. 그냥 거의 없었다. Express.js는 단순히 HTTP 요청과 응답, 미들웨어를 손쉽게 다룰 수 있는 인터페이스만 제공하는 작고 가벼운 라이브러리이기 때문이다. 그래서 데이터베이스와의 쿼리를 쉽게 다룰 수 있는 ORM 선정, 기본적인 웹 보안에 필요한 라이브러리, Bigint를 JSON 으로 바꾸어주는 라이브러리 등 Rails에서는 그냥 하면 되던 기능들이 Node.js와 Express.js에서는 전부 라이브라리들을 찾아서 구현해야하니 힘든 점이 많았다. 그리고 타입 안정성이 프로젝트에 미치는 영향을 그간 경험에서 크게 느꼈기에 TypeScript 도입을 팀에게 완고하게 말했고 이를 적용하는 과정에서 Next.js와 Express.js에서 서로 동일하게 tsconfig를 맞추는 과정도 고통스러웠다.