cloudflare·2026년 2월 20일원문

코드 모드: 1 (새 탭에서 열림)

Cloudflare에서 발표한 '코드 모드(Code Mode)'는 AI 에이전트가 방대한 API를 사용할 때 발생하는 컨텍스트 윈도우 낭비 문제를 해결하기 위한 혁신적인 접근 방식입니다. 개별 API 엔드포인트를 수천 개의 도구로 정의하는 대신, 에이전트가 직접 코드를 작성하고 실행하게 함으로써 단 1,000개의 토큰만으로 전체 Cloudflare API를 제어할 수 있게 합니다. 이 기술은 모델의 기억 공간을 보존하면서도 복잡한 연쇄 작업을 효율적으로 수행할 수 있는 높은 유연성을 제공합니다. ### 기존 MCP 방식의 한계와 코드 모드의 등장 * **컨텍스트 윈도우 포화 문제**: 모델 지시 프로토콜(MCP)에서 에이전트에게 너무 많은 도구를 제공하면 컨텍스트 윈도우가 가득 차서 실제 작업 수행에 필요한 공간이 부족해집니다. * **방대한 API의 비효율성**: Cloudflare API처럼 엔드포인트가 2,500개가 넘는 경우, 이를 모두 도구로 등록하려면 약 117만 개의 토큰이 필요하며 이는 최신 모델의 한계를 초과하는 수치입니다. * **코드 모드의 해결책**: 도구의 명세(Description)를 줄이는 대신, 에이전트가 SDK를 대상으로 코드를 작성하고 이를 안전한 샌드박스에서 실행하는 방식을 채택하여 토큰 사용량을 99.9% 절감했습니다. ### 핵심 인터페이스: search()와 execute() * **search() 도구**: 전체 OpenAPI 명세를 모델에 주입하는 대신, 모델이 자바스크립트 코드를 작성하여 명세 내에서 필요한 엔드포인트를 스스로 검색하게 합니다. 이를 통해 모델은 수천 개의 엔드포인트 중 당장 필요한 것만 식별할 수 있습니다. * **execute() 도구**: 에이전트가 실제 API 요청을 수행하는 자바스크립트 코드를 작성하여 실행합니다. 단순 호출뿐만 아니라 페이지네이션 처리, 응답 확인, 여러 작업을 하나로 묶는 체이닝(Chaining)이 가능합니다. * **고정된 토큰 비용**: API의 규모가 아무리 커져도 모델이 학습해야 할 도구는 이 두 가지뿐이므로, 약 1,000토큰의 고정된 비용만 발생합니다. ### 보안 및 실행 환경 (Dynamic Worker) * **V8 샌드박스 격리**: 에이전트가 작성한 코드는 파일 시스템 접근이나 환경 변수 유출이 불가능한 경량 V8 샌드박스인 'Dynamic Worker' 내부에서 실행됩니다. * **제한된 네트워크 접근**: 외부 호출(Fetch)은 기본적으로 비활성화되어 있으며, 필요에 따라 명시적으로 제어된 핸들러를 통해서만 외부와 통신할 수 있어 프롬프트 주입 공격으로부터 안전합니다. * **안전한 실행 흐름**: 모델이 직접 API 키를 다루지 않고 서버 측에서 정의된 안전한 환경에서 로직만 실행하므로 보안성이 높습니다. ### 실무 적용 사례: DDoS 방어 설정 * **엔드포인트 탐색**: 에이전트가 "DDoS 공격으로부터 내 사이트를 보호해줘"라는 요청을 받으면, `search()`를 통해 WAF 및 규칙 설정 관련 API 엔드포인트를 필터링합니다. * **복합 작업 수행**: 필터링된 엔드포인트 정보를 바탕으로 `execute()`를 호출하여 방화벽 규칙을 생성하고, 패키지를 업데이트하며, 설정을 확인하는 일련의 과정을 단 한 번의 도구 호출로 처리할 수 있습니다. 방대한 API를 다루는 서비스를 운영 중이라면 Cloudflare가 오픈소스로 공개한 **Code Mode SDK**를 활용해 보시기 바랍니다. 이를 통해 에이전트의 응답 속도를 높이고 운영 비용(토큰 사용량)을 획기적으로 줄이면서도 에이전트에게 서비스 전체에 대한 강력한 제어권을 부여할 수 있습니다.

JavaScriptAI 에이전트모델 컨텍스트 프로토콜Cloudflare Workers+3

github·2026년 2월 19일·4분 읽기큐레이션 요약

AI가 개발자의 선택을

AI는 단순히 코딩 속도를 높이는 도구를 넘어, 개발자가 선택하는 언어·프레임워크·도구 자체를 바꾸고 있다. GitHub의 Octoverse 2025 데이터에 따르면 TypeScript가 2025년 처음으로 Python과 JavaScript를 제치고 가장 많이 사용된 언어가 되었으며, 이는 AI가 복잡한 기술의 사용 장벽을 낮춘 결과로 해석된다. 따라서 조직은 AI의 생산성 향상뿐 아니라, AI가 증폭하는 아키텍처 품질과 기술 선택의 변화까지 관리해야 한다. ## 편의성이 개발자 선택을 바꾸는 과정 개발자는 사용하기 쉽고 마찰이 적은 기술을 반복적으로 선택하며, 이러한 선택이 생태계 전체의 흐름을 바꾼다. - 작업이 편리했던 경험은 기억에 남아 이후의 기술 선택에 영향을 준다. - GitHub 신규 개발자의 **80%가 첫 주 안에 Copilot을 사용**한다. - AI가 보일러플레이트와 문법 오류를 처리하면서, 복잡한 언어를 선택할 때의 비용이 감소했다. - 개발자는 “배우기 쉬운 기술”보다 “목적에 가장 적합하고 AI가 잘 지원하는 기술”을 선택하게 된다. ## TypeScript와 AI 친화적 기술의 성장 Octoverse 데이터는 AI가 실제 기술 채택에 영향을 주고 있음을 보여준다. - 2025년 8월, TypeScript가 GitHub에서 가장 많이 사용되는 언어가 되었다. - TypeScript 사용량은 전년 대비 **66% 증가**했다. - JavaScript 사용량은 **24% 증가**했다. - AI가 생성한 프로젝트에서 Shell 스크립트 사용량은 **206% 증가**했다. - 이는 개발자들이 Bash를 갑자기 선호하게 되었다기보다, AI가 Shell 사용의 문법적·인지적 부담을 줄였기 때문으로 볼 수 있다. ## 강한 타입 시스템이 AI 코드 생성에 유리한 이유 AI는 가능한 코드의 범위가 명확할수록 더 안정적인 결과를 생성할 수 있다. - JavaScript에서는 변수의 타입이 상황에 따라 무엇이든 될 수 있다. - TypeScript에서 `x: string`처럼 타입을 선언하면 문자열이 아닌 연산을 배제할 수 있다. - 이런 제약은 AI가 생성할 수 있는 코드의 공간을 줄이고, 문맥에 맞는 코드를 만들 가능성을 높인다. - 타입 검사는 오류를 줄이는 강력한 안전장치지만, 비즈니스 로직의 정확성까지 보장하지는 않는다. - GitHub의 공개 저장소 중 **110만 개 이상이 LLM SDK를 사용**하고 있어, 생성형 AI 연동은 실험 단계를 넘어 주류가 되었다. ## 빠른 개발과 아키텍처 품질의 균형 AI는 생산성을 크게 높이지만, 잘못된 설계도 더 빠르게 확산시킬 수 있다. - AI는 기존에 정립된 패턴을 따르는 데 강하고, 좋은 구조를 처음부터 설계하는 데는 상대적으로 약하다. - 초기 API 엔드포인트나 컴포넌트를 명확한 구조로 작성하면 이후 생성되는 코드도 그 패턴을 따를 가능성이 높다. - 반대로 불안정한 구조를 먼저 만들면 AI가 이를 반복·확장해 기술 부채를 키울 수 있다. - AI 지원 개발로 처리량이 **20~30% 증가**할 수 있지만, 그만큼 아키텍처의 일관성이 빠르게 무너질 위험도 커진다. ## 개발자와 팀을 위한 실천 방법 - **생성 전에 패턴을 정한다.** API, 컴포넌트, 디렉터리 구조, 오류 처리 방식 등을 먼저 정의한다. - **타입 시스템을 가드레일로 활용한다.** 타입 통과를 완전한 정합성의 증거로 간주하지 않는다. - **AI 생성 코드를 더 엄격하게 테스트한다.** 코드가 자연스럽고 초기 검사를 통과하더라도 테스트와 리뷰를 생략하지 않는다. - **템플릿과 문서를 표준화한다.** AI가 참고할 수 있도록 템플릿 저장소와 명시적인 아키텍처 결정을 제공한다. ## 엔지니어링 리더가 관리해야 할 지표 AI 도입의 성공 여부는 단순한 코드 생성량이나 자동완성 수락률만으로 판단하기 어렵다. - Copilot 사용 지표를 통해 일·주간 활성 사용자, 에이전트 사용률, 추가·삭제된 코드 라인, 언어·모델별 사용 패턴을 확인한다. - 에이전트 사용률은 높은데 특정 팀의 결함이 증가한다면 프롬프트 교육이나 코드 리뷰 기준을 강화해야 한다. - 특정 언어나 모델에서 결함률이 높다면 해당 기술 선택과 사용 방식을 재검토할 수 있다. - Copilot API를 이용하면 사용자 단위 데이터를 기반으로 조직에 맞는 대시보드를 구축할 수 있다. - 개발 속도가 빨라질수록 시니어 엔지니어의 아키텍처 검토와 품질 관리 역량은 더욱 중요해진다. AI를 도입할 때는 “얼마나 많은 코드를 만들었는가”보다 “어떤 구조와 품질의 코드를 만들었는가”를 관리해야 한다. TypeScript 같은 강한 제약의 도구와 명확한 개발 패턴을 기반으로 AI를 활용하고, 테스트·리뷰·품질 지표를 함께 운영하는 것이 실용적인 접근이다.

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

JavaScriptTypeScriptPythongithub-copilot+4

spotify·2026년 2월 19일원문

2025년 Spotify FOSS (새 탭에서 열림)

스포티파이는 자사 기술 스택의 근간이 되는 오픈소스 생태계를 지원하기 위해 2025년 '스포티파이 FOSS Fund' 수혜 프로젝트로 FFmpeg, MSW(Mock Service Worker), Xiph.Org 재단을 선정했습니다. 이번 펀딩은 대규모 멀티미디어 인프라부터 개인 개발자가 주도하는 테스팅 도구까지 다양한 규모의 프로젝트에 실질적인 금전적 지원을 제공함으로써 오픈소스의 지속 가능성을 확보하는 데 목적이 있습니다. 스포티파이는 이를 통해 자사가 의존하는 핵심 기술에 보답하고, 자원봉사자 중심으로 운영되는 오픈소스 환경의 안정적인 성장을 돕고자 합니다. ### 멀티미디어 인프라의 핵심, FFmpeg (3만 유로 지원) * **프로젝트 위상:** FFmpeg은 지난 25년간 멀티미디어 인코딩, 디코딩, 트랜스코딩, 스트리밍 분야에서 중추적인 역할을 해온 핵심 인프라입니다. 유튜브, 넷플릭스, 스포티파이 등 세계적인 서비스들이 이 기술에 의존하고 있습니다. * **비전과 목표:** "현존하는 모든 멀티미디어 파일을 재생하는 것"을 목표로 하며, 취미로 영상을 편집하는 개인부터 거대 기업까지 누구나 사용할 수 있는 범용성을 지향합니다. * **자금 활용 계획:** 지원금은 개발용 하드웨어 구매, 컨퍼런스 참가 비용, 그리고 새로운 개발 프로젝트를 추진하는 데 투입될 예정입니다. * **지속 가능성에 대한 제언:** 메인테이너 Kieran은 오픈소스의 장기적인 유지를 위해 기업들이 정규직 개발자를 고용해 프로젝트에 투입하거나, 일회성이 아닌 반복적인 펀딩 구조를 마련해야 한다고 강조했습니다. ### API 모킹의 표준, MSW (1.5만 유로 지원) * **프로젝트 역할:** Mock Service Worker(MSW)는 JavaScript/TypeScript 생태계에서 API 모킹을 가능하게 하여 유닛 테스트를 쉽고 유용하게 만들어주는 도구입니다. 현재 Artem Zakharchenko가 1인 풀타임 메인테이너로 운영하고 있습니다. * **최근 기술적 성과:** 2025년에는 네트워크 레이어(node:net)에서 동작하는 새로운 'Interceptors' 아키텍처를 도입하고, 사용자 요청이 많았던 서버-전송 이벤트(SSE) 지원 기능을 추가했습니다. * **미래 로드맵:** 2026년에는 기술적 난제가 많았던 '원격 요청 가로채기(Remote request interception)' 기능을 완성하고, 요청 가로채기 방식을 완전히 새롭게 정의하는 내부 아키텍처 개편을 단행할 계획입니다. * **개발자 지원:** 지원금은 메인테이너의 생계 유지뿐만 아니라, 외부 기여자들이 지속적으로 프로젝트에 참여할 수 있도록 재정적으로 보상하는 방안을 마련하는 데 사용됩니다. ### 오픈소스 생태계 지원의 다양성 * **조직 규모의 차이:** FFmpeg과 Xiph.Org는 다수의 메인테이너가 참여하는 대규모 프로젝트인 반면, MSW는 개인 개발자가 주도하는 프로젝트입니다. 스포티파이는 규모와 상관없이 생태계에 끼치는 영향력을 기준으로 지원 대상을 선정했습니다. * **기업의 역할 확대:** 프로젝트 관계자들은 기업들이 'Open Source Pledge'와 같은 이니셔티브에 참여하여 오픈소스 소프트웨어를 단순 소비하는 주체에서 지원하는 주체로 변화해야 한다고 입을 모았습니다. 기업이 오픈소스를 활용해 비즈니스를 운영한다면, 해당 프로젝트의 지속 가능성을 위해 실질적인 자금을 투입하는 것은 선택이 아닌 필수적인 투자입니다. FFmpeg과 같은 기반 기술뿐만 아니라 MSW처럼 개발 생산성을 높여주는 도구들에 대해서도 정기적인 후원과 관심을 기울이는 것이 생태계 전체의 건강함을 유지하는 길입니다.

JavaScriptTypeScriptunit-testingstreaming+4

gitlab·2026년 2월 19일원문

GitLab 위협 인텔리 (새 탭에서 열림)

GitLab 위협 인텔리전스 팀은 북한 연계 위협 그룹이 수행하는 '전염성 인터뷰(Contagious Interview)'와 가짜 IT 개발자 취업 캠페인의 세부 수법을 공개하고, 이들이 GitLab 플랫폼을 어떻게 악용했는지 분석했습니다. 북한 해커들은 채용 담당자로 위장해 개발자들에게 악성 코드가 포함된 기술 과제를 실행하도록 유도하며, 이를 통해 자금 탈취와 자격 증명 절취를 시도하고 있습니다. GitLab은 2025년 한 해 동안 130개 이상의 관련 계정을 차단했으며, 이들의 인프라 분석을 통해 확보한 지표를 공유하여 보안 커뮤니티의 대응 역량 강화를 촉구했습니다. **전염성 인터뷰(Contagious Interview)의 실체** * **공격 방식:** 해커들이 구인 구직 플랫폼에서 채용 담당자로 위장해 개발자에게 접근한 뒤, 기술 면접을 빙자하여 악성 코드가 포함된 프로젝트를 내려받아 실행하도록 유도합니다. * **주요 악성코드:** 주로 BeaverTail과 Ottercookie로 알려진 JavaScript 기반의 악성코드 패밀리가 사용됩니다. * **피해 결과:** 개발자의 장비에 대한 원격 제어 권한을 획득하고, 암호화폐 지갑 정보나 로그인 자격 증명을 탈취하여 금융 자산 절도 및 내부 네트워크 침투의 발판으로 삼습니다. **2025년 캠페인 추세 및 주요 특징** * **공격 규모:** 2025년 한 해 동안 총 131개의 북한 연계 위협 계정이 차단되었으며, 특히 9월에 공격 활동이 정점에 달했습니다. * **인프라 활용:** 공격자의 90%가 Gmail 계정을 사용해 GitLab에 가입했으며, 탐지를 피하고자 소비자용 VPN이나 전용 VPS 인프라를 통해 접속했습니다. * **타겟 산업:** 주로 암호화폐, 금융, 부동산 분야의 개발자를 타겟팅했으나, 최근에는 AI 및 게임 산업으로도 범위를 넓히고 있습니다. * **외부 서비스 악용:** 악성 페이로드를 GitLab에 직접 저장하지 않고, Vercel과 같은 합법적인 호스팅 서비스나 커스텀 도메인을 활용해 외부에서 불러오는 방식을 취했습니다. **악성 코드 삽입 및 은닉 기술** * **환경 변수 위장:** `.env` 파일 내에 악성 페이로드 URL과 헤더 값을 Base64로 인코딩하여 일반적인 설정값처럼 보이게 위장합니다. * **동적 코드 실행:** `Function.constructor`를 사용하여 문자열 형태의 원격 콘텐츠를 실행 가능한 코드로 로드하는 커스텀 에러 핸들러 기법을 사용합니다. * **최신 변종 기법:** VS Code 작업을 통한 악성 쉘 명령 실행, 가짜 폰트 파일 내에 숨겨진 바이너리 데이터 디코딩, 프로젝트 실행 직전에 생성된 악성 NPM 종속성 활용 등의 수법이 관찰되었습니다. **가짜 IT 노동자 운영 사례** * **신분 위조 파이프라인:** 최소 135개의 가짜 페르소나를 생성하는 자동화된 파이프라인을 구축하여 전문적인 인맥을 형성하고 구인 제안을 수집했습니다. * **신분증 조작:** 도용된 미국 시민권자의 신분증에 자신의 사진을 합성하여 21개의 고유한 가짜 신분을 관리하는 사례가 발견되었습니다. * **글로벌 거점:** 러시아 모스크바 등 해외 거점에서 활동하며 미국 내 조력자를 모집하고, 제재를 피하면서 미국 기업으로부터 수익을 창출하고 있습니다. 개발자들은 신뢰할 수 없는 출처에서 제공된 기술 면접용 코드 프로젝트를 실행할 때 각별히 주의해야 합니다. 특히 `.env` 파일에 인코딩된 의심스러운 문자열이 있거나, 프로젝트 실행 시 외부 URL에서 콘텐츠를 불러오는 로더가 포함되어 있는지 철저히 검증하는 보안 습관이 필요합니다.

JavaScript데이터베이스 설계gitlabnpm+3

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

딜런 필드가 전하는

Figma의 성장에는 창업자 Dylan Field의 다양한 경험과 우연한 계기, 그리고 실패에서 배우는 태도가 영향을 미쳤다. 아역 배우 시절의 경험, 수학적 사고를 키워준 멘토, 독특한 Thiel Fellowship 지원서, 초기 아이디어의 방황, 젊은 CEO로서의 시행착오가 Figma의 창업과 발전에 연결됐다. 글은 성공이 단번에 완성되는 것이 아니라 끈기와 실험, 성장 과정을 통해 만들어진다는 점을 보여준다. ## 배우 경험이 길러준 끈기 - Dylan은 1990년대 후반 캘리포니아 소노마 카운티에서 아역 배우로 활동했다. - Peter Pan 공연 중 무대에서 잠든 일은 본인이 꼽는 가장 당황스러운 연기 경험이었다. - 하지만 공연에서 얻은 와이어 비행 경험 덕분에 훗날 Windows XP 광고에 출연할 수 있었다. - 오디션 경험을 통해 “오랜 시간 계속 시도하는 사람이 결국 이긴다”는 태도를 배웠다. ## 학교 관리인이 키운 수학적 호기심 - Dylan은 6살 때부터 대수 문제를 풀 정도로 수학에 관심이 많았다. - 중학교 수업이 지루해 학교 관리인과 시간을 보내곤 했다. - 수학과 물리학에 관심이 많았던 관리인은 Dylan에게 여러 개념을 설명해 주었다. - 특히 단순 계산보다 증명이 중요하다며 집합론을 공부해 보라고 권했다. - 이 경험은 Dylan이 수학을 공식 암기가 아니라 논리와 구조를 탐구하는 학문으로 바라보는 데 영향을 주었다. ## 초콜릿에 대한 괴상한 답변과 Thiel Fellowship - Thiel Fellowship 지원서는 “대부분의 사람들이 무엇을 잘못 생각하고 있는가”를 물었다. - Dylan은 “초콜릿은 역겹다”라고 답하고, 그 주장을 진지하게 논증하는 에세이를 작성했다. - 일반적인 통념을 뒤집으면서도 유머와 논리를 결합한 답변이 심사위원의 관심을 끌었을 가능성이 있다. - Dylan은 이를 실리콘밸리의 반(反)주류 사고를 다시 뒤집은 “메타-contrarian” 접근이라고 설명했다. - Fellowship을 받으면서 Brown University를 중퇴하고 Evan Wallace와 함께 창업에 전념하게 됐다. ## WebGL을 활용하려다 만든 밈 생성기 - Dylan과 Evan은 WebGL을 이용해 웹에서 고성능 그래픽을 구현하는 디자인 도구를 만들고 싶어 했다. - 그러나 기술을 먼저 확보한 뒤 용도를 찾으려 하면서 방향을 잃었다. - 한때 WebGL이라는 “망치”에 맞는 “못”으로 밈 생성기를 고려했다. - Dylan은 밈 시장의 성장 데이터를 근거로 밈 제작 서비스를 만들자고 주장했다. - 이 아이디어는 약 5일간 이어졌지만, 두 사람은 곧 더 본질적인 제품을 만들어야 한다는 결론에 도달했다. - 이 짧은 방황은 Figma가 초기부터 명확한 제품 비전을 가지고 출발한 것은 아니었음을 보여준다. ## 스무 살 CEO로서의 성장통 - Dylan은 이전 직함이 인턴이었을 정도로 어린 나이에 CEO가 됐다. - 제품 경험의 세부 사항을 직접 고민해 왔기 때문에 초기에는 모든 일을 통제하려는 경향이 있었다. - 본인도 당시의 경영 방식을 “마이크로매니징”이라고 표현했다. - 빠르게 제품을 출시해야 한다는 압박감이 통제 욕구를 더욱 키웠다. - 이후 사무실에서의 긴장된 상황 등을 겪으며, 제품에 대한 높은 기준과 팀에 대한 신뢰 사이의 균형을 배워갔다. - 공개된 내용에서는 Figma의 UI를 만들기 위해 드롭다운, 컴포넌트, 효과 등을 화이트보드에 반복적으로 탐색한 과정도 소개된다. Figma의 사례는 창업자의 이력이 반드시 한 방향으로만 이어질 필요는 없다는 점을 보여준다. 낯선 경험에서 얻은 끈기와 논리적 사고, 과감한 실험, 초기의 실패를 인정하고 방향을 수정하는 태도가 새로운 제품을 만드는 데 실질적인 자산이 될 수 있다.

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

JavaScriptFigma프로덕트 디자인사용자 인터페이스+2

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

버전 관리: 피그마

Figma의 Layers 패널에 가로 스크롤을 추가하는 일은 단순한 UI 개선이 아니었다. 계층 구조, 접기·펼치기와 잠금·숨김 상태, 가상화 렌더링, 다양한 텍스트 길이와 다중 스크롤 방향이 서로 얽혀 있었기 때문이다. Figma 팀은 세 가지 프로토타입을 시험하며 사용자의 계층 구조 인식과 작업 맥락을 해치지 않는 방향을 탐색했다. ## 가로 스크롤이 어려웠던 이유 - Layers 패널은 자주 사용되고 신뢰성이 중요해 작은 동작 변화도 신중해야 했다. - 레이어는 정적인 목록이 아니라 다음과 같은 상태를 가진다. - 숨김·잠금 - 계층 접기·펼치기 - 부모·자식 관계 - 성능을 위해 현재 화면에 보이는 레이어만 렌더링하는 **가상화**가 적용되어 있었다. - 세로로 스크롤하면 새 레이어가 렌더링되고, 레이어 이름 길이가 달라져 가로 스크롤 영역과 정렬이 복잡해졌다. - 핵심 목표는 단순히 콘텐츠를 옮기는 것이 아니라 사용자가 현재 계층상의 위치와 “더 볼 내용이 있음”을 계속 이해하도록 하는 것이었다. - 디자이너 Giorgio Caviglia는 JavaScript, HTML, CSS, React로 직접 프로토타입을 만들어 수천 개 레이어와 다양한 상호작용을 실제로 검증했다. ## 첫 번째 시도: 화면 왼쪽의 보이지 않는 레이어 표시 - 레이어가 패널의 왼쪽 위나 오른쪽 아래 경계를 벗어나면 해당 위치에 아이콘을 표시하는 대칭형 UI를 실험했다. - 아이콘을 패널 가장자리에 고정하는 것은 쉬웠지만, 레이어 이름이 스크롤될 때 배경이 일부 요소 아래로 지나가고 다른 텍스트는 가려야 했다. - 컴포넌트가 위에 놓인 요소의 정확한 위치를 알지 못해 다음 문제가 발생했다. - 배경이 텍스트를 제대로 덮지 못함 - 레이어 행 구조와 불투명 배경 처리가 충돌함 - 스크롤 상태에 따라 시각적 가림 처리가 달라짐 - 디자인 측면에서도 왼쪽 상단에 레이어 이름의 끝부분이 들쭉날쭉하게 남아 시각적으로 어색했다. - 결과적으로 대칭성을 유지하려던 해결책이 새로운 문제를 만들었고, 패널 상단의 빈 공간을 어떻게 다룰지 재검토하게 됐다. ## 두 번째 시도: 선택한 레이어로 자동 스크롤 - 캔버스에서 선택한 레이어가 Layers 패널에 보이지 않으면 해당 레이어가 패널 중앙에 오도록 자동으로 가로 스크롤하는 방식을 실험했다. - 이론적으로는 편리했지만, 실제 사용에서는 가로와 세로 스크롤이 동시에 발생해 사용자가 현재 위치를 잃었다. - 특히 깊게 중첩된 레이어를 선택하면 부모 레이어가 화면에서 사라져 계층 구조를 파악하기 어려웠다. - 사용자는 작업 대상의 이름뿐 아니라 다음 정보도 함께 확인해야 한다. - 어떤 부모 아래에 있는지 - 계층상 어디에 위치하는지 - 특정 컴포넌트의 일부인지 - 화면을 갑자기 다른 위치로 이동시키는 동작은 Google Maps가 주행 중 지도를 갑자기 다른 장소로 옮기는 것과 비슷한 혼란을 유발했다. - 도구가 사용자를 돕기보다 현재 작업에 대한 정신적 모델을 깨뜨리는 결과가 되어 채택되지 않았다. ## 세 번째 시도: 레이어 이름 변경 중 스크롤 - 가로 스크롤 도입으로 레이어 이름을 편집하는 동안 다른 레이어로 스크롤할 때의 동작도 새롭게 정의해야 했다. - 사용자가 이름 입력 중 다른 레이어를 보기 위해 스크롤하면, 입력 중인 텍스트를 자동으로 새 이름으로 확정하는 방안을 검토했다. - 그러나 스크롤은 이름 변경을 확정했다는 충분히 강한 신호가 아니었다. - 이 동작을 채택하면 사용자가 의도하지 않게 레이어 이름을 변경할 위험이 있었다. - 따라서 스크롤과 편집 확정의 관계를 별도로 설계해야 한다는 점이 드러났다. ## 실용적인 시사점 - 복잡한 UI에서는 정적인 화면 설계만으로 모든 상태를 예측하기 어렵기 때문에 실제 코드 기반 프로토타이핑이 유용하다. - 자동 이동은 편리함보다 사용자의 공간적·계층적 맥락 보존을 우선해야 한다. - 스크롤, 선택, 편집처럼 서로 다른 의도를 가진 동작을 하나의 암묵적 신호로 처리하면 오작동과 혼란이 발생한다. - 특히 가상화된 계층형 UI에서는 렌더링 구조, 텍스트 가림, 상태 변화까지 함께 고려해야 한다.

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

JavaScriptFigma사용자 인터페이스React+4

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

강력해진 디스

Discord는 React Native 기반 모바일 앱의 성능을 높이기 위해 사용 빈도가 높은 화면과 컴포넌트를 집중적으로 최적화했다. 서버 목록 가상화, 채팅 리스트 재활용, Android 이모지 피커 네이티브 전환, 이미지 포맷 변경 등을 통해 메모리 사용량과 시작 시간, 스크롤 성능을 개선했다. 특히 저사양 Android 기기에서 발생하던 빈 프레임과 앱 충돌을 줄이는 데 초점을 맞췄으며, 일부 기능은 플랫폼별로 다른 구현을 유지하는 비용까지 감수했다. ## React Native 전환과 성능 최적화 방향 - Discord는 데스크톱에 React, 모바일에 React Native를 사용해 여러 플랫폼에서 기능을 빠르게 출시해 왔다. - Android에서는 초기 성능 우려 때문에 React Native 도입을 주저했지만, Android 기기 성능 향상과 Hermes 엔진 등장으로 2022년 React Native 기반으로 전환했다. - 전환 후 특히 저사양 기기의 시작 시간이 문제였으나, 2023년에 중앙값 기준 시작 시간을 절반으로 줄였다. - 이후에는 일반 사용자보다 서버와 메시지, 이모지를 많이 사용하는 ‘파워 유저’를 중심으로 최적화를 진행했다. ## 서버 목록 가상화 - 기존 서버 목록은 화면에 보이지 않는 서버의 뷰와 아이콘까지 모두 메모리에 유지했다. - Discord는 무료 사용자 최대 100개, Nitro 사용자 최대 200개의 서버 가입을 지원하기 때문에 서버가 많은 사용자의 메모리 부담이 컸다. - 새 가상화 구현은 현재 화면에 표시되는 서버 정보만 메모리에 유지한다. - 남은 리소스를 드래그 앤 드롭 애니메이션 개선에도 활용했다. - 서버가 100개 이상인 사용자는: - 시작 시 메모리 사용량 14% 감소 - 전체 시작 시간 10% 감소 ## 네이티브 채팅 리스트 최적화 - 채팅 리스트는 이미 네이티브로 구현되어 있었지만, 프로파일링을 통해 로딩과 스크롤 과정의 병목을 추가로 발견했다. - 주요 개선 사항: - 버튼 같은 Application Component와 이미지 격자형 Media Mosaic 재활용 - 스포일러, 업로드 오버레이처럼 자주 사용되지 않는 요소의 지연 생성 - Media Mosaic 바인딩 성능 개선 - 메시지 컨테이너와 리액션 측정 속도 개선 - 채팅을 열기 전에 자주 사용되는 요소를 재활용 풀에 미리 생성 - 결과적으로: - 느린 프레임이 최대 60% 감소 - 구형 기기에서 렌더링 프레임 수 증가 - 채팅 리스트 메모리 사용량 약 12% 감소 ## Android 이모지 피커의 네이티브 전환 - 서버 하나당 최대 250개의 커스텀 이모지를 지원하며, 여러 서버를 사용하는 경우 수백 개의 이모지가 한 화면에 표시될 수 있다. - 저사양 Android 기기에서는 이모지를 스크롤할 때 placeholder조차 표시되지 않는 빈 프레임 문제가 발생했다. - 단순한 점진적 최적화만으로는 해결하기 어렵다고 판단해 Android 이모지 피커를 네이티브로 다시 작성했다. - 200개 서버의 이모지를 사용하는 극단적인 테스트에서도: - 빈 프레임이 완전히 제거됨 - 저가형 기기에서도 일관되게 부드러운 스크롤 제공 - 메모리 부족으로 인한 충돌 방지 - Android는 네이티브, iOS는 React Native로 유지하게 되어 코드베이스와 유지보수 복잡성이 증가했다. - 향후 React Native New Architecture와 Android 기기 성능 향상에 따라 이 구조를 재검토할 예정이다. ## GIF에서 WebP로 전환 - 미디어 프록시에 애니메이션 WebP 지원을 추가했다. - 애니메이션 이모지 포맷을 GIF에서 WebP로 변경해 저사양 기기에서도 최대 60FPS 렌더링이 가능해졌다. - 이미지 포맷 선택만으로도 디코딩과 렌더링 성능을 개선할 수 있음을 보여주는 사례다. ## ChannelList의 빈 화면 문제 제거 - Discord는 자체 React Native 리스트 구현인 FastList를 사용해 왔다. - 모바일 앱 재설계 과정에서 Shopify의 FlashList를 도입했으며, 정확한 요소 크기를 미리 지정하지 않아도 되는 점과 빠른 개발 속도를 장점으로 평가했다. - 그러나 실제로는 저사양 Android 기기에서 FlashList가 더 자주 빈 화면을 표시하는 문제가 나타났다. - Discord는 다시 FastList를 리팩터링해 ChannelList에 적용했고, 50달러 수준의 저가형 기기에서도 빈 화면 문제를 제거했다. ## 적용할 수 있는 성능 개선 원칙 - 화면에 보이지 않는 요소는 가상화해 메모리에 보관하지 않는다. - 반복적으로 생성되는 UI는 재활용 풀과 recycling을 활용한다. - 자주 사용되지 않는 UI는 lazy inflation으로 늦게 생성한다. - 성능 문제가 심각한 경우 기존 프레임워크를 무리하게 유지하기보다 특정 화면을 네이티브로 재작성할 수 있다. - 평균적인 기기뿐 아니라 저사양 기기와 파워 유저의 극단적인 사용 시나리오를 기준으로 테스트해야 한다. - 범용 라이브러리가 항상 최선은 아니므로 실제 기기에서 blanking, 프레임 저하, 메모리 부족 여부를 검증해야 한다. Discord의 사례는 React Native를 전면적으로 포기하거나 모든 기능을 네이티브로 바꾸기보다, 병목이 명확한 부분만 가상화·재활용·지연 로딩·네이티브 구현으로 보완하는 접근을 보여준다. 특히 저사양 기기에서의 실제 사용자 경험을 기준으로 성능을 측정하고, 필요하다면 플랫폼별 구현 차이를 유지하는 것이 실용적인 전략이다.

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

JavaScriptAndroidReact Nativewebp+4

datadog·2024년 5월 23일원문

정적 분석기를 Java에서 Rust로 마이그레이션한 방법 (새 탭에서 열림)

Datadog은 정적 분석 도구의 성능 병목 현상을 해결하고 제한된 CI 환경에서의 효율성을 극대화하기 위해 기존 Java 기반의 엔진을 Rust로 완전히 재작성했습니다. 이 과정에서 ANTLR 대신 Tree-sitter를 도입하고 JavaScript 규칙 실행 엔진을 GraalVM에서 Deno(V8)로 교체함으로써, 분석 속도는 3배 향상시키고 메모리 사용량은 10배 절감하는 성과를 거두었습니다. 결과적으로 이번 전환은 고성능 정적 분석을 위해 언어와 런타임 수준의 근본적인 변화가 필수적이었음을 보여줍니다. **Java 기반 정적 분석기의 한계와 환경적 제약** * **CI 자원 최적화 문제:** 고객의 CI 환경(예: GitHub Actions)에서 분석기를 실행할 때, 2코어 및 7GB RAM과 같은 제한된 자원 내에서 Java 분석기는 수천 개의 파일을 스캔하는 데 5분 이상 소요되어 목표치(3분 이내)를 충족하지 못했습니다. * **환경 충돌 및 오버헤드:** Java 기반 분석기는 최신 JVM(17+)을 요구하는데, 이는 고객의 기존 CI 환경에 설치된 Java 버전과 충돌을 일으키거나 불필요한 설정 부담을 주었습니다. * **파싱 성능 저하:** 기존에 사용하던 ANTLR은 대규모 저장소에서 파싱 속도가 느렸고, 특정 언어에 대한 지원이 부분적이라는 기술적 한계가 있었습니다. **Tree-sitter 도입과 Rust로의 전환 결정** * **파서 교체:** 성능 향상을 위해 C로 구현되어 속도가 빠르고 오픈소스 커뮤니티가 활발한 Tree-sitter를 채택했습니다. * **Java 라이브러리의 한계:** Tree-sitter용 Java 라이브러리는 분석기 최적화에 필수적인 패턴 매칭 기능을 지원하지 않는 등 기능이 제한적이었습니다. * **언어 선택의 기로:** Tree-sitter가 가장 견고하게 지원하는 언어가 Rust라는 점에 착안하여, 예측 가능한 성능을 위해 Rust로의 전체 재작성이라는 도전적인 경로를 선택했습니다. **Rust 기반의 새로운 아키텍처 구성** * **AST 구축(Tree-sitter):** Rust는 Tree-sitter 생태계의 "일등 시민(First-class citizen)"으로, 직접적인 라이브러리 연동을 통해 별도의 Java 바인딩 유지보수 없이도 강력한 파싱 기능을 확보했습니다. * **자바스크립트 규칙 실행(Deno):** 정적 분석 규칙은 자바스크립트로 작성되는데, 기존 Java의 GraalVM 대신 Deno(deno-core)를 런타임으로 도입했습니다. * **보안 및 효율성:** Deno의 V8 엔진을 활용하되, 분석 규칙이 디스크나 네트워크에 접근하지 못하도록 `deno-core` 크레이트만 통합하여 보안이 강화된 샌드박스 환경을 구축했습니다. **마이그레이션 결과 및 기술적 권고** 성공적인 Rust 전환을 통해 동일한 프로그램에 대해 Java 버전과 일치하는 분석 결과를 보장하면서도 성능은 3배, 메모리 효율은 10배 개선되었습니다. 특히 리소스가 제한된 CI/CD 파이프라인에서 정적 분석 도구를 운영해야 한다면, JVM과 같은 무거운 런타임보다는 Rust와 같이 저수준 제어가 가능하고 메모리 오버헤드가 적은 언어를 선택하는 것이 장기적으로 유리합니다.

JavaScript데이터베이스 설계CI/CDRust+4

figma·2024년 4월 15일·3분 읽기큐레이션 요약

디자인 시스템을 위한 올바

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나 자동 생성 코드보다 조직의 표준 컴포넌트가 우선 노출되도록 구성해야 도입 효과를 극대화할 수 있다.

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

JavaScriptFigma디자인 시스템TypeScript+4

figma·2021년 11월 3일·3분 읽기큐레이션 요약

빌드 비하인드: 개발

Tekeste Kidanu는 디자이너의 생산성을 높이는 Figma·FigJam 플러그인과 위젯을 개발하며, 커뮤니티의 요구에서 제품 아이디어를 얻는 개발자다. 대표작인 SPELLL은 문서의 맞춤법과 문법 오류를 찾아 수정하도록 돕고, FigJam용 Notes·색상 선택기·투표 위젯 등으로 영역을 확장하고 있다. 그는 Figma 플러그인 API가 기존 JavaScript·웹 개발 지식만으로도 접근하기 쉽고, 공개 플랫폼 전환이 더욱 다양한 창작물을 이끌 것이라고 기대한다. ## 개발자 배경과 디자인 학습 - Tekeste Kidanu는 `tkmadeit`이라는 이름으로 활동하는 프론트엔드 개발자다. - 2016년 미국으로 이주해 컴퓨터 과학을 공부했으며, 웹 기술에 관심이 많다. - Figma 플러그인을 만들면서 디자인 자체에도 흥미를 느끼게 됐다. - 좋은 UI를 구별하는 것에서 나아가 직접 디자인하기 위해 색채 이론과 타이포그래피 같은 UI 디자인 기초를 학습하고 있다. ## SPELLL: Figma·FigJam용 맞춤법 검사기 - 대표 플러그인인 SPELLL은 Figma와 FigJam 문서의 철자 및 문법 오류를 검사한다. - Grammarly와 유사하게 오류를 찾아내고 사용자가 쉽게 수정할 수 있게 한다. - 디자이너가 파일을 수동으로 검토하는 시간을 줄이고, 발표나 공유 과정에서 오탈자로 곤란을 겪는 일을 방지하는 것이 목표다. - Figma뿐 아니라 FigJam에서도 사용할 수 있도록 확장됐다. ## 커뮤니티에서 얻는 아이디어 - 플러그인 아이디어는 Figma Forum, Designer News, Twitter 등 디자인 커뮤니티에서 주로 얻는다. - 사용자들이 요청하는 기능과 반복적으로 제기되는 불편을 관찰해 실제 수요가 있는 문제를 찾는다. - Figma 공식 계정의 트윗이나 디자이너들의 기능 요청도 중요한 영감의 원천이다. - Friends of Figma와 같은 Slack 커뮤니티에서는 실제 Figma 사용자를 만나고 요구사항을 파악할 수 있다. - 새 플러그인을 구상할 때 Twitter나 포럼에서 기능 요청을 검색해보는 방법을 추천한다. ## Figma 플러그인 API로 시작하기 - 먼저 플러그인이 어떤 방식으로 동작해야 하는지 조사한 뒤 개발에 착수했다. - Figma 플러그인 API 공식 문서를 읽으며 기능과 구조를 익혔다. - Figma Plugins Slack 워크스페이스에서 질문하고 다른 개발자들의 도움을 받았다. - 디자인 플러그인을 처음 만들었지만, 기존 JavaScript와 웹 개발 경험만으로도 시작할 수 있었다. - API가 직관적이고 진입 장벽이 낮았다는 점을 개발 과정에서 가장 놀라운 부분으로 꼽았다. ## FigJam으로의 확장 - FigJam이 플러그인을 지원한다는 소식을 듣고 기존 Figma 플러그인을 FigJam으로 이전하기 시작했다. - Figma와 FigJam의 API 및 개발 절차가 거의 비슷해 확장이 수월했다. - 이를 통해 하나의 플러그인 개발 경험을 두 협업 도구로 넓힐 수 있었다. - Figma가 기본 기능으로 제공하지 않는 기능도 플러그인 API를 통해 먼저 구현할 수 있다는 점을 활용했다. ## Notes와 색상 선택기 위젯 - Notes는 FigJam 보드 안에서 상세한 메모를 작성할 수 있는 위젯이다. - 일반 텍스트와 Markdown 형식을 지원한다. - 보드 위에 메모를 직접 배치해 화면을 복잡하게 만들지 않고 별도로 정리할 수 있도록 설계됐다. - FigJam용 색상 선택기는 사용자가 원하는 색상의 스티키와 도형을 만들도록 돕는다. ## 투표 위젯과 향후 계획 - Tekeste는 FigJam용 투표 위젯의 첫 버전을 공개했다. - 익명 투표와 실명 투표를 모두 지원한다. - 기존 기능을 계속 개선해 최고의 투표 위젯으로 발전시키는 것이 목표다. - 앞으로는 FigJam 파일 참여자들이 현재 듣고 있는 음악을 보여주는 위젯도 만들어보고 싶다고 밝혔다. ## 공개 플랫폼에 대한 기대 - Figma는 내부에서 몇 주간 위젯을 개발한 뒤 외부 개발자 커뮤니티에도 API를 개방했다. - Tekeste는 FigJam 플러그인과 위젯의 공개 출시가 다양한 실험과 창작을 촉진할 것으로 기대한다. - 특히 장난스럽고 생동감 있는 인터페이스가 인기를 얻는 흐름에 관심을 보였다. - Apple Maps의 3D 랜드마크 표현과 Honk의 playful한 iOS UI를 인상적인 사례로 언급했다. 새로운 Figma·FigJam 기능을 만들고 싶다면 사용자가 반복해서 제기하는 불편을 커뮤니티에서 찾고, 공식 API 문서와 개발자 커뮤니티를 활용해 작은 프로토타입부터 시작하는 접근이 효과적이다. Figma와 FigJam의 유사한 API 덕분에 하나의 아이디어를 두 환경으로 확장하기도 쉽다.

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

JavaScript사용자 인터페이스웹 개발markdown+2

figma·2021년 8월 24일·2분 읽기큐레이션 요약

Figma의 새로운 소

Figma는 2021년 8월 업데이트에서 FigJam의 확장성과 Figma 플러그인 개발 역량을 강화하고, 디자인 시스템 관리와 반복 작업을 간소화했다. 특히 FigJam 플러그인·위젯, 프로토타이핑 자동화를 위한 API, 라이브러리 관리 기능이 추가되어 협업과 디자인 운영의 효율성이 높아졌다. 또한 투명 객체의 그림자 처리와 직선 그리기처럼 일상적인 사용성도 개선했다. ## FigJam 플러그인과 위젯 도입 - FigJam에 Figma의 오픈 플랫폼을 확장해 팀별 협업 방식에 맞는 기능을 직접 만들 수 있게 했다. - **플러그인** - 개인 작업을 자동화하고 효율화하는 도구다. - 스타일 사용자 지정, 스티키 정리, 데이터 가져오기 등에 활용할 수 있다. - **위젯** - 여러 사용자가 캔버스에서 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 메모장, 게임 등을 제공해 워크숍과 브레인스토밍 진행을 돕는다. - 기본 HTML·JavaScript 지식이 있으면 플러그인을, React 경험이 있으면 위젯을 개발할 수 있도록 진입 장벽을 낮췄다. - 플러그인은 모든 요금제 사용자가 개발할 수 있었고, 위젯은 당시 비공개 베타로 제공됐다. ## Figma 플러그인 API 확장 - **프로토타이핑 쓰기 기능** - 플러그인이 프로토타입을 자동 생성하거나 기존 인터랙션을 대량으로 수정할 수 있게 됐다. - 반복적인 프로토타입 제작과 상호작용 설정을 자동화할 수 있다. - **플러그인 파라미터** - 별도의 사용자 인터페이스를 만들지 않고도 Quick Actions를 통해 사용자 입력을 받을 수 있다. - 플러그인 개발 시간이 줄고, 간단한 입력 기반 도구를 더 빠르게 만들 수 있다. - 당시 오픈 베타로 제공됐다. ## 디자인 시스템 관리 개선 - **컴포넌트 이동** - 게시된 컴포넌트와 컴포넌트 세트를 파일 간에 이동할 수 있다. - 이동 후에도 기존 인스턴스와의 연결이 유지된다. - 대형 라이브러리를 여러 파일로 분리하거나 새 파일로 이전하기 쉬워졌다. - **라이브러리 교체** - 스타일과 컴포넌트를 하나씩 변경하지 않고, 전체 라이브러리 세트를 다른 라이브러리로 교체할 수 있다. - **컴포넌트 검색** - `Shift + I` 단축키로 필요한 컴포넌트를 빠르게 검색할 수 있다. - 규모가 큰 디자인 시스템에서 탐색 시간을 줄여준다. ## 일상적인 사용성 개선 - 투명 객체가 뒤에 있는 그림자를 기본적으로 가리도록 변경되어, 별도로 설정을 조정할 필요가 줄었다. - Figma와 FigJam에서 연필 도구 사용 시 `Shift`를 누르면 직선을 그릴 수 있다. - 그 밖의 버그 수정과 개선 사항은 Figma 릴리스 노트에서 확인할 수 있도록 안내했다. 실무에서는 컴포넌트 라이브러리를 기능별 파일로 분리하고, 라이브러리 교체 기능과 플러그인 자동화를 함께 활용하면 디자인 시스템 유지보수 비용을 줄일 수 있다. FigJam에서는 투표나 설문 위젯을 활용해 회의 진행과 의사결정을 구조화할 수 있다.

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

JavaScriptFigma디자인 시스템figjam+3

figma·2021년 8월 23일·3분 읽기큐레이션 요약

FigJam에 도입된 오픈 플랫폼의

FigJam은 Figma의 개방형 플랫폼을 확장해 플러그인과 위젯을 누구나 만들 수 있도록 지원한다. 플러그인은 반복 작업과 데이터 처리를 자동화하고, 위젯은 투표·설문·게임처럼 여러 사용자가 동시에 상호작용하는 협업 경험을 제공한다. 두 API 모두 JavaScript·HTML 또는 React 지식을 바탕으로 쉽게 시작할 수 있도록 설계되었다. ## Figma 플러그인에서 FigJam으로 확장 - Figma는 약 2년 전부터 플러그인을 통해 외부 데이터 연동, 워크플로 자동화, 디자인 프로세스 개선을 지원했다. - 핵심 원칙은 “웹사이트를 만들 수 있다면 플러그인도 만들 수 있어야 한다”는 것이다. - 따라서 기본적인 JavaScript와 HTML 지식만으로도 플러그인 개발을 시작할 수 있도록 API의 진입장벽을 낮췄다. - FigJam에도 같은 개방형 플랫폼 원칙을 적용하되, 협업 중심의 사용 사례를 추가로 고려했다. ## 플러그인과 위젯의 역할 차이 - **플러그인** - 개인 또는 팀의 작업 흐름을 자동화한다. - CSV 데이터를 스티키 노트 격자로 변환하거나, 스티키 노트에 태그를 붙이는 작업 등을 처리할 수 있다. - 보드의 객체를 정리·분석하거나 외부 콘텐츠를 가져오는 데 적합하다. - **위젯** - FigJam 보드에 직접 배치해 여러 사용자가 함께 조작하는 인터랙티브 객체다. - 투표, 설문, 게임 등 협업형 기능을 구현할 수 있다. - 사용자가 보드에 드래그 앤 드롭해 사용할 수 있다. ## React 기반의 선언형 위젯 API - 위젯 API는 플러그인 API와 달리 선언적·함수형 방식으로 설계되었다. - `<Frame />`, `<Rectangle />`, `<Text />`, `<SVG />` 같은 컴포넌트로 위젯의 화면 구조를 정의한다. - 클릭 이벤트와 같은 사용자 상호작용에 임의의 코드를 연결할 수 있다. - FigJam의 기본 객체처럼 인라인 속성 메뉴도 제공할 수 있다. - React 컴포넌트와 유사한 구조를 사용하며, 컴포넌트 속성은 CSS의 레이아웃·스타일 속성과 비슷하다. - 예시 카운터 위젯은 다음 방식으로 동작한다. - `useSyncedState('count', 0)`으로 여러 사용자에게 동기화되는 상태를 만든다. - 사용자가 숫자를 클릭하면 `setCount(count + 1)`을 호출해 값을 증가시킨다. - `Frame`으로 자동 레이아웃과 패딩을 지정하고, `Text`로 현재 값을 표시한다. - `widget.register(SimpleCounter)`로 위젯을 등록한다. ## FigJam 플러그인의 주요 활용 분야 ### 보드 정리와 인사이트 도출 - 보드의 객체를 체계적으로 정리하고 분석할 수 있다. - 스티키 노트를 색상별로 정렬하거나 카테고리용 태그를 추가할 수 있다. - 스티키 노트의 내용을 분석해 워드 클라우드처럼 주제를 시각화할 수 있다. - 투표 수를 자동으로 집계하는 스탬프 카운터 플러그인도 활용 사례로 제시된다. - 텍스트를 입력하면 여러 개의 스티키 노트를 자동 생성하는 플러그인도 소개된다. ### 반복 작업 자동화 - 맞춤법 검사, 찾기 및 바꾸기 같은 수작업을 줄일 수 있다. - 동일한 스타일의 스티키 노트 100개를 한 번에 만드는 등 반복적인 작업을 자동화할 수 있다. - 사용자는 여러 단계를 직접 수행하는 대신 몇 번의 클릭만으로 작업을 완료할 수 있다. - Figma에서 사용되던 맞춤법 검사 플러그인을 FigJam으로 확장하는 사례가 언급된다. ### 콘텐츠 라이브러리 연동 - 외부 서비스나 라이브러리의 콘텐츠를 FigJam 보드로 가져올 수 있다. - 아이콘, 이모지, 회사 로고 등을 빠르게 삽입하는 플러그인을 만들 수 있다. - Icons8, Material Design, Iconify, Brandfetch 등 기존 Figma 콘텐츠 플러그인의 FigJam 확장이 사례로 제시된다. - 이를 통해 FigJam 사용자는 별도의 검색·복사 과정 없이 보드 안에서 필요한 시각 자료를 활용할 수 있다. ### 사용자 맞춤 설정 - 사용자가 원하는 색상, 폰트, 텍스트 스타일 등을 선택할 수 있는 기능도 플러그인 활용 분야로 제시된다. - FigJam은 기본적으로 폰트와 색상 체계를 단순하게 유지하지만, 사용자 요구에 따른 커스터마이징 수요가 존재한다. ## 실용적인 시사점 FigJam에서 자동화가 필요하면 플러그인을, 여러 사람이 동시에 조작하는 기능이 필요하면 위젯을 선택하는 것이 적합하다. 특히 React에 익숙한 개발자는 FigJam 레이어와 CSS와 유사한 컴포넌트 구조를 활용해 비교적 빠르게 인터랙티브 협업 도구를 만들 수 있다.

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

JavaScriptfigjamReactAPI+4

datadog·2021년 2월 10일원문

엔지니어링 스포트라이트: 마엘 니송 (새 탭에서 열림)

인도양의 작은 섬 레위니옹에서 시작해 자바스크립트 생태계의 핵심 도구인 Yarn의 메인 유지보수자가 되기까지, Maël Nison의 여정은 끊임없는 호기심과 오픈소스에 대한 열정으로 가득 차 있습니다. 그는 페이스북 부트캠프를 통해 Yarn 프로젝트에 합류한 뒤, 단순한 기여자를 넘어 프로젝트를 TypeScript 기반의 모듈형 구조로 재설계하고 커뮤니티 주도형 프로젝트로 탈바꿈시키는 데 결정적인 역할을 했습니다. 현재 Datadog의 프론트엔드 플랫폼 팀에서 근무하면서도 Yarn의 비전과 로드맵을 이끄는 그는, 기술적 해결책을 모두와 공유하는 오픈소스 정신이 개인과 공동체를 어떻게 성장시키는지 잘 보여줍니다. **Yarn의 진화와 다각적인 리더십** * 페이스북 입사 초기, 신규 입사자 교육 프로그램인 '부트캠프'를 통해 Yarn 프로젝트를 접하고 업무 시간의 상당 부분을 오픈소스 기여에 투입하기 시작했습니다. * 초기 내부 도구 성격이 강했던 Yarn을 TypeScript로 완전히 재작성하고 아키텍처를 모듈화하여, 특정 기업에 종속되지 않는 진정한 커뮤니티 오픈소스 프로젝트로 발전시켰습니다. * 프로젝트를 관리하며 개발자 역할을 넘어 제품 매니저, 팀 리드, 고객 지원, 인프라 설계, 웹 디자인 등 다방면의 역할을 수행하며 '1인 CEO'와 같은 경험을 쌓았습니다. **DarkBASIC에서 시작된 프로그래밍의 기초** * 프랑스 툴루즈의 중학교 시절, 점심시간마다 모이던 프로그래밍 클럽에서 DarkBASIC이라는 게임 제작 언어를 배우며 개발의 세계에 입문했습니다. * 화면 위에서 물고기가 움직이고 거품을 쏘는 간단한 2D 게임을 만들며, 코드를 수정하면 즉시 결과가 바뀌는 논리적인 과정에 매료되어 평생의 직업으로 삼기로 결심했습니다. * 2000년대 초반 3G 네트워크와 펜티엄 III 프로세서가 표준이던 시절부터 PHP 웹사이트를 구축하고 SQL 취약점을 직접 경험하며 실전 기술을 익혔습니다. **워크플로우 최적화와 실용적 교육** * 깃허브(GitHub)가 없던 시절, 포럼을 통해 소스 코드를 공유하며 누구나 필요한 해결책을 사용할 수 있게 하는 오픈소스의 본질을 체득했습니다. * 기존 CMS(콘텐츠 관리 시스템)들의 복잡한 관리 페이지 구조에 의문을 품고, 게시물을 클릭해 즉시 수정하는 직관적인 워크플로우를 고민하며 '사용자 경험 최적화'에 대한 철학을 세웠습니다. * 이론보다 실무 중심의 프로젝트와 동료 평가를 중시하는 프랑스의 교육 기관 EPITECH에서 수학하며, 자기 주도적 학습 역량과 실용적인 엔지니어링 기술을 연마했습니다. Maël Nison의 사례는 단순히 기술적인 숙련도를 높이는 것을 넘어, 자신이 마주한 불편함을 해결하고 그 결과물을 커뮤니티와 공유하는 습관이 어떻게 세계적인 오픈소스 리더로 성장하는 밑거름이 되는지 보여줍니다. 새로운 기술을 익힐 때 단순히 사용법을 익히는 데 그치지 않고, 오픈소스 프로젝트에 작은 기여부터 시작해 보는 것은 커리어 개발과 기술적 통찰력을 동시에 얻을 수 있는 가장 확실한 방법입니다.

JavaScript데이터베이스 설계오픈 소스TypeScript+4

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

피그마 내부 이야기: 엄

Figma는 TypeScript의 `strictNullChecks`를 도입해 `null`·`undefined`로 인한 런타임 오류를 컴파일 단계에서 줄이고 코드 유지보수성을 높였다. 약 1,162개 파일과 4,000개 이상의 오류가 있는 대규모 코드베이스였지만, 제품 개발을 중단하지 않고 파일 단위의 점진적 허용 목록 방식으로 마이그레이션했다. 이 사례는 기존 코드베이스의 타입 안전성을 높일 때 전면 전환보다 점진적이고 지속 가능한 전략이 효과적임을 보여준다. ## `strictNullChecks`가 해결하는 문제 - 기본 TypeScript 설정에서는 대부분의 값이 `null`이 될 수 있어 다음과 같은 대입이 허용된다. ```ts var v: Vector = { x: 1, y: 2 } v = null ``` - `strictNullChecks`를 활성화하면 `null`을 허용하는 타입을 명시적으로 선언해야 한다. ```ts var nullableVector: Vector | null = { x: 1, y: 2 } nullableVector = null ``` - 컴파일러는 제어 흐름 분석을 통해 값이 `null`인지 확인한 뒤 안전하게 사용할 수 있는지 검사한다. - `if (v)` 같은 조건문을 통과하면 `v`의 타입을 `Vector | null`에서 `Vector`로 좁혀, 안전하지 않은 프로퍼티 접근을 방지한다. - 그 결과 `cannot access .name of undefined`와 같은 오류를 컴파일 단계에서 발견할 수 있다. ## 오류 감소와 코드 유지보수성 향상 - Figma의 과거 장애 데이터에 따르면, 심각도가 높은 일부 프로덕션 장애는 strict null checks를 적용했다면 배포 전에 발견할 수 있었다. - 타입에 `null` 가능성이 명시되면 “이 시점에 파일 정보가 로드되어 있는가?” 같은 질문에 코드 자체가 답을 제공한다. - 함수가 `Vector`만 받는지, `Vector | null`도 받을 수 있는지 타입으로 명확히 표현할 수 있다. - null 처리 로직이 암묵적인 관례가 아니라 타입 시스템에 드러나므로 코드 이해와 변경이 쉬워진다. ## 대규모 레거시 코드베이스의 난점 - Figma는 TypeScript 2.0에서 `strictNullChecks`가 도입되기 전에 TypeScript를 사용하기 시작했다. - 기존 JavaScript 코드에 타입을 점진적으로 추가한 프로젝트에서는 null이 기본적으로 허용되는 경우가 많다. - 설정을 한 번에 켜자 약 1,162개 TypeScript 파일에서 4,000개 이상의 오류가 발생했다. - 한 오류를 수정하면 그 수정으로 인해 새로운 오류가 드러나는 연쇄적인 문제가 있었다. - 마이그레이션 중 코드베이스도 376,000줄에서 464,000줄로 증가했기 때문에, 일반적인 개발을 멈추지 않는 전략이 필요했다. ## 전면 중단 방식의 한계 - 모든 엔지니어가 기존 업무를 멈추고 마이그레이션에 참여하는 방식이다. - 마이그레이션 작업은 병렬화에 한계가 있어 모든 인력을 투입해도 효율적이지 않다. - 당시 제품 개발을 중단하면 사업 모멘텀을 잃을 수 있었다. - 조직과 팀 규모가 커질수록 여러 팀의 업무를 동시에 조정하기도 어려워진다. ## 오류를 장기간 병행 수정하는 방식의 한계 - strict null checks를 실제 빌드 규칙으로 활성화하지 않고 CI에서만 오류를 점진적으로 수정하는 방식이다. - 기존 개발 흐름을 거의 방해하지 않는다는 장점이 있다. - 그러나 강제되지 않는 상태에서는 새 코드가 계속 오류를 추가할 수 있다. - 오류를 수정하는 속도보다 새 오류가 생기는 속도가 빠르면 전체 진척도가 오히려 후퇴한다. - Figma는 이러한 방식이 오류를 줄이는 속도가 오류 유입 속도보다 빠를 때만 적절하다고 평가했다. ## 파일 단위의 점진적 허용 목록 - Figma가 선택한 방식은 strict null checks를 통과한 파일을 허용 목록에 하나씩 추가하는 것이다. - 코드베이스를 두 번 컴파일한다. - 전체 파일은 기존처럼 strict null checks 없이 컴파일한다. - 허용 목록에 포함된 파일은 strict null checks를 켠 상태로 컴파일한다. - 이를 통해 마이그레이션이 완료된 파일은 엄격한 타입 검사를 받으면서도, 아직 수정되지 않은 파일은 기존 개발 흐름을 유지할 수 있다. - Figma는 VS Code 팀의 유사한 마이그레이션 도구에서 출발해 자체 코드베이스의 특성에 맞게 확장했다. - 이 전략은 제품 개발을 중단하지 않고도 마이그레이션 진행 상황을 명확히 관리할 수 있게 한다. 기존 TypeScript 프로젝트에 strict null checks를 도입할 때는 설정을 한 번에 켜기보다, 파일·모듈 단위의 허용 목록과 별도 컴파일 구성을 활용하는 것이 현실적이다. 특히 새 코드가 계속 추가되는 조직에서는 “언젠가 고치기”보다 통과한 영역을 즉시 엄격한 규칙으로 보호하는 방식이 효과적이다.

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

JavaScriptTypeScriptcode-migrationstrict-null-checks+1

figma·2020년 10월 26일·4분 읽기큐레이션 요약

기능 비하인드:

Figma의 오토세이브는 단순히 파일 전체를 주기적으로 디스크에 저장하는 기능이 아니다. 브라우저 기반 실시간 협업 환경에서는 대용량 문서, 단일 스레드 실행, 동시 편집, 충돌 해결이 서로 얽히기 때문에 전체 파일 대신 오프라인 이후의 변경분(delta)을 저장하는 방식이 적합하다. Figma는 이 변경분을 IndexedDB에 보관했다가 문서를 다시 열 때 최신 문서에 적용하고 서버로 업로드한다. ## 오프라인 작업에서 발생하는 데이터 손실 - 온라인 상태에서는 Figma가 변경 사항을 서버로 즉시 전송한다. - 하지만 인터넷 연결이 끊기면 변경 사항을 서버와 동기화할 수 없다. - 기존에는 브라우저 탭이나 컴퓨터가 종료되면 오프라인 상태에서 작업한 내용이 사라질 위험이 있었다. - 확장된 오토세이브 시스템은 문서가 서버와 연결되지 않은 시점부터 변경 사항을 디스크에 저장한다. - 이후 문서를 새 탭에서 열면 저장된 변경 사항을 복원하고 서버에 업로드한다. ## 전체 파일 저장 방식의 한계 - 가장 단순한 방법은 메모리에 있는 scenegraph 전체를 직렬화해 백업 파일로 저장하는 것이다. - Figma 문서는 레이어 노드 트리인 **scenegraph**로 표현된다. - 큰 파일은 압축된 바이너리 기준 수십 MB, 메모리상에서는 수백 MB까지 커질 수 있다. - 전체 scenegraph를 직렬화하는 데 수 초가 걸릴 수 있으며, 저장할 때마다 사용자가 지연을 경험하게 된다. - 직렬화 시간을 10~20배 줄여 100ms 수준으로 만들어도 브라우저 환경에서는 충분하지 않다. - JavaScript와 WASM이 기본적으로 단일 스레드에서 실행되기 때문이다. - 사용자는 저장 시마다 약 100ms의 끊김을 느낄 수 있다. - 작업을 여러 프레임에 나누어 실행할 수 있지만, 직렬화 중 사용자가 문서를 수정하면 어떤 상태를 저장해야 하는지 문제가 발생한다. - 변경되지 않는 immutable scenegraph를 사용하면 해결할 수 있지만, 애플리케이션 전반의 대규모 구조 변경이 필요하고 메모리 사용량과 쓰기 성능 저하라는 비용도 따른다. ## 실시간 협업이 만드는 저장 문제 - Figma 파일은 클라우드에 저장되고 여러 사용자가 동시에 편집할 수 있다. - 오프라인 백업 파일 전체를 서버의 기존 파일로 덮어쓰면, 다른 사용자가 이후에 만든 최신 변경 사항을 잃을 수 있다. - 백업 파일을 별도 복사본으로 남기는 방법도 충분하지 않다. - 일부 파일은 디자인 시스템의 버튼이나 모달 같은 공유 컴포넌트의 원본이기 때문이다. - 복사본을 만드는 순간 공유 자산의 원본과 실제 작업 내용이 분리될 수 있다. - 따라서 오토세이브는 단순한 파일 복구가 아니라, 협업 시스템의 변경 병합 및 충돌 해결 방식과 함께 설계되어야 한다. ## 전체 문서가 아닌 변경분 저장 - Figma는 전체 파일 대신 사용자가 오프라인이 된 이후 발생한 변경 사항만 저장한다. - 이 변경분은 기존 멀티플레이어 편집 시스템에서 이미 서버 전송 및 확인을 위해 관리하던 데이터다. - 전형적인 흐름은 다음과 같다. - 사용자가 문서를 불러온다. - 서버 연결이 끊긴다. - 사용자의 변경 사항이 메모리의 pending changes buffer에 쌓인다. - 일정한 간격으로 버퍼의 내용이 디스크에 저장된다. - 문서나 브라우저 탭이 예기치 않게 종료된다. - 사용자가 문서를 다시 연다. - 저장된 변경분을 역직렬화한다. - 최신 문서 위에 변경분을 적용한다. - 복원된 변경 사항을 서버에 업로드한다. - 최신 문서에 변경분을 적용하므로, 오래된 전체 백업으로 최신 서버 상태를 덮어쓰는 문제를 피할 수 있다. ## IndexedDB를 활용한 브라우저 저장 - 브라우저에서 대용량 데이터를 저장하기 위해 IndexedDB를 사용한다. - IndexedDB는 다음 요구사항에 적합하다. - 많은 양의 데이터 저장 - 데이터를 작은 단위로 나누어 저장 - 인덱스를 통한 빠른 접근 - 트랜잭션을 통한 데이터 무결성 보장 - pending changes는 파일별, 노드 또는 레이어별 속성 변경 집합으로 저장된다. - 노드 단위의 세분화는 저장 공간과 불필요한 입출력 사이의 균형을 맞춘다. - 변경 사항을 지나치게 잘게 나누면 각 레코드의 관리 오버헤드가 커진다. - 반대로 모든 노드의 변경 사항을 하나의 객체에 넣으면 일부 변경만 발생해도 전체 변경 집합을 다시 기록해야 하므로 불필요한 I/O가 증가한다. ## 실용적인 결론 대용량 실시간 협업 애플리케이션의 오토세이브는 전체 상태를 반복 저장하기보다 변경 로그나 delta를 안정적으로 보관하는 방식이 효과적이다. 특히 저장 데이터의 단위, 트랜잭션 처리, 최신 서버 상태에 변경분을 재적용하는 복구 절차를 함께 설계해야 성능 저하와 협업 데이터 덮어쓰기를 모두 줄일 수 있다.

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

JavaScriptwebassemblyautosaveindexeddb+3