code-snippets

3 개의 포스트

figma

Forrester가 분석한 Dev Mode의 (새 탭에서 열림)

Figma의 Dev Mode는 디자인-개발 간 핸드오프와 반복적인 확인 작업을 줄여 개발자의 생산성과 출시 속도를 높인다는 내용이다. Forrester는 이를 바탕으로 3년간 개발자 생산성이 20~30% 향상되고, 개발자 1인당 매주 90분 이상을 절약할 수 있다고 분석했다. 복합 기업 모델에서는 약 1,000만 달러의 시간 절감 효과와 출시 기간 단축으로 인한 200만 달러의 추가 이익을 추정했다. ## Forrester의 분석 범위와 방법 - Figma는 Dev Mode 출시 2년 후 경제적 효과를 검증하기 위해 Forrester Consulting에 연구를 의뢰했다. - Forrester의 **Total Economic Impact(TEI)** 방법론을 활용했다. - Dev Mode를 사용하는 조직의 의사결정자 4명을 인터뷰했다. - 인터뷰 결과를 바탕으로 디자이너와 개발자 100~1,000명 규모의 복합 조직을 모델링했다. - 분석 대상의 핵심 문제는 다음과 같다. - 비효율적인 디자인-개발 핸드오프 - 디자인 의도 확인을 위한 반복적인 커뮤니케이션 - 중복 작업과 문서 탐색 - 개발 과정에서 발생하는 컨텍스트 전환 ## 개발자 생산성과 경제적 효과 - Dev Mode 사용으로 개발자 산출량이 **20~30% 증가**할 것으로 추정됐다. - 개발자 1인당 매주 **90분 이상**의 시간을 절약할 수 있는 것으로 나타났다. - 한 기업이 개발자 200명을 대상으로 조사한 결과, 평균 절감 시간은 **주 98분**이었다. - 복합 조직 모델에서는 3년 동안 개발자 효율성 향상으로 약 **1,000만 달러의 시간 절감 효과**를 추산했다. - 제품을 더 빠르게 출시함으로써 약 **200만 달러의 추가 이익**이 발생할 수 있다고 분석했다. - 효과는 단순히 코딩 속도 향상에만 있지 않고, 개발자가 실제 구현에 집중할 수 있도록 방해 요소를 줄이는 데서 비롯된다. ## 하나의 진실 공급원으로서의 Dev Mode - 디자이너와 개발자가 동일한 Figma 파일을 기준으로 작업하면서 디자인 정보가 분산되는 문제를 줄인다. - 개발자는 파일에서 다음 정보를 직접 확인할 수 있다. - 디자인 변수 - 정확한 치수와 사양 - 사용된 에셋 - 관련 문서 - 코드 스니펫 - Slack 메시지, 회의, 별도 문서 검색을 통해 디자인 의도를 확인할 필요가 줄어든다. - 시간대가 다른 글로벌 팀에서도 별도의 실시간 미팅 없이 필요한 정보를 스스로 확인할 수 있다. ## 핸드오프 방식에서 동시 협업 방식으로 - 기존 방식에서는 디자인이 완성된 뒤 개발로 넘기는 순차적인 핸드오프가 일반적이었다. - 이 과정은 디자인 의도 확인과 수정 요청이 반복되면서 출시까지 매우 오래 걸릴 수 있었다. - 한 피트니스 업계 기업은 Dev Mode를 통해 디자인과 개발이 진행 중인 상태에서 지속적으로 협업했다. - 그 결과 “코드가 전혀 없는 상태에서 출시까지” 걸리는 시간이 **2~3년에서 6~8개월**로 단축됐다고 보고했다. - 디자이너와 개발자가 작업 중간부터 피드백을 주고받으면 후반부의 대규모 재작업을 줄일 수 있다. ## 커뮤니케이션과 수작업 감소 - 개발자는 과거에 디자인 의도를 확인하기 위해 디자이너에게 질문하거나 별도 미팅을 요청해야 했다. - 디자이너 역시 수동으로 주석을 달고 사양을 설명하는 데 시간을 써야 했다. - Dev Mode는 필요한 정보를 디자인 파일 안에서 직접 제공해 이런 반복 작업을 줄인다. - 한 시스템 디자이너는 개발자가 변수, 사양, 코드 정보를 직접 확인할 수 있어 더 자율적으로 작업한다고 설명했다. - 결과적으로 다음과 같은 변화가 가능하다. - 불필요한 메시지와 회의 감소 - 수동 주석 작성 감소 - 디자인 확인을 위한 대기 시간 단축 - 개발자의 정신적 부담과 컨텍스트 전환 감소 - 구현과 제품 완성도에 더 많은 집중 ## 실용적인 시사점 Dev Mode 같은 협업 도구의 ROI는 기능 자체보다 핸드오프 과정에서 발생하는 대기·질문·중복 작업을 얼마나 줄이는지로 평가하는 것이 적절하다. 도입을 검토하는 팀이라면 개발자당 절감 시간, 디자인 확인에 소요되는 커뮤니케이션량, 재작업 횟수, 출시까지의 기간을 도입 전후로 측정하는 것이 좋다.

figma

코드 생성이 (진짜) (새 탭에서 열림)

코드 생성(codegen)은 디자인-개발 과정을 완전히 자동화하기보다, 개발자가 더 빠르고 정확하게 작업하도록 돕는 확장 도구로 활용할 때 가장 효과적이다. 특히 AI 코드 생성 결과는 정확성과 유용성에 한계가 있으므로, 개발자를 대체하기보다 적절한 컴포넌트·속성·코드 패턴을 제안해 초기 작업을 앞당기는 방향이 현실적이다. Figma는 이를 “0에서 1”이 아닌 “0에서 0.5”로 빠르게 이동시키는 도구로 설명한다. ### 코드 생성의 범위와 현실 - 코드 생성은 정해진 규칙이나 명세를 바탕으로 코드를 자동 생성하는 과정이다. - 범위가 넓으며 다음과 같은 형태를 포함한다. - IDE의 자동 완성 기능 - 반복적인 코드 패턴을 위한 스니펫과 템플릿 - Bubble 같은 비주얼 프로그래밍·노코드 도구 - GitHub Copilot, Replit Ghostwriter 같은 AI 기반 코드 생성 도구 - Stack Overflow 2023 조사에서 개발자의 82%가 AI 도구를 사용해 코드를 작성한다고 답했다. - 반면 AI 도구의 정확성을 매우 신뢰한다고 답한 비율은 3%에 불과했다. - 따라서 코드가 생성된다는 사실보다, 실제 프로젝트의 프레임워크와 코드베이스에 맞고 개발자가 유용하게 사용할 수 있는지가 더 중요하다. ### 디자인을 코드로 그대로 변환하기 어려운 이유 - Figma는 Dev Mode를 처음 개발할 때 디자인을 코드로 자동 변환하는 것을 목표로 했다. - 초기 결과는 가능성을 보였지만, 다양한 개발자의 요구와 프레임워크를 모두 만족하는 코드를 만들기는 어려웠다. - 자동 생성된 코드가 문법적으로 맞더라도 팀의 컴포넌트 구조, 네이밍 규칙, 상태 관리 방식과 맞지 않으면 실무에서는 유용하지 않을 수 있다. - 이에 따라 Figma는 디자인을 코드로 직역하는 방식보다, 디자인과 개발 사이의 해석과 협업을 보조하는 방식으로 방향을 전환했다. ### 개발자를 대체하는 도구가 아닌 지능 증폭 도구 - 코드 생성은 개발자를 대신하는 자동화 시스템보다 개발자의 능력을 확장하는 도구로 보는 편이 적절하다. - 글은 이를 **지능 증폭(Intelligence Amplification, IA)**으로 설명한다. - 복잡한 문제를 이해하고 - 필요한 정보를 빠르게 찾으며 - 해결책을 도출하는 인간의 능력을 강화하는 접근이다. - AI가 기술이 주도하는 미래를 상징한다면, IA는 사람이 주도권을 유지한 채 기술의 도움을 받는 방식이다. - 개발자는 최종 구조와 구현 방식을 결정하고, codegen은 탐색·반복·초기 작성에 드는 시간을 줄인다. ### “0에서 0.5”까지 빠르게 이동하기 - 디자인 시스템과 컴포넌트 라이브러리를 사용하는 제품에서는 codegen이 핸드오프 과정의 추측을 줄일 수 있다. - 디자인 요소에 대응하는 컴포넌트 이름이나 속성 값을 제안해 개발자가 어떤 도구를 사용할지 빠르게 판단하도록 돕는다. - 디자인 시스템을 공구 상자에 비유하면, codegen은 상황에 맞는 공구와 사용법을 추천하는 역할을 한다. - 완성된 코드를 제공하기보다는 빈 화면에서 작업을 시작할 수 있는 출발점을 만들어 준다. - 즉, “0에서 1”까지 완성하는 자동화보다 “0에서 0.5”까지 빠르게 진입하게 하는 보조 기능에 더 큰 가치가 있다. ### 팀과 코드베이스에 맞춘 구체적인 활용 - codegen의 효과는 일반적인 자동화 도구보다 특정 팀·회사·워크플로에 맞게 적용할 때 커진다. - 디자인 시스템과 컴포넌트 라이브러리가 이미 Figma에 있다면 별도의 완전 자동화 디자인-코드 변환 앱이 반드시 필요하지 않다. - 대신 다음 기능을 활용하는 편이 실용적이다. - 디자인 토큰과 변수 참조 - 컴포넌트 및 속성 문서 확인 - 팀 전용 codegen 플러그인 구축 - 프로젝트 규칙에 맞춘 사용자 정의 코드 스니펫 생성 - 이러한 정보와 힌트는 개발자가 디자인을 빠르게 해석하고 직접 코드를 작성하도록 돕는다. ### 실용적인 결론 codegen은 생성된 코드를 그대로 채택하는 자동화 수단이 아니라, 팀의 디자인 시스템과 개발 규칙을 이해한 상태에서 적절한 컴포넌트와 구현 방향을 제안하는 보조 수단으로 사용하는 것이 좋다. 특히 토큰, 문서, 컴포넌트 메타데이터, 사용자 정의 스니펫을 코드베이스와 연결하면 개발자의 판단을 유지하면서 반복 작업과 초기 탐색 시간을 크게 줄일 수 있다.

figma

새로운 Zeplin 연동 (새 탭에서 열림)

Figma는 Zeplin과의 통합을 네이티브 플러그인으로 전면 재구축해 디자인과 개발 간 핸드오프를 개선했다. 사용자는 Figma에서 프레임·컴포넌트·색상 스타일·텍스트 스타일을 몇 번의 클릭만으로 Zeplin에 내보낼 수 있으며, 개발자는 정확한 스펙·에셋·코드 스니펫을 자동으로 생성할 수 있다. 새 통합은 대형 파일 처리 성능과 해상도 문제를 해결하고, 향후 Figma 컴포넌트 변경 사항을 Zeplin에 자동 반영하는 기능도 검토한다. ## Figma와 Zeplin 통합의 배경 - Zeplin은 디자인 결과물을 개발자와 제품 팀에 전달하는 협업 및 핸드오프 도구다. - Figma의 기존 Zeplin 통합은 Figma가 공식 출시되기 전부터 제공됐다. - 기존 통합을 통해 매달 30만 개 이상의 Figma 파일이 Zeplin으로 내보내졌다. - 재택근무 확산으로 온라인 협업 수요가 커지면서 사용량이 추가로 30~40% 증가했다. ## 네이티브 플러그인으로 재설계 - 두 번째 버전에서는 내보내기 경험과 성능 문제를 개선하는 데 초점을 맞췄다. - Figma용 네이티브 플러그인으로 다시 구축해 다음을 가능하게 했다. - 더욱 매끄러운 사용자 workflow - 통합 기능의 유지보수 간소화 - 새로운 기능을 추가하기 쉬운 구조 - 대용량 Figma 파일과 프레임을 내보낼 때 발생하던 성능 저하와 해상도 문제도 개선됐다. ## Figma에서 Zeplin으로 내보내는 디자인 요소 - 사용자는 Figma에서 다음 요소를 몇 번의 클릭으로 Zeplin에 export할 수 있다. - 프레임 - 컴포넌트 - 색상 스타일 - 텍스트 스타일 - 디자인 요소가 Zeplin으로 전달되면 개발자와 제품 팀은 이를 기반으로 작업할 수 있다. - 내보낸 에셋은 Zeplin의 스타일 가이드에서도 직접 확인할 수 있다. ## 개발자 핸드오프 기능 - Zeplin은 전달받은 디자인을 바탕으로 다음 정보를 자동 생성한다. - 정확한 디자인 스펙 - 필요한 이미지 및 기타 에셋 - 개발에 활용할 수 있는 코드 스니펫 - 이를 통해 디자인 파일을 직접 분석하거나 치수를 수동으로 확인하는 부담을 줄인다. - Figma에서 만든 디자인과 실제 개발 결과물 사이의 커뮤니케이션을 표준화하는 역할을 한다. ## 웹 기반 Figma의 확장 가능성 - Figma가 웹에서 동작한다는 점은 다른 디자인 도구와 차별화되는 장점으로 제시됐다. - 웹 기반 구조를 활용하면 Figma의 변경 사항을 외부 서비스와 더 긴밀하게 연결할 수 있다. - 향후 Figma 컴포넌트가 수정되면 해당 변경 사항을 Zeplin에 자동으로 전송하는 기능이 검토되고 있다. - 이 기능이 구현되면 매번 수동으로 다시 export하지 않아도 디자인과 개발 사양을 최신 상태로 유지할 수 있다. ## 이용 방법과 혜택 - 새 Zeplin 플러그인은 Figma Community에서 설치할 수 있다. - 기존 사용자도 개선된 성능과 해상도로 대형 파일을 export할 수 있다. - Figma 고객이 Zeplin을 시험해 볼 수 있도록 Zeplin Organization 플랜 3개월 무료 혜택이 제공됐다. 실무에서는 Figma를 디자인의 원본으로 유지하고, Zeplin을 개발 사양·에셋·스타일 가이드 전달 도구로 활용하면 효과적이다. 특히 컴포넌트와 스타일을 체계적으로 관리하는 팀이라면 export 규칙을 정하고 변경 사항을 정기적으로 동기화하는 것이 좋다.