제공된 내용은 기술 블로그 글이 아니라 NAVER D2 사이트의 메뉴 목록과 저작권 문구입니다. 따라서 특정 기술 주제나 주장, 결론을 요약할 만한 본문 내용은 포함되어 있지 않습니다. ### 페이지에 표시된 메뉴 - **Hello world** - **D2 News** - **About D2** - **NAVER Developers** - **DEVIEW** - **OpenSource** - **D2 STARTUP FACTORY** ### 저작권 정보 - NAVER Corp.의 저작권 문구가 표시되어 있습니다. - 저작권 연도나 세부 이용 조건은 제공된 내용에 포함되어 있지 않습니다. 원문 본문이나 기술 글의 링크를 제공하면 해당 내용을 섹션별로 요약할 수 있습니다.
원문 읽기(새 탭에서 열림)Cloudflare는 API 토큰 중심의 제한적인 연동 방식을 넘어, 모든 고객이 직접 OAuth 클라이언트를 관리할 수 있는 self-managed OAuth를 도입했다. 이를 통해 SaaS, 내부 개발자 플랫폼, 에이전트 도구가 사용자로부터 필요한 권한만 위임받고, 사용자는 동의·철회·권한 범위를 더 명확하게 관리할 수 있게 됐다. 이 확장을 위해 동의 화면과 철회 기능을 개선하고, OAuth 엔진인 Hydra를 무중단에 가깝게 1.X와 2.X로 단계적으로 업그레이드했다. ## 모든 고객을 위한 self-managed OAuth - 기존 Cloudflare OAuth는 Wrangler나 PlanetScale 같은 일부 파트너 통합에만 제공됐다. - 자체 통합을 개발하는 일반 개발자는 API 토큰을 사용해야 했지만, API 토큰은 다음과 같은 한계가 있었다. - 관리가 어렵다. - 사용자가 애플리케이션에 권한을 위임하는 흐름에 적합하지 않다. - 권한 범위와 철회 상태를 사용자 관점에서 명확히 관리하기 어렵다. - self-managed OAuth를 사용하면 개발자가 직접 OAuth 클라이언트를 만들고 관리할 수 있다. - 애플리케이션은 사용자가 승인한 범위 내에서만 Cloudflare API에 접근하며, 사용자는 권한을 쉽게 철회할 수 있다. - 주요 활용 사례는 SaaS 통합, 내부 개발자 플랫폼, 에이전트 기반 도구다. ## 대규모 OAuth 생태계를 위한 보안 개선 - 기존 OAuth 시스템은 소수의 파트너를 수동 관리하는 데는 충분했지만, 모든 고객에게 개방하기에는 권한 모델과 보안 장치가 부족했다. - 동의 화면을 개선해 다음 정보를 명확히 표시했다. - 어떤 애플리케이션이 접근을 요청하는지 - 애플리케이션에 부여될 권한이 무엇인지 - Cloudflare 대시보드에 애플리케이션 권한 철회 기능을 추가했다. - 앱 소유자 정보를 더 잘 표시해 OAuth 피싱 공격을 예방했다. - 동시에 OAuth 엔진의 성능과 데이터 안정성을 개선하면서, 사용자 중단을 최소화하는 업그레이드 계획이 필요했다. ## Hydra 1.X 업그레이드와 데이터베이스 마이그레이션 - Cloudflare는 기존 OAuth 엔진으로 오픈소스 Hydra를 사용하고 있었다. - 개발자 플랫폼과 에이전트 워크플로가 성장하면서 성능과 기능 확장을 위해 Hydra 업그레이드가 필요해졌다. - 한 번에 대규모 업그레이드를 진행하지 않고 다음 두 단계로 나눴다. 1. 최신 1.X 버전으로 업그레이드 2. 동작과 성능을 검증한 뒤 2.X로 업그레이드 - 1.X 업그레이드에도 다음과 같은 위험이 있었다. - 인덱스 생성이 주요 테이블에 배타적 잠금을 걸어 OAuth 작업을 차단할 수 있었다. - 주요 테이블에 컬럼을 추가하거나 다른 테이블로 컬럼을 이동해야 했다. - 기존 Hydra SDK의 `SELECT *` 사용 때문에 스키마 변경 후 역직렬화 문제가 발생할 수 있었다. - 이를 해결하기 위해: - 인덱스 생성 SQL을 `CREATE INDEX CONCURRENTLY` 기반으로 다시 작성했다. - 필요한 컬럼만 명시적으로 조회하는 Hydra 커스텀 버전을 제작했다. - 실제 1.X 마이그레이션은 예상보다 빠르게 완료됐고 사용자 영향도 없었다. - 다만 구버전 Hydra가 신버전에서 생성된 토큰을 조회하지 못했기 때문에 점진적 전환이 아닌 하드 컷오버가 필요했다. ## 2.X 업그레이드를 위한 블루-그린 전략 - Hydra 2.X는 스키마 변경 규모가 커서 기존 데이터베이스에서 바로 업그레이드하는 인플레이스 방식은 적합하지 않았다. - Cloudflare는 새 환경을 준비한 뒤 전환하는 블루-그린 방식을 선택했다. - 단순히 데이터베이스 연결만 바꾸는 방식으로는 부족했다. 마이그레이션에 수 시간이 걸리는 동안에도 OAuth가 계속 작동해야 했기 때문이다. - 검토한 첫 번째 방식은 업그레이드 중 데이터베이스 쓰기를 중단하는 것이었다. - 신규 OAuth 승인을 막아 데이터 유실을 방지할 수 있다. - 하지만 기존 앱도 새 인증을 사용할 수 없게 된다. - 사용자가 애플리케이션 권한을 철회할 수도 없어 보안상 문제가 된다. - 따라서 쓰기를 계속 허용하되, 전환 과정에서 일부 쓰기가 유실될 수 있는 방식을 채택했다. ## 토큰 만료 조정과 철회 이벤트 보존 - 전환 중 발생하는 신규 토큰 쓰기를 줄이기 위해 토큰 만료 시간을 몇 시간으로 늘렸다. - 업그레이드 직전에 발급된 토큰이 갱신 없이 계속 사용되도록 해, 전환 기간의 토큰 갱신 요청을 줄였다. - 반면 권한 철회 이벤트는 절대 유실되면 안 됐다. - 철회 이벤트가 사라지면 사용자가 접근을 차단한 애플리케이션의 권한이 다시 살아날 수 있다. - Cloudflare는 Cloudflare Queues를 이용해 철회 이벤트를 별도 큐에 기록했다. - 녹색 환경으로 전환한 뒤 큐를 비우면서 철회 이벤트를 재생해, 업그레이드 중 발생한 모든 철회를 반영했다. ## 리프레시 토큰 문제와 완화 - Hydra 1.X 업그레이드 후 리프레시 토큰 오류가 증가했다. - 새 버전에서는 리프레시 토큰이 재사용되면 전체 액세스 토큰·리프레시 토큰 체인을 무효화하는 동작이 더 엄격해졌다. - 요청량이 많은 Wrangler와 MCP 클라이언트에서는 재시도 한 번만 발생해도 전체 세션이 무효화될 수 있었다. - Cloudflare는 OAuth 트래픽을 라우팅하는 Worker에 리프레시 토큰 요청 병합(coalescing)을 추가했다. - 동일 요청의 짧은 재시도를 잠시 캐시했다. - 재시도를 감지하면 Hydra에 다시 전달하지 않고 기존 요청 결과를 반환했다. - Hydra 2.X에서는 리프레시 토큰을 일정 시간 동안 재사용해도 전체 체인을 무효화하지 않는 `refresh token grace period` 설정을 제공해 이 문제를 근본적으로 완화할 수 있었다. ## 실용적인 결론 대규모 OAuth 시스템을 개방하려면 클라이언트 등록 기능만 추가해서는 부족하다. 명확한 동의 화면, 즉각적인 권한 철회, 앱 소유자 표시 같은 보안 기능과 함께, 스키마 마이그레이션 중에도 철회 이벤트를 보존하는 큐, 토큰 만료 조정, 토큰 갱신 재시도 제어 같은 운영 설계가 함께 필요하다.
원문 읽기(새 탭에서 열림)LY Corporation은 Verda와 YNW를 차세대 프라이빗 클라우드 Flava로 통합하면서, 쿠버네티스 오퍼레이터 패턴 기반의 DBaaS를 설계했습니다. Flava DBaaS는 데이터베이스 비즈니스 로직과 IaaS 제어를 분리하고, 선언적 관리·자동화·일관된 사용자 경험을 제공하는 것을 목표로 합니다. 또한 DBaaS의 역할을 신규 데이터베이스 제공에 그치지 않고, 기존 플랫폼에서 Flava로의 원활한 마이그레이션까지 확장하고 있습니다. ## 쿠버네티스 오퍼레이터 기반의 선언적 DBaaS - 사용자가 원하는 데이터베이스의 상태를 커스텀 리소스(CR)로 선언하면, 컨트롤러가 실제 상태가 선언된 상태와 일치하도록 지속적으로 조정(reconcile)합니다. - 절차를 직접 지시하는 방식보다 운영 상태를 파악하기 쉽습니다. - 커스텀 리소스의 사양과 현재 상태 비교 - 컨트롤러 로그 및 이벤트 확인 - 문제 발생 원인 추적 - 이벤트 기반 컨트롤러이므로 대규모 데이터베이스 환경에서도 효율적으로 동작할 수 있습니다. - 쿠버네티스의 CI/CD, 권한 관리, API, 모니터링 등 생태계 기능을 활용할 수 있습니다. - 구현 난이도는 높지만, 장기적인 운영과 관리에는 유리합니다. ## 인프라 오퍼레이터를 통한 IaaS 추상화 - DBaaS는 여러 VM, 스토리지, 네트워크, 도메인 등 IaaS 자원을 조합해 데이터베이스 클러스터를 구성합니다. - DBaaS가 IaaS API와 호출 절차를 직접 처리하면 다음 문제가 발생합니다. - 인프라 제어 코드가 지나치게 많아짐 - 데이터베이스 운영 로직과 인프라 로직이 뒤섞임 - DBMS별 개발자가 IaaS 세부사항까지 이해해야 함 - Flava는 IaaS 자원을 인프라 오퍼레이터가 쿠버네티스 커스텀 리소스로 추상화하도록 구성했습니다. - 예를 들어 VM 생성 시 IaaS API를 직접 호출하지 않고, 다음과 같은 속성을 선언한 `server.yaml`을 작성한 뒤 `kubectl create -f server.yaml`로 리소스를 생성합니다. - 가용 영역 - 운영체제 이미지 - vCPU·메모리 등 서버 유형 - 계층은 다음과 같이 분리됩니다. - **DBaaS**: 데이터베이스 비즈니스 로직 담당 - **인프라 오퍼레이터**: IaaS를 쿠버네티스 리소스로 추상화 - **IaaS**: 컴퓨트·네트워크·스토리지 제공 - 이 구조를 통해 여러 DBMS가 IaaS 자원을 동일한 방식으로 사용하고, DBaaS 개발자는 DBMS별 기능에 집중할 수 있습니다. ## 커스텀 리소스와 세 가지 실행 컴포넌트 Flava에서 데이터베이스 클러스터 역시 쿠버네티스 커스텀 리소스로 표현됩니다. - 커스텀 리소스에는 다음과 같은 구성이 선언됩니다. - MySQL 버전 - VM 서버 사양 - 스토리지 종류와 용량 - 복제 멤버 수 - 리소스는 YAML 형태로 etcd에 저장되며 쿠버네티스 API를 통해 생성·조회·수정·삭제할 수 있습니다. DBaaS는 커스텀 리소스를 중심으로 API 서버, 매니저, 에이전트로 나뉩니다. - **API 서버** - 사용자와 UI, IaC 도구가 호출하는 REST API를 제공합니다. - 사용자의 요청을 DBaaS 커스텀 리소스 생성·수정·삭제 작업으로 변환합니다. - **매니저** - 커스텀 리소스의 변경을 감지하는 컨트롤러입니다. - 선언된 사양과 실제 클러스터 상태가 일치하도록 VM 생성, 구성 변경, 복제 설정 등을 조정합니다. - 인프라 오퍼레이터의 커스텀 리소스를 생성해 필요한 VM과 인프라를 준비합니다. - **에이전트** - 데이터베이스가 실행되는 VM 내부에서 동작합니다. - 운영체제 명령이나 데이터베이스 명령처럼 VM 내부에서 실행해야 하는 작업을 수행합니다. - MySQL 설치, 복제 구성, 프로비저닝 등 로컬 실행이 필요한 작업을 담당합니다. 예를 들어 MySQL 클러스터 생성 요청이 들어오면 API 서버가 MySQL 커스텀 리소스를 생성하고, 매니저가 필요한 VM을 만든 뒤, 에이전트가 VM 내부에서 MySQL과 복제 구성을 완료합니다. ## DBMS 지원과 확장성 개선 - Verda와 YNW에서 제공하던 DBMS를 통합해 Flava에서 지원하는 DBMS 종류를 확대했습니다. - 기존 사용자 만족도 조사와 운영 경험을 바탕으로 기능을 추가했습니다. - 스토리지를 100GiB 단위로 구성할 수 있어 용량 조정이 유연해졌습니다. - 블록 스토리지를 사용하는 DBMS는 최대 5TiB까지 지원합니다. - 기존에는 VM 로컬 디스크 용량이 하이퍼바이저의 VM 사양에 종속됐지만, Flava는 다음을 통해 제약을 줄였습니다. - 사용자 정의 인스턴스 유형 - VM과 분리된 블록 스토리지 - 확장된 최대 스토리지 용량 - 단일 VM의 저장공간 부족으로 샤딩을 검토해야 했던 사례를 줄일 수 있습니다. - 5TiB 제한은 대부분의 사용 사례를 충족하면서 블록 스토리지 측 서버 단편화를 방지하기 위한 설계 결정입니다. ## DBMS 전반의 통일된 사용자 경험 - 모든 DBaaS 상품에 공통 아키텍처와 UI·UX를 적용했습니다. - 한 DBMS에서 익힌 관리 방식으로 다른 DBMS도 사용할 수 있습니다. - MySQL에서 서버 사양을 변경한 경험을 Redis에도 적용 - Cassandra에서 설정한 모니터링 알람 방식을 MySQL에도 적용 - DBMS마다 별도의 사용법을 학습해야 하는 부담을 줄였습니다. - 플랫폼 차원에서 프로비저닝, 고가용성, 백업·복구, 확장성, 모니터링 같은 기본 기능을 제공합니다. ## 보안 및 편의 기능 강화 - DBaaS 기본 기능으로 다음 보안 기능을 제공합니다. - **TDE(Transparent Data Encryption)**: 저장 데이터 암호화 - **TLS(Transport Layer Security)**: 전송 구간 암호화 - **Custom DB Role** - 필요한 수준의 권한을 가진 데이터베이스 사용자를 생성·관리할 수 있습니다. - 정의한 역할을 재사용할 수 있습니다. - **Database Parameter Group** - 데이터베이스 파라미터를 원하는 값으로 관리할 수 있습니다. - 설정 그룹을 여러 클러스터에 재사용할 수 있습니다. - **Restore backup** - 특정 백업을 기반으로 새 데이터베이스 클러스터를 생성합니다. - 장애 복구뿐 아니라 실제 데이터가 필요한 성능 테스트 환경 구축에도 활용할 수 있습니다. - 일부 DBMS에서 아직 제공되지 않는 기능도 향후 확대할 예정입니다. ## 마이그레이션까지 포함하는 DBaaS의 책임 - 신규 DBaaS는 데이터베이스를 생성하는 기능만 제공해서는 충분하지 않습니다. - 기존 Verda·YNW 환경의 사용자가 Flava로 쉽게 이동할 수 있도록 마이그레이션 방법까지 제공해야 합니다. - 같은 DBMS 간 마이그레이션 방식은 크게 세 가지로 소개됩니다. ### 덤프 및 복구 - 소스 데이터베이스를 백업한 뒤 목적지 데이터베이스에 복구합니다. - 구현이 가장 단순합니다. - 데이터 정합성을 보장하려면 마이그레이션 중 애플리케이션 중단이 필요합니다. ### 실시간 복제 - DBMS 자체의 복제 기능으로 소스에서 목적지로 데이터를 실시간 복제합니다. - 복제가 완료되면 페일오버해 목적지 클러스터를 새로운 프라이머리로 전환합니다. - 이후 기존 소스 데이터베이스를 제거합니다. - 애플리케이션 중단을 최소화할 수 있지만, 프라이머리 전환 시 짧은 중단이 발생할 수 있습니다. - 데이터 정합성은 사용 중인 DBMS의 복제 메커니즘에 의존합니다. ## 실용적인 결론 Flava DBaaS의 핵심은 데이터베이스를 쿠버네티스 리소스로 선언하고, 인프라 오퍼레이터·매니저·에이전트가 실제 구성을 자동으로 맞추도록 만든 점입니다. 유사한 플랫폼을 설계할 때는 DBaaS와 IaaS의 책임을 분리하고, 공통 UI·보안·백업 기능을 플랫폼 수준에서 제공하며, 신규 기능뿐 아니라 기존 시스템의 마이그레이션 경로까지 함께 설계하는 것이 중요합니다.
원문 읽기(새 탭에서 열림)LLM의 컨텍스트 창이 커져도 입력을 무작정 늘리는 ‘토큰 스터핑’만으로는 소프트웨어 에이전트의 추론 성능을 보장할 수 없다는 것이 글의 핵심 주장입니다. 긴 컨텍스트에서는 어텐션 희석과 컨텍스트 부패가 발생해 검색 정확도와 논리 일관성이 떨어질 수 있으므로, 컨텍스트를 텍스트가 아닌 관리 가능한 시스템 자원으로 다뤄야 합니다. 이를 위해 글은 로컬 루프백 프록시 형태의 ‘시맨틱 컨텍스트 OS’와 VFS, AST 기반 가지치기, 동적 토큰 관리 구조를 제안합니다. ## 컨텍스트 창은 전통적인 RAM과 다르다 - Karpathy의 은유에 따르면: - LLM은 사전 학습된 가중치를 바탕으로 추론을 수행하는 CPU와 유사합니다. - 컨텍스트 창은 현재 상태와 실행 데이터를 담는 휘발성 RAM과 유사합니다. - 그러나 전통적인 RAM과 달리 LLM의 컨텍스트 검색은 결정론적인 주소 조회가 아닙니다. - 특정 메모리 주소에서 데이터를 정확히 읽는 방식이 아니라, Q·K·V 행렬과 어텐션 점수에 기반한 확률적 검색입니다. - 컨텍스트가 32K에서 1M 또는 2M 토큰으로 커져도 정보 접근 정밀도가 선형적으로 증가하지 않습니다. - 입력이 커질수록 계산 표면적과 구조적 잡음이 증가해 오히려 추론 성능이 저하될 수 있습니다. ## 어텐션 희석과 ‘중간 정보 유실’ - 긴 코드베이스나 시스템 로그에는 다음과 같은 불필요한 정보가 포함됩니다. - 보일러플레이트 정의 - 참조되지 않는 import - 중복된 구문과 유틸리티 - 관련 없는 로그와 실행 데이터 - 이런 정보가 키 행렬에 많이 포함되면 쿼리와 키 사이의 의미 차이가 작아지고, 어텐션 로짓이 균일해집니다. - 그 결과 중요한 정보에 집중하던 날카로운 어텐션 피크가 넓게 분산되어, 정확한 사실 검색이 어려워집니다. - 글은 이를 Stanford 연구에서 제시한 ‘Lost in the Middle’ 현상과 연결합니다. - 컨텍스트의 시작과 끝에 있는 정보는 비교적 잘 검색됩니다. - 중간 영역, 특히 중간 70% 부근의 정보는 검색 정확도가 크게 낮아집니다. - 수만 줄의 코드나 복잡한 서비스 의존성을 다루는 에이전트에게 이러한 검색 편향은 심각한 논리적 오류로 이어질 수 있습니다. ## 장기 작업에서 발생하는 컨텍스트 부패 글은 자동 리팩토링, 레거시 마이그레이션, API 계약 검증처럼 여러 단계가 필요한 작업에서 컨텍스트가 시간이 지나며 악화되는 현상을 ‘컨텍스트 부패’라고 설명합니다. - **컨텍스트 오염** - 과거 실행 로그, 터미널 오류, 원시 데이터를 계속 누적합니다. - 모델이 일시적인 과거 오류를 현재 작업의 영구적인 제약으로 잘못 해석할 수 있습니다. - **컨텍스트 산만** - 모노레포의 동일한 이름, 오버로드된 메서드, 중복 유틸리티가 검색 결과에 함께 들어옵니다. - 구조적으로 비슷하지만 논리적으로 무관한 코드가 핵심 실행 경로를 가립니다. - **컨텍스트 충돌** - 이전 단계의 지시사항을 제거하거나 갱신하지 않으면 서로 모순되는 명령이 남습니다. - 에이전트가 논리적으로 마비되거나 무한 추론, 타임아웃, 환각을 일으킬 수 있습니다. - 글은 능동적인 관리 계층이 없을 경우 컨텍스트 깊이가 커질수록 실패율이 비선형적으로 증가하고, 깊은 코드 구조에서는 실패율이 약 40%에 이를 수 있다고 주장합니다. ## 수동적 프롬프트에서 능동적 거버넌스로 - 일반적인 구현은 문자열을 계속 이어 붙여 다음 LLM 호출에 전달하는 방식입니다. - 이 방식은 메모리 관리, 토큰 최적화, 노이즈 제거를 LLM의 내부 어텐션에 맡깁니다. - 시맨틱 컨텍스트 OS는 애플리케이션 로직과 파운데이션 모델 API 사이에 위치하는 AI 전용 커널로 제시됩니다. - 로컬 `localhost:8080` 루프백 프록시로 동작하며 다음 작업을 담당합니다. - 컨텍스트 상태와 접근 경로 관리 - 토큰 생명 주기 모니터링 - 전송 전 데이터 격리와 정책 적용 - 모델별 하드웨어 토큰 한계와 의미론적 컨텍스트 거버넌스의 분리 ## MVC(Minimum Viable Context) 파이프라인 MVC의 목표는 거대한 텍스트 덤프가 아니라 현재 추론 단계에 필요한 최소한의 고밀도 정보만 모델에 제공하는 것입니다. - **수집 및 토큰 매핑** - 소스 파일, 의존성 트리, 런타임 로그를 수집합니다. - `cl100k_base`, `o200k_base` 등 실제 모델 토크나이저를 사용해 정확한 토큰 수를 계산합니다. - **구조 가지치기** - 정적 코드 분석과 구조 규칙으로 불필요한 정보를 제거합니다. - 컴파일러 주석, 미사용 import, 관계없는 유틸리티 코드 등이 대상입니다. - 글에서 제시한 전체 아키텍처는 이후 단계에서 의미적 정제와 실행 중 토큰 최적화를 수행하도록 설계됩니다. ## 시맨틱 컨텍스트 OS의 구성 요소 - **POSIX 유사 VFS** - 컨텍스트와 에이전트 상태를 가상 파일 시스템처럼 구조화합니다. - 상태 토폴로지와 접근 경계를 명시적으로 관리합니다. - **PathAlign** - AST를 활용해 코드의 구조적 경로를 분석합니다. - 현재 작업과 관련된 가지를 남기고 무관한 코드 트리를 제거합니다. - **비동기 톱니(sawtooth) 메모리 모델** - 실행 중 컨텍스트를 계속 축소·갱신하는 방식으로 토큰 사용량을 최적화합니다. - 장기 실행 루프에서 오래된 상태와 불필요한 데이터를 누적하지 않도록 합니다. - **보안 및 격리** - 모델에 전달되는 데이터의 범위를 제한합니다. - 기업 코드와 로그 등 지적 재산이 불필요하게 외부 추론 엔진으로 유출되는 위험을 줄이는 것을 목표로 합니다. 시맨틱 컨텍스트 OS의 실질적인 메시지는 “큰 컨텍스트 창”보다 “잘 선별되고 지속적으로 관리되는 컨텍스트”가 중요하다는 것입니다. 엔터프라이즈 에이전트를 구축할 때는 토큰 예산을 명시적으로 계산하고, AST·의존성·의미 기반 필터링을 적용하며, 오래된 지시와 로그를 정리하는 런타임 거버넌스 계층을 두는 것이 권장됩니다. 단, 글의 실패율과 성능 개선 수치는 제안된 아키텍처의 주장으로 보아 실제 환경에서 별도의 벤치마크 검증이 필요합니다.
원문 읽기(새 탭에서 열림)Figma는 디자인 캔버스에 타임라인 기반의 네이티브 애니메이션 기능인 **Figma Motion**을 도입했다. 이제 컴포넌트·변수·팀 협업 환경과 애니메이션을 같은 파일에서 다룰 수 있으며, Figma Agent와 Dev Mode를 통해 제작과 핸드오프의 장벽을 낮춘다. 모션을 특정 전문가의 작업이 아니라 디자인 시스템의 일부로 만들겠다는 것이 글의 핵심이다. ## 캔버스에 통합된 애니메이션 작업 - Design, Draw, Dev 모드와 나란히 Motion 모드가 제공된다. - 프레임을 Motion 모드로 전환하면 디자인 옆에 타임라인이 표시된다. - 외부 애니메이션 도구나 플러그인으로 이동하지 않고 같은 파일에서 디자인과 모션을 제작할 수 있다. - 모션에 익숙하지 않은 디자이너도 Figma Agent에 프롬프트를 입력해 애니메이션 아이디어와 개선점을 얻을 수 있다. - 이를 통해 모션 제작을 전문 모션 디자이너만의 업무가 아니라 팀 전체의 작업으로 확장한다. ## 타임라인과 키프레임 제어 - 레이어를 타임라인에서 드래그해 애니메이션의 시작과 지속 시간을 조정할 수 있다. - 플레이헤드를 이동하거나 스크럽해 특정 시점의 결과를 미리 볼 수 있다. - 위치, 크기, 회전, 불투명도를 각각 독립적으로 키프레임화할 수 있다. - 자동 키프레임 기능을 켜면 플레이헤드가 움직이는 동안 변경한 값이 자동으로 기록된다. - 페이드, 이동, 확대·축소 같은 프리셋 애니메이션 스타일을 빠르게 적용할 수 있다. - 여러 스타일을 동시에 겹쳐 실행하거나 타임라인에서 순차적으로 배치할 수 있다. - 사용자 정의 애니메이션 스타일을 만들어 저장하는 기능도 제공될 예정이다. ## 시간 기반 협업과 핸드오프 - 캔버스에 시간 기반 댓글을 남겨 애니메이션의 특정 순간을 직접 지적할 수 있다. - 모션 리뷰에서 “어느 프레임의 어떤 움직임”을 수정해야 하는지 명확하게 전달할 수 있다. - Dev Mode에서도 타임라인과 관련 기능에 접근할 수 있어 개발자와의 협업이 쉬워진다. - 디자인 단계부터 팀 전체가 모션을 검토하므로, 개발 단계에서 뒤늦게 애니메이션을 전달하는 병목을 줄인다. ## 디자인 시스템에 포함되는 모션 - 컴포넌트에 애니메이션을 포함할 수 있으며, 해당 컴포넌트가 다른 화면과 협업자의 파일로 복제될 때 모션도 함께 이동한다. - 모션을 매번 새로 만드는 대신 디자인 시스템의 재사용 가능한 구성 요소로 관리할 수 있다. - 팀이 정의한 모션 원칙과 스타일을 여러 파일에 일관되게 적용할 수 있다. - 결과적으로 모션이 개인의 작업 속도나 전문성에 따라 달라지는 문제를 줄인다. ## 모션 변수와 모드 - 모션 변수에 easing 같은 애니메이션 값을 저장할 수 있다. - 하나의 변수에 여러 모드를 정의해 상황별 애니메이션 동작을 관리할 수 있다. - 페이지 수준에서 모드를 변경하면 해당 변수를 참조하는 모든 애니메이션이 한꺼번에 업데이트된다. - 디자인 토큰처럼 모션의 속도감과 전환 방식을 중앙에서 통제할 수 있다. ## 셰이더 속성의 애니메이션 - 셰이더가 노출하는 속성도 Motion 타임라인에서 키프레임화할 수 있다. - 기존에는 Figma에서 애니메이션화할 수 있는 속성이 제한적이었지만, 이제 슬라이더나 입력 필드로 조정 가능한 셰이더 값까지 시간에 따라 변화시킬 수 있다. - 이를 활용하면 시각 효과와 인터랙션 표현의 범위를 넓힐 수 있다. ## 실용적인 결론 Figma Motion은 애니메이션을 별도 제작·핸드오프 단계가 아닌 디자인 시스템과 협업 과정의 기본 요소로 통합하려는 기능이다. 팀은 컴포넌트와 모션 변수를 함께 정의하고, 타임라인 댓글과 Dev Mode를 활용해 디자인 초기부터 개발자와 움직임을 조율하는 방식으로 활용하는 것이 좋다.
원문 읽기(새 탭에서 열림)Figma는 Weavy 인수를 바탕으로 AI 창작 도구인 Figma Weave를 기존 Figma 캔버스와 연결한다. 디자이너는 Figma Design에서 이미지 스타일 변환, 제품 촬영, 소재 추출 등 20개 이상의 사전 구축 AI 작업을 사용할 수 있고, 복잡한 프롬프트나 별도 워크플로 구축 없이 반복적인 제작 업무를 처리할 수 있다. 앞으로는 사용자가 만든 Weave 워크플로를 Figma 도구로 공개·공유하고, Weave 안에서도 Figma 파일과 프레임을 활용할 수 있게 되어 디자인과 크리에이티브 제작의 경계가 더욱 줄어들 전망이다. ## Figma와 Weave의 통합 배경 - Figma는 Weavy를 인수한 뒤 이를 **Figma Weave**로 발전시키고 있다. - Weave는 이미지, 비디오, 애니메이션, 모션 디자인, VFX, 오디오, 3D 작업을 노드 기반 캔버스에서 처리하는 AI 창작 플랫폼이다. - 각 작업은 프롬프트와 모델 실행의 단순한 결과가 아니라, 입력·편집·생성·변형 과정을 연결한 시각적 워크플로로 구성된다. - 팀원은 캔버스에서 제작 과정을 확인하고, 특정 단계만 수정하거나 결과를 반복 생성할 수 있다. - Figma는 이 구조를 기존 협업 캔버스와 결합해 디자인과 크리에이티브 제작을 같은 공간에서 진행하려 한다. ## Figma Design에서 사용하는 Weave 도구 - 20개 이상의 AI 이미지 작업이 Figma Design 왼쪽 패널에서 직접 제공된다. - 각 도구는 복잡한 Weave 워크플로를 간단한 UI로 포장한 형태다. - 주요 활용 사례는 다음과 같다. - 이미지 스타일 전이 - 제품 사진 및 이커머스 촬영 이미지 생성 - 소재·재질 추출 - 다양한 시각 언어를 활용한 아트 디렉션 - 이미지 비율 변경 - 특정 예술 양식으로 사진 변환 - 사용자는 자유 형식 프롬프트를 직접 작성하지 않고 입력 이미지를 추가한 뒤 도구를 선택해 결과를 생성할 수 있다. - 동일한 작업을 반복해도 일관된 방식으로 실행되므로, 반복적인 제작 업무를 몇 번의 클릭으로 처리할 수 있다. - 결과를 여러 갈래로 분기하거나, 서로 다른 모델과 접근 방식을 비교하고, 원하는 결과를 선택해 세부 조정할 수 있다. ## 워크플로를 통한 창작 과정의 표준화 - Weave의 핵심은 하나의 프롬프트보다 **프롬프트와 모델, 편집 단계를 연결한 로직**에 있다. - 사용자는 이미지 생성뿐 아니라 결과 수정, 스타일 적용, 여러 버전 비교를 하나의 흐름으로 관리할 수 있다. - 반복적으로 사용하는 제작 방식을 워크플로로 만들어 팀의 공통 자산으로 활용할 수 있다. - 앞으로는 개인이나 팀이 직접 만든 Weave 워크플로를 Figma 안의 Weave 도구로 게시할 수 있게 된다. - 워크플로를 한 번 정의하면 팀 내부 또는 커뮤니티와 공유해, 제작 노하우와 의사결정 로직을 재사용할 수 있다. ## OutSystems의 활용 사례 - OutSystems의 브랜드 팀 디자이너 Bruno Figueiredo는 Weave를 프레젠테이션 이미지, 애니메이션, 행사 그래픽, 굿즈 제작에 활용한다. - 회사 마스코트 ‘Neo’의 키링 인형을 제작할 때는 외부 전문가에게 의존하지 않고 Weave로 제조용 3D 모델을 만들었다. - 노드 기반 워크플로를 활용해 다음 요소를 반복적으로 조정할 수 있었다. - 일러스트 스타일 - 의상 색상 - 신체 비율 - 여러 모델의 결과 비교 - 여러 플로우를 동시에 실행한 뒤 나중에 결과를 검토할 수 있어, 탐색적인 디자인 작업에 적합하다고 설명한다. - 기존 사진과 일러스트를 확장해 새로운 브랜드 가이드라인을 만들거나, 필요한 스타일의 목업을 생성하는 데도 활용할 수 있다. ## 앞으로의 연결 방향 - 현재는 Weave의 기능을 Figma 캔버스 안으로 가져오는 단계가 먼저 시작됐다. - 동시에 Weave 워크플로를 Figma Community에서 공유할 수 있도록 확장할 계획이다. - 향후 Weave에 **Figma 노드**가 추가되면 Figma 프레임과 디자인 파일을 Weave 워크플로의 입력·편집 과정에 직접 연결할 수 있다. - 이에 따라 디자인 결과물을 별도 도구로 옮기거나, AI 제작 결과를 다시 Figma로 가져오는 번거로운 변환 과정이 줄어들 것으로 보인다. - 최종적으로는 디자이너가 Figma에서 시각적 방향을 정하고, Weave가 생성·변형·반복 실행을 담당하는 통합 제작 환경을 지향한다. 실무적으로는 반복되는 이미지 생성이나 브랜드 스타일 적용 업무를 Weave 도구로 표준화하고, 팀만의 워크플로를 공유 가능한 자산으로 만드는 방식이 가장 큰 활용 포인트다. Akan AI 결과를 그대로 사용하는 것보다, 여러 버전을 비교하고 노드별 과정을 조정하면서 최종 디자인 의도를 관리하는 것이 이 통합의 장점이다.
원문 읽기(새 탭에서 열림)모션 디자인은 정적인 그래픽에 시간, 리듬, 속도, 소리, 순서를 더해 의미와 감정을 전달하는 작업이다. 좋은 모션을 만들려면 물리적 움직임을 이해하고, 타이밍과 이징을 활용해 이야기를 단계적으로 보여줘야 한다. 또한 자연·영화·예술 등 다양한 분야에서 움직임의 영감을 얻고, 우연히 생기는 조화까지 열린 태도로 받아들이는 것이 중요하다. ## 그래픽 디자인과 모션 디자인의 차이 - 그래픽 디자인은 정지된 한 장면 안에서 메시지를 전달한다. - 모션 디자인은 시간의 흐름을 활용해 다음 요소를 추가한다. - 리듬과 페이싱 - 변형과 전환 - 움직임의 성격과 캐릭터 - 소리와 이미지의 동기화 - 모든 내용을 한 화면에 담기보다 여러 프레임으로 나누어 “먼저 이것, 다음에 저것”의 순서로 보여주면 이야기를 더 쉽게 이해시킬 수 있다. - 모션의 핵심은 움직임 자체보다 시간 요소를 사용해 아이디어와 감정을 전달하는 데 있다. ## 타이밍, 이징, 사운드의 역할 - 이징과 타이밍은 움직임의 감정과 의도를 결정한다. - 음악의 박자처럼 모션도 속도와 간격의 구조를 가진다. - 이미지와 소리가 결합하면 각각의 요소를 넘어선 새로운 의미와 연결이 만들어진다. - 설계자가 모든 결과를 완벽히 통제하기보다, 사운드와 이미지가 만나며 생기는 우연한 효과와 ‘행복한 실수’를 받아들이는 태도도 창작의 중요한 부분이다. ## 물리학에서 찾는 움직임의 기준 - 현실의 움직임은 모션 디자인의 기본 참고점이다. - 예를 들어 공이 튀는 움직임은 다음과 같은 물리적 특징을 가진다. - 처음에는 빠르게 움직인다. - 위로 올라갈수록 속도가 느려진다. - 다시 떨어진다. - 반복할 때마다 튀어 오르는 높이가 낮아진다. - 이런 가속·감속과 에너지의 변화를 포착해야 움직임이 자연스럽고 설득력 있게 느껴진다. - 관객은 움직임이 왜 좋은지 설명하지 못해도 현실의 경험을 바탕으로 자연스러움과 어색함을 직관적으로 판단한다. ## 다양한 분야에서 얻는 영감 - 기존 모션 디자인만 참고하면 유행하는 표현을 반복하기 쉽다. - 자연의 움직임에서는 생동감과 물리적 설득력을 얻을 수 있다. - 영화의 스토리텔링과 편집 기법에서는 장면 전환과 서사 구성 방식을 배울 수 있다. - 예술과 디자인의 제스처, 형태, 움직임은 차별화된 표현을 만드는 데 도움이 된다. - 익숙한 공이나 사각형 애니메이션을 넘어 다양한 시각적·서사적 자원을 활용해야 독창적인 결과를 만들 수 있다. ## 모션의 핵심 원칙 - **Ease in / Ease out**: 움직임이 시간에 따라 가속하거나 감속하는 방식 - **Anticipation**: 앞으로 일어날 동작을 예고하는 준비 동작 - **Overshoot**: 목표 지점을 약간 지나친 뒤 원래 위치로 돌아오는 움직임 - **Follow-through**: 주된 움직임이 끝난 뒤에도 이어지는 보조 움직임 - **Hold**: 관객이 방금 일어난 일을 인식할 수 있도록 잠시 멈추는 구간 - **Settle**: 대상이 최종 위치에 도달한 뒤 안정되는 미세한 움직임 ## 전환으로 이야기를 연결하기 - 이징은 움직임의 속도뿐 아니라 장면이 자연스럽게 정착하는 느낌까지 결정한다. - **Match cut**은 서로 다른 장면을 같은 움직임이나 형태로 연결하는 편집 방식이다. - 느림에서 빠름으로, 다시 느림으로 속도를 변화시킨 뒤 가장 빠른 순간에 장면을 전환하면 두 장면이 매끄럽게 이어질 수 있다. - 전환은 이야기의 각 박자를 연결하고 전체 흐름을 하나로 묶는 역할을 한다. 실무에서는 먼저 전달하려는 메시지와 감정을 정한 뒤, 현실의 물리 법칙을 참고해 타이밍과 이징을 설계하는 것이 좋다. 여기에 자연·영화·음악 등 다양한 분야의 움직임을 결합하면 더 자연스럽고 독창적인 모션을 만들 수 있다.
원문 읽기(새 탭에서 열림)AI 시대의 소프트웨어는 사용자가 정해진 메뉴와 명령어를 배우는 방식에서 벗어나, 사람의 의도·감정·상황을 이해하고 그에 맞게 반응하는 방향으로 발전할 수 있다. 글은 창작자 커뮤니티의 상상을 통해, 소프트웨어가 더 자연스럽고 인간적인 상호작용을 제공하는 미래를 제시한다. 결론적으로 중요한 변화는 기능의 증가 자체보다 기술이 사람의 맥락과 상태에 맞춰지는 데 있다. ## 소프트웨어와 문화의 상호작용 - 핀치 투 줌, 좋아요 누르기, 스와이프처럼 특정 제품을 위해 만들어진 제스처가 사람들의 사고방식과 문화까지 바꿔 왔다. - AI의 등장은 또 다른 전환점으로, 소프트웨어를 만들고 사용하고 서로 소통하는 방식을 새롭게 상상하게 한다. - 미래의 인터페이스는 기술 중심이 아니라 사람의 의도, 감정, 관계 형성 방식을 중심으로 설계될 가능성이 있다. ## 맥락에 따라 나타나는 일시적 도구 - 사용자가 프레임, 문장, 영상 클립 등 특정 요소를 선택하면 현재 상황에 필요한 조작 기능만 주변에 표시된다. - 작업이 끝나면 해당 컨트롤은 사라져, 항상 메뉴와 패널을 탐색하거나 기능 위치를 외울 필요가 줄어든다. - 예를 들어 느린 영상 클립을 선택하면 타이밍, 페이싱, 대체 컷, 사운드 브리지 같은 관련 옵션이 바로 제공된다. - 사용자는 버튼을 누르는 방법보다 “무엇을 왜 바꾸려는지”에 집중할 수 있다. ## 음성·몸짓을 이해하는 매직 마커 - 사용자가 화면의 대상을 동그라미 치고 원하는 위치로 끌면서 음성으로 설명하면, AI가 말·커서의 이동·몸짓을 함께 해석한다. - 모션 디자인에서는 레이어를 직접 움직이며 바운스, 속도, 이징 등을 말이나 소리, 신체 표현으로 설명할 수 있다. - 문서 내 객체를 정확히 지칭하거나 정교한 프롬프트를 작성할 필요가 줄어든다. - AI가 검색창이나 명령어 도구가 아니라, 말하고 가리키며 협업하는 동료처럼 작동하는 방식이다. ## 필요한 결과에 맞춰 변하는 적응형 존재감 - 시스템은 사용자의 반응을 관찰해 도움의 수준과 전달 방식을 조절한다. - 사용자가 혼란스러워하면 단계별 안내를 제공하고, 익숙하게 작업하면 개입을 줄인다. - 상황에 따라 음성·텍스트·시각 자료를 전환하고, 속도를 늦추거나 정보를 작은 단계로 나눌 수 있다. - 지금까지는 사람이 기계의 작동 방식에 적응해야 했지만, AI 시대에는 시스템이 사용자의 준비도와 능력에 맞춰야 한다. - 의료와 교육처럼 사용자의 상태와 이해 수준이 중요한 분야에서 특히 의미가 크다. ## 감정에 반응하는 공감형 흐름 - 입력 속도, 스타일러스 압력, 말하는 리듬, 표정, 같은 문장을 반복해서 수정하는 행동 등이 사용자의 감정 신호로 활용된다. - 음식 배달 앱은 결정 피로가 감지되면 선택지를 단순화하고, 창작 도구는 사용자가 몰입한 순간 불필요한 버튼과 프롬프트를 숨길 수 있다. - 호텔 앱은 사용자가 피곤한 상태로 체크인한다고 판단하면 업그레이드 제안 대신 “객실이 준비되었습니다”라는 핵심 정보만 전달한다. - 사용자가 원하는 것을 매번 명시적으로 설명하지 않아도, 시스템이 행동과 상태를 바탕으로 필요한 경험을 제공하는 방식이다. ## 신경계를 안정시키는 상황 단서 - 초기 디지털 경험의 모뎀 접속음, 진행 표시줄, “메일이 도착했습니다”라는 음성처럼 사용자의 위치와 진행 상태를 알려 주는 신호를 다시 활용한다. - 오늘날의 인터페이스는 주의를 끌기 위한 알림은 많지만, 사용자를 안정시키고 방향을 알려 주는 단서는 부족하다. - 항상 보이는 진행률, 전환을 알리는 소리, 일관된 시각 언어 등을 통해 경험의 흐름을 예측 가능하게 만들 수 있다. - 제품 자체가 자극적이지 않은 것만으로는 부족하며, 이미 과부하된 사용자의 신경계를 적극적으로 진정시키는 설계가 필요하다. ## 움직임으로 조율하는 공간형 상호작용 - 클릭과 탭 대신 손짓, 몸의 방향, 기울기와 같은 움직임으로 시스템을 조작한다. - 음악 소프트웨어에서 공중으로 손을 쓸어 소리를 변형하거나, AR 환경에서 몸을 기울여 이동하고, 복잡한 디자인 도구의 시각 효과를 제스처로 조정할 수 있다. - 이런 상호작용은 자동화하거나 빠르게 처리하기 어렵기 때문에 사용자의 지속적인 주의와 현재 순간에 대한 몰입을 요구한다. - 기술이 속도와 효율만 보상하는 것이 아니라, 의도적인 느림과 신체적 참여를 경험의 일부로 만들 수 있다. ## 서로 다른 입력을 결합하는 매시업 - 데스크톱에서 두 파일을 함께 끌어놓거나, 터치스크린에서 두 객체를 동시에 누르거나, XR에서 두 대상을 손뼉 치듯 결합해 새로운 결과물을 만든다. - 시스템은 두 입력의 구조·분위기·의미를 합성해 하나의 새로운 결과를 생성한다. - 예를 들어 재생목록과 도시 지도를 결합하면 음악과 장소 정보가 결합된 새로운 경험을 만들 수 있다. - 다만 제공된 글 내용은 이 매시업 섹션의 중간에서 끝나므로 구체적인 후속 사례와 결론은 확인할 수 없다. 실무적으로는 AI 기능을 추가할 때 명령어와 메뉴를 늘리는 것보다, 사용자의 의도·감정·상황을 어떻게 감지하고 필요한 순간에만 개입할지 먼저 설계하는 것이 중요하다. 특히 자동화가 사용자의 통제권을 빼앗거나 감정을 과도하게 추론하지 않도록, 명확한 피드백과 개입 조절 기능도 함께 제공해야 한다.
원문 읽기(새 탭에서 열림)AI는 개인 생산성 도구를 넘어 팀의 협업 방식 자체를 바꾸고 있다. Figma의 조사에서 AI가 팀워크에 유의미한 변화를 일으킨다고 답한 비율은 2년 전 7%에서 41%로 증가했다. 이제 중요한 경쟁력은 더 많이 만드는 능력보다, 무엇을 만들지 함께 판단하고 빠르게 실행하는 능력이다. ## 조사 범위와 AI 협업의 변화 - 3년간 디자이너, 개발자, PM을 대상으로 조사했으며, 설문 응답 8,403건과 정성 인터뷰 639건을 분석했다. - 조사 대상 국가는 기존 7개국에서 브라질, 인도, 한국을 추가해 10개국으로 확대됐다. - AI가 팀의 협업 방식을 바꾼다고 답한 비율은 2년 전 7%에서 현재 41%로 증가했다. - AI가 개인의 생산성을 높이면서, 이제 최적화 대상은 ‘10배 더 일하는 개인’이 아니라 ‘함께 더 빠르게 움직이는 팀’이 됐다. ## 캔버스 중심의 멀티플레이어 워크플로 - 디자이너의 개발 참여율은 지난 1년 동안 21%에서 41%로 두 배 가까이 증가했다. - 개발자의 디자인 업무 참여율도 44%에서 60%로 상승했다. - 제품 제작자의 76%는 업무의 절반 이상을 캔버스에서 수행하며, 10명 중 6명은 대부분의 시간을 캔버스에서 보낸다. - 개발자의 20%는 터미널이나 프롬프트보다 캔버스에서 프로젝트를 시작하는 것을 선호한다. - 터미널과 프롬프트가 개인 중심의 작업 공간이라면, 캔버스는 아이디어를 나란히 비교하고 피드백을 주고받으며 문제를 함께 탐색하는 공간이다. ## AI 시대에 더 중요해진 디자인의 역할 - AI는 제품, 카피, 이미지 등 거의 무엇이든 빠르게 만들 수 있지만, 무엇을 만들어야 하는지는 스스로 결정하지 못한다. - 프로토타입 제작과 콘텐츠 생성이 쉬워질수록 다음 판단이 중요해진다. - 어떤 제품을 출시할 것인가 - 어떤 메시지를 전달할 것인가 - 경쟁 제품과 어떻게 차별화할 것인가 - 속도, 품질, 비용 사이에서 어떤 타협을 선택할 것인가 - 응답자의 90%는 AI 이전보다 디자인이 최소한 같은 수준으로 중요하다고 답했으며, 약 60%는 더 중요해졌다고 평가했다. - 개발자 중에서도 65%가 디자인의 중요성이 커졌다고 답했다. - AI가 제작 능력의 격차를 줄일수록, 디자인적 판단력과 취향, 사용자 경험을 개선하는 능력이 더 큰 차별점이 된다. - 올바른 의사결정은 개인보다 여러 직군이 함께 논의할 때 더 정교해진다. ## 조직별 AI 도입 패턴 조사에서는 조직의 AI 도입 방식을 네 가지 유형으로 구분했다. - **통합형(Unified, 36%)** - 개인과 조직이 같은 방향으로 AI를 도입한다. - 공유된 업무 방식과 공통의 실행 체계가 마련되어 있다. - **지시형(Directive, 27%)** - 경영진이나 리더십이 위에서부터 AI 도입을 추진한다. - 전략은 존재하지만 실제 현장 업무와 연결되지 않을 수 있다. - **자발적 확산형(Grassroots, 20%)** - 실무자들이 먼저 AI 활용법을 개발하고 조직에 확산한다. - 구성원 간 활용 수준과 방식이 달라 소통 및 지식 공유의 공백이 생길 수 있다. - **초기 단계형(Nascent, 18%)** - AI 활용이 아직 제한적이며 조직 차원의 방향이나 경험이 충분히 형성되지 않았다. ## AI 도입의 핵심은 조직 간 격차 해소 - AI를 ‘혁신적’이라고 평가하는 디자이너, 개발자, PM의 비율은 1년 만에 세 배 증가했다. - 그러나 AI를 빠르게 도입하는 속도와 실제 체감 효과는 조직마다 크게 다르다. - 상향식 도입과 하향식 도입 모두 공통적으로 다음 문제를 겪는다. - 팀마다 AI 활용 수준이 다름 - 공유된 업무 원칙과 플레이북이 없음 - 조직의 전략과 실무 적용 사이에 간극이 존재함 - 팀 간 커뮤니케이션과 지식 공유가 부족함 - 실무자 중심으로 AI를 도입하는 조직은 효과적인 워크플로를 공개하고, 이를 공유 공간과 표준 프로세스로 발전시켜야 한다. - 리더십 중심으로 추진하는 조직은 AI 전략이 실제 업무에서 어떻게 적용되는지 확인하고 현장과의 간극을 줄여야 한다. AI 시대의 목표는 한 사람이 얼마나 빨리 일하느냐가 아니라, 팀 전체가 같은 맥락에서 더 빠르게 판단하고 움직이는 것이다. 따라서 기업은 개인별 AI 도구 도입에만 집중하기보다, 캔버스와 같은 협업 공간, 공통 플레이북, 직군 간 의사결정 프로세스를 함께 구축하는 것이 바람직하다.
원문 읽기(새 탭에서 열림)Figma Config 2026의 핵심 방향은 캔버스를 단순한 디자인 작업 공간이 아니라 코드·모션·셰이더·생성형 플러그인 등을 함께 다루는 창작 환경으로 확장하는 것이다. Figma는 AI가 작업의 진입장벽은 낮췄지만 창작의 한계를 넓히는 것은 결국 디자이너와 크리에이터의 몫이라고 강조한다. 이를 위해 디자인과 코드의 경계를 없애고, 더 풍부한 표현과 협업을 캔버스 안에서 가능하게 하려 한다. ## 디자인 캔버스의 확장 - Figma는 이미지, 벡터, 디자인 레이어뿐 아니라 코드와 모션도 디자인 재료로 취급하려 한다. - 코드·모션·셰이더·생성형 플러그인·Weave 도구를 하나의 캔버스에서 조합하는 것이 이번 Config의 주요 방향이다. - 캔버스는 결과물이 저장되는 장소를 넘어, 아이디어를 연결하고 동료와 함께 반복적으로 발전시키는 협업 공간으로 정의된다. - AI가 창작의 진입장벽을 낮췄다면, 더 높은 수준의 창의성과 과감한 시도는 사용자가 만들어야 한다는 관점을 제시한다. ## 코드 레이어로 디자인과 개발 통합 - 기존의 “디자인 대 코드”라는 구분은 인위적인 논쟁이며, 코드는 이미지나 벡터와 같은 디자인 재료라는 것이 Figma의 주장이다. - Figma Design의 모든 디자인 레이어를 클릭 한 번 또는 프롬프트로 인터랙티브한 코드 레이어로 변환할 수 있다. - 코드 레이어를 복제해 여러 구현 방향을 나란히 비교하고 탐색할 수 있다. - 일반적인 Figma 캔버스처럼 팀원이 같은 파일에서 코드를 수정하고, 의견을 남기고, 반복 작업을 진행할 수 있다. - 코드로 만든 결과물을 다시 편집 가능한 디자인 레이어로 추출할 수 있다. - 디자인 레이어를 수정한 뒤에는 한 번의 클릭으로 변경 사항을 코드 레이어에 반영할 수 있어 디자인과 구현 사이를 양방향으로 오갈 수 있다. - 코드 레이어의 얼리 액세스는 7월부터 시작될 예정이며, 베타 대기자 등록을 통해 참여할 수 있다. ## Figma Motion으로 디자인에 움직임 추가 - Figma Design 안에 타임라인 기반의 모션 제작 기능이 추가된다. - 키프레임과 프리셋을 사용해 처음부터 애니메이션을 만들거나, 기존 디자인에 모션을 덧입힐 수 있다. - Figma agent를 이용해 애니메이션의 초기 시안을 생성할 수도 있다. - 모션 디자이너에게는 반복적인 작업을 줄이고, 창의적인 표현에 더 집중할 수 있는 환경을 제공한다. - 애니메이션을 컴포넌트에 한 번 정의하면 여러 화면과 협업자의 파일에서 디자인 시스템의 일부처럼 재사용할 수 있다. ## 모션과 개발 도구의 연결 - Dev Mode에서는 전체 타임라인을 확인하고 검사할 수 있다. - 각 키프레임, 타이밍 값, 이징 곡선을 별도의 해석 없이 읽을 수 있다. - 애니메이션 코드를 CSS, JSON 또는 React 프레임워크용 코드로 직접 복사할 수 있다. - MCP와 호환되므로 애니메이션이 적용된 프레임을 코딩 에이전트로 전달해 구현할 수 있다. - 결과물은 MP4, WebM, Animated SVG, GIF 등으로 내보낼 수 있으며, 향후 더 많은 포맷이 추가될 예정이다. Figma Config 2026은 디자인·개발·모션을 별도 도구로 분리하기보다 하나의 협업 캔버스에서 연결하려는 흐름을 보여준다. 특히 코드 레이어와 Figma Motion은 디자이너가 구현 가능성을 즉시 실험하고, 개발자는 디자인 의도와 애니메이션 세부 정보를 정확히 확인하도록 돕는 기능으로 볼 수 있다.
원문 읽기(새 탭에서 열림)Figma는 코드 레이어를 통해 실행 가능한 코드를 디자인 캔버스 안에서 생성·비교·수정할 수 있도록 한다. 디자이너와 개발자는 코드와 디자인을 오가는 대신 같은 Figma 파일에서 아이디어를 함께 탐색하고, 팀의 피드백을 반영하며, 최종 코드를 저장소에 반영할 수 있다. 코드 레이어는 디자인과 개발의 경계를 좁혀 협업 중심의 프로토타이핑을 가능하게 하는 기능이다. ## 캔버스에서 코드 시작하기 - Figma Design의 툴바에서 코드 레이어를 추가하거나, 기존 프레임을 코드로 변환할 수 있다. - Figma Agent에게 원하는 결과를 설명해 코드를 생성할 수도 있다. - 템플릿에서 시작하거나 직접 만들고 싶은 내용을 프롬프트로 입력할 수 있다. - GitHub 저장소를 가져오거나 로컬 폴더를 업로드해 기존 코드베이스를 불러올 수 있다. - Figma Make에서 생성·수정한 코드도 캔버스의 코드 레이어로 가져와 팀과 공유할 수 있다. ## 여러 대안을 나란히 비교하기 - 기존 프레임을 복제해 여러 디자인 방향을 시험하듯 코드 레이어도 복제해 대안을 만들 수 있다. - 실제로 작동하는 화면을 캔버스에서 비교하므로 정적인 시안만 볼 때보다 사용 경험을 구체적으로 평가할 수 있다. - 요소를 이동·조정·리사이즈하면 코드에 즉시 반영된다. - 프롬프트로 새 버전을 생성하면서도 기존 버전은 보존할 수 있다. - 팀원은 공유 파일 안에서 댓글을 남기거나 동일한 코드 레이어를 대상으로 Agent에 추가 작업을 요청할 수 있다. ## 코드와 디자인 레이어 오가기 - `Extract designs` 기능을 사용하면 코드의 현재 상태를 편집 가능한 Figma 레이어로 변환할 수 있다. - 전체 화면뿐 아니라 특정 화면, 상태, 사용자 플로우만 선택해 캔버스로 가져올 수 있다. - 코드로 구현된 인터랙션과 상태를 시각적으로 분석하고, 일반적인 Figma 디자인 요소처럼 편집할 수 있다. - 캔버스에서 수정한 내용은 한 번의 클릭으로 코드 레이어에 업데이트할 수 있어 디자인과 구현 사이의 반복 작업이 짧아진다. ## 코드 편집과 저장소 반영 - 코드 에디터에서 원하는 변경 사항을 주석이나 설명으로 작성하고 Agent에게 수정을 요청할 수 있다. - 필요하면 개발자가 직접 코드를 편집할 수도 있다. - 수정 결과를 다시 코드 레이어로 변환해 팀에 공유할 수 있다. - 최종적으로 확정한 변경 사항은 저장소에 push해 실제 소스 코드에 반영할 수 있다. - 따라서 Figma 캔버스는 단순한 시각화 공간이 아니라, 아이디어 탐색부터 코드 변경 및 공유까지 이어지는 협업 환경이 된다. ## 출시 계획 - 코드 레이어는 2026년 6월 기준 향후 몇 주 동안 비공개 베타로 제공될 예정이다. - 초기 접근 권한은 Figma의 베타 신청 페이지를 통해 요청할 수 있다. - 기능 세부 사항과 Config에서 발표된 다른 업데이트는 Figma Help Center와 Figma Learn에서 확인할 수 있다. 실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.
원문 읽기(새 탭에서 열림)Figma의 디자인 에이전트가 오픈 베타에서 더 많은 사용자에게 제공되며, 단순한 프롬프트를 넘어 사용자 정의 도구와 팀의 작업 맥락을 활용할 수 있게 됐다. 사용자는 에이전트에게 재사용 가능한 플러그인과 셰이더를 만들도록 요청해 Figma 캔버스 안에서 자신만의 디자인 워크플로를 구축할 수 있다. 이를 통해 에이전트는 결과물을 생성하는 도구를 넘어 사용자의 작업 방식을 이해하고 협업하는 파트너에 가까워진다. ## Figma 디자인 에이전트의 확장 - 에이전트는 Figma 캔버스에서 직접 작동하며, 디자인 작업의 유연성·정밀도·창작 제어력을 높인다. - 팀의 작업 방식과 실제 디자인 맥락을 이해할수록 단순히 결과물을 만드는 것을 넘어 협업할 수 있다는 점을 강조한다. - Figma는 에이전트와 사용자 정의 도구를 직접 시험할 수 있는 커뮤니티 플레이그라운드 파일도 제공한다. - 사용자의 요구를 자연어로 설명하면 에이전트가 도구 제작과 문제 해결 방법까지 제안한다. ## 프롬프트로 만드는 생성형 플러그인 - 기존에는 플러그인을 만들려면 개발 지식과 별도의 개발 환경이 필요했지만, 이제 에이전트에게 재사용 가능한 플러그인 제작을 요청할 수 있다. - 생성형 플러그인은 다음과 같은 작업에 활용될 수 있다. - HTML을 Figma 캔버스로 가져오기 - 대시보드 레이아웃 생성 - 데이터를 시각화하기 - 이미지 자산 자동 배치 - `PropsKit`을 사용하기 때문에 Figma의 기본 기능처럼 자연스럽게 동작한다. - 캔버스 안에서 직접 결과를 확인하고 반복 수정할 수 있어, 외부 도구를 오가는 번거로움이 줄어든다. - Figma 밖의 AI 서비스나 서드파티 API와 연동해야 하는 경우에는 기존 방식의 클래식 플러그인을 사용해야 한다. - 플러그인이나 셰이더 자체는 제작자, 팀원, 커뮤니티 사용자 모두 무료로 사용할 수 있지만, 에이전트에게 제작을 요청하는 기능은 일반 출시 후 AI 크레딧을 사용하게 된다. ## WebGPU 기반 셰이더 효과 - 에이전트는 픽셀이 렌더링되는 방식을 정의하는 작은 프로그램인 셰이더도 생성할 수 있다. - Figma의 WebGPU 기반 렌더러를 활용해 다음과 같은 시각 효과를 만들 수 있다. - 디더링 - 리퀴드 메탈 - 프랙털 노이즈 - 렌즈 왜곡 - 입자 늘이기 - 색상 외곽선 - 셰이더 효과는 네이티브 Figma 효과처럼 쌓아 사용할 수 있으며, 속성을 조절하거나 기본 효과와 결합할 수 있다. ## 셰이더 효과와 셰이더 필 - **셰이더 효과** - 레이어에 적용되는 사용자 정의 시각 효과다. - 입자 효과, 렌즈 왜곡, 컬러 아웃라인 등 다양한 효과를 만들 수 있다. - 여러 효과를 조합해 복합적인 결과를 만들 수 있다. - **셰이더 필** - 단색이나 일반 그라디언트를 넘어서는 동적·생성형 채우기다. - 수채화, 모아레, 패턴 그리드 등을 표현할 수 있다. - 디더 웨이브, 유체 하프톤, 파티클 웹, 마그네틱 필드 같은 프리셋으로 활용할 수 있다. - 사용자는 셰이더의 기능을 정의하고, 에이전트와 대화하며 UI와 조정 가능한 매개변수를 발전시킬 수 있다. - 사진에 콜라주, 마블링, 빛샘, 금속 엠보싱, 프리즘 효과를 적용하는 등 개인의 시각적 스타일을 재사용 가능한 워크플로로 만들 수 있다. ## 디자이너와 에이전트의 협업 방식 - 제품 디자이너 Edward Chechique는 과거 개발자 지원이나 여러 외부 도구가 필요했던 생성형 플러그인 제작을 Figma 안에서 직접 처리할 수 있게 됐다고 설명한다. - 크리에이티브 테크놀로지스트 Anna Zhang은 에이전트와 기능과 UI를 주고받는 과정을 “협상”에 비유한다. - 에이전트가 제안한 해결책과 생성 결과가 다음에 추가할 매개변수와 기능에 영향을 주면서, 일회성 생성보다 반복적인 공동 설계가 가능해진다. 자신만의 레이아웃·효과·데이터 시각화 도구가 필요하다면 에이전트로 생성형 플러그인이나 셰이더를 만들어 보는 것이 유용하다. 다만 외부 API 연동은 클래식 플러그인을 사용해야 하며, 에이전트 기반 제작 기능은 AI 크레딧 비용과 지원 범위를 확인하는 것이 좋다.
원문 읽기(새 탭에서 열림)2026년 6월 24일 GitLab은 19.1.1, 19.0.3, 18.11.6 패치 릴리스를 공개했으며, 여러 보안 취약점과 버그를 수정했다. 자체 호스팅 CE/EE 사용자는 즉시 지원 버전의 최신 패치로 업그레이드해야 하며, GitLab.com은 이미 패치가 적용되었다. GitLab Dedicated 고객은 별도 조치가 필요하지 않다. ## 패치 릴리스와 권고 사항 - 대상 버전: - GitLab 19.1.1 - GitLab 19.0.3 - GitLab 18.11.6 - Omnibus, 소스 설치, Helm 차트 등 배포 방식과 관계없이 취약 버전은 영향을 받을 수 있다. - GitLab은 정기적으로 매월 둘째·넷째 수요일에 패치 릴리스를 제공하며, 고위험 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치 릴리스 후 30일이 지나면 공개된다. ## 분석 대시보드 XSS - **CVE-2026-10086**, CVSS 8.7. - GitLab EE의 Analytics Dashboard에서 사용자 입력 sanitization이 충분하지 않았다. - 인증된 Developer 권한 사용자가 다른 사용자의 세션 컨텍스트에서 임의의 클라이언트 측 코드를 실행할 수 있었다. - GitLab EE 16.4 이상 중 다음 버전 이전이 영향받는다. - 18.11.6 - 19.0.3 - 19.1.1 ## Web IDE 자산 처리기의 XSS - **CVE-2026-10712**, CVSS 8.0. - Web IDE workbench의 경로 검증 오류를 악용하면 인증되지 않은 공격자가 사용자의 브라우저 세션에서 임의의 JavaScript를 실행할 수 있었다. - GitLab CE/EE의 다음 버전 이전이 영향을 받는다. - 18.11.6 - 19.0.3 - 19.1.1 - 네트워크를 통한 공격이 가능하지만, 특정 조건과 사용자 상호작용이 필요하다. ## Duo Workflows 정보 노출 - **CVE-2026-12053**, CVSS 7.7. - GitLab EE의 Duo Workflows가 출력 내용을 충분히 필터링하지 못했다. - 조건에 따라 사용자가 프로젝트에 이미 커밋된 민감한 정보를 열람할 수 있었다. - GitLab EE 19.1 계열에서 19.1.1 이전 버전이 영향받는다. ## Virtual Registry 권한 우회 - **CVE-2026-5309**, CVSS 5.4. - Virtual Registry Cleanup Policy API의 권한 검사가 잘못되어 있었다. - 인증된 사용자가 다른 그룹의 가상 레지스트리 정리 정책을 읽거나 수정할 수 있었다. - GitLab EE 18.6 이상 및 19.x의 특정 이전 버전이 영향을 받는다. ## Rapid Diffs의 부적절한 권한 검사 - **CVE-2026-2238**, CVSS 5.3. - 공개 프로젝트에서 인증되지 않은 사용자가 비공개 이슈 참조를 볼 수 있었다. - GitLab CE/EE 17.5 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## DAST 사이트 프로필 비밀정보 노출 - **CVE-2026-11379**, CVSS 5.3. - DAST 사이트 프로필 관리 기능의 권한 오류로 Developer 권한 사용자가 사이트 프로필의 비밀정보를 탈취할 수 있었다. - GitLab EE 13.11 이상부터 영향을 받으며, 각 유지보수 계열의 최신 패치 이전 버전이 취약하다. ## CI/CD API 로그 정보 노출 - **CVE-2026-8330**, CVSS 4.4. - CI/CD API 엔드포인트의 필터링 부족으로 민감한 정보가 애플리케이션 로그에 기록될 수 있었다. - GitLab CE/EE 9.3 이후의 오래된 버전부터 이번 패치 이전 버전까지 영향을 받는다. - 로그에 노출된 토큰이나 비밀값이 있다면 업그레이드와 함께 해당 자격 증명을 교체해야 한다. ## Snippets 콘텐츠 은닉 - **CVE-2026-1606**, CVSS 4.3. - Snippets의 입력값 검증 오류로 인증된 사용자가 콘텐츠를 숨겨 표시할 수 있었다. - GitLab CE/EE 14.8 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 영향받는다. ## Maven 패키지 보호 규칙 우회 - **CVE-2026-5952**, CVSS 4.3. - Maven Package Registry의 권한 검사 오류로 Developer 권한 사용자가 보호된 Maven 패키지 메타데이터를 덮어쓸 수 있었다. - GitLab CE/EE 17.11 이상 중 최신 패치 이전 버전이 영향을 받는다. ## 그룹 패키지 API 접근 제어 오류 - **CVE-2026-5796**, CVSS 4.3. - Package Registry가 비활성화된 프로젝트의 패키지 메타데이터를 Reporter 권한의 그룹 사용자가 열람할 수 있었다. - GitLab CE/EE 13.6 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## 권장 대응 - 자체 호스팅 GitLab은 가능한 한 즉시 18.11.6, 19.0.3, 19.1.1 중 지원 중인 계열로 업그레이드한다. - 업그레이드 전 백업과 복구 절차를 확인하고, 업그레이드 후 CI/CD, Package Registry, Web IDE, DAST, Duo Workflows를 점검한다. - 로그나 설정에서 민감정보 노출 가능성이 확인되면 토큰·비밀번호·패키지 자격 증명을 함께 교체한다. - GitLab.com은 이미 수정 버전이 적용되어 별도 조치가 필요하지 않다.
원문 읽기(새 탭에서 열림)LLM의 추론 과정은 복잡한 논리 문제가 없어도 단순한 사실을 회상하는 데 도움을 준다. 연구진은 그 이유로 생성된 추론 토큰이 추가 계산 공간으로 작동하는 효과와, 관련 사실을 먼저 떠올려 정답을 활성화하는 사실 프라이밍을 제시한다. 다만 중간에 생성한 사실이 환각일 수 있어, 이 방식은 정확성 검증과 함께 사용해야 한다. ## 단순한 사실 회상에도 추론이 효과적인 이유 - 일반적으로 Chain-of-Thought(CoT)는 수학, 프로그래밍, 다단계 질의응답처럼 복잡한 문제를 단계적으로 해결할 때 유용하다. - 그러나 “Mary Engle Pennington이 National Inventors Hall of Fame에 헌액된 연도는?”처럼 단일 사실을 묻는 질문에는 명시적인 논리 전개가 필요하지 않다. - 연구진은 이런 질문에서도 추론을 허용하면, 추론을 끈 상태에서는 사실상 회수하기 어려운 정답이 생성될 수 있음을 확인했다. - 실험에는 Gemini-2.5 Flash/Pro와 Qwen3-32B, SimpleQA Verified 및 EntityQuestions 데이터셋이 사용됐다. ## 지식 회수 한계 측정: pass@k - `pass@k`는 한 번의 최상위 답변만 보는 대신, 여러 번 생성한 답변 중 정답이 포함되는지를 측정한다. - 이를 통해 정답이 모델의 출력 분포 안에 잠재적으로 존재하는지, 현재 최상위 답변으로 선택되지 않았을 뿐인지 구분할 수 있다. - 추론 ON/OFF 모드를 비교한 결과, 세 모델과 두 데이터셋에서 추론을 활성화했을 때 정답 회수율이 일관되게 향상됐다. - 데이터셋이 주로 단순한 단일 단계 질문으로 구성되어 있어, 성능 향상이 복잡한 문제 분해 때문이라고 보기 어렵다. ## 생성 토큰이 제공하는 계산 버퍼 - 첫 번째 메커니즘은 추론 토큰이 모델에 추가적인 계산 시간과 내부 상태 갱신 기회를 제공한다는 것이다. - 연구진은 모델의 자연스러운 추론 내용을 제거하고, `"Let me think"` 같은 무의미한 문자열을 원래 추론과 같은 길이로 반복해 넣었다. - 의미 없는 토큰만 제공해도 추론을 완전히 끈 경우보다 사실 회상 성능이 크게 향상됐다. - 이는 추가 토큰이 의미를 전달하지 않더라도 여러 번의 forward pass를 통해 모델이 내부 표현을 정제하고, 접근하기 어려운 지식을 검색하게 만들 수 있음을 시사한다. - 다만 토큰을 계속 늘리면 효과가 감소하며, 자연스러운 추론의 성능에는 도달하지 못했다. - 따라서 계산량 자체가 중요하지만, 추론 과정에 포함된 실제 내용도 추가적인 역할을 한다. ## 관련 사실을 떠올리는 사실 프라이밍 - 자연스러운 추론을 분석한 결과, 모델은 논리적 증명을 수행하기보다 질문과 관련된 주변 사실을 먼저 나열하는 경우가 많았다. - 연구진은 이를 인간 기억의 ‘ spreading activation’과 유사한 현상으로 보고, **사실 프라이밍(factual priming)**이라고 명명했다. - 관련 사실을 생성하면 질문과 정답 사이에 의미적 연결 고리가 형성되어, 목표 사실을 회상하기 쉬워진다. - 실험에서는 추론 과정에서 나온 구체적인 사실만 추출하고, 채움말, 검색 계획, 정답 자체에 대한 직접 언급은 제거했다. - 짧은 사실 목록만 정답 생성에 제공해도 추론이 만들어내는 성능 향상의 상당 부분이 재현됐다. - 예를 들어 네팔의 제10대 왕을 묻는 질문에서 모델이 앞선 9명의 왕을 먼저 떠올리면, 이 정보들이 제10대 왕을 회상하기 위한 의미적 준비 단계로 작동할 수 있다. - 이 효과는 추론 모드가 꺼진 상태에서 사실 목록을 추가 문맥으로 제공했을 때도 나타났다. ## 환각으로 인한 위험 - 사실 프라이밍은 모델이 중간 사실을 스스로 생성한다는 점에서 근본적인 위험을 가진다. - 중간에 떠올린 관련 사실이 실제 지식이 아니라 환각일 경우, 잘못된 정보가 정답 회상을 방해하거나 오답을 강화할 수 있다. - 제공된 글은 이 위험을 검증하는 실험을 소개하는 도중에 끝나므로, 환각의 구체적인 측정 결과와 완화 방법은 확인할 수 없다. ## 실용적인 결론 - 단순한 사실 질문에서도 모델의 추론을 허용하면 잠재 지식 회수율을 높일 수 있다. - 성능 향상은 충분한 생성 길이를 제공하는 것과, 관련 사실을 먼저 회상하도록 유도하는 방식에서 비롯된다. - 다만 중간 추론을 그대로 신뢰하지 말고, 외부 검색·검증 또는 여러 독립 샘플의 일치 여부를 함께 확인하는 것이 안전하다.
원문 읽기(새 탭에서 열림)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`을 활용한 단계적 마이그레이션을 고려할 수 있습니다.
원문 읽기(새 탭에서 열림)
