웹 성능 최적화: Base64 인코딩으로 HTTP 요청 줄이기와 그 한계

1 August 2025

Update: 14 January 2026

웹 개발을 하거나 브라우저 소스 코드를 분석하다 보면 이미지가 있어야 할 자리에 외계어처럼 보이는 긴 텍스트가 포함된 코드를 마주할 때가 있다. 바로 <img src="data:image/png;base64,iVBORw0KGgo...">와 같은 형태다. 처음 접하면 오류처럼 보일 수 있지만, 이는 web 성능 최적화를 위해 사용되는 매우 전략적인 기술인 Base64 인코딩이다. 이 글에서는 Base64 이미지의 정체가 무엇인지, 그리고 실무에서 이를 언제 적용해야 성능 이득을 볼 수 있는지 철저히 분석한다.

Base64 인코딩의 매커니즘과 Data URI Scheme

Base64는 이진 데이터(Binary Data)를 64개의 출력 가능한 ASCII 문자로 변환하는 인코딩 방식이다. 이를 Data URI Scheme이라고 부르며, 이미지 파일을 별도의 파일로 로드하는 대신 HTML이나 CSS 파일 내부에 문자열 형태로 직접 포함시킬 수 있게 해준다.

기술적 배경: 브라우저는 HTML 파싱 중 외부 이미지 링크(URL)를 만나면 서버에 해당 파일을 요청(Request)하고 응답(Response)을 기다린다. Base64를 사용하면 이 네트워크 왕복 시간(RTT)을 제거할 수 있다.

왜 사용하는가? HTTP 요청 감소 전략

과거 HTTP/1.1 환경에서는 브라우저가 도메인당 동시에 맺을 수 있는 커넥션 수에 제한이 있었다. 수십 개의 작은 아이콘을 로딩하기 위해 수십 번의 핸드쉐이크를 맺는 것은 엄청난 오버헤드였다. 이때 Base64 인코딩을 사용하면 이미지가 HTML 문서의 일부가 되므로, 별도의 HTTP 요청 없이 즉시 렌더링이 가능하다. 이는 LCP(Largest Contentful Paint) 지표 개선에 긍정적인 영향을 줄 수 있다.

주의: HTTP/2가 보편화된 현재, 멀티플렉싱(Multiplexing) 기술 덕분에 다수의 작은 요청 처리가 효율적으로 변했다. 따라서 무조건적인 Base64 변환은 오히려 독이 될 수 있다.

치명적인 단점: 파일 크기 증가와 캐싱 문제

Base64 인코딩의 가장 큰 단점은 파일 크기가 원본 대비 약 33% 증가한다는 점이다. 3바이트의 이진 데이터를 4바이트의 문자로 변환하기 때문이다. 또한, 이미지가 HTML/CSS에 박제되므로 브라우저의 강력한 이미지 캐싱 기능을 활용하기 어렵다. HTML이 변경되어 다시 로드될 때마다 이미지 데이터도 매번 다시 다운로드해야 한다.

구현: 이미지를 Base64로 변환하기

실무에서는 빌드 타임(Webpack, Vite 등)에 자동으로 변환하지만, 개념 이해를 위해 Python으로 변환하는 로직을 살펴본다. 서버 사이드 렌더링(SSR) 시 유용하게 사용될 수 있다.

import base64

def image_to_base64(image_path):
    # 바이너리 모드로 파일 읽기
    with open(image_path, "rb") as image_file:
        # Base64 인코딩 수행
        encoded_string = base64.b64encode(image_file.read())
        
        # UTF-8 문자열로 디코딩하여 HTML에 삽입 가능한 형태 반환
        return f"data:image/png;base64,{encoded_string.decode('utf-8')}"

# 사용 예시
img_src = image_to_base64("./icon_sample.png")
print(f'<img src="{img_src}" />') 
# 결과: <img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." />

결정 매트릭스: 언제 써야 할까?

무분별한 사용을 막기 위해, 우리는 프로덕션 환경에서 다음과 같은 기준을 적용한다. 핵심은 web 리소스의 성격을 파악하는 것이다.

사용 권장 (O)	사용 금지 (X)
1KB 미만의 매우 작은 아이콘	10KB를 초과하는 일반 이미지
Critical Rendering Path에 포함된 로고	사용자 프로필 사진 등 동적인 이미지
플레이스홀더 (Lazy Loading 전 보여줄 흐릿한 이미지)	자주 변경되지 않아 캐싱이 유리한 정적 자산

Conclusion

Base64 인코딩은 마법의 지팡이가 아니다. HTTP 요청을 줄여 초기 로딩 속도를 미세하게 개선할 수 있지만, 파일 크기 증가와 캐싱 불가능이라는 명확한 트레이드오프가 존재한다. 현대적인 웹 개발에서는 SVG 스프라이트나 HTTP/2를 우선 고려하되, 아주 작은 용량의 필수 에셋이나 LCP 최적화용 플레이스홀더에만 제한적으로 Base64를 사용하는 것이 정석이다.

Base64 frontend http ko optimization WebPerformance