KNUD
1.스프레이 표현을 위한 래스터·벡터와 Canvas API 기초
배경 KNUD 2026 졸업전시 웹사이트의 메인 화면에는 마우스 클릭과 이동에 반응하는 스프레이 인터랙션을 적용하고 있다. 목표는 단순히 점을 늘어놓는 효과가 아니라, 스프레이 캔을 분사했을 때처럼 밀도·번짐·색의 누적이 느껴지는 질감을 만드는 것이다. 이 효과는
2.스프레이 인터랙션을 만들기 전에 — 브라우저의 CPU, GPU, 프로세스부터 이해하기
스프레이 인터랙션을 만들기 전에 브라우저 내비게이션부터 정리해 보려 했다. 그런데 URL을 입력한 뒤 무슨 일이 일어나는지 따라가다 보니, 그보다 먼저 답해야 할 질문이 있었다. 브라우저는 누가 실행하고, 누가 화면을 그릴까? 마우스를 움직일 때마다 이미지가 나타나
3.스프레이 인터랙션을 만들기 전에 — 브라우저 내비게이션부터 다시 이해하기
이 글에서 먼저 이해할 것 이번 글은 스프레이 인터랙션을 구현하기 전, 브라우저가 페이지 이동을 시작하고 문서를 렌더러에 넘기는 과정을 학습한 기록이다. 브라우저에서 URL을 입력하거나 링크를 누르는 일은 단순히 “새 페이지를 연다”는 한 문장으로 끝나지 않는다.
4.브라우저 렌더링 파이프라인으로 이해하는 Canvas 인터랙션 — 스프레이가 버벅이는 이유
이전 글에서 브라우저가 웹 콘텐츠를 처리하는 렌더러 프로세스와 화면을 구성하는 큰 흐름을 정리했다. 이번 글에서는 그 흐름을 KNUD 2026 졸업전시 웹사이트의 Canvas 스프레이 인터랙션에 연결해 본다. 메인 Hero에서 클릭·드래그하면 색이 바뀌는 스프레이가
5.Canvas 스프레이의 입력을 프레임으로 소비하기 — 컴포지터와 포인터 이벤트
2편에서 이어서 2편에서는 문서가 렌더러에 도착한 뒤, 화면이 스타일 계·레이아웃·페인트·래스터화·합성을 거쳐 만들어지는 흐름을 Canvas 스프레이에 연결했다. 그다음 질문은 “무엇을 그릴 것인가”가 아니라 “사용자의 입력은 어떤 경로로 들어오고, 어느 빈도로 그리
6.Canvas 애니메이션 성능은 어떻게 측정할까? — Chrome Performance 기초부터 결과 읽기까지
이 글은 앞서 작성한 Canvas 스프레이의 입력을 프레임으로 소비하기 — 컴포지터와 포인터 이벤트에서 이어진다. 이전 글에서는 포인터 입력을 이벤트가 발생할 때마다 그리지 않고, 입력 좌표를 모아 requestAnimationFrame에서 프레임 단위로 소비하도록 바
7.Canvas 스프레이는 왜 끊길까? — 성능 측정 결과 분석
시리즈의 첫 글에서는 포인터 입력을 이벤트마다 즉시 그리지 않고 requestAnimationFrame에서 프레임 단위로 소비하도록 구조를 바꿨다. > >[이어진 학습 글](https://velog.io/@subjeelee/Canvas-%EC%84%B1%EB%8A%A5
8.같은 스프레이 질감을 유지하면서 렌더 비용을 39% 줄인 과정
앞선 측정에서는 KNUD 메인 페이지의 Fast drag에서 활성 스탬프가 Native 기준 733개까지 쌓였고, Render p95와 Frame interval p95가 각각 7.55ms와 20.30ms까지 증가하는 것을 확인했다. 입력 이벤트 수 자체보다 만료 전
9.AI Agent가 측정한 성능을 어떻게 믿을 수 있을까 — 재현 가능한 E2E 실험 설계
앞선 글에서는 프레임 예산과 p95를 읽는 기준을 바탕으로 KNUD 메인 페이지의 Canvas 스프레이를 Native와 4× CPU 조건에서 50회 측정했다. 그 결과 빠른 입력에서 포인터 이벤트 수보다 동시에 살아 있는 스탬프 수가 크게 증가했고, Render p9
10.스크린샷과 Figma MCP, UI 구현 정확도는 어디서 갈릴까
Figma 시안을 코드로 옮길 때, 에이전트에게 이미지를 한 장 보여 주는 방법과 Figma MCP를 연결하는 방법은 겉보기보다 다른 입력을 제공한다. 첫 번째 방법에서 에이전트는 완성된 픽셀을 본다. 두 번째 방법에서는 픽셀과 함께 레이어·치수·변수·컴포넌트·원본
11.AI Agent로 Canvas 성능을 측정했다. 그런데 측정부터 검증해야 했다 — KNUD 최적화
“스프레이가 느리다”는 인상을 재현 가능한 성능 문제로 바꾸는 과정. > > 이 글은 최적화 이전의 기준선 측정과 원인 분리를 다룬다. 구현과 전후 비교는 2편에서 이어간다. KNUD 졸업전시 웹사이트의 메인 화면에는 사용자가 직접 칠하는 Canvas 스프레이가 있다
12.디자인은 그대로, Canvas 작업은 줄였다 — KNUD 최적화
1편에서는 빠른 입력이 누적될수록 스프레이 렌더링 경로의 부담과 프레임 누락이 커지고, 에셋 모션을 꺼도 회복되지 않는다는 사실을 확인했다. 2편에서는 같은 디자인을 유지한 채 렌더링 경로를 세 단계로 바꾸고, 운영 배포 환경에서 Before/After를 비교한다.
13.30장이 넘는 고화질 이미지 아카이브를 어떻게 가볍게 보여줄까
경북대학교 디자인학과 졸업전시 웹사이트의 Space 페이지 하단에는 전시 현장을 기록하는 Archive가 들어갈 예정이다. 처음에는 12개 정도의 자리만 만들어 두었지만, 실제 운영에서는 30장을 넘어 40장 가까운 고화질 사진이 들어올 수 있다. 사진 하나의 품질만