처음 떠올린 아이디어는 "음악 일기 앱" 이었다.
매일 일기는 쓰고 싶은데, 글 쓰는 걸 힘들어하는 (나 같은) 사람들을 위한 일기 앱이 있으면 좋겠다고 생각했다. 하루를 가장 쉽게 기록할 수 있는 수단이 뭐가 있을까 생각했는데, 그 순간조차도 에어팟을 꽂고 있었기 때문에 자연스럽게 음악으로 하루를 기록하는 컨텐츠가 떠올랐다.
본격적으로 앱 기획을 하려고 했는데, 음악 저작권을 간과하고 있었다. 이전에도 음악 관련 앱을 만들려고 했다가 저작권 이슈로 리젝을 당해서 앨범 커버를 모두 내렸다는 분이 있었다는 얘기를 듣고, 출시 자체가 불가능할 수도 있겠다는 불안함이 들었다. 다행이 애플에서 제공하는 api를 사용하기 때문에 큰 문제가 되지 않을 것이라는 피드백을 받았고, 마음을 좀 내려놓을 수 있었다. Spotify api와 Apple Music api 중 고민했는데, 후자를 선택한 것이 아주 다행이었다.
단순히 며칠 개발해서 만들어 내는 사이즈가 아니기 때문에 개발 전 반드시 계획을 잡고 시작해야겠다고 생각했다. 원래도 성격상 계획을 잡고 시작하는 것을 선호하기 때문에 큰 문제는 없었지만, 공수산정까지 해본 경험이 별로 없어서 시간을 고려하는 점이 쉽지 않았다. 이게 몇 시간 걸릴지 예상하는 것도 쉽지 않았고, 내가 몇 시간 동안 두드렸는지 체크하는 것도 쉽지 않았다. 그래서 분명 초반에는 시간도 열심히 기록했지만, 나중에는 할 일만 정리해두고 넘어갔다... 공수산정 하는 과정도 익숙해지도록 많이 연습해봐야겠다고 생각했다.
앱의 기능 자체가 크게 복잡하지 않기 때문에 구현하는데 엄청나게 큰 문제는 없었다. 2달동안 들은 수업내용으로 충분히 커버할 수 있는 정도의 자잘한 이슈들은 물론 있었지만, 에러를 찾기 위해 며칠동안 고민할 정도의 이슈는 없었다.
오히려 로직을 구상하는 과정에서 시간이 정말 많이 소요되었다. 개발 전, 웬만하면 로직을 완벽하게 짜고 개발을 시작해야겠다는 마인드가 있었다. 장단점이 있긴 했지만, 덕분에 구현 과정에서는 큰 걸림돌이 없었다. 약간씩 문제가 보이더라도 미리 구상해 둔 로직 그래프를 보고 금방 원인을 찾을 수 있었다.
이 부분에서 약간의 아쉬움이 있다면, 처음으로 만드는 앱이기 때문에 내가 너무 겁을 먹었던 것 같다. 좀 더 욕심내서 고난이도의 기능을 구현하려고 했다면, 더 의미있는 경험을 할 수 있지 않았을까 생각이 들었다.
개발 전 열심히 끄적이던 로직
이번에 사용한 대표적인 라이브러리는 FSCalendar, FSPagerView, Charts이다. 라이브러리를 사용해 본 경험이 많지 않아서 처음엔 구조를 이해하는 데 시간이 꽤 걸렸다. 확실히 수업에서 알려주시는 내용을 받아 적는 것과는 차원이 달랐다.
FSCalendar와 FSPagerView에서는 직접 커스텀 셀을 만들어야 하는 상황이 있었는데, 이 과정에서 시간이 정말 많이 걸렸다. 막상 결과 코드는 아주 간단해져서 약간의 억울함이 있다..
Charts에서는 내가 원하는 그래프 형태가 없어서 직접 UIBezierPath를 이용해 Bar graph를 구현했다. 한땀한땀 그렸던 그 과정은 정말 잊지 못할 것 같다.
이 외에도 라이브러리에서 고정으로 제공하는 기능과 내가 원하는 기능이 서로 충돌할 때, 대처해야 하는 부분이 꽤 많았다. 그 과정에서 프로퍼티 재정의, 편의 생성자 등 평소에 사용해보지 못한 문법들도 많이 경험해보았다.
가장 새로운 경험은 역시 MusicKit 이다. 애플에서 제공하는 Kit 붙은 프레임워크를 처음 써보았는데, 다른 것들도 유용하게 사용할 수 있겠다는 생각을 했다. 모든 게 처음이었고, 한글 자료도 없어서 정말 힘들었지만, 끝나고 나니 그래도 가장 기억에 남는다. 덕분에 개발자 계정도 일찍 구매하고, WWDC 영상에 발도 들이게 해 준 고마운 친구다.
서버의 부재
프론트엔드 개발자 혼자 하는 프로젝트의 한계였다. 처음엔 Firebase를 이용해서 소셜 로그인 기능도 구현해보고, 서버 구조를 간단하게 만들어서 사용자들끼리 서로 일기를 공유할 수 있는 서비스를 만들고 싶었다. 하지만 현실적으로 기간도 너무 짧고, 지금 나에게 필요한 일에 집중하기로 했다. 애매하게 약간씩 공부해서 불안한 앱을 만드는 것보다, 확실하게 기능을 구현해서 버그 없는 앱을 만드는 것이 우선이라고 생각했다.
벼락치기 MVVM
프로젝트를 시작할 때만 하더라도 MVVM 구조가 너무 어색한 시기였다. 뷰컨트롤러에 모든 코드를 다 때려박는게 가장 편했던.. 어쨌든 프로젝트의 목표 중 하나가 MVVM 이었기 때문에 처음엔 최대한 역할별로 코드를 분리해가며 개발했지만.. 나중엔 기능 구현하는데 급급해서 제대로 지키지 못했다.
어느 정도 앱이 완성된 후, 한꺼번에 구조를 바꾸려고 하니까 정말 진짜 너무 힘들었다. 이럴거면 처음부터 제대로 할걸.. 하는 생각을 하루에 500번씩 했다. 또한 이미 서로 연결되어 있는 데이터와 UI를 다시 나누려고 하니까, 코드 자체가 깔끔하지 않고 더 억지스러운 코드가 되어버렸다. 수업시간에 배운 Observable이나 bind도 적절하게 사용하지 못한 것 같아서 더 아쉬웠다.
일을 미루는 걸 떠나서, 코드 구조를 처음부터 제대로 잡고 시작하는 게 얼마나 중요한지 새삼 느꼈다.
사용자 입장에서 부족한 기능
앱을 처음 기획할 때, "한 번 들어와서 오래 사용하는 앱"이 아닌 "매일 들어와서 잠깐씩 머무는 앱"을 만들고 싶었다. 그러다 보니 사용자 입장에서는 앱에 들어와서 그날 음악을 기록/수정/삭제 하는 것 밖에 할 수 있는 기능이 없었고, 대부분의 화면은 가공된 데이터를 보여주는 역할을 하고 있었다.
너무 단순하게 생각한 게 문제였던 것 같다. 앱 기능에 대한 기획이 많이 부족했던 점이 아쉽고, 이젠 업데이트가 남았으니까 추후 기능으로는 어떤 게 있을지 꾸준히 생각해봐야겠다.
통계라기엔 부족한 데이터
기록한 음악에 대한 데이터를 정리해서 통계 화면을 구현하였는데, 현재는 장르 데이터만 보여주고 있다는 점이 약간 부족한 느낌이 있다. 업데이트 때는 아티스트 관련 데이터로 의미 있는 통계 데이터를 만들어 낼 생각이다.
음악 플레이어 기능
운이 좋게도 이번 프로젝트에서는 api에서 제공하는 previewURL을 이용한 음악 재생 기능을 구현해보았다. 이번에는 아주 최소한의 기능만 이용했기 때문에, 미디어 재생 기능에 호기심이 생겼다. 재생목록을 만든다거나, 백그라운드 재생, 잠금화면 또는 위젯에서 재생 컨트롤 등 좀 더 심화적인 내용을 공부해보고 싶은 마음이 들었다.
패턴에 대한 공부
개발을 하면서 정말 자주 들었던 생각이 "이렇게 하는 게 맞나?" 였다. 기능적으로 작동하는 데에는 아무런 문제가 없지만, 코드를 읽어보았을 때 깔끔해 보이지는 않았다.
특히 가장 많이 사용한 방법이 싱글톤 패턴이었는데, 서로 다른 곳에서 동시에 이벤트가 발생해야 할 때 무조건 싱글톤으로 데이터를 만들었다. 여러 곳에서 같은 데이터를 공유하는 방법으로는 싱글톤 패턴밖에 기억이 나지 않아서 계속 사용했는데, 내가 적절하게 사용했는지는 아직도 잘 모르겠다.
단순히 문법이나 기능 구현을 떠나서, 코드의 구조를 잡아주는 패턴에 대한 공부가 필요하다고 느꼈다.
생각나는 내용이 있으면 계속 추가하겠습니다
긴 글 읽어주셔서 감사합니다