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

피그마는 웹어

WebAssembly 도입으로 Figma는 애플리케이션 초기화, 디자인 파일 다운로드, 첫 렌더링을 포함한 전체 로드 시간을 약 3배 단축했다. 특히 C++ 기반 코드를 브라우저에서 실행할 때 asm.js보다 전송·파싱·네이티브 코드 변환·캐싱 측면에서 유리했다. 다만 압축 후 다운로드 크기 감소 효과는 작았고, 당시에는 브라우저별 구현 및 캐싱 지원 차이로 적용 범위가 제한됐다. ## WebAssembly의 특징과 asm.js와의 차이 - WebAssembly는 브라우저 실행을 위해 설계된 바이너리 형식의 머신 코드다. - 기존에는 C++ 코드를 asm.js라는 JavaScript 부분집합으로 변환해 실행했다. - 숫자와 포인터만 사용할 수 있으며, 포인터는 숫자 배열의 인덱스로 표현된다. - DOM 조작이나 네트워크 연결 등 브라우저 기능은 JavaScript를 호출해야 한다. - WebAssembly도 asm.js와 동일한 제약과 브라우저 샌드박스를 공유하지만, 실행 형식이 더 효율적이다. - C++처럼 이미 LLVM으로 최적화된 코드는 브라우저가 별도 최적화를 많이 수행하지 않고 네이티브 코드로 변환할 수 있다. ## WebAssembly가 빠른 이유 - **작은 바이너리 형식** - 동일한 코드의 JavaScript보다 네트워크 전송에 유리하다. - 다만 압축하면 asm.js와 WebAssembly의 크기 차이는 크게 줄어든다. - **빠른 파싱** - 사람이 작성하는 JavaScript에는 문법과 중복 정보가 많다. - WebAssembly는 브라우저가 빠르게 해석하도록 설계되어 asm.js보다 약 20배 빠르게 파싱된다. - **효율적인 네이티브 코드 변환** - LLVM이 사전에 C++ 코드를 최적화하므로 브라우저의 런타임 최적화 부담이 작다. - **변환 결과 캐싱** - 브라우저가 WebAssembly 모듈의 네이티브 코드 변환 결과를 쉽게 캐시할 수 있다. - 같은 애플리케이션을 다시 열 때 변환 시간이 거의 사라질 수 있다. - **64비트 정수 지원** - WebAssembly는 64비트 정수를 직접 지원한다. - JavaScript는 정수 정밀도가 53비트로 제한되어 64비트 정수를 에뮬레이션해야 한다. ## Figma에서의 적용과 성능 개선 - Figma는 C++로 작성된 대규모 2D WebGL 렌더링 엔진을 사용한다. - 측정한 로드 시간에는 다음 과정이 모두 포함됐다. - 애플리케이션 초기화 - 디자인 파일 다운로드 - 디자인의 최초 전체 렌더링 - WebAssembly로 전환한 뒤 문서 크기와 관계없이 로드 시간이 3배 이상 개선됐다. - 큰 디자인 문서를 자주 만들고 전환하는 Figma 사용자에게 특히 큰 효과가 있었다. - 앱을 한 번 실행한 뒤에는 WebAssembly의 네이티브 변환 결과가 캐시되므로, 이후 로드 시간은 애플리케이션 코드 크기에 덜 영향을 받는다. ## 다운로드 크기와 실제 개선의 차이 - WebAssembly로 전환하면 전송 크기도 크게 줄어들 것으로 예상했지만 실제 감소 폭은 작았다. - asm.js 코드도 압축하면 WebAssembly와 비슷한 크기까지 줄어들기 때문이다. - 따라서 Figma에서 가장 큰 이점은 파일 크기 감소가 아니라 파싱, 코드 변환, 캐싱에 따른 실행 및 로드 시간 단축이었다. ## 브라우저 지원의 한계 - 당시 WebAssembly는 Firefox와 Chrome에서 기본 활성화되어 있었다. - Edge와 Safari는 아직 구현 중이어서 브라우저별 지원 상황을 확인해야 했다. - Figma는 Chrome에서도 WebAssembly를 사용할 수 있었지만, 구현상의 문제 때문에 실제로는 Firefox에서만 활성화했다. - 특히 Chrome의 네이티브 변환 코드 캐싱 방식이 Firefox와 달라 페이지를 열 때마다 애플리케이션 전체를 다시 변환해야 하는 문제가 있었다. WebAssembly는 대규모 C/C++ 코드베이스를 웹으로 옮길 때 특히 효과적이다. 단순히 다운로드 용량을 줄이는 기술이라기보다, 빠른 파싱과 네이티브 코드 변환, 실행 결과 캐싱을 통해 초기 로드 시간을 줄이는 기술로 보는 것이 적절하다.

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

JavaScriptwebassemblywebglc-plus-plus+3

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

한 디자이너가 내

Pivotal의 디자이너와 개발자 간 인수인계는 디자인 파일을 이미지로 내보내고 프로젝트 카드에 반복 업로드하는 방식이라 비효율과 오류가 많았다. Figma를 도입한 뒤에는 최신 디자인을 링크 하나로 공유하고 디자인 위에 직접 댓글을 남길 수 있어, Colby는 프로젝트마다 약 이틀의 문서 관리 시간을 절약했다. 또한 맥락이 포함된 실시간 리뷰가 가능해져 협업과 결과물의 품질에도 긍정적인 영향을 주었다. ### 반복적인 이미지 내보내기와 업로드의 문제 - Colby는 디자인 프레임을 이미지로 export한 뒤 Pivotal Tracker의 개발 카드에 업로드했다. - 프로젝트마다 이 작업을 15~20회 반복해야 했다. - 프로젝트 하나에 수백 개의 카드가 있어 최신 카드를 찾는 데도 많은 시간이 들었다. - 이미지를 업데이트하지 않고 잊어버리면 개발자가 오래된 디자인을 기준으로 작업할 수 있었다. - 이 과정은 디자이너뿐 아니라 개발자의 시간도 낭비하고, 잘못된 구현으로 이어질 위험이 있었다. ### 브라우저 기반 디자인 공유 - Figma 파일은 브라우저에서 관리되므로 별도 프로그램 설치 없이 접근할 수 있었다. - 링크를 공유하면 모든 협업자가 동일한 최신 파일을 확인할 수 있었다. - 디자인이 변경되어도 개발 카드를 매번 이미지로 갱신할 필요가 없었다. - Colby는 카드를 처음 만들 때 Figma 링크만 추가하면 되었고, 프로젝트마다 약 이틀의 작업 시간을 절약했다. - Figma는 단순한 디자인 제작 도구를 넘어 파일 공유와 변경 관리까지 지원하는 “디자인 관리 도구”로 활용되었다. ### 디자인 위에 남기는 맥락 있는 댓글 - 기존 디자인 리뷰에서는 엔지니어들이 포스트잇에 의견을 적고 차례로 구두 공유했다. - 포스트잇은 어떤 디자인 요소에 대한 의견인지 맥락이 분리되어 이해하기 어려웠다. - Figma에서는 댓글을 특정 프레임이나 디자인 영역에 직접 연결할 수 있었다. - 리뷰 참여자는 의견이 적용되는 위치를 즉시 확인할 수 있어 피드백이 더 명확해졌다. - 결과적으로 주간 디자인 리뷰가 더 짧고 효율적으로 진행되었다. ### 실시간 협업과 리뷰 조정 - 엔지니어가 파일을 검토하는 동안 Colby는 각자의 커서와 활동을 실시간으로 확인할 수 있었다. - 특정 컴포넌트처럼 이미 스타일 가이드로 정해진 부분에 리뷰가 집중되면, Colby가 피드백 방향을 조정할 수 있었다. - 리뷰를 받는 디자이너가 어떤 영역에 피드백을 원하는지 직접 안내할 수 있었다. - 디자이너와 개발자가 같은 파일을 보며 의견을 주고받아 정보 전달의 누락을 줄였다. ### 협업 품질 향상 - Figma는 디자인에서 개발로 넘어가는 인수인계 과정의 반복적인 관리 작업을 줄였다. - 팀은 파일 버전과 피드백을 추적하는 데 쓰던 시간을 제품의 완성도에 더 투자할 수 있었다. - Pivotal은 개발자와 디자이너를 포함한 다양한 구성원의 의견이 더 나은 제품을 만든다고 보았고, Figma가 이를 지원한다고 평가했다. 실무에서는 디자인 파일을 이미지로 복사해 전달하기보다 최신 원본 링크를 단일 기준으로 삼고, 피드백은 해당 디자인 요소에 직접 남기는 방식이 효과적이다. 이를 위해 프로젝트 관리 카드에 Figma 링크와 버전 규칙을 명확히 기록하면 오래된 시안으로 작업하는 문제를 줄일 수 있다.

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

Figma디자인 시스템사용자 인터페이스design-collaboration+2

figma·2017년 5월 25일원문

워크플로에서 컨스트레인 (새 탭에서 열림)

Figma의 '제약 사항(Constraints)' 기능은 다양한 화면 크기에 대응해야 하는 현대 디자이너들의 작업을 효율적으로 만들어주는 강력한 도구입니다. 이 기능을 활용하면 요소가 상위 프레임의 크기 변화에 따라 어떻게 반응할지 정의할 수 있어, 반복적인 수작업 없이도 유연한 반응형 디자인을 완성할 수 있습니다. 결과적으로 디자이너는 한 번의 설계로 PC부터 모바일까지 모든 해상도에서 의도한 레이아웃을 유지하는 견고한 인터페이스를 구축할 수 있습니다. **버튼의 고정 위치 설정** * 모바일 UI에서 자주 쓰이는 '플로팅 액션 버튼(FAB)'과 같은 요소를 프레임의 특정 위치에 고정할 수 있습니다. * 제약 사항을 'Bottom'과 'Right'로 설정하면 화면 크기가 늘어나거나 줄어들더라도 버튼이 지정된 구석 위치를 이탈하지 않고 유지됩니다. **컴포넌트와 제약 사항의 결합** * Figma의 컴포넌트(반복되는 디자인 단위) 기능과 제약 사항을 함께 사용하면 디자인 시스템 운영 효율이 극대화됩니다. * 주요 요소에 제약 사항을 설정한 뒤 이를 컴포넌트로 만들고 다양한 기기 크기의 프레임에 복제하면, 원본의 색상이나 텍스트 스타일을 한 번만 수정해도 모든 해상도의 인스턴스에 즉시 반영됩니다. **그리드와 연동한 반응형 레이아웃** * 제약 사항을 'Stretch(늘리기)' 타입의 레이아웃 그리드와 결합하면 하단 내비게이션 바와 같은 복잡한 요소도 정교하게 제어할 수 있습니다. * 내비게이션 바 프레임에 'Left & Right' 및 'Bottom' 제약을 설정하고, 각 아이콘을 그리드 열 내부에 배치한 뒤 'Center'로 설정하면 화면 너비 변화에 맞춰 아이콘 간격이 자동으로 균등하게 조절됩니다. **유연한 테이블 셀 설계** * 텍스트와 아바타가 포함된 그룹은 'Center-Left'로, 우측의 버튼 그룹은 'Center-Right'로 제약 사항을 다르게 부여하여 테이블 셀을 구성합니다. * 이렇게 설계된 셀은 프레임 너비가 어떻게 변하든 각 정보가 좌우 끝단에 밀착되어 정돈된 형태를 유지하므로, 정보 밀도가 높은 목록형 UI를 설계할 때 매우 유용합니다. **일러스트레이션의 창의적 활용** * 제약 사항은 UI 요소뿐만 아니라 일러스트레이션이나 드로잉에도 적용하여 재미있는 시각 효과를 줄 수 있습니다. * 수평 또는 수직 제약을 활용해 이미지를 의도적으로 늘리거나 줄임으로써, 프레임 크기 변화에 따라 캐릭터의 형태가 변하는 위트 있는 디자인을 연출할 수 있습니다. 효율적인 워크플로우를 위해 단순히 요소를 배치하는 것에 그치지 말고, 초기 설계 단계부터 제약 사항을 고려하는 습관을 들이는 것이 좋습니다. 특히 컴포넌트와 레이아웃 그리드를 제약 사항과 유기적으로 연결하여 사용한다면, 복잡한 디자인 시스템도 훨씬 유연하고 일관성 있게 관리할 수 있습니다.

Figma사용자 인터페이스반응형 디자인components+3

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

Braintree가 디자인 크리틱 시간을

Braintree는 정적인 디자인 리뷰를 실시간 공동 작업으로 바꾸면서 디자인 크리틱에 드는 시간을 약 50% 줄였다. 디자이너들이 같은 파일에서 직접 수정하고 아이디어를 발전시키자 피드백 오해와 반복 회의가 감소했으며, 개발자와의 핸드오프도 링크 하나로 단순해졌다. ## 기존 디자인 크리틱의 비효율 - 디자이너가 작업물을 발표하고, 여러 리뷰어에게 한꺼번에 피드백을 받는 방식이었다. - 디자이너는 회의 후 혼자 피드백을 적용해야 했고, 리뷰어의 의도를 정확히 이해하지 못하는 경우가 많았다. - 수정본을 다시 검토하는 회의에서 문제가 재발견되거나 새로운 문제가 생겨 반복 작업이 발생했다. - PayPal의 Braintree 인수 이후 여러 디자인 팀, 서로 다른 스타일 가이드, 다양한 서비스와 개발 팀이 얽히며 커뮤니케이션 복잡성이 커졌다. ## Figma 도입과 실시간 리뷰 - Braintree의 Developer Experience 디자인 팀은 새로운 피드백 방식을 시험하며 Figma를 도입했다. - 디자이너들은 대면 회의 대신 Slack 음성 통화와 Figma 파일을 함께 사용했다. - 브라우저 링크로 같은 파일에 접속하고, 관찰 모드로 상대방의 화면과 작업 위치를 실시간으로 확인했다. - 별도의 운영체제나 설치 환경에 크게 구애받지 않고 온라인에서 협업할 수 있다는 점도 장점으로 작용했다. ## 정적 리뷰에서 창의적 공동 작업으로 - 리뷰어는 말로 설명하는 대신 디자이너의 아트보드를 복제하고 직접 수정해 의도를 보여줄 수 있었다. - 피드백을 메모한 뒤 나중에 해석하고 적용할 필요가 줄어들었다. - 두 디자이너가 같은 파일에서 각자의 시안을 발전시키고, 서로의 작업을 참고하며 아이디어를 조합했다. - 여러 시안의 장점을 결합한 새로운 버전을 즉석에서 만들 수 있었다. - Craig은 이 방식으로 디자인 크리틱 시간이 약 50% 감소했다고 추정했다. ## 개발자 핸드오프 간소화 - 기존에는 디자인 변경 때마다 파일을 다시 내보내고, 개발자에게 수많은 메시지를 보내야 했다. - Figma 링크 하나를 공유하면 디자이너와 개발자가 최신 디자인을 함께 확인할 수 있었다. - 특정 버튼이나 기능의 동작을 질문받으면, 디자이너가 파일 안에서 직접 복제·수정하며 설명할 수 있었다. - 디자인의 동작 방식을 설명하기 위한 별도 회의와 반복적인 파일 전달이 줄어들었다. ## 실용적인 적용 방법 - 디자인 리뷰를 발표와 질의응답에만 한정하지 말고, 공동 편집 세션으로 운영한다. - 피드백은 말이나 문서로만 전달하지 말고, 가능한 경우 리뷰어가 직접 시안을 수정해 보여주게 한다. - 디자이너와 개발자가 동일한 최신 파일을 기준으로 대화하도록 공유 링크와 실시간 협업 도구를 활용한다. - 팀 규모가 커질수록 정기 회의보다 실시간 작업 공간을 중심으로 커뮤니케이션 구조를 설계하는 것이 효과적이다.

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

Figma사용자 경험slackreal-time-collaboration+2

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

피그마의 첫

Figma는 브라우저에서 복잡한 그래픽을 빠르게 처리하면서도 여러 사용자가 동시에 작업할 수 있는 디자인 도구를 만들겠다는 목표로 첫해를 보냈다. 초기에는 “장난감”이라는 평가와 기술적 한계에 대한 의심이 있었지만, 멀티플레이어 편집과 컴포넌트·디자인 시스템 기능을 통해 협업 도구로서의 가치를 입증했다. 또한 성능 개선과 Sketch 가져오기 기능을 강화하며 기존 디자인 워크플로에 쉽게 편입되는 제품으로 발전했다. ## 브라우저 기반 디자인 도구의 도전 - 웹 브라우저에서 복잡한 그래픽을 렌더링하면서도 높은 성능을 유지해야 했다. - 기존 디자인 도구에 익숙한 디자이너들이 새로운 협업 방식을 신뢰하도록 설득해야 했다. - 초기에는 Figma를 실제 업무용 도구가 아닌 “장난감”으로 보는 시선이 있었다. - Figma는 디자이너, 엔지니어, 제품 관리자와 대화하며 규모가 커지는 팀의 요구를 파악했다. ## 빠른 제품 개선과 성능 투자 - 출시 후 작업 흐름을 단순화하고 제품 완성도를 높이기 위해 수많은 기능과 업데이트를 배포했다. - 파일 로딩과 그래픽 렌더링 속도를 높이는 데 상당한 엔지니어링 자원을 투입했다. - Sketch 파일을 Figma로 가져오는 기능을 지속적으로 개선해 사용자가 기존 작업물을 처음부터 다시 만들지 않도록 했다. - 업데이트가 매우 빠르게 진행되어 사용자가 모든 변화를 따라가기 어려울 정도였으며, 첫해를 기념해 주요 발전 사항을 한곳에 정리했다. ## 실시간 협업과 단일 진실 공급원 - 2016년 9월 28일 멀티플레이어 편집 기능을 공개했다. - 디자인 도구에서 여러 사람이 동시에 편집하는 방식은 당시 새로운 개념이었고, 디자이너들 사이에서도 찬반 논쟁이 있었다. - 실제 사용 사례로는 다음과 같은 협업이 가능해졌다. - 촉박한 일정 안에서 여러 디자이너가 함께 제품을 완성 - 세계 각지의 예비 디자이너 멘토링 - 더욱 효율적인 디자인 리뷰와 비평 - 멀티플레이어의 가장 큰 장점은 단순한 동시 편집이 아니라 팀의 **단일 진실 공급원(single source of truth)** 을 제공하는 데 있다. - 하나의 URL로 디자인을 공유할 수 있고, 파일이 수정되어도 URL은 유지된다. - 이에 따라 파일을 복사하거나 최신 버전을 확인하고 디자인 자산을 동기화하는 복잡한 과정이 줄어든다. - 카피라이터는 디자인 안에서 문구를 직접 시험할 수 있고, 개발자는 디자인 속성을 확인해 코드로 옮길 수 있으며, 제품 관리자는 별도 메시지 없이 프로젝트 상태를 파악할 수 있다. - 여러 사람이 오래된 파일을 사용하거나 서로의 작업을 덮어쓰는 문제도 줄어든다. ## 컴포넌트와 확장 가능한 디자인 시스템 - 2016년 12월 8일 컴포넌트 기능을 출시했다. - 제품이 커질수록 상태 표시줄, 내비게이션 메뉴, 아이콘처럼 반복되는 UI 요소를 여러 파일과 팀원 사이에서 일관되게 관리해야 한다. - 컴포넌트를 사용하면 기본 요소를 수정했을 때 관련 디자인에 변경 사항을 일관되게 반영할 수 있다. - 디자이너가 모든 화면을 수동으로 찾아 업데이트해야 하는 부담을 줄여 준다. - **컴포넌트 오버라이드**를 통해 개별 인스턴스의 색상이나 텍스트 폰트 등 특정 속성만 바꿀 수 있다. - 개별 화면에 필요한 차이를 허용하면서도 전체 디자인 시스템과의 연결은 유지할 수 있다. - 2017년 2월 15일에는 여러 파일과 팀에서 컴포넌트를 공유하기 위한 Team Library 베타를 공개했다. ## 실용적인 결론 Figma의 첫해 성장은 단순히 기능을 많이 추가한 결과가 아니라, 디자인 파일을 팀 전체가 함께 사용하는 중앙 작업 공간으로 바꾼 데서 비롯됐다. 협업이 중요한 팀이라면 실시간 편집뿐 아니라 공유 URL, 최신 버전 유지, 컴포넌트 재사용, 기존 Sketch 자산의 이전 가능성까지 함께 고려하는 것이 Figma식 워크플로의 핵심이다.

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

Figma디자인 시스템collaborative-designmultiplayer-editing+2

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

Figma의 2단계 인증

Figma는 2017년 계정 보안을 강화하기 위해 2단계 인증(2FA)을 도입했다. 비밀번호가 유출되더라도 SMS나 인증 앱을 통한 추가 인증으로 계정을 보호할 수 있으며, 새 기기 로그인이나 로그아웃 후 재로그인 시 인증이 요구된다. 인증 상태는 21일간 유지되고, 휴대전화를 잃어버렸을 때 사용할 복구 코드도 제공된다. ## 2단계 인증 도입 배경 - 로그인 자격 증명이 유출되더라도 계정을 안전하게 보호하기 위한 추가 보안 수단이다. - 사용자가 계정 데이터 보호 수준을 직접 선택할 수 있도록 보안 옵션을 확대했다. ## 인증 방식 - Figma 계정 설정에서 2FA를 활성화할 수 있다. - 로그인 코드는 다음 방식 중 하나로 받을 수 있다. - SMS - Google Authenticator 같은 인증 앱 - 모든 종류의 휴대전화에서 사용할 수 있도록 설계됐다. ## 복구 코드와 계정 복구 - 계정 설정 페이지에서 2FA 복구 코드를 확인할 수 있다. - 휴대전화를 분실하거나 인증 앱에 접근할 수 없을 때 복구 코드를 사용해 인증할 수 있다. - 복구 코드는 휴대전화 분실 전에 안전한 장소에 기록해 두어야 한다. ## 인증이 요구되는 시점 - 사용자가 로그아웃한 뒤 다시 로그인할 때 2FA 인증이 필요하다. - 새로운 기기에서 로그인할 때도 추가 인증을 요구한다. - 로그인 후 인증 상태는 21일 동안 유지되며, 이후 다시 인증해야 한다. ## 실용적인 권장 사항 - 계정에 민감한 디자인 파일이나 협업 자료가 있다면 2FA를 활성화하는 것이 좋다. - SMS보다 인증 앱을 우선 고려하고, 복구 코드는 비밀번호 관리자 등 안전한 장소에 별도로 보관하는 것이 바람직하다.

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

Figmatwo-factor-authenticationgoogle-authenticatorsms+1

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

해커톤이 테크 디

해커톤은 디자이너를 기술 업계로 유입시키는 효과적인 통로가 될 수 있지만, 기존 개발자 중심 문화 때문에 디자이너들이 애초에 자신을 위한 행사라고 느끼지 못한다. Hack@Brown의 사례는 브랜딩 개선, 디자인 전용 시상, 적극적인 참가자 모집과 기업 멘토링을 통해 이 장벽을 낮출 수 있음을 보여준다. 따라서 디자이너 부족 문제를 해결하려면 해커톤 주최자뿐 아니라 기술 기업도 직접 디자이너를 찾아가고 성장 경로를 제시해야 한다. ## 디자이너에게 해커톤이 필요한 이유 - 해커톤은 짧은 시간 안에 팀을 구성하고 아이디어를 제품으로 발전시키는 행사다. - 디자이너는 해커톤에서 다음과 같은 경험을 얻을 수 있다. - 엔지니어와 협업 - 제품 아이디어 구상과 빠른 반복 - 화면과 플랫폼 제약을 고려한 디자인 - 이론적으로는 기술 업계의 디자이너 채용을 위한 자연스러운 인재 발굴 경로가 될 수 있다. - 그러나 실제 해커톤은 개발자 중심의 분위기와 이미지가 강해, 디자이너들이 자신은 어울리지 않는다고 생각하기 쉽다. ## Hack@Brown의 디자이너 유치 전략 - Brown University의 Hack@Brown은 약 500명이 참여하는 대학 해커톤으로, 디자인 전공 학생을 적극적으로 끌어들이는 모델을 제시했다. - RISD 학생들 중에는 코딩을 못하면 참여할 수 없거나, 기술 기업에서 일하는 것을 “매도”처럼 여기는 인식이 있었다. - 주최 측은 이를 바꾸기 위해: - 행사 브랜딩을 더 전문적이고 디자인 친화적으로 개편 - UX·UI 분야를 위한 별도 상금 마련 - 전국 디자인 동아리에 직접 연락 - 참가자의 프로비던스 왕복 교통비 지원 - 디자인 전공자를 운영진에 더 많이 포함 - 그 결과 디자인 참가자는 2013년 15~20명에서 2017년 100명 이상으로 증가했고, 전체 참가자의 약 20%를 차지했다. ## 기술 업계로 가는 보이지 않는 경로 - 엔지니어에게는 학습 방법과 취업으로 이어지는 비교적 명확한 경로가 있지만, 기술 업계의 제품 디자이너가 되는 과정은 덜 정립되어 있다. - 디자이너가 해커톤에 참여하더라도 개발자 채용 부스만 보이면 자신이 환영받지 못한다고 느낄 수 있다. - 한 참가자는 행사장이 엔지니어 중심이라는 인상을 받자 곧바로 떠나기도 했다. - 따라서 기업이 디자이너가 있는 곳으로 직접 찾아가야 한다는 주장이 제기된다. - 제품 디자이너가 될 가능성이 있는 학생을 발굴 - 현업 디자이너를 멘토로 파견 - 참가자에게 직무와 채용 경로를 설명 - Hack@Brown 운영자였던 Atty Eleti도 행사에서 현업 디자이너를 만나 자신의 진로를 엔지니어에서 디자이너로 전환했다. 잠재력을 알아보고 격려해 주는 한 번의 만남이 진로 형성에 결정적일 수 있다는 사례다. ## 해커톤에서 채용으로 이어지는 퍼널 - Hack@Brown은 단순한 행사 참여를 넘어 기업과 학생을 연결하는 채용 퍼널로 발전했다. - Facebook 등 기술 기업은 행사에 멘토를 보내 잠재력 있는 학생을 만나고, 이후 후속 통화나 캠퍼스 방문으로 관계를 이어갔다. - 당시 기술 기업들은 디자이너 채용을 크게 늘리고 있었다. - Facebook의 디자이너 채용 목표가 과거보다 크게 증가 - LinkedIn과 Dropbox는 엔지니어 4~5명당 디자이너 1명 수준의 채용 비율을 목표로 설정 - IBM과 GE도 디자이너 대규모 채용을 추진 - 해커톤 참가자 상당수는 기술·제품 디자인 업계 진입에 불안을 느꼈지만, 기업 입장에서는 아직 발굴되지 않은 인재가 풍부한 공간이었다. 해커톤이 디자이너 부족 문제의 만능 해결책은 아니지만, 행사를 개발자만의 공간이 아니라 디자이너와 엔지니어가 함께 제품을 만드는 공간으로 설계한다면 강력한 인재 발굴 경로가 될 수 있다. 주최자는 디자인 친화적인 환경을 만들고, 기업은 현업 디자이너를 파견해 참가자에게 구체적인 진로와 채용 기회를 보여주는 것이 좋다.

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

Figma사용자 경험프로덕트 디자인사용자 인터페이스+2

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

디자인하는 여성들 | 피

여성 디자이너가 부족하다는 업계의 주장은 실제 인재를 찾으려는 노력이 부족해서 생긴 핑계일 수 있다. 이 글은 여성 디자이너 목록인 **Women Who Design**과 이를 촉발한 트위터 캠페인을 통해, 뛰어난 여성 인재가 이미 널리 존재하며 적극적으로 찾아야 한다고 주장한다. 다만 성별을 기준으로 인재를 분류하는 일이 편견을 강화할 수 있다는 역설도 함께 제기한다. ## 여성 기술 인재를 찾기 어려운 이유는 ‘부재’가 아니라 ‘가시성’이다 - 기술 업계에서 여성 인재가 남성보다 주목받지 못하는 현상은 널리 알려져 있다. - 여성 기술 인재 1,000명의 목록이나 여성 벤처 투자자 목록처럼, 기존의 인맥과 추천 구조에서 가려진 인재를 드러내려는 시도가 이어졌다. - 이런 목록이 성차별을 즉시 해결하지는 못하지만, “적합한 여성이 없다”는 주장이 사실이 아님을 보여준다. ## Women Who Design 웹사이트 - 세쿼이아의 프로덕트 디자이너 Jules Forrest가 업계 추천을 바탕으로 여성 디자이너를 모은 웹사이트를 만들었다. - 사용자는 다음과 같은 분야별 필터로 인재를 탐색할 수 있다. - 창업자 - UX 리서치 - 제품 디자인 등 - 이 사이트는 채용뿐 아니라 팔로우할 사람, 함께 일하고 싶은 사람, 롤모델을 찾는 자료로도 활용될 수 있다. - 이후에는 추천 양식을 추가해 목록을 지속적으로 확장할 계획이었다. - 공개 목록에 포함되기를 원하지 않는 사람을 위해 이메일을 통한 제외 요청도 제공했다. ## 트위터에서 시작된 대규모 추천 - Shopify 디자인 리드 Helen Tran은 디자인 인플루언서를 이야기할 때 남성만 언급되는 상황에 문제를 제기했다. - 그녀는 팔로워들에게 존경하는 여성 디자이너를 추천해 달라고 요청했다. - 트윗은 며칠 만에 다음과 같은 반응을 얻었다. - 리트윗 256회 - 좋아요 704회 - 답글 368개 - 450명 이상의 여성 디자이너 추천 - 버즈피드 디자인 부사장과 구글 벤처스 디자인 파트너 등 업계 주요 인사들도 참여했다. - 단순한 질문 하나가 여성 프로덕트 디자이너가 업계 곳곳에 존재한다는 사실을 가시화했다. ## 목록화의 효과와 한계 - 공개된 인재 목록은 채용 담당자가 새로운 후보자를 찾는 데 실질적인 도움을 줄 수 있다. - 젊은 여성 디자이너에게는 자신과 비슷한 동료와 업계 리더를 발견하는 기회가 된다. - 반면 “여성 디자이너”라는 분류가 개인의 역량보다 성별을 먼저 보게 만들 위험도 있다. - 당사자가 성별 정체성으로 분류되는 것을 불편해하거나, 개인정보가 검색 가능한 상태가 되는 것을 원하지 않을 수도 있다. - 따라서 포용성을 높이기 위한 분류가 오히려 새로운 편견이나 불편을 만들지 않도록 당사자의 선택권을 보장해야 한다. ## 업계의 오래된 핑계를 넘어 - “여성 연사가 없다”, “여성 팀 리더 후보가 없다”, “자격을 갖춘 여성이 없다”는 주장은 충분히 찾지 않았다는 뜻일 수 있다. - 인재를 찾는 조직은 기존 네트워크에만 의존하지 말고 공개 커뮤니티, 추천, 전문 목록 등을 적극적으로 활용해야 한다. - 여성 인재의 가시성을 높이는 일은 채용의 다양성뿐 아니라 업계의 롤모델과 영향력 구조를 바꾸는 데도 기여한다. 실무적으로는 성별 균형 목표를 세우는 데 그치지 말고, 다양한 후보자 풀이 실제로 존재하는지 조사하고 공개 추천·커뮤니티·전문 디렉터리를 채용 과정에 포함하는 것이 바람직하다.

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

사용자 경험프로덕트 디자인design-recruitingdesign-community+2

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

안드로이드용 피그마 미

Figma는 2017년 5월, 디자인을 Android 기기에서 실시간으로 확인할 수 있는 **Figma Mirror for Android**를 출시했다. 컴퓨터에서 선택한 프레임과 수정 사항이 모바일 앱에 즉시 반영되어 실제 기기에서 디자인을 검토할 수 있으며, 앱을 설치하지 않고 모바일 브라우저로도 같은 기능을 사용할 수 있다. Android 사용자가 전 세계 스마트폰 사용자에서 큰 비중을 차지한다는 점을 고려한 제품 확장이다. ## Android용 Figma Mirror 출시 - 기존 iOS용으로 제공되던 Figma Mirror를 Android로 확대했다. - Android 사용자는 Google Play에서 앱을 내려받아 Figma 디자인을 모바일 기기에서 확인할 수 있다. - 이 기능은 특히 Android 앱을 디자인하는 디자이너가 실제 기기 환경에서 결과물을 검토하는 데 유용하다. ## 컴퓨터와 모바일의 실시간 디자인 동기화 - 컴퓨터에서 Figma 파일의 특정 프레임을 선택하면 해당 화면이 Android 앱에 표시된다. - 컴퓨터에서 디자인을 수정하면 변경 사항이 모바일 미러 화면에 즉시 반영된다. - 별도의 내보내기나 파일 전송 없이 디자인과 실제 모바일 화면을 빠르게 비교할 수 있다. - 이를 통해 모바일 레이아웃, 화면 비율, 인터랙션 결과 등을 작업 중에 확인할 수 있다. ## 모바일 브라우저를 통한 미러링 - 앱을 설치하고 싶지 않은 사용자는 모바일 브라우저에서 `figma.com/mobile-app`에 접속할 수 있다. - 브라우저 기반 방식도 앱과 동일하게 Figma 디자인을 모바일 기기에 표시한다. - Android뿐 아니라 앱 설치가 제한된 환경에서도 접근성을 높인 방식이다. ## Android 디자인을 위한 프레임 프리셋 - Figma는 여러 인기 Android 기기에 맞춘 화면 크기 프리셋을 제공한다. - 디자이너는 기기 해상도와 비율을 직접 계산해 처음부터 프레임을 만들 필요가 없다. - 실제 타깃 기기와 유사한 프레임에서 디자인을 시작해 프로토타입 검토를 효율화할 수 있다. ## Android 시장을 고려한 제품 확장 - 글에서는 Android가 당시 미국 스마트폰 사용자 중 52%, 전 세계적으로는 82%를 차지한다고 설명한다. - 따라서 Android 지원은 일부 사용자를 위한 기능 추가가 아니라, 대규모 모바일 사용자와 디자이너를 포괄하기 위한 중요한 확장이다. - iOS와 Android 모두에서 실제 기기 기반 검토가 가능해지면서 Figma의 모바일 디자인 검증 범위가 넓어졌다. 실무에서는 Android용 프레임 프리셋으로 디자인을 시작한 뒤 Figma Mirror 또는 모바일 브라우저에서 실제 기기 화면을 확인하는 방식을 추천한다. 이를 통해 데스크톱 미리보기만으로는 발견하기 어려운 크기, 비율, 여백 문제를 조기에 수정할 수 있다.

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

FigmaAndroidiOSmobile-app-development+1

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

Figma를 이끌 새로운 얼굴

Figma는 디자인 협업 도구에 대한 수요가 커지는 가운데, 사업의 다음 단계로 성장하기 위해 핵심 리더 두 명을 영입했다고 발표했다. Atlassian 출신 Eric Wittman은 첫 COO로서 운영·수익·시장 진출 전략을 맡고, Asana 출신 Kris Rasmussen은 엔지니어링 부사장으로 기술 조직과 제품 개발을 이끈다. 이들의 합류를 통해 Figma는 협업 중심의 제품 비전을 강화하고 회사 확장에 필요한 조직 역량을 갖추려 한다. ## 디자인 협업 도구 시장의 성장 - 기술 산업이 성숙하면서 고객이 사랑하는 제품을 만들기 위한 디자인의 중요성이 커지고 있다. - IBM과 GE 같은 대기업이 디자이너를 적극적으로 채용하고, Facebook은 엔지니어 4~5명당 디자이너 1명을 두는 방향을 추진하고 있다. - 그러나 디자이너가 실제 업무에서 사용하는 기술과 도구는 이러한 수요를 충분히 따라가지 못하고 있다. - Figma는 여러 사람이 함께 작업할 수 있도록 협업을 쉽게 만드는 것을 제품 전략의 핵심 기준으로 삼고 있다. ## Eric Wittman의 COO 합류 - Eric Wittman은 Atlassian에서 개발자 도구 사업을 이끌었으며, Bitbucket 운영 경험을 보유하고 있다. - Figma의 첫 COO로서 다음 업무를 담당한다. - 채용과 재무 등 회사 운영 프로세스 확장 - 시장 진출(GTM) 전략 - 매출과 수익 모델 관리 - 회사 전략 및 가치 정립 - 합류 초기부터 Figma의 가격 정책을 출시하고 회사 전략과 가치를 구체화하는 데 기여했다. - Macromedia 고객지원에서 시작해 Flash 제품관리 책임자까지 성장했으며, Songbird CEO와 Atlassian 개발자 도구 총괄을 거쳤다. - 운영과 사업 전문가이면서도 제품에 깊은 관심을 가진 인물이라는 점이 Figma와 잘 맞는다고 평가받았다. ## Kris Rasmussen의 엔지니어링 리더십 - Kris Rasmussen은 처음에는 주 2일 근무하는 파트타임 계약자로 Figma에 합류했다. - 짧은 근무 시간에도 팀 내에서 자연스럽게 리더 역할을 하며 다음과 같은 기여를 했다. - 논쟁이나 의견 충돌이 있을 때 핵심 쟁점을 제시 - 팀이 결정을 내리고 업무를 진전시키도록 지원 - 조용하지만 영향력 있는 방식으로 팀을 이끔 - Asana 초기 엔지니어링 조직을 이끌며 협업 제품의 인프라 구축과 팀 운영을 경험했다. - Aptana에서 웹 애플리케이션 개발자 도구의 엔지니어링 확장을 담당했고, 개인 프로젝트로 3D 그래픽 애플리케이션도 개발했다. - Figma에서는 세계적 수준의 기술 조직을 구축하고 여러 엔지니어링 프로젝트를 총괄한다. ## 성장 단계에 맞춘 조직 확장 - Figma는 제품을 만드는 것뿐 아니라, 빠르게 성장할 수 있는 운영·수익·기술 조직을 함께 구축하려 한다. - COO 영입으로 사업 전략과 운영 체계를 강화하고, 엔지니어링 부사장 영입으로 기술 인프라와 개발 조직의 확장을 추진한다. - 두 리더 모두 협업형 소프트웨어 기업에서 성장 경험을 쌓았다는 공통점이 있다. - 회사는 엔지니어, 디자이너, 작가, 제품 관리자 등 디자인에 열정을 가진 인재를 추가로 채용할 계획이다. Figma의 사례는 제품 비전이 명확한 초기 기업이 성장 국면에 진입할 때, 제품을 이해하는 사업 리더와 협업 기술에 경험이 있는 엔지니어링 리더를 함께 영입하는 전략을 보여준다.

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

Figmadesign-collaborationsaasdeveloper-tools+2

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

에어비앤비 존 골

에어비앤비의 디자인 테크놀로지스트 젬 골드는 디자인을 결과물이 아니라 시스템과 프로세스의 산물로 바라본다. 그가 고른 다섯 권의 책은 디자인 시스템, 인간과 컴퓨터의 협업, 집중력, 명상, 함수형 프로그래밍에 대한 관점을 형성했다. 공통적으로 작은 구성 요소를 조합하고, 인간의 창의성을 확장하는 도구와 환경을 중시한다. ## 디자인을 생성하는 시스템으로 보기 — 《Designing Programmes》 - 칼 게르스트너의 책은 레이아웃·로고·타이포그래피를 개별 결과물이 아니라 일정한 규칙과 과정이 만들어내는 산출물로 설명한다. - 디자이너가 매번 최종 결과를 직접 만드는 대신, 사람이 조정할 수 있는 디자인 파이프라인과 시스템을 설계한다는 관점을 제시한다. - UI 디자인 시스템이 등장하기 전의 책이지만, 오늘날의 디자인 시스템과 자동화된 제작 도구에도 그대로 연결된다. - 젬 골드는 이 관점을 에어비앤비의 디자인 시스템과 디자인 자동화 작업에 적용하고 있다. ## 반응을 늦추는 습관 — 《10% Happier》 - 명상은 즉각적인 감정이나 직관에 따라 반응하기보다, 문제를 관찰하고 더 나은 대응을 선택하게 해준다. - 이 책은 명상 기법 안내서라기보다, 방송 중 신경 쇠약을 겪은 저널리스트 댄 해리스의 회고록에 가깝다. - 저자는 명상에 관한 여러 주장에 회의적인 태도를 유지하며, 종교적·초월적 설명보다 실제 경험과 검증 가능성을 중시한다. - 젬 골드는 이런 현실적이고 비판적인 태도가 디자인 의사결정에도 도움이 된다고 본다. ## 인간의 지능을 확장하는 컴퓨터 — 《The Dream Machine》 - J. C. R. 리클라이더가 주창한 ‘인간-컴퓨터 공생’과 컴퓨터의 상호작용적 활용을 다룬다. - 컴퓨터를 펀치카드를 입력하고 결과를 오래 기다리는 기계가 아니라, 인간의 사고력을 증폭하고 함께 탐구하는 도구로 바라본다. - IBM 중심의 정적이고 관료적인 컴퓨팅 비전에 맞서, 사람들이 즐겁게 사용할 수 있는 인터랙티브 컴퓨팅을 추구한 연구자들의 역사를 소개한다. - 젬 골드는 기존 관습에 도전하고 인간의 능력을 확장하는 기술을 만들려는 태도를 자신의 작업에도 이어가고 있다. ## 창의성을 위한 집중력 — 《Deep Work》 - 소셜 미디어는 작업 중 주의를 끊고, 사고와 상상력을 계속 초기화해 깊은 아이디어를 형성하기 어렵게 만든다. - 젬 골드는 한 달 동안 소셜 미디어를 끊고, 창작 작업을 위한 시간을 미리 일정에 배치했다. - 초기에는 확인 충동을 참기 어렵지만, 달리기나 독서처럼 창의성을 회복시키는 활동으로 주의를 전환할 수 있다. - 집중력은 단순히 방해 요소를 제거하는 것이 아니라, 창의적인 활동으로 삶의 빈자리를 채우는 습관과 관련된다. ## 작은 단위의 조합과 확장 — 《Professor Frisby’s Mostly Adequate Guide to Functional Programming》 - 함수형 프로그래밍은 문제를 가능한 한 작은 단위로 나눈 뒤, 이 요소들을 조합하고 재배열하는 방식이다. - 짧고 무료로 읽을 수 있어 프로그래밍 입문자에게도 비교적 접근하기 쉽다. - 젬 골드는 이 사고방식이 디자인에도 직접 적용된다고 본다. - 큰 레이아웃이나 마케팅 페이지부터 시작해 쪼개는 대신, 가장 작은 디자인 프리미티브에서 출발해 점진적으로 구성 요소를 쌓아 올린다. - 이는 디자인 시스템에서 재사용성과 일관성을 확보하는 데 특히 유용하다. ## 실무에 적용할 점 - 디자인을 개별 시안이 아니라 규칙·구성 요소·자동화 과정이 결합된 시스템으로 설계한다. - 작은 프리미티브부터 시작해 복잡한 화면과 제품으로 확장한다. - 소셜 미디어와 즉각적인 반응을 줄여 깊이 있는 작업 시간을 확보한다. - 기술을 단순한 자동화 수단이 아니라 인간의 사고와 창의성을 강화하는 협업 도구로 활용한다.

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

AI디자인 시스템Reacttypography+2

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

속도 제한에 대한 대안

Figma는 스팸 공격으로부터 서비스를 보호하기 위해 Redis 기반의 자체 레이트 리미터를 구축했다. 토큰 버킷과 고정 윈도 카운터는 메모리 효율이 좋지만 정확성이나 동시성 문제가 있었고, 슬라이딩 윈도 로그는 정확하지만 메모리를 많이 사용한다. Figma는 여러 기법을 조합해 분산 환경에서 빠르고 정확하며 메모리 효율적인 방식으로 요청량을 제한했다. ## 레이트 리미팅의 요구사항 - 사용자나 IP 주소별로 일정 시간 동안 허용할 요청 수를 제한한다. - 예: 1분에 25회 요청 허용 - 여러 웹 서버가 동일한 제한 정보를 공유해야 하므로 외부 저장소가 필요하다. - 웹 요청 처리 속도를 크게 저하시켜서는 안 된다. - 오래된 추적 데이터를 효율적으로 삭제해야 한다. - 과도한 요청을 정확하게 차단하면서 메모리 사용량도 최소화해야 한다. - Figma는 PostgreSQL보다 읽기·쓰기 속도가 빠르고 만료 키를 지원하는 Redis를 추적 데이터 저장소로 선택했다. ## 토큰 버킷의 장점과 동시성 문제 - 사용자마다 다음 두 값을 Redis 해시에 저장한다. - 마지막 요청 시각 - 현재 남아 있는 토큰 수 - 시간이 지나면 설정된 보충 속도에 따라 토큰을 다시 채운다. - 토큰이 0개가 되면 요청을 제한한다. - 장점: - 구현 개념이 단순하다. - 사용자별로 작은 해시 하나만 저장하므로 메모리 효율이 높다. - 일정한 요청 속도와 일시적인 버스트를 모두 처리할 수 있다. - 문제점: - Redis에서 값을 읽고 계산한 뒤 다시 쓰는 과정이 원자적이지 않다. - 두 서버가 동시에 같은 토큰 수를 읽으면, 둘 다 요청을 허용하는 경쟁 조건이 발생할 수 있다. - 결과적으로 실제 허용량보다 많은 요청이 통과할 수 있다. - Redis 락이나 Lua 스크립트로 원자성을 보장할 수 있지만, 락은 지연과 복잡성을 늘리고 Lua는 코드베이스에 별도 언어를 추가해야 한다. ## 고정 윈도 카운터의 단순성과 경계 문제 - 요청이 발생한 시간 구간을 키로 삼아 Redis 카운터를 증가시킨다. - 예: `user:1:2017-03-30T10:00`에 해당 분의 요청 수 저장 - 카운터가 제한값을 넘으면 요청을 거부한다. - 각 키에 만료 시간을 설정해 오래된 카운터를 자동 삭제한다. - `INCR` 같은 Redis 연산을 사용하므로 토큰 버킷보다 동시성 처리가 안전하다. - 메모리 사용량도 적고 구현과 동작을 이해하기 쉽다. - 하지만 윈도 경계에서 허용량보다 최대 두 배 많은 요청이 통과할 수 있다. - 예를 들어 분당 5회 제한에서 10:00:59에 5회, 10:01:00에 다시 5회를 보내면 실제로는 2초 안에 10회가 허용된다. - 따라서 고정 윈도만으로는 요청량을 정확하게 제한하기 어렵다. ## 슬라이딩 윈도 로그의 정확성과 메모리 비용 - 각 요청의 정확한 타임스탬프를 저장한다. - 새 요청이 들어오면 제한 시간보다 오래된 기록을 삭제하고, 현재 윈도 안의 요청 수를 계산한다. - 윈도가 계속 이동하므로 고정 윈도 경계에서 발생하는 폭주 문제가 없다. - 가장 정확한 방식이지만 모든 요청 기록을 보관해야 한다. - 요청 빈도가 높은 사용자나 공격자가 많아지면 저장해야 할 타임스탬프 수가 급증한다. - 따라서 정확성은 높지만 Redis 메모리를 많이 사용한다. ## Figma의 절충 방식 - Figma는 고정 윈도 카운터의 낮은 메모리 사용량과 슬라이딩 윈도의 정확성을 결합하는 방식을 사용했다. - 전체 제한 구간을 더 작은 시간 단위의 카운터들로 나누고, 현재 구간과 직전 구간의 요청량을 이용해 이동 중인 윈도의 사용량을 계산한다. - 개별 요청의 타임스탬프를 모두 저장하지 않고 카운터만 유지하므로 슬라이딩 윈도 로그보다 메모리 효율적이다. - Redis의 원자적 카운터 증가 연산을 활용해 여러 애플리케이션 서버가 동시에 요청을 처리해도 경쟁 조건을 줄일 수 있다. - Redis 키에 만료 시간을 지정해 오래된 시간 구간의 데이터가 자동으로 제거되도록 한다. - 이 방식은 완벽한 요청 단위 정확성보다는 약간의 근사치를 허용하는 대신, 다음 특성을 균형 있게 제공한다. - 분산 환경에서의 안전성 - 낮은 지연 시간 - 적은 메모리 사용량 - 고정 윈도보다 나은 제한 정확도 ## 스팸 공격 방어 효과 - 공격자는 다수의 이메일 주소로 문서 초대 요청을 반복해서 보냈다. - 레이트 리미터가 비정상적인 요청 증가를 조기에 감지해 추가 요청을 차단했다. - 그 결과 이메일 발송 비용의 급증과 발신자 평판 하락을 막을 수 있었다. - 레이트 리미팅은 단순한 성능 보호 장치뿐 아니라 이메일 초대, 비밀번호 재설정, 결제 등 악용되기 쉬운 기능의 스팸 방어 수단으로도 활용할 수 있다. 서비스 규모가 크고 여러 서버가 요청을 처리한다면 Redis 기반의 원자적 카운터와 만료 키를 우선 고려하는 것이 실용적이다. 높은 정확성이 필요하면 슬라이딩 윈도 로그를, 메모리와 성능을 중시하면 슬라이딩 윈도 카운터나 세분화된 고정 윈도 방식을 선택하는 것이 적절하다.

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

PostgreSQL분산 시스템redisrate-limiting+2

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

피그마의 새로운 아이

Figma의 새 아이콘은 단순한 로고 변경이 아니라, 회사의 디자인 철학과 제품 정체성을 시각화한 결과다. 아이콘은 디자인의 기본 요소를 기념하고, 놀이와 실험을 장려하며, 재사용 가능한 모듈과 시스템으로서의 디자인을 표현한다. Figma는 이를 통해 복잡한 결과물도 단순한 요소와 규칙의 조합에서 출발한다는 메시지를 전달한다. ## 디자인의 기본 요소를 기념 - 모든 디자인은 점, 선, 도형 같은 기본 요소에서 시작한다. - 복잡한 디자인도 필수적인 구성 요소들의 조합으로 단순화할 수 있다. - Figma는 많은 도구를 제공하기보다, 벡터 네트워크나 프레임처럼 적은 수의 강력한 기능이 서로 잘 결합되는 방식을 중시한다. - 기본 도형과 원색을 활용하는 디자인 철학은 바우하우스 등에서 강조되어 왔으며, 오랜 디자인 전통과 연결된다. - 새 아이콘은 모든 디자인 프로젝트의 출발점인 단순한 형태와 구성 요소를 상징한다. ## 놀이와 실험을 장려 - 기존 문제에 대한 새로운 해결책은 개방적인 태도와 실험, 때로는 구조화된 놀이를 통해 발견할 수 있다. - 아이들이 가지고 노는 블록에서 영감을 받아, 아이콘에 밝은 색상과 단순한 형태를 적용했다. - 놀이를 통해 정답에 얽매이지 않고 더 흥미로운 결과를 탐색할 수 있다는 믿음이 반영됐다. - 브루노 무나리, 앤 랜드와 폴 랜드처럼 주요 디자이너들이 어린이 책 작업을 통해 창의성과 놀이의 가치를 다룬 사례도 언급된다. - 아이콘은 Figma가 사용자에게 개방적이고 즐거운 디자인 경험을 제공하고자 한다는 점을 표현한다. ## 시스템으로서의 디자인 - 디지털 제품은 다양한 화면 크기, 운영체제, 모니터, 네트워크 환경에 대응해야 하므로 일회성 결과물보다 모듈형 시스템이 적합하다. - Figma는 디자인을 개별 아티팩트가 아니라 레시피나 청사진처럼 재사용 가능한 규칙과 구성 요소의 체계로 본다. - 픽셀 기반 디자인은 특정 환경을 벗어나면 쉽게 깨질 수 있지만, 벡터와 규칙 기반 디자인은 다양한 환경에 맞게 확장할 수 있다. - 새 아이콘은 세 가지 단순한 도형과 모듈형 그리드로 구성되어, 시스템 기반 디자인이라는 개념을 직접 보여준다. - 팀 라이브러리 같은 Figma의 기능 역시 여러 사람이 일관된 디자인 시스템을 구축하도록 돕는다는 철학에서 출발한다. Figma의 새 아이콘은 단순한 시각적 표식이 아니라, 기본 요소를 조합하고 자유롭게 실험하며 재사용 가능한 시스템을 만드는 디자인 관점을 압축한 상징이다. 디자인 작업에서는 복잡한 결과물을 처음부터 만들기보다, 단순한 구성 요소와 명확한 규칙을 조합하는 방식이 확장성과 창의성을 함께 높일 수 있다.

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

Figma디자인 시스템반응형 디자인vector-design+2

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

디자이너가 코

알렉스 코넬은 디자이너가 반드시 코딩을 배워야 한다는 통념에 의문을 제기한다. 그는 코딩 대신 영화 제작과 모션 그래픽을 선택했고, 그 전문성이 훗날 Facebook Live의 디자인과 제품 개발에 중요한 자산이 되었다. 결론적으로 코딩 학습은 개인의 흥미와 팀의 필요에 따라 결정해야 하며, 글쓰기와 커뮤니케이션 능력 역시 디자인 영향력을 키우는 핵심 역량이다. ## 코딩을 선택하지 않은 이유 - 코넬이 진로를 결정한 2007년에는 “디자이너가 코딩을 배워야 하는가”가 지금처럼 널리 논쟁되는 주제가 아니었다. - 당시 스타트업에는 이미 코딩을 깊이 아는 엔지니어들이 있었기 때문에, 자신까지 코딩을 배우는 것보다 팀에 없는 역량을 갖추는 편이 유용하다고 판단했다. - 그는 영화 제작, After Effects, Premiere 등 영상과 모션 그래픽 기술을 선택했다. - 프로토타이핑 도구가 부족했던 시절, After Effects를 활용해 얼굴 애니메이션과 인터랙션을 시각적으로 표현했다. - 궁극적으로 코딩보다 모션 그래픽이 더 흥미롭게 느껴졌다는 개인적 동기도 컸다. ## 전문성의 차별화가 만든 기회 - 코넬은 영화와 사진 분야의 역량 덕분에 Facebook에 영입되어 Live 기능 출시를 돕게 되었다. - 특정 직무의 표준 경로를 따르지 않고 팀에 부족한 능력을 개발한 것이 장기적으로 차별화된 경쟁력이 되었다. - 코딩을 직접 하지 않더라도 기술적 배경을 이해하면 엔지니어와 원활히 협업하고, 디자인을 구현 가능한 형태로 설명할 수 있다. ## 코딩 학습은 정답이 아닌 개인의 선택 - 코딩을 배울지 확신이 없다면, 코넬은 우선 “아니오”에 가깝게 답한다. - “영화 편집을 배워야 할까?”라는 질문처럼, 실제로 해당 분야에 흥미가 있는지가 판단의 출발점이 되어야 한다. - 코딩이 유용하다는 이유만으로 모든 디자이너에게 동일한 학습 경로를 강요할 수는 없다. - 디자인과 코딩의 경계는 Framer, Origami 같은 도구와 로직 기반 프로토타이핑의 등장으로 점점 흐려지고 있다. - 따라서 코딩을 할 줄 아는 디자이너와 그렇지 않은 디자이너라는 이분법보다, 자신에게 적합한 도구와 전문성을 선택하는 것이 중요하다. ## 글쓰기와 커뮤니케이션의 중요성 - 코딩 외에 특히 추천하는 역량은 글쓰기와 아이디어를 설명하고 설득하는 능력이다. - 훌륭한 디자인이나 애니메이션도 다른 사람을 납득시키고 관심을 끌지 못하면 실제 제품이나 의사결정으로 이어지기 어렵다. - 커뮤니케이션은 공식적인 발표뿐 아니라 회의, 영상, 강연, 프레젠테이션 등 다양한 방식으로 이루어진다. - 아이디어를 명확하게 전달하고 사람들을 움직이는 능력은 프로젝트의 방향 자체를 바꿀 수 있다. - 학교 교육은 글쓰기와 감성 지능, 대인 커뮤니케이션을 연습할 기회를 제공하므로 이런 역량을 충분히 익히기 전에 너무 일찍 학업을 중단하지 말 것을 권한다. 자신이 코딩에 흥미가 있고 제품 구현을 직접 다루고 싶다면 코딩을 배우는 것이 좋다. 그러나 모든 디자이너가 같은 길을 갈 필요는 없으며, 팀에 필요한 역량과 자신의 관심사를 기준으로 영상, 글쓰기, 발표, 리서치 등 차별화된 전문성을 개발하는 편이 더 실용적이다.

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

사용자 경험프로토타이핑framermotion-graphics+3

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

존 마에다가 State

기술이 보편화되면서 제품 차별화의 핵심이 기능에서 사용자 경험과 감정으로 이동하고 있으며, 이에 따라 제품 디자이너 수요가 급증할 것이라는 글이다. 동시에 디자인 교육은 디지털 제품 환경을 따라가지 못하고, 도구와 업무 흐름도 파편화되어 있다는 문제가 지적된다. 앞으로는 포용적 디자인, 음성 인터페이스, 보안 디자인, 중국의 영향력 확대가 중요해지지만, 도구의 지능화로 디자이너 역할이 줄어들 가능성도 함께 제시된다. ## 제품 디자이너 수요 급증 - 기술이 상품화되어 누구나 앱을 만들 수 있게 되면서, 제품의 성공을 결정하는 요소가 사용자에게 주는 감정과 삶과의 관련성으로 이동했다. - 주요 기업들은 제품 디자이너를 대규모로 채용하고 있다. - Facebook, Google, Amazon의 디자이너 채용은 1년 사이 65% 증가했다. - 대기업들은 최근 2년 동안 35개 이상의 디자인 에이전시를 인수했다. - 디자인은 시각적 장식이 아니라 제품 전략과 사용자 경험을 결정하는 핵심 역량으로 자리 잡고 있다. ## 포용적 디자인의 확대 - 기술 사용자가 대중 전체로 확대되면서 다양한 배경과 경험을 가진 사람을 고려하는 디자인이 필요해졌다. - 성별, 인종, 문화, 능력, 사회적 배경의 차이를 제품 설계에 반영해야 한다. - Airbnb, Slack, Google, Microsoft 등이 포용적 디자인을 주도하는 기업으로 언급된다. ## 디지털 환경을 따라가지 못하는 디자인 교육 - 많은 디자인 학교가 여전히 인쇄 시대의 타이포그래피 등 고전적 디자인 교육에 집중한다. - 웹과 모바일 제품을 설계하는 데 필요한 인터랙션, 프로토타이핑, 디지털 협업 등의 실무 교육은 부족하다. - 설문에 참여한 학생의 3분의 2 이상이 Lynda.com 같은 외부 서비스를 통해 디지털 기술을 독학했다고 답했다. - 대학 교육은 제도와 교육과정의 특성상 변화 속도가 느려, 현업의 수요를 단기간에 따라잡기 어렵다. ## 디자인 중심 투자와 창업 - 벤처캐피털 업계에서 디자인 역량을 핵심 경쟁력으로 보는 시각이 확산되고 있다. - 디자인 중심 기업에 투자하는 것을 목표로 하는 VC가 등장하고 있다. - 조사 대상 디자이너의 80%는 자금만 있다면 창업하겠다고 답했다. - 디자인은 기업의 외부 이미지뿐 아니라 제품 개발과 사업 모델을 이끄는 창업 역량으로 인식되고 있다. ## 디자인 도구의 증가와 업무 흐름의 파편화 - 제품 디자인 도구 시장은 다양한 도구와 작업 방식이 공존하는 ‘개척 시대’에 가깝다. - 아직 하나의 회사가 기획, 디자인, 협업, 개발 전달 과정을 완전히 통합하지 못했다. - 새로운 도구가 계속 등장하면서 선택지는 늘지만, 팀의 업무 방식은 오히려 복잡해질 수 있다. - 도구가 정교해질수록 머신 인텔리전스가 디자인 과정에 더 많이 개입할 가능성이 있다. - 자동화와 인공지능의 발전은 장기적으로 일부 디자이너 업무와 수요를 감소시킬 수 있다. ## 새롭게 부상하는 디자인 영역 - Alexa와 같은 음성 인터페이스를 설계하는 역량이 중요해진다. - 사이버보안 제품과 서비스를 위한 전문 디자이너 수요가 증가한다. - 중국이 기술과 디자인 분야에서 차지하는 영향력이 커질 것으로 전망된다. - 제품 디자이너는 화면 기반 UI뿐 아니라 음성, 보안, 글로벌 시장을 아우르는 역량을 갖춰야 한다. 글은 전반적으로 기술 업계 디자인의 미래를 낙관적으로 전망하지만, 교육 시스템의 지연과 도구·워크플로의 분열을 주요 과제로 남긴다. 실무적으로는 디자이너가 디지털 제품 역량과 포용적 설계 능력을 함께 익히고, 조직은 도구를 늘리기보다 협업 과정과 업무 흐름을 통합하는 데 집중하는 것이 바람직하다.

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

Figma프로덕트 디자인web-designuser-interface-design+4