Claude Code를 사용해 LG TV를 리버스 엔지니어링하고 네이티브 Plex 클라이언트를 만들었습니다

C에서 Rust로

PlxNative 첫 버전은 Plex 클라이언트도 아니었음. 그냥 색깔 있는 타일들 가득 채워놓고, 타일마다 The Office 같은 에피소드 하나씩 재생하려고 발악하는 수준이었지. 일단 궁금했던 건 하나였음. 이 TV가 네이티브 인터페이스를 60fps로 렌더링할 수 있냐는 거. 사각형 그리는 건 쉬웠음. 근데 LG 하드웨어 비디오 평면에 실제 비디오 프레임을 올리는 건 차원이 다른 문제였음. 그래서 Fable한테 이 문제를 던져줬더니 네이티브 미디어 스택 조각들을 충분히 연결해 줘서, 처음으로 화면에 The Office가 떴음. 첫 프레임이 뜨는 걸 보고 일반 LG TV에서도 완전한 네이티브 미디어 클라이언트가 가능하다는 걸 확신했고, 그다음부턴 어디까지 밀어붙일 수 있을지가 관건이 됐음.

첫 번째 프로토타입

프로토타입은 C로 짰고, 거의 전부가 main.c 파일 하나에 다 들어있었음. 코드가 커지길래 에이전트한테 모듈별로 쪼개달라고 시켰는데, 여기서 에이전트 코딩의 핵심을 깨달음. 코드가 겉보기엔 멀쩡하고 컴파일도 잘 되는데, 메모리나 소유권 문제 때문에 전혀 상관없는 곳에서 터져버리는 거임. 제일 골치 아팠던 건 리팩토링 후에 eglSwapBuffers에서 발생한 크래시였음. 알고 보니 LG가 포크한 SDL이 내 헤더가 선언한 것보다 더 큰 SDL_SysWMinfo를 써서 스택 오버플로우가 나고 있었던 거임. 거대한 main() 함수에선 오버플로우가 나도 별일 없었는데, 코드를 작은 함수로 옮기니까 라이브 상태를 다 망가뜨리기 시작함. 이걸 안정적인 ABI라고 부르긴 힘들지. 뻔한 malloc/free 실수까지 겹치니까 언어 선택을 다시 고민하게 되더라. 에이전트가 코드를 이 정도로 많이 짜고 옮기는 상황에선 언어 선택이 진짜 중요함. 에이전트가 제일 잘 쓰고, TV에 들어가기 전에 컴파일러가 최대한 많은 걸 잡아낼 수 있는 언어를 골라야 함. 나한테는 그게 Rust였음.

결국 처음부터 다시 짜는 수준이 됐는데, 한 번에 다 바꾼 건 아니고 점진적으로 진행함. LG 네이티브 경계는 C로 남겨두고 나머지를 하나씩 옮겼음. 이미지 디코딩이랑 HTTP부터 시작해서, 액세스 유닛 큐, Matroska 디먹서, Plex 파싱, 포스터 워커, 텍스트 렌더링, 마지막으로 앱 대부분을 옮겼지. Rust는 32비트 ARM 기반의 구형 임베디드 리눅스 박스에서도 놀라울 정도로 잘 돌아갔고, 컴파일러가 빡세게 피드백을 주니까 나랑 에이전트 둘 다 훨씬 정신 똑바로 차리고 작업할 수 있었음.

2019년형 TV에서 60 fps 뽑기

재생 기능이 돌아가고 나서는 UI는 그냥 포스터, 텍스트, 둥근 사각형 정도로 간단하게 유지하려고 했음. 근데 셰이더를 짜기 시작하면서 상황이 달라짐. 셰이더가 점점 커지더니 어느새 내비게이션, 모달, 포커스 핸들링, 모션, 히트 테스트, 캐싱까지 포함된 나만의 OpenGL 기반 UI 라이브러리가 되어버림. UIKit이나 남이 만든 프레임워크 위에서만 몇 년을 놀다가, 리모컨 버튼 누르는 것부터 화면에 픽셀 찍히는 것까지 밑바닥부터 다 파헤쳐 보니까 진짜 재밌더라.

모든 4K LG TV는 webOS가 앱에 1920×1080 UI 서피스를 제공함(HD 모델은 1280×720). 영상은 별도의 하드웨어 평면에서 돌아가니까 1080p는 내가 선택한 최적화가 아니라 그냥 캔버스 그 자체임. 나는 실제 TV에서 60 fps를 찍는 걸 목표로 잡고, 프레임 드랍이 날 때까지 기능을 계속 때려 넣었음. 처음엔 그림자 하나 넣었다가 프레임 레이트가 박살 나더라. 무식하게 짠 버전은 엄청 느렸는데, 파고들면 항상 해결책은 있었음. 셰이더에서 일찍 계산 끝내기(early-out), 해상도 낮춘 버퍼 쓰기, 안 변하는 프레임 부분 캐싱하기 같은 거. 지금은 거의 모든 요소에 그림자가 들어가는데도 60 fps로 잘 돌아감. 추측만으론 한계가 와서 TV에서 Mali 하드웨어 카운터를 뽑아봤음. 프로파일링 해보니까 산술 파이프 점유율이 89.5%, 로드/스토어가 44.8%였고, 셰이더에 있는 별거 아닌 것 같은 분기문 하나가 프레임당 수백만 번의 산술 연산을 추가하고 있었음. 그러니까 문제는 "픽셀이 너무 많다"가 아니라 GPU가 ALU 연산에 꽉 막혀있던 거였음.

제일 흥미로웠던 건 리퀴드 글래스(Liquid Glass) 느낌의 머티리얼이었음. 밑에 있는 페이지를 블러 처리하고, 모양에 따라 굴절시키고, 진짜 투명한 유리처럼 테두리에 명암을 넣는 거였지. 굴절은 쉬웠는데 가독성이 문제였음. 어두운 포스터 위에서는 예쁜데 사람 얼굴이나 하얀 하늘 위에서는 아무짝에도 쓸모가 없어서, 틴트랑 대비, 블러 값을 끝도 없이 조절해야 했음. 이제야 애플이 왜 그런 문제를 해결하려고 애쓰는지 알겠더라. 그리고 넘을 수 없는 벽도 하나 있는데, 영상은 내 렌더러가 물리적으로 샘플링할 수 없는 별도의 오버레이 평면에서 돌아감. 그래서 영상 위에 유리를 얹는 건 다르게 처리해야 함.

앱이 화면 몇 개를 넘어가니까 디자인이 점점 따로 놀기 시작함. 여기는 간격이 이렇고, 저기는 버튼이 다르고 하는 식이었음. 그래서 Claude Design을 써서 디자인 시스템을 만들고 화면들을 한곳에 정리했음. 디자인은 HTML/JS로 되어 있고 실제 UI는 Rust랑 OpenGL이지만, Claude가 내 컴포넌트, 간격 토큰, 타이포그래피에 맞춰서 매핑을 해줌. 디자인 툴이 꼭 실제 프로덕션이랑 기술 스택을 공유할 필요는 없음. 그냥 디자인을 정확하게 설명만 할 수 있으면 되는 거임.

결과적으로 같은 TV에서 콜드 스타트 기준으로 이렇게 됐음. "누가 시청 중인가요?" 화면까지 3초, 프로필을 기억하게 두면 홈 그리드까지 바로 4초 걸림. 비교하자면 공식 앱은 각각 30초 정도 걸렸음.

에이전트 활용하기

Claude Code, Opus, Fable, Codex가 구현, 리버스 엔지니어링, 디버깅, 리팩토링, 테스트, 리뷰 등 거의 모든 과정에 참여했음. 하지만 최종 결정권은 언제나 실제 TV가 쥐고 있음. 시뮬레이터에서는 완벽한 화면이 나와도 TV에서는 빈 카드만 뜰 때가 있는데, 시뮬레이터는 절대 겪지 않는 캐시된 프레임 경로를 하드웨어가 타기 때문임. 에이전트가 아무리 코드가 맞다고 확신해도 결국 TV에서 돌려보기 전까진 모르는 거임.

또 하나 배운 점은, 절대 자동 조종에만 맡기지 말라는 거임. 처음엔 주말 동안 대충 바이브 코딩으로 끝낼 생각이라 에이전트한테 시키기만 했음. 그러다 보니 엉망인 아키텍처 때문에 문제가 터지기 시작했고, 똑같은 버그가 계속 재발하지 않게 앱을 제대로 된 꼴로 만드는 데 리팩토링만 수십 번을 했음. 결국 핵심 결정, 특히 아키텍처는 숙련된 엔지니어가 직접 챙겨야 함. 진작에 이렇게 할 걸 그랬음 :)

그럼에도 불구하고 AI 덕분에 한 사람이 펌웨어 리버스 엔지니어링, 미디어 재생, Rust, 그래픽, GPU 프로파일링, UI 아키텍처, 디자인, QA, 빌드 최적화, SEO까지 말도 안 되는 범위를 커버할 수 있게 됐음. 주변에 널린 "구형" 기기들(오래된 TV, 차량용 헤드 유닛, 각종 임베디드 화면)을 보는 시각도 완전히 바뀌었음. 매일 쓰는 기기 인터페이스가 마음에 안 든다면, 직접 원하는 걸 만들어 보는 것도 해볼 만함. 하드웨어가 구린 게 아니라 소프트웨어가 구린 경우가 태반이니까.

실전 정보: PlxNative는 webOS 4.0 이상에서 돌아감. 나는 2019년형 LG TV에서 개발했고, 사용 리포트를 보면 2018년형부터 최신 webOS 11 모델까지 재생이 잘 되는 걸로 확인됨. H.264/HEVC는 4K, 10-bit, Dolby Vision 프로필 5/8, E-AC-3 Atmos까지 TV가 지원하는 선에서 다이렉트 재생되고, 나머지는 Plex 서버가 트랜스코딩함. LG 개발자 모드(주기적으로 갱신 필요)나 webOS Homebrew Channel을 통해 설치할 수 있음. 루팅은 필요 없음.

사이트: https://plxnative.com
소스: https://github.com/GLinnik21/plx-native