figma·2017년 3월 8일·3분 읽기큐레이션 요약

스냅챗은 논란의

Snapchat의 성공은 전통적인 사용성 원칙을 따랐기 때문이 아니라, 오히려 복잡하고 숨겨진 UI를 통해 독특한 문화와 참여 방식을 만들었기 때문이라는 글이다. 직관성 대신 친구에게 기능을 배우고 공유하게 만드는 ‘공유 가능한 UI’를 택했으며, 카메라 중심 화면과 제스처 기반 탐색으로 모바일 소셜 앱의 새로운 방향을 제시했다. 다만 이러한 성공이 의도적인 전략인지 우연히 형성된 결과인지는 명확하지 않다. ## 전통적인 사용성 원칙을 거스른 UI - Snapchat은 사용자가 앱을 쉽게 이해하도록 만드는 일반적인 디자인 원칙을 따르지 않았다. - Stories 메뉴는 세로와 가로로 모두 스크롤되며, 화면마다 기능 배치와 탐색 방식이 일관되지 않았다. - 앱 전체를 아우르는 보편적인 내비게이션 바가 없고, 기능이 여러 화면과 제스처 속에 분산되어 있었다. - 이런 구조는 사용성을 떨어뜨리지만, 디자인의 목표가 항상 ‘가장 쉽게 이해되는 화면’을 만드는 데 있는 것은 아니라는 점을 보여준다. - Bobby Goodlatte는 디자인이란 픽셀이나 미적 완성도보다 문제 해결에 관한 것이며, 때로는 덜 다듬어진 공간이 더 적절한 해결책이 될 수 있다고 설명한다. ## 숨겨진 기능이 만든 사용자 문화 - Snapchat의 일부 기능은 화면에 명확히 드러나지 않아 다른 사용자에게 배워야 했다. - 라이브 영상 통화나 필터 기능처럼 숨겨진 기능을 친구가 직접 알려주면서 사용자 사이에 일종의 ‘부족 지식(tr ial knowledge)’이 형성됐다. - 앱 사용법을 아는 사람과 모르는 사람 사이에 경계가 생기면서, Snapchat은 부모 세대가 쉽게 접근하기 어려운 젊은 사용자만의 공간이 되었다. - 복잡하고 정돈되지 않은 인터페이스가 오히려 젊은 세대의 혼란스럽고 비정형적인 일상과 잘 맞는다는 해석도 제시된다. ## 카메라 중심 설계와 모바일 UX의 혁신 - Snapchat은 앱을 실행하면 피드가 아니라 카메라가 먼저 열리도록 설계한 최초의 대형 소셜 앱 중 하나였다. - 이 선택은 다른 사람의 콘텐츠를 소비하는 데서 벗어나, 사용자가 직접 사진과 영상을 만들도록 유도했다. - 화면을 스와이프해 앱의 다른 영역으로 이동하는 다차원적 탐색은 기존 메뉴 버튼보다 모바일 환경에 더 자연스러울 수 있었다. - 더블 탭, 스와이프, 길게 누르기 같은 터치 동작을 독자적인 명령어처럼 활용했다. - 이미지 위에서 필터를 바로 끌어오는 방식도 기존 앱의 썸네일 목록 중심 필터 UI와 달랐다. - 카메라를 열자마자 재미있고 창의적인 행동을 제안한다는 점이 Snapchat의 핵심 차별점이었다. ## ‘직관적인 UI’에서 ‘공유 가능한 UI’로 - Greylock의 Josh Elman은 Snapchat의 접근을 ‘공유 가능한 UI(shareable UI)’라고 설명한다. - 모든 제품이 처음부터 직관적일 필요는 없으며, Facebook이나 Excel도 처음 사용하는 사람에게는 즉시 이해되지 않았다는 논리다. - 중요한 것은 사용자가 혼자 메뉴를 헤매지 않고, 친구에게 기능을 묻고 사용법을 공유할 만큼 강력하고 매력적인 제품을 만드는 것이다. - 특히 소셜 앱에서는 기능을 알려주는 행위 자체가 사용자 간 관계와 참여를 강화할 수 있다. - Snapchat의 필터처럼 누군가 직접 보여줘야 알 수 있는 기능은 단순한 사용법이 아니라 사용자 확산 방식으로 작동했다. ## 의도된 전략인가, 우연한 성공인가 - 인터뷰에 참여한 디자이너들은 Snapchat의 성공을 완전히 계획된 디자인 전략으로 보지는 않았다. - 일부는 여러 가지 서투른 디자인이 우연히 하나의 앱에 모였고, 이후 젊은 세대의 취향에 맞았다고 평가했다. - 반대로 결과적으로는 기존 디자인 규칙을 깨면서 새로운 사용 행태와 모바일 소셜 경험을 만들어냈다. - Snapchat의 사례는 좋은 디자인이 반드시 정돈되고 예측 가능하며 즉시 이해 가능한 디자인과 같지는 않다는 점을 보여준다. 제품을 설계할 때는 무조건 직관성을 극대화하기보다, 사용자가 친구에게 알려주고 싶을 만큼 강력한 기능과 문화를 만들 수 있는지도 고려할 만하다. 다만 숨겨진 UI는 제품의 핵심 기능까지 가리지 않도록 설계해야 하며, Snapchat의 성공을 그대로 모방하기보다는 타깃 사용자와 서비스 목적에 맞게 적용해야 한다.

원문 읽기(새 탭에서 열림)

사용자 경험사용자 인터페이스interaction-designmobile-design+3

figma·2017년 3월 5일·3분 읽기큐레이션 요약

순서가 지정된 시퀀

Figma는 실시간 협업에서 여러 사용자가 객체의 순서를 동시에 변경해도 모든 클라이언트가 동일한 최종 상태에 도달하도록 해야 했다. 처음에는 Operational Transformation(OT)을 고려했지만, 텍스트 편집에 필요한 고급 기능과 구현 복잡도가 Figma에는 과도하다고 판단했다. 대신 각 객체에 순서를 나타내는 분수형 인덱스를 부여하고 정렬하는 방식을 사용해, 단순성과 안정성을 확보했다. ## 실시간 순서 편집의 문제 - Figma의 문서, 그룹, 컴포넌트 등은 자식 객체의 순서가 있는 목록을 가진다. - 사용자는 객체를 삽입·삭제하거나 드래그해 순서를 변경할 수 있다. - 각 클라이언트는 편집을 즉시 로컬에 적용한 뒤 서버로 전송한다. - 네트워크 상황에 따라 각 클라이언트가 작업을 서로 다른 순서로 받을 수 있다. - 따라서 작업 적용 순서가 달라도 모든 클라이언트의 문서가 동일해지는 eventual consistency가 필요하다. ## Operational Transformation의 접근법 - OT는 동시 작업이 서로의 위치와 의미를 깨뜨리지 않도록 작업을 변환한다. - 예를 들어 텍스트 `bcde`에 대해 한 사용자가 앞에 `x`를 삽입하고 다른 사용자가 `bc`를 삭제하면, 삭제 위치를 삽입만큼 보정한다. - 서버와 클라이언트는 다른 작업을 기준으로 각 연산을 변환해 같은 결과를 만든다. - OT는 오래된 협업 편집 알고리즘이며 텍스트 편집기에서 널리 사용됐다. ### OT의 장단점 - 장점 - 매우 큰 시퀀스에서도 성능과 메모리 효율이 좋다. - 같은 위치에 동시에 삽입된 문자열을 서로 끼워 넣지 않고 연속된 덩어리로 정렬할 수 있다. - 단점 - 구현과 정확성 검증이 어렵다. - 일반적으로 객체 이동을 삭제 후 삽입으로 처리한다. - 연산 종류가 늘어날수록 모든 연산 쌍 간 변환 규칙이 필요해 복잡도가 크게 증가한다. - Figma는 거대한 시퀀스나 삽입 결과의 비인터리빙이 필요하지 않았고, 객체 이동이 빈번했기 때문에 OT를 선택하지 않았다. ## 분수형 인덱싱 - 각 객체에 `0과 1 사이의 위치값`을 부여하고, 이 값을 기준으로 자식 객체를 정렬한다. - 두 객체 사이에 삽입할 때는 양쪽 인덱스의 평균을 새 객체의 인덱스로 사용한다. - 예를 들어 `0.2`와 `0.6` 사이에 삽입하면 `0.4`를 사용할 수 있다. - 인덱스는 64비트 부동소수점 대신 임의 정밀도 분수로 저장해 반복 삽입으로 정밀도가 고갈되는 문제를 피한다. - Figma는 인덱스를 문자열로 저장하고 문자열 조작으로 평균을 계산한다. - 저장 공간을 줄이기 위해 `0.`을 생략하고, 숫자만이 아니라 전체 ASCII 범위를 사용한 base 95 표현을 적용한다. ## 분수형 인덱싱의 장단점 - 장점 - 알고리즘이 단순하고 이해·구현하기 쉽다. - 객체를 이동할 때 위치값 하나만 변경하면 된다. - 이동을 삭제와 삽입으로 나눌 필요가 없다. - 단점 - 반복적인 삽입과 재배치로 인덱스 문자열이 길어질 수 있다. - 여러 클라이언트가 같은 위치에 동시에 삽입하면 새 객체들이 서로 섞일 수 있다. - 동일한 두 인덱스 사이의 평균을 다시 계산할 수 없다. ## 동시 삽입 충돌 처리 - 동일한 위치에 두 클라이언트가 동시에 객체를 삽입하면 두 객체가 같은 인덱스를 가질 수 있다. - 서버가 두 객체에 동일한 위치값이 생기지 않도록 두 번째 삽입에 고유한 위치를 부여한다. - 인덱스 길이 증가는 Figma에서 객체 수와 사용자 활동이 실용적인 범위로 제한되므로 큰 문제가 되지 않는다. - 디자인 문서에서는 동시에 삽입된 객체가 서로 겹치지 않는 경우가 많아, 순서가 일부 인터리빙되는 것도 허용 가능하다. Figma의 사례는 가장 정교한 알고리즘보다 제품의 요구사항에 맞는 단순한 알고리즘이 더 유리할 수 있음을 보여준다. 대규모 텍스트 편집처럼 강한 순서 보장이 필요하지 않다면, 분수형 인덱싱은 구현·유지보수 비용이 낮고 객체 이동에도 효율적인 실용적 선택이다.

원문 읽기(새 탭에서 열림)

분산 시스템operational-transformationeventual-consistencyfractional-indexing+3

figma·2017년 3월 1일·3분 읽기큐레이션 요약

디자이너가 정치적 변화

디자이너는 시각적 결과물을 만드는 데 그치지 않고, 정치·사회적 변화를 촉진하는 실질적인 역할을 할 수 있다. 2016년 미국 대선 이후 여러 디자이너가 무상 디자인, 캠페인, 작품 판매, 풍자 작업 등을 통해 소수자와 시민단체를 지원했다. 글은 좋은 디자인이 조직의 신뢰도와 영향력을 높이며, 디자이너 개인도 자신의 직업과 창작물을 정치적 참여의 수단으로 활용할 수 있다고 말한다. ## 선거 이후 행동으로 전환한 디자이너들 - 트럼프 당선 다음 날, 포틀랜드의 디자인 에이전시 **The Beauty Shop**은 여성, 유색인종, 히스패닉계, 무슬림, 이민자, LGBTQ 커뮤니티를 대표하는 단체에 무료 디자인을 제공하겠다고 발표했다. - 게시물 공개 후 이틀 만에 팔로워가 네 배로 늘었고, 약 300명의 디자이너와 스튜디오가 참여 의사를 밝혔다. - 이들은 디자이너와 풀뿌리 조직을 연결하는 연합체 **Visible**을 만들었다. - 초기 협력 단체에는 낙태 접근권을 지원하는 Iowa Abortion Access Fund, 의료 문제를 다루는 Nightingale, 예멘과 미국의 관계를 연구하는 Yemen Peace Project 등이 포함됐다. - 해킹 공격을 받은 Yemen Peace Project처럼, 디자인은 미적 개선뿐 아니라 조직의 복구와 활동 지속에도 직접 기여할 수 있었다. ## 디자인이 사회운동의 신뢰도를 높이는 방식 - 좋은 로고와 시각 체계는 단체를 더 합법적이고 신뢰할 만한 조직처럼 보이게 한다. - 디자인은 사회운동의 구조와 메시지를 정리해 사람들이 단체의 목적을 이해하고 참여하도록 돕는다. - 따라서 디자이너의 기여는 단순히 “예쁜 결과물”을 만드는 일이 아니라, 시민단체가 목표를 달성할 수 있는 기반을 구축하는 일이다. - 글은 디자이너가 사회를 직접 구한다는 식의 낙관을 경계하면서도, 전문 기술이 운동의 성공 가능성을 높일 수 있다고 설명한다. ## 긍정적 가치와 공통 기반을 보여주는 캠페인 - **Creative Action Network(CAN)**은 National Parks Conservation Association, New York Public Library 등과 협력해 사회적 목적의 디자인 캠페인을 진행한다. - 트럼프 행정부 출범 이후에는 “미국을 위대하게 만드는 것”을 주제로 포스터를 제작했다. - 목표는 새 행정부의 첫 100일 동안 하루에 한 장씩 포스터를 공개하는 것이었다. - 포스터는 재즈, 종교의 자유 등 미국 사회가 지켜야 할 다양한 가치를 다뤘다. - 저항과 protest뿐 아니라, 사람들이 더 많이 보고 싶어 하는 가치를 축하하고 공통점을 만드는 것 역시 정치적 행동이라는 관점을 제시한다. ## 예술 작품을 통한 직접적인 모금 - 일러스트레이터 **Hallie Bateman**은 정치적 현실이 바뀐 뒤 자신의 작품이 새로운 시대를 충분히 반영하고 있는지 고민했다. - 그는 전쟁 시기의 예술가와 예술의 역할을 다룬 책을 읽으며 자신의 창작 방향을 재검토했다. - 이후 어두운 숲길을 달리는 장면을 그린 작품을 한정 판매하고, 인쇄비를 제외한 수익을 Planned Parenthood에 기부했다. - 모금 목표였던 2,000달러를 달성했으며, 이후 Sierra Club을 위한 작품 판매도 진행했다. - 명확한 정치 포스터가 아니더라도 작품 판매와 기부를 결합하면 예술 자체가 사회운동의 재원이 될 수 있음을 보여준다. ## 풍자와 대중매체를 활용한 정치적 메시지 - 전 Facebook 디자이너 **Ben Barry**는 The New York Times의 의뢰로 트럼프를 풍자하는 가짜 구인 지원서를 디자인했다. - 그는 초등학교 현장학습 안내문처럼 보이게 하거나 러시아 내부 문서처럼 보이게 하는 등 여러 시각적 형식을 제안했다. - 최종안은 트럼프의 이미지와 연상되는 크고 화려한 금색 스타일로 제작됐다. - 이 사례는 디자이너가 신문, 소셜미디어 등 대중적인 매체의 영향력을 활용해 정치적 비판을 효과적으로 전달할 수 있음을 보여준다. 디자이너는 자신의 전문성을 무상 지원, 캠페인 제작, 기부 상품, 풍자 콘텐츠 등 다양한 방식으로 사회적 목적에 연결할 수 있다. 중요한 것은 모든 작업이 거대한 정치 프로젝트일 필요는 없으며, 자신이 가진 기술과 창작 방식을 현실적인 범위에서 지속적으로 활용하는 것이다.

원문 읽기(새 탭에서 열림)

web-designgraphic-designillustrationsocial-media+1

figma·2017년 2월 14일·3분 읽기큐레이션 요약

Figma의 팀 라이

Figma의 Team Libraries는 여러 파일과 팀원이 동일한 컴포넌트를 공유하고 동기화하도록 해 디자인 시스템 구축을 돕는 기능이다. 기존처럼 파일마다 심볼을 복사해 수동으로 교체하는 방식의 불일치 문제를 해결하고, 컴포넌트를 게시·삽입·업데이트하는 흐름으로 단일 진실 공급원을 유지한다. 이를 통해 디자인 시스템을 더 빠르고 일관되게 확장할 수 있다. ## 기존 디자인 도구의 한계 - 전통적인 디자인 도구는 사진 편집, 일러스트 제작, 정적인 화면 구성에 초점을 맞췄다. - 실제 애플리케이션의 반응형 동작이나 플랫폼의 제약 조건을 충분히 표현하지 못했다. - 디자인 시스템을 하나의 마스터 파일에서 관리하더라도 컴포넌트를 다른 파일로 복사하면 서로 다른 버전이 된다. - 작은 변경도 여러 문서를 찾아 각 심볼과 오버라이드를 수동으로 수정해야 했다. - Facebook, Google, Airbnb 같은 기업은 이러한 한계를 보완하기 위해 자체 디자인 시스템 도구와 전담 인력을 구축했다. ## Figma가 제시한 기반 - Figma는 시각 디자인과 동적인 사용자 인터페이스 설계를 연결하는 것을 목표로 했다. - 벡터 편집, 시스템 동작에 대응하는 제약 조건, 재사용 가능한 동적 컴포넌트를 제공해 디자인 시스템의 기반을 마련했다. - Team Libraries를 통해 이 컴포넌트를 여러 파일과 팀원 사이에서 공유할 수 있게 했다. - 웹 기반 구조 덕분에 파일 간 동기화 지연이 거의 없고, 여러 기기와 플랫폼을 위한 레이아웃을 일관된 규칙으로 설계할 수 있다. ## 엔지니어링 원칙을 반영한 디자인 시스템 - React 같은 프레임워크처럼 애플리케이션을 명확히 정의된 작은 단위로 구성하는 방식을 디자인에도 적용했다. - 재사용 가능하고 유지보수하기 쉬운 구조는 제품 개발 주기 전체의 효율을 높인다. - 다만 프로그래밍 개념을 그대로 가져오기보다 디자이너가 쉽게 사용할 수 있도록 인터페이스와 작업 흐름을 단순화했다. ## 게시(Publish): 단일 진실 공급원 만들기 - 파일에서 컴포넌트를 선택하고 Inspector의 **Add to Library**를 눌러 라이브러리에 추가한다. - 여러 컴포넌트를 선택한 뒤 변경 사항을 검토하고 팀 라이브러리에 게시한다. - 라이브러리와 원본 파일을 분리해 디자인 시스템의 변경 권한을 통제할 수 있다. - 원본 파일에 편집 권한이 있는 사람만 소스 컴포넌트를 수정할 수 있다. - 원본 파일을 볼 수 있는 사람은 게시된 컴포넌트를 사용할 수 있지만 규칙 자체를 변경할 수는 없다. - 예를 들어 프로덕션 디자이너는 아이콘을, 브랜드 디자이너는 색상 문서를 관리하고 다른 팀원은 이를 재사용할 수 있다. ## 삽입(Insert): 여러 파일에서 컴포넌트 재사용 - 라이브러리에 게시된 컴포넌트는 원본 파일을 볼 권한이 있는 팀원에게 제공된다. - 각 파일의 툴바에서 컴포넌트 도구를 선택해 공유 컴포넌트를 삽입한다. - 컴포넌트 안에 다른 컴포넌트를 중첩할 수 있다. - 개별 요소로 모듈을 구성한 뒤, 이를 더 복잡한 화면과 사용자 흐름에서 재사용할 수 있다. - 깊게 중첩된 컴포넌트도 원본과 연결되므로 단일 진실 공급원을 예측 가능하게 유지할 수 있다. ## 업데이트(Update): 변경 사항의 동기화 - 브랜드 가이드나 UI 자산을 변경할 때 기존 컴포넌트를 수정하고 다시 게시한다. - 재게시 전 확인 단계를 거치며, 이전 버전과 무엇이 달라졌는지 시각적 diff로 확인할 수 있다. - 원본 파일에서 컴포넌트를 삭제한 뒤 게시하면 팀 라이브러리에서도 해당 컴포넌트가 사라진다. - 따라서 팀에는 현재 유효한 디자인 시스템 요소만 공유된다. - 공유 컴포넌트의 변경이 여러 탐색 작업에 영향을 줄 수 있으므로, 작업 손실을 막기 위한 추가 확인 절차를 둔다. ## 실용적인 결론 Team Libraries는 디자인 시스템을 복사본이 아니라 연결된 컴포넌트 구조로 관리하게 해준다. 팀에서는 원본 파일의 편집 권한을 제한하고, 색상·아이콘·버튼·복합 모듈을 라이브러리로 게시한 뒤 변경 사항을 검토하며 재게시하는 운영 방식을 마련하는 것이 좋다.

원문 읽기(새 탭에서 열림)

Figma디자인 시스템사용자 인터페이스React+3

figma·2016년 12월 7일·3분 읽기큐레이션 요약

피그마 컴포넌트

Figma의 컴포넌트는 소프트웨어 개발의 composition, inheritance, override 개념을 디자인에 적용해 복잡한 UI를 일관되고 효율적으로 설계하도록 돕는다. 원본 컴포넌트를 수정하면 모든 인스턴스에 변경 사항이 반영되지만, 각 인스턴스는 필요한 속성을 독립적으로 재정의할 수 있다. 이를 통해 반복 작업을 줄이면서도 디자인 시스템의 일관성과 창의적인 변형을 동시에 확보할 수 있다. ## 디자인에 컴포넌트를 적용하는 이유 - 복잡한 화면을 더 작은 재사용 단위로 나누어 이해하고 구성할 수 있다. - 주소록의 연락처 행처럼 반복되는 UI를 한 번만 설계한 뒤 여러 곳에서 재사용할 수 있다. - 동일한 컴포넌트를 사용하면 글자 크기, 간격, 아이콘, 그래픽 등의 시각적 일관성을 유지하기 쉽다. - 컴포넌트는 단순한 복사본이 아니라 동일한 원본을 참조하는 인스턴스이므로, 원본 변경 사항이 관련 디자인에 자동으로 반영된다. ## Figma가 지향한 컴포넌트 설계 - 초보자도 쉽게 배울 수 있어야 한다. - 고급 사용자에게 충분히 강력해야 한다. - 디자인 과정 전반에서 유연하게 활용할 수 있어야 한다. - 체계적으로 디자인하더라도 창의적인 작업을 방해하거나 불필요한 작업 절차를 늘리지 않아야 한다. - 디자인 시스템 구축이 속도와 일관성을 높이는 수단이 되어야 하며, 새로운 문제를 해결하는 데 제약이 되어서는 안 된다. ## 컴포넌트와 인스턴스의 동작 방식 - 선택한 프레임이나 객체에 “Create Component”를 적용하면 컴포넌트가 생성된다. - 컴포넌트를 복제하거나 Alt 키로 드래그하거나 복사·붙여넣기하면 일반 복사본이 아니라 인스턴스가 만들어진다. - 인스턴스는 캔버스에서 위치를 독립적으로 가질 수 있지만, 기본적으로 원본 컴포넌트의 구조와 속성을 공유한다. - 원본 컴포넌트의 변경 사항은 모든 인스턴스에 즉시 반영된다. - 인스턴스 내부의 일부 속성은 관리와 유지보수를 위해 제한될 수 있으며, 특히 내부 객체의 위치와 크기 같은 속성이 대표적이다. ## 스타일 및 속성 오버라이드 - 인스턴스에서 변경한 값은 원본을 대체하는 것이 아니라 해당 인스턴스에만 적용되는 오버라이드로 취급된다. - 예를 들어 특정 인스턴스의 채우기 색상을 진회색으로 바꾸거나, 다른 인스턴스의 선 색상과 두께를 빨간색·6px로 설정할 수 있다. - 원본 컴포넌트를 수정해도 인스턴스에서 직접 재정의한 속성은 유지된다. - 재정의하지 않은 속성은 원본 컴포넌트의 최신 상태를 계속 반영한다. - 인스턴스 내부의 하위 레이어와 그 속성도 오버라이드할 수 있어 다양한 변형을 만들 수 있다. - 변경 사항을 제거하려면 “Reset Instance”를 사용해 원본 컴포넌트의 상태로 되돌릴 수 있다. ## 중첩 컴포넌트로 복잡한 UI 구성 - 컴포넌트 안에 다른 컴포넌트의 인스턴스를 포함할 수 있다. - 여러 인스턴스를 조합해 더 복잡한 동작과 UI 구조를 만들 수 있다. - 기존 인스턴스를 포함한 객체를 다시 컴포넌트로 만들 수도 있다. - 작은 단위의 컴포넌트를 계층적으로 조합하면 대규모 디자인 시스템을 관리하기 쉬워진다. ## 제약 조건과의 결합 - 컴포넌트는 Figma의 다른 기능과 함께 사용할 때 더 큰 표현력을 갖는다. - 제약 조건을 적용하면 화면 크기나 객체 위치가 바뀔 때 내부 요소가 어떻게 반응할지 정의할 수 있다. - 따라서 단순히 같은 UI를 복제하는 것을 넘어, 다양한 크기와 상황에 대응하는 반응형 디자인을 구성할 수 있다. 실무에서는 반복되는 UI를 먼저 컴포넌트로 만들고, 인스턴스별 차이는 오버라이드로 최소한만 적용하는 방식이 적합하다. 공통 구조와 스타일은 원본에서 관리하고, 개별 화면의 예외적인 요구만 인스턴스에서 변경하면 유지보수성과 디자인 일관성을 함께 확보할 수 있다.

원문 읽기(새 탭에서 열림)

Figma디자인 시스템ReactAndroid+4

figma·2016년 11월 16일·3분 읽기큐레이션 요약

벡터 네트워크의 삭제 및 복구 |

Figma의 “삭제 후 복구(Delete and Heal)”는 정점을 단순히 제거하는 기능이 아니라, 주변 선과 곡률을 최대한 보존하며 벡터 구조를 재구성하는 작업이다. 단순한 경로에서는 인접 정점을 연결하면 되지만, 곡선과 벡터 네트워크에서는 베지어 곡선 근사와 그래프 구조를 함께 고려해야 한다. Figma는 이 기능을 통해 복잡한 벡터 네트워크에서도 자연스러운 편집 결과를 제공한다. ## 삭제와 삭제 후 복구의 차이 - 일반적인 정점 삭제는 해당 정점에 연결된 모든 선분과 그 선분에 닿는 채우기 영역을 함께 제거한다. - “삭제 후 복구”는 삭제된 정점 양쪽의 구조를 새 선으로 연결해 기존 형태를 유지하려는 기능이다. - 한쪽에만 선이 연결된 정점은 연결할 대상이 없으므로 선을 제거한다. - 삼각형처럼 정점 수가 줄어드는 경우에도 결과가 항상 같지는 않다. - 어떤 경우에는 두 정점 사이의 단일 선으로 축소된다. - 다른 경우에는 두 개의 선이 유지될 수 있다. - Figma는 정점과 선의 연결 관계에 따라 결과를 다르게 처리한다. ## 곡선의 형태를 보존하는 복구 - 곡선 위의 정점을 삭제하면 단순히 양 끝점을 직선으로 연결할 경우 기존 곡률이 사라진다. - 다른 도구는 인접 정점의 곡률 핸들 위치를 그대로 유지하는 경우가 많다. - Figma는 원래 곡선을 최대한 근사하도록 인접 정점의 제어 핸들을 조정한다. - 각 곡선 선분은 cubic Bézier curve로 표현된다. - 복구 문제는 다음 두 개의 cubic Bézier 곡선을 하나의 곡선으로 근사하는 문제로 바뀐다. - 첫 번째 곡선: `(P0, P1, P2, P3)` - 두 번째 곡선: `(P3, P4, P5, P6)` - 새 곡선: `(P’0, P’1, P’2, P’3)` - 벡터 네트워크의 나머지 부분을 변경하지 않기 위해 새 곡선의 양 끝점은 고정한다. - `P’0 = P0` - `P’3 = P6` - 따라서 계산해야 하는 것은 새 곡선의 제어점 `P’1`, `P’2`다. ## 베지어 곡선 근사 알고리즘 - 먼저 두 기존 곡선을 따라 여러 샘플 점을 생성한다. - cubic Bézier의 매개변수 `t`에 값을 대입해 곡선 위의 점을 계산한다. - 두 곡선이 공유하는 끝점은 중복해서 세지 않는다. - 예를 들어 각 구간에 여러 `t` 값을 적용하면 전체 연결 곡선 위의 샘플 점 목록을 얻을 수 있다. - 생성된 점들을 하나의 cubic Bézier 곡선으로 피팅한다. - Figma는 Philip J. Schneider의 “An Algorithm for Automatically Fitting Digitized Curves” 알고리즘과 관련 구현을 활용한다. - 결과적으로 삭제 전의 곡률을 완벽히 복원하지는 않지만, 시각적으로 자연스러운 단일 곡선을 얻는다. ## 벡터 네트워크와 그래프 기반 삭제 - Figma의 벡터 객체는 일반적인 순차 경로가 아니라 무방향 그래프로 표현된다. - 더 정확히는 각 선 자체의 식별성을 가진 무방향 멀티그래프다. - 따라서 하나의 정점에 최대 두 개의 선만 연결된다는 경로 기반 도구의 가정을 사용할 수 없다. - 삭제 대상 정점에 세 개 이상의 선이 연결될 수 있으며, 이 경우 어떤 선끼리 연결할지 결정해야 한다. - 연결된 선의 개수가 홀수라면 모든 인접 선을 제거한다. - 남는 선을 자연스럽게 짝지을 방법이 없기 때문이다. - 연결된 선의 개수가 짝수라면 선들을 쌍으로 묶어 새 선을 만든다. - 이때 “서로 반대편에 있는 선”을 정의하기 위해 정점에서 뻗어나가는 선을 각도 기준으로 정렬한다. - 정렬된 방향을 바탕으로 서로 마주 보는 선끼리 연결해 네트워크 구조를 복구한다. ## 실용적인 결론 벡터 편집기의 삭제 기능은 단순한 데이터 제거가 아니라, 그래프 연결성·곡선 근사·사용자 기대를 함께 처리하는 기하학적 재구성 문제다. 특히 벡터 네트워크를 지원하려면 정점 차수가 2를 넘는 상황과 곡선 제어점까지 고려해야 하며, Bézier 샘플링과 곡선 피팅을 결합하는 방식이 실용적인 해결책이 된다.

원문 읽기(새 탭에서 열림)

vector-graphicsbezier-curvescomputational-geometrygraph-theory+2

figma·2016년 11월 6일·4분 읽기큐레이션 요약

Emscripten으로 데이터

Figma의 저장 파일이 간헐적으로 손상되는 문제는 재현이 어려운 비결정적 이벤트와 C++의 메모리 안전성 문제 때문에 장기간 해결되지 않았다. 일반적인 메모리 디버깅 도구로 원인을 찾지 못한 뒤, 키보드·마우스 입력을 생성하는 퍼저로 이벤트를 반복 실행해 문제를 재현하는 데 성공했다. 최종 수정은 FlatBuffers의 잘못된 메모리 접근을 고치는 세 줄짜리 커밋이었지만, 원인을 추적하는 과정에서 Emscripten과 브라우저의 메모리 모델까지 분석해야 했다. ## 간헐적으로 발생한 저장 파일 손상 - Figma는 때때로 다시 읽을 수 없는 잘못된 저장 파일을 생성했다. - 당시 저장 형식은 다음 구조였다. - ZIP 파일 - 내부에 Google FlatBuffers로 인코딩된 문서 - 파일의 전체 바이트 구조는 대체로 정상처럼 보였지만, 뒤쪽 데이터를 가리키는 일부 오프셋이 0으로 변해 있었다. - 데이터가 원래 위치가 아닌 곳에 기록된 현상은 다음과 같은 메모리 안전성 위반을 의심하게 했다. - 초기화되지 않은 메모리 사용 - 해제된 메모리 접근(use-after-free) - 배열 범위를 벗어난 읽기·쓰기 ## C++ 메모리 오류의 추적 난이도 - Figma 에디터는 C++로 작성되어 있었다. - C++는 다음과 같은 장점 때문에 그래픽 소프트웨어에 적합하다. - FreeType, HarfBuzz, Skia 같은 저수준 라이브러리 활용 - 하드웨어와 직접 연결되는 언어 기능 - 성숙한 디버깅 및 최적화 도구 - 높은 성능과 세밀한 메모리 제어 - 반면 C++는 언어 자체가 메모리 안전성을 보장하지 않는다. - 복잡한 언어 설계, 오류가 발생하기 쉬운 표준 라이브러리 API, C에서 물려받은 레거시가 결합되어 대규모 프로젝트에서 메모리 오류를 완전히 피하기 어렵다. ## 일반적인 디버깅 방법의 한계 개발팀은 다음과 같은 방법을 시도했지만 문제를 발견하지 못했다. - 메모리를 해제하지 않아 use-after-free 가능성 제거 - macOS의 malloc 디버깅 옵션 활성화 - Valgrind가 보고한 모든 문제 수정 - 컴파일러 업그레이드 - Clang 정적 분석기가 발견한 문제 수정 이런 도구들은 많은 오류를 찾아내지만, 실행 조건에 따라 드물게 발생하거나 특정 메모리 배치에서만 나타나는 문제까지 항상 잡아내지는 못한다. ## 이벤트 기록과 퍼징으로 재현성 확보 - 문제의 핵심은 비동기 타이머와 네트워크 이벤트 등 웹 앱의 비결정성이었다. - 해결 전략은 다음과 같았다. - 사용자 이벤트를 기록한다. - 동일한 이벤트를 순서대로 재생한다. - 문제가 발생할 때까지 세션을 반복 실행한다. - 이벤트를 무작위로 제거하면서도 문제가 유지되는 최소 테스트 케이스를 만든다. - 실제 사용자 세션에는 너무 다양한 이벤트가 포함되므로, 범위를 키보드와 마우스 이벤트로 제한했다. - 실제 세션을 수집하는 대신 퍼저가 무작위 키보드·마우스 입력을 생성하도록 했다. - 며칠 동안 실행한 결과 여러 건의 저장 실패를 재현할 수 있었고, 이후 반복 가능한 입력 시퀀스를 기반으로 본격적인 디버깅이 가능해졌다. ## Emscripten이 C++를 브라우저에서 실행하는 방식 - Figma는 플러그인 없이 브라우저에서 실행되는 웹 앱이다. - C++ 코드는 Emscripten을 통해 JavaScript로 컴파일된다. - JavaScript는 기본적으로 메모리 안전성과 가비지 컬렉션을 제공하지만, WebGL과 Typed Arrays 덕분에 C의 메모리 모델을 흉내 낼 수 있다. - Typed Array의 특징은 다음과 같다. - 고정된 크기를 가진다. - 모든 원소가 같은 타입이다. - 여러 Typed Array가 하나의 ArrayBuffer를 공유할 수 있다. - 같은 메모리를 `Float32Array`와 `Uint8Array` 등 서로 다른 타입으로 해석할 수 있기 때문에 C/C++의 포인터 캐스팅과 유사한 동작을 구현할 수 있다. ## Emscripten의 포인터와 메모리 변환 Emscripten은 C++의 주요 요소를 JavaScript 구조로 변환한다. - 포인터 읽기: Typed Array 읽기 - 포인터 쓰기: Typed Array 쓰기 - 레지스터: JavaScript 지역 변수 - 스택: `STACKTOP`이라는 스택 포인터로 관리 - 타입 변환: 동일한 ArrayBuffer를 공유하는 Typed Array를 통해 구현 - 생성된 코드는 asm.js라는 제한적인 JavaScript 부분집합을 사용해 JIT 컴파일러가 타입을 추론하고 빠르게 최적화하도록 한다. - 예를 들어 `+$value`는 값을 double로 취급하도록 JIT에 힌트를 주며, 비트 연산은 정수 연산으로 최적화될 가능성을 높인다. ## 실용적인 결론 재현이 어려운 데이터 손상 문제는 도구를 하나씩 추가하는 것만으로 해결되지 않을 수 있다. 비결정적 입력을 통제하고, 퍼징과 이벤트 재생으로 실패 조건을 반복 가능하게 만드는 것이 핵심이며, 컴파일된 실행 환경에서는 원본 언어뿐 아니라 Emscripten의 메모리 모델과 런타임 동작까지 함께 이해해야 한다.

원문 읽기(새 탭에서 열림)

JavaScriptwebglc-plus-plusmemory-safety+4

figma·2016년 9월 27일·4분 읽기큐레이션 요약

Figma의 멀티플레이어 편집

Figma는 파일을 내려받아 로컬에서 편집한 뒤 전체 문서를 저장하는 방식이 협업 환경과 근본적으로 맞지 않는다는 문제를 해결하기 위해 실시간 멀티플레이어 편집을 도입했다. 사용자의 변경 사항을 서버에 전송하고 실시간으로 다른 사용자에게 브로드캐스트함으로써 최신 버전 보장, 덮어쓰기 방지, 원격 협업과 리뷰 개선을实现했다. 구현 과정에서는 실행 취소·다시 실행, 충돌 해결, 성능과 파일 형식 개선 등 복잡한 기술적 과제를 해결해야 했다. ## 기존 저장 방식의 한계 - 초기 Figma는 문서를 브라우저로 내려받아 로컬에서 편집하고, 일정 주기마다 전체 문서를 다시 업로드했다. - 개인 사용자에게는 구현과 이해가 쉬웠고, Dropbox 같은 동기화 서비스와도 유사해 익숙한 방식이었다. - 하지만 팀 기능이 추가되면서 다음 문제가 발생했다. - 여러 사용자가 서로의 작업을 모르고 저장해 변경 사항을 덮어씀 - 저장이 완료되기 전에 공유한 링크를 열면 이전 버전이 표시됨 - 버전 기록에는 모든 저장이 남았지만, 협업 중 발생하는 혼란 자체를 막지는 못함 - 한 명씩 편집권을 넘기는 ‘baton-passing’ 방식도 검토했지만, 동시 편집만큼 단순하고 자연스럽지는 않았다. ## 실시간 멀티플레이어 모델 - 각 사용자의 변경 사항을 서버로 보내고, 서버가 이를 다른 사용자에게 실시간으로 전달한다. - 서로 다른 객체나 속성에 대한 변경은 독립적으로 처리한다. - 동일 객체의 동일 속성을 동시에 수정하면 최신 변경을 적용하는 방식으로 충돌을 해결한다. - 이 구조를 통해 사용자는 항상 최신 문서를 보고, 편집 중인 파일 버전을 따로 확인하거나 충돌을 조정할 필요가 줄어든다. - Figma는 이 기능이 협동 멀티플레이어 게임과 비슷하다는 점에서 “multiplayer”라는 이름을 붙였다. ## 멀티플레이어 실행 취소와 다시 실행 - 단일 사용자 환경에서는 실행 취소가 “내가 방금 한 작업을 되돌리는 것”으로 정의되지만, 여러 사용자가 같은 객체를 수정하면 의미가 복잡해진다. - 다른 사용자의 변경 이후 실행 취소를 수행할 때 자신의 과거 변경을 다시 덮어써서는 안 된다. - Figma는 다음 원칙을 기준으로 동작을 설계했다. - 사용자가 여러 작업을 실행 취소한다. - 중간 상태에서 무언가를 복사한다. - 다시 실행해 현재 상태로 돌아온다. - 이 과정만으로 문서 내용이 달라져서는 안 된다. - 단순히 과거 상태를 복원하는 방식이 아니라, 다른 사용자의 후속 변경을 보존하는 방향으로 redo를 설계해야 했다. ## 충돌 해결의 복잡성 - 한 객체의 여러 속성이 함께 변경되어야 하는 경우, 특정 속성 하나의 변경만으로 전체 상태를 덮어쓰지 않도록 세밀한 병합이 필요했다. - 겉보기에는 한 객체만 수정하는 작업이 실제로는 다른 객체에도 영향을 줄 수 있었다. - 이 때문에 서로 무관해 보이는 객체를 두 사용자가 동시에 편집해도 충돌이 발생할 수 있었다. - 일부 레이아웃 기능은 이러한 협업 상황에 맞게 동작 방식을 수정해야 했다. - 단순한 “최신 변경 우선”만으로는 충분하지 않고, 작업 간 의존성과 여러 객체에 걸친 부수 효과까지 고려해야 했다. ## 성능과 파일 형식 개선 - 전문 디자인 도구 수준의 실시간 협업을 위해 지속적인 측정과 성능 튜닝이 필요했다. - 기존 파일 형식은 작은 변경 사항을 효율적으로 표현하기에 적합하지 않아 파일 포맷 자체를 개편했다. - 전체 문서를 반복해서 전송하는 대신, 작은 변경 메시지를 빠르게 전달하고 처리하는 것이 중요했다. - 멀티플레이어 기능은 에디터의 핵심 구조에 영향을 주는 대규모 기술 투자였지만, 향후 협업 기능을 위한 기반이 되었다. ## 협업 경험을 단순하게 만든 UI - 멀티플레이어는 기능을 추가했지만, 기존에 사용자들이 협업을 위해 사용하던 복잡한 우회 절차를 없애 UX를 오히려 단순하게 만들었다. - 현재 문서에 참여 중인 사용자의 마우스 커서와 선택 영역을 표시한다. - 누가 문서에 있는지 확인할 수 있다. - 다른 사람이 어느 부분을 작업 중인지 알 수 있다. - 커서를 특정 객체 옆에 두어 다른 사람의 주의를 끌거나 대상을 가리킬 수 있다. - 모든 사용자는 화면 오른쪽 위에 아바타로 표시된다. - 아바타는 참여자 확인뿐 아니라 프레젠테이션에도 활용된다. - Figma는 한 명의 발표자를 강제하고 모두가 그 사람을 따라가게 하는 방식을 시험했지만, 사용자의 선택권을 제한한다고 판단했다. - 대신 다른 사용자의 아바타를 클릭해 발표를 따라가는 선택적 방식이 더 자연스럽다고 보았다. ## 실용적인 결론 실시간 협업 기능은 단순히 변경 사항을 동기화하는 문제가 아니라, 실행 취소·충돌 병합·파일 포맷·레이아웃 모델·사용자 인터페이스까지 함께 설계해야 하는 시스템 문제다. 협업 제품을 만들 때는 기존의 개인용 저장 모델에 기능을 덧붙이기보다, 처음부터 동시 편집과 사용자 간 맥락 공유를 핵심 구조로 고려하는 것이 바람직하다.

원문 읽기(새 탭에서 열림)

Figmareal-time-collaborationoperational-transformationweb-browser+3

figma·2016년 8월 22일·3분 읽기큐레이션 요약

Figma와 Framer 통합 기능 소개

Figma는 2016년 Framer와의 통합을 발표하며, 정적 UI 디자인과 코드 기반 프로토타이핑 사이의 작업 흐름을 단순화했다. 이제 사용자는 Figma의 디자인 자산을 레이어별로 내보내고 다시 업로드하지 않고도 Framer로 한 번에 가져올 수 있다. 이를 통해 디자인 아이디어를 빠르게 코드로 구현하고, 실제 상호작용을 테스트하며, 더 나은 제품을 빠르게 출시할 수 있다는 것이 글의 결론이다. ## 정적 목업만으로는 부족한 이유 - 모바일과 다양한 디바이스 환경에서는 단순한 화면 이미지나 정적 목업만으로 사용자 경험을 충분히 표현하기 어렵다. - 디자이너에게는 다음 세 가지 능력이 필요하다. - 실제 사용될 맥락에 맞춰 디자인하기 - 사용자의 입력에 따라 화면이 어떻게 변하는지 보여주기 - 모션 그래픽과 전환 효과를 통해 상호작용의 즐거움을 표현하기 - 과거에는 After Effects 같은 영상 편집 도구를 사용하거나 HTML, JavaScript, CSS로 프로토타입을 직접 작성해야 했다. - 이러한 방식은 FTP 업로드, 모바일 기기에서 3G로 접속하기, 브라우저 호환성 문제 해결 등 창의적인 작업과 무관한 부담이 컸다. ## Figma와 Framer의 역할 - Figma는 UI를 빠르게 설계하고 반복해서 수정하는 데 강점을 가진다. - Framer는 코드를 기반으로 복잡하고 개방적인 상호작용을 구현하는 프로토타이핑 도구다. - 특히 복잡한 단일 페이지 인터랙션을 표현하는 데 적합하며, 디자이너가 코드 수준의 프로토타입을 만들 수 있도록 돕는다. - 두 도구를 함께 사용하면 Figma에서 만든 UI 아이디어를 Framer에서 빠르게 구현하고 실제 동작을 검증할 수 있다. ## 한 번의 클릭으로 디자인 자산 가져오기 - 통합 이전에는 Figma의 레이어를 하나씩 내보낸 뒤 Framer에 다시 업로드해야 했다. - 새 통합 기능을 사용하면 Framer 작업 중 Figma 자산을 한 번에 가져올 수 있다. - 반복적인 파일 변환과 업로드 과정이 줄어들어 디자인에서 프로토타이핑으로 넘어가는 시간이 단축된다. - 결과적으로 아이디어를 코드로 옮기고 테스트하는 과정이 더 빠르고 효율적으로 바뀐다. ## 디자인과 코드의 연결 - Framer 사용자 Jonathan Simcoe는 Framer의 코드 기반 구조가 표현력이 높고 제한이 적다고 설명했다. - Figma는 팀이 UI를 빠르게 설계하고 반복하는 데 도움을 주며, Framer는 이를 실제 상호작용이 포함된 프로토타입으로 발전시키는 역할을 한다. - 통합의 목표는 디자이너가 아이디어를 더 빨리 구현하고, 테스트와 개선을 반복해 더 나은 제품을 출시하도록 지원하는 것이다. - 이는 디자인 도구와 개발·프로토타이핑 도구를 분리하기보다 하나의 연속된 작업 흐름으로 연결하려는 시도다. ## 출시 당시 상황 - 해당 기능은 2016년 8월 발표됐으며, 당시 Figma는 아직 비공개 릴리스 단계였다. - Figma는 사용자 요청을 바탕으로 여러 프로토타이핑 도구와의 연동을 검토했고, 그중 Framer에 대한 요구가 가장 컸다고 밝혔다. - 사용자는 Figma에서 시각적 설계를 진행한 뒤 Framer에서 코드 기반 상호작용을 구현하는 방식으로 두 도구를 조합할 수 있었다. 실무에서는 Figma를 화면 설계와 반복 작업에 활용하고, 복잡한 인터랙션이나 실제 동작 검증이 필요할 때 Framer로 가져가는 방식이 효과적이다. 특히 레이어를 수동으로 내보내는 과정이 줄어들기 때문에 프로토타입을 자주 수정하고 테스트하는 팀일수록 통합의 이점을 크게 얻을 수 있다.

원문 읽기(새 탭에서 열림)

Figma프로토타이핑JavaScriptCSS+4

figma·2016년 6월 30일·3분 읽기큐레이션 요약

피그마에서 콘텐츠 디자인

Figma는 콘텐츠 디자이너가 UI가 완성된 뒤 문구를 채우는 방식에서 벗어나, 디자인 초기부터 제품의 모습과 메시지를 함께 설계하도록 돕는다. 실시간 협업, 실제 콘텐츠 사용, 대화형 시나리오 작성, 사용자 여정 매핑을 통해 콘텐츠와 UI의 불일치를 조기에 발견할 수 있다. 결과적으로 콘텐츠 디자이너는 협업 과정에 더 깊이 참여하고 사용자 경험 전반에 미치는 영향도 효과적으로 보여줄 수 있다. ## 실제 콘텐츠로 UI 설계하기 - 화면, 모달, 작은 인터랙션을 만들 때부터 가능한 한 실제 문구를 사용한다. - 실제 콘텐츠를 넣으면 다음 문제를 조기에 발견할 수 있다. - UI가 전달하려는 메시지를 혼란스럽게 만드는 경우 - 콘텐츠가 들어갈 공간이 부족한 경우 - 문구 때문에 인터랙션이나 사용자 흐름을 다시 설계해야 하는 경우 - 콘텐츠를 UI 완성 후 추가하면 문제가 발견됐을 때 이미 많은 디자인을 다시 작업해야 한다. - Figma에서는 콘텐츠 디자이너와 제품 디자이너가 동시에 작업하며 UI와 메시지를 함께 다듬을 수 있다. - 특히 콘텐츠 디자이너가 프로젝트 초기에 참여하지 못했더라도 실제 문구를 넣어 기존 UI의 문제를 빠르게 검토할 수 있다. ## 대화로 시작하는 콘텐츠 우선 설계 - 인터랙션을 실제 대화처럼 상상하고, 시스템과 사용자가 주고받을 말을 먼저 작성한다. - Figma 안에 대화 전용 프레임을 만들거나 댓글로 시나리오를 기록할 수 있다. - 한 사람이 시스템 역할을 맡고 다른 사람이 사용자가 되어 역할극을 하면 다음을 파악하는 데 도움이 된다. - 사용자 목표와 예외 상황 - 정보의 흐름과 우선순위 - 시스템 용어가 아닌 자연스러운 사용자 언어 - 시각적 UI를 만들기 전에 대화를 작성하면 콘텐츠와 디자인이 같은 방향으로 발전한다. - 대화 스크립트가 최종 설계의 완벽한 청사진은 아니지만, 반복적인 수정 과정에서 중요한 기준점이 된다. ## Figma에서 사용자 여정 매핑하기 - 콘텐츠 디자인은 특정 화면 하나가 아니라 사용자 여정 전체를 이해해야 한다. - 이전 단계에서 사용자가 무엇을 했고 다음 단계에서 무엇을 기대하는지 알아야 적절한 안내와 정보를 제공할 수 있다. - 팀과 함께 Figma에서 전체 여정을 시각화하고, 각 단계 아래에 필요한 콘텐츠를 정리한다. - 이 방식은 시각적 탐색이 콘텐츠 요구사항을 바탕으로 시작되도록 유도한다. - 웹 기반 협업 도구이므로 지리적 제약이나 화이트보드·스케치 파일의 공유 한계를 줄일 수 있다. - 엔지니어, 제품 관리자, 제품 디자이너가 실시간으로 작업을 볼 수 있어 콘텐츠 디자이너의 역할과 기여도도 자연스럽게 드러난다. ## 댓글로 콘텐츠 결정 협업하고 기록하기 - 제공된 글 내용은 이 섹션의 도입부에서 끝나 있어 구체적인 댓글 활용 방법까지는 확인할 수 없다. - 다만 제목과 앞선 내용에 따르면 Figma 댓글은 콘텐츠 선택의 근거를 팀과 공유하고, 주요 결정 사항을 디자인 파일 안에 남기는 협업 수단으로 제시된다. - 문서나 별도 회의록이 아니라 실제 디자인 맥락에 결정을 기록하면 이후 수정과 검토 과정에서 내용을 추적하기 쉬워진다. 실무에서는 초기부터 실제 문구를 넣고, 주요 플로우를 대화로 먼저 검증한 뒤, 사용자 여정과 콘텐츠 요구사항을 하나의 Figma 파일에서 관리하는 것이 효과적이다. 이를 통해 콘텐츠를 마지막 단계의 산출물이 아니라 제품 경험을 함께 결정하는 설계 요소로 다룰 수 있다.

원문 읽기(새 탭에서 열림)

Figma사용자 인터페이스collaborative-designux-writing+2

figma·2016년 2월 8일·3분 읽기큐레이션 요약

벡터 네트워크 소개 | 피그

Figma는 기존의 단일 경로(path) 모델을 확장한 **벡터 네트워크(vector networks)** 를 소개한다. 벡터 네트워크는 점과 선을 자유롭게 연결·분리할 수 있어 복잡한 도형을 더 직관적으로 편집하게 해주며, 기존 벡터 데이터와의 호환성도 유지한다. 직접 곡선을 구부리고 영역을 클릭해 채우거나 뚫을 수 있어, 기존 벡터 편집기의 불편한 동작을 크게 줄이는 것이 결론이다. ## 기존 경로 모델의 한계 - 기존 path는 두 끝점을 가진 선과 곡선이 하나의 연속된 체인을 이루는 구조다. - 펜 플로터가 선을 따라 이동하듯, 점과 곡선을 정해진 순서로 연결해야 한다. - 세 개 이상의 선이 한 점에 연결되는 구조를 표현하기 어렵다. - 일부를 삭제하거나 도형을 분리·재결합할 때 사용자가 연결 관계를 직접 관리해야 해 조작이 부자연스럽다. - 선을 연결하거나 해제하는 동작도 상황에 따라 다르게 작동해 직관성이 떨어진다. ## 자유로운 연결을 지원하는 벡터 네트워크 - 벡터 네트워크에서는 임의의 두 점 사이에 선이나 곡선을 연결할 수 있다. - 모든 선이 하나의 단일 체인을 이룰 필요가 없으므로, 여러 선이 한 점에서 만나는 구조를 자연스럽게 표현한다. - 도형의 일부를 어디서든 삭제하고, 필요한 요소를 다시 연결할 수 있다. - 선의 cap과 join 스타일이 분기점에서도 자연스럽게 동작한다. - 기존 path와 동일한 곡선 데이터를 사용하므로 기존 벡터 데이터와의 하위 호환성을 유지한다. - 사용자 테스트에서는 많은 사용자가 구조적 차이를 의식하지 않아도 원하는 방식으로 편집할 수 있었다. ## 곡선을 직접 조작하는 벤드 도구 - 기존 벡터 그래픽은 cubic Bézier 곡선과 곡선 바깥에 위치한 control handle로 형태를 조정한다. - 따라서 사용자는 곡선 자체가 아니라 멀리 떨어진 핸들을 움직여야 했다. - Figma의 bend tool은 곡선 위를 직접 드래그할 수 있게 한다. - 사용자가 곡선을 원하는 위치로 움직이면 편집기가 적절한 control handle의 위치를 자동으로 계산한다. - 새로운 곡선 형식을 도입하는 대신 기존 Bézier 기반 구조를 유지해 호환성과 직접 조작성을 함께 확보했다. ## 직관적인 영역 채우기 - 기존 벡터 엔진은 winding number를 사용해 영역의 안팎을 판단한다. - 이 방식은 곡선을 시계 방향 또는 반시계 방향으로 그렸는지에 따라 채우기 결과가 달라진다. - 사용자는 곡선의 방향을 직접 볼 수 없기 때문에 구멍과 채우기 동작을 예측하기 어렵다. - Figma는 기본적으로 곡선이 둘러싼 모든 영역을 자동으로 채운다. - 구멍이 필요하면 곡선 방향을 조정하는 대신 paint bucket 도구로 해당 영역을 직접 토글해 채우기를 제거한다. - 이 방식은 음의 공간을 별도로 구성해야 했던 기존 접근보다 도형 내부와 구멍을 이해하기 쉽다. ## 개발 과정과 설계 방향 - 경로 모델처럼 기본적인 벡터 구조를 다시 설계하는 과정은 여러 시행착오를 거쳤다. - 초기에는 더 강력한 곡선 형식도 실험했지만, 기존 벡터 데이터와의 호환성을 위해 Bézier 곡선을 유지했다. - 영역 채우기는 특히 어려운 문제였으며, 사용자가 구멍을 직접 정의해야 하는 접근은 복잡하다는 결론을 내렸다. - 최종적으로 자유로운 연결, 직접 곡선 조작, 영역 토글 방식을 결합해 기존 편집기의 동작을 더 자연스럽게 만들었다. 벡터 네트워크의 핵심 가치는 새로운 그래픽 형식을 도입하는 데 있지 않고, 기존 벡터 구조를 유지하면서도 편집 방식을 사용자의 직관에 맞게 바꾼 데 있다. 벡터 편집기를 설계할 때는 내부 데이터 모델의 제약보다 사용자가 점·선·영역을 어떻게 직접 조작하고 싶어 하는지를 우선하는 것이 실용적인 방향이다.

원문 읽기(새 탭에서 열림)

Figmavector-graphicsbezier-curvesvector-networks+2

figma·2016년 1월 20일·3분 읽기큐레이션 요약

가구에서 스크린까지

가구는 완성 후 실수를 고치기 어렵지만, 디지털 제품은 매일 개선할 수 있다는 차이에서 출발한다. Figma는 가구처럼 사용자의 작업을 돕되 스스로는 눈에 띄지 않는 도구를 지향하며, 가구 디자인의 원칙을 도구·조작감·색상 설계에 적용했다. 궁극적으로 좋은 디자인 도구는 사용자가 도구 자체가 아니라 자신의 아이디어에 집중하게 해야 한다. ## 사용자의 삶을 돕고 사라지는 제품 - 가구의 목적은 빈 공간을 채우는 것이 아니라 그 안에서 이루어지는 생활을 지원하는 데 있다. - Figma 역시 제품 자체가 주인공이 아니라, 사용자가 다른 제품과 아이디어를 만들어내도록 돕는 기반이 되어야 한다. - 따라서 인터페이스는 기능을 제공하면서도 사용자의 창작 활동을 방해하지 않고 배경으로 물러나야 한다. ## 최소한이지만 강력한 도구 - 기본 도구 수를 줄이되, 단순한 작업부터 복잡한 작업까지 대응할 수 있도록 설계했다. - 망치 하나로 작은 수납장부터 집 전체를 만들 수 있듯이, 핵심 도구는 다양한 결과물을 만들어낼 만큼 유연해야 한다. - Figma의 펜 도구는 물리적인 펜처럼 느껴지도록 재구성했다. - 벡터 객체를 전통적인 경로가 아니라 점들의 네트워크로 구성해, 임의의 점을 서로 연결할 수 있게 했다. - 이 방식은 정해진 절차를 따라가는 대신 결과물을 자연스럽게 만들어가는 데 집중하게 한다. - 편집기는 필요한 도구가 잘 정리된 작업대처럼 느껴져야 하며, 도구의 배치와 접근성은 작업의 기본 조건이다. ## 손에 잡히는 조작감과 사용자 제어 - 물리적 도구를 사용할 때의 촉각적 익숙함은 디지털 도구에서도 통제감을 높인다. - 키보드 단축키는 사용자가 작업을 빠르고 직접적으로 제어하게 만드는 대표적인 수단이다. - Figma의 `Command` 키와 드래그 조합은 중첩된 요소를 선택할 때의 불편을 해결한다. - `Command`를 누른 채 드래그하면 컨테이너와 내부 요소를 구분하는 휴리스틱이 작동해, 컨테이너 자체가 아니라 포함된 요소만 선택한다. - 예를 들어 툴바 배경은 제외하고 그 안의 아이콘만 한 번에 박스 선택할 수 있다. - 사용자는 레이어 계층 구조를 일일이 생각하지 않고 화면 속 요소를 직접 조작할 수 있다. ## 눈에 띄지 않되 의미를 전달하는 색상 - 초기 Figma는 거의 단색에 가까운 ‘무스킨’ 스타일을 사용해 UI가 디자인을 방해하지 않도록 했다. - 그러나 기능이 늘어나면서 단색 UI만으로는 서로 다른 구성 요소를 명확히 구분하기 어려워졌다. - 해결책은 UI를 완전히 사라지게 하는 것이 아니라, 사용자가 의식하지 않아도 의미를 파악할 수 있도록 만드는 것이었다. - 현재의 색상 체계는 색을 시각적 장식이 아니라 의미의 추가 계층으로 활용한다. - 초록색: 실행이나 행동 - 파란색: 선택 상태 - 이러한 색상 그룹은 화면을 한눈에 이해하게 하고, 사용자가 “어떻게 도구를 쓰는가”보다 “무엇을 그리고 있는가”에 집중하도록 돕는다. ## 분야를 넘나드는 디자인 원칙 - 디자인 도구를 발전시키려면 현재 업계의 관습과 기준을 계속 재검토해야 한다. - 유용한 해결책은 과거의 디자인뿐 아니라 다른 분야에서도 발견될 수 있다. - 가구 디자인처럼 분야를 초월하는 원칙—기능 지원, 사용성, 절제, 재료와 도구의 이해—을 디지털 제품에 적용할 수 있다. - 디자이너는 자신의 전문 영역에만 머무르지 않고 역사와 타 분야를 폭넓게 참고해야 혁신적인 도구를 만들 수 있다. Figma를 설계할 때는 기능을 늘리는 것보다 사용자의 작업을 얼마나 자연스럽게 지원하는지에 초점을 두는 것이 중요하다. 최소한의 유연한 도구, 직관적인 조작, 의미를 전달하는 시각 체계를 갖추면 제품은 사용자의 창작을 돕면서도 전면에 나서지 않을 수 있다.

원문 읽기(새 탭에서 열림)

Figma디자인 시스템사용자 경험사용자 인터페이스+2

figma·2015년 12월 14일·2분 읽기큐레이션 요약

처음부터 슬랙과 함께 |

Figma는 협업형 인터페이스 디자인 도구의 핵심 협업 경험을 자체 메시징 기능이 아니라 Slack 위에 구축하기로 했다. 디자이너들이 Slack을 일상적으로 사용하고, Slack 사용자가 디자인 과정을 더 개방적으로 공유하는 경향이 있었기 때문이다. 따라서 Figma 팀을 Slack 팀과 연결하고 파일 알림도 Figma가 아닌 Slack으로 전달하는 전략이 통합과 사용자 경험 측면에서 효과적이었다. ## Slack 사용자를 관찰한 배경 - Figma는 제품을 개발하며 디자이너들이 파일 저장, 사양 작성, 제품 의사결정 등을 어떻게 협업하는지 조사했다. - 인터뷰한 디자이너 중 절반 이상이 Slack을 하루 종일 사용한다고 답했다. - Slack 사용 여부는 다른 협업 방식과도 연관되어 있었다. - Slack을 사용하는 디자이너일수록 디자인 과정을 팀에 더 개방적이고 투명하게 공유하는 경향이 있었다. - 이를 통해 Slack이 단순한 채팅 도구가 아니라 디자인 협업의 중심 채널이 될 수 있다고 판단했다. ## 중복 기능을 만들지 않은 이유 - Figma는 디자인에 대한 커뮤니케이션을 지원하는 제품이므로, 자체적으로 메시지·알림 기능을 구현하고 싶은 유혹이 있었다. - 하지만 Slack과 비슷한 기능을 다시 만들면 다음과 같은 문제가 생긴다. - 사용자가 메시지를 확인할 장소를 하나 더 관리해야 한다. - 팀을 Figma와 Slack 양쪽에서 별도로 설정해야 한다. - 이미 익숙한 협업 흐름이 여러 서비스로 분산된다. - Figma는 사용자가 또 다른 메시지함을 확인하도록 만들기보다, 기존에 사용 중인 Slack을 협업 기반으로 활용하기로 했다. ## Figma와 Slack의 긴밀한 통합 - Figma의 협업 모델에서 “Figma 팀”은 “Slack 팀”과 연결된다. - Figma 파일에서 발생하는 알림은 Figma 내부가 아니라 Slack을 통해 전달된다. - 사용자는 Slack에서 디자인 관련 소식을 확인하고 팀원과 논의할 수 있다. - 이는 Slack을 단순한 외부 연동 대상이 아니라 Figma 협업 경험의 기반 플랫폼으로 활용한 결정이다. ## 플랫폼 전략과 사업적 판단 - Figma는 Slack 플랫폼이 공식적으로 출시되기 전부터 Slack을 플랫폼으로 바라보고 통합을 준비했다. - Slack 중심의 협업 구조는 당시로서는 큰 전략적 선택이었지만, 초기 성과를 통해 그 판단이 효과를 내고 있다고 평가했다. - 글은 앞으로 다른 기업들도 자체 기능을 무작정 복제하기보다, 사용자가 이미 익숙한 플랫폼 위에 제품 경험을 구축할 가능성이 커질 것이라고 전망한다. 실용적으로는 새로운 협업 기능을 개발할 때 자체 메시징·알림 시스템을 추가하기 전에, 사용자가 이미 매일 사용하는 도구와 자연스럽게 연결하는 방식을 우선 검토할 필요가 있다.

원문 읽기(새 탭에서 열림)

Figmaslackcollaborationapi-integration+2

figma·2015년 12월 14일·3분 읽기큐레이션 요약

스크린 디자인을 위한 그리드

스위스 타이포그래피에서 발전한 그리드 시스템은 화면 디자인에서도 여전히 일관성과 질서를 만드는 핵심 원리다. 고정된 인쇄물과 달리 화면은 기기 크기와 밀도가 달라지므로, 디지털 디자인에는 유연한 그리드와 이를 제어할 도구가 필요하다. Figma는 제약 조건, 레이아웃 그리드, 중첩 프레임을 결합해 다양한 화면 크기에서도 구조가 유지되는 디자인을 제안한다. ## 고정된 페이지에서 유동적인 화면으로 - 1950년대 스위스 디자이너들은 정보를 체계적으로 배치하기 위해 그리드 디자인을 발전시켰다. - Joseph Müller-Brockmann, Karl Gerstner 등의 작업은 합리적인 구조와 시각적 아름다움을 함께 보여주었다. - 인쇄 디자인은 페이지 크기, 글자 크기, 행간, 여백을 정밀하게 통제할 수 있다는 전제를 가진다. - 반면 화면 디자인은 브라우저와 기기마다 크기와 화면 밀도가 달라 동일한 고정 레이아웃을 그대로 적용하기 어렵다. - 따라서 문제는 그리드 철학 자체가 아니라, 유동적인 캔버스를 다룰 수 있는 디지털 도구가 부족했다는 데 있다. ## 기존 화면 디자인 도구의 한계 - 초기 디지털 디자인에서는 기술적 제약 때문에 인쇄 디자인의 많은 원칙이 버려졌다. - 오늘날에는 타이포그래피와 레이아웃 제어 기능이 발전했지만, 도구는 여전히 고정된 아트보드 중심인 경우가 많다. - 디자이너는 여러 화면 크기의 아트보드를 반복해서 복사·수정하거나, 개발 단계에서 반응형 동작을 추측해야 했다. - iPad처럼 화면의 가장자리와 페이지 개념을 제공하는 기기가 등장했지만, 기기 종류가 늘면서 디지털 페이지는 어떤 크기와 형태도 가질 수 있게 되었다. - 중요한 과제는 유연성을 확보하면서도 정밀한 정렬과 통제를 유지하는 것이다. ## 제약 조건: 크기 변화에 대응하는 규칙 - 제약 조건은 프레임의 크기가 바뀔 때 내부 객체가 어떻게 반응할지 지정한다. - 객체를 프레임의 왼쪽이나 오른쪽에 고정하거나, 중앙에 배치하거나, 남은 공간을 채우도록 늘릴 수 있다. - 이를 통해 단순히 요소를 특정 좌표에 고정하는 대신, 화면 크기 변화에 따른 동작을 설계할 수 있다. - 제약 조건만으로도 가장자리 고정, 중앙 정렬, 영역 확장과 같은 기본적인 반응형 레이아웃을 구현할 수 있다. ## 레이아웃 그리드: 정밀한 반응형 정렬 - 복잡한 디자인에서는 단순한 좌우 고정이나 중앙 정렬만으로 충분하지 않기 때문에 그리드가 필요하다. - Figma의 그리드는 제약 조건이 작동하는 기준을 세밀하게 정의한다. - 예를 들어 어떤 박스가 두 개의 그리드 열을 차지하도록 설정하면, 화면이 커지거나 작아질 때 박스도 그 열의 경계에 맞춰 함께 늘어나거나 줄어든다. - 열 그리드는 웹페이지의 텍스트 흐름뿐 아니라 아이콘, 툴바, 버튼 등 다양한 요소를 정렬하는 데 사용할 수 있다. - 그리드는 열과 행, 여백, 모듈 등의 구조를 통해 디자인 전체에 일관된 시각적 리듬을 부여한다. ## 중첩 프레임: 복잡한 구조를 구성하는 방법 - 하나의 화면 안에서도 영역마다 다른 레이아웃 규칙이 필요할 수 있다. - 프레임 안에 또 다른 프레임을 배치하면 각 영역에 독립적인 그리드와 제약 조건을 적용할 수 있다. - 예를 들어 전체 화면은 큰 2열 그리드를 사용하고, 툴바나 카드 내부에는 별도의 그리드를 적용할 수 있다. - 이러한 구조는 HTML의 중첩된 `<div>`와 유사하며, 실제 개발 구조로 옮기기에도 적합하다. - Figma가 ‘아트보드’ 대신 ‘프레임’이라는 용어를 사용하는 이유도 단순한 캔버스를 넘어 계층적 레이아웃 시스템을 제공하기 때문이다. ## 현대적인 디자인 도구의 방향 - 정적인 화면을 그리는 것만으로는 다양한 디바이스 환경을 충분히 다룰 수 없다. - 디자인 도구는 과거의 인쇄 디자인 원칙을 버리기보다, 이를 유동적인 화면 환경에 맞게 재해석해야 한다. - 제약 조건, 그리드, 중첩 프레임은 각각 독립적으로도 사용할 수 있지만 함께 사용할 때 복잡한 반응형 디자인 시스템을 구축할 수 있다. - 좋은 도구는 결과물뿐 아니라 화면 크기 변화에 따른 디자인의 동작과 규칙까지 표현할 수 있어야 한다. 실무에서는 먼저 전체 화면의 그리드를 정의한 뒤, 주요 요소에 제약 조건을 설정하고, 카드·툴바·콘텐츠 영역을 중첩 프레임으로 분리하는 방식이 효과적이다. 이렇게 하면 여러 화면 크기별 시안을 일일이 복제하지 않고도 일관성과 반응성을 함께 관리할 수 있다.

원문 읽기(새 탭에서 열림)

Figma디자인 시스템HTML반응형 디자인+3

figma·2015년 12월 6일·4분 읽기큐레이션 요약

웹에서 전문적인 디자인 도구

Figma는 전문 디자이너가 받아들일 수 있는 고품질 편집 경험을 웹 브라우저에서 제공하기 위해, 사실상 “브라우저 안의 브라우저”를 구축했다. 웹 플랫폼의 제한적인 추상화 대신 WebGL·asm.js 같은 저수준 기술을 활용하고, C++ 기반 편집기와 자체 메모리·렌더링 시스템으로 성능과 플랫폼 간 일관성을 확보했다. 특히 Emscripten을 통해 네이티브에 가까운 성능과 예측 가능한 프레임률을 달성하는 것이 핵심 전략이다. ## 웹에서 전문 디자인 도구를 만들기 어려운 이유 - 웹은 원래 문서 표시를 위해 설계되었고, 애플리케이션 개발 기능은 이후 개별 API 형태로 덧붙여졌다. - 따라서 특정 기능은 제공하지만, 개발자가 이를 조합해 새로운 동작을 구현할 수 있는 범용적인 저수준 primitive가 부족하다. - CSS는 복잡한 텍스트 배치 알고리즘을 제공하지만: - 알고리즘을 직접 커스터마이즈하기 어렵고 - 브라우저가 계산한 결과를 읽어 다른 알고리즘에 재사용하기도 어렵다. - 브라우저의 GPU 컴포지터는 고성능이지만: - 렌더링 과정에 직접 개입하기 어렵고 - 사용자 정의 블렌드 모드나 애플리케이션 특화 최적화를 추가할 수 없다. - 이미지 디코더는 하드웨어 가속과 비동기 처리를 지원하지만: - EXIF 방향 정보를 어떻게 처리할지 지정하기 어렵고 - 디스플레이 색 공간을 이미지 데이터에 미리 반영하지 않도록 제어하기 어렵다. - WebGL과 asm.js의 등장으로 개발자가 브라우저에 기능 추가를 기다리지 않고 하드웨어에 가까운 수준에서 필요한 기능을 직접 구현할 수 있게 되었다. ## Emscripten으로 C++ 편집기 실행 - Figma 편집기는 C++로 작성하고 Emscripten으로 JavaScript로 크로스 컴파일했다. - Emscripten은 asm.js를 대상으로 하며, asm.js는 JIT가 예측 가능하고 compact한 기계어를 생성하기 쉬운 JavaScript 부분집합이다. - 이 방식의 장점: - 메모리 배치를 직접 제어할 수 있어 64비트 부동소수점 중심인 JavaScript보다 32비트 float나 byte를 효율적으로 사용할 수 있다. - 객체를 미리 할당한 typed array 영역에 배치해 JavaScript 가비지 컬렉터의 개입을 피한다. - GC 중단으로 인한 프레임 저하를 줄여 60fps 달성에 유리하다. - LLVM 최적화와 C++ 템플릿 특수화를 활용해 네이티브 성능의 약 2배 이내 수준까지 접근할 수 있다. - asm.js에는 일반 JavaScript의 JIT 추론에 따른 deoptimization 지점이 없어 실행 성능이 더 예측 가능하다. ## 대용량 메모리와 브라우저 제약 대응 - Emscripten은 전체 메모리 공간을 하나의 큰 typed array에 담기 때문에 연속된 주소 공간을 충분히 확보해야 한다. - 특히 32비트 Chrome on Windows에서는 ASLR이 주소 공간을 파편화해 256MB typed array조차 할당하지 못하는 문제가 있었다. - Figma는 대형 이미지·기하 버퍼를 주 힙 외부의 별도 typed array에 저장하고, 이를 C++에서 참조하는 `IndirectBuffer` API를 만들었다. - 이 방식은: - 장시간 실행 시 메모리 파편화를 줄이고 - 32비트 브라우저의 제한된 주소 공간을 더 효율적으로 사용하며 - 64비트 브라우저의 31비트 typed array 크기 제한을 우회한다. - 해당 `IndirectBuffer` 구현은 오픈소스로 공개되었다. ## asm.js 이후의 발전 방향 - WebAssembly는 asm.js 코드를 바이너리 형식으로 표현해 JavaScript 파싱 시간을 크게 줄이는 것을 목표로 한다. - 당시 웹의 멀티스레딩은 Web Worker와 메시지 전달 방식에 의존했다. - Shared Typed Array가 도입되면 여러 실행 흐름이 메모리를 공유하는 진정한 공유 메모리 기반 멀티스레딩이 가능해질 것으로 전망했다. ## 자체 렌더링 엔진 - 브라우저의 그래픽 기능을 그대로 사용하는 대신, 콘텐츠를 빠르고 플랫폼 간 일관되게 표시하기 위해 자체 렌더링 엔진을 구현했다. - 이는 브라우저마다 다른 그래픽 구현과 동작 차이를 통제하고, 전문 디자인 도구에 필요한 고성능 렌더링을 직접 최적화하기 위한 선택이다. - 제공된 글 내용은 자체 렌더링 엔진의 필요성을 설명하는 부분에서 끝나므로, 구체적인 렌더링 구조와 최적화 기법은 확인할 수 없다. 브라우저 기반 고성능 그래픽 애플리케이션을 만들 때는 DOM과 일반 JavaScript API만으로 해결하려 하기보다, C++/WebAssembly 계열의 실행 모델과 명시적인 메모리 관리, 자체 렌더링 계층을 고려하는 것이 효과적이다. 특히 60fps가 중요한 편집 도구라면 가비지 컬렉션과 브라우저별 렌더링 차이를 구조적으로 줄이는 설계가 중요하다.

원문 읽기(새 탭에서 열림)

webassemblyc++webglasm-js+3