SVG viewBox 로 확대·축소 붙이기 — 좌표 40군데를 안 고친 이유
1,290줄 화면 파일에 확대를 넣는데 좌표 계산은 한 줄도 손대지 않았다. 대신 반대 방향 14곳을 함수 둘로 모았다.
도면 편집기에 확대·축소를 붙이려고 코드를 열면, 보통 「칸 크기」를 직접 곱해 쓰는 자리가 한가득 나온다.
x = 칸번호 * 칸가로
y = 줄번호 * 칸세로
2026-08-26, 내 경우도 그랬다. 1,290줄짜리 화면 파일이고, 이런 줄이 도형마다·글자마다·벽마다·미리보기마다 흩어져 마흔 군데가 넘었다. 확대를 넣는다는 건 보통 이걸 전부 * 배율 로 바꾸는 일이라고 생각한다. 그래서 처음에 잡은 시간이 90분이었다. "안 해봤다, 90분 잡고 막히면 보고"라고 적어뒀다.
마흔 군데가 위험한 건 개수 때문이 아니다
먼저 세어 본 건 「몇 시간 걸리나」가 아니라 「빠뜨리면 어떻게 되나」였다.
하나만 빠뜨리면 그 도형만 엉뚱한 자리에 그려진다. 문제는 그게 화면에서 거의 안 보인다는 점이다. 100%에서는 배율이 1이라 틀린 줄도 맞게 보인다. 확대해야만 어긋나는데, 확대한 화면에서 「이 글자가 3픽셀 밀렸다」를 알아보는 사람은 없다.
그때 SVG 의 viewBox 가 떠올랐다. 그림의 내부 좌표계와 화면에 그려지는 크기를 따로 정하는 값이다. 내부 좌표를 그대로 두고 그려지는 크기만 두 배로 하면 브라우저가 알아서 두 배로 그린다.
- 안쪽 좌표를 전부 고친다 — 마흔 군데. 하나 빠지면 조용히 어긋난다
- 바깥 크기만 곱한다 — 한 줄. 안쪽은 아무것도 안 건드린다
실제로 고친 줄
둘째를 골랐다. 고친 건 이것뿐이다.
width = 원래폭 * 배율
height = 원래높이 * 배율
viewBox = 원래 그대로
대신 반대 방향은 반드시 고쳐야 한다. 마우스가 화면 어디를 눌렀는지를 내부 좌표로 되돌리는 계산은 배율로 나눠야 한다. 그 자리를 세어 보니 열네 군데였다. 마흔이 아니라 열넷이고, 게다가 전부 같은 모양(화면좌표 - 그림의 왼쪽위)이라 함수 두 개로 모을 수 있었다.
화면점 → 내부좌표 (한 곳)
움직인 거리 → 내부 길이 (한 곳)
새로 쓰는 코드도 반드시 이 둘을 거치게 주석을 박아뒀다. 다음에 직접 빼기를 하면 그 자리만 다시 어긋난다.
곁가지로 하나 더 필요했다. 손잡이는 배율을 거슬러 그려야 한다. 모서리를 잡는 동그라미가 반지름 5픽셀인데 32%로 줄이면 1.6픽셀이 된다. 잡을 수가 없다. 그래서 손잡이만 1 / 배율 을 곱해 화면상 크기를 고정했다.
남은 것
90분 잡은 일이 훨씬 짧게 끝났다. 짧아진 이유가 타이핑이 빨라서가 아니라, 고칠 자리를 마흔에서 열넷으로 줄이는 판단을 먼저 했기 때문이다.
「전부 고쳐야 한다」가 보이면, 안 고쳐도 되게 만드는 층이 있는지 먼저 찾는다.
여기선 그 층이 viewBox 였다. 브라우저가 이미 「좌표계와 표시 크기를 분리하는」 일을 해 주고 있었고, 나는 그걸 안 쓰고 손으로 하려던 참이었다.
그리고 이 선택은 버그의 개수가 아니라 버그의 성질을 바꿨다. 마흔 군데를 고쳤으면 남았을 버그는 「어떤 도형이 어떤 배율에서만 3픽셀 밀린다」였을 것이다. 아무도 못 찾는 종류다. 지금 남을 수 있는 버그는 「클릭이 통째로 어긋난다」뿐이고, 그건 한 번 눌러 보면 안다.