2026-08-24

구글 슬라이드·문서에 PDF가 안 들어가는 이유, 업로드 없이 페이지를 JPG로 바꾸는 법

새 학기 수업 자료와 발표 자료가 만들어지는 8월마다, 구글 자체 지원 포럼에는 같은 질문이 다시 올라옵니다: PDF를 구글 슬라이드에 어떻게 넣나요? 이 질문은 몇 년째 반복되고 있습니다 — 2020년, 2023년, 그리고 가장 최근에는 2026년 1월의 스레드까지 전부 같은 발견을 맴돕니다. 해결할 오류 메시지조차 없습니다. 클릭할 것 자체가 없으니까요: 슬라이드나 문서에서 삽입 > 이미지를 열면 구글 공식 도움말이 나열하는 소스는 "컴퓨터에서 업로드, 스톡 및 웹, Drive 및 Photos, 카메라, URL 사용" — 전부 이미지 경로입니다. 그 페이지가 설명하는 삽입 가능한 유형은 사진, 동영상, GIF, 스티커, 오디오 파일이고, PDF는 메뉴 어디에도 없습니다. 파일명을 바꾸든 다시 내보내든 달라지지 않습니다. 사람들이 결국 도달하는 우회로는 이미지 전용 업로드 창구 어디에서나 통하는 그 방법 하나입니다: 페이지를 먼저 이미지로 바꾸는 것. 흥미로운 부분은 그 변환을 문서를 변환 사이트에 넘기지 않고 해내는 것 — 그리고 그 거래에서 무엇을 내주는지 정확히 아는 것입니다.

마이크로소프트는 속사정을 대놓고 말합니다

파워포인트를 먼저 보는 게 좋습니다. 마이크로소프트가 구글보다 상황을 더 직설적으로 문서화해 놓았기 때문입니다. 프레젠테이션에 PDF 콘텐츠를 삽입하는 방법에 대한 공식 지원 페이지는 정확히 두 가지 방법을 제시하는데, 둘 다 데스크톱 전용입니다. 하나는 PDF의 그림을 삽입하는 것 — 화면에 지금 보이는 부분의 스크린샷으로, "캡처하려는 내용이 전부 보이도록 PDF의 확대/축소 수준을 낮추라"는 팁까지 마이크로소프트가 직접 달아 놓았습니다. 다른 하나는 파일 전체를 개체로 포함시켜 더블클릭하면 별도 뷰어로 열리게 하는 것인데, 같은 페이지가 그 방법에 대해 문자 그대로 "이 방법을 사용하면 PDF 파일의 품질이 저하됩니다"라고 경고합니다. 그리고 브라우저에서 작업한다면 둘 다 없습니다: "웹용 PowerPoint에서 프레젠테이션을 편집할 때는 PDF 콘텐츠를 삽입할 수 없습니다." 두 회사의 문서를 겹쳐 읽으면 밑바탕의 사실은 하나입니다. 슬라이드는 텍스트 상자와 이미지의 캔버스이고 PDF 페이지는 그 둘 다 아니므로, 슬라이드에 오르는 모든 실질적인 경로는 페이지를 그림으로 바꿉니다 — 남는 질문은 그 그림이 잘려 나간 스크린샷이냐, 제대로 된 전체 페이지 렌더링이냐뿐입니다.

구글의 텍스트 경로도 있습니다 — 대신 레이아웃을 내줍니다

구글에도 PDF에서 편집 가능한 파일로 가는 자체 경로가 하나 있습니다: Drive에 저장된 PDF를 Google 문서로 열면 문서가 텍스트 변환을 시도합니다. 하지만 구글 도움말 스스로 제약을 솔직하게 밝힙니다: 파일은 2MB 이하여야 하고, 텍스트 높이는 최소 10픽셀이어야 하며, "굵게, 기울임꼴, 글꼴 크기, 글꼴 종류, 줄바꿈은 유지될 가능성이 높지만" "목록, 표, 열, 각주, 미주는 인식되지 않을 가능성이 높습니다." 이 거래가 딱 맞는 경우도 있습니다 — 원하는 게 글자이고, 그걸 내 슬라이드에 다시 흘려 넣을 거라면요. 하지만 사람들이 보통 이 질문을 하게 만드는 문서들 — 두 단으로 빈칸이 배치된 학습지, 전단, 차트, 서식, 악보 한 장 — 즉 생긴 모습 자체가 가치인 문서에는 정확히 틀린 거래입니다. 그런 문서라면 충실한 경로는 반대쪽입니다: 텍스트를 추출하지 말고, 페이지를 렌더링하세요.

페이지를 JPG로 렌더링 — 서버가 아니라 브라우저에서

그 렌더링 단계가 NearPDF의 PDF to JPG 도구가 하는 일이고, 전부 사용자 기기 안에서 실행됩니다. PDF를 추가하면 모든 페이지가 썸네일 그리드에 나타납니다. 자료에 필요 없는 페이지는 빼고, 폰 스캔이 옆으로 눕혀 놓은 페이지는 회전시킨 다음 변환하세요. 남은 각 페이지는 로컬에서 — 썸네일을 그리는 바로 그 브라우저 내장 엔진이 전체 페이지를 그대로 그려서 — 축소판이 아니라 읽기와 인쇄를 염두에 둔 높은 고정 해상도로 렌더링됩니다. 결과는 페이지당 JPG 한 장씩, 정해 둔 순서대로 번호가 붙어(page-01.jpg, page-02.jpg, …) ZIP 파일 하나에 담깁니다. 아무것도 업로드되지 않는다는 점이 이 작업에서는 평소보다 더 중요합니다: 수업 자료와 회의 슬라이드에 들어가는 PDF야말로 낯선 서버를 거쳐서는 안 되는 파일인 경우가 많으니까요 — 출제 전 시험지, 명단, 내부 보고서 같은 것들 말입니다. 거기서부터는 편집기가 자기 방식대로 이어받습니다: 슬라이드나 문서에서 삽입 > 이미지 > 컴퓨터에서 업로드. 전체 페이지 JPG는 페이지 본래의 비율을 유지하므로 슬라이드 한 장에 페이지 한 장이 깔끔하게 들어갑니다. 그리고 삽입된 이미지는 이들 편집기의 일급 객체이므로, 사진에 할 수 있는 모든 것 — 자르기, 크기 조절, 배치, 위에 텍스트 얹기 — 이 이제 당신의 페이지에도 통합니다.

그림이 된 페이지가 할 수 없는 것

이 변환의 대가를 냉정하게 보아야 합니다. 구글 텍스트 경로의 대가를 정확히 뒤집은 것이기 때문입니다. 렌더링된 JPG는 레이아웃을 완벽하게 보존하는 대신 텍스트를 내줍니다: 슬라이드나 문서 안에서 그것은 그림이므로, 그 위의 어떤 것도 편집할 수 없고 어떤 것도 검색되지 않습니다. 학생들이 학습지에 직접 타이핑해야 한다면 학습지의 이미지로는 도달할 수 없습니다 — 그건 서식 손실을 감수하는 변환 경로의 일이거나, 편집기에서 페이지를 다시 만드는 일입니다. 방향(회전)에도 같은 일방통행 논리가 적용되는데, 이유는 회전 글이 설명한 그대로입니다: PDF 페이지는 회전을 나중에 다른 도구가 바꿀 수 있는 플래그로 담고 다니지만, JPG에는 그런 플래그가 없습니다 — 픽셀이 그려진 방향이 곧 영원한 방향입니다. 그리드에서 변환 전에 회전시킬 수 있게 해 둔 이유가 정확히 그것이고, 변환 전에 썸네일을 실제로 한번 훑어볼 가치가 있는 이유이기도 합니다.

정직하게 밝히는 한계

NearPDF는 페이지를 하나의 높은 고정 해상도로 렌더링합니다 — 정확한 픽셀 크기나 JPEG 품질, 파일 용량 목표를 맞추는 다이얼은 없고, 여러 페이지를 세로로 긴 이미지 한 장으로 합치는 옵션도 없습니다. 목적지가 정확한 규격을 요구한다면 그건 다른 도구의 일이며, 자세한 내용은 이미지 전용 업로드 글에 정리되어 있습니다. 반대 방향(이미지를 다시 PDF로)은 하지 않고, OCR도 하지 않으며, 암호화된 PDF는 아예 열 수 없습니다 — 암호가 걸린 파일은 추가 단계에서 건너뛰므로 먼저 암호를 해제하세요. 그리고 발표 자료를 대신 만들어 주지도 않습니다: 결과물은 페이지 이미지가 담긴 ZIP이고, 각 이미지를 슬라이드에 얹는 건 여전히 편집기 위의 당신 손입니다. NearPDF가 대신하는 것은 그 포럼 스레드들 전부에 빠져 있던 바로 그 한 단계뿐입니다: 문서가 방을 떠나는 일 없이 만들어지는, 각 페이지의 충실한 전체 해상도 이미지.