Figma 레이어 패널 아키텍처 개선 훑어보면서 든 생각

Figma 블로그에서 레이어 패널 아키텍처를 재설계했다는 글이 올라왔다. 제목만 봤을 땐 내부 최적화 이야기겠거니 했는데, 읽어보니 생각보다 흥미로운 접근이 담겨있었다.

레이어 패널은 Figma를 쓰면서 가장 자주 마주치는 UI 중 하나다. 레이어 목록을 열어서 원하는 요소를 찾고, 계층 구조를 확인하는 흐름이 작업 전반에 걸쳐 반복된다. 디자인 파일이 커질수록 이 패널이 느려지는 게 당연하다고만 생각했는데, 이번 글을 읽고 나서 그게 단순히 “파일이 커서”가 아니라 구조적인 원인이 있다는 걸 알게 됐다.

1️⃣ 이게 뭐냐?

기존 레이어 패널은 전개된 모든 노드의 데이터를 통째로 계산하는 방식이었던 것 같다. 화면에 안 보이는 부분까지 포함해서 다 처리하다 보니, 파일 규모가 커질수록 계산량이 그대로 늘어났다. 복잡한 파일에서 느려지는 게 구조적으로 불가피했을 것 같다.

새 아키텍처의 핵심은 “보이는 것만 처리하자”는 방향에 가까웠다. Figma는 이걸 2단계 계산이라고 설명했다. 먼저 화면에 표시될 행의 ID 목록만 추출하고, 그다음에 실제로 화면에 보이는 항목의 데이터만 계산하는 방식이다. 수만 개의 노드가 있어도 화면에 보이는 수십 개만 처리하면 된다는 게 핵심인 것 같다.

캐싱도 함께 새로 설계했다. 각 속성이 어떤 값에 의존하는지를 미리 알고 있다가, 관련된 값이 바뀔 때만 재계산하는 방식이다. 전체를 다시 돌리는 게 아니라, 변경된 부분에만 반응하는 구조로 바꾼 것으로 보인다. 불필요한 재계산을 구조적으로 차단하는 방향이라고 이해했다.

메모리 측면에서는 로프(Rope) 데이터 구조를 도입했다고 했다. 트리 구조를 통째로 복사하지 않고 포인터 참조로 공유하는 방식인데, 이 덕분에 메모리 사용이 크게 줄어든다고 한다. 로프가 텍스트 에디터에서 많이 쓰이는 구조라는 건 알고 있었는데, 레이어 트리에도 이 방식을 적용할 수 있다는 게 흥미로웠다.

2️⃣ 내가 든 생각

디자이너로서 보면 이 변화가 체감될 수 있는 상황이 꽤 있다. 컴포넌트가 많이 쌓인 디자인 시스템 파일이나, 화면을 여러 겹 중첩해놓은 복잡한 파일에서 레이어 패널이 버벅이는 경험이 있었다. 이번 글을 읽고 나서 그게 아키텍처 수준의 문제였다는 게 어느 정도 납득됐다.

👉🏻 흥미로웠던 건 “보이는 것만 처리한다”는 개념이 프론트엔드 쪽에서 자주 쓰이는 가상화(virtualization) 패턴과 겹친다는 점이었다. 공부하면서 리스트 가상화 라이브러리를 접한 적이 있는데, 이 원리가 Figma 내부 UI에도 적용됐다는 게 재미있었다. 도구가 내부에서 쓰는 기술이, 그 도구로 만드는 제품에서도 똑같이 쓰일 수 있다는 게 묘한 지점이었다.

💡 여기서 드는 질문?
의존성 기반 캐싱은 “무엇이 무엇에 영향을 주는지”를 구조 안에 명확히 정의해야 작동한다. 이 관계를 잘 설계해두면 불필요한 계산을 구조적으로 줄일 수 있는데, 이런 설계가 내부에 있다는 게 사용자 입장에서는 그냥 “반응이 빠른 도구”로만 느껴지는 거겠지. 설계가 눈에 안 보인다는 게 오히려 잘 된 설계의 증거인 것 같기도 하다.

⭐️ 마지막으로

이번에 읽으면서 남은 건 “필요한 것만, 필요할 때만”이라는 한 줄짜리 인상이다. 성능 개선이라고 하면 무언가를 더 빠르게 하는 작업을 떠올리기 쉬운데, 이 글을 보면 오히려 하지 않아도 될 계산을 줄이는 쪽에 가까웠다. 더 많이보다 더 적게, 더 빠르게보다 더 필요하게 — 정리해보니 이번 개선의 방향은 그쪽이었던 것 같다.

---

참고 원문: Improving performance in the layers panel