Python으로 개발하면서 Rust로 구현된 라이브러리들을 쓸 때마다 그 압도적인 속도에 감탄하곤 했습니다. 그래서 직접 앱을 만들기로 결심했을 때, 네이티브로 갈지 아니면 멀티플랫폼 도구를 쓸지 고민하다가 자연스럽게 Rust 기반의 Tauri가 눈에 들어왔습니다. 그렇게 SyncWatcher의 여정은 Tauri와 함께 시작되었습니다.
초반의 전율: 그 압도적인 속도
처음 Tauri로 개발을 시작했을 때의 그 느낌은 “와, 정말 빠르다!” 한 마디로 요약됩니다. 물론 초반이라 앱이 가볍기도 했겠지만, 빌드와 실행 속도 모두 매우 만족스러웠습니다. AI를 도구 삼아 개발하는 과정 자체도 꽤나 신선하고 긍정적인 경험이었죠. 중반까지는 이 기세라면 세상에서 가장 빠른 앱을 만들 수 있을 것 같았습니다.
중반의 깨달음: 이벤트와 동기화의 함정
하지만 앱이 완성도를 갖춰가고 안정성을 고민하기 시작하면서 예상치 못한 벽에 부딪혔습니다. 프로그램 자체가 느린 게 문제가 아니었습니다. 문제는 Tauri의 Backend(Rust)와 Frontend(Webview) 사이에서 발생하는 방대한 이벤트 처리였습니다.
다량의 이벤트가 동시에 발생할 때 이를 안정적으로 처리하고, 이벤트 간 충돌을 막기 위해 장치들을 추가하다 보니 화면 변화에 시간이 걸리기 시작했습니다. “어이쿠, 정말 빠르다”는 그 첫인상을 유지하는 데 실패한 것이죠.
특히 실행 시점에 체크해야 할 요구사항들이 많아지면서 병목이 생겼습니다. 앱 자체는 가볍지만, 시작하자마자 동기화 설정을 읽고 필요한 경우 첫 동기화를 즉시 실행하고, 그 상태를 화면에 실시간으로 반영하는 과정들이 얽히기 시작했습니다. 이 모든 것을 완벽한 Non-blocking 방식으로 처리하기엔 구조적 난도가 높았고, 결국 일부 블로킹 설정이 들어가면서 초기 구동 속도가 기대만큼 나오지 않게 되었습니다.
아쉬움과 하드웨어의 벽
한 가지 더 아쉬웠던 점은 네이티브 앱만큼의 조작감을 완벽히 구현하기 어려웠다는 것입니다. 특히 macOS 윈도우 자체의 크기 조절(Resizing) 같은 미세한 제어가 잘 안 되더군요. 제가 더 깊게 파보지 않은 탓도 있겠지만, AI를 통해 이 문제를 해결하려고 할 때도 한계가 분명했습니다.
그럼에도 왜 다시 Tauri인가?
그럼에도 불구하고 저는 다음 프로젝트인 지식 관리 서비스 역시 Tauri로 개발할 계획입니다. 왜냐하면:
- 메모리 점유율이 극히 낮습니다.
- Rust 자체의 로직 실행 속도는 타의 추종을 불허합니다.
- 생산성 측면에서 네이티브 개발에 쏟을 시간을 아껴 더 빠르게 기능을 구현할 수 있기 때문입니다.
아이러니하게도 SyncWatcher는 철저히 macOS 전용으로 기획된 앱이라 굳이 Tauri 같은 멀티플랫폼 도구가 필요 없었습니다. 그저 Tauri를 제대로 ‘찍먹’해보고 싶어 선택했을 뿐이죠. 하지만 이 경험은 저에게 멀티플랫폼 기술과 네이티브의 간극을 이해하는 소중한 자산이 되었습니다.
AI 시대, 코딩의 기초에 대하여
AI로 코딩을 하면 할수록 역설적으로 컴퓨터 프로그래밍의 기초가 더욱 소중하게 느껴집니다. 이벤트 루프, 메모리 관리, 비동기 처리 같은 기본 원리를 모르면 AI가 뱉어내는 코드가 왜 문제가 되는지조차 알 수 없기 때문입니다.
하지만 한편으론 이런 생각도 듭니다. “과연 초보라도 AI와 완벽하게 소통할 수만 있다면 이 모든 기초의 부재를 극복할 수 있을까?”
저의 결론은, 도구는 변해도 본질은 변하지 않는다는 것입니다. 다만 그 본질을 다루는 방식이 조금 더 영리해질 뿐이죠. 다음 프로젝트에선 이 이벤트 처리의 한계를 어떻게 넘어서게 될지, 벌써 기대가 됩니다.