swiftui

8 개의 포스트

toss4분 읽기큐레이션 요약

디자이너가 시안 대신 앱을 만든 이유

AI를 활용하면 디자이너가 정적인 시안을 넘어 실제로 동작하는 프로토타입을 직접 만들 수 있고, 디자인과 개발 사이의 번역 과정도 줄어든다. 토스의 underlay 프로젝트는 화면 위에 겹치는 대신 화면 아래에 있던 정보가 드러나는 방식을 통해, 사용자의 흐름을 방해하지 않고 다음 경험으로 연결하려 했다. 이 과정에서 동작하는 코드 자체가 디자인 명세이자 개발 가능한 구조가 될 수 있음을 보여준다. ## 데드엔드를 다음 경험의 시작으로 바꾸기 - 송금 완료나 결제 완료처럼 사용자의 할 일이 끝나는 화면을 ‘데드엔드’로 정의했다. - 목표는 특정 화면을 개선하는 것이 아니라, 앱 어디서든 현재 경험을 자연스럽게 다음 경험으로 연결하는 공통 장치를 만드는 것이었다. - 이를 위해 여러 화면에서 재사용할 수 있는 컴포넌트 개발부터 시작했다. ## 기존 알림 UI의 한계와 underlay의 발상 - 바텀시트, 토스트, 푸시 등 기존 UI는 화면 위에 나타나 사용자의 시선을 끌지만, 보고 있던 화면이나 진행 중인 행동을 방해할 수 있다. - 전화처럼 등장하거나 화면 한쪽·채팅창처럼 나타나는 방식도 같은 문제를 가졌다. - 택배 송장을 떼자 아래에 있던 책의 문구가 드러난 경험에서 아이디어를 얻었다. - 새로운 정보를 화면 위에 올리는 대신, 화면 아래에 존재하던 정보가 드러나게 하는 컴포넌트를 **underlay**라고 정의했다. ## AI와 코드로 인터랙션을 디자인하기 - underlay는 외형보다 움직임과 반응 방식이 중요한 컴포넌트였다. 인터랙션 자체가 디자인의 핵심이었다. - 프로토파이나 프레이머 대신 SwiftUI와 Xcode로 iOS 앱 형태의 프로토타입을 직접 만들었다. - SwiftUI를 처음 사용했지만 AI에게 구현을 요청하며 디자인을 구체화했다. - 디자이너의 역할은 다음 세 가지로 정리됐다. - 만들고 싶은 경험을 설명하기 - AI가 제안한 여러 방향 중 적절한 것을 선택하기 - 실제 기기에서 결과를 보고 판단하기 - AI와의 디자인 과정은 설계, 선택, 검증을 반복하는 과정이었다. ## 실제 기기에서 반복하며 완성도 높이기 - 먼저 자유롭게 실험하고 지울 수 있는 플레이그라운드 환경을 만들고, 피그마 시안을 AI에게 참고 자료로 제공했다. - 버튼, 텍스트, 레이아웃을 정지 화면이 아니라 실제 기기에서 움직여 보며 수정했다. - 상상한 움직임과 실제 구현된 움직임의 차이가 컸기 때문에 수백 번 반복해서 조정했다. - 화면의 맥락을 읽고 적절한 정보를 찾는 느낌을 표현하기 위해 빛이 화면을 훑는 스캔 인터랙션을 도입했다. - 빛의 번짐, 틴트, 폭, 속도, 배경 어두워짐 등은 Metal 셰이더로 구현했다. - AI가 작성한 셰이더 코드를 출발점으로 삼되, 최종 질감은 직접 수치를 조정하며 완성했다. - 등장하거나 스캔이 지나갈 때의 미세한 출렁임 같은 디테일도 코드로 다듬었다. ## 디자인 가이드 대신 동작하는 레포 전달하기 - 기존 방식이라면 등장 타이밍, 이징 커브, 딜레이 등을 문서로 정리했을 것이다. - 이번에는 간단한 플로우만 설명하고, 직접 만든 코드 레포를 개발자에게 전달했다. - 동작하는 레퍼런스가 있었기 때문에 개발자는 시안의 구조와 인터랙션을 빠르게 이해할 수 있었다. - 개발 과정의 파인튜닝에서도 opacity나 모션 값을 말로 주고받기보다, 디자이너가 직접 실행 결과를 보며 수정했다. - AI에게 원하는 모션을 자연어로 설명하고 결과를 확인하는 과정을 개발자의 환경에서도 반복하면서 인터랙션 완성도를 높였다. - “느낌이 이상하다”는 추상적 표현 대신 실제 코드와 동작을 기준으로 소통할 수 있었다. ## 시각적 결과뿐 아니라 코드 구조까지 디자인하기 - 프로토타입 레포의 구조가 실제 iOS 개발 코드와 거의 동일하게 활용됐다. - 처음부터 개발을 위한 구조를 의도한 것은 아니었지만, UT와 빠른 버전 변경을 위해 만든 구조가 자연스럽게 개발 가능한 형태가 됐다. - 잘 만든 시안은 보기 좋은 화면에 그치지 않고, 재사용·수정·확장이 가능한 방식으로 만들어져야 한다. - 일회용 코드라면 개발자가 다시 구현해야 하지만, 개발 가능한 구조의 시안은 그대로 구현 명세가 될 수 있다. - AI가 “어떻게 만들지”를 지원하는 시대에는 디자이너가 “무엇을 만들지” 상상하고 결정하는 역량이 더 중요해진다. ## 적용 방법 - 도구의 제약에 맞춰 디자인하기보다, 가장 좋은 사용자 경험을 먼저 상상한다. - 정적인 그림으로 끝내지 말고 AI와 코드를 활용해 실제 기기에서 작동하는 프로토타입을 만든다. - 인터랙션을 문서로만 설명하기보다, 직접 만든 동작하는 레포를 개발자에게 전달한다. - 최종 결과뿐 아니라 코드 구조와 수정 가능성까지 디자인의 일부로 고려한다. 실용적으로는 작은 인터랙션부터 SwiftUI나 웹 기술로 직접 구현해 보고, 실제 기기에서 반복 검증하는 방식이 효과적이다. 완성된 코드는 단순한 시안이 아니라 개발자와 AI 모두가 이해할 수 있는 실행 가능한 디자인 스펙이 될 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

더블 클릭: 코딩이

AI와 대화하며 코드를 생성·수정하는 ‘바이브 코딩’은 프로그래밍을 문법 작성보다 아이디어 표현과 반복 대화에 가깝게 만든다. 덕분에 코딩 경험이 없는 사람도 빠르게 프로토타입과 사이드 프로젝트를 만들 수 있지만, 프로젝트가 복잡해지면 일관성 없는 데이터 모델과 스파게티 코드라는 한계에 부딪힌다. 따라서 바이브 코딩은 완성도 높은 소프트웨어 개발 전체를 대체하기보다, 초기 탐색과 실험을 가속하는 방식으로 보는 것이 적절하다. ## 대화형 프로그래밍으로의 변화 - 바이브 코딩은 원하는 기능을 자연어로 설명하고, AI가 코드를 작성하면 실행 결과를 확인한 뒤 다시 대화로 수정하는 개발 방식이다. - 개발자는 코드를 한 줄씩 직접 작성하기보다 “보고, 말하고, 실행하고, 복사·붙여넣는” 흐름으로 결과를 만들어 간다. - Cursor Composer, Claude Sonnet, 음성 입력 도구인 SuperWhisper 같은 LLM 기반 도구의 성능 향상이 이러한 방식을 가능하게 했다. - 어셈블리에서 C, C에서 Python으로 추상화 수준이 높아졌던 것처럼, 바이브 코딩도 프로그래밍 추상화의 또 다른 단계로 볼 수 있다는 의견이 제시된다. ## 펀치카드에서 즉시 프로토타이핑까지 - 초기 컴퓨팅에서는 명령 하나를 펀치카드에 기록하고, 실행 결과를 보기까지 수 시간 또는 수일을 기다려야 했다. - 이후 직접 코드를 입력할 수 있게 되었지만, 아이디어를 실제 인터랙티브 결과물로 바꾸는 과정은 여전히 개발자에게 큰 장벽이었다. - 바이브 코딩은 이 간극을 줄여 아이디어를 빠르게 표현하고 반복적으로 실험하게 한다. - Figma의 디자이너 Nikolas Klein은 이를 “코딩 자체보다 인터랙티브 아이디어를 더 빠르고 쉽게 표현하는 방법”으로 본다. - Val Town의 Charmaine Lee는 문서에 낙서하거나 Google Sheet를 만드는 것처럼 코드를 가볍게 실험할 수 있다는 점을 강조한다. ## 코딩을 하지 않는 사용자도 소프트웨어를 만든다 - 바이브 코딩은 전문 개발자뿐 아니라 코드를 전혀 작성하지 않는 사람에게도 소프트웨어 제작 기회를 넓힌다. - Replit CEO Amjad Masad에 따르면 Replit 고객의 75%는 코드 한 줄도 직접 작성하지 않는다. - Figma 구성원들은 SwiftUI를 몰라도 러닝 코치 앱이나 TikTok 스타일의 Wikipedia 앱 로딩 애니메이션 같은 프로젝트를 만들 수 있었다. - 특히 사이드 프로젝트, 인터랙션 실험, 디자인 프로토타입처럼 빠른 시도가 중요한 작업에서 효과가 크다. ## 복잡해질수록 드러나는 한계 - 바이브 코딩은 프로젝트 초반에는 매우 빠르고 즐겁지만, 기능과 코드 규모가 커지면 AI의 대응 품질이 떨어진다. - 처음에는 원하는 결과의 약 80%까지 빠르게 도달할 수 있지만, 나머지 20%를 완성하는 과정에서 어려움이 커진다. - AI가 생성한 코드가 기능별로는 작동해도 전체적으로 일관된 내부 데이터 모델을 갖추지 못할 수 있다. - 결과적으로 구조를 이해하기 어렵고 유지보수하기 힘든 스파게티 코드가 쌓일 위험이 있다. - 따라서 복잡한 프로젝트에서는 아키텍처 설계, 데이터 모델 검토, 테스트와 리팩터링 등 전통적인 개발 역량이 여전히 필요하다. ## 실용적인 활용 방향 - 바이브 코딩은 아이디어 검증, 초기 프로토타입, 개인 프로젝트, UI·인터랙션 실험에 적극 활용할 만하다. - 운영 환경에 배포하거나 장기 유지보수할 코드는 생성 결과를 그대로 사용하지 말고, 개발자가 구조·보안·성능·테스트를 검토해야 한다. - 가장 현실적인 접근은 AI에게 구현을 맡기되, 사람이 요구사항과 설계 방향을 통제하고 결과물을 지속적으로 정리하는 방식이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

개발 모드와 함께한

Figma Dev Mode를 1년간 도입한 Decathlon의 경험에 따르면, 이 도구는 디자인과 개발 사이의 협업을 크게 개선할 수 있다. 특히 Code Connect를 활용하면 Figma 컴포넌트와 실제 코드 간의 속성, 명명 규칙, 상태를 직접 연결할 수 있어 디자인 시스템 운영이 정교해진다. 다만 기존 업무 방식을 한 번에 바꾸기보다 작은 성공 사례부터 시작하고, 명확한 문서화와 완료 기준을 마련하는 것이 중요하다. ## 디자인과 코드의 연결: Code Connect - Dev Mode의 가장 큰 효과는 Figma 컴포넌트를 실제 컴포넌트 코드와 연결하는 **Code Connect**에서 나타났다. - 디자인과 코드에서 컴포넌트 구조가 다르더라도 다음 문제를 조정하는 데 도움이 된다. - 속성 및 프로퍼티 정렬 - 컴포넌트 이름 규칙 통일 - 상태 관리 방식 일치 - 디자인 토큰을 Figma에서 명확히 표현하면 개발자가 시각적 의사결정을 코드 수준에서 이해하기 쉬워진다. - 색상 값과 토큰 이름을 연결하면 디자인 토큰 변경 사항이 대응하는 코드 변경으로 즉시 이어진다. ## 작게 시작하고 확장하기 - 개발자에게 새로운 도구는 기존 업무 흐름을 방해할 수 있으므로, Dev Mode를 전면 도입하기보다 작은 범위에서 시작했다. - 초기에는 Figma Variables를 활용한 디자인 토큰 관리처럼 빠르게 효과를 확인할 수 있는 영역에 집중했다. - **변수 별칭(variable aliasing)**을 사용하면 원시 토큰과 의미론적 토큰 사이에 계층을 만들 수 있다. - 테마 구현이 쉬워진다. - 팀원이 토큰 체계를 이해하고 적용하기 쉬워진다. - 변수 스코핑을 설정하면 특정 변수가 적용될 수 있는 속성을 제한할 수 있다. - 배경색을 텍스트 색상에 사용하는 실수 방지 - 간격 값을 테두리 반경에 사용하는 잘못된 적용 방지 - 변수의 코드 표기법을 플랫폼별 개발자 명명 규칙에 맞게 사용자 지정할 수 있다. ## 고급 검사 기능으로 레이아웃 확인 - Dev Mode는 복잡한 UI 레이아웃과 Flexbox 기반 구조를 검사하고 구현 가능한 코드로 확인하는 데 유용하다. - 개발자는 다음 플랫폼의 구현 속성을 직접 살펴볼 수 있다. - 웹 CSS - iOS의 SwiftUI와 UIKit - Android의 XML과 Compose - 디자이너와 디자인 시스템 담당자는 컴포넌트가 요구사항에 맞게 구현될 수 있는지 구체적으로 검증할 수 있다. - Figma VS Code 확장을 이용하면 CSS, Compose, SwiftUI 코드 탐색과 자동완성을 IDE 안에서 처리할 수 있다. - 결과적으로 디자인 파일을 별도로 해석해 코드를 작성하는 부담이 줄어든다. ## 완료 기준과 문서화 통일 - 디자인 시스템 문서는 지속적으로 최신 상태를 유지하기 어렵고, 디자인 의도나 세부 요구사항이 개발 과정에서 누락되기 쉽다. - Dev Mode의 문서화 및 주석 기능을 사용하면 디자인 파일 안에 필요한 정보를 직접 남길 수 있다. - 주석에는 다음 내용을 포함할 수 있다. - 자유로운 설명 문장 - 정렬 및 크기 같은 명시적 값 - 간격과 치수를 보여주는 측정 정보 - 디자이너는 개발자에게 특정 주석을 직접 연결해 의도와 구현 조건을 명확히 전달할 수 있다. - 팀에서는 각 컴포넌트에 다음 자료를 함께 연결하는 문서화 체계를 구축했다. - GitHub 소스 코드 - README - 관련 플레이그라운드 - 이를 통해 “디자인 완료”와 “개발 완료”의 기준을 팀 전체가 같은 방식으로 이해할 수 있다. ## 적용 시 권장 방식 - Dev Mode를 도입할 때는 기존 개발 프로세스를 즉시 대체하기보다 디자인 토큰이나 변수처럼 효과가 명확한 영역부터 시작하는 것이 좋다. - 토큰 계층, 변수 스코핑, 코드 명명 규칙을 먼저 정리하면 이후 Code Connect와 컴포넌트 문서화의 효과가 커진다. - 검사 기능만 사용하는 데 그치지 말고, 주석·소스 코드·README·플레이그라운드를 연결해 디자인 시스템의 단일한 참고 지점을 만들어야 한다.

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

Datadog의 데이터 시각화를 iOS에 구현한 방법: 성능 최적화에 집중하며 (새 탭에서 열림)

Datadog은 복잡한 데이터 시각화를 iOS 모바일 앱에 네이티브로 구현하기 위해 자체 SwiftUI 기반 그래프 라이브러리인 'DogGraphs'를 개발했습니다. iOS 14 호환성을 유지해야 하는 제약 속에서 성능 병목을 해결하기 위해 SwiftUI의 렌더링 파이프라인과 디핑(Diffing) 메커니즘을 심도 있게 분석하고 최적화했습니다. 그 결과, 다양한 제품군에서 빠르고 유연하게 동작하며 컴파일 타임에 타입 안정성까지 보장하는 선언형 그래프 프레임워크를 구축할 수 있었습니다. ### DogGraphs 개발 배경과 도전 과제 * **자체 라이브러리 필요성**: 개발 당시 Swift Charts 같은 공식 라이브러리가 없었으며, Datadog 특유의 복잡한 데이터 시각화 요구사항을 충족하기 위해 직접 개발을 결정했습니다. * **하위 호환성 제약**: iOS 14를 지원해야 했기에 성능 최적화에 유리한 최신 `Canvas` API를 사용할 수 없었고, 표준 SwiftUI 뷰 계층 구조만으로 고성능을 구현해야 했습니다. * **선언형 API 설계**: Swift의 Result Builder를 활용해 SwiftUI와 유사한 구문으로 복잡한 그래프를 정의할 수 있게 했으며, 서로 다른 유형의 그래프를 잘못 쌓는 등의 실수를 컴파일 타임에 방지하도록 설계했습니다. ### 성능 분석 및 프로파일링 도구 활용 * **_printChanges() 활용**: 뷰의 `body` 내에서 이 비공개 API를 호출하여 어떤 상태 변화가 불필요한 재렌더링을 유발하는지 로그로 확인하고 디버깅했습니다. * **Xcode Instruments**: 'SwiftUI View body evaluations'를 통해 뷰의 바디가 평가되는 횟수와 평균 소요 시간을 측정했으며, 'Time profiler'로 실행 시간이 긴 함수를 찾아 최적화했습니다. * **주요 측정 시나리오**: 초기 그래프 렌더링 시점, 툴팁 선택이나 레이어 토글 같은 상호작용 발생 시, 기기 회전 및 다크/라이트 모드 전환 시의 성능을 집중적으로 점검했습니다. ### SwiftUI 핵심 개념과 디핑(Diffing) 메커니즘 * **렌더링 원리 이해**: SwiftUI의 성능 최적화를 위해 Identity(정체성), Lifetime(생명주기), Dependencies(의존성)라는 세 가지 핵심 개념을 기반으로 뷰 업데이트 방식을 분석했습니다. * **비트 단위 비교**: SwiftUI는 뷰의 필드를 비트 단위로 비교(memcmp)하여 이전 값과 차이가 없으면 `body`를 다시 계산하지 않고 건너跳는 최적화 방식을 사용합니다. * **의존성 관리**: 불필요한 의존성 전파를 막고 뷰 구조를 효율적으로 설계함으로써, 데이터 변경 시 영향을 받는 뷰만 정확히 다시 그려지도록 유도했습니다. ### 실용적인 권장 사항 복잡한 SwiftUI 애플리케이션의 성능을 높이려면 단순히 최신 기능을 사용하는 것에 그치지 말고, **뷰의 정체성(Identity)과 의존성 관계를 명확히 정의**해야 합니다. 특히 대규모 데이터를 다루는 시각화 도구에서는 SwiftUI의 내부 디핑 엔진이 효율적으로 작동할 수 있도록 뷰 모델과 프로퍼티 구조를 최적화하고, Instruments를 통해 렌더링 비용을 주기적으로 측정하는 과정이 필수적입니다.

figma3분 읽기큐레이션 요약

디자인 시스템을 위한 올바

Code Connect는 Figma의 Dev Mode에서 자동 생성된 CSS 대신 조직의 실제 디자인 시스템 코드를 보여줘 디자인 시스템 도입률을 높이는 도구다. 개발자는 목업과 연결된 컴포넌트의 올바른 코드와 사용 지침을 바로 확인할 수 있어 구현 속도와 일관성이 향상된다. 결과적으로 잘못된 컴포넌트 사용과 중복된 일회성 컴포넌트의 생성·유지보수를 줄이는 것이 목표다. ## 디자인 시스템 도입이 어려운 이유 - 디자인 시스템을 구축해도 개발자가 시스템의 모든 컴포넌트와 패턴을 알지 못하는 경우가 많다. - 일부 컴포넌트를 사용하더라도 의도된 가이드라인과 다르게 적용할 수 있다. - 디자인 시스템의 성공은 단순히 사용 여부가 아니라, 올바르고 일관되게 사용하는지에 달려 있다. - 디자인과 코드는 서로 다른 도구와 제약을 가진 별개의 작업 영역으로 발전해 왔기 때문에 연결 지점이 부족했다. ## 디자인과 코드의 연결 - 디자인은 무엇을 만들지 탐색하고 결정하는 데 초점을 두며, 코드는 이를 구조적이고 유지보수 가능한 형태로 구현하는 데 초점을 둔다. - Figma는 두 영역이 원활하게 오갈 수 있어야 한다고 보고, Code Connect를 그 연결을 강화하는 기능으로 소개한다. - 기존의 Auto Layout, Variables, Component Props, Dev Mode 등의 기능과 함께 디자인 시스템을 코드에 더 가깝게 통합하려는 흐름에 속한다. - 디자인 시스템 팀이 작성한 실제 구현 방식과 문서를 디자인 목업의 맥락 안에서 제공한다. ## Code Connect의 핵심 기능 - Dev Mode에 표시되는 코드 스니펫을 조직의 실제 디자인 시스템 코드로 사용자 지정할 수 있다. - 자동 생성 CSS가 아니라 프로젝트에서 사용하는 컴포넌트, 속성, 패턴에 맞는 코드를 개발자에게 보여준다. - 개발자가 목업에서 특정 요소를 선택하면 관련 코드와 사용법을 별도의 문서 검색 없이 확인할 수 있도록 한다. - 올바른 구현 예시와 디자인 시스템 사용 원칙을 함께 제공해 오용을 줄인다. - 디자인 시스템의 재사용을 촉진해 중복 컴포넌트와 일회성 구현의 생성을 줄인다. ## 개발자 워크플로에 맞춘 설치 방식 - Code Connect는 개발자가 익숙한 패키지 및 명령줄 기반 방식으로 설치·설정할 수 있다. - JavaScript와 TypeScript 프로젝트에서는 **npm**을 사용한다. - SwiftUI 프로젝트에서는 **Swift Package Manager**를 지원한다. - 설치 패키지와 설정 방법은 GitHub 저장소에서 제공된다. - 향후 더 많은 플랫폼을 지원해 기존 개발 환경에 자연스럽게 통합하는 것을 목표로 한다. ## 기대 효과 - 개발자가 디자인 시스템 컴포넌트를 더 쉽게 발견하고 사용할 수 있다. - 디자인에서 코드로 전환하는 과정이 빨라지고 구현 효율이 높아진다. - 실제 코드와 디자인 간의 차이를 줄여 제품 전반의 UI 일관성을 높인다. - 디자인 시스템 팀의 문서화와 모범 사례를 개발 작업의 적절한 시점에 전달할 수 있다. - 결과적으로 조직 전체의 디자인 시스템 채택률과 유지보수성을 개선한다. Code Connect를 도입할 때는 자주 사용하는 컴포넌트부터 실제 프로덕션 코드와 연결하고, 각 컴포넌트의 올바른 사용 예시와 속성 매핑을 함께 관리하는 것이 효과적이다. Primitives나 자동 생성 코드보다 조직의 표준 컴포넌트가 우선 노출되도록 구성해야 도입 효과를 극대화할 수 있다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

디자인에서 코드로의 자동화를

Dev Mode의 코드 생성(codegen)은 디자인을 완성된 코드로 자동 변환하는 기능이라기보다, 개발자가 구현을 시작할 수 있도록 돕는 출발점이다. Figma는 기본 코드 스니펫을 제공하고, 팀의 디자인 시스템과 기술 스택에 맞춰 다양한 codegen 플러그인으로 확장할 수 있다고 설명한다. Anima, Builder, Figma to Code, Locofy.ai 같은 도구는 React·HTML·Tailwind부터 Flutter·SwiftUI까지 지원하며 반응형 구현과 컴포넌트화를 가속한다. ## Dev Mode와 codegen의 역할 - Codegen은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - Figma Dev Mode에서 캔버스의 객체를 선택하면 Inspect 패널에 자동 코드 스니펫이 표시된다. - 사용자는 코드 언어와 단위 체계를 드롭다운에서 선택할 수 있다. - codegen은 디자인을 개발로 옮기는 작업을 완전히 대체하기보다, 매번 빈 화면에서 시작하지 않도록 구현의 출발점을 제공한다. - 성숙한 디자인 시스템을 운영하는 팀은 자체 규칙과 컴포넌트를 반영하기 위해 custom codegen 플러그인을 만들 수 있다. ## Anima를 활용한 디자인 코드 변환 - Figma의 레이어·컴포넌트·프레임을 React 또는 HTML 코드로 내보낼 수 있다. - CSS, SCSS, Tailwind 형식의 스타일 코드와 함께 인터랙티브하고 반응형인 결과물을 생성한다. - 반복되는 컴포넌트를 자동으로 감지해 코드 중복을 줄인다. - 팀이 사용하는 코드 스타일과 관례를 학습해 더 적절한 코드 스니펫을 제공한다. - Dev Mode에서 애니메이션을 추가하거나 특정 스타일에 맞게 코드를 조정하도록 요청할 수 있다. ## Builder의 AI 기반 코드 컴포넌트 활용 - React, Svelte, HTML 등의 코드를 AI로 생성한다. - 팀의 기존 코드 컴포넌트를 활용해 디자인과 실제 구현 사이의 간극을 줄인다. - 생성된 코드에 대해 대화형으로 수정 사항을 요청할 수 있다. - 팀의 코드 스타일에 맞도록 AI를 학습시키고, 디자인을 자동으로 반응형으로 변환할 수 있다. - Figma 밖의 별도 웹 인터페이스에서 생성 코드를 시험하고 수정할 수 있다. ## Figma to Code로 웹·모바일 코드 생성 - Figma Community에서 제공되는 무료 오픈 소스 플러그인이다. - 반응형 웹을 위해 HTML 또는 Tailwind 코드를 생성한다. - 모바일 앱 개발을 위해 Flutter와 SwiftUI 코드도 지원한다. - 플러그인에서 생성된 Tailwind 코드를 확인한 뒤 코드 에디터로 복사해 사용할 수 있다. - 별도의 유료 도구 없이 디자인을 여러 플랫폼의 코드로 빠르게 변환할 수 있다는 점이 특징이다. ## Locofy.ai를 통한 웹·모바일 프로토타입 구현 - React, HTML/CSS, Next.js, Gatsby, Vue 기반의 인터랙티브 코드를 생성한다. - 개별 컴포넌트뿐 아니라 전체 화면 단위의 코드 생성도 지원한다. - 자동 레이아웃과 프레임 그룹화 같은 디자인 최적화를 적용한다. - 시맨틱 HTML 요소, 라이브러리, 동작을 태깅해 인터랙션을 구성한다. - 화면 크기에 따른 반응형 동작을 지원한다. - 컴포넌트와 props를 생성해 결과물을 모듈화한다. - 사람이 이해하기 쉬운 문맥 기반 클래스명을 사용해 협업과 확장성을 높인다. - 생성 코드를 다듬은 뒤 프로토타입을 공유하고, 데이터를 연결하며, 코드나 Storybook 파일로 내보낼 수 있다. - GitHub와 직접 동기화하고 자동 병합 및 충돌 해결을 지원해 지속적 통합 흐름에 연결할 수 있다. 실무에서는 생성된 코드를 최종 결과물로 그대로 사용하기보다, 팀의 디자인 시스템·컴포넌트 구조·접근성·상태 관리·성능 기준에 맞게 검토하고 수정하는 것이 좋다. codegen 플러그인은 반복적인 초기 구현을 줄이고 협업을 빠르게 만드는 보조 도구로 활용할 때 가장 효과적이다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

주목하고 좋아하게

피그마 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 사례 중간에서 끝나므로, 나머지 두 프로젝트의 구체적인 내용은 포함되어 있지 않다.

원문 읽기(새 탭에서 열림)
figma3분 읽기큐레이션 요약

오토 레이아웃

Figma의 Auto Layout은 자유로운 디자인 탐색과 HTML/CSS·SwiftUI 같은 개발 환경의 구조적 레이아웃 장점을 결합한 기능이다. 텍스트나 콘텐츠가 바뀌면 버튼과 주변 요소의 크기·위치가 자동으로 조정되어 반복적인 수작업을 줄인다. 또한 프레임 중첩을 통해 콘텐츠에 반응하는 복잡한 인터페이스와 재사용 가능한 컴포넌트를 만들 수 있다. ## 디자인과 개발 환경의 간극 - Figma의 기존 자유 배치 방식은 창의적인 탐색에는 유리하지만 반복 작업이 많았다. - 버튼 문구를 수정하려면 텍스트 편집, 버튼 크기 조정, 인접 버튼 이동을 각각 수행해야 했다. - HTML/CSS나 SwiftUI는 객체 간 구조와 관계를 표현하므로 콘텐츠 변경에 강하지만, 자유로운 시각적 실험에는 불편하다. - Auto Layout은 CSS 박스 모델, 특히 flexbox의 핵심 개념을 Figma에 도입해 두 환경의 장점을 결합했다. - 프레임의 속성으로 제공되므로 컴포넌트뿐 아니라 일반 프레임에도 적용할 수 있다. ## 콘텐츠에 따라 자동으로 변하는 레이아웃 - Auto Layout을 적용하면 내부 요소가 가로 또는 세로 방향으로 순서대로 배치된다. - 컨테이너의 크기는 내부 요소들의 전체 크기에 맞춰 자동으로 결정된다. - 프레임 자체에 패딩, 채우기, 선, 모서리 반경을 설정할 수 있어 버튼 제작에 별도 레이어가 필요하지 않다. - “Buy”를 “Add to basket”으로 변경하면 버튼이 텍스트 길이에 맞춰 자동으로 늘어난다. - 인접한 버튼이나 요소도 레이아웃 흐름에 맞춰 함께 이동한다. - 요소 간 간격은 개별 요소가 아니라 컨테이너 수준에서 설정된다. 특정 요소 사이만 다르게 조정하려면 추가 작업이 필요하다. ## 리스트와 메뉴의 자동 재정렬 - 반복되는 UI 요소를 배치하는 리스트와 메뉴 제작에 특히 유용하다. - 요소를 드래그해 순서를 바꾸면 나머지 요소가 자동으로 재배치된다. - 항목을 하나씩 올바른 위치로 옮기던 반복적인 클릭 작업을 줄일 수 있다. - 기존 컴포넌트 라이브러리와 디자인 시스템에도 적용할 수 있으며, `Shift + A` 또는 옵션 메뉴에서 활성화할 수 있다. ## 중첩 프레임으로 복잡한 인터페이스 구성 - 여러 Auto Layout 프레임을 HTML의 중첩된 `div`처럼 조합할 수 있다. - 버튼, 카드, 리스트, 화면 전체를 계층적으로 구성하면서 각 영역이 콘텐츠 변화에 반응하도록 만들 수 있다. - 콘텐츠를 수정하거나 요소를 다른 Auto Layout 프레임 안팎으로 이동하기 쉽다. - 의도하지 않은 배치를 막기 위해 큰 이미지를 버튼 안에 넣는 등의 작업에는 안전장치가 작동한다. - 실제로 원하는 작업이라면 macOS에서는 `Command`, Windows에서는 `Ctrl` 키를 눌러 안전장치를 무시할 수 있다. - 콘텐츠 변형마다 별도 컴포넌트를 만들기보다, 다양한 콘텐츠를 수용하는 범용 컴포넌트를 제작할 수 있다. ## 향후 발전 방향 - Figma는 Auto Layout을 첫 출시로 보고, 향후 더 많은 기능을 추가할 계획이라고 밝혔다. - 사용자는 플레이그라운드 파일, 동영상, 공식 문서를 통해 기능을 학습할 수 있다. - 기능 사용 후 피드백과 개선 요청을 공유하도록 독려했다. 실무에서는 텍스트 길이가 달라지는 버튼, 반복 목록, 카드와 메뉴처럼 콘텐츠 변화가 잦은 UI부터 Auto Layout을 적용하는 것이 효과적이다. 이후 프레임을 중첩해 디자인 시스템 전반을 반응형이고 재사용 가능한 구조로 확장할 수 있다.

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