Figma

736 개의 포스트

www.figma.com/blog/engineering

태그로 필터

figma

올바른 방향으로 빠르게 나아가는 방법 | Figma 블로그 (새 탭에서 열림)

AI는 소프트웨어 제작 속도를 크게 높였지만, 빠른 실행이 곧 올바른 제품을 의미하지는 않는다. AI가 만든 결과물을 그대로 받아들이면 기술 부채가 늘고, 평균적인 디자인과 기능에 머물 수 있다. 따라서 좋은 팀은 먼저 무엇을 만들지 충분히 고민하고, 명확한 맥락과 시스템을 제공한 뒤, 자신만의 관점으로 결과물을 다듬어야 한다. ## AI는 실행을 가속하지만 판단을 대신하지 못한다 - AI는 짧은 프롬프트만으로도 완성도 높아 보이는 프로토타입과 코드를 만들어낸다. - 그러나 겉보기의 완성도는 내부 구조, 제약 조건, 시스템 동작 방식까지 올바르다는 뜻이 아니다. - 과거에는 결과물의 세련됨 뒤에 전문가의 의사결정과 트레이드오프가 있었지만, 이제는 AI가 그 빈틈을 임의로 채울 수 있다. - **인지적 항복(cognitive surrender)**은 AI의 출력을 검토 없이 자신의 판단처럼 받아들이는 현상이다. - 첫 번째 결과물이 그럴듯하다는 이유로 바로 출시하지 말고, 문제의 본질과 실제로 만들 가치가 있는 것을 먼저 정의해야 한다. 글에서는 이를 **고려의 의무(consideration imperative)**로 표현한다. ## 맥락과 의도를 먼저 제공해야 한다 - 에이전틱 엔지니어링에서는 개발자의 역할이 코드를 직접 작성하는 것에서 **의도를 명확히 표현하고 검증하는 것**으로 이동한다. - Google의 관련 백서는 다음 요소를 중요한 기반으로 제시한다. - **결정론적 계층**: 테스트, 타입 검사, 검증처럼 매번 동일하게 실행되며 AI의 오류를 잡는 장치 - **고신호 맥락**: 명세, 문서화된 컴포넌트, 설계 원칙 등 에이전트가 의도를 정확히 이해하도록 돕는 정보 - **명확한 인터페이스**: 시스템 각 부분이 어떻게 연결되는지 에이전트가 추측하지 않도록 정의한 계약 - 디자인에서 코드로 전환할 때도 에이전트가 실제 프로덕션 컴포넌트의 구조를 모르면 픽셀을 보고 임의로 재구성할 가능성이 높다. - Figma MCP의 Code Connect처럼 실제 컴포넌트의 코드, props, variants를 제공하면 에이전트가 기존 시스템에 맞는 결과를 만들 수 있다. - 강력한 디자인 시스템은 결정 사항을 재사용 가능한 어휘와 가드레일로 codify해 결과물의 일관성을 높이고 코드와 기술 부채를 줄인다. - 초기에는 명세와 시스템을 준비하는 데 더 많은 시간이 들지만, 장기적으로 유지보수 비용을 낮춘다. ## “괜찮은 결과”는 쉽게 평균이 된다 - AI 모델은 방대한 기존 데이터를 학습했기 때문에 이미 널리 사용된 패턴과 스타일, 즉 **분포 안의 평균적인 결과**를 생성하는 경향이 있다. - 예를 들면 다음과 같은 결과가 반복될 수 있다. - 로고: 단순한 기하학적 형태와 그라디언트 - 발표 자료: 흔한 산세리프 글꼴과 익숙한 레이아웃 - React 컴포넌트: 둥근 모서리의 전형적인 카드 UI - 이런 결과는 틀리지는 않지만 차별성이 부족하다. - AI가 만든 “충분히 좋은” 결과를 반복해서 받아들이면 사용자의 판단 기준이 좁아지고, “무엇이어야 하는가?”보다 “덜 나쁜 선택은 무엇인가?”를 고르게 된다. - AI의 품질이 향상될수록 개인이 과거보다 나은 결과를 만들 수 있지만, 동시에 다른 AI 생성물과 비슷해질 위험도 커진다. ## 제품의 관점은 사람이 결정해야 한다 - AI는 실행과 변형을 빠르게 수행할 수 있지만, 제품의 목적과 차별화된 방향까지 자동으로 결정하게 두어서는 안 된다. - 명확한 의도와 평가 기준이 없으면 모델이 기본값과 평균적인 패턴을 대신 선택한다. - 팀은 AI가 제시한 결과를 출발점으로 활용하되, 왜 이 기능과 디자인이 필요한지, 누구를 위한 것인지, 무엇이 달라야 하는지를 직접 판단해야 한다. - 결국 속도의 핵심은 첫 결과물을 빨리 내는 것이 아니라, 명확한 맥락과 검증 장치를 통해 **올바른 방향으로 빠르게 반복하는 것**이다. AI를 활용할 때는 프롬프트 작성보다 먼저 목표, 제약 조건, 성공 기준을 문서화하는 것이 좋다. 테스트·타입 검사·디자인 시스템·명확한 인터페이스를 갖추고, AI 결과물을 반드시 사람의 관점과 제품 기준으로 검토해야 평균적인 결과와 기술 부채를 피할 수 있다.

figma

이 10가지 스킬을 시도해 보고—여러분의 스킬도 뽐내 보세요 | Figma 블로그 (새 탭에서 열림)

Figma의 ‘스킬’은 에이전트가 따를 작업 절차와 디자이너의 판단 기준을 담은 Markdown 지침 파일이다. 글은 디자이너가 자신의 스타일과 노하우를 스킬로 만들고, Figma 안에서 에이전트와 함께 작성·수정·실행할 수 있다고 설명한다. 이를 통해 반복 작업을 자동화하고, 개인의 디자인 감각을 팀의 워크플로에 확장할 수 있다. ## 디자이너의 판단을 담는 스킬 - 스킬은 엔지니어링 코드가 아니라, 에이전트가 따라야 할 순서화된 지침이나 프롬프트다. - 디자이너가 평소 사용하는 미적 기준, 작업 방식, 판단 규칙을 문서화할 수 있다. - 예시: - `/image-audit`: 파일 내 이미지의 내보내기 가능 여부를 검사하고 캔버스에 보고서 작성 - `/shader-starter`: 셰이더를 생성할 때 필요한 프롬프트 작성을 지원 - `/make-a-type-scale`: 선택한 텍스트를 기반으로 타입 스케일과 관련 폰트 변수를 생성 - `/ease-like-miggi` 스킬은 특정 디자이너가 선호하는 이징 커브를 키프레임에 적용해, 팀원도 동일한 모션 스타일을 사용할 수 있게 했다. ## Figma 안에서 스킬을 직접 제작하는 과정 - 디자인 프레임을 참고 자료로 제공하거나, 원하는 작업 단계와 가이드라인을 설명해 에이전트에 스킬 생성을 요청할 수 있다. - 에이전트가 초안을 만들면 미리보기로 결과를 확인한 뒤 채팅에서 바로 사용할 수 있다. - 테스트 과정에서 다음과 같이 반복 개선할 수 있다. - 작업 단계 수정 - Markdown 형식 변경 - 개선 방향이나 추천 요청 - Markdown 편집기를 통한 직접 수정 - 일부 스킬은 Figma MCP 서버와 연동되는 서드파티 에이전트에서도 사용할 수 있다. - MCP 서버용 스킬은 Figma의 GitHub 저장소에서 확인할 수 있다. ## 이미지에 X선 효과 적용하기 - 스킬: `/xray-scan` - 제작자: Adele Ix - 이미지나 텍스트 설명을 현실적인 방사선 사진처럼 변환한다. - 한 번에 두 가지 스타일을 생성한다. - 검은 배경 위에 빛나는 흰색 윤곽 - 흰 배경 위의 부드러운 어두운 톤 - 여러 X선 이미지를 겹쳐 독특한 모노크롬 콜라주를 만들 수 있다. - 빛나는 가장자리를 활용하기 때문에 여러 결과물을 겹쳐도 시각적으로 자연스럽게 섞인다. ## 모션이 필요한 지점 찾기 - 스킬: `/find-animation-opportunities` - 제작자: Linear의 Emil Kowalski - 디자인을 분석해 애니메이션이 필요한 부분과 오히려 애니메이션을 제거해야 할 부분을 찾아낸다. - 다음과 같은 질문에 답하도록 설계됐다. - 어떤 요소를 움직이면 더 생동감이 생기는가? - 어디에 어떤 모션을 적용해야 하는가? - 애니메이션의 구체적인 값은 무엇인가? - 제안된 변경 사항은 Figma Motion에서 직접 구현하거나 에이전트에게 적용하도록 요청할 수 있다. - 한 프레임을 대상으로 사용하고, 페이지의 타깃 사용자 같은 추가 맥락을 제공할 때 효과가 좋다. - “아예 움직이지 않아야 하는 요소는 무엇인가?”라고 질문하면 과도한 애니메이션도 줄일 수 있다. ## 정적인 구성에 카메라 움직임 추가하기 - 스킬: `/camera-pan-and-zoom` - 제작자: Figma의 Mallory Dean - 선택한 콘텐츠 주변에 실제 카메라 리그처럼 작동하는 중첩 레이어 구조를 만든다. - 팬, 줌, 롤 같은 카메라 움직임을 적용해 정적인 화면을 영상처럼 연출한다. - 예를 들어 여러 카드가 있는 그리드를 순차적으로 둘러본 뒤 전체 화면으로 다시 줌아웃하는 장면을 만들 수 있다. - 특정한 모션 연출에 특화된 스킬이지만, 복잡한 카메라 이동을 직접 구성하는 작업을 단순화한다. ## 실용적인 활용 방향 스킬은 단순한 자동화 명령이 아니라 디자이너의 작업 철학과 반복 가능한 판단을 팀에 공유하는 방법이다. 먼저 자신이 자주 수행하는 작업이나 고유한 스타일을 하나의 명확한 절차로 정리한 뒤, Figma 에이전트로 초안을 만들고 실제 결과를 확인하며 반복 개선하는 방식이 효과적이다.

figma

Figma Make를 통한 시간 절약 측정 | Figma 블로그 (새 탭에서 열림)

Figma 데이터 과학팀은 Figma Make가 디자인 작업을 얼마나 단축하는지 측정하기 위해 100명 대상의 무작위 대조 실험(RCT)을 설계했다. 그 결과 전체 디자인 작업은 20% 빨라지고 16% 쉬워졌으며, 특히 PM은 작업 시간이 23% 단축되고 난이도가 37% 낮아지는 가장 큰 효과를 보였다. 기존 A/B 테스트나 로그 기반 인과 추론만으로는 작업 복잡도와 사용자 경험 같은 교란 요인을 충분히 통제하기 어려워 RCT가 선택됐다. ## AI 시간 절감 측정의 어려움 - AI가 반복적·기계적인 업무를 대신하면 팀이 더 중요한 작업에 집중할 수 있지만, 실제 절감 시간과 효율 개선 지점을 정량화하기는 어렵다. - 작업 완료 시간에는 AI 사용 여부 외에도 다음과 같은 교란 요인이 영향을 준다. - 근속 기간 - 경력과 숙련도 - 작업의 복잡성 - 개인의 주관적인 디자인 경험 - 이런 요인을 통제하지 않으면 생산성 향상이 AI 때문인지, 다른 조건 때문인지 구분하기 어렵다. ## 기존 방법의 한계 ### 온라인 A/B 테스트 - 한 그룹에는 Figma Make를 제공하고 다른 그룹에는 제공하지 않는 방식이다. - 무작위 배정으로 사용자 특성의 차이는 어느 정도 줄일 수 있다. - 그러나 사용자마다 수행하는 작업이 달라 작업 난이도와 유형을 동일하게 맞추기 어렵다. - 따라서 두 그룹의 완료 시간 차이가 AI 효과인지, 과제 차이 때문인지 판단하기 어렵다. ### 로그 데이터 기반 인과 추론 - AI 기능을 사용한 작업과 사용하지 않은 작업의 평균 소요 시간을 비교하는 방식이다. - **성향 점수 매칭(PSM)**은 각 작업이 AI 사용 조건에 속할 확률을 계산해 비교하지만, 모든 교란 요인이 로그에 기록되어 있어야 한다. - 익명화된 사용자 ID만으로는 사용자의 주관적인 디자인 숙련도나 경험을 알 수 없어 PSM 적용에 한계가 있다. - **도구 변수(IV)** 방법은 AI 사용 여부에 영향을 주면서 작업 속도에는 다른 방식으로 영향을 주지 않는 변수가 필요하다. - 하지만 Figma 로그에는 이러한 조건을 만족하는 유효한 도구 변수가 없었다. ## 무작위 대조 실험을 선택한 이유 - RCT는 인과적 효과를 측정하는 표준적인 방법으로, 데이터 수집 단계에서 교란 요인을 직접 통제할 수 있다. - 연구에서는 다음 세 가지 요소를 결합했다. - **무작위 배정:** 참가자를 실험군과 대조군에 나누어 개인별 차이를 양쪽에 대체로 균등하게 분산 - **동일한 과제:** 모든 참가자가 같은 작업을 수행하게 해 과제 속성의 영향을 제거 - **실험 진행 관리:** 숙련된 연구팀이 실험을 감독해 수행 과정의 변동과 통계적 오류를 줄임 - 제품 디자이너와 PM이 일상적인 디자인 업무에서 Figma Make를 사용할 때 얻는 시간 절감 효과를 측정하기 위해 Figma 안팎의 사용자 연구팀과 협력했다. ## 연구 대상과 실험 도구 - 여러 AI 도구를 동시에 허용하면 어떤 도구가 시간 절감에 기여했는지 구분하기 어려워, 연구 대상 AI를 Figma Make 하나로 제한했다. - Figma Make는 사용자 기반이 크고 다양한 디자인 작업에 활용될 수 있어 연구 도구로 선정됐다. - 참가자는 총 100명으로 구성됐다. - 제품 디자이너 50명 - 제품 관리자 50명 - 표본 수는 GitHub Copilot 무작위 대조 실험 등 기존 연구에서 관찰된 효과 크기를 참고해 산출했다. - 이후 통계적으로 유의미한 효과를 탐지할 수 있도록 검정력 분석(power analysis)을 수행해 최종 표본 규모를 결정했다. ## 관찰된 효과 - 전체적으로 Figma Make 사용 시: - 디자인 작업이 **20% 더 빨라짐** - 작업이 **16% 더 쉬워짐** - 직군별로는 PM의 효과가 가장 컸다. - 작업 시간 **23% 단축** - 작업 난이도 **37% 감소** 실무에서 AI의 생산성 효과를 검증하려면 단순한 사용 로그 비교보다, 동일한 과제와 무작위 배정을 포함한 통제된 실험이 더 신뢰할 만하다. 특히 AI 도입 효과를 직군별로 비교하려면 사용자 특성뿐 아니라 과제 복잡도와 실험 진행 방식까지 함께 표준화하는 것이 중요하다.

figma

더 나은 코드, 더 적은 토큰: MCP에서 Code Connect의 이점 | Figma 블로그 (새 탭에서 열림)

코딩 에이전트가 디자인을 코드로 변환할 때 Code Connect를 사용하면 실제 프로덕션 컴포넌트와 디자인 시스템을 더 정확히 활용할 수 있다. Figma MCP와 Code Connect를 함께 사용한 실험에서 작업 시간은 19.6%, 토큰 사용량은 29.5% 감소했고, 코드 품질은 1~4점 척도에서 1점 향상됐다. 즉, 시각적으로 비슷한 코드를 새로 만드는 대신 기존 컴포넌트를 직접 연결하면 더 빠르고 일관된 결과를 얻을 수 있다. ## 코딩 에이전트가 디자인 시스템을 잘못 구현하는 이유 - Figma MCP의 `get_design_context`는 캔버스의 디자인을 React 코드 형태로 설명한다. - Code Connect가 없으면 에이전트는 다음과 같은 문제를 겪을 수 있다. - 기존 컴포넌트 대신 새로운 컴포넌트를 직접 생성한다. - 디자인 시스템에서 잘못된 컴포넌트를 선택한다. - 올바른 컴포넌트를 찾더라도 검색과 수정에 불필요한 토큰과 시간을 사용한다. - 결과물은 시각적으로는 맞아 보여도 프로젝트의 실제 코드 구조나 디자인 시스템 규칙과 어긋날 수 있다. ## Code Connect가 MCP 응답을 보강하는 방식 - Code Connect는 Figma 컴포넌트와 코드베이스의 실제 컴포넌트를 연결한다. - 설정이 완료되면 MCP 응답에 일반적인 React 표현 대신 프로덕션 코드에 가까운 코드 스니펫이 포함된다. - 에이전트는 다음 정보를 직접 전달받는다. - 사용해야 할 컴포넌트의 import 경로 - 컴포넌트에 전달할 정확한 속성값 - 디자인 요소와 코드 컴포넌트 간의 대응 관계 - 예를 들어 Code Connect가 없으면 탭 UI를 여러 `<button>` 요소와 CSS 클래스로 재구성할 수 있다. - Code Connect를 사용하면 다음처럼 기존 디자인 시스템 컴포넌트를 바로 사용한다. ```tsx <SegmentedControl value="design" options={["Design", "Code"]} /> ``` ## Coinbase 사례 - Coinbase Design Systems 팀은 일관된 UI를 위해 핵심 컴포넌트, 디자인 토큰, 인프라를 관리한다. - 에이전트 기반 개발을 도입하면서 Code Connect를 적용해 에이전트가 CDS 컴포넌트를 재사용하도록 했다. - Code Connect가 없을 때는 에이전트가 스테퍼를 프로그레스 바 조합으로 임의 구현하는 등 컴포넌트를 잘못 추측할 수 있었다. - Code Connect를 사용하면 정확한 코드 표현과 실제 CDS 컴포넌트의 import 문을 확인할 수 있어 코드 품질이 향상되고 토큰도 절약됐다. ## Code Connect의 효과를 측정한 실험 - 동일한 디자인, 프롬프트, 모델을 사용해 Code Connect 적용 여부만 달리한 디자인-투-코드 작업을 비교했다. - 총 27개 테스트 케이스에서 다음 항목을 측정했다. - 코드 품질 - 토큰 사용량 - 작업 소요 시간 - React 기반 디자인 시스템 두 가지를 대상으로 했다. - Figma의 예제 디자인 시스템인 Simple Design System(SDS) - 더 규모가 크고 복잡한 내부 시스템인 Figma Pattern Library(FPL) - Code Connect 적용 결과: - 작업 시간 중앙값 19.6% 감소 - 토큰 사용량 중앙값 29.5% 감소 - 코드 품질 1~4점 Likert 척도에서 1점 향상 ## 실용적인 적용 방향 - 디자인 시스템의 핵심 컴포넌트에 Code Connect 템플릿을 우선 설정하는 것이 효과적이다. - 에이전트가 직접 HTML과 스타일을 조합하게 하기보다 실제 컴포넌트와 import 정보를 제공해야 한다. - 디자인 시스템을 사용하는 팀이라면 Code Connect를 단순한 인간 개발자용 문서화 도구가 아니라 에이전트의 코드 생성 품질과 비용을 개선하는 컨텍스트 계층으로 활용할 수 있다.

figma

코드, 장인정신, 그리고 중첩 폴더의 제작 | Figma 블로그 (새 탭에서 열림)

Figma의 중첩 폴더는 단순한 파일 정리 기능이 아니라 콘텐츠 구조와 권한 모델을 재설계한 대규모 제품 작업이었다. 개발 과정에서 팀은 전통적인 순차형 프로세스 대신 코드로 아이디어를 빠르게 검증하고, 직무 경계를 유연하게 넘나들며, 인수인계를 대화 중심 협업으로 바꾸었다. 그 결과 변화하는 AI·코드 중심 환경에서도 복잡한 기능을 빠르게 구체화하고 출시할 수 있었다. ## 중첩 폴더가 단순한 기능이 아니었던 이유 - 중첩 폴더는 규모가 커지는 팀이 파일과 프로젝트를 계층적으로 정리하도록 돕는 기능이다. - 구현 범위는 파일 브라우저에 그치지 않았다. - 콘텐츠 구조 - 관리자 제어 - 공유 방식 - 권한 처리 - 핵심 인프라 - 따라서 기존 모델에 폴더 한 단계만 추가하는 방식이 아니라, Figma의 콘텐츠 및 권한 모델을 근본적으로 재검토해야 했다. ## 변화한 제품 개발 환경 - 프로젝트 초기에는 일반적인 순차형 개발 방식을 따랐다. - 제품팀이 요구사항을 정의 - 디자인팀이 사용자 경험을 설계 - 설계가 충분히 정리된 뒤 엔지니어링 시작 - 그러나 개발 중 팀의 자원과 우선순위가 달라졌다. - AI 네이티브 기능 개발로 인력이 분산됨 - Figma Make, MCP 서버, 에이전트 스킬, 코드베이스 프로토타이핑 등이 아이디어를 빠르게 구현하는 수단으로 부상함 - 아이디어는 더 이상 완성된 문서에서만 출발하지 않고, 프로토타입·코드·Slack의 간단한 스케치에서도 시작될 수 있게 되었다. ## 코드로 먼저 검증하기 - 코드 작성 비용이 낮아지면서 논쟁이나 추상적인 기획을 오래 이어가기보다 실제 구현물을 빠르게 만들 수 있게 되었다. - 팀은 아이디어를 검증하기 위해 초기부터 pull request(PR)를 생성했다. - PR은 단순한 최종 코드 리뷰 수단이 아니라 다음을 확인하는 실험 도구로 활용되었다. - 기술적으로 가능한지 - 사용자 경험이 자연스러운지 - 권한과 데이터 구조에 문제가 없는지 - 여러 대안 중 어떤 방향이 적절한지 - 실제 동작하는 결과물을 바탕으로 논의하면서 의사결정 속도와 피드백의 구체성이 높아졌다. ## 직무 경계를 유연하게 바꾸기 - 역할을 엄격히 분리하기보다 문제 해결에 필요한 사람이 해당 영역의 결정을 맡았다. - 엔지니어가 디자인 관련 결정을 내리고, 디자이너가 직접 코드를 작성하는 등 업무 범위가 서로 겹쳤다. - 제품 관리자는 일상적인 실행 관리에서 일부 벗어나 더 큰 전략적 질문에 집중했다. - 이 방식은 각 직무의 전문성을 없애는 것이 아니라, 프로젝트 상황에 따라 책임을 유연하게 배분하는 접근이다. ## 인수인계 대신 지속적인 대화 - 디자인 완료 후 개발로 넘기는 식의 일방적인 handoff를 줄였다. - 역할의 경계가 흐려지면서 팀원들은 서로에게 배우는 동시에 자신의 전문 지식을 공유하는 관계가 되었다. - 평소 각 직무가 독점하던 작업 방식과 판단 기준을 공개함으로써 협업에 필요한 신뢰를 쌓았다. - 결과적으로 디자인, 제품, 엔지니어링이 단계별로 분리된 프로세스가 아니라 지속적인 대화와 공동 결정에 가까워졌다. ## 실용적인 시사점 복잡한 기능을 개발할 때는 완벽한 사전 설계만 기다리기보다 작은 PR과 프로토타입으로 가설을 검증하는 것이 효과적이다. 또한 직무별 책임을 고정하기보다 문제의 성격에 따라 역할을 유연하게 조정하고, 인수인계 문서만으로 소통하기보다 실행 과정에서 지속적으로 대화하는 협업 구조를 만드는 것이 중요하다.

figma

AI 숙련도는 최종 목표가 아니다 | Figma 블로그 (새 탭에서 열림)

AI 도구를 잘 다루는 능력은 중요하지만, 그것만으로는 AI 시대의 성공을 보장할 수 없다. 더 중요한 역량은 개인의 생산성 향상을 팀 전체의 속도로 확장하고, 다양한 의견을 모아 결정을 내리며, 실험과 실패를 안전하게 공유하는 협업 능력이다. 결국 AI의 가치는 한 사람이 10배 빠르게 일하는 데보다 팀 전체가 함께 더 빠르고 현명하게 움직이는 데 있다. ## AI 활용 능력 이상의 역량 - 제품 개발자 90% 이상이 AI 활용 능력을 미래의 성공에 필수적이라고 답했다. - AI 도구 숙련도는 채용, 업무 속도, 자신감 향상에 직접적인 도움을 준다. - 그러나 AI가 업무 방식을 바꿀수록 다음과 같은 역량의 중요성이 더 커진다. - 팀이 함께 사용할 수 있는 시스템 구축 - 적절한 사람들과 아이디어를 주고받는 능력 - 공동의 목표를 향해 협력하는 능력 ## 내부 제품 빌더가 되기 - AI 도구를 개인용으로만 사용하지 말고, 팀 전체가 활용할 수 있는 내부 도구로 전환해야 한다. - 예시는 다음과 같다. - 프로토타이핑 에이전트 - 브랜드 플러그인 - 공유 프롬프트 라이브러리 - 누구나 사용할 수 있는 프로토타이핑 도구 - Figma 연구팀은 AI를 활용해 설문 데이터를 탐색할 수 있는 인터랙티브 웹사이트를 만들었다. - 데이터와 맥락이 개인의 컴퓨터나 머릿속에만 머무르지 않게 했다. - AI를 개인 생산성 도구가 아니라 팀의 협업 역량을 확장하는 수단으로 활용했다. - Figma Brand Studio는 Figma Make로 이미지 효과 생성기를 제작했다. - 팀원이 사진이나 디자인에 브랜드에 맞는 질감을 클릭 한 번으로 적용할 수 있었다. - 핵심은 팀의 업무에서 반복되거나 막히는 지점을 발견하고, AI로 마찰을 줄이는 것이다. - 한 사람이 10배 빠르게 일하는 것보다 팀 전체가 함께 10배 빠르게 움직이는 편이 더 큰 효과를 낸다. ## 수많은 선택지에서 결정으로 이끌기 - AI는 짧은 시간에 수십 개의 방향과 결과물을 만들어내므로, 생성 자체보다 선택과 의사결정이 어려워진다. - 효과적인 의사결정을 위해서는 프로젝트 책임자뿐 아니라 다음 사람들을 참여시켜야 한다. - 반대 의견이나 새로운 관점을 가진 사람 - 과거의 맥락과 조직의 경험을 아는 사람 - 잠재적 위험을 발견할 수 있는 전문가 - 한 팀이 AI로 내부 앱을 빠르게 만들었지만, 직원들이 접근해서는 안 되는 회사 프로젝트 정보가 노출되는 문제가 발생했다. - 데이터 거버넌스 전문가를 초기 단계부터 참여시켰다면 예방할 수 있었던 사례다. - 회의 전에 이해하기 쉬운 선택지를 제공해야 한다. - 프로토타입의 각 흐름을 설명하는 Loom 영상 - 방향별 동작을 보여주는 주석이 달린 FigJam 파일 - 회의에서는 단순한 설명보다 트레이드오프를 비교하고 결정을 내리는 데 집중해야 한다. - 발언하지 않은 사람의 의견을 요청한다. - 모호한 추천은 구체적으로 되묻는다. - 논의를 진전시키는 질문을 한다. - 회의가 끝나기 전에 결정사항과 다음 단계를 확인한다. ## 나쁜 아이디어도 공유하기 - AI 활용 속도는 개인과 조직 사이에서 서로 다르게 나타난다. - 20%는 개인 기여자가 조직의 지원 없이 앞서가고 있다고 답했다. - 27%는 리더십이 AI 도입을 밀어붙이지만 팀이 따라가기 어려워한다고 답했다. - 팀원마다 AI를 접한 시점과 숙련도가 달라, 방치하면 역량 격차가 계속 커질 수 있다. - 앞선 사람만 계속 실험하면 다른 구성원은 AI 활용법을 배우기보다 뒤처지는 상황에 놓인다. - 따라서 아직 다듬어지지 않은 아이디어나 실패한 시도도 공유할 수 있는 환경이 필요하다. - 실험 결과를 공개적으로 나누면 개인의 경험이 팀의 학습 자산이 되고, AI 도입 속도 차이를 줄일 수 있다. AI 도구를 배우는 데 그치지 말고, 팀이 함께 사용할 수 있는 도구와 프로세스를 만들고, 다양한 이해관계자를 참여시켜 의사결정을 구조화하는 것이 좋다. 또한 완성된 결과만 공유하기보다 실패와 미숙한 아이디어까지 안전하게 나누는 문화를 구축해야 AI의 효과를 조직 전체로 확장할 수 있다.

figma

속성 패널과 주석 기능, 이제 Figma Make에서 사용 가능 | Figma 블로그 (새 탭에서 열림)

Figma Make에 속성 패널과 주석 기능이 추가되어, 사용자는 코드를 직접 작성하지 않고도 시각적으로 인터페이스를 수정할 수 있게 되었다. 속성 패널은 간격·타이포그래피·레이아웃 같은 시각적 변경을 정밀하게 처리하고, 주석은 애니메이션이나 상호작용처럼 설명이 필요한 변경을 특정 요소에 연결해 전달한다. 두 기능은 디자인과 코드 사이의 간극을 줄이고, 프롬프트 기반 편집보다 정확하고 효율적인 작업 흐름을 제공한다. ## Figma Make의 속성 패널과 주석 기능 - Figma Make 편집기에서 요소를 선택한 뒤 시각적 컨트롤이나 자연어 주석으로 코드를 수정할 수 있다. - 디자인을 수정하는 과정과 코드가 업데이트되는 과정을 하나의 연속적인 작업 흐름으로 통합한다. - 새 기능은 처음부터 작업하는 경우뿐 아니라 기존 코드 기반 프로젝트를 편집할 때도 사용할 수 있다. ## 속성 패널을 활용한 시각적 편집 - 상단 툴바에서 **Edit**를 선택하면 요소의 속성을 조정할 수 있다. - 조정 가능한 항목에는 다음이 포함된다. - 패딩, 요소 간 간격, 코너 반경 - 글꼴 굵기, 줄 높이, 자간 - 투명도, `z-index`, 테두리 스타일 - 위치와 레이아웃 속성 - 코드의 전체 DOM 트리를 레이어 패널처럼 확인하면서 원하는 요소를 선택할 수 있다. - 동일한 요소의 모든 인스턴스를 한 번에 선택해 일괄 수정할 수 있다. - 현재는 코드베이스에 정의된 색상 및 타이포그래피 토큰을 사용해 디자인 일관성을 유지한다. - 향후 Code Connect가 적용되면 Figma Design 컴포넌트와 코드 컴포넌트 간 연결도 강화될 예정이다. ## 변경 사항 검토와 코드 반영 - 속성 패널에서 변경한 내용은 즉시 코드에 확정되지 않고 프롬프트 입력창에 먼저 단계적으로 쌓인다. - 사용자는 각 변경 사항을 검토한 뒤 적용하거나 마음에 들지 않는 변경을 폐기할 수 있다. - 적용을 완료하면 Figma Make가 실제 코드를 수정하고 새로운 파일 버전을 생성한다. - 따라서 캔버스에서 시각적으로 확인한 결과와 실제 배포되는 코드 사이의 불일치를 줄일 수 있다. ## 주석을 통한 정밀한 프롬프트 작성 - 속성 패널만으로 표현하기 어려운 상호작용, 애니메이션, 동작 변경에는 주석 기능을 사용할 수 있다. - **Annotate for agent**를 선택한 뒤 캔버스에서 변경 대상 영역을 직접 표시하고 자연어로 요구사항을 작성한다. - 예시는 다음과 같다. - 썸네일에 마우스를 올리면 약간 확대 - 버튼을 300ms 지연 후 페이드 인 - 버튼을 탭할 때 눌리는 효과 추가 - 메뉴 버튼 클릭 시 전체 화면 내비게이션 오버레이 표시 - 번호가 매겨진 주석으로 여러 요소를 동시에 지정할 수 있다. - 에이전트는 표시된 정확한 위치와 설명을 함께 활용해 관련 코드 전체에 변경 사항을 적용한다. ## 프롬프트 비용과 작업 효율 - 직접 요소를 선택하면 에이전트가 수정 대상을 탐색하거나 추측할 필요가 줄어든다. - 일반적인 텍스트 프롬프트로 같은 변경을 설명하는 것보다 토큰을 적게 사용하고 더 빠르게 완료할 수 있다. - 변경 사항은 적용 전까지 크레딧을 소비하지 않고 대기한다. - 최종적으로 변경 사항을 적용할 때 크레딧이 차감되고 파일이 새 버전으로 업데이트된다. ## 디자인과 코드의 통합 - 속성 패널은 시각적 조정에, 주석은 동작과 맥락이 필요한 변경에 적합하다. - 두 기능을 통해 사용자는 코드를 직접 다루면서도 Figma와 유사한 시각적 편집 경험을 유지할 수 있다. - 같은 편집 경험은 향후 Figma Design의 코드 레이어에도 제공될 예정이다. - 장기적으로는 Figma 캔버스에서 코드 기반 결과물을 여러 방향으로 탐색하고 팀과 함께 비교하는 작업이 가능해진다. 실무에서는 간격·타이포그래피·레이아웃처럼 명확한 시각 속성은 속성 패널로 수정하고, 인터랙션이나 애니메이션처럼 의도가 중요한 변경은 주석으로 요청하는 방식이 가장 효율적이다. 적용 전 검토 단계가 제공되므로 여러 변경을 시도한 뒤 실제 코드 반영 여부를 결정하는 것도 권장된다.

figma

에이전트를 활용해 Figma의 내부 시스템을 보호하는 방법 | Figma 블로그 (새 탭에서 열림)

Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다. ## 보안 경보 대응의 병목 - Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다. - 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다. - 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다. - 같은 경보가 과거에 발생했는지 - 이전 조사에서 어떤 결론을 내렸는지 - 관련된 Slack 대화가 있는지 - 문제를 해결할 예정인 PR이 존재하는지 - 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다. - 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다. ## 검색 시스템에서 에이전트 시스템으로의 확장 - 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다. - 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다. - 경보 조사 - 보안 데이터 레이크와 감사 로그 질의 - 관련 코드 변경 작성 - PR 생성 - 과거 조사 결과를 기억하고 다음 대응에 활용 - Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다. - 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다. ## RAG 계층: 경보에 기억을 부여하기 - Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다. - Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다. - 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다. - `p_any_ip_addresses`에서 추출한 IP 주소 - `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보 - ARN에서 추출한 AWS 계정 ID - 경보 제목, 심각도, 태그, 생성 시각 - 경보 유형, 상태, 조사 맥락의 존재 여부 - 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다. ## 의미 검색과 최신성 반영 - 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다. - 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다. ```text {경보 제목} has_investigation_context=1 ``` - 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다. - 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다. - 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다. - 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다. ## Slack 조사 기록의 자동 축적 - `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다. - 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다. - Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다. - 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다. - 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다. - 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다. ## 실용적인 적용 방향 - 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다. - 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다. - 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다. - 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다. - AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.

figma

디지털 도구, 인간의 표현: Config 2026의 시각적 아이덴티티 | Figma 블로그 (새 탭에서 열림)

Config 2026의 시각적 정체성은 AI 시대의 강력한 디지털 도구와 인간의 창의적·불완전한 표현을 함께 보여주는 데 초점을 맞췄다. Figma Brand Studio는 아이디어가 변형되고 확장되는 과정을 글리프, 생성형 텍스처, 동적인 구성으로 표현했다. 그 결과 디지털 화면부터 샌프란시스코 Moscone Center의 대형 조형물과 공간 연출까지 일관되면서도 인간적인 브랜드 경험을 만들었다. ## 인간과 AI의 협업을 표현한 세 가지 원칙 - **진화(Evolution)** - 아이디어를 그대로 완성하는 대신 remix, reinterpret, reinvent 과정을 거쳐 새로운 결과를 만든다는 개념이다. - 하나의 형태가 변형되고 증식하는 모습을 시각 시스템에 반영했다. - **유동성(Fluidity)** - 디자인, 코드, 프로토타입 사이를 오가며 다양한 지점에서 작업을 시작하는 현대적 제작 방식을 나타낸다. - 고정된 순서보다 반복과 순환을 강조한다. - **조화(Harmony)** - 생성형 도구로 빠르게 탐색하더라도 최종 판단에는 인간의 관점과 감각이 필요하다는 의미다. - AI의 정교함과 사람의 의도적인 불완전성을 함께 유지했다. ## 글리프로 아이디어의 변형과 확장을 시각화 - Config의 핵심 시각 요소는 스케치처럼 보이거나, 생성형 이미지처럼 유기적이거나, 선명한 기하학 형태를 가진 **글리프**였다. - 입자 형태의 글리프는 아이디어가 계속 생성되고 퍼지는 과정을 상징했다. - 반대로 깔끔한 직사각형은 충분히 정리되고 완성된 아이디어를 나타냈다. - 글리프는 약 14피트 높이의 폼 조형물로 제작되어 Moscone Center 외부와 행사 공간의 장면을 구성했다. - 결과물은 다소 엉뚱하고 개성 있어 보이면서도 프로그램으로 생성된 듯한 디지털 특성을 동시에 지녔다. ## AI로 만든 불완전한 텍스처 - 팀은 Figma Make로 원하는 로파이 효과를 도구화하고, 다음 세 가지 핵심 텍스처를 제작했다. - 낙서 같은 선화 - 흐릿한 그라디언트 - 타원형 입자 - 이미지를 도구에 입력해 예측하기 어렵고 손으로 그린 듯한 구성을 생성했다. - 완벽하고 자동화된 시각물 대신 작은 오류와 불규칙성을 남겨 인간적인 느낌을 강조했다. - 수백 명의 발표자 사진에는 디더링 도구를 적용했다. - 모든 사진에 일관된 스타일을 빠르게 적용했다. - 미세한 점묘 효과가 디지털 코드처럼 보이면서도 손으로 만든 질감을 더했다. - 흐릿한 형태와 거친 점 텍스처는 키노트 무대, 영상, 행사장 애니메이션 등 여러 접점에서 활용됐다. ## 정적인 디자인과 모션의 병행 제작 - 팀은 정적 그래픽을 먼저 완성한 뒤 애니메이션으로 넘기는 방식 대신, 정적 자산과 모션 자산을 동시에 개발했다. - 디자인과 모션이 서로 영향을 주는 반복적인 협업 구조를 취했다. - 초기 글리프가 실제로 움직이는 모습을 확인하면서 형태의 가능성을 새롭게 발견하는 등, 애니메이션 자체가 디자인 탐색의 도구로 기능했다. - 이를 통해 Config의 그래픽은 단순한 장식이 아니라 아이디어가 살아 움직이고 변형되는 과정을 보여주는 시스템이 됐다. ## 실용적인 시사점 AI를 활용한 브랜드 디자인에서도 결과물을 지나치게 매끈하게 만드는 것보다, 의도적인 불완전성과 인간의 판단을 남기는 것이 차별화에 도움이 된다. 또한 글리프·텍스처·모션처럼 재사용 가능한 시각 요소를 시스템화하면 디지털 콘텐츠와 오프라인 공간 전반에 일관된 경험을 효율적으로 확장할 수 있다.

figma

에이전트를 활용해 취약점에 앞서가는 Figma의 방법 | Figma 블로그 (새 탭에서 열림)

Figma는 하나의 보안 정책을 기반으로 AI 에이전트를 코드 작성, 풀 리퀘스트(PR) 리뷰, 과거 코드 감사에 활용한다. 핵심은 단순히 취약점을 많이 찾는 것이 아니라, 정밀도(실제 취약점 비율)와 재현율(실제 취약점 탐지 비율)을 함께 관리해 개발자의 신뢰를 확보하는 것이다. 특히 모든 PR에 적용되는 리뷰 시스템과 사람의 피드백·기존 취약점 재검증을 통해 정책을 지속적으로 개선한다. ## 에이전트 보안의 세 가지 적용 단계 - **코드 생성 단계**: 개발자가 코드를 작성하는 과정에서 취약점을 예방한다. - **PR 리뷰 단계**: 변경된 코드를 검토해 배포 전에 문제를 탐지하고 수정하도록 한다. - **과거 코드 감사 단계**: 오래된 모노레포 전체를 점검해 이미 배포된 취약점을 찾는다. - 세 단계 모두 다음 내용을 포함한 공통 정책을 사용한다. - 신뢰 경계 - 조직이 허용한 위험 - 과거 판단의 선례(precedent) ## 정밀도와 재현율을 함께 측정 - **정밀도(precision)**: - 에이전트가 보고한 결과 중 실제 취약점의 비율이다. - 높을수록 오탐(false positive)이 적다. - **재현율(recall)**: - 실제 존재하는 취약점 중 에이전트가 찾아낸 비율이다. - 높을수록 미탐(false negative)이 적다. - 취약점을 많이 보고하는 것만으로는 충분하지 않다. - 오탐이 많으면 개발자가 도구의 결과를 무시하게 된다. - 반대로 정밀도만 높이고 탐지 범위를 줄이면 중요한 취약점을 놓칠 수 있다. ## PR 리뷰를 먼저 구축한 이유 Figma는 코드 생성이나 전체 저장소 감사보다 개선 주기가 빠른 PR 리뷰부터 만들었다. - **보편성**: 모든 PR이 리뷰 대상이 된다. - **셀프서비스 구조**: 에이전트가 PR에 직접 댓글을 달고, 작성자가 해당 결과에 답변한다. - **양방향 측정**: - 정밀도는 작성자의 thumbs up/down 평가와 설명으로 측정한다. - 재현율은 이미 취약점이 있었던 커밋에 리뷰어를 다시 실행해 놓친 문제를 세는 방식으로 측정한다. - 이렇게 수집한 피드백은 에이전트가 따르는 보안 정책 개선에 반영된다. ## 여러 모델을 병렬로 사용 - Figma는 서로 다른 취약점을 놓치는 모델을 함께 사용한다. - Claude Code의 Opus 4.8, xhigh 노력 수준 - Codex의 GPT-5.6 Sol, high 노력 수준 - 어느 한 모델이라도 문제를 보고하면 결과를 상위 단계로 전달한다. - PR 하나의 리뷰 비용은 중앙값 약 0.50달러이며, 대부분의 PR에는 보고할 문제가 없어 비용이 크게 증가하지 않는다. - Figma는 이 비용이 버그 바운티 지급이나 사용자 피해를 예방하는 효과에 비해 충분히 낮다고 판단한다. ## 실제로 탐지한 취약점 사례 - 복잡한 취약점: - 주입된 샌드박스 객체가 호스트 영역의 `Function` 생성자에 접근할 수 있음을 추론했다. - 이를 통해 데스크톱 클라이언트에서 코드 실행으로 이어지는 경로를 찾아냈다. - 일반적인 접근 제어 취약점: - 송장 조회 API가 호출자가 전달한 송장 ID만 확인하고 소속 조직을 검증하지 않았다. - 인증된 사용자가 ID만 알면 다른 조직의 송장을 읽을 수 있는 IDOR(Insecure Direct Object Reference) 문제였다. - 해결책은 송장 조회 시 인증된 사용자의 조직에 속하는지 함께 확인하는 것이다. ## 초기 도입과 신뢰 확보 - Anthropic이 Claude Code Security Reviewer를 공개한 2025년 8월, Figma는 즉시 도입했다. - 처음에는 개발자 PR 댓글이 아닌 Slack과 Datadog로만 결과를 보내는 shadow mode로 운영했다. - 리뷰어는 두 단계로 동작했다. - 잠재적 취약점 탐색 - 적대적 검토를 통한 오탐 필터링 - 실제 보안 사고를 재현했을 때 근본 원인을 거의 그대로 찾아냈고, 애플리케이션 보안과 인프라 설정 오류 등 여러 영역에도 잘 일반화됐다. - 그러나 첫 주에는 27개 결과 중 4개만 유효해 정밀도가 약 15%에 불과했다. - Figma는 개발자에게 노출하기 위한 기준으로 70% 정밀도를 설정했다. - 10개 중 7개가 유효해야 개발자가 결과를 읽을 것이라는 실용적 기준이다. - 2주간의 관찰 기간 동안 정밀도가 70% 이상이고 심각한 오탐이 없을 때까지 PR 댓글을 보류했다. - 이를 위해 최근 8주간의 PR에 리뷰어를 다시 실행하고, 보안팀이 오탐을 직접 분류했다. - 과거 사례를 기반으로 에이전트가 따라야 할 정책을 작성했다. - 여기서 **선례(precedent)**는 특정 상황에서 어떤 보고가 유효하거나 유효하지 않은지 설명하는 구체적인 사례다. ## 실용적인 결론 AI 보안 에이전트를 도입할 때는 처음부터 모든 개발자에게 결과를 노출하기보다 shadow mode로 운영하며 정밀도를 먼저 확보하는 것이 좋다. 모든 PR에 적용하고, 사람의 결과 평가와 알려진 취약점 재검증을 분리해 수집하면 신뢰성과 탐지력을 함께 개선할 수 있다.

figma

Sightlines 1호: Config에서 얻은 인사이트 | Figma 블로그 (새 탭에서 열림)

AI 시대에도 좋은 리더십의 기본과 디자인의 본질은 변하지 않는다. 리더들은 AI를 제품·팀·업무 시스템에 통합하면서도 품질을 유지하는 방법을 실험하고 있으며, 속도보다 중요한 것은 인간의 판단력과 협업이라고 강조한다. 자동화로 생산량이 늘어날수록 좋은 결과를 선별하는 ‘취향(taste)’과 세밀한 완성도가 핵심 경쟁력이 된다. ## AI 시대의 리더들이 고민하는 과제 - AI를 제품, 조직, 업무 프로세스에 어떻게 도입할지 아직 대부분의 리더가 탐색 중이다. - AI가 제공하는 빠른 제작 속도를 활용하면서도 품질 저하를 막아야 한다. - AI 이전의 전문성, 팀 구조, 협업 방식 중 무엇을 유지하고 무엇을 바꿀지 재검토하고 있다. - 변화의 방향을 리더 자신도 완전히 알지 못하는 상황에서 팀을 이끌어야 한다. ## 변하지 않는 리더십의 기본 - 좋은 리더의 핵심 역량은 AI 시대에도 크게 달라지지 않는다. - 호기심이 많고 비판적으로 사고하는 사람들로 팀을 구성해야 한다. - 빠르게 결과를 만드는 것보다 높은 완성도와 장인정신에 대한 기준을 유지해야 한다. - 리더는 모든 세부 사항을 직접 통제할 수 없으므로, 신뢰할 수 있는 인재를 채용하고 권한을 위임해야 한다. ## 초보자의 관점으로 실험하기 - 리더와 팀원 모두 기존 방식이나 전문성에만 의존하지 않고 원칙부터 다시 검토해야 한다. - AI 도구를 단순히 도입하는 데 그치지 말고, 실제 프로토타입을 만들며 가능성과 한계를 확인해야 한다. - 리더도 팀과 함께 직접 실험하며 변화 과정을 경험해야 한다. - 새로운 도구를 좇기보다 어떤 문제를 해결하려는지, 고객과 인간에게 어떤 가치를 주는지를 먼저 판단해야 한다. ## 개인 작업보다 중요해진 협업 - AI 도구는 사람을 혼자 작업하는 흐름으로 끌어갈 수 있지만, 리더들은 오히려 협업을 강화하고 있다. - 작업물을 공개하고, 팀 전체가 피드백과 비평을 주고받아야 한다. - 여러 사람이 결과물을 함께 검토하고 최선의 방향을 논쟁하는 과정이 품질을 높인다. - 협업은 단순한 업무 분담이 아니라 판단 기준을 공유하고 결과의 완성도를 높이는 방식이다. ## 자동화 시대의 핵심 경쟁력은 ‘취향’ - AI로 누구나 빠르게 많은 결과물을 만들 수 있게 되면서 결과물의 양 자체는 차별점이 되기 어렵다. - 무엇이 좋은지 판단하고, 불필요하거나 수준 낮은 결과를 과감히 제거하는 편집 능력이 중요해진다. - 한동안 낮은 품질의 디자인이 많아질 수 있지만, 뛰어난 작업은 결국 드러난다는 전망이 제시된다. - 창작자의 상상력, 판단력, 편집 능력은 자동화하기 어려운 인간 고유의 역량으로 남는다. ## 인간 중심 디자인과 세부 완성도 - 도구 자체를 따라가기보다 최종 사용자인 인간을 중심에 두어야 한다. - 디자인은 고객에게 기업이 얼마나 세심하게 신경 썼는지를 보여주는 수단이다. - 작은 세부 사항까지 정교하게 다듬으면 고객에게 논리적 만족을 넘어 감정적 반응을 이끌어낼 수 있다. - AI 시대에도 인간을 이해하고 배려하는 태도와 세심한 품질 관리가 중요하다. AI를 활용할 때는 속도와 생산성만 추구하기보다, 실험·협업·비판적 검토를 함께 운영하는 것이 바람직하다. 특히 팀은 AI가 만든 결과를 그대로 받아들이지 말고, 인간의 취향과 판단력으로 선별하고 다듬는 체계를 갖춰야 한다.

figma

워크플로우 랩: Figma Make로 디자인을 직접 배포하기 | Figma 블로그 (새 탭에서 열림)

디자인과 개발의 핸드오프는 일방향일 필요가 없으며, 디자이너가 Figma Make에서 실제 코드베이스를 직접 수정하고 PR까지 이어지는 작업 흐름을 제안한다. 작은 접근성·사용성 개선을 티켓과 백로그에 맡기지 않고 디자이너가 직접 처리하면, 엔지니어는 대규모 아키텍처 작업에 집중하면서도 제품의 완성도를 높일 수 있다. Figma Design, Figma Make, Figma agent, GitHub 연동을 활용해 캔버스에서 검토하고 코드로 반영하는 것이 핵심이다. ## 작은 개선이 백로그에 묻히는 문제 - “간격을 조금 줄여 달라”거나 “스크린 리더가 잘못 읽는다”와 같은 수정은 중요하지만 규모가 작아 우선순위 경쟁에서 밀리기 쉽다. - 디자이너가 요구사항을 티켓으로 작성하면 엔지니어가 의도를 해석해야 하므로, 스크린샷과 설명을 주고받는 과정에서 디자인의 뉘앙스가 손실된다. - 그 결과 엔지니어는 실제 구현보다 디자이너의 결정을 번역하는 데 시간을 쓰게 된다. - 글에서는 이러한 문제를 해결하기 위해 디자이너가 저위험·고완성도 작업을 처음부터 끝까지 맡는 방식을 제안한다. ## MOSF 웹사이트의 접근성 개선 사례 - 가상의 박물관인 ‘Museum of Speculative Futures(MOSF)’가 사례로 등장한다. - 엔지니어는 대규모 정보 구조 재작성에 집중해야 하고, 디자이너는 웹사이트의 접근성 문제를 해결하려 한다. - PM은 엔지니어가 구조 개편 같은 고난도 작업을 계속 담당하고, 디자이너가 세부적인 접근성·사용성 개선을 직접 처리하도록 역할을 나눈다. - 목표는 기술적으로 동작하는 수준을 넘어, 다양한 사용자가 실제로 편리하게 사용할 수 있는 웹사이트를 만드는 것이다. ## 캔버스에서 사용자 피드백 수집 - 디자이너는 수정 전에 현재 경험을 점검하기 위해 Figma Design의 Figma agent를 사용한다. - 첫 방문자, 재방문 회원, 스크린 리더 사용자 등 여러 합성 페르소나를 생성하고 사이트를 탐색하게 한다. - 합성 페르소나는 실제 사용자 조사나 대면 테스트를 대체하지 않지만, 초기에 명백한 마찰을 발견해 후속 사용자 조사에 집중할 여지를 만든다. - 탐색 결과 다음과 같은 문제가 확인된다. - 전시 페이지의 내비게이션 라벨이 모호함 - 주요 행동 유도 버튼(CTA)이 눈에 잘 띄지 않음 - 날짜 선택기가 한눈에 이해하기 어려움 - 검색 결과가 없을 때 빈 화면만 표시됨 - 각각은 대규모 기능 변경은 아니지만, 여러 문제가 누적되면 사이트의 접근성과 사용성이 크게 떨어질 수 있다. ## 팀 검토를 거친 디자인 수정 - 디자이너는 에이전트가 발견한 문제를 바탕으로 디자인을 수정한다. - 이후 디자이너, 엔지니어, PM이 캔버스에서 변경 사항을 함께 검토한다. - 검토 대상에는 방문 페이지의 더 명확한 라벨, 눈에 잘 띄는 CTA, 사용하기 쉬운 날짜 선택기 등이 포함된다. - 디자인 단계에서 팀의 합의를 먼저 확보하므로, 코드 수정 이후에 요구사항을 다시 해석하거나 되돌리는 일을 줄일 수 있다. ## Figma Make로 실제 코드에서 작업 - 디자이너는 프로덕션 코드와 연결된 Figma Make를 사용해 캔버스의 수정 사항을 실제 코드에 반영한다. - 기존처럼 티켓을 생성해 백로그에 넣고 엔지니어가 나중에 구현하기를 기다리지 않는 것이 핵심이다. - Figma Make, GitHub 연동, 주석과 리뷰 기능을 통해 디자인 변경을 코드 변경으로 연결하고 팀 검토를 이어간다. - 최종적으로 작업은 풀 리퀘스트(PR) 단계까지 진행되며, 디자이너가 캔버스에서 시작한 개선을 병합 가능한 코드 변경으로 전달한다. - 이 방식은 엔지니어의 책임을 없애는 것이 아니라, 엔지니어가 코드 품질과 구조를 검토하는 동안 디자이너가 세부적인 사용자 경험 개선을 주도하도록 역할을 재배치한다. 작은 접근성·사용성 개선은 별도 티켓으로 쌓아두기보다, 디자이너가 실제 코드에서 직접 수정하고 엔지니어와 PR 리뷰를 진행하는 편이 효율적이다. 다만 합성 페르소나의 결과는 초기 탐색용으로 활용하고, 중요한 접근성 판단은 실제 사용자 조사와 기술 검증으로 보완하는 것이 바람직하다.

figma

Decagon이 AI를 활용해 디자인 시스템을 포화시키는 방법 | Figma 블로그 (새 탭에서 열림)

Decagon은 빠르게 성장하는 AI 고객지원 플랫폼의 품질과 개발 속도를 함께 확보하기 위해 Deco라는 디자인 시스템을 구축했다. Figma 라이브러리, Storybook, 코딩 에이전트, Figma MCP를 연결해 디자인과 코드가 지속적으로 일치하도록 만들었고, 그 결과 반복적인 해석과 수정 작업을 줄였다. 핵심은 디자인 시스템을 단순한 컴포넌트 모음이 아니라 사람과 AI 에이전트가 함께 사용하는 공통 언어로 만든 데 있다. ## 빠른 성장에 대응하는 디자인 시스템 구축 - Decagon은 초기에는 디자인 시스템 없이 빠르게 제품을 개발했지만, 플랫폼과 팀이 커지면서 화면 간 불일치와 완성도 저하가 나타났다. - 기업 고객을 대상으로 제품을 제공하기 위해서는 일관된 UI와 높은 품질이 필요했으며, 디자인과 개발 사이의 반복적인 수정 작업도 줄여야 했다. - 디자이너와 엔지니어가 처음부터 함께 Deco를 설계해 다음과 같은 세부 사항을 미리 정의했다. - 포커스 상태 - 비활성화, 읽기 전용, 오류, 경고 상태 - 플레이스홀더 사용 여부 - 기존 코드에 이미 존재하는 컴포넌트와의 관계 - 현재 Deco는 수백 개의 컴포넌트·스타일·변수를 포함하며, 여러 팀과 제품 영역의 대부분의 사용 사례를 다룬다. - Figma 라이브러리에서 30일 동안 수만 건의 컴포넌트 삽입이 발생해 조직 전반에서 실제로 활용되고 있음을 확인했다. ## 디자인 시스템이 만든 공통 언어 - 디자이너는 기존 컴포넌트로 화면을 조합할 수 있어 매번 UI를 처음부터 만들 필요가 없어졌다. - 개발자는 어떤 버튼이나 테이블을 사용해야 하는지 명확히 알 수 있어 구현상의 판단과 논쟁이 줄었다. - 디자인과 코드가 동일한 프리미티브를 기준으로 소통하면서 제품 흐름과 요구사항을 설명하기 쉬워졌다. - Deco는 조직 전체에 공개된 단일 진실 공급원(single source of truth)으로 작동해 빠른 출시와 일관된 디자인을 동시에 지원한다. ## 디자인과 코드 사이의 반복 작업 줄이기 - 기존 방식에서는 디자이너가 명세를 전달하면 개발자가 해석하고, 리뷰 단계에서 불일치를 발견한 뒤 다시 수정하는 과정이 반복됐다. - 코딩 에이전트는 개발자처럼 암묵적인 의도를 추론하지 않고 제공된 정보만 바탕으로 작업하므로, 디자인 파일과 명세가 불명확하거나 일관되지 않으면 결과물도 부정확해진다. - Decagon은 디자인 시스템 컴포넌트를 Storybook으로 옮겨 코드에서도 동일한 컴포넌트를 확인할 수 있게 했다. - 코딩 에이전트가 구현할 때 정확한 Deco 컴포넌트를 사용하도록 별도의 skill을 만들었다. - 디자이너가 새로운 컴포넌트를 추가할 때 사용하는 skill도 구축해 Figma와 코드의 동기화를 유지했다. ## Figma MCP를 통한 에이전트 활용 - Figma MCP를 사용하면 코딩 에이전트가 Figma의 디자인 문맥과 명세를 직접 읽을 수 있다. - 디자이너는 Figma 링크를 코딩 에이전트에 전달하는 것만으로 다음 작업을 수행할 수 있다. - 디자인의 구조와 세부 명세 파악 - Deco의 적합한 컴포넌트와 매핑 - 디자인에 가까운 고충실도 구현 생성 - 디자인 캔버스, 코드, 컴포넌트 명세가 하나의 작업 흐름으로 연결되어 파일을 내보내고 다시 해석하는 수동 왕복이 줄었다. - 에이전트가 기존 디자인 시스템을 활용하므로 빠른 프로토타이핑과 반복 수정이 가능하면서도 브랜드와 UI 일관성을 유지할 수 있다. ## 실용적인 결론 AI 코딩 도구를 도입할 때는 에이전트의 성능만 높이기보다, 먼저 재사용 가능한 디자인 시스템과 명확한 컴포넌트 문맥을 마련해야 한다. Figma와 Storybook을 연결하고, MCP와 에이전트 skill을 통해 동일한 컴포넌트를 사용하게 하면 디자인-개발 간 불일치를 줄이면서 빠른 개발 속도와 품질을 함께 확보할 수 있다.

figma

GPT-5.6이 이제 Figma Make에서 사용 가능합니다 | Figma 블로그 (새 탭에서 열림)

GPT-5.6이 Figma Make에 추가되어 프롬프트에서 프로토타입과 코드로 전환하는 속도와 첫 결과물의 품질을 높인다. 복잡한 앱도 한 번의 프롬프트로 만들고, 오류가 발생하면 모델이 원인을 찾아 스스로 수정할 수 있다. 또한 기존 Figma 디자인을 높은 충실도로 인터랙티브 프로토타입으로 변환하며, 반응형 레이아웃과 실제 동작하는 상호작용까지 구현한다. ## 빠른 프로토타이핑과 작업 흐름 유지 - GPT-5.6은 아이디어를 working build로 빠르게 전환해 한 번의 작업 세션에서 여러 방향을 탐색할 수 있도록 한다. - 복잡한 디자인에서도 첫 결과물을 빠르게 생성하며, 토큰 효율성도 높다고 소개된다. - 예시로 금융·고딕 스타일의 주식 추적 앱을 한 번의 프롬프트로 제작했다. - 어두운 배경과 앰버·네온 오렌지 텍스트 - 샘플 주가와 수익률 정보 - 스파크라인, 티커, 모듈형 그리드 - 키보드 단축키와 검색 기능 - 빌드 중 오류가 발생해도 작업을 중단하지 않고 원인을 조사해 자체적으로 수정한다. - 실제 테스트에서는 빈 화면이 나타난 원인을 GPT-5.6이 찾아 해결했다. ## 기존 디자인을 충실하게 구현 - Figma Design 파일이나 디자인 명세를 기반으로 기존 시각적 구조를 유지하면서 인터랙티브 프로토타입을 만들 수 있다. - 자연의 소리를 재생하는 오디오 플레이어 사례에서 다음 요소들이 원본 디자인과 유사하게 구현됐다. - 다중 트랙 타임라인 - 재생·일시정지·이전·다음 컨트롤 - 사운드 라이브러리와 아트워크 - 레이아웃, 시각적 계층, 간격, 비율, 스타일 - 정적인 디자인을 실제 동작하는 프로토타입으로 바꾸는 디자인-투-코드 작업을 보다 안정적으로 수행한다. - 오디오 파일 재생뿐 아니라 음악에 반응하는 셰이더 기반 이미지 왜곡 효과도 요청할 수 있다. ## 높은 완성도의 첫 결과물 - 최소한의 프롬프트만으로도 스타일이 정돈된 프로토타입을 생성하는 것이 목표다. - 책장 제품을 판매하는 콘텐츠 중심의 이커머스 페이지 사례에서는 다음 기능이 첫 결과물에 포함됐다. - 제품 설명, 치수, 관리 가이드 - 제품 정보가 채워진 드롭다운 - 책장 사진을 탐색하는 인터랙티브 이미지 갤러리 - 클릭 가능한 메뉴 - 별도의 추가 지시 없이도 화면 크기에 따라 레이아웃이 안정적으로 조정됐다. - 따라서 초기 결과물을 단순한 시안이 아니라 팀이 검토·수정·확장할 수 있는 출발점으로 활용할 수 있다. ## Figma Make에서의 사용 방법 - GPT-5.6은 Figma Make에서 제공된다. - Make의 모델 선택기에서 GPT-5.6을 선택해 사용할 수 있다. - 사용자는 거친 아이디어, 기존 Figma 디자인, 짧은 기능 설명 등을 입력해 프로토타입이나 생산 코드에 가까운 결과물을 생성할 수 있다. 실무에서는 먼저 기존 디자인이나 원하는 사용자 경험을 구체적으로 제공하고, 생성된 첫 결과물을 기반으로 세부 기능과 스타일을 반복 수정하는 방식이 효과적이다. 특히 반응형 동작, 실제 인터랙션, 오류 자동 수정 기능을 활용하면 초기 프로토타입 제작과 팀 리뷰까지의 시간을 줄일 수 있다.

figma

AI 시대에 디자인 팀을 이끄는 방법 | Figma 블로그 (새 탭에서 열림)

AI 시대의 디자인 리더에게 필요한 것은 무조건적인 속도가 아니라, 팀이 침착하게 판단하고 실험하도록 돕는 안정감이다. Jen Dunnam은 도구와 유행을 좇기보다 인간을 위한 디자인이라는 원칙을 유지하고, 비판적 사고와 다양한 경험을 가진 인재를 채용해야 한다고 강조한다. 결론적으로 리더는 긴박감을 더하기보다 팀이 올바른 문제를 정의하고 현명하게 실행하도록 방향을 잡아야 한다. ## 변화 속에서도 침착하게 이끌기 - AI의 발전으로 업계에 불안과 긴박감이 커졌지만, 뛰어난 디자이너들은 이미 충분한 추진력을 갖고 있다. - 리더의 역할은 위기감을 더하는 것이 아니라 팀을 안정시키는 데 있다. - 문제를 작은 단위로 나누고, 전략을 세우며, 적절한 도구를 실험하고, 디자인 원칙을 다듬어야 한다. - AI 도구의 기능이나 유행을 무작정 따라가기보다 디자이너이자 인간으로서 본질에 집중해야 한다. - 기술은 바뀌어도 디자인의 대상은 여전히 인간이므로, 사용자에 대한 이해와 인간 중심 원칙은 변하지 않는다. - 가장 현실적인 접근은 꾸준히 실험하되, 결과를 학습하고 원칙에 따라 판단하는 것이다. ## 비판적 사고를 기준으로 채용하기 - 빠른 제품 출시가 강조되면서 신입 디자이너와 졸업생이 기회를 얻기 어려워졌으므로, 이들의 성장 가능성에 투자할 필요가 있다. - 신입 인재를 제품 출시 경험이 풍부한 시니어와 짝지으면 새로운 관점과 실행력을 결합할 수 있다. - 사용자 연구자 중에서도 인사이트를 수집하는 데 그치지 않고, 디자인과 제품 방향에 대해 결단력 있게 의견을 낼 수 있는 사람을 찾는 것이 유효하다. - 현재 채용에서 특히 가치가 높아진 역량은 비판적 사고다. - 면접에서는 단순히 결과물을 확인하기보다 다음과 같은 경험을 깊이 물어야 한다. - 언제 자신의 의견에 반대했는가? - 이해관계자에게 어떻게 이의를 제기했는가? - 제품에 반영되지 않아 지금도 아쉬운 점은 무엇인가? - AI가 만들어낸 결과물은 시각적으로 매력적이고 그럴듯해 보일 수 있다. 따라서 ‘반짝이는 결과’나 그럴듯한 답을 그대로 받아들이지 않고, 문제와 결과를 검증하는 태도가 중요하다. ## 실용적인 결론 디자인 팀은 AI 도구를 빠르게 익히되, 도구 자체를 목표로 삼아서는 안 된다. 리더는 팀이 인간 중심 원칙을 잃지 않으면서 실험하고, 근거를 바탕으로 반대 의견을 내며, 빠른 실행과 깊이 있는 판단을 함께 발전시키도록 지원해야 한다.