터미널에서 음악까지 해결하고 싶은 개발자들
하루 종일 터미널을 띄워두고 일하는 개발자라면 '음악도 그냥 여기서 틀 수 없나?' 하는 생각을 한 번쯤 해보셨을 거예요. 이런 수요를 채워주던 대표 도구가 Rust로 만든 spotify-tui였어요. TUI(Text User Interface)는 터미널 안에서 키보드만으로 조작하는 화면이에요. vim을 떠올리시면 돼요. 그런데 spotify-tui는 업데이트가 멈춘 지 오래됐고, 결국 저장소도 아카이브됐어요.
Spotatui는 spotify-tui의 바통을 이어받은 프로젝트예요. 익숙한 화면 구성은 그대로 두고 터미널(TUI)과 GUI를 모두 지원해요. 무엇보다 'Web API 레이트 리밋 없이' 동작한다는 점을 앞세우고 있어요. 이게 왜 중요한지 알려면 기존 클라이언트들이 어디서 막혔는지부터 살펴봐야 해요.
레이트 리밋, 터미널 클라이언트의 천적
레이트 리밋(rate limit)은 일정 시간 동안 API를 몇 번까지 부를 수 있는지 정해둔 제한이에요. 맛집 앞에 '1인당 하루 2회까지만 주문 가능'이라고 붙여둔 것과 비슷해요. Spotify Web API도 짧은 시간에 요청이 몰리면 HTTP 429(Too Many Requests)를 돌려줘요. 그러면 클라이언트는 응답 헤더에 적힌 시간만큼 기다려야 하고요.
문제는 TUI 클라이언트가 동작하는 방식이에요. 지금 재생 중인 곡과 진행 바를 실시간으로 보여주려면 1~2초마다 서버에 '지금 뭐 재생 중이야?' 하고 물어봐야 하거든요. 이렇게 주기적으로 묻는 걸 폴링(polling)이라고 해요. 여기에 검색, 플레이리스트 불러오기, 앨범 정보 요청까지 겹치면 한도에 금방 닿아요. 그러면 사용자는 화면이 멈추거나 키 입력이 먹히지 않는 상황을 겪게 돼요.
엎친 데 덮친 격으로 Spotify는 최근 몇 년간 Web API 문을 계속 좁혀왔어요. 2024년 말에는 신규 앱이 추천이나 오디오 특징 분석 같은 엔드포인트를 쓰지 못하게 막았어요. 2025년에는 확장 할당량을 사실상 대규모 서비스 위주로만 승인하는 쪽으로 정책을 바꿨고요. 개인이 만든 오픈소스 클라이언트는 빡빡한 개발자 모드 한도 안에서 버틸 수밖에 없게 됐어요.
Spotatui는 어떻게 피해갔을까
핵심은 공식 Web API에만 기대지 않는 구조로 보여요. Spotify 오픈소스 생태계에는 librespot이라는 Rust 라이브러리가 있어요. 이게 뭐냐면, 공식 Spotify 앱이 서버와 대화할 때 쓰는 내부 프로토콜을 오픈소스로 다시 구현한 라이브러리예요. 이걸 쓰면 앱이 직접 음원을 스트리밍하고 재생 상태를 주고받을 수 있어요.
비유하자면 Web API 방식은 궁금할 때마다 고객센터에 전화하는 거예요. 내부 프로토콜 방식은 직원용 무전기를 들고 있는 거고요. 무전기는 상황이 바뀌면 저쪽에서 먼저 알려주니까 계속 전화를 걸 필요가 없어요. 폴링 횟수가 크게 줄면 레이트 리밋에 걸릴 일도 그만큼 줄어들어요. 어떤 기능을 어느 경로로 처리하는지는 저장소의 README와 소스에서 직접 확인해보세요.
참고로 librespot 기반 재생은 보통 Spotify Premium 계정이 있어야 동작해요.
비슷한 프로젝트와 비교
같은 Rust 진영의 ncspot도 librespot으로 직접 재생하는 TUI 클라이언트라서 Spotatui와 결이 비슷해요. 반면 원조 spotify-tui는 스스로 소리를 내지 못했어요. spotifyd 같은 별도 데몬이나 공식 앱을 리모컨처럼 조종하는 방식이었죠. 그래서 거의 모든 동작이 Web API를 거쳤고, 레이트 리밋에 그대로 노출됐던 거예요.
Spotatui가 다른 점은 spotify-tui 특유의 화면과 키 바인딩에 익숙한 사람에게 익숙한 UI와 요즘 방식의 내부 구조를 함께 준다는 거예요. GUI까지 지원하니까 터미널이 낯선 사용자도 쓸 수 있고요.
한국 개발자에게 주는 시사점
당장 써볼 만해요. Rust 툴체인과 Premium 계정이 있다면 tmux 창 하나에 띄워두고 쓰기 좋아요.
코드 공부 교재로도 괜찮아요. Ratatui(tui-rs의 후속 라이브러리) 기반 화면 구성, 비동기 이벤트 루프, 외부 서비스 연동을 한 프로젝트 안에서 모두 볼 수 있거든요.
외부 API에 기대는 설계를 돌아볼 기회예요. 남의 API 위에 핵심 기능을 올려두면 정책 한 줄만 바뀌어도 서비스 전체가 흔들려요. 폴링을 웹훅이나 푸시로 바꿀 수 있는지, 캐싱으로 호출 수를 줄였는지, 429 응답에 지수 백오프(재시도 간격을 점점 늘리는 방식)로 대응하고 있는지 점검해보세요.
다만 비공식 프로토콜을 쓰면 서비스 약관과 부딪칠 수 있어요. 혼자 쓰는 것과 이걸 바탕으로 상용 서비스를 만드는 건 전혀 다른 문제라는 점을 꼭 기억하세요.
마무리
한 줄 정리: Spotatui는 Web API 폴링 대신 공식 앱과 같은 경로를 써서 '자꾸 멈추는 터미널 클라이언트'라는 고질병을 풀려는 프로젝트예요.
플랫폼이 공식 API를 점점 닫아갈 때 비공식 프로토콜로 우회하는 오픈소스를 어떻게 보시나요? 사용자의 선택권을 지키는 시도일까요, 언젠가 막힐 위험한 줄타기일까요?
🔗 출처: Hacker News