첨부파일과 메시지의 크기가 다른 이유
전송할 때 커지는 것은 주로 PDF가 들어 있는 메시지입니다. 이메일은 원래 텍스트를 위해 만들어졌습니다. 그래서 이메일 프로그램은 첨부파일을 MIME 형식으로 구성하고, 대부분 Base64를 사용해 바이너리 데이터를 일반 텍스트 문자로 변환합니다. 이 과정에서 파일의 3바이트마다 4개의 문자가 만들어지고, 이 문자들은 줄 끝 문자가 있는 여러 줄로 나뉩니다. Base64 인코딩 자체는 되돌릴 수 있습니다. 디코딩하면 원래의 바이트가 정확히 복원됩니다. 완성된 메시지에는 헤더, 메시지 본문, 각 부분 사이의 경계 표시도 추가됩니다.
따라서 메시지는 선택한 첨부파일보다 훨씬 클 수 있습니다. 한 독일어 포럼에서는 누군가 20.1 MB PDF를 보냈는데 발송된 이메일이 왜 27.5 MB가 되었는지 질문했습니다. 이 계산기에서 20,100,000바이트를 줄바꿈을 켜고 추가 바이트 없이 계산하면 Base64 데이터 26,800,000바이트와 줄 끝 문자 705,264바이트가 나옵니다. 합계는 27,505,264바이트로, 약 27.51 MB입니다. 이 계산은 그러한 크기가 어떻게 나오는지 보여줍니다. 모형 계산이며 해당 이메일 자체를 분석한 것은 아닙니다.
예상치의 구성 요소
각 첨부 파일은 개별적으로 인코딩되므로 파일마다 별도의 행에 입력하세요. 크기는 B, KB, MB, GB, MiB, GiB 등의 단위를 사용할 수 있습니다. 계산기는 십진 단위인 MB를 1,000,000바이트로, 이진 단위인 MiB를 1,048,576바이트로 환산합니다. 환산한 바이트 수는 정수여야 하며, 파일 크기에 음수를 사용할 수 없습니다. 숫자 입력란에는 단위를 넣지 마세요. 소수점은 마침표를 사용하므로 1.000의 값은 1입니다. 천은 1000 또는 1,000으로 입력하세요. 쉼표는 세 자리씩 자릿수를 구분할 때만 사용할 수 있으며, 자릿수 사이의 공백은 허용되지 않습니다.
- 원본 크기: 첨부파일의 바이트 수를 합한 값입니다. 계산의 시작값이며 첨부파일 한도와 비교할 때 사용됩니다.
- Base64 데이터: n바이트 첨부파일은 4 × 올림(n ÷ 3)개의 문자가 됩니다. 끝에 남은 바이트가 세 개로 이루어진 묶음을 채우기에 부족하면 패딩이 마지막 네 문자 묶음을 채웁니다.
- 줄 끝 문자: 기본 설정인 줄바꿈이 켜져 있으면 계산기는 각 첨부파일의 문자를 최대 76자씩 줄로 나눕니다. 마지막 줄을 포함해 각 줄마다 줄 끝 문자 CRLF에 해당하는 2바이트를 더합니다.
- 추가 바이트: 텍스트, 헤더, 메시지의 다른 부분에 대해 직접 입력하는 값입니다. 기본값은 0입니다.
- 예상치: 모든 첨부파일의 Base64 데이터와 줄 끝 문자에 추가 바이트를 더한 값입니다.
Base64는 항상 정확히 삼분의 일만큼 커지나요?
대략 그렇습니다. 3바이트가 4개의 문자로 바뀌는 비율은 파일이 클수록 33⅓ % 증가에 가까워집니다. 줄바꿈이 없으면 10,000,000바이트는 정확히 13,333,336바이트가 되어 약 33.33 % 커집니다. 정확한 삼분의 일과의 미세한 차이는 패딩에서 발생합니다. 줄 끝 문자를 포함하면 13,684,214바이트로 약 36.8 % 커집니다. 따라서 약 37 %라는 경험적 기준은 줄바꿈을 포함한 인코딩 데이터를 설명합니다. 이 값은 줄 길이와 줄 끝 문자에 따라 달라지며 헤더와 본문은 반영하지 않습니다.
작은 파일에는 고정 배수를 적용하는 것이 전혀 맞지 않을 수 있습니다. 1바이트 첨부파일은 Base64 문자 4개와 줄 끝 문자 2바이트로 바뀌어 총 6바이트가 됩니다. 그래서 계산기는 전체에 일률적인 배수를 곱하는 대신 각 첨부파일을 정확히 계산합니다.
첨부파일이 여러 개라면 각 파일을 개별적으로 계산
첨부파일은 하나의 큰 블록으로 합쳐지는 것이 아니라 각각 별도로 인코딩됩니다. 따라서 각 파일에는 고유한 패딩과 마지막 줄 끝 문자가 붙습니다. 각각 1바이트인 파일 두 개라는 극단적인 예시에서 이 차이가 가장 뚜렷하게 드러납니다.
큰 PDF 하나에서는 이 몇 바이트의 영향이 거의 없습니다. 하지만 작은 파일이 많으면 이 차이가 누적됩니다.
76자라는 줄 길이는 MIME 표준에서 Base64 줄에 허용하는 최대 길이입니다. 마지막 줄 뒤에도 CRLF를 계산하는 것은 이 계산기에서 정한 규칙입니다. 더 짧은 줄을 사용하거나 마지막 부분을 다르게 처리하는 이메일 프로그램에서는 값이 조금 달라집니다. 또 하나 흔한 오해가 있습니다. Base64는 암호화가 아닙니다. 키 없이도 원래대로 되돌릴 수 있는 단순한 인코딩이며 첨부파일의 내용을 보호하지 않습니다.
올바른 크기 한도와 비교하기
크기 한도에는 숫자가 적혀 있지만, 무엇을 기준으로 하는지 항상 명시되어 있지는 않습니다. 어떤 규칙은 이메일 프로그램에 표시되는 파일 크기, 즉 원본 첨부파일의 총크기를 제한합니다. 다른 규칙은 인코딩된 첨부파일, 본문, 헤더를 모두 포함한 전체 메시지를 제한합니다. 그래서 계산기에서는 한도를 무엇과 비교할지 선택합니다. 미리 입력된 25 MB는 시작값일 뿐 특정 제공업체의 규정이 아닙니다. 결과가 한도와 정확히 같으면 한도 이내로 간주합니다.
따라서 같은 파일이 한 규칙은 충족하고 다른 규칙은 충족하지 못할 수 있으며, 이는 모순이 아닙니다.
기준이 서로 다른 실제 규칙 두 가지
- Gmail: 독일어 Gmail 첨부파일 도움말에 따르면(2026년 10월 13일 확인), 개인 계정의 첨부파일 총크기는 25 MB까지 허용됩니다. 첨부파일의 합계를 뜻하므로 원본 첨부파일과 비교하는 것이 적절합니다. Google Workspace 계정은 관리자가 한도를 정합니다. 합계가 이를 넘으면 첨부파일이 Google Drive 링크로 대체됩니다.
- 에를랑겐 뉘른베르크 대학교 RRZE: 이메일 첨부파일 크기 제한 안내에 따르면(2026년 10월 13일 확인), RRZE 서버에서 송수신되는 이메일은 전체 크기가 최대 20 MB여야 합니다. 이 경우 예상 메시지와 비교하고 추가 바이트도 입력하는 것이 적절합니다.
두 규칙은 각각 해당 범위에만 적용되며 변경될 수 있습니다. 발송할 때는 개인 계정이든 직장, 학교, 대학교에서 관리하는 계정이든 본인 계정의 규칙을 따라야 합니다. 수신자 메일함의 규칙도 마찬가지로 중요합니다. 수신자의 요구 사항을 알고 있다면 정확히 무엇을 기준으로 하는지 확인해 비교에 반영하세요. 제공업체가 큰 파일을 자동으로 링크로 보내면 해당 파일은 더 이상 메시지의 첨부파일에 포함되지 않습니다. 그 링크를 수신자가 열 수 있는지, 열어도 되는지는 별도로 확인해야 합니다.
완전한 메시지에 추가로 필요한 요소
인코딩된 첨부파일만으로는 이메일이 완성되지 않습니다. 완성된 메시지에는 발신자, 수신자, 제목, 기술 정보가 담긴 헤더가 포함됩니다. 여기에 메시지 본문이 추가되며, 본문은 일반 텍스트와 HTML 두 형식으로 함께 들어가는 경우가 많습니다. MIME 부분 사이의 경계선과 서명의 로고 같은 삽입 이미지도 추가됩니다. 이 요소들이 차지하는 크기는 이메일 프로그램, 본문, 수신자에 따라 달라집니다.
추가 바이트에 입력할 값
모든 경우에 맞는 정답은 없습니다. 추가 바이트를 0으로 두면 계산기는 줄 끝 문자를 포함한 인코딩 첨부파일만 표시합니다. 즉, 본문과 헤더가 빠진 모형값입니다. 따라서 본인의 이메일에 맞는 가정값을 입력하세요. 이미지 없는 짧은 본문에는 적은 용량이 필요하지만 이미지가 삽입된 HTML 이메일에는 훨씬 더 많은 용량이 필요합니다. 다른 이메일 예시의 값은 해당 이메일에만 적용됩니다. 결과가 한도보다 조금 작다면 여유 있게 더 큰 값을 가정해 다시 계산해 보세요. 그래도 한도 이내라면 여유가 있는 것입니다. 초과로 바뀐다면 한도에 근접한 상황입니다.
비교 결과가 한도 이내인데도 이메일이 반송되는 경우
- 메시지에 포함된 데이터가 추가 바이트로 가정한 것보다 많았거나 이메일 프로그램이 다른 줄 길이로 인코딩했을 수 있습니다.
- 수신자 서버의 허용 한도가 본인 계정보다 낮을 수 있습니다.
- 한도가 전체 메시지에 적용되는데 원본 첨부파일과 비교했을 수 있습니다. 또는 본인 계정에 예상과 다른 규칙이 적용될 수 있습니다.
- 수신자가 매크로가 포함된 문서나 실행 프로그램 같은 특정 파일 형식을 허용하지 않아 크기와 무관하게 차단할 수 있습니다.
이 계산기는 선택한 수치만 비교합니다. 아무것도 전송하지 않으며, 전달 여부를 시험하거나 파일 형식과 보안 규칙을 확인하지도 않습니다. 뉴스레터에는 표시와 관련된 제한도 있습니다. 일부 메일함은 긴 HTML 이메일의 일부만 표시합니다. 이는 첨부파일 크기와는 별개의 문제이며 여기서 계산하지 않습니다.
너무 큰 경우: 완성된 PDF로 다음 단계 진행하기
예상치가 한도를 넘으면 두 가지 방법이 있습니다. 파일 자체의 바이트 수를 줄이거나 첨부파일 이외의 전달 방법을 선택하는 것입니다. 수신자가 첨부파일을 명시적으로 요구한다면 다음과 같이 진행하세요.
- 전송 전에 PDF 압축하기를 이용하거나, 정해진 한도를 알고 있다면 크기 한도에 맞춰 PDF 줄이기를 이용하세요. 파일이 얼마나 줄어드는지는 내용에 따라 달라집니다. 모든 경우에 목표 크기를 달성할 수 있는 것은 아닙니다.
- 결과를 열어 문서가 여전히 읽기 좋은지 확인하세요.
- 다운로드한 파일의 크기를 여기에 다시 입력하세요. 기준은 기대하는 절감량이 아니라 완성된 파일입니다.
- 예상치가 한도 이내라면 이메일을 보내세요. 그렇지 않다면 수신자와 다른 방법을 상의하세요.
수신자가 링크를 허용하고 접근 권한과 개인정보 보호 조건이 문서에 적합하다면 클라우드나 파일 서비스를 통한 공유 링크가 대안이 될 수 있습니다. 서비스는 직접 선택합니다. 이 계산기는 입력한 숫자만으로 계산하며 파일을 저장하거나 전송하지 않습니다. 반면 ZIP 압축파일은 더 작은 PDF를 대신하는 확실한 방법이 아닙니다. PDF 크기가 반드시 줄어드는 것은 아니며, PDF 파일을 명시적으로 요구하는 곳에서는 압축파일을 받지 않을 수도 있습니다.
파일을 이메일로 보내는 대신 포털에 업로드하려면 PDF 업로드 제한 확인을 이용하고, 미리 파일 업로드 시간 예상하기를 이용할 수 있습니다.