인쇄 CSS 가 70% 로만 그려질 때 — 0.707 의 정체

PDF 로 뽑았는데 내용이 종이 왼쪽 위 70% 쯤에만 그려져 있다. 나머지는 흰 공간이고, 세로 장은 오른쪽이 잘리기도 한다. 이때 인쇄 CSS 를 고치기 시작하면 증상은 계속 조금씩 달라지는데 70% 는 안 움직인다.

2026-08-13. 방과후 수업 결과보고서가 그랬다.

인쇄 CSS 를 여러 번 손봤다. 페이지 방향을 정하는 규칙 이름을 바꾸고, 장 나누는 방식을 「뒤에서 끊기」에서 「앞에서 끊기」로 바꾸고, 시트 높이를 0.4mm 낮추고, 가운데 정렬을 껐다. 그때마다 증상이 조금씩 달라졌다. 빈 장이 사라지고, 잘림이 줄었다. 그런데 70% 는 그대로였다.

그럴듯한 첫 진단

처음 세운 가설은 이랬다. 페이지 방향 규칙에 portrait·landscape 라는 이름을 붙였는데, 그게 CSS 방향 키워드와 같은 낱말이라 브라우저가 규칙을 통째로 버린다는 것. 증상과도 맞아떨어졌다 — 브라우저가 방향을 못 정하니 인쇄 대화상자 설정이 전부를 덮어쓴 것처럼 보였다.

그런데 이 문서에는 정답지가 있었다. 3주 전에 승인받은 시안이 같은 레이아웃으로 이미 잘 나오고 있었다. 그 CSS 를 열어 봤다.

시안은 그 이름을 그대로 쓰고 있었다. portrait, landscape. 그리고 멀쩡했다. 내 진단이 틀렸다는 증거였다.

가른 건 실험 한 번이었다

그래서 시안 HTML 을 내 방식(headless 브라우저)으로 그대로 뽑아 봤다. 결과는 꽉 찬 A4 였다.

이걸로 갈렸다 — 뽑는 방법이 아니라 내 페이지가 문제다.

차이는 금방 나왔다. 시안은 종이 한 장이 body 바로 밑에 있고, 내 것은 앱 껍데기 두 겹 안에 들어 있었다. 그 껍데기가 화면 크기를 붙들고 있어서 문서 폭이 가장 넓은 요소(가로 장) 기준으로 잡히고, 그걸 세로 종이에 인쇄하려니 축소가 걸렸다.

210 ÷ 297 = 0.707.

내가 본 70% 가 그 숫자였다.

바꾼 것과 되돌린 것

• 인쇄할 때만 껍데기를 레이아웃에서 빼냈다. 상자를 없애고 자식만 남기는 방식이라 안쪽 구조는 건드리지 않는다
• 앞서 넣었던 땜질 두 개가 필요 없어져 되돌렸다 — 시트 높이 0.4mm 축소, 방향 기본값 규칙. 둘 다 증상을 덮으려고 넣었던 것이고, 원인이 사라지니 역할이 없었다
• 페이지 방향 이름은 헷갈리지 않는 이름으로 바꿨다. 원인은 아니었지만 다음 사람이 나처럼 의심할 자리라서

잘 되는 사례가 이미 있으면, 가설을 세우기 전에 그걸 내 조건에 넣어 본다. 그 한 번이 「내 코드가 문제인가, 방법이 문제인가」를 갈라 준다. 나는 그걸 나중에 했고, 그 사이에 넣은 수정 중 절반은 없어도 되는 것이었다.