캔버스와 코드의 만남: Figma의 코드 레이어 구축
같은 캔버스에서 디자인하고 구축할 수 있다면 어떨까요? 디자인과 코드를 하나로 결합하기 위해 코드 레이어를 어떻게 만들었는지 소개합니다.
캔버스와 코드의 만남: Figma의 코드 레이어 구축공유
일러스트레이션: Fiona Ye
지난주, 우리는 React 코드로 렌더링되는 Figma Sites의 새로운 레이어 유형인 코드 레이어 베타 버전을 출시했습니다. 사용자는 코드 레이어를 통해 웹의 모든 기능을 시각적 캔버스로 가져와 양식, 셰이더, 인터랙션 및 API를 사용하여 인터랙티브한 경험을 구축할 수 있습니다. 동시에, 코드 레이어는 프레임 내에 중첩되고, 컴포넌트에 사용되며, 캔버스에서 자유롭게 이동하고 크기를 조정할 수 있다는 점에서 다른 Figma 레이어와 동일하게 작동합니다. 또한, 사용자는 버튼 클릭 한 번으로 Figma에서 구축한 디자인을 코드 레이어로 즉시 변환할 수 있으며, Figma Make를 구동하는 것과 동일한 AI 모델을 사용하여 동작을 추가할 수 있습니다.
Figma에 코드 레이어를 구축하려면 소프트웨어에 대한 두 가지 다른 사고방식, 즉 디자인과 코드를 조화해야 했습니다. 오늘날 Figma의 시각적 캔버스는 사용자가 디자인을 빠르게 반복할 수 있는 개방적이고 유연한 환경입니다. 코드는 더 많은 기능을 열어주지만 더 구조화되어 있어 계층적 구성과 정확한 구문이 필요합니다. 이 두 가지 모델을 조화하기 위해, 디자인의 신속하고 탐구적인 특성을 존중하면서 코드의 모든 기능을 활용할 수 있는 하이브리드 접근 방식이 필요했습니다.
이를 성공적으로 수행하려면 세 가지 과제를 해결해야 했습니다.
- Figma 생태계에 코드 레이어와 컴포넌트를 자연스럽게 통합
- 코드 사용자 지정을 지원하는 강력하면서도 사용하기 쉬운 IDE 구축
- 디자이너와 개발자 간의 멀티플레이어 협업 지원
소재로서의 코드
코드는 전통적으로 파일 시스템, 즉 코드 파일을 리프 노드로 하는 디렉터리 트리로 구조화됩니다. 이 모델은 개발에는 좋지만 Figma의 공간적인 2D 캔버스와 조화하기는 어렵습니다. 예를 들어, 객체는 시각적 캔버스의 어디에나 존재할 수 있는 반면, 코드 파일은 파일 시스템의 지정된 위치에 존재합니다. 이러한 불일치는 업무 흐름에 실질적인 과제를 안겨줍니다. 시각적 레이어가 특정 파일 위치에 해당할 때 이를 어떻게 복사할까요? 단일 진실 공급원은 캔버스일까요, 아니면 파일 시스템일까요? 코드 레이어를 복제할 때 코드의 일반적인 방식처럼 인스턴스를 생성해야 할까요, 아니면 기존 Figma의 복제 방식처럼 포크 버전을 생성해야 할까요?
Figma 내의 코드가 디자이너와 개발자에게 친숙하게 느껴져야 한다는 것을 알았고, 이는 사용자가 공간 캔버스에서 코드 레이어를 자유롭게 조작할 수 있는 능력을 유지해야 한다는 의미입니다. 우리가 도달한 해결책은 코드 레이어를 새로운 캔버스 원형으로 구현하는 것이었습니다. 코드 레이어는 완전한 공간적 유연성(이동, 크기 조정, 상위 요소 변경 포함)과 매끄러운 레이아웃 통합(오토 레이아웃 스택 배치 등)을 통해 다른 레이어와 동일하게 동작합니다. 가장 중요한 것은 시각적 캔버스의 자유롭고 실험적인 특성을 모방하여 쉽게 복제하고 반복할 수 있다는 점입니다. 이를 통해 서로 다른 버전의 코드를 나란히 생성 및 비교할 수 있습니다. 일반적으로 비교를 위해 코드를 두 개 복사하려면 별도의 git 브랜치를 만들어야 하지만, 코드 레이어를 사용하면 ⌥ 키를 누른 채로 드래그하기만 하면 됩니다. 이렇게 하면 소스 코드의 포크가 자동으로 생성되어 빠른 작업이 가능해집니다.
우리는 React를 지원하기로 결정했는데, 그 이유는 React의 컴포넌트 모델이 Figma의 컴포넌트 개념과 밀접하게 일치하기 때문입니다. Figma의 컴포넌트는 디자이너가 인터페이스를 구축하는 데 사용하는 재사용 가능하고 유연한 구성 요소입니다. React도 같은 방식으로 작동합니다. 개발자는 재사용 가능한 React 컴포넌트를 결합하여 화면과 앱을 구축합니다. 또한, React의 속성은 Figma의 컴포넌트 속성 개념과 직접 연결되므로 이 둘을 서로 연결했습니다. 코드에서 속성을 정의한 다음 토글, 슬라이더, 드롭다운과 같은 사용자 지정 가능한 제어판을 사용하여 시각적으로 편집할 수 있습니다.
모든 기능이 포함된 웹 기반 IDE
코드 레이어는 전적으로 AI를 통해 생성하고 편집할 수 있지만, 사용자가 완전한 유연성을 위해 코드를 직접 편집하고 싶어 할 것이라는 점도 알고 있었습니다. 이를 작업을 원활하게 하기 위해 IDE의 핵심 엔진으로 CodeMirror를 선택하는 것을 시작으로 Figma 내에 최신 코드 편집 경험을 구축했습니다.
CodeMirror는 웹 기반 코드 편집을 위한 확장 가능한 기반을 제공하여 색상 테마, 찾기 및 바꾸기, 줄 번호와 같은 기능을 위한 확장을 정의할 수 있게 지원합니다. 여러 상황에서, 코드 에디터를 Figma에 통합하기 위해 기본 동작을 재정의해야 했습니다. 예를 들어, CodeMirror의 기본 실행 취소/다시 실행 동작을 자체 실행 취소 스택을 기반으로 한 맞춤형 구현으로 대체했습니다.
우리는 특히 대규모 코드베이스의 경우 성능이 병목 현상으로 작용할 수 있다는 것을 일찌감치 인식했습니다. 번들링 및 타입 검사와 같은 IDE 작업은 느려질 수 있으며 JS는 단일 스레드이기 때문에 대용량 파일을 처리할 때 UI가 멈출 수 있습니다. Figma의 코드 환경을 빠르고 쾌적하게 유지하기 위해 대부분의 개발 툴체인을 웹 워커에서 실행합니다. 워커 내부에서는 빠른 번들 시간을 위해 esbuild(Figma의 공동 창립자인 Evan Wallace가 제작)를 사용하고, 효율적인 스타일 컴파일을 위해 Lightning CSS와 함께 Tailwind v4를 사용합니다. 이 도구들은 부분적으로 네이티브 코드로 작성되어 WebAssembly로 컴파일되며, 상당한 성능 향상을 제공합니다.
종속성 관리의 복잡성을 최소화하기 위해 NPM 또는 ESM URL에서 가져온 패키지를 자동으로 설치합니다. package.json을 초기화할 필요 없이, 필요한 라이브러리를 가져오기만 하면 안전한 샌드박스 내에서 바로 구축을 시작할 수 있습니다. Motion이나 React-Three-Fiber처럼 커뮤니티에서 즐겨 찾는 패키지를 포함하여 대부분의 패키지는 Figma 내에서 기본적으로 작동합니다.
코드 레이어를 협업 가능하게 만들기
멀티플레이어 협업은 훌륭한 경험을 디자인하고 출시하기 위해 팀이 효율적으로 함께 작업할 수 있도록 해주는 Figma의 핵심입니다. 우리의 멀티플레이어 기술은 위치, 색상과 같은 많은 노드 필드에 대한 동시 동기화를 지원합니다. 하지만, 텍스트가 수천 줄에 달할 수 있는 소스 코드와 같이 복잡한 영역에 사용된 적은 없었습니다.
이러한 새로운 요구 사항은 우리의 접근 방식을 재고할 기회를 제공했습니다. 편집을 동기화하기 위한 가장 심플한 해결책은 마지막에 작성된 내용이 우선하는 방식이며, 각 사용자의 변경 사항이 다른 사용자가 변경한 내용을 덮어쓰는 방식입니다. 이는 Figma 디자인의 UX 카피와 같이 짧은 텍스트에는 효과적이지만 느린 연결에서 대규모 소스 코드 파일을 동시에 편집할 때는 문제가 발생합니다. 또한 AI 모델이 코드를 동시에 편집할 때 이러한 문제가 더욱 악화되어 충돌이 추가로 발생한다는 것을 확인했습니다.
운영 변환(OT)은 실행 순서와 컨텍스트에 따라 작업을 조정하여 동시 작업을 변환함으로써 수렴을 달성하는 충돌 해결 기법입니다.
따라서, 운영 변환(OT)과 충돌 없는 복제 데이터 타입(CRDT)과 같은 고전적인 협업 텍스트 편집 알고리즘으로 눈을 돌려 더 나은 대안을 찾았습니다. OT는 충돌 없이 적용될 수 있도록 동시 작업을 변환합니다. 이는 Google Docs와 같은 수많은 협업 텍스트 편집기의 기반 기술을 형성합니다. 하지만 모든 충돌하는 편집 내용을 서로 변환해야 하므로 충돌이 많은 파일을 병합할 때 속도가 느려집니다.
충돌 없는 복제 데이터 유형(CRDT)은 작업 순서에 관계없이 모든 복제본이 동일한 상태로 수렴되도록 보장하여 최종 일관성을 보장하는 데이터 구조입니다.
반대로 대부분의 CRDT는 각 문자를 독립적인 엔티티로 취급합니다. 이로 인해 편집 병합이 훨씬 쉬워지지만 메모리 오버헤드가 더 높아집니다. 업데이트를 처리하려면 동시 편집이 없는 경우(가장 일반적인 사용 사례)에도 문서의 전체 기록을 메모리에서 재구성해야 합니다. 이는 메모리 과다 사용 현상을 유발하고 성능 저하를 초래합니다.
다행히 OT와 CRDT의 장점을 대부분 갖춘 새로운 알고리즘인 Eg-walker(Event Graph Walker)가 작년에 발표된 한 논문에서 소개되었습니다. Eg-walker는 편집을 방향성 비순환 인과 이벤트 그래프로 표현합니다. 이 알고리즘은 git rebase와 유사하여 여러 갈래로 나뉜 브랜치를 선형 순서로 재정렬합니다. 동시 이벤트를 병합하기 위해 Eg-walker는 임시로 CRDT 구조를 구축합니다. 해결 알고리즘이 완료되면 Eg-walker는 내부 CRDT를 삭제하여 메모리를 확보합니다. 충돌이 없는 순차적인 편집이 이루어지는 이상적인 경로에서는 업데이트 비용이 거의 0에 가깝습니다. 결과적으로 CRDT만큼 병합 속도가 빠르지만 OT처럼 메모리 오버헤드가 최소화됩니다.
성능 및 메모리상의 이점을 고려하여 Eg-walker 알고리즘을 사용하여 코드 레이어를 위한 멀티플레이어 협업 서비스를 구축했습니다. 사용자가 코드 파일을 편집하면 클라이언트는 편집 목록을 서버로 전송합니다. 서버는 Eg-walker를 사용하여 모든 활성 클라이언트의 동시 편집 내용을 조정하고 충돌을 해결하여 업데이트된 편집 목록을 다시 보냅니다. 이 아키텍처를 통해 멀티플레이어 서비스는 모든 클라이언트의 가장 계산 집약적인 병합 작업을 처리하여 대규모 파일 시스템에서도 빠른 초기 로드 시간과 우수한 성능의 사용자 경험을 지원합니다.
코드와 디자인의 미래
원칙에 입각한 발명
영향력 있는 작가이자 연구원 겸 인터페이스 디자이너인 Bret Victor는 "대부분의 사람들이 말하지 않는 삶의 방식"을 설명합니다. 중요하고, 필요하며, 옳다고 믿는 원칙을 찾고 그것을 동기 부여에 활용하는 방법에 대한 Bret Victor의 강연 전체를 시청하세요.
코드 레이어는 Figma 내 코드 도입의 시작에 불과합니다. 코드 레이어에 더 많은 직접 조작 기능을 도입하여 코드 업무 흐름과 디자인 업무 흐름 간의 격차를 더욱 좁히고, 사용자가 그 순간의 필요에 따라 매체를 매끄럽게 전환할 수 있게 될 것으로 기대합니다.
인터페이스 디자이너인 Bret Victor는 자신의 강연 "원칙에 입각한 발명(Inventing On Principle)"에서 "크리에이터는 자신이 만드는 것과 즉각적으로 연결되어야 합니다. 무언가를 만들 때, 변경하거나 결정했다면 그 효과를 즉시 확인해야 합니다."라고 말합니다. Figma 내 코드의 기능을 계속 확장하면서, 우리는 '디자인과 코드를 분리된 도구에 가두지 않고 모두가 공유된 환경에서 함께 창작할 수 있어야 한다'는 아이디어를 바탕으로 나아가고 있습니다.
현재 Figma Sites에서 코드 레이어 베타 버전을 이용할 수 있습니다. 여러분이 무엇을 만드실지 무척 기대됩니다!
