2026-07-25

PDF 회전이 저장되지 않는 이유, 페이지 회전이 실제로 동작하는 방식

"PDF 회전이 저장되지 않는다"는 PDF 관련해서 가장 흔한 불만 중 하나입니다. 검색해보면 이걸 고쳐주겠다는 가이드가 끝없이 나옵니다. 그런데 대부분의 경우 회전은 실제로 일어났습니다. 다만 그 뒤에 파일이 기대한 대로 동작하지 않을 뿐입니다. PDF 페이지의 회전은 나름의 규칙을 가진 숫자 값 하나로 저장되는데, 정작 회전 버튼들은 이 규칙을 거의 설명해주지 않기 때문입니다.

페이지를 회전시키면 실제로 무엇이 바뀌나

PDF 페이지는 자신의 페이지 딕셔너리 안에 /Rotate라는 항목을 하나 갖고 있습니다. 이 값은 0, 90, 180, 270도, 이렇게 네 가지만 가능하고 항상 시계 방향으로 해석됩니다. 메커니즘 전체가 이게 다입니다. 페이지를 회전시켜도 그 페이지의 콘텐츠 스트림 — 텍스트, 이미지, 벡터 선을 그리는 실제 명령어들 — 은 전혀 건드리지 않습니다. "이걸 몇 도 돌려서 보여줘"라는 지시 하나만 바뀌고, 나머지는 바이트 단위로 그대로입니다. 그래서 40페이지짜리 PDF를 회전시켜도 거의 즉시 끝나고 파일 용량도 늘지 않습니다 — 다시 인코딩할 이미지는 없고, 손댄 페이지 수만큼의 정수 값만 바뀌는 것이니까요.

같은 "회전"이라는 이름의 서로 다른 두 가지

"PDF 회전이 저장되지 않는다"를 검색하면 불만의 모양이 늘 똑같습니다: 페이지를 회전시키고, 파일을 닫았다가 다시 열면 원래대로 돌아와 있다는 것입니다. 많은 무료 PDF 뷰어는 겉보기엔 똑같아 보이는 두 가지 기능을 제공하는데, 실제로는 완전히 다르게 동작합니다. 하나는 보기 회전(view rotation)으로, 해당 열람 세션에서만 적용되는 화면 표시 설정이며 뷰어 자체의 설정으로만 저장될 뿐 파일에는 절대 기록되지 않습니다. 다른 하나는 페이지 회전(page rotation)으로, 페이지의 실제 /Rotate 값을 다시 써서 새 파일로 저장하며, 이렇게 저장된 회전은 다른 모든 앱, 모든 프린터, 나중에 그 파일을 여는 다른 사람에게도 똑같이 보입니다. 이건 PDF 업계에서도 이름을 붙여 구분할 만큼 자리 잡은 구분입니다 — Bluebeam은 아예 "Rotate View vs. Rotate Pages"라는 제목의 지원 문서를 따로 두고 있습니다. 회전이 저장되지 않는다면 거의 항상 전자입니다 — 파일에는 애초에 아무것도 기록된 적이 없는 것입니다.

손대기도 전에 이미 회전되어 있는 페이지들

옆으로 누운 페이지가 전부 누군가 회전 버튼을 눌러서 생긴 결과는 아닙니다. 스캐너나 휴대폰 스캔 앱은 센서가 놓인 방향 그대로 페이지를 촬영한 뒤, 이미지를 바로 세워 다시 인코딩하는 대신 그냥 /Rotate 값을 설정해서 화면에서만 바르게 보이도록 처리하는 경우가 많습니다. 그래야 출력 파일 용량이 작게 유지되지만, 그 대신 스캔한 PDF는 각 페이지마다 실제로 0이 아닌 회전 값을 이미 품은 채로 도착할 수 있습니다 — 용지를 스캐너에 번갈아 넣었다면 페이지마다 값이 다를 수도 있습니다. 이런 문서를 열었을 때 4페이지가 옆으로 누워 있다고 해서 누군가 회전을 잘못한 것이 아닙니다. 스캐너가 이미 회전 값을 써 넣은 것이고, 그 다음에 무엇을 하든 그건 백지 상태가 아니라 이미 그 값 위에 얹히는 것입니다.

회전은 초기화되지 않고 누적된다

바로 이 "값 위에 얹힌다"는 부분이 중요합니다. 페이지를 회전시키는 건 방향을 고정된 값으로 설정하는 게 아니라, 그 페이지가 이미 갖고 있던 회전 값에 사용자가 고른 각도를 더하는 것이기 때문입니다. 이미 90도가 걸려 있는 페이지를 도구로 한 번 더 90도 회전시키면 90도가 아니라 180도가 됩니다. NearPDF의 회전 구현도 정확히 이렇게 동작합니다: page.setRotation(degrees((page.getRotation().angle + rot) % 360))는 페이지의 현재 각도를 읽어서 요청된 회전 값을 더하고, 360을 넘으면 다시 0부터 감아 돕니다. 90도 회전 버튼을 네 번 누르면 항상 원래 방향으로 돌아오지만, 반대로 말하면 한 번 눌렀는데도 여전히 방향이 이상하다면 버튼이 고장난 게 아니라 한 번 더 눌러야 하는 경우가 대부분이라는 뜻이기도 합니다.

같은 파일이 한 앱에서는 맞게, 다른 앱에서는 다르게 보이는 이유

/Rotate 값을 규격에 맞게 정확히 써 넣었다고 해도, 그 다음에 이 파일을 여는 모든 소프트웨어가 그걸 똑같이 존중해준다는 보장은 없습니다. 인쇄 경로는 특히 잘 알려진 문제 지점입니다 — Mozilla의 버그 트래커에는 자체 내장 PDF 뷰어가 회전된 페이지를 제대로 인쇄하지 못한다는 보고가 실제로 등록되어 있습니다. 화면에서는 회전이 맞게 보였는데, 인쇄된 페이지는 그렇지 않았던 사례입니다. 이건 회전 도구 쪽에서 미리 막을 수 있는 문제가 아닙니다. 규격에 맞는 /Rotate 값을 파일에 정확히 써 넣는 것까지가 페이지 회전 도구의 몫이고, 그 다음에 이어지는 뷰어나 프린터 드라이버, 변환기가 그 값을 제대로 읽어내는지는 회전 도구가 넘겨준 파일이 아니라 그 다른 소프트웨어의 몫입니다.

NearPDF는 이걸 어떻게 적용하나

NearPDF의 회전 기능은 workspace 화면의 개별 페이지 단위로 동작합니다. 페이지의 회전 버튼을 누를 때마다 90도씩 더해지고, 저장하기 전에 미리보기로 바로 확인할 수 있습니다. 저장하는 순간 이렇게 누적된 페이지별 회전 값이 그 페이지가 원래 갖고 있던 /Rotate 값과 합쳐져서 pdf-lib을 통해 출력 PDF에 실제로 기록됩니다 — 화면 표시 설정이 아니라 파일 자체에 남는 진짜 변경이며, 이 모든 과정이 사용자 기기 안의 Web Worker에서만 일어나고 아무것도 업로드되지 않습니다. 순서 바꾸기, 삭제, 회전은 모두 저장 전 같은 페이지 목록 위에서 함께 적용되므로, 옆으로 누운 스캔 페이지 하나, 빼고 싶은 페이지 하나, 순서가 뒤바뀐 페이지 하나를 도구 세 개와 내보내기 세 번이 아니라 한 번의 저장으로 함께 처리할 수 있습니다.