← Docs hub

차기 모델 OS 판단과 라운드 디스플레이 포팅·사용 방향

권고: 차기 모델은 Android를 우선 기준선으로 유지하고, 원형 전용 제품 UI를 구축한다. 외부 앱·서비스 확장성이 불확실하고 기존 Android 음성·기기 제어 자산을 활용한다는 현재 전제에서의 판단이다. Linux+Qt는 필수 서비스의 상용 연동 경로를 모두 확보하고, 고정 기능 제품으로 범위를 제한하며, 이식 비용보다 자원·운영 이득이 크다는 실측 근거가 있을 때 전환 후보로 채택한다.

작성·공식 자료 확인: 2026-10-14. 이 문서는 플랫폼 선택 제안과 포팅 계획이며 차기 보드·패널의 구현 완료 보고가 아니다. 패널 지름·해상도·인터페이스·터치 사양, 차기 SoC/BSP, 서비스 목록·계약, 수명·원가 목표는 미확정이다. 라운드는 모서리만 둥근 사각형이 아닌 완전한 원형 표시 영역을 뜻한다.

이번 보강에서 바로 볼 항목: 서비스 실패 시 대안, 기존 자산 이식 범위, 원형 안전 영역 계산, 시험 절차와 선택 기준, 수명 비용과 실행 순서.

문서의 근거 수준은 세 가지로 구분한다. 공식 문서 확인은 플랫폼/API의 제공 조건, 기존 분석 기록은 현행 자산의 이식 후보, 설계 제안은 차기 제품에서 검증할 구성이다. 아래 수치 예시는 설계 계산 또는 시험 횟수 제안이며 성능 실측값이 아니다.

0. 차세대 AP 구성·인증 검토의 추가 기준

현행 구성은 QCS6490 Android AP + RK3588 Linux·ROS AMR이다. 기존 본문은 앱/UI OS 비교이며, AP 수·AMR 이식·Google Play 도입의 결정을 모두 포함한 자료는 차세대 AP 분리/통합 종합 검토에서 다룬다. 현재 권고 기준선은 Android를 유지하면서 AMR 실행을 별도 Linux·ROS AP에 두는 안이다. 차세대 AP는 QCS6490보다 상위 SoC를 적용하며, 구체 모델은 미정이다. 1안도 Android AP 교체를 전제로 비교한다.

원형 패널은 지름 약 50cm를 검토 중이며 실제 사양은 미정이다. 원형 가시 영역 기준으로 자체 UI를 설계하는 것과 일반 앱의 전체 화면을 보존하는 것은 별도 요구다. 일반 앱을 원형 전체에 출력해 모서리를 가리면 CDD 화면 요구와 충돌할 수 있어 인증과 논리 화면 전략을 선행 검토해야 한다. 원형 디스플레이 Android 포팅 상세에 표시 방식·소스 지점·시스템 화면·인증 조건을 정리했다.

1. 책임 기준과 전체 해야 할 일

OS는 화면 모양만으로 선택하지 않는다. 서비스 제공 가능성, 하드웨어 지원, 사용자 경험, 장기 유지보수를 함께 만족해야 한다.

진행 순서: 필수 서비스 확보 → 두 OS의 BSP/미들웨어 지원 확인 → 실제 패널의 핵심 UX 검증 → 동일 기능 성능·비용 비교 → OS 확정 → 양산 검증. 서비스가 불가능한 후보를 화면 데모의 매끄러움만으로 선택하지 않는다.

2. 선택지는 세 가지다

Android도 Linux 커널을 사용한다. 여기서 Linux는 Android 프레임워크 없이 임베디드 Linux와 Qt를 구성하는 안이다. Qt는 UI 프레임워크이므로 Linux 선택과 동의어가 아니며 Android에서도 사용 가능하다. 현 비교는 Kotlin/Java 등 기존 Android 자산 활용과 임베디드 Linux+Qt 전환을 비교한다. 개발팀 숙련도와 공급사 지원도 총비용에 포함한다.

3. Android와 Linux+Qt 장단점 상세

다음 표의 우열은 현재 제품 방향에 대한 설계 판단이다. 실측되지 않은 속도·전력·원가를 확정하지 않는다.

AOSP 호환성 프로그램은 CDD/CTS와 GMS 라이선스 검토를 구분한다. AOSP 사용은 Play Store 제공 보장이 아니다. Qt 라이선스는 모듈에 따라 조건이 다르므로 무료·유료로 단순 분류하지 않는다. Qt 임베디드 Linux는 EGLFS/Wayland 등 여러 구성을 제공하며, 선택한 그래픽 경로가 성능에 영향을 준다.

4. Spotify와 외부 서비스: 앱 실행·통합·Connect를 구분

공식 근거: 상용 하드웨어 절차, Connect 동작, Android App Remote 시작, Web Playback SDK, Linux 배포 안내.

음성 제품의 추가 선결사항: 공개 Spotify Developer Policy III.3은 음성으로 Spotify를 제어하는 SDA/음성 비서 기능을 금지한다. 따라서 일반 개발자 API를 연결해 음성 제어를 출시할 수 있다고 가정하지 않는다. 상용 하드웨어 파트너 경로에서 우리 사용 사례의 허용 여부를 별도로 확인해야 한다. AI가 곡을 선택·제어하는 흐름도 승인된 데이터·명령 범위를 정의한다. Spotify Developer Policy

상용 eSDK 인증이 모든 음성·검색·화면 조작을 자동 허용하는 것은 아니다. 기능 제한 처리, 인증된 UI 범위, 계정 방식, 대기 상태의 연결 유지 조건은 제품 유형별로 확인한다. Spotify 기술 요구사항

다른 서비스도 같은 표로 별도 조사한다. 영상 서비스가 추가되면 원형에서 영상 손실·레터박스, 보안 디코딩·출력 경로, 로그인 UI, 서비스 기기 인증을 추가 검토한다. Spotify 지원만으로 다른 음악·영상 앱의 지원을 추정하지 않는다.

4.1 서비스 경로가 막혔을 때의 제품 대안

출시 필수 요구를 먼저 문장으로 고정한다. “Spotify 음악을 들을 수 있다”, “휴대폰 없이 기기에서 검색한다”, “우리 음성 비서가 곡을 지정한다”는 서로 다른 요구다. 첫 번째만 만족한 시제품으로 세 번째까지 가능하다고 판단하지 않는다.

휴대폰으로 최초 인증하는 것과 재생 중 계속 휴대폰에 의존하는 것은 다르다. Connect 계열의 기기 직접 재생과 Bluetooth 수신을 시험표에서 분리한다. QR은 인증 방식을 만드는 기술이 아니라 지원되는 인증 경로의 진입 수단이며, 서비스가 허용하지 않는 로그인 흐름을 임의로 추가하지 않는다.

서비스 요구표에는 기기 단독 탐색, 직접 재생, 휴대폰 인증, 음성 명령, 오프라인, 지역/계정, 업데이트 주체를 각각 기록한다. 상태는 확보 / 조건부 / 미확정 / 불가로 구분하고 공급사 확인 날짜와 적용 버전을 붙인다. 미확정을 지원 가능으로 합산하지 않는다.

5. 상황별 판단과 권고를 바꾸는 조건

Linux 전환의 필수 조건은 ① 출시 서비스 전체의 승인된 연동 경로 ② 차기 보드의 GPU/음성/오디오/무선 SDK 지원 ③ Android 전용 자산 이식 계획 ④ OTA·진단·보안 책임 확보 ⑤ 동일 기능 실측과 수명 총비용의 유의미한 이점이다. 하나라도 미확정이면 Linux 확정 결정을 보류한다.

총비용 비교는 보드·메모리·저장장치 + 초기 포팅 + 서비스 계약/인증 + 라이선스/지원 + 연간 보안·회귀·운영 + 서비스 변경 대응으로 산정한다. 단순 OS 이미지 크기나 UI 데모 개발 일수로 비교하지 않는다. 아직 견적·측정값이 없으므로 임의 점수·절감률·일정을 제시하지 않는다.

5.1 기존 자산을 어디까지 재사용할 수 있는가

아래는 이식 범위 산정을 위한 분해안이다. 기존 typed SDK 소비 경계 분석에는 ForegroundService, FunctionCallHandler, ApiCallValidator의 DeviceCommunicator 의존과 SkixManager 연결·리스너 경계가 기록되어 있다. 이는 2026-09-03 분석 기록이며, 현재 브랜치 전체를 새로 감사한 결과나 Linux 동작 증거는 아니다.

재사용 가능성은 코드 줄 수가 아니라 동작 계약과 검증 자산으로 계산한다. 서버를 그대로 쓴다고 Android의 기기 실행 경로까지 이식되는 것은 아니며, C/C++라는 이유만으로 벤더 런타임 의존성이 사라지지도 않는다.

5.2 플랫폼 선택을 바꿔도 유지할 권장 경계

제품 UI는 요청 전송 → 수락/거절 → 실행 상태 관찰 → 실제 완료/실패 표시 순서로 동작하도록 설계한다. Planner는 목표와 명령을 생성하고, 기기 실행 서비스는 실제 상태를 제공하며, Android 또는 Linux 어댑터가 이를 연결한다. 이것은 차기 모델의 설계 제안으로 현재 구현 완료를 뜻하지 않는다.

연결이 끊겼다가 복구되면 먼저 현재 상태를 조회한다. 요청 ID와 상태 버전 또는 동등한 순서 식별자를 사용해 중복 명령·늦은 응답을 구분하는 방안을 검토한다. 이 계약을 Android에 먼저 정리하면 Linux 후보도 같은 입력/결과 사례로 시험할 수 있다. 단, 공통 인터페이스 구축만으로 서로 다른 HAL·오디오·보안 동작의 동등성을 증명할 수는 없다.

6. 라운드 디스플레이 포팅: 두 OS 공통

원형 패널도 사각형 프레임버퍼/좌표 공간에 원형 가시 영역을 갖는 구성이 흔하다. 실제 구조는 패널·컨트롤러 사양으로 확인한다. 모양 플래그는 패널 구동을 대신하지 않는다.

OLED이면 정적 링·시계·앨범 표시의 잔상/번인 완화도 평가한다. LCD와 동일 전력·잔상 특성을 가정하지 않는다. 로컬 GPU 데모의 성공은 전체 BSP·실기기 포팅 완료가 아니다.

7. Android 포팅과 통합 범위

기본 경로는 패널/터치 드라이버 → Display HAL·Hardware Composer → SurfaceFlinger → WindowManager → SystemUI/제품 앱이다. AOSP 그래픽 구조

1. 패널을 정상 구동한다. 해상도·회전·터치와 composer 지원을 확인하고 원형 마스크와 실제 가시 영역을 일치시킨다.
2. 시스템에 화면 형태를 전달한다. 대상 Android 브랜치의 display round flag와 제품 리소스 overlay를 확인한다. 참고로 로컬 Android 소스의 LocalDisplayAdapter.java는 config_mainBuiltInDisplayIsRound를 확인하고, 리소스 기본값은 config_windowIsRound를 참조한다. 브랜치별 구현을 확인한 뒤 적용하며 에뮬레이터용 속성을 양산 패널 설정으로 대체 사용하지 않는다.
3. 앱은 원형 정보를 사용해 배치한다. Configuration.isScreenRound()와 사용 가능한 inset 정보를 활용하되 실제 패널 안전 영역을 검증한다. 둥근 사각형 모서리 API만으로 완전한 원형 배치를 해결하지 않는다. Configuration API
4. 제품 전용 홈과 화면 이동을 정의한다. 홈·뒤로가기·취소·알림 진입·유휴 복귀, 재시작 후 현재 작업 표시를 일관되게 만든다. 전용 기기 모드는 도구이며 모든 팝업을 자동으로 원형화하지 않는다. Lock task mode
5. 시스템이 소유하는 화면을 별도로 정리한다. 볼륨, 권한, 연결, 입력기, 전원, 오류/ANR, OTA, 잠금 화면을 실제 사용 경로에서 확인한다. 앱 overlay로 실제 SystemUI 책임을 대체했다고 간주하지 않는다.
6. 외부 앱을 원형에서 검증한다. 계정 로그인·키보드·동의·오류·검색·재생·앱 업데이트 후 흐름을 확인한다. 호환 화면을 축소해 넣는 방식은 터치 크기가 줄어들므로 마지막 수단이다. Wear OS용 UI 참고가 일반 AOSP에 Wear OS 앱/서비스를 제공하지는 않는다.

위 소스 확인은 설정 지점의 근거이며 차기 패널에 적용됐다는 증거가 아니다. 실제 포팅은 선택한 BSP 브랜치와 제품 overlay 경로를 확정한 뒤 수행한다.

8. Linux+Qt 포팅과 통합 범위

기본 후보는 패널/터치 드라이버 → DRM/KMS·GPU 드라이버 → EGLFS 또는 Wayland → Qt Quick/QML → 제품 UI다. 보드에 따라 경로를 조정한다.

• EGLFS: 단일 전체 화면 제품 UI에 적합한 후보. 창 구성 제약과 GPU 지원을 확인한다.
• Wayland: 여러 클라이언트나 독립 화면 서비스가 필요하면 검토한다. compositor 구성과 자원 사용을 함께 평가한다.
• Qt Quick/QML: 원형 전용 UI와 상태 전이를 구성한다. 소프트웨어 렌더링으로 내려간 상태를 GPU 가속 성공으로 보고하지 않는다.
• 입력: evdev/libinput 등 입력 경로, 회전, 활성 영역, 노브·키 입력을 통합한다.
• 시스템 기능: 네트워크 설정, 시간, 사용자 계정, 비밀정보 저장, 서비스 감독, OTA/복구, 오디오 중재를 제품 서비스와 연결한다. 이미 있는 Linux 컴포넌트를 활용하되 제품 전체 동작은 검증해야 한다.
• 서비스 연결: Qt는 Spotify·DRM·음성 SDK를 자동 제공하지 않는다. 서비스별 바이너리·지원 ABI·계약·업데이트 수명을 확인한다.

Qt 임베디드 Linux, 임베디드 입력, 가상 키보드 통합.

9. 원형 화면의 사용 방향

권장 역할은 음성 상호작용의 상태·짧은 결과·즉시 조작을 보여주는 화면이다. 긴 검색·계정 입력·복잡한 설정은 휴대폰 연계를 우선 검토하되 휴대폰이 없는 상황의 지원 범위를 제품 요구로 명시한다.

원형 외곽은 정보 표시, 중앙은 읽기·터치를 기본으로 한다. 링 전체를 작은 버튼으로 채우지 않는다. 원의 위/아래로 갈수록 사용 가능한 가로 폭이 줄어드므로 상단 제목·하단 고정 버튼에 특히 여백을 둔다. 중앙 내접 사각형만 쓰면 안전하지만 면적 활용이 줄어든다. 핵심 조작은 안전 영역에, 장식·진행 표시는 바깥 영역에 배치한다.

터치 크기는 해상도 픽셀 수만으로 정하지 않고 실제 지름·밀도·사용 거리·손가락 가림을 반영한다. 물리 노브가 있으면 회전=값 변경/목록 이동, 누름=선택 등 단순한 규칙을 검증한다. 화면 없는 음성 조작, 청각/시각 접근성, 명시적인 중지 동작도 함께 설계한다.

9.1 원형 안전 영역을 수치로 설계하기

아래 계산은 직경 480 px의 원형 가시 영역이 480×480 좌표 안에 있고 경계 오프셋이 없다는 가정의 예시다. 실제 패널 사양이 아니다. 중심에서 세로 거리 y, 반지름 R일 때 해당 높이의 표시 가능한 가로 폭은 W(y)=2√(R²−y²)다.

높이를 가진 버튼은 중심선의 폭만 확인하면 안 된다. 버튼의 모든 모서리가 유효 반경 안에 있어야 하며, 패널의 비가시 영역·조립 공차·터치 가장자리 오차를 추가 반영한다. 터치 대상의 물리 크기는 픽셀 크기 × 표시 지름(mm) / 표시 지름(px)로 환산할 수 있지만 적절한 목표 크기는 실제 사용 거리·손가락·접근성 시험으로 정한다.

화면이 원이라고 그래픽 메모리가 자동 절감되지는 않는다. 예를 들어 480×480 RGBA8888 단일 비압축 버퍼는 480×480×4=921,600 byte(약 0.88 MiB)다. 실제 점유는 stride 정렬·버퍼 개수·레이어·GPU 텍스처에 따라 달라진다. 원형 마스크 바깥이 보이지 않아도 사각형 버퍼를 유지할 수 있다.

9.2 외부 앱과 시스템 화면의 완료 기준

동그란 홈 화면을 완성했다고 포팅을 종료하지 않는다. 공장 초기화 직후부터 계정 연결·첫 재생·장애 복구까지 제품이 약속한 경로가 실제 패널에서 끊기지 않아야 한다. Wear OS의 원형 레이아웃 안내는 배치 참고 자료로 활용하되 일반 AOSP의 앱/시스템 동작을 보증하는 근거로 쓰지 않는다.

10. 음성·음악·기기 제어의 공통 정책

두 OS 모두 재생·녹음 동시 동작과 우선순위를 제품 차원에서 정의해야 한다. 일반적인 설계 후보는 음악 재생 → 깨움 감지 → 승인된 방식의 일시정지/음량 조정 → 음성 입력 → 응답 → 정책에 따른 재개다. 서비스 계약이 허용하는 동작만 적용하며 Spotify 콘텐츠와 TTS 혼합을 기본 허용으로 가정하지 않는다.

볼륨은 UI 단계 수와 실제 감쇠 곡선을 구분한다. Android의 미디어 최대 인덱스 설정과 audio policy 곡선은 별개이며, Linux에서도 UI 값과 실제 mixer/player gain의 변환을 정의한다. 15단계의 균일한 인덱스가 동일한 체감 음량 차이를 보장하지 않는다. 플랫폼 변경 시 녹음·재생 지연과 AEC 품질을 다시 측정한다.

10.1 자동 재개와 오래된 상태를 막는 실행 규칙

아래는 공통 오디오 정책의 제안이며 서비스가 허용한 제어 범위 안에서 구현한다.

Android AudioFocus는 오디오 경합을 다루는 기반이지만 제품의 작업 취소·계정 변경·재개 소유권을 전부 판단하지 않는다. focus 요청 결과와 실제 플레이어 상태를 함께 확인해야 한다. Android 15/API 35 이상을 대상으로 하는 앱에는 focus 요청의 전면 앱/foreground service 조건도 있으므로 기존 동작을 새 OS에 그대로 가정하지 않는다. Android Audio Focus

Linux에서도 어떤 오디오 서버를 쓸지와 별도로 누가 일시정지했고 누가 재개할 수 있는지를 제품 계층에서 정의한다. 소리 출력·미디어 상태·UI 표시·기기 실행 상태를 각각 관찰해 단순 메시지 수신 성공을 실제 수행 성공으로 해석하지 않는다.

11. 결정 전에 실행할 검증과 완료 기준

같은 패널·SoC·밝기·네트워크·음원·AI 모델과 동등 기능을 사용한다. 다른 보드나 소프트웨어 렌더링 결과는 별도 비교군으로 표시한다. 다음 측정의 목표값은 제품팀이 확정해야 하며 이 문서에는 측정 결과가 없다.

첫 단계에서 만들 비교물은 미디어 상태·볼륨·음성 상태·확인 질문·Wi-Fi/계정 연결·업데이트/오류의 최소 화면 세트다. Linux 시제품에서 서비스 재생을 모의 데이터로만 구현했다면 Android의 실제 재생 결과와 동등 기능 비교로 취급하지 않는다.

11.1 비교 시험을 재현 가능하게 만드는 방법

다음 횟수는 초기 비교 시험의 시작안이다. 양산 신뢰성 표본 수나 통계적 보증이 아니다. 목표값과 허용 실패율은 시험 전에 합의하며 결과를 보고 기준을 완화하지 않는다.

서로 다른 OS의 로그 시계는 직접 빼지 않는다. 지연 측정은 공통 외부 기준 또는 검증된 시각 정렬을 사용한다. 원시 로그에는 OS/BSP/커널·앱·SDK 버전, 보드/패널 ID, 설정, 시작 온도, 연결 상태를 함께 남긴다. 초기 30회 부팅값으로 p99를 안정적으로 추정했다고 보고하지 않고 원시값·중앙값·최댓값·실패 수를 우선 제시한다.

11.2 필수 통과 조건과 선호 점수는 분리한다

필수 조건을 통과한 후보끼리만 서비스 확장성·출시 작업량·원형 UX·자원/전력·수명 운영 비용을 비교한다. 가중치를 쓰면 제품 요구에서 합의한 뒤 고정하고, 미측정 항목에는 숫자를 넣지 않는다. 핵심 가중치를 바꾸면 우세 후보가 뒤집히는 경우 “압도적 우위”로 결론내리지 말고 추가 측정과 요구 확정이 필요한 항목으로 남긴다.

12. 수명 비용·운영 책임·실행 순서

12.1 Linux 전환의 손익을 계산하는 기준

같은 판매 수량 N, 지원 기간 Y에서 다음 식으로 각 후보를 비교한다.

TCO = 초기 개발/포팅 + 초기 서비스 인증 + N×(대당 하드웨어 + 대당 라이선스) + Y×연간 유지보수/지원 + 변경·장애 대응 예상비용

비용 항목이 일회성인지 대당인지 연간인지 계약별로 분리해 중복 합산하지 않는다. Android 대비 Linux의 대당 절감액을 S, 추가 고정비용과 지원 기간 전체의 추가 운영비를 합친 값을 F라고 두면, S>0이고 비용이 이 범위에서 선형이라는 가정 아래 손익분기 수량은 N=F/S다. 실제로는 수량 구간별 라이선스·인증 재작업·메모리 SKU·보안 지원 조건이 달라질 수 있으므로 구간별 견적을 사용한다. S가 없거나 음수라면 판매량 증가만으로 전환비가 회수된다고 주장할 수 없다.

서비스 승인 실패와 BSP 지원 종료는 평균 비용에 작은 확률로 흡수해도 되는 항목이 아니라 먼저 판정할 출시 조건이다. 낙관/기준/비관 견적을 함께 두고, 필수 서비스 추가 시 두 후보의 추가 개발·인증·회귀 범위를 별도로 계산한다.

12.2 출시 후 책임을 제품 설계에 포함

Android의 A/B 업데이트 같은 플랫폼 기능도 대상 제품에 실제 적용되어 있어야 이점으로 계산한다. 프레임워크가 제공하는 복구 개념과 우리 보드에서 검증된 복구 절차를 구분한다.

12.3 단계별 산출물과 결정 주체

위 역할은 책임 배정을 위한 제안이며 특정 팀의 확정 업무나 완료 상태가 아니다. 각 단계의 기간은 공급사 응답과 대상 보드 확보 후 산정한다.

13. 최종 권고와 재검토 조건

현재 권고는 Android 유지 + 원형 전용 UI + 서비스별 승인된 연동이다. 장점은 기존 자산과 앱 확장 선택지를 보존한다는 것이고, 비용은 원형에서 시스템 화면·외부 앱·입력 흐름까지 다듬어야 한다는 것이다. Linux+Qt의 장점은 전용 제품 구성과 자원 최적화의 자유도이고, 비용은 서비스 확보와 플랫폼 통합·운영 책임이다.

확정 전에 필요한 입력은 패널 실제 크기/해상도/터치·노브, SoC/BSP 지원 수명, 필수 앱과 서비스, 휴대폰 없는 사용 범위, GMS 필요성·가능성, 음악/영상·음성 계약, 전력/부팅 목표, 양산 수량과 유지보수 기간이다. 기술 검토 문서의 공개가 서비스 파트너 계약 체결이나 제품 사양 확정을 의미하지 않는다.

권고를 유지할 조건: 필수 앱/서비스 확장이 열려 있고 Android 자산의 재사용 가치가 크며, 차기 Android BSP의 지원 수명이 제품 요구를 만족하는 경우다. Linux로 권고를 바꿀 조건: 모든 필수 서비스가 승인된 임베디드 경로로 제공되고, 동등 기능 시제품이 필수 검증을 통과하며, 이식·운영비를 포함한 수명 비용 또는 자원 제약 충족에서 실측 이점이 확인되는 경우다. 두 후보 모두 보류할 조건: 필수 서비스 권한·단독 사용·BSP 지원 같은 제품의 핵심 조건이 확보되지 않는 경우다.

따라서 당장의 다음 행동은 OS를 먼저 갈아타는 것이 아니라 출시 필수 서비스표와 차기 보드 지원표를 확정하고, 실제 원형 패널에서 초기 설정부터 음성·재생·장애 복구까지 같은 시나리오를 비교하는 것이다.

Connections

• 차세대 Android AP·Linux ROS AMR 분리/통합

• 원형 디스플레이 Android 포팅 상세

• SK-Intellix Engineering Knowledge Hub

• 프로젝트 포트폴리오
• Android 호환성 프로그램
• AOSP 그래픽
• Qt 임베디드 Linux
• Spotify 상용 하드웨어