## 개요

드로잉 기능을 만들고 나서 뿌듯했던 시간은 짧았다. QA를 돌리는데 창 크기를 바꾸는 순간 드로잉이 전부 어긋났다. 사각형은 비디오 밖으로 튀어나가고, 펜 스트로크는 엉뚱한 위치에 떠 있었다. 여러 방식으로 고쳐봤지만 임시방편을 반복했고, 결국 좌표계를 처음부터 다시 생각해야 했다.

## 화면 좌표를 그대로 쓰면

Konva에서 Stage는 캔버스 전체를 감싸는 최상위 컨테이너다. react-konva에서는 `<Stage>` 컴포넌트를 쓰면 된다.

```tsx
<Stage width={1920} height={1080}>
  <Layer>
    <Line points={[0, 0, 100, 100]} stroke="red" />
  </Layer>
</Stage>
```

내부적으로는 `<Stage>`가 div 안에 `<canvas>` 요소를 자동으로 생성한다.

```html

<div>
  <div class="konvajs-content">
    <canvas width="1920" height="1080"></canvas>
  </div>
</div>
```

`<canvas>` 태그를 직접 만들 필요 없이, `width`와 `height`를 props로 넘기면 Konva가 알아서 캔버스를 생성하고 그 위에 올라가는 모든 도형의 렌더링을 관할한다.

이 Stage의 크기를 화면에 맞추고, 마우스 좌표를 그대로 저장했다.

```typescript
const handleMouseDown = (e: Konva.KonvaEventObject<MouseEvent>) => {
  const pos = e.target.getStage()?.getPointerPosition();
  if (!pos) return;

  const newStroke: DrawingStroke = {
    tool: selectedTool,
    points: [pos.x, pos.y], // 화면 픽셀 좌표 그대로 저장
    color: drawingToolConfig.color,
    strokeWidth: drawingToolConfig.strokeWidth,
    id: generateId(),
  };

  addStroke(newStroke);
};
```

예를 들어 1920x1080 화면에서 `(960, 540)`에 점을 찍으면, 그 좌표가 그대로 서버에 저장된다. 화면 크기와 좌표가 1:1로 대응하는 상태다. 문제는 화면 크기가 변할 때 벌어진다.

창 크기를 1280x720으로 줄이면 화면은 줄어드는데, 좌표 `(960, 540)`은 그대로다. 1280 안에 960이 들어가긴 하지만, 비디오 위에 정확히 겹쳐야 하는 드로잉이 비디오와 어긋나기 시작한다.

## 일단 scale로

우선 현재 화면 크기를 원본 크기로 나눠서 scale을 계산하고, 이 값을 `providedScale`이라는 props로 드로잉 컴포넌트에 전달하는 방식으로 고쳐봤다. 드로잉 컴포넌트는 자기가 scale을 계산하는 게 아니라, 외부에서 받은 값을 그대로 쓴다.

```typescript
if (providedScale !== undefined) {
  calculatedScale = providedScale;
}
```

1920x1080 화면에서 그린 드로잉을 1280x720 화면에서 열면, 1280 / 1920 = 0.67이 scale이 된다. 이 값을 렌더링에 적용하면 드로잉이 비율에 맞게 축소된다. 화면을 줄였다 늘렸다 해도 scale이 따라가니까, 당장은 드로잉이 비디오와 정확히 겹쳤다.

## 다시 고민

며칠 뒤 같은 버그가 다시 올라왔다. 이번에는 "창 크기를 변경한 후 페이지를 나갔다가 다시 들어오면" 드로잉이 틀어진다는 것이었다.

원인을 추적해보니, `providedScale`이 현재 화면 크기 기준으로 계산된 값이라는 게 문제였다. 1920x1080 화면에서 1280x720으로 줄인 상태에서 scale이 0.67로 계산된다. 여기까지는 맞다. 하지만 이 상태에서 페이지를 나갔다가 다시 들어오면, 1280x720이 "새로운 기준"이 된다. scale이 1.0으로 리셋되고, 원본 1920x1080 기준으로 저장된 좌표와 맞지 않게 된다.

scale의 기준은 "현재 화면"이 아니라 "드로잉이 처음 그려졌을 때의 크기"여야 한다는 걸 깨달았다.

## 화면 크기 != 좌표

한 발짝 물러서서 문제를 정리해봤다. scale로 보정하면 당장은 맞지만, 페이지를 새로 열면 기준이 바뀌어서 깨진다. 그러면 근본적으로 왜 scale이 필요한 건가? 화면 크기가 바뀌는데 좌표는 안 바뀌기 때문이다. 결국 "화면에 보이는 크기"와 "좌표가 기록되는 크기"는 원래 별개의 개념인데, 이걸 하나로 취급한 게 원인이었다.

**표시 공간(Display Space)**은 캔버스가 화면에 보이는 크기다. 브라우저 창을 줄이면 표시 공간도 줄어든다. **좌표 공간(Coordinate Space)**은 드로잉이 기록되는 내부 좌표계다. 사용자가 `(960, 540)`에 점을 찍었을 때, 이 좌표가 속하는 공간이다.

SVG에서는 이 두 공간이 처음부터 분리되어 있다.

```html
<svg width="600" height="400" viewBox="0 0 1200 800"></svg>
```

`width`/`height`가 표시 공간을, `viewBox`가 좌표 공간을 정의한다. 두 값이 다르면 SVG가 알아서 스케일링한다. 구글 맵에서 특정 지역을 줌인하면 지도의 좌표는 그대로인데 화면에 보이는 영역만 달라지는 것과 같은 원리다.

Canvas API에는 `viewBox` 같은 개념이 없다. `canvas.width`를 바꾸면 화면에 보이는 크기와 내부 좌표계가 동시에 바뀐다. 표시 공간과 좌표 공간이 항상 1:1로 묶여 있는 것이다. 그래서 직접 분리해야 했다.

![excalidraw: 표시 공간과 좌표 공간 — 화면이 줄어들면 같은 좌표가 다른 위치에 렌더링된다](/images/posts/drawing-resize-coordinate/display-vs-coordinate-space.png)

## 기준점을 고정하기

드로잉 데이터를 서버에 저장할 때 이미 `width`, `height`를 함께 저장하고 있었다. 드로잉이 그려진 시점의 캔버스 크기, 즉 좌표 공간의 크기다.

읽기 모드에서 scale을 계산할 때 이 값을 기준으로 바꿨다. 수정 전에는 외부에서 받은 `providedScale`을 우선으로 사용했다.

```typescript
if (providedScale !== undefined) {
  calculatedScale = providedScale;
} else if (containerSize && drawingData?.data) { ... }
```

수정 후에는 저장된 원본 크기를 우선으로 바꿨다.

```typescript
if (containerSize && drawingData?.data) {
  const parsedData = JSON.parse(drawingData.data);
  if (parsedData.width && parsedData.height) {
    const scaleX = containerSize.width / parsedData.width;
    const scaleY = containerSize.height / parsedData.height;
    calculatedScale = Math.min(scaleX, scaleY);
  }
} else if (providedScale !== undefined) {
  calculatedScale = providedScale; // fallback
}
```

if 문의 순서를 바꾼 것뿐이지만, "현재 표시 공간 / 원본 좌표 공간"으로 scale을 계산한다는 점에서 의미가 크다. 표시 공간이 어떻게 바뀌든, 좌표 공간(원본 크기)은 드로잉 데이터에 고정되어 있으니까 항상 정확한 비율이 나온다.

`Math.min`을 쓰는 이유는 가로세로 비율을 유지하기 위해서다. 원본이 1920x1080인데 현재 화면이 1600x720이면, scaleX는 0.83이고 scaleY는 0.67이 된다. 만약 가로는 0.83, 세로는 0.67로 따로 적용하면 동그란 원이 옆으로 늘어난 타원이 된다. `Math.min(0.83, 0.67)` = 0.67을 가로세로 둘 다에 적용하면 비율이 유지된다. 대신 가로에 약간 여백이 생기는데, SVG의 `preserveAspectRatio="meet"`가 하는 일과 동일하다.

## 아직 저장 전인 경우

서버에 저장된 데이터에 원본 크기가 있으니까 읽기 모드는 해결됐다. 하지만 편집 모드에서는 아직 저장 전이라 원본 크기를 직접 관리해야 했다.

편집 중에는 화면 크기가 수시로 바뀔 수 있는데, 그때마다 원본 크기를 기억하고 scale을 다시 계산해야 한다. 이 로직을 `useDrawingAutoScale` 훅으로 분리했다. 처음 로드된 크기를 state에 고정하고, 이후 크기가 변하면 비율만 재계산한다.

```typescript
export function useDrawingAutoScale(currentSize: Size | null) {
  const [originalSize, setOriginalSize] = useState<Size | null>(null);
  const [scale, setScale] = useState(1);

  useEffect(() => {
    if (!currentSize) return;

    if (!originalSize) {
      setOriginalSize(currentSize); // 처음 크기를 좌표 공간으로 고정
      setScale(1);
      return;
    }

    setScale(calculateScale(currentSize, originalSize));
  }, [currentSize, originalSize]);

  return { pageSize: originalSize || currentSize, scale };
}
```

## 크기 변화 감지하기

"크기가 변하는 걸" 감지하는 것도 문제였다. 처음에는 `window.resize` 이벤트를 썼는데, 이건 브라우저 창 크기만 감지한다. 사이드바를 열고 닫으면 비디오 컨테이너 크기가 바뀌는데, 브라우저 창 크기 자체는 변하지 않기 때문에 `resize` 이벤트는 발생하지 않는다. `ResizeObserver`로 바꿔서 해결했다.

`ResizeObserver`는 특정 DOM 요소의 크기 변화를 감지하는 브라우저 API다. `window.resize`가 브라우저 창 전체만 보는 반면, `ResizeObserver`는 지정한 요소의 크기가 바뀔 때마다 콜백을 실행한다. CSS 레이아웃 변화, 사이드바 여닫기, 컨테이너 크기 변동 등을 모두 감지할 수 있다.

```typescript
useEffect(() => {
  const container = containerRef.current;
  if (!container) return;

  const resizeObserver = new ResizeObserver(() => {
    calculateVideoSize();
  });

  resizeObserver.observe(container);
  return () => resizeObserver.disconnect();
}, [calculateVideoSize]);
```

유튜브 임베드에서는 한 가지 더 복잡했다. 대부분의 유튜브 영상이 16:9 비율이기 때문에, 컨테이너가 넓적해도 iframe은 16:9에 맞춰 작아진다. 드로잉 영역을 iframe에 정확히 겹치려면 컨테이너 크기에서 실제 iframe 크기를 역산해야 했다. 예를 들어 컨테이너가 1200x500이면, 가로 기준 1200 / 16 = 75, 세로 기준 500 / 9 = 55.5가 되고, 작은 쪽인 55.5를 기준으로 16 * 55.5 = 888, 9 * 55.5 = 500이 실제 iframe 크기가 된다.

```typescript
const calculateIframeSize = useCallback(() => {
  const container = containerRef.current;
  if (!container) return;

  const rect = container.getBoundingClientRect();
  const xRatio = rect.width / 16;
  const yRatio = rect.height / 9;
  const maxRatio = Math.min(xRatio, yRatio);

  setIframeSize({
    width: Math.floor(16 * maxRatio),
    height: Math.floor(9 * maxRatio),
  });
}, []);
```

## 텍스트

도형과 펜 스트로크는 Konva Layer에 `scaleX`, `scaleY`를 적용하면 일괄 처리된다. 좌표 공간 분리가 잘 되는 것이다. 그런데 텍스트에서 같은 문제가 다시 터졌다.

텍스트를 저장할 때 width/height를 기록하는 코드에서 `stage.width()`를 쓰고 있었다. 텍스트의 크기를 Stage에서 가져오는 게 자연스러워 보였기 때문이다. 하지만 `stage.width()`는 표시 공간의 크기를 반환한다.

```typescript
// As-is
const width = stage.width();
const height = stage.height();
```

좌표는 좌표 공간(원본) 기준으로 저장하고 있었는데, width/height만 표시 공간의 값을 쓰고 있었다. 두 공간이 다시 섞인 것이다.

그래서 아래와 같이 좌표 공간(원본 크기) 기준으로 저장하도록 수정했다.

```typescript
// To-be
const width = originalWidth ?? stage.width();
const height = originalHeight ?? stage.height();
```

`originalWidth`는 `useDrawingAutoScale` 훅에서 처음 로드 시 고정해둔 원본 크기다. `stage.width()`가 아닌 이 값을 쓰면 화면 크기가 바뀌어도 항상 좌표 공간 기준으로 저장된다.

텍스트 입력 시 보이는 크기도 문제였다.

```tsx
// As-is
<input style={{ fontSize: "16px", position: "absolute", left: x, top: y }} value={text} />
```

CSS input에 `fontSize: 16px`를 넣으면 표시 공간 기준의 16px가 렌더링된다. 하지만 Konva Text로 확정할 때는 좌표 공간 기준으로 그려지니까 크기가 달라졌다. CSS와 Canvas는 서로 다른 좌표 체계를 쓰고 있었던 것이다.

결국 CSS input 방식을 포기하고, hidden input으로 키보드 입력만 받고 화면에 보이는 건 Konva Text가 담당하게 바꿨다.

```tsx
// To-be
<input style={{ opacity: 0 }} value={text} />
<Text x={x} y={y} text={text} fontSize={16} />
```

하나의 렌더링 시스템 안에서 통일해 크기 불일치가 사라졌다.

## 정리

- 화면 좌표를 그대로 저장하면 화면 크기가 바뀔 때 드로잉이 어긋난다.
- 외부에서 scale을 전달하는 방식은 기준이 바뀌면 같이 깨진다.
- 표시 공간(화면에 보이는 크기)과 좌표 공간(드로잉이 기록되는 좌표계)을 분리해야 한다.
- scale 기준은 "현재 화면"이 아니라 "드로잉이 처음 그려졌을 때의 크기"로 고정한다.
- SVG는 `viewBox`로 이 분리를 언어 차원에서 지원하지만, Canvas는 직접 구현해야 한다.
- 하나의 드로잉 안에서 두 공간을 섞으면 같은 문제가 반복된다. (텍스트의 `stage.width()`, CSS와 Canvas의 좌표 체계 차이)

## 참고

- [MDN — SVG viewBox](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/viewBox)
- [MDN — SVG preserveAspectRatio](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/preserveAspectRatio)
- [MDN — ResizeObserver](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver)
- [react-konva](https://konvajs.org/docs/react/)

좌표계와 스케일링 삽질기

화면 리사이징으로 인한 드로잉 어긋남 해결하기


## 개요

비디오 피드백 협업 도구를 만들면서 영상 위에 드로잉 기능이 필요했다. 펜, 사각형, 원, 화살표, 텍스트 5가지 도구를 지원해야 했고, Undo/Redo와 개별 스트로크 관리도 필요했다. Canvas API로 충분할 줄 알았는데, 막상 구현에 들어가니 Canvas만으로는 해결할 수 없는 근본적인 한계가 있었다.

## 비트맵과 씬 그래프

본격적으로 들어가기 전에, 이 글에서 계속 등장하는 두 개념을 먼저 짚고 가자.

![excalidraw: 비트맵과 벡터 비교](/images/posts/why-konva-over-canvas/bitmap-concept.png)

비트맵(Bitmap)은 픽셀의 격자다. 가로 1920개, 세로 1080개의 점이 모여 하나의 이미지를 구성한다. 각 점은 색상 값만 가지고 있을 뿐, "이 점이 사각형의 일부인지 원의 일부인지"는 알지 못한다. 사진 파일(PNG, JPG)이 대표적인 비트맵이다. Canvas API가 바로 이 방식으로 동작한다. 화면에 무언가를 그리면 결과는 픽셀 덩어리로 남고, 그 픽셀이 어떤 도형에서 왔는지는 기록하지 않는다.

씬 그래프(Scene Graph)는 화면에 표시할 객체들을 트리 구조로 관리하는 모델이다. "빨간 원이 좌표 (100, 150)에 반지름 40으로 존재한다"는 정보를 JavaScript 객체로 들고 있다. 렌더링할 때는 이 객체들을 순회하면서 비트맵에 그리지만, 객체 자체는 메모리에 남아있다. 그래서 "세 번째 도형을 삭제하라"는 명령이 가능하다. Konva가 Canvas 위에 씬 그래프를 얹는 방식이다.

핵심은 Konva가 비트맵을 대체하는 게 아니라는 점이다. 내부적으로는 똑같이 Canvas API로 픽셀을 찍는다. 다만 그 위에 객체 모델을 얹어서, 비트맵만으로는 할 수 없는 개별 도형 관리와 이벤트 처리를 가능하게 한다.

## Canvas API의 근본적인 한계

Canvas는 비트맵 기반이다. `context.stroke()`를 호출하는 순간 픽셀이 캔버스에 새겨지고, 그 이후로는 어떤 도형이었는지에 대한 정보가 사라진다.

실제로 구현하면서 부딪힌 문제를 보자.

### 도형 하나를 지우려면

SVG라면 해당 DOM 노드를 `removeChild()`하면 끝이다. 하지만 Canvas에는 지울 "노드"가 없다. 할 수 있는 건 전체 캔버스를 `clearRect()`로 지운 다음, 나머지 도형을 처음부터 다시 그리는 것뿐이다.

```typescript
// Canvas API로 Undo를 구현하려면,
ctx.clearRect(0, 0, canvas.width, canvas.height);

// 마지막 스트로크를 제외한 나머지를 전부 다시 그려야 한다.
remainingStrokes.forEach((stroke) => drawStroke(ctx, stroke));
```

스트로크가 100개일 때 하나를 지우려고 99개를 다시 그린다. 스트로크가 늘어날수록 Undo 한 번의 비용이 선형으로 증가한다. 거기다 Redo, 중간 스트로크 삭제, 특정 도형만 색상 변경 같은 기능까지 고려하면, 매번 전체를 다시 그리는 방식은 금방 한계에 부딪힌다.

### 특정 도형을 선택하려면

드로잉 도구에서는 특정 스트로크를 선택하거나, 마우스 커서가 도형 위에 있을 때 하이라이트를 보여줘야 할 수 있다. SVG라면 각 요소에 `addEventListener`를 달면 된다. 하지만 Canvas는 하나의 `<canvas>` 요소가 전부다. 이벤트는 캔버스 전체에 걸리고, 클릭 좌표 `(300, 200)`을 받았을 때 그 위치에 어떤 도형이 있는지 알아내는 건 전적으로 개발자 몫이다. 이걸 히트 테스팅(Hit Testing)이라 한다.

직접 구현하려면 도형별로 수식이 다르다.

![excalidraw: 히트 테스팅 수식](/images/posts/why-konva-over-canvas/hit-testing-math.png)

사각형과 원은 그나마 간단하다. 하지만 자유곡선(펜 도구)은? 사용자가 마우스를 움직이며 그린 수백 개의 점으로 이루어진 곡선 위에 마우스가 있는지 판별하려면, 모든 연속된 두 점 사이의 선분과 마우스 좌표 간 거리를 계산해야 한다. 점의 개수를 n이라 하면 `O(n)`이고, 스트로크가 여러 개면 모든 스트로크를 순회해야 한다.

## Konva의 히트 캔버스

Konva는 이 문제를 히트 캔버스(Hit Canvas)로 해결한다. 히트 캔버스란 화면에 보이지 않는 별도의 캔버스를 두고, 그 위에 각 도형을 고유한 색상으로 칠해서 클릭 지점의 픽셀 색상만으로 어떤 도형인지 식별하는 기법이다. 원리는 단순하다.

쉽게 비유하자면, 같은 그림을 두 장 그리는 것과 비슷하다. 한 장은 사용자에게 보여주는 예쁜 그림이고, 다른 한 장은 각 도형에 번호표를 붙인 지도다. 사용자가 그림의 어느 지점을 클릭하면, 뒤에 숨겨둔 지도에서 같은 위치를 찾아 "여기는 3번 도형 영역이군" 하고 바로 알아내는 원리다.

구체적으로는 이렇다. 화면에 보이는 캔버스 뒤에 숨겨진 캔버스를 하나 더 만든다. 이 히트 캔버스에서는 각 도형을 고유한 색상으로 칠한다. 첫 번째 도형은 `#000001`, 두 번째는 `#000002`... 색상 자체가 ID 역할을 하는 셈이다. 사용자가 클릭하면,

1. 클릭 좌표 `(x, y)`에서 히트 캔버스의 픽셀 색상을 `getImageData(x, y, 1, 1)`로 읽는다.
2. 색상 값을 도형 ID로 변환한다.
3. 해당 도형 객체를 반환한다.

![excalidraw: 히트 캔버스 원리](/images/posts/why-konva-over-canvas/hit-canvas.png)

이 방식은 도형의 복잡도와 무관하게 항상 `O(1)`이다. 자유곡선이든 복잡한 다각형이든, 결국 픽셀 하나만 읽으면 된다. 도형이 1000개여도 성능은 동일하다.

## Konva의 씬 그래프 구조

Konva가 단순히 히트 테스팅만 해결하는 건 아니다. Canvas 위에 씬 그래프를 만든다. Stage → Layer → Shape 계층 구조로, 각 도형이 JavaScript 객체로 존재한다.

```text
Stage (최상위 컨테이너)
├── Layer 1 (도형 레이어)
│   ├── Line (펜 스트로크)
│   ├── Rect (사각형)
│   └── Circle (원)
└── Layer 2 (텍스트 레이어)
    └── Text (텍스트)
```

내부적으로는 결국 Canvas API의 `beginPath()`, `stroke()`, `fill()` 등을 호출한다. 하지만 그 위에 객체 모델을 얹었기 때문에, "세 번째 스트로크를 삭제하라"는 명령이 가능해진다. Canvas API만으로는 불가능했던 일이다.

## 그러면 SVG를 쓰면 되지 않나?

처음에는 SVG도 고려했다. DOM 기반이라 이벤트 처리도 쉽고, 개별 요소 삭제도 가능하다. 하지만 SVG를 선택하지 않은 이유가 있다.

SVG는 각 도형이 곧 DOM 노드다. `<rect>`, `<circle>`, `<polyline>` 하나하나가 HTML의 `<div>`와 같은 레벨의 DOM 요소로 존재한다. 도형 10개면 DOM 노드 10개, 100개면 100개다. 자유곡선 하나에 점이 200개면 그 `<polyline>`의 `points` 속성에 400개의 좌표값이 들어간다. 스트로크 50개면 DOM에 50개의 SVG 요소가 존재하고, 하나를 수정할 때마다 브라우저는 전체 레이아웃을 다시 계산한다.

```mermaid
sequenceDiagram
    participant U as 사용자
    participant B as 브라우저
    participant D as SVG DOM
    participant L as 레이아웃 엔진

    U->>D: 세 번째 도형 색상 변경
    D->>B: DOM 변경 감지
    B->>L: 레이아웃 재계산 요청
    L->>L: 50개 SVG 요소 전체 재계산
    L->>B: 리페인트
    B->>U: 화면 갱신
    Note over L: 도형이 늘어날수록<br/>재계산 비용 증가
```

Canvas(와 Konva)는 DOM 노드 하나(`<canvas>`)만 사용한다. 도형이 아무리 많아도 DOM 구조는 변하지 않는다. 브라우저의 레이아웃 엔진에 부하를 주지 않는다.

세 가지 선택지의 트레이드오프를 정리하면 다음과 같다.

|                     | SVG          | Canvas API   | Konva (Canvas 기반) |
| ------------------- | ------------ | ------------ | ------------------- |
| DOM 노드 수         | 도형 수만큼  | 1개          | 1개                 |
| 이벤트 처리         | 네이티브     | 직접 구현    | 히트 캔버스         |
| 개별 도형 관리      | DOM 조작     | 불가         | 씬 그래프           |
| 성능 (도형 많을 때) | 느려짐       | 빠름         | 빠름                |
| 번들 크기           | 0 (네이티브) | 0 (네이티브) | ~150KB              |

만들고 있던 드로잉 도구는 자유곡선이 핵심이고, 사용자가 많이 그릴수록 도형이 늘어난다. SVG는 이 상황에서 성능 문제가 생길 수밖에 없었다. Canvas의 성능은 유지하면서 객체 관리와 이벤트 처리가 가능한 Konva를 선택했다.

## 편집 모드와 읽기 모드의 분리

프로젝트에서 한 가지 더 결정해야 할 것이 있었다. 드로잉을 "편집"하는 화면과 "읽기만" 하는 화면이 따로 존재한다는 점이다. 두 화면의 요구사항이 다르기 때문에 같은 렌더링 방식을 쓸 이유가 없었다.

편집 모드에서는 Konva가 필요하다. 도형을 추가/삭제하고, Undo/Redo를 처리하고, 마우스 이벤트에 반응해야 한다. 씬 그래프 없이는 이런 상호작용이 불가능하다.

읽기 모드에서는 저장된 스트로크 데이터를 화면에 표시만 하면 된다. 상호작용이 없다. 이 경우 Konva의 씬 그래프를 메모리에 올릴 이유가 없다. Canvas API로 한번 쭉 그리면 끝이다.

```typescript
// 읽기 모드: Canvas API 직접 사용
const renderStroke = (ctx: CanvasRenderingContext2D, stroke: StrokeData) => {
  ctx.save();
  ctx.scale(scale, scale);
  ctx.strokeStyle = stroke.color;
  ctx.lineWidth = stroke.strokeWidth;

  if (stroke.type === "pen") {
    ctx.beginPath();
    for (let i = 0; i < stroke.points.length; i += 2) {
      if (i === 0) ctx.moveTo(stroke.points[i], stroke.points[i + 1]);
      else ctx.lineTo(stroke.points[i], stroke.points[i + 1]);
    }
    ctx.stroke();
  }
  // rect, circle, arrow, text도 각각 처리
  ctx.restore();
};
```

이 분리가 특히 중요했던 건 읽기 모드의 드로잉이 댓글마다 하나씩 붙기 때문이다. 댓글이 20개이고 각각 드로잉이 있으면 20개의 캔버스 인스턴스가 생긴다. 전부 Konva로 렌더링하면 씬 그래프 20개가 메모리에 올라간다. Canvas API로 직접 그리면 그릴 때만 컨텍스트를 사용하고, 결과는 비트맵으로 남아서 메모리 부담이 훨씬 적다.

## 정리

Canvas API만으로도 드로잉 도구를 만들 수 있다. 다만 도형 관리, 이벤트 처리, Undo/Redo를 전부 직접 구현해야 한다. Konva는 그 수고를 덜어주되, 읽기 전용처럼 상호작용이 필요 없는 곳에서는 오히려 불필요한 무게가 된다. 그래서 편집 화면에는 Konva를, 읽기 화면에는 Canvas API를 각각 적용했다.


비트맵의 한계와 씬 그래프 도입기

Canvas 위에 Konva 한 겹 얹기


## 개요

Vue로 만든 v1에서는 네이티브 Canvas API로 직접 그리고, `canvas.toDataURL()`로 캔버스를 캡처해서 서버에 저장하는 방식이었다. `toDataURL()`은 캔버스에 현재 그려진 픽셀을 그 순간 PNG로 변환해서 `data:image/png;base64,...` 형태의 문자열로 돌려주는 메서드다. 서버에서 이미지를 가져오는 게 아니라 캔버스의 스크린샷을 찍는 것이다. React로 새로 만드는 v2에서는 스트로크 데이터를 JSON으로 저장하는 방식으로 바꾸려 했는데, 기존에 PNG로 저장된 드로잉도 보여줘야 했기 때문에 두 포맷을 모두 지원해야 했다.

v2에서는 react-konva를 사용했다. Konva는 Canvas를 다루는 바닐라 JS 라이브러리다. React 없이 Konva를 쓰면 명령적으로 하나하나 지시해야 한다.

```typescript
// Konva만 사용 -> 명령적
const line = new Konva.Line({
  points: [0, 0, 100, 100],
  stroke: "red",
});
layer.add(line);
layer.draw();
```

react-konva는 이걸 React 컴포넌트로 감싸서, 선언적으로 쓸 수 있게 해준다.

```tsx
// react-konva 사용 -> 선언적
<Line points={[0, 0, 100, 100]} stroke="red" />
```

react-konva가 내부적으로 `new Konva.Line()` 생성, props 변경 시 `line.points()` 호출, 컴포넌트 제거 시 `line.destroy()` 같은 명령적 작업을 대신 처리한다. 개발자는 원하는 결과만 선언하면 된다.

다만 `stageRef.current.toDataURL()`처럼 ref로 Konva에 직접 접근하면, react-konva의 선언적 흐름을 거치지 않고 Canvas를 즉시 읽는 명령적 호출이 된다. 그리기/Undo/Redo가 일어날 때마다 현재 드로잉 데이터를 상위 컴포넌트에 전달하는 구조였고, v1 하위 호환을 위해 `stage.toDataURL()`로 PNG 캡처하는 경로도 남아 있었다.

여기서 이상한 버그를 만났다. Undo를 누르면 캔버스에서는 스트로크가 사라지는데, 캡처된 이미지에는 여전히 남아 있었다. 한참을 헤매다가 `setTimeout(0)` 한 줄로 해결했는데, 왜 이게 되는지 이해하기까지가 더 오래 걸렸다.

## 선언적 vs 명령적

이 버그의 근본 원인은 React와 Canvas가 서로 다른 모델로 동작한다는 데 있다.

선언적(Declarative)이란 "무엇을 원하는지"만 말하고 과정은 맡기는 것이다. React가 이 방식이다. `setStrokes([A, B])`를 호출하면 "스트로크가 A, B인 상태를 원해"라고 선언할 뿐, 실제로 DOM에서 어떤 노드를 지우고 어떤 노드를 추가할지는 React가 결정한다. 호출 시점에는 아무 일도 일어나지 않는다.

명령적(Imperative)이란 "어떻게 할지"를 하나하나 지시하는 것이다. Canvas가 이 방식이다. `ctx.clearRect()`로 지우고, `ctx.beginPath()`로 선을 시작하고, `ctx.stroke()`로 그린다. `stage.toDataURL()`을 호출하면 그 순간 캔버스에 그려진 픽셀을 바로 돌려준다. 호출한 시점의 상태가 곧 결과다.

```mermaid
gantt
    dateFormat X
    axisFormat %s
    title 호출 → 결과

    section React
    호출           :a1, 0, 1
    스케줄링       :a2, 1, 3
    화면 반영      :crit, a3, 3, 4

    section Canvas
    호출 → 즉시 반환 :active, b1, 0, 1
```

문제는 이 두 모델을 한 함수 안에서 섞어 쓸 때 생긴다. `setStrokes`(선언적)와 `toDataURL()`(명령적)을 순서대로 호출하면, 선언적 세계에서는 아직 "예약"만 된 상태인데 명령적 세계에서는 "지금 당장" 읽어버린다. 둘 다 선언적이었으면 React가 배치 처리를 알아서 해주고, 둘 다 명령적이었으면 실행 순서가 보장된다. 두 모델이 섞이는 순간 타이밍 간극이 생기고, 따라서 이 타이밍에 버그가 터지게 된 것이다.

## 상태 변경 != 화면 반영

이걸 더 구체적으로 이해하려면 React의 렌더링 파이프라인을 알아야 한다. React 공식 문서에서는 이걸 레스토랑에 비유한다. React는 웨이터, 컴포넌트는 요리사, DOM은 테이블이다.

![excalidraw: React Render 단계 — Component Kitchen에서 Card를 받아오는 장면](/images/posts/settimeout-zero-react-canvas/react-render.png)

`setState`를 호출하는 건 웨이터에게 주문을 넣는 것이다. 주문이 들어갔다고 요리가 바로 나오지는 않는다. React는 주문을 받아서 주방(컴포넌트)에 전달하고, 요리(렌더링 결과)를 받아서 테이블(DOM)에 서빙한다. 이 과정이 세 단계로 나뉜다.

1. **Trigger** — 상태가 변경되어 렌더링이 예약된다.
2. **Render** — 컴포넌트 함수를 호출해서 새로운 UI를 계산한다. 이 단계에서는 DOM을 건드리지 않는다.
3. **Commit** — 계산된 변경 사항을 실제 DOM에 반영한다.

![excalidraw: React Re-render — 상태 변경으로 새로운 Card를 요청하는 장면](/images/posts/settimeout-zero-react-canvas/react-renderer.png)

Commit 이후에도 끝이 아니다. Konva를 쓰는 경우, React가 Commit에서 하는 일은 Konva 컴포넌트(`<Line>`, `<Rect>` 등)에 새 props를 전달하는 것이다. 그러면 Konva가 내부적으로 캔버스에 다시 그린다. 그 다음에야 브라우저가 **Paint**를 수행해서 화면에 픽셀을 찍는다.

![excalidraw: Browser Paint — 브라우저가 최종 결과를 화면에 그리는 장면](/images/posts/settimeout-zero-react-canvas/browser-paint.png)

> 이미지 출처: [React 공식 문서 — Render and Commit](https://react.dev/learn/render-and-commit)

전체 흐름을 정리하면 이렇다.

```mermaid
sequenceDiagram
    participant S as setState
    participant R as React
    participant K as Konva
    participant B as Browser

    S->>R: Trigger — 렌더링 예약
    R->>R: Render — 새 UI 계산
    R->>K: Commit — 새 props 전달
    K->>K: 캔버스 다시 그리기
    K->>B: Paint — 화면에 픽셀 표시

    Note over S,K: toDataURL()은 여기 이후에 호출해야 정확함
```

`toDataURL()`로 정확한 결과를 얻으려면 최소한 Konva가 캔버스를 다시 그린 이후에 호출해야 한다. `setState`를 호출한 시점(Trigger)과 Konva가 캔버스를 업데이트하는 시점 사이에 간격이 있고, 이 간격 안에서 Canvas를 읽으면 이전 상태가 읽힌다.

## 화면에서는 사라졌는데 캡처에는 남아 있다

드로잉 에디터에서 스트로크를 그리거나 Undo/Redo를 할 때마다 현재 캔버스를 이미지로 캡처해서 상위 컴포넌트에 전달해야 했다. Konva의 `stage.toDataURL()`을 호출하면 캔버스를 PNG data URL로 변환할 수 있다.

```typescript
const finishStroke = useCallback(() => {
  addToHistory(strokes);

  if (stageRef.current && onDrawingChange) {
    const dataURL = stageRef.current.toDataURL();
    onDrawingChange(dataURL);
  }
}, [strokes, addToHistory, onDrawingChange]);
```

Undo를 누르면 화면에서는 스트로크가 사라지는데, `onDrawingChange`로 전달되는 이미지에는 아직 남아 있었다. 처음에는 히스토리 로직이 잘못된 줄 알고 한참 디버깅했다.

## 로그 찍기

히스토리를 아무리 살펴봐도 문제가 없었다. 혹시나 해서 `toDataURL()` 직전에 상태를 찍어봤다.

```typescript
console.log("현재 strokes:", strokes.length); // Undo 후: 2개
const dataURL = stageRef.current.toDataURL();
// dataURL 이미지에는 3개짜리 그림이 찍혀 있음
```

`strokes`는 분명 2개인데, 캡처된 이미지에는 3개가 그려져 있었다. 상태(state)와 실제 캔버스에 그려진 그림이 다른 것이다.

`setStrokes`로 상태를 바꿨지만, 그건 Trigger일 뿐이었다. React가 Render → Commit을 거쳐 Konva에 새 props를 전달하고, Konva가 캔버스에 다시 그리는 것은 그 이후에 일어난다. `toDataURL()`은 Trigger 직후에 호출되고 있었으니, 캔버스에는 아직 이전 상태가 그려져 있는 것이다.

```mermaid
sequenceDiagram
    participant H as 이벤트 핸들러
    participant R as React
    participant K as Konva Canvas
    participant T as 태스크 큐

    Note over H,T: 문제 — setTimeout 없이 직접 호출

    H->>R: setStrokes(2개) — 상태 변경 예약
    H->>K: toDataURL() — 아직 3개짜리 캔버스를 캡처
    Note over H: 함수 종료

    R->>R: Render — 새 UI 계산
    R->>K: Commit — 2개짜리 strokes 전달
    K->>K: 캔버스 업데이트 — 비로소 2개만 그려짐
```

## 일단 다음 틱으로

원인은 알겠는데, 어떻게 고칠지가 막막했다. React의 Commit이 끝난 후에 `toDataURL()`을 호출해야 하는데, "Commit이 끝났다"를 직접 알 수 있는 방법이 마땅치 않았다.

그러다 "일단 다음 이벤트 루프 틱으로 밀어보자"는 생각에 `setTimeout(0)`을 넣어봤다.

```typescript
const finishStroke = useCallback(() => {
  addToHistory(strokes);

  setTimeout(() => {
    if (stageRef.current && onDrawingChange) {
      const dataURL = stageRef.current.toDataURL();
      onDrawingChange(dataURL);
    }
  }, 0);
}, [strokes, addToHistory, onDrawingChange]);
```

이렇게 바꾸니 Undo를 눌렀을 때 캡처된 이미지도 정확하게 나왔다. 되긴 됐는데, 왜 되는 건지 정확하게 알지 못해 찜찜했다.

## 이벤트 루프

`setTimeout(fn, 0)`은 "0밀리초 후에 실행"이 아니다. 브라우저 이벤트 루프는 세 단계로 돌아간다.

1. **콜 스택** — 현재 실행 중인 코드를 끝까지 처리한다.
2. **마이크로태스크 큐** — `Promise.then`, React 배치 처리 등이 실행된다.
3. **태스크 큐(macrotask)** — `setTimeout` 콜백 등이 실행된다.

`setTimeout(fn, 0)`의 콜백은 3번 태스크 큐에 들어간다. 0ms라고 해도 1번(현재 코드)과 2번(마이크로태스크)이 전부 끝난 후에야 실행된다. React의 배치 처리는 2번에서 일어나기 때문에, 3번에 있는 `setTimeout` 콜백이 실행되는 시점에는 React가 이미 Render → Commit을 마친 후다.

```mermaid
sequenceDiagram
    participant H as 이벤트 핸들러
    participant R as React
    participant K as Konva Canvas
    participant T as 태스크 큐

    Note over H,T: 해결 — setTimeout(0)으로 다음 틱에 호출

    H->>R: setStrokes(2개) — 상태 변경 예약
    H->>T: setTimeout(callback, 0) — 콜백 등록
    Note over H: 함수 종료, 콜 스택 비워짐

    R->>R: Render — 새 UI 계산
    R->>K: Commit — 새 props 전달
    K->>K: 캔버스 업데이트 (2개만 그려짐)

    Note over T: 배치 처리 완료 후 실행
    T->>K: toDataURL() — 최신 캔버스 캡처
```

핵심은 React의 배치 처리가 콜 스택이 비워진 직후에 마이크로태스크로 실행된다는 것이다. `setTimeout(0)`의 콜백은 태스크 큐(macrotask)에 있기 때문에, 마이크로태스크인 React 배치 처리가 끝난 후에야 실행된다. 그래서 `toDataURL()`이 호출되는 시점에는 캔버스가 이미 최신 상태다.

## 같은 패턴이 여기저기에

`finishStroke`에서 해결하고 나니, 같은 문제가 `undo`, `redo`, `addStroke`에도 전부 있다는 걸 발견했다. "상태를 바꾸고 캔버스를 캡처하는" 모든 곳에서 동일한 타이밍 이슈가 있었다.

```typescript
const undo = useCallback(() => {
  if (historyIndex > 0) {
    const newIndex = historyIndex - 1;
    setStrokes(history[newIndex].strokes);
    setHistoryIndex(newIndex);

    setTimeout(() => {
      if (stageRef.current && onDrawingChange) {
        const dataURL = stageRef.current.toDataURL();
        onDrawingChange(dataURL);
      }
    }, 0);
  }
}, [historyIndex, history, onDrawingChange]);
```

결국 모든 캡처 코드에 `setTimeout(0)`을 넣었다.

## 다른 방법

### useEffect

"상태 변경 후에 뭔가를 실행하고 싶다"면 보통 `useEffect`를 떠올린다.

```typescript
useEffect(() => {
  if (stageRef.current && onDrawingChange) {
    const dataURL = stageRef.current.toDataURL();
    onDrawingChange(dataURL);
  }
}, [strokes]);
```

`strokes`가 바뀔 때마다 캡처하는 방식이다. 동작은 하지만 두 가지 문제가 있었다.

첫째, `useEffect`의 실행 시점이 애매하다. `useEffect`는 Commit 이후 브라우저가 Paint를 마친 다음에 비동기적으로 실행된다. React에서는 이 단계를 Passive Effects라고 부른다. 화면 업데이트를 차단하지 않기 위해 Paint 이후로 미루는 것이다. Mark Erikson의 설명에 따르면 "React가 짧은 timeout을 설정하고, 그것이 만료되면 모든 useEffect를 실행한다." 이 시점에 Konva가 실제로 캔버스에 픽셀을 찍었는지는 보장되지 않는다.

둘째, `strokes`는 마우스 드래그 중에도 `updateLastStroke`로 계속 바뀐다. 그리는 중간에 매 프레임마다 `toDataURL()`이 호출되면 불필요한 캡처가 반복된다. 성능을 직접 측정하지는 않았지만, 확정되지 않은 스트로크를 매번 캡처할 이유는 없었다. `setTimeout(0)`은 `finishStroke` 안에서만 호출되기 때문에, 스트로크가 확정된 시점에서만 캡처가 일어난다.

### flushSync

나중에 찾아보니 `react-dom`에 `flushSync`라는 API가 있었다. 상태 업데이트를 즉시 동기적으로 Commit까지 수행한다. "배치하지 말고 지금 당장 DOM에 반영하라"는 명령이다.

```typescript
import { flushSync } from "react-dom";

flushSync(() => {
  setStrokes(newStrokes);
});
// 이 시점에서 DOM은 이미 업데이트됨
const dataURL = stageRef.current.toDataURL();
```

당시에는 이런 API가 있는지 몰랐다. 나중에 찾아보니 React 공식 문서에서도 "마지막 수단(last resort)"으로 소개하고 있었다. 배치 최적화를 무력화하기 때문에 성능에 영향을 줄 수 있고, 드로잉처럼 빈번한 상태 업데이트가 일어나는 곳에서는 부담이 된다고 생각했다.

### requestAnimationFrame

`requestAnimationFrame`은 브라우저가 다음 화면을 그리기 직전에 콜백을 실행한다. 이후 창 크기 계산 같은 곳에서는 `requestAnimationFrame`으로 바꿨다.

```typescript
requestAnimationFrame(() => {
  calculateVideoSize();
});
```

하지만 `toDataURL()` 캡처 용도에서는 `setTimeout(0)`을 유지했다. `requestAnimationFrame`은 다음 Paint 직전에 실행되는데, 이 시점에 React의 Commit은 완료되었지만 react-konva가 내부적으로 `batchDraw`를 통해 캔버스 드로잉을 비동기 처리하는 경우, 우리가 등록한 콜백이 Konva의 실제 캔버스 드로잉보다 먼저 실행될 수 있기 때문이다.

## React 18에서 달라진 점

한 가지 주의할 점이 있다. React 18에서는 Automatic Batching이 도입됐다. React 17에서는 이벤트 핸들러 내부에서만 배치가 적용됐지만, React 18에서는 `setTimeout`, `Promise.then` 안의 `setState`도 배치된다.

이 프로젝트는 React 18을 사용하고 있었고, `setTimeout(0)` 안에서 `setState`를 호출하는 경우는 없었기 때문에 문제가 되지 않았다. 하지만 만약 `setTimeout(0)` 콜백 안에서 상태를 업데이트하는 패턴을 쓴다면 React 18에서 의도와 다르게 배치될 수 있다.

## 정리

React는 선언적이다. "이 상태일 때 이렇게 보여라"고 선언하면 React가 알아서 그린다. Canvas는 명령적이다. "지금 캔버스에 뭐가 그려져 있지?"를 물으면 그 즉시의 상태를 돌려준다.

이 두 세계를 함께 쓰면 반드시 타이밍 문제를 만난다. `setState`는 주문이고, 캔버스에 그려지는 건 서빙이다. 주문 직후에 테이블을 보면 아직 이전 요리가 놓여 있다.

`setTimeout(0)`은 우아한 해결책이 아니다. 하지만 "React가 서빙을 끝낼 때까지 한 틱 기다린다"는 의도를 명확하게 표현한다. 처음에는 왜 되는지도 모르고 넣었지만, 렌더링 파이프라인을 따져보고 나서야 이게 적절한 해결이라는 확신이 생겼다.

돌아보면 이 버그를 찾는 데 오래 걸린 이유가 하나 더 있다. `DrawingCanvas` 컴포넌트 하나에 히스토리 관리, 이미지 캡처, 스케일 계산이 전부 들어 있었다. 상태를 바꾸는 코드와 캔버스를 읽는 코드가 같은 함수 안에 붙어 있으니, 둘 사이의 타이밍 간극을 의심하기가 어려웠다. 역할이 분리되어 있었다면 "캡처는 상태 반영 이후에 해야 한다"는 걸 구조적으로 더 빨리 알아챘을 것이다.


Konva.js

2025

화면 리사이징으로 인한 드로잉 어긋남 해결하기

Canvas 위에 Konva 한 겹 얹기

setTimeout(0)으로 React와 Canvas 타이밍 맞추기