Techlist.io - 한국 테크 블로그 큐레이터

figma2023년 12월 5일3분 읽기큐레이션 요약

변수에 관한 모든 궁금증 해결

Figma의 변수(Variables)는 단순한 디자인 토큰을 넘어 여러 상태와 플랫폼에 따라 디자인 값을 동적으로 바꾸고, 디자인과 코드를 더 밀접하게 연결하는 기능이다. 이번 업데이트로 효과, 선 두께, 투명도, 레이아웃 그리드, 모서리 반경, 중첩된 컴포넌트 인스턴스까지 변수로 제어할 수 있게 되어 반응형·다중 플랫폼 디자인의 유연성이 크게 향상됐다. Figma는 앞으로 타이포그래피 영역까지 변수 활용을 확장할 계획이다. ## 변수의 확장된 활용 - 변수는 색상이나 간격 같은 고정된 토큰을 대체하는 데 그치지 않고, 모드에 따라 값이 달라지는 유연한 설계 단위로 사용된다. - 데스크톱·모바일, 라이트·다크 모드, 브랜드별 테마 등 서로 다른 조건에 맞춰 디자인을 한 번에 조정할 수 있다. - Headspace처럼 디자인 시스템의 일관성을 유지하면서도 다양한 제품 상황과 협업 요구에 대응하는 데 활용할 수 있다. - 변수의 개방적인 구조 덕분에 일반적인 디자인 시스템뿐 아니라 Figma 안에서 게임과 인터랙티브 작품을 만드는 등 창의적인 용도로도 사용된다. ## 효과와 시각적 속성의 반응형 제어 - 블러 크기, 드롭 섀도의 색상, 오프셋 거리 등 효과의 다양한 속성에 변수를 바인딩할 수 있다. - 모드가 바뀌면 효과 값도 함께 변경되므로, 플랫폼이나 테마에 맞는 시각적 표현을 자동으로 적용할 수 있다. - 레이어의 불투명도 역시 변수로 제어할 수 있으며, 불투명도 필드를 마우스 오른쪽 버튼으로 클릭해 변수를 연결한다. - 개별 모서리 반경을 변수에 연결해 네 모서리를 동일하게 처리하지 않고 각각 세밀하게 조정할 수 있다. ## 플랫폼별 반응형 디자인 - 선 두께를 변수로 관리해 데스크톱과 모바일 등 플랫폼별로 다른 스트로크 값을 적용할 수 있다. - 레이아웃 그리드도 변수와 모드에 따라 변경할 수 있어 화면 크기나 기기별 레이아웃을 더욱 정밀하게 설계할 수 있다. - 동일한 컴포넌트 구조를 유지하면서 모드만 전환해 픽셀 단위로 최적화된 디자인을 만들 수 있다. ## 중첩된 컴포넌트 인스턴스 제어 - 컴포넌트 내부에 포함된 다른 컴포넌트 인스턴스의 변형(variant)에도 변수를 연결할 수 있다. - 이를 통해 복잡한 컴포넌트 구조에서도 내부 요소의 상태와 속성을 상위 시스템에서 유연하게 제어할 수 있다. - 여러 단계로 중첩된 디자인 시스템을 구성할 때 반복적인 수동 수정이 줄어든다. ## 변수와 스타일의 관계 - 스타일은 특정 색상, 텍스트, 효과 등을 재사용하는 데 적합한 반면, 변수는 조건이나 모드에 따라 값이 바뀌는 동적 상황에 더 적합하다. - 변수는 기존 스타일을 대체하기보다는 스타일과 함께 사용해 디자인 시스템을 확장하는 방식으로 이해할 수 있다. - 변수의 활용 범위가 넓어지면서 디자인 파일의 값과 실제 코드에서 사용하는 토큰 사이의 연결도 더 자연스러워진다. ## 디자인과 코드의 연결 강화 - 변수 기반으로 디자인 값을 관리하면 개발자가 사용하는 플랫폼별 토큰 및 테마 값과 디자인 시스템을 맞추기 쉬워진다. - 모드와 변수 구조를 코드의 상태값이나 디자인 토큰 구조에 대응시킬 수 있어 핸드오프 과정의 불일치를 줄일 수 있다. - Figma는 이러한 연계를 앞으로 타이포그래피까지 확장하려 하며, 글꼴 크기·행간·문자 간격 등도 더 유연하게 관리할 가능성을 제시한다. 실무에서는 먼저 색상과 간격처럼 반복 사용이 많은 값을 변수화한 뒤, 라이트·다크 모드나 모바일·데스크톱 모드를 구성하는 것이 좋다. 이후 효과, 투명도, 그리드, 컴포넌트 상태로 범위를 넓히면 디자인 시스템의 일관성과 반응형 설계 효율을 함께 높일 수 있다.

원문 읽기

Figma 디자인 시스템 디자인 토큰 반응형 디자인+2

figma2023년 11월 21일3분 읽기큐레이션 요약

개발 모드: 개발자를 위해 더

Figma는 개발자를 단순한 디자인 파일 소비자가 아니라 제품 개발의 핵심 사용자로 보고 Dev Mode를 구축했다. 초기에는 디자인을 코드로 자동 변환하는 codegen 중심 접근을 택했지만, 실제 조직의 다양한 기술 스택과 협업 방식에는 한계가 있음을 발견했다. 결국 Dev Mode는 코드 생성만이 아니라 디자인 탐색, 변경 비교, 개발 도구 연동 등 개발자에게 맞춘 작업 환경을 제공하는 방향으로 확장됐다. ## 디자인과 개발의 경계를 줄이려는 Figma의 목표 - Figma는 처음부터 디자이너만을 위한 도구가 아니라 제품 관리자, 개발자 등 여러 직군이 함께 문제를 해결하는 공간을 지향했다. - 2017년 프로토타이핑과 개발자 핸드오프 기능을 선보이며 디자인과 코드 사이의 협업 흐름을 개선하려 했다. - 개발자들은 디자인 작업 중인 파일을 직접 확인하고 여러 핸드오프 방식을 실험했지만, 기존 Figma는 개발자 업무에 최적화된 도구는 아니었다. - Dev Mode는 디자인을 검사하고, 변경 사항을 비교하며, VS Code에서 작업하는 기능 등을 제공하는 개발자용 환경으로 출시됐다. ## 개발자 관점을 확보한 Visly 인수 - Figma 사용자 중 개발자가 약 3분의 1을 차지했지만, 개발자의 작업 방식과 도구 선호도에 대한 실질적인 직관은 부족했다. - 2021년 Figma는 React UI 컴포넌트 개발 도구를 만들던 Visly를 인수했다. - Visly 팀은 개발자 도구에 대한 연구와 실제 개발 경험을 Figma에 가져왔고, Dev Mode 개발을 가속했다. - 인수의 핵심 효과는 개발자를 대상으로 조사하는 것에서 나아가, 개발자처럼 생각하고 제품을 설계할 수 있는 팀을 확보한 데 있었다. ## 개발자를 2차 사용자가 아닌 핵심 사용자로 설계 - 기존 개발자들은 디자인 협업 때문에 Figma에 들어오지만, Figma가 자신들을 위해 만들어졌다고 느끼기 어려웠다. - Dev Mode 팀은 개발자가 디자인 모드의 복잡한 상호작용을 배울 필요 없이, 자신의 작업 방식에 맞는 인터페이스를 사용해야 한다고 판단했다. - 개발자 중심 기능으로 다음과 같은 아이디어를 검토했다. - 컴포넌트 플레이그라운드 - 코드 스니펫 - GitHub, Storybook 등 개발 도구와의 플러그인 연동 - 개발자 전용 리소스 - 중요한 관점은 개발자가 디자인 도구 안에서 장시간 생활한다는 전제가 아니라, 기존 개발 환경과 연결되는 보조 작업 공간을 제공하는 것이었다. - 베타 사용자 피드백과 고객 요청을 지속적으로 수집해 기능 우선순위에 반영했다. ## codegen 중심 접근의 출발과 한계 - **Codegen**은 정해진 규칙이나 명세를 바탕으로 디자인에서 코드를 자동 생성하는 방식이다. - Dev Mode 초기에는 디자인을 코드로 변환하면 개발 속도가 크게 빨라질 것이라고 보고 codegen을 핵심 방향으로 삼았다. - 자동 변환이 잘 작동하는 경우 프로젝트 작업 시간을 수시간에서 수일까지 줄일 수 있었다. - 그러나 테스트 환경에서 codegen이 작동하는 것과 실제 조직의 개발 프로세스에서 유용하게 작동하는 것은 달랐다. - 기업 규모, 팀 구조, 기술 스택, 개발 워크플로가 서로 다르기 때문에 모든 조직에 동일한 코드 생성 규칙을 적용하기 어려웠다. - 따라서 Dev Mode의 가치는 완성된 코드를 일괄 생성하는 데만 있지 않고, 개발자가 디자인 의도를 이해하고 자신의 코드베이스와 방식에 맞게 구현하도록 돕는 데 있다는 방향 전환이 필요해졌다. ## 실용적인 시사점 디자인-개발 협업 도구는 자동 코드 생성만으로 문제를 해결하기 어렵다. 조직별 기술 환경과 개발자의 실제 작업 흐름을 고려해 디자인 검사, 변경 추적, 코드 정보 제공, 기존 개발 도구와의 연동을 함께 지원해야 하며, 개발자를 제품의 부차적 사용자가 아닌 핵심 사용자로 설계하는 것이 중요하다.

원문 읽기

Figma React github dev-mode+3

figma2023년 11월 15일3분 읽기큐레이션 요약

피그마 + 어도비

2022년 발표된 Figma의 Adobe 인수합병은 협업형 디지털 제품 개발 도구와 Adobe의 창작 도구가 결합해 소비자에게 더 큰 혜택을 줄 수 있다는 취지로 설명됐다. Figma는 자신이 그래픽·마케팅 디자인 도구가 아니라 앱과 웹사이트를 팀 단위로 설계·개발하는 플랫폼이며, 경쟁 시장도 매우 역동적이라고 강조했다. 다만 규제 당국의 승인을 받지 못해 2023년 12월 양사는 인수합병을 포기했다. ## Figma가 해결하는 문제 - Figma는 디지털 제품을 만드는 팀을 위한 웹 기반 디자인 도구다. - 주요 사용자는 디자이너뿐 아니라 개발자, 제품 관리자 등 제품 개발에 참여하는 모든 구성원이다. - 제품 개발 과정 전체를 지원한다. - **FigJam**: 아이디어 발상과 브레인스토밍 - **Figma**: UI 설계와 프로토타이핑 - **Dev Mode**: 디자인과 프로토타입을 개발자가 코드로 구현하도록 지원 - 규제 당국이 Figma의 사업과 시장 위치를 잘 이해하지 못했기 때문에, 회사는 이를 설명하는 데 수천 시간을 들였다고 밝혔다. ## 그래픽 디자인과 디지털 제품 개발의 차이 - 전통적인 그래픽 디자인은 광고, 포스터, 일러스트처럼 시각적 결과물을 만드는 데 초점을 둔다. - Figma의 고객은 상호작용하는 앱과 웹사이트를 구축한다. - 디지털 제품 개발에는 디자인뿐 아니라 개발, 기획, 프로토타이핑 등 다양한 역할과 도구가 필요하다. - 따라서 Figma는 단순한 이미지 제작 도구가 아니라 여러 직군이 함께 제품을 설계하는 협업 플랫폼으로 포지셔닝됐다. ## 경쟁 시장의 확대 - 제품 개발 도구 시장에는 여러 유형의 경쟁자가 존재한다. - 종합 디자인 도구: Sketch, Figma, Penpot - 특화 도구: Miro, Flinto, Anima, ProtoPie, Zeplin - 로우코드 플랫폼: Salesforce 등 - 앱과 웹사이트가 기업과 사용자에게 필수 요소가 되면서 관련 도구 시장도 크게 성장했다. - AI 발전으로 제품 개발 도구의 혁신 속도도 빨라지고 있다. - 새로운 스타트업과 서비스가 지속적으로 등장해 경쟁 구도가 빠르게 변하며, 규제 당국에 제시한 경쟁사 목록조차 몇 주 만에 outdated될 정도라고 설명한다. ## Adobe와 Figma의 차이 - Adobe는 과거 Figma와 경쟁하려고 Adobe XD를 운영했지만, 새로운 기능 개발을 중단하고 유지보수 모드로 전환했다. - Photoshop과 Illustrator는 사진 편집과 고급 일러스트레이션에 강점을 가진다. - 반면 Figma는 팀 협업, 웹·앱 UI 설계, 프로토타이핑과 개발 연계에 특화돼 있어 두 회사의 핵심 제품과 사용 목적이 다르다고 주장했다. ## 인수합병의 기대 효과 - Figma는 협업형 제품 디자인과 개발에 집중한다. - Adobe는 전 세계 수억 명이 사용하는 창작 도구와 기술을 보유하고 있다. - 양사의 강점이 상호보완적이므로 결합하면 다음과 같은 효과가 가능하다고 설명했다. - 디자인과 창작 도구 간 연결 강화 - 더 많은 사용자를 위한 제품 개발·창작 기능 제공 - AI와 Adobe의 기술을 활용한 새로운 디자인 경험 - 디지털 제품 제작과 시각적 창작 영역의 통합 - 그러나 이러한 기대는 규제 승인이라는 전제에 달려 있었고, 결국 15개월간의 심사 끝에 승인 가능성이 없다고 판단해 거래가 종료됐다. 실질적으로 이 글은 인수합병의 장점을 설명하는 Figma의 입장을 담은 FAQ이지만, 최종적으로는 거래가 무산됐다는 후속 결과까지 함께 고려해야 한다.

원문 읽기

Figma AI 프로토타이핑 프로덕트 디자인+4

figma2023년 11월 13일3분 읽기큐레이션 요약

Config 202

Figma는 커뮤니티 중심의 컨퍼런스인 Config 2024를 더 많은 참여와 원활한 경험을 제공하는 행사로 발전시키겠다고 밝혔다. 2024년 6월 26~27일 샌프란시스코에서 열리며, 디자인·AI·개발·디자인 시스템 등을 주제로 75명 이상의 연사가 참여한다. 참가자 피드백을 반영해 세션 예약제, 개발자 콘텐츠 확대, 교류 시간 확보, 다국어 지원 등을 도입한다. ## 커뮤니티 중심의 컨퍼런스 - Config는 단순한 제품 발표회가 아니라 다음을 위한 행사로 소개된다. - 커뮤니티 구성원 간의 교류 - 실무 중심의 학습과 아이디어 공유 - 제품을 만드는 사람들의 작업과 전문성에 대한 축하 - 2020년 첫 오프라인 행사에서 약 1,000명의 Figma 사용자를 모은 이후, Figma와 커뮤니티의 성장에 맞춰 행사의 규모와 범위를 확장해 왔다. - 팬데믹 이후 첫 대규모 오프라인 Config에서 얻은 경험을 2024년 행사 운영에 반영한다. ## 세션 예약제로 좌석 보장 - 참가자는 원하는 브레이크아웃 세션을 사전에 예약할 수 있다. - 예약한 세션에 제시간에 도착하면 좌석을 보장받는다. - 매우 얼리버드 티켓 구매자는 다른 참가자보다 24시간 먼저 세션을 예약할 수 있다. - 인기 세션의 긴 대기 줄과 좌석 부족 문제를 줄이려는 개선이다. ## 개발자를 위한 프로그램 확대 - 제품 제작에 참여하는 모든 직군을 지원하기 위해 개발자 대상 콘텐츠를 늘린다. - 구체적인 세부 프로그램은 추후 공개될 예정이지만, 기존 디자인 중심 구성에서 개발 관련 트랙을 강화하는 방향이다. - 디자인 시스템, 개발, AI 등 여러 분야를 아우르는 발표가 예정되어 있다. ## 교류와 현장 경험 개선 - 참가자들이 네트워킹하거나 휴식할 수 있도록 일정에 더 많은 여유 시간을 배치한다. - 행사 공간을 확장해 다음과 같은 현장 문제를 개선한다. - 대기 줄 단축 - 이동 및 좌석 공간 확대 - 참가자 동선 개선 - 전반적인 행사 운영의 원활함 향상 - 강연을 연속해서 듣는 데 그치지 않고 커뮤니티와 직접 교류할 수 있는 경험을 강화한다. ## 글로벌 참가자를 위한 다국어 지원 - 온라인 참가자에게 영어, 프랑스어, 독일어, 일본어, 한국어, 스페인어 자막을 제공한다. - 오프라인 참가자를 위해 동시통역과 번역을 지원한다. - 향후 더 많은 언어를 행사에 추가해 글로벌 커뮤니티의 접근성을 높일 계획이다. ## 리더십 트랙 확대 - 전년도 긍정적인 반응을 바탕으로 임원 및 리더 대상 프로그램인 Leadership Collective를 확대한다. - 새로운 임원 브리핑 센터를 마련한다. - 리더를 위한 콘텐츠와 네트워킹 기회를 늘린다. - 등록 과정에서 초대 전용 트랙에 지원할 수 있다. ## 참가 및 발표자 모집 - 얼리버드 티켓은 수량이 제한되어 있으며, 자격 요건을 충족하는 참가자를 위한 장학금도 제공한다. - 참가자 의견과 발표자 제안을 이메일이나 소셜미디어로 받고 있다. - 발표 또는 세션 진행을 원하는 사람은 2023년 12월 31일까지 발표자 모집에 지원할 수 있었다. - 행사는 2024년 6월 26~27일 샌프란시스코에서 개최될 예정이었다. Config 2024는 규모만 키우는 대신 좌석 예약, 개발자 콘텐츠, 다국어 지원, 네트워킹 시간처럼 참가자의 실제 불편을 해결하는 방향으로 설계된 행사다. 비슷한 컨퍼런스를 기획한다면 참가자 피드백을 운영 방식에 직접 반영하고, 학습·교류·접근성을 균형 있게 강화하는 것이 핵심이다.

원문 읽기

Figma AI 디자인 시스템 software-development+1

figma2023년 11월 12일3분 읽기큐레이션 요약

2023년 피그

지난 3년간 업무 방식이 크게 바뀌었지만, 디자이너의 전반적인 직무 만족도는 오히려 높아진 것으로 나타났다. Figma가 유럽·아시아태평양 지역 디자이너 470명을 조사한 결과, 원격·하이브리드 근무와 협업 방식의 변화가 생산성과 관계 개선에 기여했으며 디자인의 조직 내 가치와 고용 전망도 상승했다. 특히 개인 기여자와 경영진의 적극적인 디자인 참여가 긍정적인 인식과 연결됐다. ### 조사 목적과 범위 - Figma는 변화한 근무 환경이 디자이너에게 미친 영향을 파악하기 위해 ‘State of the Designer’ 보고서를 작성했다. - 유럽과 아시아태평양 지역의 디자이너 470명을 대상으로 최근 3년간의 변화를 조사했다. - 주요 조사 항목은 다음과 같다. - 원격·하이브리드 근무가 협업과 생산성에 미친 영향 - 업무 방식 변화에 따른 직무 만족도 - 긍정적인 비즈니스 성과와 연결되는 협업 행동 - 디자이너가 업무에서 행복과 성취감을 느끼는 요인 ### 디자이너의 직무 만족도는 상승 - 응답자의 **69%가 팬데믹 이전보다 현재 직무 만족도가 높아졌다**고 답했다. - 조사한 모든 직급 중에서는 **개인 기여자(IC)의 82%가 긍정적인 변화**를 경험했다고 답해 가장 높은 비율을 보였다. - 디자이너들은 자신이 일하는 장소와 방식을 더 많이 통제할 수 있다고 느꼈다. - 원격 근무 비중이 높아졌음에도 업무 흐름과 디지털 제품의 품질이 개선됐다고 인식했다. ### 원격 근무를 가능하게 한 협업 방식의 변화 - 디자이너들은 원격 환경에서 협업을 유지하기 위해 협업 습관 자체를 바꾸고 있다. - 팀 회의에서 단순히 진행 상황을 공유하는 대신, 여러 사람이 함께 디자인하고 문제를 해결하는 방식이 활용되고 있다. - 디자이너들은 이러한 공동 작업 방식이 원격 근무의 한계를 줄이고 업무 효율을 높였다고 평가했다. - 변화한 협업 방식은 디자이너들이 원격 근무를 효과적으로 정착시키는 데 중요한 역할을 했다. ### 디자인의 조직 내 가치와 고용 전망 상승 - 디자인 직업에 대해 긍정적으로 느끼는 디자이너가 부정적으로 느끼는 디자이너보다 **약 5배 많았다**. - 기업과 리더들이 디자인을 단순한 실행 부서가 아니라 비즈니스 전략과 문제 해결을 위한 사고방식으로 보기 시작한 점이 영향을 미쳤다. - 응답자의 **69%는 자신의 고용 선택지가 ‘개선됐다’ 또는 ‘크게 개선됐다’**고 평가했다. - 유명 기업의 CEO들이 디자인의 전략적 가치를 강조하는 사례가 늘면서 디자이너의 역할에 대한 자신감도 커졌다. ### 경영진의 디자인 참여가 주는 효과 - 디자이너들은 경영진과 리더가 디자인 업무에 직접 참여할 때 자신의 역할이 더 중요하게 인정받는다고 느꼈다. - 긍정적인 사례로 다음과 같은 행동이 언급된다. - 경영진이 디자인 파일에 직접 참여 - 디자인 결과물에 구체적인 피드백 제공 - 제품 개발 과정을 직접 경험 - 이러한 참여는 디자인을 조직의 핵심 의사결정 과정과 연결하고, 디자이너의 직무 만족도와 소속감을 높이는 신호로 작용한다. 조직은 원격 근무를 단순한 장소의 변화로 보지 말고, 함께 디자인하고 피드백하는 협업 구조까지 재설계해야 한다. 또한 경영진이 디자인 과정에 직접 참여하고 디자인을 비즈니스 전략의 일부로 인정할수록 디자이너의 만족도와 조직 내 영향력을 함께 높일 수 있다.

원문 읽기

Figma 사용자 경험 collaborative-design design-thinking+2

figma2023년 11월 8일3분 읽기큐레이션 요약

Little Big Updates: 위대한 도약

Figma는 화려한 신기능뿐 아니라 사용자가 매일 반복하는 작은 불편을 줄이는 품질 개선이 제품에 더 큰 영향을 줄 수 있다고 주장한다. 특히 하루 수백 번 사용하는 동작을 한 번 덜 클릭하게 하거나 버그를 해결하는 일은 발표 무대에 오를 만한 기능보다 실제 업무 흐름을 크게 바꿀 수 있다. 이를 체계적으로 실천하기 위해 Figma는 매년 ‘Little Big Updates’라는 개선 활동을 진행한다. ## 사용자의 반복 작업에 집중하는 이유 - 디자이너들은 일주일에 40시간 이상 Figma를 사용하며, 도구를 익히는 과정 자체가 전문성을 쌓는 일과 비슷하다. - 사용자가 제품에 많은 시간과 노력을 투자하는 만큼 Figma는 지속적으로 도구를 개선할 책임이 있다고 본다. - 사용자가 자주 반복하는 작은 행동을 개선하면, 사용 빈도가 낮은 대형 기능보다 더 큰 누적 효과를 낼 수 있다. - 작은 변화는 사용자가 처음부터 요구하지 않았더라도 실제 사용 경험을 크게 향상시킬 수 있다. ## ‘Little Big Updates’의 시작 - Figma는 초기부터 디자이너들의 의견을 듣고 가능한 한 자주 업데이트를 출시했다. - 평소에는 매주 한 번 업데이트했지만, 네 가지 업데이트를 월요일부터 목요일까지 하루에 하나씩 공개한 일이 계기가 됐다. - 사용자들은 매일 새로운 선물을 받는 것처럼 느꼈고, 이 방식이 ‘Little Big Updates’라는 이름으로 발전했다. - 각각의 작은 개선에 주목할 기회를 제공하면 사용자가 그 변화의 가치를 더 잘 인식할 수 있다. ## 작은 개선이 만드는 큰 영향 - 기능 추가는 제품에 새로운 능력을 부여하는 일이지만, 품질 개선은 기존 기능을 더 빠르고 편하게 만드는 일이다. - “한 번 덜 클릭하게 만들었다”와 같은 변화는 홍보하기 어렵지만, 사용자가 반복해서 경험하기 때문에 영향력이 크다. - Figma의 사례: - 과거에는 붙여넣기 결과가 화면의 임의 위치에 나타나 불편했지만, 이를 개선해 반복적인 좌절을 없앴다. - 프레임을 전환할 때 텍스트를 선택하려고 여러 번 더블클릭해야 하는 문제를 줄였다. - 붙여넣기처럼 하루에도 수백 번 사용하는 동작의 개선은 화려한 신기능보다 사용자의 작업 흐름에 더 큰 효과를 줄 수 있다. ## 대형 기능과 작은 기능의 우선순위 결정 - AI for FigJam 같은 대형 기능은 다른 개선 사항과 어떻게 결합되는지, 제품 전체 전략에 어떻게 들어맞는지를 신중하게 검토해야 한다. - 대형 기능은 자동차에 큰 여행 가방을 먼저 싣는 것처럼 선행 조건과 전체적인 배치가 중요하다. - 반대로 작은 기능은 지나치게 중앙집중적으로 우선순위를 정할 필요가 없다. - 각 팀은 자신이 담당하는 기능과 사용자의 불편을 가장 잘 이해하므로, 품질 개선의 우선순위를 팀에 분산하는 것이 효과적이다. - 조직 전체가 품질의 중요성을 공유하되, 구체적으로 무엇을 개선할지는 현장 팀이 결정하도록 해야 한다. ## 실용적인 적용 방향 - 기능의 신규성보다 사용 빈도와 반복되는 불편의 크기를 기준으로 개선 대상을 찾는다. - 오류, 불필요한 클릭, 어색한 선택 방식처럼 작아 보이는 문제를 사용자 피드백과 실제 사용 사례로 평가한다. - 작은 개선도 별도로 공개하고 기록해 팀과 사용자가 그 가치를 인식하도록 한다. - 대형 기능은 전략적으로 통합하고, 세부적인 사용성 개선은 각 팀이 빠르게 실행하도록 권한을 위임하는 것이 좋다.

원문 읽기

Figma AI figjam 프로덕트 디자인+2

figma2023년 11월 7일3분 읽기큐레이션 요약

주목하고 좋아하게

피그마 Creator Fund는 커뮤니티를 위해 무료 위젯·플러그인·템플릿 등을 만드는 창작자를 지원하며, 13명에게 약 30만 달러를 지원했다. 이 글은 그중 실용적이고 어려운 문제를 해결한 프로젝트들을 소개하고, 창작자가 명확한 비전과 시각 자료를 바탕으로 자신이 관심 있는 아이디어를 발전시키라고 권한다. 제공된 본문에는 세 프로젝트 중 **Figma to Code** 사례가 중심적으로 포함되어 있다. ## Creator Fund의 목적과 성과 - Figma Community에서 누구나 사용할 수 있는 무료 리소스 제작을 지원한다. - 2023년 3월 시작 이후: - 수백 건의 지원서를 접수했다. - 9개국 13명의 창작자에게 약 30만 달러를 지원했다. - 디자인 시스템 튜토리얼, Figma 개발자 플랫폼 학습 플러그인 등 다양한 결과물이 나왔다. - Figma는 단순히 흥미로운 프로젝트보다 다음과 같은 프로젝트를 선호한다. - 해결하기 어려운 문제를 다루는 프로젝트 - 사용자의 시간을 절약하는 실용적인 도구 - 커뮤니티 전체가 무료로 사용할 수 있는 리소스 ## Creator Fund 지원서 작성 시 고려할 점 - 만들고 싶은 것이 무엇인지 명확한 비전을 제시해야 한다. - 몇 문장으로 급하게 작성하기보다 아이디어와 목표를 충분히 구체화해야 한다. - 추가 설명을 요청받을 수 있으므로 시각 자료를 준비하는 것이 좋다. - 심사위원이 원하는 것을 추측하기보다 자신이 실제로 관심 있는 문제를 선택해야 한다. - 지원 프로그램은 단순한 자금 제공을 넘어, 창작자가 프로젝트를 완성하도록 돕는 역할을 한다. ## Figma to Code: 디자인을 코드로 변환 - 브라질 쿠리치바의 Bernardo Ferrari가 만든 프로토타이핑 플러그인이다. - Figma 레이아웃을 다음 형식의 코드로 변환한다. - HTML - Tailwind - Flutter - SwiftUI - 디자인 시안을 실제 프론트엔드 코드로 빠르게 옮길 수 있어 프로토타이핑과 초기 개발 과정을 단축한다. - 디자인을 기반으로 제품을 만들고 사업화하려는 창작자에게 특히 유용하다. ## 코로나19 프로젝트에서 시작된 플러그인 - Bernardo는 코로나19 확산 정보를 제공하는 브라질 지역 웹사이트의 유지보수를 맡으며 플러그인을 구상했다. - 웹 개발 경험이 2015년 이후 거의 없었기 때문에 Figma에서 디자인한 화면을 직접 코드로 재현하는 방식으로 작업했다. - 기존 디자인-코드 변환 플러그인에는 다음과 같은 한계가 있었다. - 코드 생성 속도가 느림 - 여러 단계를 거쳐야 함 - 전체 기능을 사용하려면 유료 결제가 필요함 - Figma API 지원 범위가 좁고 오토 레이아웃 같은 기능이 빠짐 - 하나의 언어나 프레임워크만 지원함 - 반응형 디자인과 접근성을 충분히 고려하지 않음 - 이를 해결하기 위해 약 두 달 동안 플러그인을 개발했고, 2020년 7월 출시했다. ## Creator Fund를 통한 기능 개선 - 출시 후 몇 년 동안 Figma와 웹 프레임워크가 크게 바뀌었지만, 플러그인은 이를 따라가지 못했다. - 초기 버전은 다음과 같은 제한이 있었다. - 패딩을 수직·수평 방향으로만 설정 가능 - 오토 레이아웃에서 `min`과 `fixed` 정도만 지원 - Creator Fund 지원을 계기로 플러그인을 유료화하지 않고 대대적으로 개선할 기회를 얻었다. - Figma의 새로운 Dev Mode를 지원하는 작업도 진행했으며, 2023년 Config에서 업데이트를 공개했다. - 지원금은 기존 프로젝트를 유지하는 데 그치지 않고, 최신 Figma 기능과 개발 환경에 맞춰 제품을 발전시키는 촉진제가 되었다. ## 실용적인 시사점 - 디자인-코드 변환 도구는 단순한 코드 생성뿐 아니라 반응형 레이아웃, 접근성, 최신 Figma API 지원까지 고려해야 한다. - 무료 도구를 지속적으로 유지하려면 개발 비용과 기능 업데이트를 지원하는 구조가 필요하다. - Creator Fund에 지원하려는 창작자는 명확한 문제 정의, 구체적인 해결 방법, 실제 사용자가 얻는 이점을 함께 제시하는 것이 좋다. - 제공된 글 본문은 Figma to Code 사례 중간에서 끝나므로, 나머지 두 프로젝트의 구체적인 내용은 포함되어 있지 않다.

원문 읽기

Figma design-to-code HTML figma-plugins+3

figma2023년 11월 6일3분 읽기큐레이션 요약

FigJam에 AI 도입하기 | Figma

FigJam은 생성형 AI를 활용해 빈 캔버스에서 시작하는 부담을 줄이고, 회의·브레인스토밍·계획 수립을 빠르게 시각화하도록 돕는다. 사용자는 자연어 프롬프트만으로 템플릿과 다이어그램을 만들고, 회의 내용을 요약하거나 스티키 노트를 주제별로 정리할 수 있다. Figma는 이를 통해 디자인 전문 지식이 없는 사람도 시각적 협업에 쉽게 참여하게 하면서, 반복적인 정리 작업은 자동화해 더 중요한 논의에 집중하도록 하는 것을 목표로 한다. ## FigJam에 도입된 AI 기능 - 간단한 프롬프트로 주간 팀 미팅, 브레인스토밍, 회고 등 맞춤형 템플릿을 생성한다. - 시각적 타임라인과 조직도처럼 계획 수립에 필요한 다이어그램을 자동으로 만든다. - 브레인스토밍 결과나 회의 보드의 내용을 요약한다. - 여러 스티키 노트를 주제별로 자동 분류하고 그룹화한다. - 실제 사용 사례와 협업 모범 사례를 바탕으로 구성된 프롬프트를 제공하며, 생성 결과는 사용자가 수정할 수 있다. ## ‘빈 캔버스 문제’ 해결 - 새로운 FigJam 파일을 열었을 때 무엇부터 시작해야 할지 몰라 멈추는 문제를 줄인다. - “네 명이 참석하는 회의가 필요하다”처럼 의도를 자연어로 표현하면 초기 회의 템플릿을 생성한다. - 사용자가 도구의 기능이나 디자인 소프트웨어 사용법을 먼저 배울 필요 없이 작업에 바로 착수할 수 있다. - AI가 초안을 제공하므로 사용자는 빈 화면을 구성하는 대신 내용과 논의에 집중할 수 있다. ## 접근성 향상과 가능성 확장 - Figma가 말하는 “진입 장벽을 낮추고 상한선을 높인다”는 방향을 FigJam AI에 적용했다. - 디자인 도구에 익숙하지 않은 사람도 대화형 입력 방식으로 시각적 협업에 참여할 수 있다. - 시각화는 개념을 명확히 하고 팀의 정렬과 의사소통을 돕지만, 기존에는 디자인 전문성이 진입 장벽이 될 수 있었다. - AI는 이러한 장벽을 낮추는 동시에 복잡한 아이디어를 정리·시각화하는 새로운 작업 방식도 제공한다. ## 반복적인 협업 작업의 자동화 - 회의 내용을 요약하는 작업을 자동화한다. - 흩어진 아이디어를 의미 있는 범주로 통합하고 분류한다. - 수작업으로 최대 한 시간가량 걸릴 수 있는 정리·종합 작업을 컴퓨터에 맡길 수 있다. - 참여자는 기록 정리보다 대화, 의사결정, 문제 해결 같은 더 중요한 활동에 시간을 사용할 수 있다. ## 실제 문제를 중심으로 한 AI 설계 - Figma는 AI를 단순한 신기술이나 장식적 기능이 아니라 실제 문제를 해결하는 수단으로 접근한다. - FigJam 제품팀은 자신들이 FigJam을 사용하는 경험을 바탕으로 사용자 불편을 파악했다. - 생성형 AI를 동적인 시각 협업 공간에 결합해, 결과물을 일방적으로 생성하기보다 사용자의 작업 흐름을 보조하도록 설계했다. - 회의와 브레인스토밍처럼 일상적인 협업 상황에 맞춘 기능을 제공해 AI의 활용성을 높였다. 실무에서는 회의 시작 전에 AI로 템플릿을 만들고, 회의 후에는 요약과 스티키 노트 분류를 활용하면 준비·정리 시간을 줄일 수 있다. 다만 AI가 만든 구조와 요약은 초안으로 보고, 팀의 실제 맥락과 의도에 맞게 검토·수정하는 것이 바람직하다.

원문 읽기

AI 생성형 AI figjam 프롬프트 엔지니어링+2

datadog2023년 10월 27일3분 읽기큐레이션 요약

엔지니어링 스포트

Datadog은 Gartner의 ‘Observability Platforms’ 매직 쿼드런트 2026에서 리더(Leader)로 선정되었다고 발표합니다. 글은 Datadog을 인프라부터 애플리케이션, 로그, 보안, 디지털 경험, 소프트웨어 제공, 서비스 관리, AI까지 아우르는 통합 관측성 플랫폼으로 소개합니다. 다만 제공된 내용에는 Gartner 평가의 세부 기준이나 Datadog의 구체적인 강·약점 분석보다 제품 목록과 링크가 중심으로 포함되어 있습니다. ### Gartner 매직 쿼드런트 리더 선정 - Datadog은 Gartner의 **Observability Platforms** 부문에서 리더로 평가되었다고 밝힙니다. - 이번 발표의 핵심 메시지는 Datadog이 다양한 관측성 데이터를 하나의 플랫폼에서 수집·분석하고 운영 대응까지 지원한다는 점입니다. - 본문에 제공된 자료만으로는 Gartner가 어떤 실행 능력이나 비전 항목을 근거로 평가했는지는 확인되지 않습니다. ### 인프라 및 클라우드 관측성 - 인프라 모니터링과 메트릭 수집을 제공합니다. - 컨테이너와 Kubernetes 환경을 모니터링하고, Kubernetes 오토스케일링을 지원합니다. - 네트워크, 서버리스 애플리케이션, 스토리지, GPU를 관측할 수 있습니다. - Cloud Cost Management와 Cloudcraft를 통해 클라우드 비용 및 인프라 구성을 관리합니다. ### 애플리케이션 성능 모니터링 - APM으로 애플리케이션 성능과 서비스 간 동작을 추적합니다. - Universal Service Monitoring을 통해 서비스 상태를 파악합니다. - Continuous Profiler로 코드 실행 중의 CPU·메모리 사용 패턴을 분석할 수 있습니다. - Dynamic Instrumentation을 사용해 코드를 재배포하지 않고 실행 중인 애플리케이션을 조사할 수 있습니다. - AI 에이전트의 동작을 관찰하는 Agent Observability도 포함됩니다. ### 로그와 데이터 관측성 - Log Management를 통해 로그를 수집·검색·분석합니다. - Observability Pipelines로 로그의 라우팅, 필터링, 변환 및 보관 정책을 제어합니다. - Sensitive Data Scanner는 로그 등에서 민감정보를 탐지합니다. - Database Monitoring, Data Streams Monitoring을 통해 데이터베이스와 데이터 파이프라인을 모니터링합니다. - 데이터 품질과 작업 실행 상태를 확인하는 Quality Monitoring, Jobs Monitoring도 제공합니다. ### 보안 플랫폼 통합 - 코드 보안, SAST, IAST, 소프트웨어 구성 분석(SCA), IaC 보안을 제공합니다. - 클라우드 보안 상태, 권한, 취약점 및 컴플라이언스를 관리합니다. - Cloud SIEM과 Workload Protection으로 런타임 보안 이벤트와 워크로드를 분석합니다. - App and API Protection, Secret Scanning, Sensitive Data Scanner 등 애플리케이션 및 데이터 보호 기능을 포함합니다. ### 디지털 경험 모니터링 - Browser와 Mobile RUM을 통해 실제 사용자 경험을 측정합니다. - Product Analytics와 Session Replay로 사용자 행동과 세션 흐름을 분석합니다. - Synthetic Monitoring으로 실제 사용자가 없어도 웹·API·애플리케이션의 가용성을 점검합니다. - Error Tracking, Mobile App Testing, Feature Experiments 등을 통해 오류와 모바일 앱 품질을 관리합니다. ### 소프트웨어 제공과 서비스 운영 - CI Visibility와 Test Optimization으로 빌드·테스트 파이프라인의 성능과 실패 원인을 분석합니다. - Continuous Testing, Code Coverage, IDE Plugins를 통해 개발 및 테스트 과정의 가시성을 높입니다. - Internal Developer Portal과 Software Catalog로 서비스와 개발 자산을 관리합니다. - SLO, Event Management, Incident Response, Case Management를 통해 장애 대응과 서비스 수준을 관리합니다. - Workflow Automation과 App Builder로 반복적인 운영 작업을 자동화할 수 있습니다. ### AI 기반 운영 기능 - Bits AI Agents, Bits Chat, Bits Investigation 등을 활용해 조사와 운영 분석을 지원합니다. - Bits Security Analyst는 보안 분석 업무를 보조합니다. - MCP Server, Agent Builder, Agent Directory 등을 통해 AI 에이전트와 외부 도구의 연계를 지원합니다. - Watchdog은 이상 징후 탐지와 문제 분석을 자동화하는 기능으로 제시됩니다. - GPU Monitoring은 AI 및 머신러닝 워크로드의 GPU 사용 상태를 관찰하는 데 활용됩니다. 실무적으로는 Datadog을 도입할 때 단순히 Gartner의 리더 선정만 볼 것이 아니라, 필요한 영역이 인프라·APM·로그·보안·RUM 중 어디인지와 데이터 수집량에 따른 비용, 기존 도구와의 통합성, 보존 정책을 함께 검토하는 것이 좋습니다.

원문 읽기

쿠버네티스 datadog 옵저버빌리티 애플리케이션 성능 모니터링+3

datadog2023년 10월 27일원문

엔지니어링 스포트라이트: 제로미 캐리어 (새 탭에서 열림)

데이터독(Datadog)의 제품 엔지니어링 SVP인 제로미 캐리어(Jeromy Carriere)는 엔지니어링 조직의 성패가 단순한 속도가 아닌, 명확한 방향성을 가진 '지속 가능한 속도(Sustained Velocity)'에 달려 있다고 강조합니다. 그는 구글과 페이스북에서의 경험을 바탕으로, 엔지니어링 리더십은 팀의 자율성을 보장하는 것과 결과에 대한 책임을 묻는 것 사이의 균형을 잡는 과정임을 설명합니다. 결론적으로 그는 관측성(Observability)의 미래가 단순한 현상 파악을 넘어 엔지니어가 무엇을 해야 하는지 알려주는 처방적 단계로 진화해야 한다고 주장합니다. **엔지니어링 리더의 다각적 실행 사이클** * **계획 및 실행의 조화:** 분기별 계획 사이클을 통해 팀 간의 협업 기회를 테마별로 연결하고, 실행 사이클에서는 리소스 지원이나 의사결정 정체를 해소하여 팀의 병목 현상을 제거합니다. * **엔지니어링 메타 관리:** 엔지니어링 조직이 어떻게 작동하는지에 대한 프로세스 정의, 채용, 성과 관리 등 조직의 운영 효율성을 높이는 '메타 수준'의 업무에 집중합니다. * **기술적 현장감 유지:** 고위 임원임에도 불구하고 설계 문서와 코드를 읽고, 인시던트 및 사후 분석(Post-mortems)을 관찰하며 전체 스택에서 조직이 어떻게 실행되고 있는지 파악합니다. **데이터독을 선택한 이유: 지속 가능한 속도** * **성장 궤적:** 구글 클라우드 플랫폼 초기 시절 클라우드 모니터링 제품을 구축하며 관측성 분야의 중요성을 체감했고, 이후 페이스북을 거치며 개발자 생산성에 미치는 영향력에 매료되었습니다. * **전략적 속도:** 단순히 빨리 움직이는 것이 아니라, 의도된 전략과 방향성을 가지고 10년 넘게 혁신을 유지하는 데이터독의 '지속 가능한 속도'를 유지하고 확장하는 데 주력하고 있습니다. **실수를 통한 학습과 리더십 철학** * **새로운 실수의 장려:** 과거의 실수를 반복하지 않되, 새로운 실수를 통해 배우고 성장하는 문화를 지향합니다. * **자율성과 책임의 균형:** 초기 커리어의 지나치게 지시적인 태도가 팀의 창의성을 해친다는 것을 깨닫고, 현재는 최대한의 자율성을 부여하되 약속한 결과에 대해서는 엄격히 책임을 묻는 균형점을 추구합니다. * **만족 중심의 커리어 개발:** 5년 단위의 경력 계획보다는 개인이 어떤 업무에서 만족감을 느끼는지 파악하는 것이 중요하며, 리더는 팀원이 이를 발견할 수 있도록 시야를 넓혀주는 역할을 해야 합니다. **관측성 기술의 미래와 실전 경험의 가치** * **처방적 관측성으로의 전환:** 관측성은 "무슨 일이 일어나고 있는가?"라는 질문에서 "내가 무엇을 해야 하며, 어떻게 고쳐야 하는가?"라는 처방적인 단계로 진화하고 있습니다. * **실무 중심의 인재 양성:** 워털루 대학교의 코옵(Co-op) 프로그램이나 데이터독의 인턴십처럼, 학생들이 실제 업무 환경에서 책임감을 가지고 기여할 때 진정한 전문 소프트웨어 개발자로 성장할 수 있습니다. 성공적인 엔지니어링 조직을 구축하기 위해서는 기술적 탁월함만큼이나 조직 운영의 프로세스를 정교하게 다듬는 노력이 필요합니다. 특히 리더는 팀이 스스로 방향을 찾을 수 있도록 자율성을 부여하는 동시에, '지속 가능한 속도'를 유지할 수 있는 전략적 가이드를 끊임없이 제시해야 합니다.

데이터베이스 설계 datadog 옵저버빌리티 software-development+4

figma2023년 10월 25일원문

디자인과 창의성의 미래 (새 탭에서 열림)

피그마와 어도비는 15개월에 걸친 규제 검토 끝에, 당국의 승인을 얻을 수 있는 현실적인 경로가 없다는 판단하에 인수 합병 계약을 공식적으로 종료하기로 합의했습니다. 이번 결정은 양사의 기술적 결합이 가져올 혁신적인 디자인 생태계에 대한 비전을 뒤로한 채 각자의 길을 걷게 됨을 의미합니다. 비록 합병은 무산되었으나, 피그마는 실시간 협업과 생성형 AI, 그리고 도구 간의 심리스한 연결성이 주도할 미래 디자인 워크플로우의 청사진을 제시하며 창의성의 미래를 향한 의지를 밝혔습니다. **합병 중단 배경과 규제 환경** * 2023년 12월 18일, 피그마와 어도비는 시장 독점 및 경쟁 저해를 우려하는 규제 당국의 높은 벽을 넘지 못하고 인수 포기를 선언함. * 양사는 장기간의 검토 과정 끝에 더 이상 승인 가능성이 없다는 점에 상호 동의하며 15개월간의 인수 절차를 마무리함. **멀티플레이어 협업 기술의 확장** * 피그마의 강점인 실시간 멀티플레이어 환경을 어도비의 전문 저작 도구(예: 3D 디자인)에 이식하여 협업 효율 극대화 추진. * 한 디자이너가 3D 모델을 구축하는 동안 다른 디자이너가 실시간으로 조명이나 텍스처를 조정하는 동시 작업 환경 구상. * 전문 툴 학습 시 숙련자가 초보자와 같은 파일 내에서 실시간 가이드를 제공하는 교육적 효과 기대. **심리스한 에셋 연동과 디자인 시스템 통합** * Adobe Substance 3D에서 제작한 에셋을 피그마 목업에 배치하고, 원본 수정 시 피그마 내 에셋도 자동으로 최신화되는 실시간 동기화 기술. * 피그마의 제품 디자인과 어도비 에셋 간의 디자인 시스템(컬러 팔레트, 폰트 등) 공유 및 Adobe Fonts의 피그마 내 직접 활용. * 완성된 피그마 프로토타입을 마케팅 영상에 직접 삽입하여, 제품 디자인 변경이 영상 소스에 즉각 반영되는 워크플로우 구축. **생성형 AI '파이어플라이'와의 기술적 융합** * 어도비의 생성형 AI 모델인 '파이어플라이(Firefly)'를 피그마 워크플로우에 통합하여 UI 컨셉에 맞는 배경을 즉석에서 생성. * 반응형 디자인 대응을 위해 이미지를 자연스럽게 확장하는 '제너레이티브 필(Generative Fill)' 기능의 피그마 내 구현. * 브레인스토밍 단계의 스티키 노트를 지능적으로 분석하여 순식간에 시각화된 스토리보드로 전환하는 자동화 기능 구상. 기업 간의 물리적 합병은 멈추었으나, 피그마가 제시한 '도구 간의 경계 없는 연결'과 '실시간 협업의 확장'이라는 방향성은 향후 디자인 도구 시장의 중요한 표준이 될 것입니다. 디자이너들은 개별 툴의 숙련도를 넘어, AI와 실시간 협업 기능을 활용해 아이디어에서 프로토타입까지의 도달 시간을 단축하는 효율적인 워크플로우 구축에 주목해야 합니다.

Figma 디자인 시스템 프로토타이핑 생성형 AI+4

figma2023년 10월 24일2분 읽기큐레이션 요약

Figma, 유럽 자동차 산업

Figma는 유럽 자동차 업계의 정보보안 표준인 TISAX 평가에 참여했다고 발표했습니다. 이를 통해 자동차 업계 고객이 Figma에서 관리하는 디자인 데이터가 업계 기준에 따라 안전하게 보호되고 있음을 확인할 수 있다고 강조합니다. 이번 참여는 EU Cloud Code of Conduct 인증과 EU 내 파일 호스팅 옵션 등 Figma의 유럽 시장 보안·규제 대응 전략의 일부입니다. ## TISAX와 유럽 자동차 산업의 정보보안 - TISAX(Trusted Information Security Assessment Exchange)는 독일자동차산업협회(VDA)를 대신해 ENX Association이 운영하는 정보보안 평가 체계입니다. - 특히 독일을 포함한 유럽 자동차 산업에서 데이터 보안과 보호 수준을 판단하는 기준으로 활용됩니다. - 자동차 제품 디자이너와 기업 고객은 TISAX 참여를 통해 Figma가 디자인 작업물을 업계 보안 요구사항에 맞게 관리한다는 점을 확인할 수 있습니다. - TISAX는 일반 대중을 위한 인증 결과 공개 체계가 아니며, 관련 결과는 ENX 포털을 통해 확인하도록 안내됩니다. ## Figma의 TISAX 평가 참여 정보 - **회사명:** Figma, Inc. - **Scope ID:** S3XH77 - **Assessment ID:** AV01AK-2 - 공식 참여 결과는 ENX의 TISAX 평가 결과 포털에서 조회할 수 있습니다. - Figma는 이번 참여를 통해 단순한 디자인 협업 도구를 넘어 기업의 보안·규제 준수 요구까지 지원하겠다는 입장을 밝혔습니다. ## 유럽 고객을 위한 추가 보안 및 데이터 거버넌스 - Figma는 TISAX 참여 외에도 EU Cloud Code of Conduct 인증을 획득했습니다. - 해당 인증은 클라우드 서비스의 데이터 보호와 규정 준수 체계를 검토하는 유럽 차원의 프로그램입니다. - Figma와 FigJam 파일을 **유럽연합 내에서 호스팅할 수 있는 옵션**도 제공하고 있습니다. - 이러한 조치는 유럽 고객의 데이터 지역성, 보안, 규제 준수 요구에 대응하기 위한 것입니다. ## 기업 고객을 겨냥한 보안 신뢰성 강화 - Figma는 기술, 금융, 패션, 자동차 등 다양한 산업의 디자인·엔지니어링·제품 팀을 대상으로 서비스를 제공합니다. - 산업별로 민감한 제품 정보와 설계 데이터가 오가는 만큼, 협업 기능뿐 아니라 저장·관리 과정의 보안도 중요한 경쟁 요소입니다. - TISAX 참여는 특히 자동차 제조사와 협력사처럼 엄격한 공급망 보안 기준을 적용받는 조직의 도입 검토에 긍정적으로 작용할 수 있습니다. 자동차 업계에서 Figma를 도입하려는 기업은 ENX 포털에서 제공되는 TISAX 참여 정보를 확인하고, 실제 계약 전에는 필요한 평가 범위와 데이터 호스팅 지역이 조직의 보안 정책에 부합하는지 별도로 검토하는 것이 좋습니다.

원문 읽기

Figma information-security compliance cloud-hosting+1

figma2023년 10월 24일3분 읽기큐레이션 요약

Figma의 데이터 사이언스 및

Figma의 데이터 과학팀과 사용자 조사팀은 알림 문제를 정량 데이터와 정성적 사용자 의견으로 함께 분석했다. 그 결과 알림 클릭률보다 앞선 단계인 “알림을 아예 받지 못하는 문제”가 가장 큰 개선 기회임을 발견했다. Figma는 이를 해결하기 위해 새로운 알림 유형을 추가하고, 누가 언제 알림을 받아야 하는지 재검토하는 실험을 시작했다. ## 정량 데이터와 정성 조사의 결합 - 데이터 과학은 대규모 사용자 행동을 통해 **무슨 일이 일어나는지(What)** 보여준다. - 사용자 조사는 사용자가 왜 그렇게 행동하는지 **이유(Why)** 를 파악하는 데 도움을 준다. - 수치만으로는 사용자의 동기와 맥락을 알기 어렵고, 인터뷰만으로는 전체 사용자에게 나타나는 패턴을 확인하기 어렵다. - 두 방법을 함께 사용하면 각 분석의 한계를 보완해 더 완전한 제품 이해가 가능하다. - 두 팀은 이를 날실과 씨실을 엮어 천을 만드는 과정에 비유했다. ## Figma 알림 퍼널과 문제 정의 - Figma 알림은 이메일, Slack, 모바일, 파일 브라우저·시스템 트레이·데스크톱 알림 등 여러 경로로 전달된다. - 알림 유형에는 댓글, 댓글 답글, 댓글 반응, 파일·팀·프로젝트 초대, 편집 초대, 멘션 등이 있다. - 사용자가 알림과 상호작용하려면 다음 단계를 통과해야 한다. - 알림 대상이 될 수 있음 - 알림을 받음 - 알림을 확인함 - 알림과 상호작용함 - 활동 팀은 어느 단계에서 사용자가 가장 많이 이탈하는지, 어떤 단계에 투자해야 하는지 알지 못했다. - 분석 결과 가장 큰 문제는 많은 사용자가 알림을 열지 않는 것이 아니라 **알림 자체를 받지 못하고 있다는 점**이었다. ## 협업형 분석 프로세스 구축 - Caitlin Hudon과 Jennifer Sanders는 FigJam에서 팀 전체 브레인스토밍을 진행했다. - 팀은 알림을 받은 사용자, 열어본 사용자, 클릭한 사용자의 비율과 현재 상태를 공유했다. - 이후 다음과 같은 질문을 함께 정리했다. - 분기별로 어떤 지표를 개선할 것인가? - 새로운 알림 유형이 필요한가? - 현재 데이터만으로 알 수 없는 것은 무엇인가? - 질문을 데이터 과학으로 답할지, 사용자 조사로 답할지 각자의 전문 영역에 따라 나누었다. - 두 연구자는 각자 프로젝트를 진행하면서도 지속적으로 소통하고, 공통된 질문과 발견을 맞춰 갔다. - 이런 지속적인 동기화와 결과 종합에 충분히 투자하는 것이 단순히 두 연구 결과를 나열하는 것보다 중요했다. ## 행동 데이터가 보여준 것과 사용자 조사가 밝혀야 한 것 - 데이터 분석은 알림 퍼널의 각 단계에서 사용자가 얼마나 줄어드는지 파악하는 데 적합했다. - 특히 알림 수신 여부와 실제 상호작용 사이의 차이를 수치로 확인할 수 있었다. - 사용자 조사는 사용자가 알림을 받지 못하거나 활용하지 않는 상황의 맥락과 기대를 이해하는 데 사용됐다. - 사용자는 자신의 행동 이유를 항상 정확히 설명하지 못할 수 있으므로, 인터뷰 결과를 행동 데이터와 함께 검증해야 했다. - 정량 결과와 정성적 설명을 결합해 팀은 단순한 클릭률 개선이 아닌 알림 전달 구조 자체를 개선해야 한다고 판단했다. ## 발견을 제품 개선으로 연결 - 활동 팀은 알림을 통해 팀원 간 연결과 협업을 강화하는 것을 목표로 했다. - 가장 큰 개선 영역은 기존 알림의 클릭을 유도하는 것보다 다음 문제를 해결하는 데 있었다. - 적절한 사용자가 알림을 받지 못하는 문제 - 필요한 상황을 포괄하지 못하는 알림 유형 - 알림을 받을 시점과 대상이 적절하지 않은 문제 - 이후 팀은 여러 알림 실험을 시작했다. - 사용자의 주요 불편을 해결하기 위한 새로운 알림 유형도 출시됐다. ## 실용적인 결론 제품 문제를 분석할 때 퍼널의 마지막 행동만 보지 말고, 사용자가 그 단계에 도달하기 전 어디에서 이탈하는지 확인해야 한다. 대규모 행동 데이터로 문제의 범위를 파악한 뒤, 사용자 조사로 원인과 맥락을 보완하고, 두 결과를 공동으로 종합하는 방식이 효과적이다.

원문 읽기

figjam slack user-research 데이터 사이언스+2

figma2023년 10월 23일3분 읽기큐레이션 요약

서버 사이드 샌드박

VM은 게스트 운영체제마다 CPU·메모리·디스크를 제공해 강한 격리 경계를 만드는 샌드박싱 방식이다. 하지만 보안은 VM 자체만으로 완성되지 않으며, 하이퍼바이저의 취약점으로 인한 VM 탈출과 VM 권한을 악용한 데이터 유출을 함께 고려해야 한다. Figma는 취약점을 완전히 제거하기보다 서버 측 샌드박싱으로 침해 발생 시 피해 범위를 줄이는 접근을 취한다. ## 서버 측 샌드박싱의 목적 - 신뢰할 수 없는 작업이나 악성 작업을 별도의 실행 환경에 격리한다. - 목표는 모든 보안 취약점을 예방하는 것이 아니라, 취약점이 악용되어도 호스트와 다른 시스템으로 피해가 확산되지 않도록 하는 것이다. - 서버 측 샌드박싱의 대표적인 접근 방식으로 VM, 컨테이너, seccomp가 소개된다. - VM은 컨테이너나 seccomp보다 무겁지만, 별도의 게스트 운영체제를 제공해 더 강한 격리 모델을 구성할 수 있다. ## VM의 보안 모델 VM 보안은 크게 하이퍼바이저 경계와 VM 권한이라는 두 요소로 나뉜다. - **VM과 호스트의 분리** - 하이퍼바이저는 물리 서버의 자원을 관리하고 여러 VM을 동시에 실행한다. - 게스트 VM과 호스트 시스템, 그리고 서로 다른 게스트 VM 사이의 접근을 차단한다. - **VM 탈출** - 게스트 내부의 악성 프로그램이 하이퍼바이저 취약점을 이용해 호스트 시스템에 접근하는 공격이다. - VM 탈출이 성공하면 호스트 장악, 다른 VM과의 상호작용, 다른 게스트의 정보 획득 등이 가능해질 수 있다. - **하이퍼바이저의 공격 표면** - 하이퍼바이저는 운영체제와 하드웨어 작업을 폭넓게 중재하므로 코드와 기능이 복잡하다. - 따라서 VM 격리는 강력하지만, 하이퍼바이저 자체가 중요한 보안 경계이자 공격 대상이 된다. - 클라우드 IaaS 사업자 대부분이 테넌트 격리에 VM을 사용하므로, 베어메탈 인스턴스를 사용하지 않는다면 사실상 하이퍼바이저 보안에 의존하게 된다. ## VM 권한과 피해 범위 VM 탈출이 발생하지 않더라도 악성 작업은 VM에 부여된 권한을 이용해 피해를 일으킬 수 있다. - VM 내부 프로세스가 네트워크에 접근하면 민감한 데이터를 외부로 유출할 수 있다. - VM의 인증 정보로 다른 서비스나 시스템 API를 호출할 수도 있다. - 따라서 VM 내부에 작업을 넣는 것만으로는 충분하지 않다. - 네트워크 접근, 서비스 자격 증명, 파일 및 시스템 권한 등을 제한해 침해 시 **blast radius**를 줄여야 한다. - 하이퍼바이저를 직접 수정하기 어려운 환경에서는 VM의 기능과 권한을 세밀하게 구성하는 방어가 특히 중요하다. ## 엔지니어링 관점의 고려사항 - VM은 강한 격리를 제공하지만 컨테이너나 seccomp보다 실행 비용과 운영 복잡성이 크다. - 하이퍼바이저를 직접 개발하거나 공격 표면을 깊이 분석해야 하는 시스템은 구현 난도가 높다. - 보안 설계 시 “VM에서 탈출할 수 있는가?”뿐 아니라 “탈출하지 않고도 어떤 시스템에 접근할 수 있는가?”를 함께 검토해야 한다. - 격리 기술 선택은 보안 강도, 성능, 비용, 운영 편의성, 클라우드 인프라의 신뢰 모델 사이의 절충이다. VM을 사용할 때는 최신 하이퍼바이저 보안 패치와 격리 설정을 유지하는 동시에, 네트워크·자격 증명·서비스 권한을 최소화하는 다층 방어를 적용하는 것이 좋다. VM은 강력한 첫 번째 경계이지만, 권한 제한 없이는 완전한 보안 대책이 될 수 없다.

원문 읽기

클라우드 보안 virtual-machines seccomp server-side-sandboxing+3

figma2023년 10월 23일3분 읽기큐레이션 요약

서버 측 샌드박싱

서버 측 샌드박싱은 악성 입력을 처리하는 애플리케이션의 취약점이 전체 인프라로 확산되는 것을 막는 방어 계층이다. 이미지·데이터 처리 라이브러리처럼 메모리 안전성이 낮고 취약점이 반복적으로 발견되는 소프트웨어를 완전히 제거하거나 재작성하기는 현실적으로 어렵기 때문에, VM·컨테이너·seccomp 등을 이용해 실행 환경과 접근 가능한 자원을 제한해야 한다. 중요한 것은 특정 기술 하나를 선택하는 것이 아니라 보안성, 운영 복잡도, 성능, 격리 수준 사이의 트레이드오프를 workload 특성에 맞게 평가하는 것이다. ## 사용자 입력을 처리할 때 발생하는 위험 - 이미지 처리, 파싱, 압축, 썸네일 생성은 SaaS 애플리케이션에서 흔히 필요한 작업이다. - 이러한 기능은 C++ 같은 메모리 비안전 언어로 작성된 라이브러리에 의존하는 경우가 많다. - 해당 라이브러리는 원래 악의적인 입력을 처리하도록 설계되지 않았으며, 메모리 손상 취약점이 반복적으로 발견되어 왔다. - 대표적인 사례가 2016년 ImageMagick에서 발견된 **ImageTragick**이다. - 사용자가 제공한 이미지를 서버에서 처리하는 서비스가 원격 코드 실행 공격에 노출될 수 있었다. - 모든 버그와 취약점을 사전에 제거하는 것은 사실상 불가능하므로, 취약점이 발생하더라도 피해 범위를 제한하는 방어책이 필요하다. ## 서버 측 샌드박싱의 역할 - 샌드박싱은 애플리케이션이나 작업을 제한된 환경에서 실행하는 **workload isolation** 기법이다. - 공격자가 취약한 작업을 장악하더라도 다음과 같은 접근을 제한하는 것이 목표다. - 다른 작업의 사용자 데이터 - 운영 환경의 내부 서비스 - 파일 시스템과 네트워크 자원 - 추가 시스템으로의 lateral movement - Figma는 C++로 작성된 서버 측 렌더링 시스템인 RenderServer와 사용자 생성 그래픽 데이터를 처리하는 서드파티 라이브러리를 사용한다. - 이러한 작업을 인프라 내부에서 직접 실행하면 단 하나의 심각한 버그가 다른 사용자 데이터나 운영 시스템 침해로 이어질 수 있다. - 모든 unsafe 코드를 메모리 안전 언어로 다시 작성하고 정적 분석으로 정확성을 증명하는 방법도 있지만, 비용과 시간이 크며 완벽한 보안을 보장하지도 않는다. - 따라서 취약점 예방과 함께, 취약점이 악용되었을 때 영향 범위를 줄이는 격리 전략을 병행한다. ## VM, 컨테이너, seccomp - 글에서는 서버 측 샌드박싱의 대표적인 구현 방식으로 다음 세 가지를 소개한다. - **가상 머신(VM)**: 하이퍼바이저 위에서 각 게스트 운영체제를 실행한다. 인프라와 작업 사이에 하이퍼바이저 및 게스트 OS 계층이 존재한다. - **컨테이너**: 호스트 운영체제의 기능과 커널을 공유하면서 컨테이너 엔진을 통해 작업을 분리한다. VM보다 가볍게 실행할 수 있지만 격리 특성이 다르다. - **seccomp**: 프로세스가 호출할 수 있는 시스템 콜을 제한하는 Linux 보안 기능이다. - 각 방식은 격리 강도, 실행 비용, 성능, 시작 시간, 운영 편의성, 설정 복잡도 등에서 서로 다른 특성을 가진다. - 실제 환경에서는 단일 기술만 사용하기보다 workload의 신뢰 수준과 필요한 권한에 따라 여러 샌드박싱 primitive를 조합할 수 있다. ## 샌드박싱 선택 시 고려할 점 - 샌드박싱은 보안 취약점을 없애는 기술이 아니라, 취약점이 발생했을 때 공격의 범위와 피해를 제한하는 방어 계층이다. - 선택 과정에서는 다음을 함께 검토해야 한다. - 처리 대상이 사용자 입력인지, 내부에서 신뢰할 수 있는 데이터인지 - 작업이 필요한 파일·네트워크·시스템 콜의 범위 - 강한 격리에 필요한 성능 및 비용 - 샌드박스의 생성·폐기와 패치·모니터링 운영 부담 - 샌드박스 자체의 탈출 가능성과 호스트에 미치는 영향 - 샌드박싱 기술은 과거보다 안정적이고 실용적으로 발전했지만, 여전히 보안 연구와 운영 경험이 중요한 분야다. 악성 입력을 처리하는 기능은 메모리 안전 언어로의 전환만으로 보호하려 하기보다, 최소 권한과 강한 실행 격리를 함께 적용하는 것이 현실적이다. 특히 사용자 데이터를 다루는 고위험 작업은 VM이나 컨테이너 격리를 검토하고, 불필요한 시스템 콜은 seccomp로 추가 제한하는 접근이 유용하다.

원문 읽기

Docker & 컨테이너 webassembly c++application-security+3