"패리티는 같은 픽셀이 아니라 같은 쓸모를 뜻해."
표면을 베끼는 함정
사랑받는 도구를 대체하려 들 때, 게으른 성공 기준은 이거야. '내 걸 걔네랑 똑같이 보이고 똑같이 느껴지게 하자.' 함정이지. 창 배치, 메뉴 문구, 설정 트리를 베끼면, 원본이 쌓아온 온갖 우연을 그대로 물려받으면서 정작 왜 작동하는지는 하나도 안 배워. 게다가 금세 코드랑 에셋이랑 디자인까지 베끼게 돼. 그건 법으로도 문제고 영혼으로도 문제야.
Ashen Reel 은 반대로 가. 쓸모 있는 명령의 뜻이랑 손버릇(muscle memory)은 남겨도, Movist 의 코드·에셋·문구·창 배치·설정 구조는 하나도 안 베껴. 패리티는 결과로 따지고, 결과는 곧 행동이야.
'같은 결과' 의 일곱 규칙
패리티 계약은 이 기준을 적어둬서 '느낌' 으로 새지 않게 막아. 진짜 중요한 것만 추리면 이래.
- 손버릇은 관찰해서 정하지, 추측으로 안 정해. 네 기본값 정하기 전에 Movist 가 실제로 쓰는 키랑 마우스 동작부터 기록해. 기억으로 단축키 지어내는 거 금지.
- 빠른 seek 이랑 정확한 seek 은 따로 둬. 쭉 훑는 스크럽은 부드러움을 위해 정밀도를 좀 내줘도 되지만, Recall 점프는 안 돼. 같은 말인데 보장이 달라.
- 상태는 확인되고 나서 보여줘. 메뉴랑 컨트롤은 네가 마지막에 보낸 명령이 아니라 엔진이 실제로 한 걸 비춰.
- 출력은 눈으로 확인해. HDR, 10-bit, Dolby Vision, 자막 타이밍, A/V 싱크. 이런 건 스펙 시트가 아니라 진짜 화면에 나란히 띄워봐야 알아.
눈으로 봤다는 게 경험적이라는 뜻이야
'출력은 눈으로 확인.' 이게 다들 건너뛰는 규칙이야. 'libmpv 가 HEVC Main 10 디코딩하니까 HDR 도 괜찮겠지' 하고 싶지. 아니. Ashen Reel 이랑 Movist 를 같은 Pro Display XDR 에 띄우고, 같은 10-bit 파일 틀고, 직접 봐. 색, 밝기, 밴딩, 프레임 드롭. 패리티 케이스는 느낌이 아니라 데이터로 남기고.
기능 짜기 전에 합격 기준부터 기계가 검사할 수 있는 케이스로 적어. id 랑 전제조건이랑 oracle 동작이랑 기대 결과가 박힌 행동은 슬그머니 '대충 맞네' 로 후퇴 못 해. 그 케이스 파일이 곧 계약이 돼.
'Movist 랑 픽셀까지 똑같아' 는 목표가 아냐. 오히려 방해물이야. 제대로 된 HDR 파이프라인 둘이 미묘하게 다른 픽셀을 뽑아도 둘 다 맞을 수 있거든. 똑같은 출력을 쫓다 보면, 네 게 맞다는 걸 증명하는 대신 남의 렌더링 선택을 역공학하고 앉아 있게 돼.
행동으로 패리티를 따지면 뭐가 좋냐면, 독립이 생겨. Ashen Reel 은 올바르려고 Movist 가 필요하지 않아. 아빠 미디어가 제대로 재생되면 그만이야. Movist 는 네가 맞췄는지 알려주는 잣대일 뿐이고, 증명이 끝날 때까지 쓰는 예비일 뿐이야.