문제AI 바이브 코딩 도구들이 빠르게 UI 를 생성하지만 디자인 시스템 규칙을 따르지 않아 "당근스러운 화면"을 만들 수 없음.

접근Kraft 의사결정 자동화 도구를 어드민 → CLI → 에이전트로 진화시키면서 DesignSpec 중간 표현 + 11개 Scorer 기반 검증 + Mastra 하네스 + Claude Agent SDK + 크로스세션 메모리 누적으로 구조화.

결과SEED 디자인 시스템 준수 여부 자동 검증, 도메인별 맥락 반영, 세션 간 학습이 누적되는 UI 생성 플랫폼 구축.

문제토스 프론트엔드 디자인 시스템 v1 이 한계에 도달. 새 컴포넌트 라이브러리(Toss Front 2) 를 만들기로 했는데 처음 설계 결정에 실패가 있었다.

접근실패한 디자인 결정을 솔직히 회고하고 점진적으로 개선. 디자이너-개발자 협업 방식, 마이그레이션 전략, 사내 적용 단계까지 정리.

결과새 디자인 시스템이 사내 표준으로 자리잡고, 실패에서 얻은 디자인 시스템 운영 원칙을 정리. 자랑보다 회고 톤이 가치 있다.

문제lodash 가 무거워졌고, ESM/tree-shaking 시대에 잘 안 맞는 부분이 늘었다.

접근토스가 es-toolkit 을 만들어 lodash 의 modern alternative 를 제공. 네이티브 메서드 활용 + TypeScript-first + tree-shaking 친화 설계.

결과npm weekly download 1000만 도달. 번들 크기 97% 감소 + 성능 2배 향상. OSS 채택 사례.

문제공통 컴포넌트 라이브러리는 시간이 갈수록 누가 관리하고, 어떻게 기여 받고, breaking change 는 어떻게 알릴지 모호해진다.

접근카카오페이가 공통 컴포넌트 운영 framework 를 정리. 명확한 ownership 모델, 기여 가이드, semver 룰, deprecation 정책까지.

결과라이브러리가 "건강하게" 유지되며 새 기능 추가도 빠르다. 디자인 시스템 / 라이브러리 운영의 참고 사례.

문제Yarn Berry 가 한때 "새로운 표준" 으로 도입됐지만 모노레포 빌드 속도, lockfile 안정성에서 한계가 노출됐다.

접근카카오페이가 pnpm 으로 전환. install 시간, dependency 처리, monorepo 운영 비교 데이터를 정리.

결과"그때는 맞고 지금은 틀리다" 의 의사결정 변화 사례. 도구 선택은 시대에 따라 다르다는 교훈.

문제외부 개발자가 쓸 SDK 가 어려우면 채택률이 떨어진다. 초기화 부담 / 타입 안전성 / 에러 메시지의 명확함이 핵심.

접근Toss Front SDK 의 "쓰기 쉬움" 설계 회고. 호출 한 줄로 시작 가능한 init, 자동 type inference, 친절한 에러 메시지까지의 DX 설계 결정.

결과외부 개발자의 "첫 동작" 까지 걸리는 시간을 크게 단축. SDK 설계 시 DX 우선 결정의 사례.

문제사내 디자인 시스템 v1 의 한계 (확장성, 버전 관리, 빌드 속도) 가 누적되며 v2 가 필요해졌다.

접근쏘카 디자인 시스템 2.0 의 기술 측면. 토큰 / 컴포넌트 구조, 빌드 / 배포 파이프라인, 버전 관리 전략을 새로 설계.

결과새 컴포넌트 추가 / 마이그레이션 속도 개선. 기술 측면에서 "굴러가는" 디자인 시스템 정착.

문제디자인 시스템은 기술만 잘 만들어도 운영 거버넌스가 없으면 점차 사용 빈도가 줄고 "디자인 빚" 이 쌓인다.

접근쏘카 디자인 시스템 2.0 의 시스템 측면 — 오너십 모델, 기여 프로세스, 우선순위 결정 framework, 변경 알림 체계.

결과디자인 시스템이 사내 표준으로 자리잡고, 디자이너 / 개발자 협업 비용이 줄었다.

문제1년치 FE 동향을 한 번에 따라잡고 싶을 때 흩어진 글을 모으기 번거롭다.

접근NHN Cloud 가 2025년 프론트엔드 동향을 한 글로 정리. React 19, Next 15, signals / zustand, Bun / Deno 경쟁, AI 코딩 도구까지 1년치 흐름.

결과1년 동향을 한 번에 따라잡을 수 있는 가이드. 새로 합류한 팀원 / 오랜만에 FE 복귀하는 사람에게 유용.

문제게임 엔진 경험 없이 웹뷰 게이미피케이션 앱(일해라 김뱅샐)을 만들어야 했다. 캐릭터 옷 조합 수가 폭발적으로 늘어 모든 조합마다 애니메이션 파일을 만들 수 없었고, iOS 웹뷰에서 화면 깜빡임도 발생했다.

접근Lottie JSON 구조를 런타임에 조작해 하나의 파일로 모든 조합을 표현. assets 배열의 이미지 경로만 동적으로 교체한다. iOS 깜빡임은 img absolute 누적 대신 background-image 로 전환해 해결.

결과React + DOM + Lottie 만으로 게임 엔진 없이 캐릭터 커스터마이징을 구현했다. 디자이너는 뼈대만 만들고 개발팀은 JSON 만 다루는 분업 구조를 정착시켰다.