toss·2026년 6월 24일·4분 읽기큐레이션 요약

es-toolkit: 작은 내부 라이브러리가 글로벌 프로젝트가 된 이야기

es-toolkit은 레거시 브라우저 지원과 비효율적인 구현으로 무거워진 lodash를 대체하기 위해 Toss 내부 유틸리티 라이브러리에서 출발했습니다. 최신 브라우저 API와 ECMAScript Modules를 활용해 불필요한 코드를 제거한 결과, 함수별 성능이 최소 2배에서 10배 이상 향상되고 번들 크기도 일부 경우 30배 이상 줄었습니다. 이후 국내외 개발자들의 참여와 오픈소스 생태계의 지원을 바탕으로 크게 성장했으며, 기존 lodash 사용자가 쉽게 전환할 수 있도록 `es-toolkit/compat`도 개발했습니다. ## lodash를 대체할 현대적인 유틸리티 라이브러리의 필요성 - 프론트엔드 개발에서는 `throttle`, `debounce`, `uniq` 같은 유틸리티 함수가 자주 필요했습니다. - 널리 사용되던 lodash는 다음과 같은 한계가 있었습니다. - 오래된 코드 구조를 유지함 - `Array#map`처럼 브라우저가 기본 제공하는 기능을 직접 재구현함 - Internet Explorer 등 레거시 브라우저를 위한 방어 로직을 포함함 - ECMAScript Modules를 지원하지 않아 tree-shaking이 어려움 - `lodash-es`는 ESM을 지원했지만 lodash의 오래된 내부 구현과 비효율성은 그대로였습니다. - Toss는 자체 라이브러리인 `@toss/utils`를 운영했지만, 모든 함수를 직접 구현하고 다양한 엣지 케이스를 관리하는 데 큰 부담이 있었습니다. ## es-toolkit의 시작과 성능 개선 - Toss 팀은 현대적인 웹 환경에 맞는 효율적인 유틸리티 라이브러리를 만들기로 했습니다. - 핵심 목표는 lodash의 불필요한 로직을 제거하고, 브라우저 내장 API를 적극 활용하는 것이었습니다. - 구현 결과: - 함수에 따라 성능이 최소 2배, 최대 10배 이상 향상 - 레거시 브라우저 지원 코드와 중복 구현을 제거해 일부 번들 크기가 30배 이상 감소 - 최신 모듈 시스템을 활용해 필요한 코드만 포함할 수 있는 기반 마련 ## 국내외 오픈소스 커뮤니티의 참여 - Toss Frontend의 소셜 미디어에 초기 결과를 공유한 뒤 예상보다 많은 사용자가 유입되었습니다. - 커뮤니티 구성원들은 다음과 같은 방식으로 프로젝트에 기여했습니다. - 누락된 함수 구현 - 버그 수정 - 미완성된 코드 최적화 - lodash를 es-toolkit으로 교체하는 번들러 플러그인 제작 - 유명 라이브러리의 의존성 교체 - Reddit 공유 이후 100개 이상의 추천과 수만 명의 저장소 방문이 발생했습니다. - 해외 블로그와 뉴스레터가 프로젝트를 소개하면서 국제적인 참여가 더욱 확대되었습니다. ## 오픈소스 기여가 개발자 성장으로 이어진 사례 - Dayong Lee는 es-toolkit을 계기로 한국에서도 영향력 있는 오픈소스 프로젝트가 나올 수 있다는 가능성에 주목했습니다. - Toss 직원이 아니었지만 공개 저장소에 작은 Pull Request부터 제출하며 기여를 시작했습니다. - 지속적인 코드 리뷰와 기여를 통해 프로젝트의 두 번째로 많은 기여자가 되었습니다. - 이 과정에서 다음을 학습했습니다. - 인터페이스 설계 원칙 - JavaScript 언어의 세부 동작 - 협업과 코드 리뷰 방식 - es-toolkit에서 쌓은 경험은 이후 Toss Bank에 합류하는 계기가 되었습니다. ## 기존 사용자의 전환 장벽 - 라이브러리가 빠르게 발전했지만, 기존 lodash 사용자가 es-toolkit으로 전환하는 속도는 상대적으로 느렸습니다. - lodash는 코드베이스 곳곳에서 다양한 함수를 사용하기 때문에 함수별로 하나씩 교체하는 작업은 큰 부담이었습니다. - 또한 lodash는 가능한 많은 입력과 예외 상황을 처리하는 반면, es-toolkit은 주요 사용 사례에 집중했습니다. - 따라서 동일한 이름의 함수를 단순히 교체하면 일부 상황에서 동작 차이로 런타임 오류가 발생할 수 있었습니다. ## `es-toolkit/compat`을 통한 점진적 마이그레이션 - es-toolkit 팀은 import 문만 바꿔도 사용할 수 있는 lodash 호환 계층의 필요성을 발견했습니다. - `es-toolkit/compat`은 lodash의 인터페이스와 실제 동작을 최대한 유지하면서 내부 구현만 현대화하는 방식으로 설계되었습니다. - 이를 통해 사용자는 대규모 코드 수정 없이도 다음 효과를 얻을 수 있습니다. - 기존 lodash 사용 방식 유지 - 더 빠른 내부 구현 활용 - 점진적으로 es-toolkit 표준 API로 마이그레이션 - 즉, 완전한 재작성보다 낮은 비용으로 성능과 번들 크기 개선을 먼저 경험하게 하는 전략입니다. ## 실용적인 결론 레거시 라이브러리를 교체할 때는 단순히 더 빠른 구현을 제공하는 것만으로는 충분하지 않습니다. 기존 API와 동작을 유지하는 호환 계층을 함께 제공하면 대규모 코드베이스의 전환 장벽을 크게 낮출 수 있습니다. 새로운 프로젝트에는 es-toolkit을 직접 사용하고, 기존 lodash 프로젝트에는 `es-toolkit/compat`을 활용한 단계적 마이그레이션을 고려할 수 있습니다.

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

웹 개발JavaScriptes-toolkitlodash+3

naver·2026년 6월 22일·1분 읽기큐레이션 요약

사람과 AI Agent를 위한 통합 Context Provider 구축

제공된 내용은 기술 블로그 글이 아니라 NAVER D2 사이트의 메뉴와 저작권 정보만 포함하고 있습니다. 따라서 특정 기술 주제에 대한 주장, 설명, 결론 또는 기술적 세부사항은 확인할 수 없습니다. ### 페이지에 포함된 항목 - **Hello world** - 기본 인사말로 보이는 항목입니다. - **D2 News** - NAVER D2 관련 소식 메뉴입니다. - **About D2** - D2 조직 또는 서비스 소개 메뉴입니다. - **NAVER Developers** - NAVER 개발자 관련 페이지로 연결되는 메뉴입니다. - **DEVIEW** - NAVER의 개발자 конферен스인 DEVIEW 관련 메뉴입니다. - **OpenSource** - 오픈소스 프로젝트나 활동을 다루는 메뉴입니다. - **D2 STARTUP FACTORY** - 스타트업 지원 프로그램 관련 메뉴입니다. - **저작권** - Copyright © NAVER Corp. All Rights Reserved. 문구가 표시되어 있습니다. 실제 기술 글을 요약하려면 본문 내용이나 원문 링크가 추가로 필요합니다.

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

웹 개발오픈 소스software-development

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

AI 도구로 아이디어를 제품으로 발전시키는 4가지 새로운 방법 | Figma 블로그

AI 도구는 제품 개발의 시작점을 아이디어나 정적 목업에서 실행 가능한 프로토타입으로 확장하고 있다. 팀은 코드를 통해 복잡한 제약과 실제 데이터를 먼저 검증한 뒤 Figma에서 함께 탐색·개선하고, 필요하면 디자인 맥락을 유지한 채 다시 코드로 돌아갈 수 있다. 글은 FloQast, Merkle, Affirm, Accor의 사례를 통해 속도와 의도적인 협업을 결합하는 네 가지 AI 기반 워크플로를 소개한다. ## AI 시대의 제품 개발 방식 변화 - 제품팀은 초기부터 프로토타입을 만들며 아이디어를 검증하는 방향으로 이동하고 있다. - AI 코딩 도구를 활용하면 디자이너나 기획자도 개발자의 큰 투입 없이 복잡한 상호작용을 시험할 수 있다. - 제품 탐색은 코드, Figma 캔버스, 다시 코드로 이어지는 순환형 과정이 된다. - AI는 탐색 범위를 넓힐 뿐 아니라, 기존에 핸드오프 과정에서 사라지던 디자인 시스템과 맥락을 개발 단계까지 전달하는 데 활용된다. ## 코드로 복잡한 제약 검증 - 정적 목업만으로 평가하기 어려운 다음과 같은 상황을 코드 기반 프로토타입으로 테스트할 수 있다. - 한 작업이 완료되어야 다음 작업이 활성화되는 다단계 흐름 - 실제 데이터에 따라 화면과 동작이 달라지는 인터페이스 - 사용자 권한, 조건부 상태, 외부 시스템 간 데이터 일치 여부 - 제품 담당자는 AI 코딩 도구로 실제 동작하는 프로토타입을 만들고, 이후 **Codex to Figma**를 통해 Figma 캔버스로 가져와 팀과 함께 검토할 수 있다. - 디자인에서 추가 조정이 필요하면 Figma에서 작업한 뒤 MCP를 통해 코드로 되돌릴 수 있으며, 디자인 맥락도 함께 유지된다. ## FloQast의 복잡한 회계 워크플로 테스트 ### 문제 상황 - FloQast의 회계 소프트웨어에서는 작업 간 의존성, 결제 처리업체와 은행 간 기록 대조, 검토 및 승인 절차 등이 중요하다. - 기존 워크플로에서는 사용자가 불일치를 확인하기 위해 여러 페이지를 오가야 했다. - 팀은 작업 목록, 차단된 작업, 문제 해결 기능을 하나의 화면에 통합하려 했다. - 초기 프로토타입은 가능성을 보였지만, 실제 데이터와 연결된 여러 단계의 상호작용을 정적 디자인만으로는 검증하기 어려웠다. ### AI 코딩 프로토타입의 활용 - UX 매니저 Benjamin Ellis는 AI 코딩 도구로 시뮬레이션 백엔드와 실제 고객 워크플로를 기반으로 한 현실적인 데이터를 구성했다. - 팀은 한 단계의 완료가 다음 단계의 상태를 바꾸는 실제 시나리오를 직접 실행했다. - 겉보기에는 자연스러워 보였지만 실제 데이터와 로직을 적용하면 무너지는 흐름을 조기에 발견했다. ### 결과와 적용 시점 - 디자인 방향을 확정하기 전에 실제 시나리오를 충분히 검증해 후속 개발 단계의 예상치 못한 문제를 줄였다. - 다음과 같은 경우에 이 방식을 적용할 수 있다. - 권한이나 조건에 따라 UI 동작이 달라지는 경우 - 한 동작이 다른 동작과 상태에 연쇄적으로 영향을 주는 경우 - 작은 수정은 디자인 툴을 거치는 것보다 코드에서 직접 처리하는 편이 빠른 경우 - 디자이너와 개발자가 복잡한 경험을 함께 정의해야 하는 경우 정적인 화면을 먼저 완성하려 하기보다, AI 도구로 실제 데이터와 로직을 포함한 작동 가능한 프로토타입을 빠르게 만든 뒤 디자인과 개발을 오가는 방식이 효과적이다. 특히 복잡한 제품일수록 초기 코드 검증을 통해 잘못된 상호작용을 일찍 발견하고, Figma를 협업과 refinement의 공간으로 활용하는 것이 유리하다.

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

웹 개발Figma디자인 시스템프로토타이핑+4

line·2026년 4월 10일원문

AI로 리뷰 정체를 해소하다 - PR 리뷰 지원과 사내 워크숍으로 리뷰 문화 바꾸기 (새 탭에서 열림)

개발 생산성을 저해하는 리뷰 정체 현상을 해결하기 위해 AI 스크리닝 리뷰와 프로세스 체계화를 도입하여 팀의 업무 효율을 극대화한 사례를 소개합니다. 단순히 도구를 사용하는 수준을 넘어 Claude Code의 커스텀 명령어를 활용해 'AI의 1차 점검 후 사람의 최종 판단'이라는 2단계 리뷰 체계를 구축함으로써, 리뷰어의 부담을 줄이고 코드 품질을 안정적으로 유지할 수 있었습니다. 이러한 기술적 장치와 PR 작성 자동화 등의 문화적 노력이 결합될 때 지속 가능한 개발 환경이 만들어진다는 것이 핵심입니다. ## 리뷰 정체와 기술적 부채의 발생 * **특정 인원에게 집중된 리뷰 부하(SPOF):** 소수의 테크 리드나 숙련된 엔지니어에게 리뷰가 집중되면서, 자신의 구현 업무와 리뷰 대응을 병행해야 하는 과부하 상태가 지속되었습니다. * **효율과 품질의 트레이드오프:** 리뷰 속도를 높이면 버그 누락 위험이 커지고, 꼼꼼히 리뷰하면 전체 개발 속도가 늦어지는 딜레마에 빠졌습니다. * **리뷰 대기 시간 증가:** PR이 쌓이면서 구현 담당자가 다음 작업으로 전환하는 데 병목이 발생하고 프로젝트 전체의 리드 타임이 길어지는 문제가 나타났습니다. ## AI 스크리닝 리뷰 시스템의 도입 * **단순 요약의 한계 극복:** 초기에는 AI에 PR 내용을 붙여넣는 방식을 시도했으나, 매번 프롬프트를 입력해야 하는 번거로움 때문에 실무 정착에 실패했습니다. * **Claude Code 커스텀 명령어 활용:** 사내에 도입된 Claude Code를 이용해 리뷰 명령어를 자동화함으로써, 별도의 프롬프트 준비 없이 한 번의 명령으로 정교한 리뷰가 가능해졌습니다. * **2단계 리뷰 프로세스:** AI가 먼저 변경 사항 요약, 영향 범위 분석, 코딩 규칙 위반 여부, 잠재적 버그를 점검하여 리포트를 제공하면, 리뷰어는 이를 바탕으로 최종 판단만 내리는 방식으로 전환했습니다. ## Claude Code를 활용한 리뷰 자동화 디테일 * **단계적 분석 절차:** AI가 단순히 코드만 보는 것이 아니라 `gh` 커맨드로 PR 메타 정보와 코멘트 이력을 가져와 배경지식을 파악하고, 전체 코드베이스의 의존 관계까지 조사하도록 설계했습니다. * **리뷰어용 코멘트 제안:** AI가 지적 사항에 대해 `[must]`, `[want]`, `[imo]` 등의 라벨을 붙여 구현자에게 보낼 코멘트 초안을 작성해 줌으로써 리뷰어의 커뮤니케이션 비용을 절감했습니다. * **체크아웃 및 환경 동기화:** PR 브랜치를 자동으로 체크아웃하고 파일 차분(diff)을 직접 확인하여 분석의 정확도를 높였습니다. ## 선순환을 만드는 PR 작성 자동화와 조직 문화 * **PR 작성 지원:** 리뷰 효율을 높이기 위해 작성 단계부터 AI가 커밋 차분을 분석하여 제목과 배경, 변경 내용을 템플릿에 맞춰 자동으로 작성하도록 자동화했습니다. * **데이터 기반의 정확도 향상:** 충실하게 작성된 PR 설명은 다시 AI 스크리닝 리뷰의 분석 정확도를 높이는 데이터로 활용되어 리뷰 품질의 선순환을 만듭니다. * **지속 개선 구조:** '효율화-정확도 기반-문화 형성-지속 개선'이라는 네 가지 축을 바탕으로 기술과 문화가 조화를 이루는 통합적인 리뷰 환경을 지향합니다. 리뷰 정체 문제를 해결하고 싶다면 단순히 AI에게 "이 코드를 리뷰해줘"라고 요청하는 단발성 시도에서 벗어나야 합니다. Claude Code와 같은 도구를 활용해 팀의 코딩 규칙과 워크플로우를 반영한 **커스텀 명령어를 구축**하고, AI가 1차 스크리닝을 담당하게 하여 사람이 '최종 의사결정'에만 집중할 수 있는 환경을 만드는 것을 추천합니다. 이러한 체계화는 리뷰어의 심리적 부담을 줄일 뿐만 아니라 팀 전체의 개발 속도를 비약적으로 향상시키는 실질적인 해법이 됩니다.

웹 개발AI데이터베이스 설계claude-code+4

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

Codex와 Figma로 프론트

Codex와 Figma MCP 서버를 연결하면 디자인과 실행 중인 프론트엔드 UI를 양방향으로 오갈 수 있다. Figma의 디자인 정보를 Codex에 전달해 코드를 생성하고, 구현된 UI를 다시 편집 가능한 Figma 프레임으로 가져와 검토·협업·개선한 뒤 변경 사항을 코드에 반영하는 방식이다. 이를 통해 초기 디자인이나 코드에 고정되지 않고, 탐색과 구현을 반복하며 더 나은 제품을 만들 수 있다. ## Figma 디자인에서 앱 시작하기 - Figma MCP 서버는 **Figma Design, Figma Make, FigJam** 파일의 정보를 Codex에 전달한다. - 구현할 Figma 파일에서 원하는 프레임이나 노드를 우클릭한 뒤 **“Copy as → Copy link to selection”**을 선택한다. - 복사한 선택 URL은 단일 요소, 컴포넌트 묶음 등 특정 캔버스 영역을 가리키며, 에이전트가 코드 생성에 사용할 원본 데이터가 된다. - Codex에서 새 프로젝트나 기존 프로젝트를 선택하고 다음과 같은 방식으로 요청한다. - “이 Figma 디자인을 코드로 구현하고, 기존 디자인 시스템 컴포넌트를 최대한 활용해줘.” - Codex는 Figma MCP 서버의 `get_design_context` 도구를 호출해 다음 정보를 추출한다. - 레이아웃 구조 - 스타일 - 컴포넌트 정보 - 기타 디자인 관련 컨텍스트 - 이 정보를 바탕으로 Codex가 디자인에 맞는 UI 코드를 생성한다. ## 코드에서 Figma 캔버스로 가져오기 - 코드에서 UI를 구현하고 반복 수정한 뒤, 실행 중인 화면을 Figma로 가져와 시각적으로 비교하고 대안을 탐색할 수 있다. - 앱은 로컬 환경이나 공개 웹 서버에서 렌더링할 수 있다. - Codex에 새 Figma Design 파일을 생성하도록 요청하면 다음 과정을 안내한다. 1. 새 파일 또는 기존 파일 선택 2. 파일을 저장할 워크스페이스 선택 3. UI 캡처를 위한 애플리케이션 설정 4. 브라우저에서 앱 세션 열기 - Figma MCP 서버의 `generate_figma_design` 도구는 실행 중인 인터페이스를 편집 가능한 Figma 프레임으로 변환한다. ## UI 캡처 기능 앱이 다시 로드되면 화면 상단에 캡처 도구 모음이 표시된다. - **Entire screen**: 현재 표시된 전체 화면을 Figma 파일로 캡처 - **Select element**: 페이지에서 특정 컴포넌트나 요소만 선택해 캡처 - **Open file**: 생성된 디자인 레이어를 Figma에서 확인 캡처가 끝나면 Figma 파일을 바로 열거나 Codex로 돌아갈 수 있으며, Codex에는 해당 Figma 파일 URL이 전달된다. ## 캔버스에서 UI 개선하기 Figma로 가져온 실행 UI는 단순 이미지가 아니라 추가 편집과 협업이 가능한 디자인 자료로 활용된다. - 디자인 시스템 컴포넌트 추가 - 스타일, 글꼴, 색상을 변수로 전환 - 레이아웃 조정 및 주석 작성 - 인터랙션과 빈 상태 화면 설계 - 여러 UI 변형안과 탐색안 비교 - 팀원과 캔버스에서 공동 검토 수정이 끝나면 처음과 동일하게 프레임 또는 노드의 선택 URL을 복사해 Codex에 전달하고, Figma MCP 서버를 통해 변경된 디자인을 애플리케이션 코드에 반영할 수 있다. ## 디자인과 코드의 왕복 workflow - 디자인에서 시작해 Codex로 구현한다. - 실행 중인 UI를 Figma로 가져와 실제 결과를 검토한다. - Figma 캔버스에서 스타일, 컴포넌트, 레이아웃, 상태를 개선한다. - 변경된 디자인 컨텍스트를 다시 Codex로 보내 코드에 반영한다. - 이 과정을 반복하면서 속도를 유지한 채 프로토타입부터 실제 서비스 UI까지 발전시킬 수 있다. 실무에서는 먼저 Figma에 디자인 시스템과 핵심 화면을 정리한 뒤 Codex에 전달하고, 생성된 UI를 `generate_figma_design`으로 다시 캔버스에 가져와 시각적 차이를 검토하는 방식을 추천한다. 이를 통해 코드 구현과 디자인 의사결정을 분리하지 않고 하나의 반복 가능한 작업 흐름으로 통합할 수 있다.

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

웹 개발Figma디자인 시스템모델 컨텍스트 프로토콜+2

daangn·2026년 2월 23일원문

웹뷰 엔지니어를 위한 iOS Webview Input 경험 개선기 (새 탭에서 열림)

당근 커뮤니티실의 웹뷰 엔지니어가 iOS 환경에서 키보드가 올라올 때 화면 전체가 위로 밀리는 고질적인 문제를 해결하기 위해 시도한 네 가지 단계의 여정을 담고 있습니다. iOS 웹뷰의 레이아웃(Layout) 및 시각적(Visual) 뷰포트 특성을 분석하고, 최종적으로 `opacity` 속성을 이용해 OS의 자동 스크롤 동작을 선제적으로 차단하는 최적의 사용자 경험(UX) 솔루션을 도출했습니다. 이는 기술적 완결성보다 유저의 입력 흐름을 깨지 않는 실전적인 해결책에 집중한 사례입니다. ### iOS 웹뷰의 뷰포트 구조와 문제의 원인 iOS 웹뷰에서 입력창(Input)에 포커스가 되면 키보드 공간을 확보하기 위해 페이지가 위로 밀려 올라가는 현상이 발생합니다. * **두 가지 뷰포트의 차이**: 키보드가 올라와도 크기가 변하지 않는 'Layout Viewport'와 사용자 눈에 보이는 영역인 'Visual Viewport' 간의 불일치가 원인입니다. * **OS의 강제 동작**: iOS는 포커스된 입력창을 시각적 영역 안에 두기 위해 페이지 전체를 밀어 올리며, 이 과정에서 상단 콘텐츠가 화면 밖으로 사라지는 등 웹 개발자가 제어하기 어려운 동작이 수반됩니다. ### 초기 시도: 리사이징과 오프셋 보정의 한계 문제를 인지한 후 화면을 원래 위치로 되돌리거나 밀린 만큼 따라가는 방식을 시도했으나 기술적 한계가 있었습니다. * **Resize 방식**: `visualViewport`의 변화를 감지해 래퍼 요소를 축소하고 `scrollTo(0, 0)`를 호출했으나, OS가 화면을 먼저 밀어버린 후 복구되기 때문에 화면 떨림과 깜빡임이 발생했습니다. * **OffsetTop 방식**: `visualViewport.offsetTop` 값을 계산해 화면이 밀린 만큼 레이아웃의 `top` 위치를 조정했습니다. 첫 번째 시도보다 나았지만, 키보드가 올라오는 과정에서 실시간 보정 딜레이로 인한 미세한 진동 피드백이 남았습니다. ### 전환점: Fake Input을 활용한 입력창 스왑 iOS가 화면을 밀어 올리는 원인 자체를 제거하기 위해 입력창을 두 개로 분리하는 전략을 세웠습니다. * **동작 원리**: 평소에는 화면에 보이는 'Fake Input(ReadOnly)'을 노출하고, 터치 시 화면 밖에 숨겨둔 'Real Input'에 포커스를 줍니다. * **효과**: iOS는 화면 밖에 있는 요소를 위해 스크롤을 발생시키지 않으므로 화면 밀림이 완벽히 해결되었습니다. * **문제점**: 두 입력창 사이의 값(Value), 선택 영역, 자동 높이 조절 등을 동기화해야 하는 로직이 매우 복잡해져 유지보수 부담이 컸습니다. ### 최종 해결책: Opacity를 이용한 OS 속이기 입력창을 하나만 유지하면서도 OS의 자동 스크롤을 막기 위해 브라우저의 특성을 활용한 'Opacity Trick'을 적용했습니다. * **핵심 아이디어**: iOS는 `opacity: 0`인 요소에 대해서는 'scroll-into-view'(포커스된 요소를 화면 안으로 가져오는 동작)를 수행하지 않는다는 점을 발견했습니다. * **구현 로직**: `onTouchStart` 시점에 입력창의 `opacity`를 0으로 만들어 자동 스크롤을 차단한 뒤, `focus`가 완료되고 키보드가 올라온 시점에 다시 `opacity`를 1로 복원합니다. * **결과**: 입력창 상태 관리의 복잡성 없이 단일 요소를 사용하면서도 화면 밀림 현상을 선제적으로 차단하여 가장 매끄러운 UX를 구현했습니다. 정석적인 API가 없는 환경에서 유저 경험을 위해 선택한 이 방식은 다소 'Hacky'할 수 있으나, 프로덕트의 핵심인 '글쓰기 경험'을 보호하기 위한 엔지니어링적 결단이었습니다. 기술적인 완벽함보다는 유저가 느끼는 불편함을 제거하는 것이 우선이며, OS 업데이트 등 변화하는 환경에 맞춰 지속적으로 해결책을 고도화해 나가는 자세가 중요합니다.

웹 개발사용자 경험iOSwebview+4

toss·2025년 12월 23일원문

AST로 Outdated 없는 퍼널 문서 만들기 (새 탭에서 열림)

토스팀은 복잡한 판매자 입점 퍼널을 효율적으로 관리하기 위해 코드를 정적으로 분석하여 자동으로 업데이트되는 퍼널 문서를 구축했습니다. 기존의 수동 문서는 빈번한 코드 변경을 따라가지 못해 실효성을 잃었으나, `ts-morph`와 AST(Abstract Syntax Tree) 분석을 통해 코드와 100% 일치하는 흐름도를 생성할 수 있게 되었습니다. 이를 통해 개발자는 복잡한 조건부 분기와 페이지 이동 로직을 별도의 문서 작업 없이도 시각적으로 정확하게 파악할 수 있게 되었습니다. **수동 문서화의 한계와 정적 분석의 선택** * **문서의 파편화:** 수기로 작성된 다이어그램은 코드가 수정될 때마다 즉시 업데이트되지 않아 실제 동작과 문서가 불일치하는 'Outdated' 문제가 발생합니다. * **복잡한 분기 처리의 어려움:** 수십 개의 페이지와 80여 개의 조건부 분기를 시각적 도구로 일일이 표현하는 것은 휴먼 에러의 위험이 크고 관리가 불가능합니다. * **정적 분석 채택:** 런타임 분석은 모든 경로를 직접 실행해야 하는 번거로움이 있지만, AST를 활용한 정적 분석은 코드를 텍스트로 읽어 모든 잠재적 경로를 빠르고 안전하게 추출할 수 있습니다. **Navigation Edge 데이터 구조 설계** * **맥락 정보 포함:** 단순한 이동 경로(A → B)를 넘어, 이동 방식(`push` vs `replace`), 실행 조건, 쿼리 파라미터 등의 상세 데이터를 포함하는 `NavigationEdge` 인터페이스를 설계했습니다. * **추적 가능성 확보:** 코드 내 정확한 위치(`lineNumber`)와 호출 출처(`sourceType`)를 저장하여 다이어그램에서 실제 소스 코드로 즉시 연결될 수 있는 기반을 마련했습니다. **AST를 활용한 로직 추출 및 조건문 파싱** * **패턴 감지:** `ts-morph`를 사용하여 프로젝트 내 페이지 파일을 탐색하고, `router.push()` 또는 `router.replace()`와 같은 함수 호출 패턴을 감지합니다. * **상위 노드 추적:** 특정 이동 로직이 발견되면 AST의 부모 방향으로 거슬러 올라가 가장 가까운 `if`문이나 삼항 연산자의 텍스트를 추출함으로써 이동 조건(Condition)을 파악합니다. **커스텀 훅 및 URL 상수의 역추적** * **숨은 로직 탐색:** 페이지 컴포넌트 내부뿐만 아니라, `import` 구문을 분석하여 커스텀 훅 내부에 숨겨진 이동 로직까지 추적하여 데이터 누락을 방지합니다. * **상수 해독:** `URLS.FUNNEL.PAY_METHOD`와 같이 상수로 정의된 목적지를 실제 URL 경로로 변환하기 위해 상수 정의 파일을 별도로 파싱하여 매핑 테이블을 구축했습니다. **실용적인 결론** 복잡도가 높은 서비스일수록 문서와 코드의 동기화는 자동화되어야 합니다. `ts-morph`와 같은 도구를 활용해 소스 코드를 단일 진실 공급원(Single Source of Truth)으로 삼는 자동화 문서를 구축하면, 불필요한 커뮤니케이션 비용을 줄이고 퍼널 전체의 비즈니스 로직을 명확하게 시각화할 수 있습니다.

웹 개발TypeScriptstatic-analysisabstract-syntax-tree+3

figma·2025년 12월 2일·4분 읽기큐레이션 요약

더블 클릭: AI 시대

AI는 디자인·개발·제품 관리의 전문 업무를 자동화하고, 역할 간 경계를 흐리게 만들고 있다. 이에 따라 디자이너라는 직함은 고정된 직무명이 아니라 변화하는 업무 묶음과 전문적 정체성을 설명하는 장치가 된다. 글은 직함이 여전히 경력 경로와 협업 기대치를 정하는 데 유용하지만, 앞으로는 특정 직함보다 여러 영역을 연결하고 가치를 만들어내는 능력이 더 중요해질 것이라고 말한다. ## AI가 만든 역할의 확장과 경계의 붕괴 - 디자이너, 개발자, 제품 관리자가 담당하는 업무 범위가 넓어지면서 서로의 역할을 일부 수행하는 일이 일반화되고 있다. - Figma의 최근 조사에 따르면 제품을 만드는 사람의 **64%가 두 개 이상의 역할과 자신을 동일시**한다. - AI가 전문적인 작업을 점점 더 잘 처리하면서, 한 분야의 깊은 전문성뿐 아니라 여러 영역의 관계를 파악하고 연결하는 능력이 중요해지고 있다. - 이런 변화 속에서 ‘제너럴리스트’의 가치가 커지고 있으며, 직무 간 경계와 전통적인 역할 구분은 약해지고 있다. ## 직함이 갖는 사회적·심리적 의미 - 직함은 단순한 명칭이 아니라 다음과 같은 기능을 한다. - 개인의 지위와 전문성을 전달한다. - 협업 상대가 그 사람의 역할과 기대치를 빠르게 이해하도록 돕는다. - 개인이 자신의 직업적 정체성을 이해하고 표현하는 기준이 된다. - 직함은 업무 만족도와 심리적 안정감에도 영향을 줄 수 있다. - Adam Grant가 참여한 연구에서는 직원이 자신의 직함을 직접 정할 수 있을 때 심리적 안전감이 높아지고, 5주 동안 정서적 소진이 최대 10% 감소했다. - 건축·기계공학·전기전자공학·의학 분야처럼 직함과 자격을 중심으로 전문성을 제도화한 조직도 존재한다. ## 기술 변화에 따라 달라지는 직업명 - ‘디자이너’의 의미는 시대에 따라 변해 왔다. - 1950년대에는 주로 사물과 인쇄물의 시각적 형태를 설계하는 직업으로 이해됐다. - 소프트웨어와 디지털 제품이 등장하면서 사용자 경험, 인터랙션, 서비스 설계까지 역할이 확장됐다. - ‘소프트웨어 엔지니어’라는 명칭도 1966년 무렵 등장했으며, 1968년 NATO 회의에서는 급증하는 컴퓨팅 능력에 맞춰 복잡해진 소프트웨어 개발 문제, 이른바 ‘소프트웨어 위기’를 다뤘다. - 닷컴 붐 당시에는 한 사람이 제품 관리자, 프로그램 관리자, 개발자, 아티스트를 동시에 맡는 경우도 있었고, 인사 부서가 적절한 직함이나 직군을 정하지 못하는 일도 있었다. - 최근에는 ‘프롬프트 엔지니어’처럼 AI 기술의 부상과 함께 새로운 직함이 빠르게 등장했다가 중요성이 약해지는 현상도 나타났다. - Ethan Mollick은 직업을 고정된 정체성이 아니라 기술과 환경에 따라 중요도와 난이도가 달라지는 **업무(task)의 묶음**으로 설명한다. ## 직함은 기대치를 조정하는 도구 - Figma의 Nikolas Klein은 자신을 “PM 트렌치코트를 입은 프로덕트 디자이너”라고 표현한다. - 그는 직함이 다음과 같은 실용적 역할을 한다고 본다. - 조직 내 경력 단계와 승진 경로를 제시한다. - 처음 만난 사람에게 담당 업무와 전문성을 설명한다. - 협업 과정에서 상대방이 기대할 수 있는 역량을 조정한다. - 디자이너에서 제품 관리자로 이동한 뒤에는 전략, 서비스 디자인, 여러 문제를 연결하는 능력이 더 자연스럽게 기대되었고, 시각 디자인 업무에 대한 기대는 줄었다. - 즉, 직함은 개인의 모든 능력을 완벽하게 설명하지는 못하지만, 다른 사람이 그 사람을 이해하고 협업하는 출발점이 된다. ## 직함의 한계와 정체성의 변화 - Figma의 개발자 옹호자 Jake Albaugh는 역할이 자신의 전문성이 성장함에 따라 계속 변하기 때문에, 직함이 때로는 한계처럼 느껴진다고 말한다. - 반대로 웹 디자이너에서 소프트웨어 엔지니어로 자신을 소개할 수 있게 된 경험은 전문성을 인정받는다는 점에서 강한 자신감을 줬다. - 특정 직함에는 해당 시대와 업계가 중요하게 여기는 가치가 반영된다. - 사람들은 자신이 제공하는 가치와 가장 잘 맞는 방식으로 불리기를 원한다. - 따라서 직함은 고정된 능력의 목록이라기보다, 개인의 현재 역할과 업계가 평가하는 가치를 표현하는 신호에 가깝다. ## 앞으로의 디자이너 역할 - AI가 반복적이고 전문화된 작업을 수행할수록 디자이너의 역할은 다음 방향으로 확장될 가능성이 크다. - 문제를 정의하고 올바른 질문을 만드는 일 - 사용자·비즈니스·기술 요구사항을 연결하는 일 - 여러 분야의 아이디어를 종합해 제품 방향을 정하는 일 - AI가 생성한 결과를 평가하고 맥락에 맞게 개선하는 일 - 디자이너라는 직함이 사라진다기보다, 그 안에 포함되는 업무와 기대 역량이 계속 재구성될 가능성이 높다. - 중요한 것은 하나의 직함에 자신을 가두기보다, 자신의 핵심 가치와 여러 역할 사이의 연결 능력을 분명히 설명하는 것이다. 조직은 직함을 폐지하기보다 경력 경로와 협업 기준을 제공하는 장치로 유지하되, 실제 평가에서는 직함보다 수행한 업무와 만들어낸 가치를 함께 봐야 한다. 개인 역시 현재의 직함에만 의존하기보다 자신이 해결할 수 있는 문제, 연결할 수 있는 분야, AI를 활용해 확장할 수 있는 역량을 중심으로 전문성을 정의하는 것이 실용적이다.

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

웹 개발FigmaAI프로덕트 디자인+3

figma·2025년 6월 16일원문

코드 레이어로 사이트를 인터랙티브 (새 탭에서 열림)

피그마(Figma)는 디자인 환경 내에서 커스텀 리액트(React) 코드를 활용해 역동적인 상호작용을 구현할 수 있는 ‘코드 레이어(Code Layers)’ 기능을 출시했습니다. 이 기능을 통해 디자이너는 복잡한 개발 지식 없이도 AI 채팅이나 직접적인 코드 수정을 통해 정적인 디자인을 실제 작동하는 웹 요소로 변환하고 실험할 수 있습니다. 결과적으로 디자인과 실제 제품 구현 사이의 장벽을 허물어, 별도의 개발 전달 과정 없이도 고도화된 애니메이션이나 기능적 컴포넌트를 피그마 사이츠(Figma Sites)에서 즉시 빌드할 수 있게 되었습니다. **코드 레이어를 활용한 인터랙션 구현** * 코드 레이어는 리액트 코드를 기반으로 구동되는 상호작용 요소로, 피그마 사이츠 내에서 기존 컴포넌트를 코드로 변환하거나 새롭게 생성할 수 있습니다. * 피그마 메이크(Figma Make)의 AI 기술을 활용하여 "꽃 이미지를 무한히 복제해서 드래그할 수 있게 해줘"와 같은 자연어 프롬프트만으로 복잡한 로직을 생성합니다. * 캔버스 위에서 바로 코드 레이어를 복제(Cmd + D)하여 여러 버전의 상호작용을 나란히 비교하고 실험하는 유연한 워크플로우를 제공합니다. **기존 디자인의 동적 변환 및 제작 방식** * 작업 중인 요소에 애니메이션(회전, 바운스 등)을 추가하거나, 마우스 호버 시 색상이 변하는 리플 효과 등 정적 이미지에 생명력을 불어넣을 수 있습니다. * 대출 계산기, 가격 추정기, 실시간 통계 카운터와 같이 단순한 프로토타입을 넘어 실제 로직이 작동하는 유틸리티 컴포넌트를 제작할 수 있습니다. * 단축키(E)를 사용하여 캔버스에 즉석에서 코드 레이어를 그려 넣고, AI에게 이모지 파티클 생성이나 이미지 갤러리 구축 등을 요청하여 빠르게 아이디어를 시각화합니다. **개발자 수준의 확장성과 재사용성** * **커스텀 속성 편집:** AI가 코드 기반의 속성(문자열, 숫자 등)을 자동으로 생성하며, 사용자는 코드 수정 없이도 패널에서 직접 값을 조정해 레이어의 동작을 변경할 수 있습니다. * **컴포넌트화:** 일반적인 피그마 프레임처럼 코드 레이어도 재사용 가능한 컴포넌트로 전환하여 여러 페이지나 팀 프로젝트에 공유할 수 있습니다. * **npm 패키지 지원:** `motion`이나 `@react-three/fiber`와 같은 외부 노드 패키지 매니저(npm) 라이브러리를 임포트하여 고난도의 3D 렌더링이나 정교한 모션 그래픽을 구현할 수 있습니다. 웹 디자인의 한계를 넓히고자 하는 디자이너라면 피그마 사이츠에서 제공되는 코드 레이어를 적극적으로 활용해 보시기 바랍니다. 특히 AI 프롬프트를 통해 기초 코드를 생성한 뒤, npm 패키지를 결합해 시중의 템플릿으로는 불가능했던 독창적인 사용자 경험을 직접 구축해 보는 것을 추천합니다.

웹 개발AI프로토타이핑React+4

figma·2025년 6월 16일원문

Payload의 Figma 팀 합류를 (새 탭에서 열림)

피그마(Figma)는 오픈소스 헤드리스 CMS이자 애플리케이션 프레임워크인 페이로드(Payload) 팀을 인수하여 디자인과 개발의 경계를 허무는 행보를 가속화합니다. 이번 인수는 최근 발표된 '피그마 사이트(Figma Sites)'와 시너지를 내어 개발자들에게 더욱 강력하고 유연한 도구를 제공하는 데 목적이 있습니다. 피그마는 이를 통해 디자인뿐만 아니라 실제 제품의 빌드와 배포까지 생태계 내에서 직접 수행할 수 있는 중앙 허브로 거듭날 계획입니다. **Figma Sites와 Payload의 기술적 시너지** - Config 2025에서 발표된 '피그마 사이트'와 결합하여, 디자인에서 실제 프로덕션 웹사이트 제작까지의 과정을 비약적으로 단축합니다. - Payload가 제공하는 높은 커스터마이징 자유도와 확장성을 활용해, 개발자들이 기존의 제한적인 CMS 환경에서 벗어나 더 나은 DX(개발자 경험)를 누릴 수 있도록 지원합니다. - 포춘 100대 기업들이 이미 도입하여 신뢰성을 검증받은 Payload의 기술력을 피그마 플랫폼에 이식함으로써 엔터프라이즈급 개발 환경을 구축합니다. **오픈소스 생태계 유지와 커뮤니티 협업** - Payload는 인수 후에도 오픈소스 프로젝트로 유지되며, 기존 사용자들은 현재와 동일하게 서비스를 이용할 수 있도록 독립성을 보장합니다. - 피그마의 협업 중심 철학과 Payload의 오픈소스 커뮤니티 지향점이 결합되어, 사용자 피드백을 기반으로 한 제품 로드맵을 투명하게 공유할 예정입니다. - 피그마는 오픈소스 프로젝트에 지속적으로 투자하여 개발자들이 지식을 공유하고 기술을 발전시킬 수 있는 생태계를 확장하는 데 집중할 계획입니다. **디자인-개발 통합을 통한 제품 제작 가속화** - AI의 발전으로 코드와 콘텐츠 생성이 쉬워진 환경에 발맞추어, 배포 채널을 직접 제어하고 사용자 경험을 세밀하게 튜닝할 수 있는 제어권을 강화합니다. - 단순히 디자인 결과물을 공유하는 단계를 넘어, 피그마 생태계 내에서 직접 디지털 제품을 구축하고 배포할 수 있는 환경을 조성합니다. - 디자인과 개발 사이에 전통적으로 존재해 왔던 간극을 좁힘으로써 제품 제작 팀의 전체적인 생산성을 높이는 것을 최종 목표로 삼고 있습니다. 디자이너와 개발자가 긴밀하게 협업해야 하는 조직이라면 향후 피그마 사이트와 페이로드의 통합 기능을 주목할 필요가 있습니다. 디자인 시스템을 기반으로 실제 웹 서비스를 신속하게 배포하고 관리하려는 팀에게 이번 인수는 매우 강력한 생산성 도구의 탄생을 예고합니다.

웹 개발FigmaAI오픈 소스+4

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

Figma Sites로 웹

Figma Sites는 Figma 안에서 웹사이트를 디자인하고, 반응형 동작과 인터랙션을 적용한 뒤 바로 게시할 수 있는 올인원 도구다. 기존의 디자인·프로토타이핑·개발·배포로 이어지는 선형 작업을 하나의 반복적인 흐름으로 통합해, 개발 도구나 별도 협업 과정 없이 실제 웹사이트를 제작하도록 돕는다. 템플릿과 디자인 시스템 연동, 반응형 레이아웃, 다양한 애니메이션 기능을 통해 디자이너와 소규모 팀도 표현력 있는 사이트를 만들 수 있다. ## 디자인부터 게시까지 하나의 작업 흐름 - 기존 웹 제작은 Figma에서 디자인한 뒤 프로토타입을 만들고, 브레이크포인트를 설정하며, 디자인을 코드로 변환하고 테스트·배포하는 수작업과 도구 전환이 필요했다. - Figma Sites에서는 Figma를 떠나지 않고 디자인, 인터랙션 구현, 반응형 조정, 웹 게시를 수행할 수 있다. - 포트폴리오, 이벤트 사이트, 제품 랜딩 페이지 등 다양한 목적의 실제 동작하는 웹사이트를 제작할 수 있다. - 템플릿, 반응형 웹 요소, 사전 제작된 인터랙션을 제공해 디자인·개발 인력이 제한적인 팀도 빠르게 시작할 수 있다. - 향후 Figma Make 기반의 채팅-투-코드 기능을 통해 원하는 애니메이션이나 인터랙션을 자연어로 설명하고 생성할 수 있게 될 예정이다. ## 템플릿과 디자인 시스템 연동 - Inserts 패널을 통해 게시된 디자인 라이브러리를 사이트에 연결할 수 있다. - 팀의 컴포넌트와 스타일을 재사용해 제작 속도와 일관성을 높일 수 있다. - 별도의 디자인 시스템이 없는 경우에도 내비게이션, 히어로 섹션, 전체 페이지 같은 기본 블록을 활용할 수 있다. - 디자인 시스템을 처음부터 구축하지 않아도 검증된 구성 요소를 조합해 사이트를 만들 수 있다. ## 다양한 화면에 대응하는 반응형 디자인 - 레이아웃, 텍스트, 디자인이 화면 크기와 브레이크포인트에 맞춰 자동으로 조정된다. - Multi-edit 기능으로 여러 화면 크기의 요소를 한 번에 수정할 수 있다. - 텍스트 스타일마다 브레이크포인트별 글자 크기와 간격을 설정할 수 있으며, 별도의 변수를 사용하지 않아도 된다. - 자동 조정 기능을 기반으로 하면서도 세부 요소는 수동으로 조정해 정교하게 다듬을 수 있다. - 미리보기 창의 크기를 바꾸면서 레이아웃 재배치와 브레이크포인트 전환을 확인할 수 있다. ## 웹사이트 수준의 프로토타이핑과 검수 - 협업자에게 인터랙티브한 라이브 웹사이트 미리보기를 공유하고 피드백을 받을 수 있다. - 미리보기는 HTML과 CSS로 렌더링되므로 일반적인 Figma 프로토타입보다 실제 게시 환경에 가까운 결과를 확인할 수 있다. - 반응형 동작뿐 아니라 웹사이트에 특화된 인터랙션도 게시 전에 테스트할 수 있다. ## 기본 제공되는 애니메이션과 인터랙션 - 마우스 패럴랙스: 커서 움직임에 따라 객체를 이동시킨다. - 라이트박스: 이미지를 강조하고 배경을 어둡게 처리한다. - 스핀: 객체를 무한 회전시킨다. - 드래그 가능 요소: 페이지 안의 요소를 자유롭게 이동시킨다. - 타자기 효과: 텍스트를 한 글자씩 표시한다. - 스크램블 텍스트: 문자를 무작위로 보여준 뒤 원래 텍스트를 드러낸다. - 마키, 리빌, 스크롤 패럴랙스 같은 사전 제작 효과도 제공된다. ## Figma Sites만의 확장 기능 - Figma Design에는 아직 없는 스크롤 패럴랙스와 스크롤 변환 기능을 지원한다. - 인터랙티브 컴포넌트를 별도로 만들지 않아도 호버 상태와 눌림 상태를 구현할 수 있다. - 향후 코드 레이어를 사용해 플러그인이나 외부 도구 없이 더 복잡한 인터랙션을 추가할 수 있다. - AI 채팅을 이용해 드래그 가능한 목록이나 실제 지리 정보를 반영한 시계처럼 복잡한 동작을 설명만으로 생성할 수 있게 될 예정이다. - 생성한 코드 레이어는 Figma Design의 라이브러리처럼 재사용·공유 가능한 컴포넌트와 인스턴스로 만들 수 있다. Figma Sites는 단순히 디자인을 웹으로 내보내는 기능보다, 디자인·반응형 구현·프로토타이핑·게시를 통합한 제작 환경에 가깝다. 빠르게 랜딩 페이지나 이벤트 사이트를 제작해야 하는 팀, 개발 리소스가 적은 디자이너에게 특히 유용하며, 복잡한 서비스 기능이나 세밀한 코드 제어가 필요한 경우에는 향후 코드 레이어 기능의 성숙도를 함께 확인하는 것이 좋다.

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

웹 개발AI디자인 시스템프로토타이핑+4

figma·2025년 5월 6일원문

Config 2025: (새 탭에서 열림)

피그마는 Config 2025를 통해 단순한 디자인 도구를 넘어 아이디어 구상부터 실제 제품 구현까지 전 과정을 아우르는 통합 플랫폼으로의 확장을 선언했습니다. AI 기술을 전면에 배치한 4개의 신규 제품과 강력해진 디자인 기능을 도입하여, 디자인과 개발 사이의 경계를 허물고 팀 전체의 생산성을 극대화하는 데 집중하고 있습니다. 이는 디자인이 비즈니스 차별화의 핵심이 되는 시대에 발맞추어, 모든 팀원이 제품 개발 프로세스에 더욱 깊이 기여할 수 있는 환경을 구축하려는 전략적 움직임으로 풀이됩니다. **AI 기반의 앱 및 웹 제작 솔루션** * **Figma Make**: 텍스트 프롬프트를 코드로 변환하거나 기존 디자인을 실제 작동하는 프로토타입 및 앱으로 제작해 주는 AI 도구로, 숙련도와 상관없이 아이디어를 빠르게 시각화하고 반복 수정할 수 있도록 돕습니다. * **Figma Sites**: 디자이너가 AI와 코드의 도움을 받아 역동적인 상호작용과 맞춤 설정이 가능한 웹사이트를 직접 구축하고 즉시 배포할 수 있는 환경을 제공합니다. **디자인 표현력과 브랜드 일관성 강화** * **Figma Draw**: 더욱 정교해진 벡터 편집 및 일러스트레이션 도구 세트를 통해 디자이너가 높은 수준의 공예적 완성도를 가진 시각 결과물을 만들 수 있도록 지원합니다. * **Figma Buzz**: 마케팅 및 브랜드 팀이 브랜드 가이드라인을 준수하면서도 AI를 활용해 대규모로 시각적 자산을 생성하고 관리할 수 있도록 설계된 전용 제품입니다. **개발 협업 및 AI 워크플로우 고도화** * **Grid**: 반응형 레이아웃 설정을 돕는 새로운 옵션으로, Dev Mode에서 즉시 활용 가능한 CSS 코드를 생성하여 디자인에서 개발로 이어지는 핸드오프 과정을 획기적으로 개선합니다. * **지능형 AI 기능**: 이미지 생성 및 편집 기능이 고도화되었으며, 작업 맥락을 이해해 다음 단계를 제안하는 자동 제안 기능과 FigJam 내 AI 보조 도구가 추가되어 워크플로우 속도를 높였습니다. **사용자 저변 확대와 글로벌 시장 최적화** * **사용자 구성의 변화**: 현재 피그마 사용자의 약 2/3가 비디자인 직군이며 그중 30%가 개발자인 점을 반영하여, 직군 간의 협업 효율을 높이는 도구(Dev Mode, Slides 등)를 지속적으로 강화하고 있습니다. * **글로벌 현지화**: 전체 사용자의 85%가 미국 외 지역에 거주하는 상황에 맞춰 브라질 시장을 위한 포르투갈어 전면 지원 및 UI 현지화를 진행하며 글로벌 확장세를 이어가고 있습니다. 이제 피그마는 디자이너만을 위한 도구를 넘어, 기획자, 개발자, 마케터가 하나의 캔버스에서 제품을 완성하는 '제품 개발 운영 체제'로 진화하고 있습니다. 팀 내 협업 효율을 높이고 AI를 통해 제작 단계를 단축하고자 한다면, 순차적으로 출시될 이번 신규 기능들을 워크플로우에 적극적으로 도입해 볼 것을 권장합니다.

웹 개발Figma프로토타이핑생성형 AI+4

figma·2025년 4월 9일원문

FigPals를 위한 영원한 (새 탭에서 열림)

Figma는 디자이너의 고독한 작업 환경에 즐거움을 더하기 위해 커서를 따라다니는 디지털 컴패니언인 'FigPals'를 기간 한정으로 도입했습니다. 90년대 다마고치와 네오펫에서 영감을 받은 이 프로젝트는 사내 해커톤인 '메이커 위크'를 통해 탄생했으며, 단순한 장식 요소를 넘어 사용자와 정서적 교감을 나누는 인터랙티브 요소로 기능했습니다. 짧은 운영 기간에도 불구하고 150만 개 이상의 캐릭터가 생성되는 등 폭발적인 반응을 얻었으며, Figma는 커뮤니티의 요청에 부응해 이를 영구적으로 간직할 수 있는 스티커 팩을 출시하며 프로젝트를 마무리했습니다. ### FigPals의 탄생 배경과 노스탤지어 * 디자이너들이 Figma 파일 내에서 느끼는 반복적이고 고독한 작업 경험을 개선하기 위해 기획된 커서 추적형 디지털 동반자입니다. * 70년대의 '펫 락(Pet Rock)'과 90년대의 '다마고치' 같은 복고풍 장난감 문화에서 영감을 받아, 업무 도구에 장난기 가득한 요소를 결합했습니다. * 9,000가지 이상의 조합(색상, 형태, 액세서리 등)을 제공하여 사용자가 자신만의 개성 있는 캐릭터를 만들고 이름을 붙일 수 있도록 설계했습니다. ### '메이커 위크'를 통한 창의적 실험과 구현 * Figma의 연례 사내 행사인 '메이커 위크(Maker Week)'에서 인턴의 아이디어로 시작된 'Figmagotchi'가 프로젝트의 모태가 되었습니다. * 엔지니어링, 제품, 디자인 팀이 협업하여 캐릭터가 레이어나 노드를 '먹이'로 섭취하거나, 컴포넌트를 해제할 때 놀라는 반응을 보이는 등 다양한 이스터 에그와 상호작용 기능을 구현했습니다. * 업무용 소프트웨어에서도 '놀이(Play)'라는 핵심 가치를 실현할 수 있음을 증명하며, 개발 과정에서 엔지니어들조차 캐릭터에 정서적 애착을 느낄 만큼 몰입도 높은 경험을 구축했습니다. ### 커뮤니티의 열광적인 반응과 데이터 * 출시 일주일 만에 150만 개 이상의 FigPal이 생성되었으며, 사용자들이 캐릭터에게 먹이를 준 횟수만 25만 회를 상회했습니다. * 사용자들은 자신의 실제 반려동물을 모델로 FigPal을 제작하거나, 서비스 종료를 앞두고 영구 도입을 촉구하는 서명 운동(2,000명 이상 참여)을 벌이는 등 강력한 유대감을 보여주었습니다. * 단순한 픽셀의 조합을 넘어 사용자의 업무 공간에 활력을 불어넣는 정서적 매개체로서의 가치를 입증했습니다. 현재 FigPals의 인터랙티브 기능은 종료되었지만, Figma 커뮤니티에서 제공하는 **'FigPal 스티커 팩'**을 활용하면 작업 파일에 이들을 영구적으로 배치하고 추억할 수 있습니다. 또한, 다가오는 Figma의 컨퍼런스 'Config'에서 FigPal과 관련된 추가적인 소식이 있을 예정이므로 관련 업데이트를 주목해 보시기 바랍니다.

웹 개발Figma사용자 경험figjam+3

figma·2025년 1월 27일·3분 읽기큐레이션 요약

요점 정리: 제9호 |

이 글은 빠르게 변하는 기술과 흐려지는 직무 경계 속에서도 소프트웨어 제작의 목적과 완성도를 어떻게 지킬지 탐구한다. 2025년을 위한 Figma 구성원들의 여섯 가지 메모를 소개하며, 개인적이고 표현력 있는 웹, 감정적 공감, 유연한 제품 개발, 창의적 코딩과 제너럴리스트 역량의 중요성을 강조한다. 공통된 결론은 기능과 효율만 좇기보다 사람과 맥락, 실험과 개성을 제품에 반영해야 한다는 것이다. ## 개인적이고 손으로 만든 웹 - 인터넷 사용자가 늘면서 다양한 요구를 수용하는 웹이 필요해졌지만, 많은 웹사이트가 획일적인 구조와 스타일로 수렴했다. - Chia Amisola는 웹이 더 개인적이고 시적이며 표현력 있는 공간이 될 수 있다고 주장한다. - 소규모의 수작업 웹사이트와 독립적인 온라인 공간이 기존 인터넷의 흐름에 도전하고 있다. - 이러한 움직임에 참여하는 방법은 거대한 플랫폼을 만드는 것이 아니라 직접 자신만의 웹사이트를 만드는 것에서 시작할 수 있다. - 웹 디자인은 효율적인 정보 전달뿐 아니라 제작자의 취향과 개성을 드러내는 창작 행위가 될 수 있다. ## 감정이 만드는 경쟁 우위 - 기능이 비슷한 애플리케이션이 많아지면서 기능 목록만으로는 제품을 차별화하기 어려워졌다. - Andrew Hogan은 사용자가 제품과 맺는 감정적 관계와 정서적 공감이 새로운 경쟁력이라고 설명한다. - 특히 기술이 일상생활과 가족 경험에 깊이 들어올수록, 제품이 사용자에게 어떤 느낌과 기억을 남기는지가 중요해진다. - 감정적 반응은 우연히 생기는 것이 아니라 제품 로드맵에 포함해 의도적으로 설계해야 한다. - 유용성에 더해 즐거움, 신뢰, 애착, 의미를 제공하는 제품이 장기적으로 더 강한 브랜드와 사용자 관계를 구축할 수 있다. ## 정해진 로드맵에서 벗어나기 - 신제품 개발은 처음 세운 비전과 계획을 끝까지 고수하는 과정만은 아니다. - Avantika Gomes는 제품의 성공이 사전에 정한 로드맵뿐 아니라 개발 중 발생하는 예상 밖의 변화와 전환에도 달려 있다고 말한다. - 특정 솔루션을 지나치게 일찍 확정하면 새로운 사용자 요구나 시장 신호를 놓칠 위험이 있다. - 로드맵은 목표와 문제를 명확히 제시하되, 해결책과 실행 순서는 유연하게 바꿀 수 있어야 한다. - 팀은 실험 결과와 사용자 피드백에 따라 방향을 전환할 수 있는 여지를 계획 단계부터 확보해야 한다. ## 창의적 코딩과 웹의 표현력 - 개발자는 웹을 단순히 기능을 구현하는 플랫폼이 아니라 창작과 표현의 매체로 바라볼 필요가 있다. - Jake Albaugh는 창의적 코딩을 통해 웹이 가진 시각적·상호작용적 가능성을 다시 탐구하자고 제안한다. - 코드 기반 작업은 디자이너와 개발자의 협업을 넘어, 개발자 스스로 새로운 미학과 경험을 만들어내는 수단이 될 수 있다. - Henry Desroches와 같은 크리에이티브 코더의 작업은 기술적 구현과 예술적 표현이 결합될 수 있음을 보여준다. ## 제너럴리스트의 가치 - 직무가 세분화되는 동시에 기술과 제품 환경이 빠르게 변하면서 여러 분야를 연결하는 능력이 중요해지고 있다. - 콘텐츠 전략가 Carly Ayres는 디자인, 개발, 기획, 글쓰기 등 복수의 영역을 이해하는 하이브리드 인재의 가치를 강조한다. - 제너럴리스트는 한 분야의 깊이만 갖추기보다 서로 다른 전문성을 연결해 문제를 새롭게 정의하고 해결할 수 있다. - 복잡한 제품을 만들기 위해서는 직무 간 번역과 협업, 전체 맥락을 파악하는 능력이 점점 더 중요해진다. ## 포용적인 디자인으로 관점 확장하기 - 글은 디자인의 범위를 넓히고 더 많은 사람을 설계 과정에 포함해야 한다는 문제의식도 제시한다. - 포용성은 특정 사용자를 위한 부가 기능이 아니라 제품의 정의와 제작 방식 자체에 반영되어야 한다. - 다양한 배경과 경험을 가진 사람들이 참여할수록 기존 관습이 놓친 요구와 사용 방식이 드러날 가능성이 커진다. - 이는 더 많은 사용자가 접근할 수 있는 제품뿐 아니라, 문제를 바라보는 방식 자체를 확장하는 데 기여한다. ## 실천을 위한 방향 제품팀은 기능 추가와 일정 준수만을 성과 기준으로 삼기보다, 사용자가 느끼는 감정과 제품의 개성, 실험 가능성을 함께 평가하는 것이 좋다. 또한 로드맵에는 명확한 목표를 두되 해결책은 열어 두고, 개발자·디자이너·기획자·작가가 서로의 영역을 넘나들며 협업할 수 있는 환경을 마련해야 한다.

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

웹 개발Figma사용자 경험product-development+2

figma·2025년 1월 8일·4분 읽기큐레이션 요약

디지털 크리에이션의 미래를

피그마는 2025년 디지털 창작의 미래를 바라보며 개발, 디자인, 제품 전략, 브랜딩, 웹, 인재상에 관한 여섯 가지 메모를 제시한다. 글은 기술 발전만으로는 충분하지 않으며, 실험정신·감정·수작업의 가치·융합형 역량이 앞으로의 창작과 제품 경쟁력을 좌우한다고 주장한다. 각 메모는 피그마 구성원들이 업무 속에서 발전시킨 문제의식과 실천 방향을 공유하고, 독자에게도 자신의 메모를 작성해보라고 권한다. ## 메모라는 형식과 창작에 대한 관점 - 이 글의 제목은 이탈로 칼비노의 유고작 《다음 천년을 위한 여섯 가지 메모》에서 영감을 얻었다. - 칼비노는 문학의 미래를 위해 가벼움, 신속성, 정확성, 가시성, 다양성, 일관성 등의 가치를 제시했다. - 기술 업계에서 메모는 단순한 업무 문서를 넘어 전략적 방향, 제품 철학, 조직의 문제의식을 공유하는 장르로 발전했다. - 빌 게이츠의 그래픽 인터페이스 관련 선언, 스튜어트 버터필드의 Slack 전략 메모처럼 산업의 방향을 바꾼 사례도 있다. - 피그마에서는 Slack 스레드와 공유 문서가 감정, 제품 전략 비판, 산업 현상에 대한 관찰을 기록하는 비공식 메모로 기능한다. ## 개발자는 다시 창의적 코딩을 받아들여야 한다 - 현대 웹 브라우저는 많은 디자인 도구보다 더 넓은 표현 가능성과 기술적 기능을 제공한다. - 개발자는 이미 만들어진 템플릿과 정형화된 컴포넌트에만 의존하기보다 웹의 실험적 가능성을 적극적으로 탐색해야 한다. - 창의적 코딩은 단순히 시각적으로 아름다운 결과물을 만드는 일이 아니라, 코드와 브라우저를 창작 매체로 활용하는 방식이다. - 과거의 창의적 코딩 경험을 되돌아보며, 개발자가 실험과 우연성, 인터랙션을 다시 작업의 중심에 놓아야 한다고 제안한다. - 디자인 도구가 제공하는 범위를 넘어 브라우저의 애니메이션, 인터랙션, 계산 능력 등을 활용할 필요가 있다. ## 디자인의 정의를 확장해야 한다 - 디자인을 시각적 결과물을 만드는 직무에만 한정하지 말고, 문제를 구조화하고 경험을 설계하는 폭넓은 활동으로 바라봐야 한다. - 제품의 인터페이스뿐 아니라 시스템, 조직, 협업 방식, 콘텐츠와 커뮤니케이션도 디자인의 대상이 될 수 있다. - 복잡한 디지털 제품을 만들기 위해서는 디자이너뿐 아니라 개발자, PM, 작가, 분석가 등 다양한 역할이 디자인 과정에 참여해야 한다. - 디자인의 범위를 넓히면 특정 직군에 창의적 책임을 집중시키지 않고, 조직 전체가 사용자 경험과 결과물의 품질에 기여할 수 있다. ## 제품 로드맵에서 벗어나야 할 때 - 장기 로드맵은 방향성을 제공하지만, 모든 중요한 기회와 사용자 요구를 미리 예측할 수는 없다. - 시장 변화, 새로운 기술, 사용자의 예상 밖 행동이 나타났을 때는 기존 계획에서 벗어나는 판단이 필요하다. - 로드맵을 지키는 것 자체를 목표로 삼으면 실제 문제보다 계획 준수와 일정 관리가 우선될 수 있다. - 제품팀은 명확한 목표와 원칙은 유지하되, 목표에 도달하는 방법과 순서는 유연하게 조정해야 한다. - 계획 밖의 실험이나 우연한 발견을 제품 전략에 반영할 수 있는 여지를 남겨야 한다. ## 새로운 경쟁력은 감정이다 - 기능과 성능이 빠르게 평준화되는 환경에서는 감정적 경험이 제품을 차별화하는 요소가 된다. - 사용자가 제품을 편리하다고 느끼는 것을 넘어, 즐겁고 신뢰할 수 있으며 애착을 느끼게 만드는 것이 중요하다. - 브랜드의 말투, 인터랙션, 시각적 표현, 작은 세부사항이 제품에 대한 감정과 기억을 형성한다. - 생성형 AI와 자동화가 결과물 생산을 쉽게 만들수록, 인간적인 공감과 정서적 연결은 더 희소한 가치가 된다. - 경쟁 우위는 단순한 기능 목록보다 사용자가 제품을 사용하며 어떤 감정을 경험하는지에 의해 결정될 수 있다. ## 손으로 만든 웹을 위한 공간 - 자동화된 템플릿과 플랫폼 중심의 웹은 빠르고 효율적이지만, 개성과 우연성은 줄어들 수 있다. - 손으로 만든 웹은 완벽하게 표준화되지 않은 개인 사이트, 실험적인 인터랙션, 독특한 시각 언어를 포괄한다. - 웹 창작자는 규격화된 디자인 시스템만 따르기보다 자신만의 취향과 시행착오를 결과물에 남길 수 있다. - 개별 창작자의 관점과 수작업의 흔적은 획일화된 디지털 환경에서 차별화된 경험을 제공한다. - 웹의 미래는 대규모 서비스뿐 아니라 작고 독립적이며 실험적인 공간도 함께 보존할 때 더 풍부해진다. ## 제너럴리스트의 부상 - 복잡한 디지털 제품을 만들기 위해서는 한 분야의 깊은 전문성뿐 아니라 여러 분야를 연결하는 능력도 중요해진다. - 제너럴리스트는 디자인, 개발, 글쓰기, 분석, 제품 전략 등 서로 다른 영역을 이해하고 협업을 이어주는 역할을 한다. - AI가 개별 작업의 진입장벽을 낮추면서, 무엇을 만들지 정의하고 여러 요소를 통합하는 능력이 더욱 중요해진다. - 특정 직무의 경계에만 머무르기보다 다양한 기술과 관점을 조합하는 사람이 새로운 기회를 발견하기 쉽다. - 제너럴리스트의 강점은 모든 분야의 최고 전문가가 되는 것이 아니라, 서로 다른 전문성을 연결해 새로운 결과를 만드는 데 있다. 실무적으로는 로드맵을 절대적인 약속으로 여기지 말고 정기적으로 재검토하며, 브라우저와 코드로 작은 창작 실험을 시도하는 것이 좋다. 또한 기능 구현뿐 아니라 사용자의 감정, 결과물의 개성, 직군 간 연결 능력까지 제품 설계의 중요한 기준으로 삼을 필요가 있다.

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

웹 개발프로덕트 디자인design-toolscreative-coding+2