음악을 길거리에 떨어뜨려 추천하자, RE:MEDY

정현·2025년 12월 8일

서론

반갑습니다 부산소프트웨어마이스터고등학교에 재학중인 학생입니다.
저희 학교는 2학년 4월에 5명이 동아리를 구성하여 7개월 동안 프로젝트를 진행하고 11월에 최종 발표를 하는 전공동아리 프로젝트를 합니다.

본 회고록은 올해 7개월 동안 진행한 전공동아리 회고록입니다.
전공동아리 회고록인만큼 기술보다는 전공동아리에 초점을 맞췄습니다!
재미있게 읽어주세요 :)

동아리 구성

올해 전공동아리는 기존과 조금 다르게 구성되었다.
5명이 한 팀이 되는 구성은 같지만 팀장(CEO), 기술 팀장(CTO)를 먼저 12명씩 선발하고, 팀장과 기술 팀장이 매칭되고 이후에 추가 팀원 3명을 데려오는 방식이었다.

나는 정해진 팀도 크게 없었고, 팀장을 해보고 싶다는 생각 속에서 팀장에 지원하였다.
이후에 팀장 12명, 기술 팀장 12명이 정해지고 매칭이 시작되었다.

팀장과 기술 팀장이 팀이 되는 방식은 팀장이 정해온 아이디어를 발표하고 서로 합의하에 팀이 결정 되는 방식이었다.

다만 당시에 꽤 많은 친구들이 미리 팀을 구성해왔었고, 나는 이전에 별 생각이 없었기에 미리 구성 안 된 친구들 중 한 명과 팀을 이루게 되었다.

그렇게 팀장과 기술 팀장이 정해지고 나머지 3명을 구성해야 했다.
디자이너 한 명과 프론트엔드 한 명, 백엔드 한 명을 다 구했지만 백엔드 한 명은 다른 팀이 팀원 구성 전날 긴 시간 동안 설득을 해서 데려갔고 프론트엔드 한 명도 구성 되는 당일에 그 팀으로 가버렸다.

참 슬펐지만 어쩔 수 없이 백엔드 한 명과 프론트엔드 한 명은 즉석으로 구했고 그렇게 'TERA' 라는 팀이 결성 되었다.

아이디어

처음에는 선생님들이 교내에서 쓰시는 PEN 메신저, 쿨 메신저의 불편함을 해결하기 위해 교내 메신저를 만들려고 했지만 교장선생님의 PEN 메신저 사랑과 반대로 인해 무산되었다.

그렇게 아이디어를 다시 잡기 위해 여러 아이디어가 나왔다.
개발 협업 툴, 뉴스 기사 편향도 분석, 헬스 메이트, 코드 로직 구직 서비스 등 정말 다양한 아이디어가 나왔다.

그 중 내가 낸 아이디어가 강력한 후보로 잡혔다.
나는 작년에 '어쩌다 발견한 이야기' 라는 위치 기반의 사연 라디오 서비스를 제작 및 수상한 경험이 있다.

버스정류장이라는 매개체를 통해 사연을 남기면 다른 사람이 해당 정류소에 와서 여러 사연들을 읽을 수 있는 간단한 서비스였다.

당시에 내가 위치 기반 소셜 컨셉 아이디어를 내게 되었는데 이때 나온 것이 게시글, 스토리, 음악,영상 같은 매체를 거리에 게시 할 수 있는 위치 기반 SNS였다.

이때 '음악은 저작권 문제가 심하지 않나?' '아이디어를 좀 더 가다듬어 보자' 하고 나온 것이 '어쩌다 발견한 이야기' 였기에 나는 '전공동아리 프로젝트에서는 음악 플랫폼을 만들어도 괜찮지 않을까?' 라는 생각 속에 아이디어를 제시하게 되었고 팀원들도 나온 아이디어 중에 가장 재미있고 신선한 아이디어라고 생각해

위치 기반의 음악 소셜 플랫폼, RE:MEDY가 탄생하게 되었다.

RE:MEDY

기획

컨셉은 거리에 음악을 떨어뜨리는 형식으로 '해당 장소에 어울리는 음악을 그 위치에 추천하자'였다.

기본적인 기능인 음악 드랍, 음악 재생, 커뮤니티 기능, 인기 드로퍼 등을 기반으로 전공동아리 계획 발표회를 성공적으로 마쳤다.

당시에 떨려서 발표 목소리가 조금 많이 떨렸던 것 같은데 끝나고 나니 '발표 연습 많이 했냐' 처럼 잘 발표했다는 말을 들어서 좋았고, 1,2학년, 선생님들 대상으로 '재미있는 서비스'로 잘 각인 되었다는 말이 나와서 나름 행복했다.

이후에 다이어그램, 와이어프레임을 짜면서 서비스의 기획을 구체화하였다.

서비스 소개

음악을 특정 장소에 떨어뜨리고, 떨어진 음악을 주변 사람들이 주워 들을 수 있는 위치 기반형 음악 스트리밍 서비스이다.

사용자는 자신의 현재 위치에 어울릴만한 다른 사람에게 추천하고 싶은 음악을 떨어뜨리고,떨어진 음악은 주변 사용자가 다시 들을 수 있고, 좋아요와 함께 간단한 코멘트를 남길 수 있다.

또한 평소에 자주 듣는 플레이리스트를 떨어뜨리거나 사용자끼리 어떤 음악이 더 좋은지 의견을 받는 투표를 길거리에 떨어뜨려 토론의 장을 열 수 있다.

개발

React Native

일단 앱이다 보니 React Native 혹은 Flutter 두 개 중에 고민하다가 아무래도 dart보다 내가 더 사용하기 편한 typescript를 사용하는게 더 좋을 것 같아서 React Native를 사용하기로 결정했다.

RN이 처음이었기에 좀 익힐겸 본 프로젝트 개발전에 간단하게 게시글을 작성할 수 있는 게시판을 만들어봤다.

일단 처음 개발할 때는 크게 다른걸 느끼지 못했다.
또 스타일링은 RN에서 자주 사용되는 styleSheet를 사용하게 되었다.

처음 퍼블리싱 당시에 style-component와 유사한 방식으로 스타일링을 하였지만 조금만 생각해도 styleSheet를 좀 멍청하게 사용했던 것 같다.

리팩토링을 진행할 때는 더 유연한 스타일링을 해야할 것 같다.

구조

src/
├── components/
├── constants/
├── hooks/
├── modules/
├── navigation/
├── services/
├── store/
├── theme/
├── types/
├── utils/


modules/
├── home/ - 메인 페이지
├── drop/ - 음악 드랍 관련 페이지
├── music/ - 음악 상세보기 페이지
├── profile/ - 마이페이지
├── setting/ - 설정페이지
├── auth/ - 로그인, 회원가입, 소셜 인증
├── notification/ - 푸시 알림


modules/
└── home/
    ├── pages/
    ├── api/
    ├── components/
    ├── queries/
    ├── store/
    ├── hooks/
    ├── utils/
    ├── types/
    ├── styles/
    ├── datas/
    └── index.ts

위는 V1에 구성된 폴더 구조이다.

도메인(기능)별로 modules로 분해해두고 해당 도메인에서 사용 되는건 해당 폴더 안에서 관리하고 전역적으로 사용되는 건 최상위에서 관리하는 식으로 구성했다.
처음에 구조를 짤 당시에는 나쁘지 않다고 생각했는데 점점 개발이 진행될 수록
'utils는 애매한데 그냥 싹다 전역으로 뺄까', '쓸데없이 폴더 구조가 복잡하네' 같은 생각들이 들어서 좀 마음에 안 드는 구조였다.

V2를 할 때는 디자인도 다 확실하게 나온 상태고, 기능 추가가 갑자기 일어날 일도 없어서 좀 더 깔끔하게 아키텍쳐를 구성해야겠다.

앱 개발

앱 개발이 처음이다 보니 웹 개발과 다른점들이 조금씩 있었다.
우선 앱은 빌드 에러가 정말 자주 일어난다.

EXPO로 시작하면 훨씬 더 편했겠지만 이왕 전공동아리로 RN 프로젝트를 하는 김에 CLI로 하면 좋을 것 같아서 CLI로 시작했다.

하지만 정말 자주 빌드 에러가 터졌다.

라이브러리를 하나 추가하려고 하면 이 라이브러리와 이미 사용중인 라이브러리끼리 버전이 안 맞거나 RN 자체가 정식 버전이 아니라 버전이 꽤나 자주 바뀌는데 RN 자체의 버전과 라이브러리가 서로 호환 되지 않는 문제들도 정말 많았고, 0.80, 0.71 차이로 다운그레이드와 업그레이드를 여러번 시도했다.

또 React Native Track Player 같은 경우는 음악을 재생하기 위해 필요한 라이브러리였는데 이건 기기별로 되는게 있고 안 되는게 있었다.
ios에서는 최신 버전에서 잘 되는데 android에서는 안 되고, 또 android에서는 특정 버전이 잘 되는데 ios에서는 빌드 에러나는 경우도 있었다.

ios에서 네이티브 세팅을 조금 건드려주니 해결이 되긴 했지만 이외에도 다양한 빌드 에러들이 있었다.
AI의 검색 도움이 없었다면 개발 속도가 훨씬 느려졌을 것이다.

빌드 에러가 한 번 나면 해결하기 위해서 원인 검색, 여러 해결 방안 생각, 해결 방안 중 하나를 선택하고, 시도 해보고 안 되면 다시 되돌리고를 반복해야했다.

심지어 RN 빌드 에러는 국내 자료도 많이 없어서 깃허브, 라이브러리 공식 문서, 스택오버 플로우에서 나와 비슷한 문제, 원인을 찾아야 했던 것도 시간이 많이 걸렸다.
정말 빌드 에러가 한 번 나면 힘이 쭉 빠지며 '코드 짜고 싶다' 라는 생각 속에서 해결했던 경험이 많다.

지도와 웹뷰

이것들 중 해결을 포기한 것이 react-native-maps다.
위치 기반 서비스다 보니 지도 라이브러리르 사용해야했고 구글 지도를 사용할 수 있는 react-native-maps를 사용하기로 결정했다.

하지만 이 정말 화가 나게 만드는 rn-maps가 정말 다양한 빌드 에러를 터뜨려주며 개발 초기에 나를 고생시켰다.

'AirGoogleMaps dir must be added to your xCode project to support GoogleMaps on iOS.'

다양한 에러를 해결하고 위의 문구까지 간 것이 가장 많이 해결한 상태였다.

AirGoogleMaps 폴더 직접 생성 → 에러 유발 (실패)
버전 1.3.2로 다운 후 AirGoogleMaps 폴더 생성 → 실패

여러 시도들을 계속 이어나갔지만 실패하였고, 우리 전공동아리 멘토 선배님이 마침 작년에 RN을 하셨기에 '지도를 어떻게 해결하면 좋을까요?' SOS 요청을 했지만 선배님도 정확히 작년 전공동아리에서 지도 라이브러리를 사용하시다가 똑같은 문제를 2주동안 해결하지 못하시고 웹뷰로 띄웠다고 하셨다.

결국 약 1주동안 삽질을 한 나는 중간 발표때는 임시로 웹뷰로 띄우자 라고 하였고 웹뷰는 바로 성공했다.

이후에 바꾸는 것이 좋겠다고 생각했지만 생각보다 웹뷰로 해도 크게 불편하지 않아서 계속 놔두었다.

하지만 최종 발표 1주 전에 디자인이 변경되고 지도 위에 재생 중인 음악의 모달을 띄워야 했고, 음악이 전환되면 웹뷰 안에서도 반영이 되어야했다.

웹뷰는 기본적으로 웹을 따로 띄워서 위젯 형태로 띄우는거다 보니 저 웹이랑 RN이랑 어떻게 정보를 주고 받을지 생각하다가, 서로의 console 로그를 활용하기로 하였다.

사용자가 음악 변경(휠 돌리기)를 하면 콘솔 로그를 찍어 정보를 전달하고 웹뷰에서는 로그를 확인하게 하여 선택된 음악이 하이라이팅 및 모달로 뜨게 만드는데 성공했다!

크로스 플랫폼

아무래도 RN으로 개발하니 당연하게도 ios와 android 크로스플랫폼으로 개발하게 되었다.

ios는 내가 android는 다른 프론트엔드 팀원이 담당하여 개발하기로 하였지만, 이후에 해당 팀원이 맥북 용량이 부족해져 에뮬레이터, 안드로이드 스튜디오를 똑바로 돌리기 힘들어져 android까지 내가 어느정도 담당하게 되었다.

위치 기반이다 보니 당연하게도 위치 권한을 받아와야 하는데 android와 ios의 위치 권한 요청 방식 차이가 있었다.
또 위치 권한 거부시 앱 크래시가 발생하는 문제점이 생겨 위치 서비스 비활성화 상태 처리가 필요했다.

useEffect(() => {
  async function requestLocation() {
    try {
      if (Platform.OS === 'android') {
        const res = await PermissionsAndroid.requestMultiple([
          PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION,
          PermissionsAndroid.PERMISSIONS.ACCESS_COARSE_LOCATION,
        ]);
        const fineGranted = res[PermissionsAndroid.PERMISSIONS.ACCESS_FINE_LOCATION] === PermissionsAndroid.RESULTS.GRANTED;
        const coarseGranted = res[PermissionsAndroid.PERMISSIONS.ACCESS_COARSE_LOCATION] === PermissionsAndroid.RESULTS.GRANTED;
        
        if (!fineGranted && !coarseGranted) {
          Linking.openSettings(); // 설정으로 이동
          return;
        }
        enableHighAccuracy = fineGranted;
      } else {
        const auth = await Geolocation.requestAuthorization('whenInUse');
        if (auth !== 'granted') return;
      }
      
    } catch (e) {
      console.error('Permission error', e);
      setLocation(null);
    }
  }
  requestLocation();
}, []);

그래서 위와 같이 플랫폼 별 분기를 나누어 다르게 권한 허용을 받았고, try-catch로 에러 헨들링을 하였다.

위치 권한 뿐만 아니라 음악 재생, svg 렌더링에서도 android와 ios의 차이가 있었다.
예를 들어 svg의 그림자 효과는 android에서는 적용이 안 되는 문제처럼 플랫폼별 차이점이 있는 경우는 분기로 나눠 따로 처리를 해주는 코드를 짜는 경험을 하였다.

또한 safeArea도 같은 react-native의 기본 제공되는 safeArea 위젯을 사용하면 ios에서는 잘 되지만 android에서는 안 되는 문제가 있어서 safeArea만큼은 'react-native-safe-area-context' 여기서 들고와서 사용하여 해결하였다.

React Query 캐시 무효화

근처에 떨어진 음악을 들고오는 API가 있었다.
위도 경도를 넘겨줘서 해당 위치를 기반으로 근처에 떨어진 음악을 반환하는 API였다.

export function useDroppings(longitude: number, latitude: number) {
  return useQuery({
    queryKey: ["droppings"],
    queryFn: () => getDroppings({ longitude, latitude }),
    staleTime: 5 * 60 * 1000, 
    retry: 1,
  });
}

이렇게 queryKey에 droppings만 넣어두면 위치가 바귀어도 같은 쿼리로 취급하기 때문에 이전 캐시 내용을 보여준다.
또 좌표가 준비 되기 전에, 즉 위도 경도가 받아와지기 전에 API 요청을 보내는 건 불필요한 API 호출이므로

export function useDroppings(longitude: number, latitude: number) {
  return useQuery({
    queryKey: ["droppings", longitude, latitude],
    queryFn: () => getDroppings({ longitude, latitude }),
    enabled: longitude !== undefined && latitude !== undefined,
    staleTime: 5 * 60 * 1000, 
    retry: 1,
  });
}

다음과 같이 queryKey에 위도 & 경도를 넣고, enabled를 걸어 위도 경도가 준비 되었을때만 호출이 발생하도록 수정하였다.

음악 재생

ios는 정책에 따라 백그라운드 재생이 제한된다.
물론 일시적으로는 재생이 잘 된다.
하지만 일정 시간이 지나면(앱이 백그라운드로 전환되면) 자동으로 음악이 꺼진다.

그렇기에 아래와 같이 info.plist에 요청 설정을 추가하고,
음악을 재생하려고 할때 백그라운드 재생 권한을 요청하고 설정으로 바로 이동할 수 있게 사용자가 명시적으로 권한을 허용하면 백그라운드 재생이 가능하도록 만들었다.

<key>UIBackgroundModes</key>
<array>
    <string>audio</string>
</array>

const useBackgroundAudioPermission = () => {
  const requestBackgroundAudioPermission = async () => {
    Alert.alert(
      '백그라운드 재생 권한',
      '음악을 백그라운드에서 계속 재생하려면 권한이 필요합니다.',
      [
        { text: '나중에', style: 'cancel' },
        { 
          text: '설정으로 이동', 
          onPress: () => {
            Linking.openURL('App-Prefs:root=General&path=BACKGROUND_APP_REFRESH');
          }
        }
      ]
    );
  };
};

또 스트리밍 음악 앱이라 음악을 HLS를 통해 재생하였다.
HLS(http live streaming)은 애플이 만든 http 기반의 적응형 비트레이트 스트리밍 프로토콜이다.
비디오를 작은 조각(세그먼트)로 나눠 사용자 네트워크 환경에 맞게 조절하여 전송해준다.
실시간 음악이나 동영상을 재생할 때 자주 사용된다.

서버는 음원을 여러개의 .ts 세그먼트 파일로 분할하여 저장중이고, 클라이언트에서 해당 음악을 요청하면 .m3u8 플레이리스트를 받을 수 있다.

해당 m3u8 파일을

// 클라이언트 사이드 M3U8 파싱 및 절대 경로 변환
const processedM3U8 = text
  .split('\n')
  .map(line => {
    if (line && !line.startsWith('#') && !line.startsWith('http')) {
      return `${baseURL}/songs/${songId}/segments/${line}`;
    }
    return line;
  })
  .join('\n');

// Data URL로 변환하여 TrackPlayer에 전달
const dataUrl = `data:application/vnd.apple.mpegurl;base64,${btoa(processedM3U8)}`;

클라이언트에서는 전달받은 m3u8 플레이리스트를 직접 파싱하여, 내부 세그먼트 경로를 상대 경로에서 절대 경로로 변환하였다.

변환된 m3u8 내용을 Data URL 형태로 래핑하여 TrackPlayer에 전달하였다.
이렇게 하는 이유는 TrackPlayer는 실제 파일을 기반으로 재생할 수 있기 때문에 Data URL 형태로 래핑하여 파일로 처리될 수 있게 하였다.

TrackPlayer는 전달받은 Data URL을 하나의 플레이리스트 파일처럼 해석하고, 내부에 정의된 .ts 세그먼트 URL을 스트리밍 서버에 요청을 넣어 음악을 재생한다.

그 결과, HLS 기반 스트리밍 음악 재생을 정상적으로 구현할 수 있었다!

운영

음악 저작권

음악은 저작권이 매우 중요하다.
그래서 저작권 문제를 해결하기 위해 다양한 시도를 하였다.

우선 한국음악저작권협회에 음원 이용 허락 계약을 요청하기 위해서는 사업자 등록증이 필요했다.
그래서 나는 여름방학 때 직접 세무서에 방문하여 개인 사업자등록증을 발급 받았다.

그렇게 한국음악저작권 협회에 음원 이용 허락 계약을 요청 넣었으며 허가가 났지만

음원이 별도로 유통 받아야 한다는 사실을 잊고 있었다.
그래서 음원 유통을 위해 다양한 음원 유통사에게 연락을 넣었다.

하지만 고등학생이 음원 유통 계약까지 받기는 정말 어려웠다.
콜드 메일을 여러 차례 보냈지만 씹히거나 연락이 오더라도 직접적인 계약까지 가기는 어려웠다.

그래서 만약 음원 유통이 이루어지는 것을 가정하고, 또 이후에 실제로 유통까지 이어졌을때 바로 개발이 되도록 MVP 모델에서는 저작권에 문제가 없는 음원, 일부 음원들을 기반으로 개발을 진행하였다.

출시

안드로이드는 앱 심사가 빡빡하지 않고, 무료인 원스토어에 먼저 심사 요청을 넣었다
앱 아이콘, 앱 스크린샷, 앱 설명 등을 준비하였으며 2번의 반려 끝에 승인을 받아 원스토어에 RE:MEDY를 출시하였다.
또한 이후 수정 사항 및 버그 픽스를 위해 업데이트를 진행하였다.

그렇게 전공동아리 최종 발표까지 약 50건의 다운로드 수를 확보하였다.

또한 iOS는 Apple Developer Program에 가입하기 위해 약 13만원의 비용을 지불하였다 ㅜ
apple developer program에 가입하면 1년 동안 앱 출시, 앱 베타 테스트 등을 자유롭게 할 수 있어진다.

앱 심사를 받기까지는 조금 무리가 있어서 교내 배포용으로 testflight로 베타 테스트를 출시하여 위와 같은 교내 배포를 진행하였다.

13만원이 아까워서라도 RE:MEDY와 다른 개인 프로젝트 앱을 개발한다면 꼭 출시까지 해버리고 싶다.

외부 부스 운영

전공동아리 최종 발표전까지 외부에서 총 2번의 부스 운영도 진행하였다.
먼저 비디아에서 전시를 할 수 있었다.

비디아는 부산정보산업진흥원, 동의대, 동아대, 국립한국해양대, 부산외국어대, 부산대, 국립부경대, 동서대, 부산소프트웨어마이스터고 등 9개 기관이 공동 주관한 행사이다.

학교 대표 4팀 중 한 팀으로 출전하여 RE:MEDY 부스 운영을 하였다.

많은 분들이 오시진 않았지만 오시는 분들을 대상으로 설명 드렸을때 '신박한 아이디어' 라는 평가를 많이 들었으며, 이대로 다른 음악 앱에 판매해도 좋을 것 같다고 칭찬 해주셔서 기분이 좋았다.

또한 지스타에서도 학교 대표 3팀 중 한 팀으로 선정되어 러닝, 도전과제, 재화, 꾸미기 등 살짝의 게임적 요소를 첨가하여 부스 운영을 하였다.

지스타에 출품하여 부스 운영을 해본 것은 정말 재미있는 경험이었다.
물론 지스타가 게임 행사다 보니 큰 관심을 끌지는 못했지만 그래도 좋은 경험이었다.

지스타 이후, 기능 확장이 필요하다고 판단해 '드랍 종류를 늘리자'는 결론이 나왔고, 플레이리스트와 투표 드랍 두 가지 기능을 추가하기로 결정했다.

플레이리스트는 단순히 하나의 음악이 아니라 플레이리스트 단위로 떨어뜨리는 기능이고, 투표 드랍은 음악을 선택지로 둔 후 투표 주제를 작성하여 토론의 장을 해당 장소에 열 수 있는 커뮤니케이션 기능이었다.

추가한 건 좋았지만 최종 발표 약 1~2주전에다가 디자인과 백엔드가 최종 발표 주에 나와서 내가 이걸 완벽하게 만들 수 있을지 의문이 조금 있었지만 그래도 잘 해내어서 다행이었다.

최종 발표

나는 최종 발표 전날과 전전날에 밤을 샜다.
그래서 최종 발표 당일 정말 피곤해서 말이 잘 안 나왔다.

그래도 지금까지 계획 발표, 중간 발표, 비디아, 지스타로 정말 많이 발표 해왔다 보니 큰 걱정이 되진 않았다.

최종 부스 운영

다른 부스에서 간식, 경품으로 뽑기를 많이들 준비하길래 우리도 간단하게 cd 키링과 간식으로 뽑기를 준비했다.

오전 10시 ~ 오후 3시까지 부스 운영이었는데 오전은 대부분 선생님과 1학년들이었다.
최종 발표다 보니 많은 사람들이 왔다.

원래 같으면 팀원과 발표 교대를 하겠지만 심사위원이 언제 오실지 모르기 때문에 계속 내가 했다.

오전 타임이 지나고 점심을 먹고 난뒤에는 본격적으로 심사위원분들이 돌아다니셨다.
원래라면 총 12개 팀 모두 심사위원분들이 오셔서 듣고 채점하셔야 하지만,
심사위원분들이 반대쪽 6팀 쪽을 먼저 가시고 게다가 일찍 가셔야 하는 심사위원 분들이 많으셔서 우리 팀에는 10명의 심사위원 중 4~5명의 심사위원 밖에 안 오셨다.

우리 옆에 부스도 4~5명의 심사위원 밖에 안 오셨다고 하는 걸 보니 이쪽에 잘 안 오신 걸로 보인다.
심사위원이 부스에 오지 않으면 미리 만들어둔 노션을 기준으로 채점이 되었다.