일렉트론 기반의 스크립트와 연동된 에디터 페이지 작업중, 편집을 하다가 화면이 멈추는 현상이 있었다. 사실은 올게 왔다, 라고 생각했다. 회사에서는 ai agent 로 최대한 빨리빨리 진행하기를 원하고, 프론트엔드, 백엔드 할 것 없이 한 프로젝트에 투입되며 규칙은 지켜지지 않고 코드가 꼬이는것은 한순간이었다. 스파게티 그 자체..가장 큰 문제는 Context 이다. 모든 상태를 Context 에 넣고 앱 전체를 감싸고 있으니, 거의 대부분의 컴포넌트가 스크립트 한 줄 변경, 리전 드래그 동작 하나마다 모두 리렌더되는 상황.. 이전에 한번 거대 리팩토링을 거쳤지만 또 이런문제가 발생했다는것은 팀전체의 리렌더와 상태관리 이해도 문제라고 생각했다. 이 문제를 풀고, 앞으로도 예방하기위해서 어떤것을 할 수 있..

1. 분리된 창이 같은 상태를 공유하지 못하는 문제이번에 실시간 변경 가능한 srt script panel을 바탕으로 TTS를 생성하여 바로 스튜디오에 연동하여 편집할 수 있는 멀티미디어 에디터를 제작하는 프로젝트를 하면서 일렉트론을 처음 사용해보았다. 그러던 중, 분리된 창에서 수정한 내용이 다른 창에 반영이 되지 않는 버그를 만났다. 일렉트론 앱의 특성과 여러 분리된 창들이 같은 상태를 공유하기 위해 SSOT를 어디에 둘 지 설계하였던 과정들을 공유해보려고 한다.Electron 앱에서 프로젝트 저장, SRT script panel, editor 페이지, admin 페이지가 같은 프로젝트 데이터를 다루고 있었다. 문제는 이 데이터들이 하나의 단일 진실 공급원, 즉 SSOT(Single Source of..

1. 들어가며타임라인 리전 드래그 성능을 보면서 처음에는 “Canvas redraw를 어떻게 줄일까”를 먼저 생각했다. 이전 실험에서는 requestAnimationFrame으로 redraw를 묶고, React state 경로를 우회하고, 드래그 중 임시 이동 상태를 별도 저장소에 두는 방식으로 비용을 줄였다. 그 접근은 의미가 있었다. 실제로 Canvas draw 호출 수와 React 렌더 비용이 줄었다.그런데 후속 최적화를 하면서 문제를 조금 다르게 보게 됐다. 드래그 중에 Canvas를 더 효율적으로 다시 그리는 것보다, 드래그 중 Canvas가 다시 그릴 필요가 없도록 구조를 바꾸는 편이 더 낫지 않을까라는 생각이었다.결론부터 적으면, 현재 구조는 드래그 중 원본 리전과 Canvas를 움직이지 않..

1. 들어가며타임라인 리전 드래그 성능 개선 작업을 다시 돌아보면, 처음에는 문제를 너무 빨리 해결책 쪽으로 끌고 가려 했던 것 같다. 드래그가 끊기고, 캔버스가 여러 번 다시 그려지고, React 리렌더가 많이 발생한다는 사실을 보자마자 requestAnimationFrame이나 ref 패턴을 떠올리기 쉬웠다.하지만 지금 다시 보면 더 중요한 것은 특정 패턴 자체가 아니었다. 어떤 증상이 있었고, 그 증상이 어떤 실행 경로에서 발생했는지, 그리고 각 경로를 어떤 순서로 줄여야 하는지를 나누는 과정이 더 중요했다.이 글은 구현 내용을 다시 설명하기보다, 내가 이 문제를 어떤 순서로 풀었어야 더 좋았을지 돌아보는 회고다. 결론부터 적으면 성능 개선은 바로 패턴을 넣는 일이 아니라, 증상 관찰, 측정, 병목..

1. 들어가며타임라인에서 리전을 드래그할 때 화면이 뚝뚝 끊기는 문제가 있었다. 처음에는 캔버스에 그리는 데이터가 많아서 생기는 문제라고 생각했다. 하지만 React DevTools Profiler와 Chrome Performance로 확인해 보니, 단순히 Canvas draw 비용만의 문제는 아니었다.드래그 중 React commit은 105회 발생했고, canvas clearRect는 104회, drawImage는 25,300회 호출됐다. 같은 드래그 구간에서 메인 스레드 busy time은 1,524ms였다. 이 수치는 드래그 중 React와 Canvas가 모두 자주 깨어나고 있었다는 사실을 보여줬다.결론부터 적으면, 드래그 중 매번 React를 깨우던 경로를 줄이고, Canvas 다시 그리기와 S..

썸네일 최적화 시도 시리즈는 총 3편으로, 잘못된 판단으로 삽질을 하고, 스스로에게 질문하고 수정해나가는 과정을 담았습니다. 이전 글들은 아래 링크에서 보실 수 있습니다. 이전 글: [썸네일 생성 최적화 시도1] Web Worker 를 이용한 썸네일 생성 최적화 https://insight74278.tistory.com/42[썸네일 생성 최적화 시도2] 썸네일 생성 구조 재설계하기 https://insight74278.tistory.com/49 1. 들어가며앞선 글에서는 비디오 썸네일 생성 구조를 두 번에 걸쳐 정리했다.첫 번째 글에서는 Web Worker를 이용해 썸네일 생성 비용을 메인 스레드에서 분리하는 과정을 다뤘다. 그 과정에서 처음에는 Web Worker 가 항상 빠를 것이라고 생각했지만, ..