Base64 인코딩이란 무엇일까? Base64 인코딩의 원리, 사용하는 이유, 그리고 인코딩의 본질

📍개요

백엔드 개발을 하다 보면 Base64를 생각보다 자주 마주치게 됩니다. 파일 업로드 API를 만들 때도 보게 되고, JWT를 다룰 때도 보게 되며, 인증서나 키 파일을 처리할 때도 자연스럽게 등장합니다. 그런데 막상 “Base64가 정확히 무엇인가요?”라고 질문을 받으면, 단순히 “문자열로 바꿔주는 방식입니다” 정도로만 설명하고 넘어가는 경우가 많습니다. 실무에서는 이 정도 이해만으로도 사용할 수는 있지만, 조금만 더 깊이 들어가 보면 왜 이런 방식이 필요한지, 어떤 원리로 동작하는지, 무엇과 헷갈리기 쉬운지까지 정확히 이해하고 계시는 것이 훨씬 중요합니다.

 

특히 Base64는 문자 인코딩, 압축, 암호화와 자주 혼동됩니다. 실제로 개발을 하다 보면 “이거 Base64로 암호화된 값 아닌가요?” 또는 “UTF-8이랑 Base64가 비슷한 개념인가요?” 같은 질문이 자주 나옵니다. 하지만 Base64는 이런 개념들과 결이 다릅니다. 그래서 이번 글에서는 Base64를 단순히 “외워서 쓰는 기술”이 아니라 왜 필요한지, 어떤 원리로 동작하는지, 어디에 사용되는지, 무엇과 다른지까지 한 번에 정리해보겠습니다.

 

 

 

🤔Base64는 무엇인가?

Base64를 한 문장으로 정의하면, 바이너리 데이터를 텍스트로 안전하게 표현하기 위한 인코딩 방식입니다. 여기서 핵심은 “바이너리를 텍스트처럼 보이게 바꾼다”는 점입니다.

 

컴퓨터 내부에서 데이터는 결국 바이트 단위로 다뤄집니다. 이미지 파일도, PDF도, 오디오 파일도, 심지어 우리가 다루는 문자열조차도 결국은 바이트열입니다. 그런데 모든 시스템이 이런 바이트들을 그대로 안전하게 주고받을 수 있는 것은 아닙니다. 특히 과거의 많은 프로토콜과 시스템은 텍스트 중심, 더 정확히는 ASCII 문자 중심으로 설계되었습니다. 이런 환경에서는 특정 바이트 값이 제어 문자로 해석되거나, 줄바꿈으로 오인되거나, 문자열의 종료로 받아들여져 데이터가 손상될 수 있습니다.

 

이 문제를 해결하기 위해 등장한 것이 바로 Base64입니다. 원본이 바이너리이더라도, 이를 안전한 문자 집합으로 바꾸어 텍스트 기반 시스템에서도 문제 없이 전달할 수 있도록 만든 것입니다. 즉 Base64의 본질은 데이터를 숨기는 것이 아니라, 전달 가능한 형태로 바꾸는 것이라고 보시면 됩니다.

 

 

 

❓그럼 인코딩은 무엇일까?

Base64를 제대로 이해하려면 “인코딩”이라는 단어부터 정확히 짚고 넘어가야 합니다. 개발을 하다 보면 인코딩이라는 말을 너무 넓은 의미로 사용하게 되는데, 사실 인코딩은 어떤 데이터를 다른 표현 방식으로 바꾸는 규칙입니다. 즉, 데이터의 의미를 바꾸는 것이 아니라 표현 방식만 바꾸는 것입니다.

 

 

예를 들어 UTF-8은 문자를 바이트로 바꾸는 규칙입니다. "가"라는 문자를 저장하거나 전송하려면, 먼저 이것을 바이트로 바꿔야 하는데, 그때 어떤 바이트 조합으로 표현할지 정하는 규칙이 UTF-8 같은 문자 인코딩입니다. 반면 Base64는 이미 존재하는 바이트열을 다시 텍스트 형태의 문자열로 표현하는 규칙입니다. 둘 다 인코딩이지만, 대상과 목적이 완전히 다릅니다.

 

정리하면 다음과 같습니다.

1. 문자 인코딩은 문자를 바이트로 바꾸는 규칙입니다.
   예: ASCII, EUC-KR, UTF-8, UTF-16
2. Base64 같은 표현 인코딩은 바이트를 다시 안전한 텍스트 문자열로 바꾸는 규칙입니다.

즉 UTF-8은 "문자 → 바이트"이고, Base64는 "바이트 → 안전한 문자"입니다. 이 차이를 이해하지 못하면 Base64를 문자 인코딩과 비슷한 것으로 오해하게 됩니다.

 

 

 

🔄️왜 Base64가 필요할까?

Base64가 필요한 이유는 명확합니다. 모든 시스템이 바이너리를 안전하게 다루지는 못했기 때문입니다.

예전부터 많은 통신 프로토콜은 텍스트를 주고받는 데 최적화되어 있었습니다. 특히 이메일이나 일부 텍스트 기반 전송 방식에서는 바이너리 데이터가 포함되면 문제가 생기기 쉬웠습니다. 예를 들어 바이너리 데이터 안에는 다음과 같은 값들이 포함될 수 있습니다.

• 0x00 : null 바이트
• 0x0A : 줄바꿈
• 0x0D : 캐리지 리턴
• 0xFF : 확장 바이트

앞서 말한 바와 같이 이런 값들은 텍스트 프로토콜 안에서 다음과 같은 문제를 일으킬 수 있습니다.

1. 문자열의 끝으로 잘못 인식될 수 있습니다.
2. 줄바꿈이나 제어 문자로 해석될 수 있습니다.
3. 전송 과정에서 깨질 수 있습니다.
4. 중간 시스템이 잘못 처리할 수 있습니다.

그래서 이미지나 문서, 인증서, 서명값, 해시값 같은 바이너리 데이터를 직접 보내는 대신, 모두가 안전하게 다룰 수 있는 문자들로 바꾼 뒤 보내는 방식이 필요했습니다. Base64는 바로 이 문제를 해결하기 위해 널리 사용되기 시작했습니다.

 

 

✔️Base64의 핵심 원리

Base64의 핵심은 64개의 문자로 데이터를 표현한다는 것입니다. 이름 그대로 64개의 문자 집합을 사용합니다. 일반적으로 사용하는 문자 집합은 다음과 같습니다.

• A-Z : 26개
• a-z : 26개
• 0-9 : 10개
• + : 1개
• / : 1개

총 64개입니다.

왜 하필 64개일까요? 이유는 64가 2^6이기 때문입니다.

Base64는 데이터를 6비트 단위로 쪼개어 해석합니다. 컴퓨터의 기본 저장 단위는 8비트, 즉 1바이트인데, Base64는 이 바이트 흐름을 6비트씩 잘라서 각 값을 하나의 문자에 대응시킵니다. 각 문자는 0부터 63까지의 값을 표현한다고 생각하시면 됩니다. 

6비트에서 최대로 나타낼 수 있는 숫자는 63이고 최소는 0 이기 때문에 이 64개 글자를 이용해서 각 6비트에 해당하는 수의 값을 나타내는 것입니다. 

 

 

예를 들면 다음과 같은 방식입니다.

• 0 → A
• 1 → B
• 25 → Z
• 26 → a
• 51 → z
• 52 → 0
• 61 → 9
• 62 → +
• 63 → /

즉, Base64 인코딩이란 원본 바이트열을 6비트 단위의 값들로 재구성한 뒤, 그 값을 문자표에 대응시키는 과정입니다.

 

 

🔢Base64 인코딩 과정

이 부분은 글로만 보면 조금 추상적일 수 있기 때문에, 많이 사용하는 예시인 "Man"을 기준으로 단계별로 보겠습니다.

 

"Man"이 "TWFu"가 되는 과정

1. 먼저 "Man"의 각 문자를 ASCII 바이트로 바꿉니다.
   • M = 77
   • a = 97
   • n = 110
2. 이를 2진수 8비트로 표현합니다.
   • M = 01001101
   • a = 01100001
   • n = 01101110
3. 세 바이트를 하나로 이어붙입니다.
   • 01001101 01100001 01101110
4. 총 24비트가 만들어지므로 이를 6비트씩 나눕니다.
   • 010011
   • 010110
   • 000101
   • 101110
5. 각 6비트를 10진수 값으로 바꿉니다.
   • 010011 = 19
   • 010110 = 22
   • 000101 = 5
   • 101110 = 46
6. 각 값을 Base64 문자표에 대응시킵니다.
   • 19 → T
   • 22 → W
   • 5 → F
   • 46 → u
7. 최종 결과는 "TWFu"가 됩니다.

이 과정을 보면 Base64가  비트 단위 재배열과 문자 매핑만으로 동작한다는 것을 알 수 있습니다.

 

 

 

⁉️왜 3바이트가 4문자가 될까?

Base64를 이해할 때 가장 중요한 구조 중 하나가 바로 이것입니다. Base64는 6비트 단위로 데이터를 표현하는데, 원본 데이터는 8비트 단위입니다. 그러므로 계산해보면 다음과 같습니다.

1. 원본 3바이트는 3 × 8 = 24비트입니다.
2. Base64는 6비트씩 자르므로 24 ÷ 6 = 4입니다.
3. 따라서 3바이트 입력은 4개의 Base64 문자 출력으로 변환됩니다.

이 구조는 Base64 인코딩의 기본 패턴입니다. 입력 데이터가 길어지더라도 내부적으로는 계속 3바이트씩 처리되어 4문자씩 출력된다고 생각하시면 됩니다.

 

 

 

⬆️Base64인코딩을 하면 원본보다 데이터 크기가 커지는 이유

Base64를 처음 접하시는 분들 중에는 “이상한 문자열로 바뀌었으니 데이터가 줄어든 것 아닌가요?”라고 생각하시는 경우도 있습니다. 하지만 실제로는 반대입니다. Base64는 데이터를 압축하지 않습니다. 오히려 원본보다 약 33% 정도 크기가 증가합니다.

 

이유도 간단합니다.

1. 원본 3바이트가 있습니다.
2. Base64로 변환하면 4문자가 됩니다.
3. 이 4문자는 보통 ASCII 문자이므로 1문자당 1바이트로 생각할 수 있습니다.
4. 결과적으로 3바이트 → 4바이트가 됩니다.

증가율로 계산하면 다음과 같습니다.

• 증가한 크기: 4 - 3 = 1
• 원본 대비 증가율: 1 / 3 → 33.3%

즉 Base64는 전송 호환성을 얻는 대신, 크기 증가라는 비용을 지불하는 방식입니다. 그래서 대용량 파일을 Base64로 감싸서 JSON에 넣는 방식은 실무에서 꽤 비효율적일 수 있습니다.

 

 

 

🟰 = 패딩 붙는 이유

Base64는 기본적으로 3바이트 단위로 처리됩니다. 그런데 입력 데이터 길이가 항상 3의 배수는 아닙니다. 예를 들어 마지막에 1바이트만 남거나 2바이트만 남을 수 있습니다. 이때 등장하는 것이 = 패딩입니다.

 

1바이트만 남는 경우

예를 들어 "M" 하나만 있다고 가정하겠습니다.

1. M의 ASCII 값은 77입니다.
2. 2진수로는 01001101입니다.
3. Base64는 6비트 단위로 잘라야 하는데, 현재는 8비트뿐입니다.
4. 부족한 비트는 0으로 채워 계산합니다.
5. 그리고 원래 데이터가 부족했다는 사실을 표시하기 위해 결과 뒤에 ==를 붙입니다.

결과는 "TQ=="가 됩니다.

 

 

2바이트가 남는 경우

이번에는 "Ma"를 보겠습니다.

1. M = 01001101
2. a = 01100001
3. 합치면 16비트입니다.
4. 6비트 단위로 자르면 마지막 그룹이 부족합니다.
5. 부족한 부분은 0으로 채웁니다.
6. 마지막이 완전한 3바이트가 아니었다는 것을 나타내기 위해 = 하나를 붙입니다.

결과는 "TWE="가 됩니다.

즉 =는 실제 데이터가 아니라, 마지막 블록이 덜 찼다는 것을 알려주는 표시입니다. 디코딩하는 쪽에서는 이 패딩을 보고 원래 데이터 길이를 정확히 복원할 수 있습니다.

 

 

 

🔸암호화와 Base64 인코딩의 차이

Base64는 암호화가 아닙니다. 단지 표현 방식이 바뀐 것뿐입니다.

결과 문자열이 바로 읽기 어렵다는 이유로 암호화처럼 보일 수는 있습니다. 하지만 Base64는 누구나 규칙만 알면 즉시 원래 데이터로 복원할 수 있습니다. 예를 들어 SGVsbG8=라는 값을 보면 얼핏 복잡해 보이지만, Base64 디코딩을 해보면 바로 "Hello"가 나옵니다. 별도의 키가 필요한 것도 아니고, 보안성을 제공하는 것도 아닙니다.

암호화와 Base64의 차이는 다음처럼 정리할 수 있습니다.

1. 암호화는 키가 있어야 합니다.
2. 암호화는 키 없이는 원문을 알기 어렵도록 만드는 것이 목적입니다.
3. Base64는 키가 필요 없습니다.
4. Base64는 단지 바이트를 텍스트로 표현할 뿐입니다.
5. Base64는 보안 수단이 아닙니다.

따라서 민감한 정보를 Base64로 바꾸어 저장한다고 해서 안전해지는 것은 아닙니다. 눈에 잘 안 들어올 뿐, 사실상 누구나 복원할 수 있는 값입니다.

 

 

🔹UTF-8 같은 문자 인코딩과 Base64 인코딩의 차이

Base64와 UTF-8은 둘 다 인코딩이라는 말을 사용하지만, 완전히 다른 변환의 문제를 해결합니다. 이 부분은 실무에서 가장 많이 혼동되는 지점 중 하나입니다.

 

앞서 말한 것처럼 UTF-8은 문자를 바이트로 바꾸는 규칙입니다. 예를 들어 "가"라는 문자는 UTF-8에서 특정 바이트 조합으로 저장됩니다. 반면 Base64는 그렇게 만들어진 바이트를 다시 안전한 ASCII 문자열로 바꾸는 규칙입니다.

 

즉 문자열이 Base64로 바뀐다고 말할 때 실제 내부 흐름은 다음과 같습니다.

1. 먼저 원본 문자열이 있습니다.
2. 문자열을 UTF-8 같은 문자 인코딩으로 바이트열로 바꿉니다.
3. 그 바이트열을 Base64 규칙으로 다시 문자열화합니다.

예를 들어 "A"라는 문자열을 Base64로 바꾼다면 실제로는 다음과 같은 흐름입니다.

1. 문자 'A'
2. UTF-8 인코딩 → 바이트 0x41
3. Base64 인코딩 → "QQ=="

즉 "QQ=="는 문자 'A' 자체를 직접 바꾼 것이 아니라, 0x41이라는 바이트를 Base64로 표현한 결과입니다.

 

 

 

✅Base64는 어디에서 사용될까?

Base64는 생각보다 다양한 곳에서 사용됩니다. 공통점은 대부분 텍스트 기반 환경에 바이너리를 넣어야 하는 상황이라는 점입니다.

 

① 이메일 첨부파일

이메일은 전통적으로 텍스트 중심 프로토콜입니다. 이미지나 PDF 같은 첨부파일을 넣으려면 바이너리를 그대로 보내기 어려웠기 때문에 MIME과 Base64가 함께 사용됩니다.

 

② JSON 안에 바이너리 데이터 포함

JSON은 텍스트 포맷이므로 바이너리 자체를 직접 넣을 수 없습니다. 그래서 작은 파일, 이미지, 서명값, 인증 관련 값 등을 문자열 필드에 넣고 싶을 때 Base64로 변환해서 전달합니다.

예를 들어 API 요청 본문에 이런 식으로 들어갈 수 있습니다.

{
  "filename": "sample.png",
  "content": "iVBORw0KGgoAAAANSUhEUgAA..."
}

 

③ Data URI

HTML이나 CSS에서 외부 이미지 파일을 따로 참조하지 않고, 문서 안에 직접 넣고 싶을 때 Base64를 사용합니다.

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

 

④ JWT

JWT는 정확히는 Base64가 아니라 Base64URL을 사용합니다. 하지만 본질적으로는 같은 계열의 인코딩 방식입니다. 헤더, 페이로드, 서명이 각각 Base64URL로 표현됩니다.

 

⑤ 인증서와 키 파일

PEM 형식의 인증서나 공개키, 개인키 파일을 열어보면 본문이 긴 문자열로 들어 있는데, 이 부분 역시 Base64입니다.

 

 

 

⚠️실무에서 흔히 보이는 “문자열 Base64 인코딩”

실무에서 보면 위에 내용과는 다르게 문자열을 Base64 인코딩 하는 경우도 더러 볼 수 있습니다.

실무에서 “문자열을 Base64 인코딩한다”라고 말하는 경우도, 실제로는 문자열 자체를 다루는 게 아니라 그 문자열이 바이트로 변환된 결과를 Base64로 인코딩하는 것입니다.

즉 겉으로는 문자열을 Base64 인코딩하는 것처럼 보이지만, 내부적으로는 여전히

문자열 → 바이트 → Base64 문자열

이 흐름입니다.

 

 

예를 들어 "안녕하세요"를 Base64 인코딩한다고 해보겠습니다.

실제로는 이렇게 됩니다.

1. 원본 문자열: "안녕하세요"
2. UTF-8로 바이트 변환
3. 그 바이트를 Base64 인코딩
4. 결과 문자열 생성

즉 입력은 문자열이지만, Base64가 처리하는 대상은 결국 UTF-8 바이트입니다.

 

 

1️⃣실무에서 “문자열 Base64 인코딩”이 많은 것처럼 보이는 이유

이렇게 느껴지는 이유는 두 가지입니다.

 

첫째, 문자열이 가장 흔한 입력 형태이기 때문입니다

개발자는 보통 코드에서 문자열을 많이 다룹니다.

예:

• JSON 문자열
• 사용자 입력 문자열
• 토큰 문자열
• 인증 정보 문자열

그래서 코드상으로는 string -> base64처럼 보입니다.

하지만 내부적으로는 항상:

• string
• UTF-8 bytes
• base64 string

순서입니다.

 

둘째, 결과를 다시 문자열로 써야 하는 경우가 많기 때문입니다

HTTP 헤더, JSON 필드, DB varchar 컬럼, 로그, 설정 파일 등은 대개 문자열 중심입니다.

즉 원본이 바이트라도 최종 저장/전송 매체가 문자열이기 때문에 Base64를 많이 보게 됩니다.

그래서 실무에서는 “Base64는 바이너리용”이라고 설명하면서도, 정작 코드에서는 문자열을 넣는 모습이 흔하게 보이는 것입니다.

 

 

2️⃣ “문자열 Base64 인코딩” 사용하는 이유

그럼 왜 굳이 문자열을 또 Base64로 바꿀까요? 문자열이면 그냥 문자열로 보내면 되지 않느냐는 의문이 생길 수 있습니다.
맞습니다. 일반 텍스트 문자열이라면 굳이 Base64로 바꿀 필요가 없는 경우가 많습니다.
그런데 실무에서는 아래 같은 이유로 문자열을 Base64로 바꾸는 경우가 있습니다.

 

① 안전한 문자 집합으로 맞추기 위해

문자열 안에 다음 같은 문자가 있을 수 있습니다.

• 줄바꿈
• 탭
• 공백
• 한글
• 이모지
• 특수문자
• 제어문자

이런 값들은 어떤 시스템에서는 다루기 까다롭거나, 중간에서 깨질 수 있거나, 포맷 충돌을 일으킬 수 있습니다.

그래서 아예 문자열을 UTF-8 바이트로 만든 뒤 Base64로 바꾸면 결과는:

• 영문 대소문자
• 숫자
• +, /, =

정도의 제한된 안전 문자 집합으로만 구성됩니다.

즉, 원본 문자열이 복잡하더라도 안전한 ASCII 계열 문자열로 평탄화할 수 있습니다.

 

 

② 특정 필드가 “텍스트 한 줄”이어야 할 때

어떤 시스템은 값을 한 줄 문자열로만 받는데, 실제 값 안에는 줄바꿈이나 특수문자가 포함될 수 있습니다.

 

예시)

• PEM 인증서 본문
• JSON 조각
• XML 조각
• 멀티라인 텍스트
• 서명 원문

이럴 때 Base64로 바꾸면 줄바꿈이나 특수문자 문제를 피하고 한 줄 텍스트로 보낼 수 있습니다.

 

 

③ JSON/XML/쿼리스트링에 넣기 쉽게 만들기 위해

어떤 문자열은 직접 넣으면 escaping이 번거롭습니다.

예를 들어 JSON 안에 아래 문자열을 넣는다고 생각해보겠습니다.

{"name":"홍길동","message":"hello\nworld"}

 

이걸 그대로 다른 포맷 안에 다시 넣으려면

• 따옴표 이스케이프
• 줄바꿈 이스케이프
• 문자셋 문제

등을 신경 써야 합니다.

그런데 Base64로 바꾸면 그냥 평범한 영숫자 문자열처럼 다룰 수 있습니다.

 

 

👍Base64의 장점

Base64는 오래된 방식이지만 지금도 널리 사용되는 데에는 분명한 이유가 있습니다.

 

첫째, 텍스트 기반 시스템과의 호환성이 뛰어납니다. ASCII 중심 환경에서도 비교적 안전하게 다룰 수 있는 문자만 사용하기 때문에 전송이 안정적입니다.

 

둘째, 구현이 단순합니다. Base64는 매우 표준화되어 있고, 거의 모든 언어와 프레임워크에서 기본적으로 지원합니다. Java, C#, JavaScript, Python 등 대부분의 언어에서 라이브러리 없이도 쉽게 처리할 수 있습니다.

 

셋째, 바이너리 데이터를 직렬화된 텍스트 포맷 안에 넣기 쉽습니다. JSON, XML, 이메일, 로그, 메시지 큐 등에 바이너리를 넣어야 할 때 유용합니다.

 

넷째, 복사와 붙여넣기가 쉽습니다. 바이너리 그대로는 눈으로 다루기 어려우나, Base64 문자열은 텍스트처럼 취급할 수 있어 전달과 저장이 편리합니다.

 

 

 

👎Base64의 단점

물론 장점만 있는 것은 아닙니다. 실무에서는 Base64의 단점도 분명히 알고 사용하셔야 합니다.

 

첫째, 크기가 증가합니다. 앞서 설명드린 것처럼 원본보다 약 33% 커집니다. 그래서 대용량 파일을 Base64로 감싸면 네트워크 트래픽과 메모리 사용량이 증가합니다.

 

둘째, 인코딩과 디코딩 비용이 발생합니다. 아주 큰 비용은 아니지만, 고성능 환경이나 대용량 처리 구간에서는 무시할 수 없습니다.

 

셋째, 큰 파일에는 비효율적입니다. 특히 JSON 안에 Base64 문자열로 대형 바이너리를 넣는 방식은 다음과 같은 문제를 일으킬 수 있습니다.

1. 전송량 증가
2. 메모리 사용량 증가
3. 파싱 비용 증가
4. 클라이언트와 서버 양쪽의 처리 부담 증가

그래서 실무에서는 작은 바이너리 데이터에는 Base64를 쓰더라도, 큰 파일은 보통 멀티파트 업로드나 스트리밍, 혹은 파일 스토리지 업로드 후 URL 전달 방식으로 분리하는 경우가 많습니다.

 

 

 

➕추가적으로 URL-safe Base64

일반 Base64는 +, /, = 같은 문자를 사용합니다. 그런데 이 문자들은 URL, 파일명, 쿼리스트링 등에서는 불편할 수 있습니다. 예를 들어 +는 공백처럼 처리될 수 있고, /는 경로 구분자로 해석될 수 있습니다.

그래서 URL 환경에서 사용하기 쉽게 약간 변형한 것이 Base64URL입니다. 규칙은 단순합니다.

1. +를 -로 바꿉니다.
2. /를 _로 바꿉니다.
3. = 패딩은 생략하기도 합니다.

JWT가 바로 이 Base64URL을 사용하는 대표적인 사례입니다. 그래서 JWT를 보면 일반 Base64와 비슷하면서도 +, /, =가 잘 보이지 않는 이유가 여기에 있습니다.

 

 

 

✨마무리

Base64는 오래된 개념이지만, 지금도 백엔드 실무에서 매우 자주 등장하는 중요한 기본기입니다. 기술 자체는 단순해 보이지만, 어디에 쓰이고 왜 필요한지, 어떤 원리로 동작하는지, 무엇과 혼동하면 안 되는지를 정확히 이해하고 계시는지에 따라 설계와 디버깅의 질이 달라집니다.

결국 Base64의 본질은 명확합니다. 내용을 숨기는 기술이 아니라, 바이너리 데이터를 텍스트 기반 환경에서도 안전하게 전달할 수 있도록 표현 방식을 바꾸는 기술입니다. 이 관점을 정확히 잡고 계시면, 앞으로 Base64를 만날 때마다 훨씬 선명하게 이해하실 수 있을 것입니다.