본문 바로가기

파일 형식 백과사전

한글 문서에 사진을 작게 줄여 넣었는데 용량이 그대로인 이유

보고서에 사진 몇 장을 넣고 크기를 작게 조절했는데도 파일이 400KB를 넘어갑니다. 화면에서는 손톱만 하게 줄여 놨으니 용량도 줄었으려니 하지만, 저장하고 보면 그대로입니다.

한글이 사진을 어떻게 담는지 확인해 봤습니다. 4000x3000 사진 한 장을 표시 크기만 바꿔 가며 넣고 저장한 뒤, 문서 안에 실제로 들어간 그림을 꺼내 픽셀과 바이트를 셌습니다. 같은 작업을 워드에서도 해서 나란히 놓았습니다.

 

 

4000x3000 사진 377,822바이트를 표시 크기만 바꿔 한글과 워드에 넣고 문서 안에 저장된 그림을 측정한 막대 그래프. 한글은 폭 지정 없이, 15cm, 8cm, 4cm 네 경우 모두 4000x3000 원본 377,822바이트를 그대로 담았다. 워드는 각각 1379x1034 103,883바이트, 1300x975 95,084바이트, 693x520 40,944바이트, 346x260 15,427바이트로 표시 크기에 220ppi를 곱한 픽셀로 다시 만들어 담았다

 

표시 크기를 줄여도 파일은 꿈쩍하지 않았습니다

같은 사진을 폭 150mm, 80mm, 40mm로 각각 줄여 넣고 저장했습니다. 문서 안의 그림 자리(BinData)를 열어 보니 결과가 한결같았습니다.

넣은 방법 문서 안 사진 사진 픽셀
폭 지정 없이 377,822 B 4000x3000
폭 150mm로 377,822 B 4000x3000
폭 80mm로 377,822 B 4000x3000
폭 40mm로 377,822 B 4000x3000

네 경우 모두 원본 파일과 한 바이트도 다르지 않았습니다. 화면에서 조절한 크기는 "이만큼으로 그려라"라는 표시 정보일 뿐이고, 저장되는 그림은 처음 넣은 원본 그대로입니다.

문서 전체 크기도 39만 바이트대에서 거의 움직이지 않았습니다. 사진을 아무리 작게 보이게 해도 파일이 안 줄어드는 이유가 여기 있습니다.


워드는 같은 상황에서 사진을 다시 만듭니다

비교를 위해 같은 사진을 워드에 넣고 폭만 바꿔 저장했습니다. 이쪽은 완전히 다르게 움직였습니다.

표시 폭 docx 안 사진 사진 픽셀
지정 없이 103,883 B 1379x1034
15cm 95,084 B 1300x975
8cm 40,944 B 693x520
4cm 15,427 B 346x260

규칙이 정확히 떨어집니다. 표시할 크기에 인치당 220픽셀을 곱한 만큼으로 사진을 다시 만들어 넣습니다. 15cm는 15 나누기 2.54 곱하기 220으로 계산하면 1,299가 되고 실제 값은 1,300이었습니다. 8cm는 693, 4cm는 346으로 계산과 맞아떨어졌습니다.

그래서 같은 사진, 같은 표시 크기인데도 문서 크기가 크게 벌어집니다. 폭 4cm로 넣은 경우 한글 문서는 39만 바이트대, 워드 문서는 27,493바이트였습니다.

한글에서 용량을 줄이려면 넣기 전에 줄여야 합니다

한글이 원본을 그대로 안고 가니, 방법은 하나입니다. 넣기 전에 사진 자체를 필요한 크기로 줄여 두는 것입니다. 폭 150mm를 220ppi로 채우는 데 필요한 만큼(1299x974)으로 미리 줄여서 같은 자리에 넣어 봤습니다.

넣은 사진 문서 안 사진 문서 전체
4000x3000 원본 377,822 B 398,336 B
1299x974로 미리 줄인 것 73,943 B 184,320 B

사진 자리가 80% 줄었고 문서도 절반 이하가 됐습니다. 인쇄까지 생각해도 문서 폭에 맞춰 1,300픽셀 안팎이면 충분합니다. 해상도를 줄일지 화질을 낮출지 헷갈린다면 해상도와 화질 중 무엇을 조절하는 게 효율적인지 실측한 글이 기준이 됩니다.

참고로 문서 전체 크기에는 탐색기 미리보기용 썸네일도 함께 들어가는데, 이 썸네일 크기는 그림 내용에 따라 오르내립니다. 그래서 사진을 줄인 효과를 정확히 보려면 문서 크기보다 그림 자리 자체를 봐야 합니다.


내 문서 안에 무엇이 들었는지 확인하기

hwp는 한 파일 안에 여러 칸을 둔 구조라 코드로 열어 볼 수 있습니다. 그림은 BinData 아래에 들어갑니다.

import olefile

ole = olefile.OleFileIO("보고서.hwp")
for path in ole.listdir(streams=True):
    name = "/".join(path)
    print(name, ole.get_size(name))

# BinData/BIN0001.jpg    377822
# PrvImage                 8857
# BodyText/Section0         380

hwpx로 저장했다면 표준 zip이라 더 간단합니다. 압축 프로그램으로 열어도 BinData 폴더가 그대로 보입니다. 파일 안이 어떻게 나뉘어 있는지는 한컴 없이 hwp를 여는 방법을 다룬 글에서 더 자세히 볼 수 있습니다.

자주 묻는 질문

Q. 사진을 자르면 잘린 부분은 빠지나요?
표시상 잘라 낸 것이라 원본이 그대로 남는 경우가 많습니다. 확실히 줄이려면 사진 편집 프로그램에서 잘라 저장한 뒤 그 파일을 넣으세요.

Q. 한글에도 그림 압축 기능이 있지 않나요?
문서 정리나 그림 저장 관련 기능이 버전에 따라 제공됩니다. 다만 메뉴 위치와 동작이 버전마다 달라, 위 실측은 기본 삽입과 저장만으로 확인한 결과입니다.

Q. 사진 여러 장을 넣으면 어떻게 되나요?
장마다 원본이 그대로 들어갑니다. 10장이면 원본 10개가 그대로 쌓인다고 보면 됩니다.

Q. 화질이 떨어지지 않을까요?
문서 폭에 맞는 픽셀 수만 확보하면 화면과 인쇄 모두 차이를 느끼기 어렵습니다. 원본은 따로 보관해 두면 됩니다.

 

파일이 무거워진 원인을 안에서 찾아내는 접근은 엑셀 파일이 3.4MB가 된 이유를 파일 안에서 찾은 글과 같습니다. 프로그램마다 무엇을 어떻게 담는지가 다를 뿐, 열어 보면 범인은 대개 한 자리에 몰려 있습니다.

 

위 픽셀과 바이트는 윈도우 11에서 한글 2020과 Word 2013으로 같은 사진을 넣어 저장한 뒤, 파이썬 3.14.3의 olefile과 zipfile로 문서 내부를 직접 읽어 얻은 값입니다.

 

 

중첩된 JSON을 엑셀에서 열리는 CSV로, 배열까지 한 줄씩 펼쳐 변환하기

API에서 받아 온 JSON을 엑셀로 열어 보려고 CSV로 바꿨더니,한 칸 안에 {'name': '김민수', 'grade': 'gold'} 같은 덩어리가통째로 들어가 버린 적이 있습니다. 표로 정리하려던 데이터가 오히려 더 읽기

richyeon.com

 

 

Parquet 저장할 때 compression만 바꿨을 뿐인데 용량이 갈립니다, 코덱 3종 실측 비교

데이터를 Parquet로 저장하다 보면 compression 옵션에 snappy, gzip, zstd 같은 낯선 이름이 등장합니다.아무거나 골라도 열리기는 하니 대충 넘기기 쉽지만,이 한 줄이 파일 크기와 저장 속도를 꽤 크게

richyeon.com

 

 

CSV를 열었더니 주소 뒷부분이 옆 칸으로, 값 속 쉼표 때문에 열이 밀리는 문제

이름과 주소가 잘 정리돼 있던 CSV를 프로그램으로 읽었더니,주소 한 칸이 두 칸으로 쪼개지면서 그 뒤 금액까지 줄줄이 옆으로 밀려 버리는 경우가 있습니다.데이터는 멀쩡한데 표만 어긋난 것

richyeon.com