Spotify 브라우저 API가 타입스크립트 기반 로컬 단일 계정 서버로 제공됨

이 프로젝트는 Spotify를 새로운 플랫폼으로 재구현한 제품이라기보다, 사용자가 이미 로그인한 웹 플레이어를 자기 컴퓨터 안에서 조작하게 해주는 개인용 제어 계층에 가깝습니다. Spotify 웹 API를 호출하지 않고 접근 토큰을 추출하거나 비공개 네트워크 요청을 재생하지 않는다는 점은 분명한 장점입니다. 공식 API의 권한 범위나 호출 정책에 덜 의존하면서 검색, 보관함 조회, 재생 제어를 자동화할 수 있기 때문입니다. 다만 이 장점이 곧 안정성을 뜻하지는 않는다고 봅니다.

가장 큰 약점은 렌더링된 HTML과 버튼 동작에 의존한다는 구조입니다. Puppeteer가 크로미움이나 파이어폭스를 띄우고 화면을 읽는 방식은 실제 사용자의 동작을 흉내 내기에는 적합하지만, 안정적인 프로그래밍 인터페이스는 아닙니다. Spotify가 DOM 구조, 버튼 이름, 로그인 절차, 동의 화면을 바꾸거나 사용자별 화면을 다르게 제공하면 이 서버가 갑자기 일부 기능을 잃을 가능성이 큽니다. 브라우저 자동화 프로젝트에서 유지보수 비용이 기능 개발보다 커지는 흐름으로 이어질 수 있습니다.

그래서 이 도구를 Spotify API의 대체재라고 부르는 데에는 선을 그어야 합니다. 기사에 나온 기능은 검색과 항목 스냅샷, 좋아요 표시 곡과 보관함, 특정 재생 목록 조회, 플레이어 제어, 제한된 메모리 캐시입니다. 이는 개인용 터미널 플레이어나 홈 서버에는 충분히 매력적이지만, 여러 사용자를 지원하는 서비스나 장시간 무중단으로 돌아가야 하는 자동화에는 부족할 가능성이 높습니다. 특히 단일 계정 서버라는 설계는 범용 서비스보다 개인의 작업 흐름을 위한 선택으로 읽는 편이 정확합니다.

보안 경계도 가볍게 볼 수 없습니다. 서버 실행에 쓰이는 API_TOKEN이 있고, 브라우저에는 Spotify 로그인 상태가 남아 있을 수 있습니다. 기사만으로 실제 토큰 저장 방식이나 외부 접속 차단 여부를 단정할 수는 없지만, 로컬 서버의 포트가 외부에 노출되거나 토큰이 다른 프로그램에 전달되면 계정 제어 권한이 악용될 위험이 생길 수 있습니다. 따라서 같은 컴퓨터에서만 접근하도록 묶고, 토큰을 공유하지 않으며, 브라우저 프로필을 별도로 분리하는 운영이 필요해 보입니다.

헤드리스 환경에서 오디오 재생이 보장되지 않는다는 제한은 이 프로젝트의 성격을 잘 보여줍니다. 이것은 음악 스트리밍 엔진을 제공하는 서버가 아니라 웹 플레이어를 자동 조작하는 도구입니다. 화면에서 재생 버튼을 누르는 일과 실제 오디오 출력이 서버 환경에서 지속적으로 이뤄지는 일은 다릅니다. 터미널 인터페이스를 만들 수 있다는 사실만 보고 라즈베리 파이 같은 무인 장비에서도 안정적인 음악 서버가 될 것이라고 기대하면 실망할 가능성이 큽니다.

그럼에도 실험적 가치가 작지는 않습니다. 비공개 네트워크 요청을 재현하지 않고 브라우저가 제공하는 사용자 경험을 활용한다는 방식은 구현의 경계를 비교적 솔직하게 드러냅니다. 다만 Spotify의 이용 약관과 계정 자동화 정책을 확인하지 않은 채 개인적 편의를 곧바로 배포 서비스로 확장하는 것은 위험해 보입니다. 앞으로는 UI 변경에 대비한 선택자 테스트, 로그인 실패 복구, 기능별 호환성 점검이 프로젝트 생존을 좌우할 가능성이 큽니다.

결국 이 도구는 공식 통합 플랫폼보다 개인이 자신의 계정과 플레이어를 통제하는 작은 자동화 실험으로 평가하는 편이 맞습니다. 음악 목록을 터미널에서 다루고 싶은 사용자에게는 유용한 출발점이 될 수 있지만, 안정성과 확장성을 중시하는 개발자라면 브라우저 화면이라는 취약한 기반을 감수해야 합니다. 편리함은 지금 얻을 수 있어도, 지속 가능성은 Spotify의 다음 UI 변경 이후에야 검증될 겁니다.