프론트엔드에게 배포플랫폼이란 - 2024 당근 테크 밋업

당근 테크 밋업 영상을 보고 내용 위주로 정리하였습니다.

🌐 HTML

• 웹페이지에서 가장 중요한 요소는 브라우저에 표시되는 내용을 결정하는 HTML이다.
• 사용자가 로컬에서 HTML 파일에 접근하면 브라우저가 직접 열 수 있지만 리모트 서버에 있는 HTML에 접근하기 위해서는 리모트 URL로 접근해야 한다. (* 리모트 URL : 외부에 위치한 HTML을 가리키는 경로)
• 로컬에서는 파일 프로토콜을 통해 HTML을 요청, 리모트에서 접근할 때는 HTTP 프로토콜을 사용하여 요청한다.
  (*프로토콜: 컴퓨터와 컴퓨터 사이, 또는 한 장치와 다른 장치 사이에서 데이터를 원활히 주고받기 위하여 약속한 여러 가지 규약)

📦  배포의 정의 및 성공적인 배포의 조건

배포란?

1. 사용자와 개발자가 만나는 지점.

2. HTML 위치를 탐색하고 HTML을 요청하고 HTML스펙이 동작을 보장하는 것.

 

성공적인 배포는?

로컬 파일 생성 후 브라우저를 통해 확인할 수 있는 위의 세 가지 동작이 충족되어야 한다.

✅  정적 웹사이트와 동적 웹사이트의 배포 플랫폼 구성 요소

정적 웹사이트

- 내용이 변하지 않는 HTML 콘텐츠.

- 리모트 URL을 파악하고 HTTP GET 요청을 통해 HTML을 받아오는 방식으로 작동한다.
- 웹서버가 브라우저가 보낸 HTTP GET 요청을 처리함

 

정적 웹사이트는 웹 서버만으로 배포 플랫폼을 구축할 수 있다. (변하는 데이터가 없음)

 

동적 웹사이트

- 동적 웹사이트는 사용자마다 개인화된 콘텐츠를 제공하기 위해 동적인 처리가 필요하다.

 

- HTTP 요청을 받아서 동적인 작업을 처리하는 웹 애플리케이션 서버가 추가됨.

- 웹 애플리케이션 서버는 웹 서버와 협력하여 HTML을 동적으로 수정하고 응답함.

 

동적 웹사이트에서의 배포 플랫폼은 단순한 웹 서버뿐만 아니라, HTML을 동적으로 제어할 수 있는 웹 애플리케이션 서버가 함께 있어야 한다.

 

✅ SPA 동작 방식 및 배포 플랫폼 구성 요소

1. 웹 애플리케이션의 한계 

HTML을 새로 받아야 하기 때문에 UI/UX 측면에서 계속 새로고침이 발생하게 된다.

화면 표시와 데이터 처리에 강결합이 된다. 

 

2. AJAX 기술 등장

새로고침 없이 데이터를 받을 수 있는 방법을 제공한다.

웹 서버에서 HTML을 받아온 후, 브라우저는 데이터 전달을 위해 또 다른 웹 서버에 요청을 보내 데이터를 받을 수 있는 구조로 발전하게 된다.

 

🔥 AJAX 등장으로 SPA이 부상하게 되었으며, HTML 페이지는 JS와 CSS를 받아오는 통로로 동작하게 된다.

 

JS는 사용자와의 상호작용을 제어하고, 애플리케이션의 기능을 구현하면서 CSS스타일도 적용하게 되는데 빌드 도구를 통해 HTML에 JS와 CSS를 통합하게 된다.

 

 

SPA 배포 플랫폼 요구사항

- JS, CSS, AJAX 응답을 처리하는 웹 서버를 필요로 한다.

- 다만 SPA에서 서브 패스의 처리가 어려워지기 때문에  404 not found 발생 시 index.html 응답도 필요하다. 

✅ SPA 성능 최적화를 위한 캐시 관리

 

SPA는 사용자가 첫 화면을 보기 위한 대량의 HTML, JS, CSS요청을 하기 때문에 성능 우려가 있다. 

- SPA 구조에서는 JS와 CSS가 사용자의 인터랙션을 제어하고, HTML은 통로 역할을 하여 필요한 데이터가 동적으로 로드되는데, 이 과정에서 복잡한 HTTP 요청이 발생하여 워터폴 현상이 발생할 수 있게 됨.

 

🤔 그럼 배포 플랫폼에서 어떻게 성능을 최적화할 수 있을까?

HTTP 요청을 통해 응답 헤더를 설정하여, 성능을 최적화할 수 있다. 

아래 이미지처럼 여러 응답헤더들이 있는데 그 중 Cache-Control를 사용해서 성능을 최적화할 수 있음.

 

🤔 Cache-Control로 성능 최적하기 위한 방법은? 

Cache-Control는 기존에 받았던 HTML이나 JS, CSS를 재활용하는 일종의 캐싱 정책을 뜻하는데 

예를 들어 max-age를 60초로 설정하면 60초간 웹 서버를 통하지 않고 바로 HTML을 받아올 수 있어 성능이 향상된다.

JS에서도 동일하게 적용할 수 있는데 max-age=600으로 설정하면 600초 동안 캐시 된다. 

 

🤔 그럼 새로 배포를 했을 때 max-age 값이 설정되어 있으면 만료될 때까지 기다려야 하는가? 

 

• HTML 파일에 max-age를 설정하면 새로운 배포 시에도 브라우저가 캐시된 HTML을 사용하여 변경 사항이 사용자에게 즉시 반영되지 않을 수 있다.
• 따라서 보통 HTML 파일에는 캐싱을 제한 (no-store) 하고, JS  해시를 사용한 캐싱 전략을 적용하는 것이 일반적이다. 
  • JS의 파일명은 hash로 구분되는데, 캐싱 값을 불러오는 키로 파일명을 사용하기 때문에 파일명이 다르면 캐싱으로부터 자유로워짐. 
    • 파일 내용이 변경되지 않으면 해시가 동일하므로 브라우저는 캐시 된 파일을 사용하여 로딩 속도를 향상함.
    • 파일 내용이 변경되면 해시가 변경되어 브라우저가 새로운 파일로 인식하고 서버에서 최신 파일을 받아옴

 

 

이전 배포 플랫폼에서는 배포 버전이 없었지만 배포 버전을 필요로 하게 된다.

예를 들어 새로운 배포 시 이전 버전의 HTML이 새로운 JS 파일을 로드하려 하면 404 에러가 발생할 수 있음.
ex) index.foo.js에서 index.bar.js로 변경되었을 때, HTML이 이전 버전의 JS를 로드하면 파일을 찾지 못함.

 

 

그럼 앞서 제시한 SPA 배포 플랫폼에서 성능 최적화가 추가된 배포 플랫폼이 되기 위해서 버전 정책이 추가된다. 

 

SPA 배포 플랫폼 요구사항

- [기존] JS, CSS, AJAX 응답을 처리하는 웹 서버를 필요로 한다.

- [기존] 다만 SPA에서 서브 패스의 처리가 어려워지기 때문에  404 not found 발생 시 index.html 응답도 필요하다. 

- [추가] Cache-Control 사용 시, 캐싱 정책에 따른 버전 정책이 필요하다. 

 

 

🔥 CDN 도입

 

CDN을 활용하여 배포 플랫폼을 더욱 개선할 수 있다. 

 

• CDN은 HTML응답을 로컬 서버가 아닌 물리적으로 더 가까운 서버에서 받아오는 방식으로, 응답 속도를 최적화할 수 있다.
• 요청이 필요할 때 캐시된 응답을 제공함으로써 HTTP 응답 속도를 개선하는 역할을 한다.
• 새로운 배포 시 CDN 퍼지를 통해 캐싱을 무효화할 수 있다.

++ CDN은 SPA뿐만 아니라 정적 웹사이트의 성능 최적화에도 적용 가능하다.

✅ 결론

 

- 복잡해 보이는 개념들도 기본적인 요소들의 조합을 통해 충분히 구현하고 이해할 수 있다.

- 프론트엔드 배포 플랫폼은 렌더링 이후만 보면 단순해 보일 수 있지만, 렌더링 이전의 세계, 즉 웹 시스템을 고려하면 그 중요성은 매우 크다.