reMarkable 2에서 필기로 코딩하는 시대?
reMarkable 2에서 필기 입력으로 Clojure 코드를 실행하는 'Edsger' REPL이 공개됨
14초의 지연 시간(14-second lag)과 같은 성능 이슈가 지적되었으나, '재미'와 '가능성'으로 긍정적 평가도 존재함
e-paper 디스플레이의 픽셀 전환 제약과 xochitl 훅킹의 불안정성이 주요 기술적 난제로 언급됨
C++, Zig, Rust 등 다양한 언어로 디스플레이 직접 제어 시도가 공유됨
필기 인식 지연 시간(Latency)과 성능 병목
커뮤니티에서는 14초에 달하는 필기 후 결과 출력 지연 시간에 대한 우려가 제기되었습니다. 이 지연 시간의 원인이 reMarkable 자체 처리, Claude 기반 필기 인식, 또는 시스템 시작 오버헤드 중 어디에 있는지 분석해야 한다는 의견이 있었습니다. 데이터 격리 아키텍처(Data Isolation Architecture) 측면에서, 필기 인식과 REPL 평가 간의 지연이 사용자 경험에 미치는 영향이 주요 논의 대상이었습니다.
e-paper 디스플레이 제어의 복잡성
reMarkable 2의 e-paper 디스플레이는 픽셀 전환에 여러 프레임이 필요하며, 데이터 패킹 방식이 복잡하다는 점이 지적되었습니다. xochitl이라는 사용자 인터페이스 핸들러에 훅(hook)하는 방식이 일반적이나, 이는 소프트웨어 업데이트 시 주소 변경으로 인한 불안정성(Brittleness)을 야기한다고 합니다. 개발자들은 waved 라이브러리나 이를 Zig, Rust로 재작성하는 시도를 통해 디스플레이를 직접 제어하려 했으나, 코드 복잡성과 유지보수 문제가 따랐습니다.
실용성 vs. 재미: 'Why Not?' 동기 부여
일부 사용자는 reMarkable 2에 SSH로 접속하여 REPL을 사용하는 것이 실용성 측면에서 매우 비효율적이라고 지적했습니다. 하지만 다른 의견으로는, '할 수 있기 때문에' 하는 실험과 재미가 충분히 가치 있다는 반론도 제기되었습니다. 이는 기술적 한계에 도전하고 새로운 가능성을 탐색하는 개발 문화의 단면을 보여줍니다.
대안 하드웨어 및 플러그인 API 논의
Supernote Manta와 같은 경쟁 기기의 새로운 플러그인 API가 이러한 기능을 구현하는 데 더 용이할 수 있다는 추측이 있었습니다. 이는 특정 하드웨어 플랫폼의 개방성(Openness)과 확장성(Extensibility)이 개발자 커뮤니티의 창의적인 실험을 얼마나 촉진하는지를 보여주는 사례입니다. reMarkable 2의 폐쇄적인 생태계와 비교되며 논의되었습니다.
필기 기반 블로그 컨셉의 독창성
필기한 내용을 그대로 블로그에 게시하는 '핸드라이팅 블로그' 컨셉에 대한 감탄이 있었습니다. 특히 reMarkable에서 직접 작성하고 링크까지 포함하는 방식에 대한 궁금증이 제기되었습니다. 이는 비정형 데이터 처리(Unstructured Data Processing)와 콘텐츠 생성 파이프라인(Content Generation Pipeline)의 흥미로운 결합 사례로 볼 수 있습니다.
