프로그레시브 웹 앱의 특징
일반적인 웹 브라우저 애플리케이션과 노트북이나 휴대폰에 설치된 앱의 차이를 생각해 보면 프로그레시브 웹 앱의 가치를 알 수 있다. 설치형 앱의 가장 큰 특징은 네트워크에 연결하지 않아도 기기에서 실행된다는 점이다. 프로그레시브 웹 앱은 브라우저 내에서 유사한 오프라인 기능을 지원한다. 또한 프로그레시브 웹 앱은 브라우저 기반 웹 애플리케이션과 달리 애플리케이션 유형에 따라 크게 달라지며, 애플리케이션의 기능이 구현 방식을 결정하는 데 큰 역할을 한다.프로그레시브 웹 앱의 일반적인 특징은 다음과 같다.
- 오프라인 기능
- 동기화를 포함한 백그라운드 기능
- 홈페이지 "설치" 가능
- 앱이 실행되고 있지 않을 때를 포함한 푸시 알림 및 경고
- 공격적인 캐싱을 통해 간헐적인 네트워크 문제를 해결
- 다양한 기기를 지원하는 반응형 모바일 우선 레이아웃
- 링크를 통해 북마크 및 공유 가능
프로그레시브 웹 앱의 좋은 사용례는 웹에 배포된 애플리케이션을 전환해 오프라인과 같은 기능을 구현하는 것이다. 예를 들어 구글 문서 도구는 네트워크를 사용할 수 없을 때 '오프라인 모드'를 지원하는 브라우저 기반 앱이다. 기본적으로 이 앱은 모든 내용을 브라우저에 로컬로 저장한 다음 브라우저가 다시 온라인 상태가 되면 백엔드와 동기화한다. 물론 앱의 분산된 부분을 동기화하는 것은 본질적으로 복잡하다. 구글 문서 도구는 이를 정교한 아키텍처로 구현한다. 하지만 기본적인 애플리케이션은 훨씬 더 간단하다. 결과적으로 애플리케이션의 요구 사항에 따라 프로그레시브 웹 앱 구현 작업의 복잡성이 결정된다.
이제 프로그레시브 웹 앱이 어떤 기능을 제공하는지 이해했으니, 작동 방식을 살펴보자.
프로그레시브 웹 앱 설치하기
프로그레시브 웹 앱의 특징은 브라우저에서 실행하더라도 '설치'가 가능하다는 점이다. 프런트엔드에서 기기 홈페이지에 링크를 넣으면 브라우저에서 웹 사이트가 실행된다. 이런 설치 작업은 브라우저에 앱의 기능과 홈페이지 아이콘을 알려주는 manifest.json 파일을 통해 이뤄진다. 다음은 간단한 매니페스트의 예다."name": "My PWA App",
"short_name": "My PWA",
"icons": [
{
"src": "icons/icon-192x192.png",
"sizes": "192x192",
"type": "image/png"
}
],
"start_url": "/",
"display": "standalone",
"theme_color": "#ffffff"
}
브라우저가 루트 디렉터리에서 해당 파일을 발견하고 파일이 유효하면 홈페이지 링크를 추가하는 방식으로 작동한다.
서비스 워커
서비스 워커는 프로그레시브 웹 앱 기능을 제공하는 주요 수단이다. navigator.serviceWorker 객체를 사용하면 서비스 워커 API에 액세스할 수 있다. 보안(HTTPS) 컨텍스트에서만 사용할 수 있다. 서비스 워커는 워커 스레드(worker thread)와 비슷하지만 수명이 더 길고 DOM, 브라우저 API에 대한 액세스 권한이 더 적다.서비스 워커는 메시지와 이벤트를 통해 메인 스레드나 다른 워커와 상호 작용할 수 있는 격리된 컨텍스트라고 생각하면 된다. 이런 이벤트에 응답하고, 네트워크 요청을 실행하고, 푸시 호출에 응답하고, 캐시 API 또는 IndexedDB에 저장한다. 서비스 워커는 메인 스레드로 돌아오는 메시지를 통해서만 UI에서 작업할 수 있다. 어떤 의미에서 서비스 워커는 브라우저에서 실행되는 프록시 미들웨어다.
서비스 워커에는 고유한 수명 주기가 있다. 특정 조건에 따라 종료 시기가 결정된다. 서비스 워커는 이를 생성한 페이지가 닫힌 후에도 푸시 업데이트를 기반으로 사용자에게 알림을 실행하고 표시한다. 더 자세한 내용은 서비스 워커 수명 주기를 참고하면 된다. 크롬 같은 브라우저별 서비스 워커 종료 정보도 찾을 수 있다.
서비스 워커 이벤트
기본적으로 서비스 워커는 비동기 이벤트 처리기다. UI 또는 백엔드에서 이벤트에 응답한다. 이벤트 간에 공유할 로컬 변수에 상태를 저장할 수 없고 캐시나 데이터베이스를 사용하므로 이벤트 간에 컨텍스트가 지워질 수 있도록 설계해야 한다. 다음은 서비스 워커가 응답할 수 있는 모든 이벤트다.- install : 이 이벤트는 서비스 워커가 처음 설치될 때 한 번 발생한다. 오프라인 기능을 활성화하기 위해 HTML, CSS, 자바스크립트 파일과 같은 자산을 미리 캐싱하는 데 자주 사용된다.
- activate : 이 이벤트는 서비스 워커가 활성화된 후에 발생한다. 이전 버전의 서비스 워커에서 캐시를 정리하거나 서비스 워커가 클라이언트(웹 페이지)를 제어할 때 사용한다.
- fetch : 이 이벤트는 제어되는 페이지가 네트워크에 요청할 때마다 발생한다. 이를 통해 서비스 워커는 메인 페이지에 대한 보이지 않는 중개자 역할을 수행해 요청을 가로채고 캐시된 버전을 제공하거나 완전히 처리하도록 요청을 수정할 수 있다.
- sync : 이 이벤트는 네트워크 연결이 안정적일 때 브라우저에서 정의한 간격으로 발생한다. 오프라인에서 변경된 데이터를 서버와 동기화하는 데 자주 사용한다. 이 API는 네트워크가 사용 가능할 때 처리하도록 자동화하는 데도 유용하다.
- push : 이 이벤트는 서비스 워커가 서버로부터 푸시 알림을 받을 때 발생한다. 이를 통해 서비스 작업자는 웹페이지가 닫혀 있어도 알림을 처리해 사용자에게 표시한다.
- notificationclick : 이 이벤트는 사용자가 표시된 푸시 알림을 클릭할 때 발생한다. 이 이벤트를 사용해 알림 상호 작용을 처리하고 사용자를 프로그레시브 웹 앱 내의 특정 페이지로 이동할 수 있다.
- error : 이 이벤트는 서비스 워커가 작동하는 동안 오류가 나타날 때 발생한다. 로깅 또는 디버깅 목적으로 사용할 수도 있다.
- broadcast와 post messages : 메인 스레드에서 자바스크립트 코드에 의해 특별히 발생하는 이벤트다. 서비스 워커에 데이터를 전달하는 데 사용한다.
서비스 워커는 이런 이벤트와 함께 다음과 같은 다양한 API에 액세스할 수 있다.
- IndexedDB : 쿼리를 지원하는 강력한 객체 저장소 데이터베이스다. 서비스 워커 인스턴스 사이에 존재하며 메인 스레드와 공유된다.
- Cache API : 이를 사용하면 요청 개체를 쉽게 가져와 응답을 저장할 수 있다. fetch 이벤트와 결합해 오프라인 모드에 대한 응답을 메인 스레드의 관점에서 캐시할 수도 있다. 캐시 전략에 대한 더 자세한 설명은 여기를 참고하면 된다.
- Fetch와 WebSocket API : 서비스 워커는 DOM에 대한 액세스 권한은 없지만 Fetch와 WebSocket API를 통해 네트워크에 대한 전체 액세스 권한을 가질 수 확보할 수 있다.
- Geolocation : 서비스 워커를 지리적 위치에 노출하고 서비스 워커에서 지리적 위치를 지원하는 방법에 대한 논의가 계속 진행 중이다.
서비스 워커 예제
서비스 워커는 항상 다음과 같이 navigator.serviceWorker 객체가 있는 자바스크립트 파일을 로드하는 것으로 시작한다.그런 다음 service-worker.js에서 이벤트 구독이 이루어진다. 예를 들어 fetch 이벤트를 감시하고 캐시 API를 사용하려면 다음과 같이 하면 된다.
const request = event.request;
const url = new URL(request.url);
// Try serving assets from cache first
event.respondWith(
caches.match(request)
.then((cachedResponse) => {
// If found in cache, return the cached response
if (cachedResponse) {
return cachedResponse;
}
// If not in cache, fetch from network
return fetch(request)
.then((response) => {
// Clone the response for potential caching
const responseClone = response.clone();
// Cache the new response for future requests
caches.open('my-cache')
.then((cache) => {
cache.put(request, responseClone);
});
return response;
});
})
);
});
서비스 워커가 로드되면 self가 이를 참조한다. addEventListener 메서드를 사용하면 다양한 이벤트를 감시할 수 있다. fetch 이벤트 내에서 캐시 API를 사용해 주어진 요청 URL이 이미 캐시돼 있는지 확인하고, 캐시돼 있다면 다시 전송하는 것도 가능하다. URL이 새 URL인 경우 서버에 요청을 한 후 응답을 캐시한다. 캐시 API는 같은 요청인지 판단하는 데 있어 많은 복잡성을 제거한다. 서비스 워커를 사용하면 이 모든 것이 메인 스레드에 투명하게 표시된다.
브라우저 보편성과 네이티브 기능성의 결합
프로그레시브 웹 앱을 사용하면 브라우저에서 앱을 제공하고 일반적인 브라우저 기반 애플리케이션에서는 불가능한 기능을 제공할 수 있다. 반면 프로그레시브 웹 앱을 개발할 때는 더 복잡한 문제를 처리해야 한다. 프로그레시브 웹 앱으로 할 수 있는 네이티브와 유사한 작업 대부분에는 서비스 워커가 필요하며, 이는 안드로이드나 맥OS와 같은 운영체제를 사용하는 네이티브 앱에서 하는 것보다 더 많은 작업이 필요하다.반면 프로그레시브 웹 앱 기술을 사용해 브라우저를 통해 여러 플랫폼에서 같은 기능을 구현하는 것은, 여러 플랫폼에 맞춰 기능을 다시 구현하는 것보다 작업량이 적다. 프로그레시브 웹 앱을 사용하면 하나의 코드베이스만 빌드하고 유지 관리하면 되며 익숙한 브라우저 표준으로 작업할 수 있다.
editor@itworld.co.kr
Sponsored
Seagate
“작지만 큰 영향력” 하드 드라이브의 나노 스케일 혁신
ⓒ Seagate 플래터당 3TB라는 전례 없는 드라이브 집적도를 자랑하는 새로운 하드 드라이브 플랫폼이 등장하며 디지털 시대의 새로운 이정표를 세웠다. 플래터당 3TB를 저장할 수 있다는 것은 동일한 면적에서 스토리지 용량을 기존 드라이브 대비 거의 두 배로 늘릴 수 있다는 것을 의미한다. 이러한 혁신은 데이터 스토리지의 미래와 데이터센터의 디지털 인프라에 괄목할 만한 영향을 미친다. AI의 발전과 함께 데이터의 가치가 그 어느 때보다 높아졌다. IDC에 따르면 2027년에는 전 세계에서 총 291ZB의 데이터가 생성될 것으로 예측되며, 이는 스토리지 제조 용량의 15배 이상일 것으로 보인다. 대부분의 데이터를 호스팅하는 대형 데이터 센터에 저장된 데이터 중 90%가 하드 드라이브에 저장된다. 즉, AI 애플리케이션의 주도로 데이터가 급증함에 따라 물리적 공간을 늘리지 않으면서도 데이터를 저장할 수 있는 스토리지 기술 혁신이 필요하다. 데이터 스토리지 인프라를 업그레이드하는 것은 단순히 기술적인 문제가 아니라 지금 시대가 직면한 규모, 총소유비용(TCO), 지속가능성이라는 과제에 대한 논리적 해답인 셈이다. 열 보조 자기 기록(HAMR) 기술은 선구적인 하드 드라이브 기술로 드라이브 집적도 향상을 위해 지난 20년 동안 수많은 연구를 거쳐 완성되어 왔다. 씨게이트 모자이크 3+ 플랫폼은 이러한 HAMR 기술을 씨게이트만의 방식으로 독특하게 구현한 것으로, 미디어(매체)부터 쓰기, 읽기 및 컨트롤러에 이르는 복잡한 나노 스케일 기록 기술과 혁신적인 재료 과학 역량을 집약한 결정체다. 이 플랫폼은 데이터 비트를 변환하고 자기 및 열 안정성을 유지하면서 더욱 촘촘하게 패킹해서 각 플래터에 훨씬 더 많은 데이터를 안정적이고 효율적으로 저장할 수 있다. 예를 들어, 기존 데이터센터에 있는 16TB 드라이브를 30TB 드라이브로 업그레이드하면 동일한 면적에서 스토리지 용량을 두 배로 늘릴 수 있다. 더 낮은 용량에서 업그레이드한다면 상승 폭은 더욱 커진다. 이 경우, 테라바이트당 전력 소비량이 40% 감소하는 등 스토리지 총소유비용(TCO)이 크게 개선된다. 또한 효율적인 자원 할당과 재활용 재료 사용으로 운영 비용을 절감하고 테라바이트당 탄소 배출량을 55% 감소시켜 데이터센터가 지속 가능성 목표를 달성할 수 있다. 드라이브 집적도 향상은 하이퍼스케일과 프라이빗 데이터센터의 판도를 바꿀 수 있다. 데이터센터가 급증하며 전력사용량과 탄소배출량 역시 늘어나 데이터센터의 지속가능성이 화두가 되고 있는 가운데, 과학기술정보통신부는 ‘탄소중립 기술혁신 추진전략-10대 핵심기술 개발방향’에서 2030년까지 데이터센터 전력소모량을 20% 절감하겠다고 밝힌 바 있다. 이러한 목표에 발맞춰, 집적도를 획기적으로 개선한 대용량 데이터 스토리지를 활용하는 것은 원활하고 지속적인 AI 모델 학습, 혁신 촉진 및 비즈니스 성공을 위해 필수적이다. 엔터프라이즈 데이터센터의 경우 제한된 공간, 전력, 예산에 맞춰 확장할 수 있는 지속 가능한 방법을 찾아야 한다. 하드 드라이브의 집적도 혁신은 점점 더 커져가는 클라우드 생태계와 AI 시대에 대응하는 해답이자, 동일한 공간에 더 많은 엑사바이트를 저장하면서도 자원 사용은 줄이도록 인프라를 확장할 수 있는 방법이다. 이는 글로벌 데이터 영역에서 경쟁력을 유지하고 글로벌 디지털 경제의 선두주자로서 입지를 강화하는 데 매우 중요하다.
Seagate
'반박 불가' 하드 드라이브와 SSD에 관한 3가지 진실
ⓒ Getty Images Bank 하드 드라이브가 멸종할 것이라는 논쟁이 10년 넘게 계속되고 있다. 빠른 속도와 뛰어난 성능이 필요한 애플리케이션에 적합한 플래시 스토리지의 연매출이 증가하고 있는 것은 자명한 사실이다. 하지만, 클라우드의 보편화 및 AI 사용 사례의 등장으로 인해 방대한 데이터 세트의 가치가 높아지는 시대에 하드 드라이브는 플래시 스토리지로 대체할 수 없는 가치를 가지고 있다. 전 세계 엑사바이트(EB) 규모 데이터의 대부분을 저장하는 하드 드라이브는 데이터센터에서 그 어느 때보다 필수적이다. 전 세계 데이터 세트의 대부분이 저장된 엔터프라이즈 및 대규모 클라우드 데이터센터는 데이터 성장에서 핵심이 될 것이다. 하드 드라이브와 SSD를 비교하자면, 하드 드라이브 스토리지는 2022년에서 2027년 사이 6,996EB 증가할 것으로 예상되는 반면, SSD는 1,363EB 증가할 것으로 보인다. ⓒ Seagate 생성형 AI 시대에는 콘텐츠를 경제적으로 저장해야 하기 때문에 플래시 기술과 밀접하게 결합된 컴퓨팅 클러스터는 더 큰 하드 드라이브 EB의 다운스트림 수요를 직간접적으로 촉진할 것이다. 하드 드라이브가 왜 데이터 스토리지 아키텍처의 중심이 될 수밖에 없는지는 시장 데이터를 근거로 설명 가능하다. 가격 책정 근거 없는 믿음 : SSD 가격이 곧 하드 드라이브 가격과 같아질 것이다. 사실 : SSD와 하드 드라이브 가격은 향후 10년간 어느 시점에도 수렴하지 않을 것이다. 데이터가 이를 명확하게 뒷받침한다. 하드 드라이브는 SSD에 비해 테라바이트당 비용 면에서 확고한 우위를 점하고 있으며, 이로 인해 하드 드라이브는 데이터센터 스토리지 인프라의 확고한 주춧돌 역할을 하고 있다. IDC 및 포워드 인사이트(Forward Insights)의 연구에 따르면, 하드 드라이브는 대부분의 기업 업무에 가장 비용 효율적인 옵션으로 유지될 것으로 전망된다. 엔터프라이즈 SSD와 엔터프라이즈 하드 드라이브의 TB당 가격 차이는 적어도 2027년까지 6대 1 이상의 프리미엄이 유지될 것으로 예상된다. ⓒ Seagate 이러한 TB당 가격 차이는 장치 구입 비용이 총소유비용(TCO)에서 가장 큰 비중을 차지하는 데이터센터에서 특히 두드러지게 드러난다. 장치 구입, 전력, 네트워킹, 컴퓨팅 비용을 포함한 모든 스토리지 시스템 비용을 고려하면 TB당 TCO는 하드 드라이브 기반 시스템이 훨씬 더 우수하게 나타난다. ⓒ Seagate 따라서, 플래시는 특정 고성능 작업의 수행에 탁월한 스토리지이지만, 하드 드라이브는 당분간 안정적이고 비용 효율적이며 널리 채택된 솔루션을 제공하는 데이터센터에서 계속해서 주류로 사용될 것이다. 공급과 확장의 관계 근거 없는 믿음 : NAND 공급이 모든 하드 드라이브 용량을 대체할 정도로 증가할 수 있다. 사실 : 하드 드라이브를 NAND로 완전히 교체하려면 감당할 수 없는 설비투자(CapEx)가 필요하다. NAND 산업이 모든 하드 드라이브 용량을 대체하기 위해 공급을 빠르게 늘릴 수 있다는 주장은 재정적, 물류적으로 엄청난 비용이 발생한다는 점을 간과한 낙관적인 생각이다. 산업 분석기관 욜 인텔리전스(Yole Intelligence)의 2023년 4분기 NAND 시장 모니터 리포트에 따르면, 전체 NAND 산업은 2015년~2023년 사이 3.1제타바이트(ZB)를 출하하면서 총 매출의 약 47%에 해당하는 2,080억 달러의 막대한 자본 지출을 투자해야 했다. 반면, 하드 드라이브 산업은 데이터센터 스토리지 수요의 거의 대부분을 매우 자본 효율적인 방식으로 해결하고 있다. 씨게이트가 2015년~2023년 사이 3.5ZB의 스토리지를 출하하며 투자한 자본은 총 43억 달러로, 전체 하드 드라이브 매출의 약 5%에 불과하다. 그러나 NAND 산업의 경우 ZB당 약 670억 달러에 해당하는 금액을 투자한 것으로 나타나 하드 드라이브가 데이터센터에 ZB를 공급하는 것이 훨씬 더 효율적임을 알 수 있다. ⓒ Seagate 작업 부하 근거 없는 믿음 : 올 플래시 어레이(AFA)만이 최신 엔터프라이즈 작업 부하의 성능 요구를 충족할 수 있다. 사실 : 엔터프라이즈 스토리지 아키텍처는 일반적으로 디스크 또는 하이브리드 어레이, 플래시, 테이프를 사용하여 특정 작업 부하의 비용, 용량, 성능 요구 사항에 최적화할 수 있도록 미디어 유형을 혼합한다. 기업이 플래시 없이는 최신 작업 부하의 성능 수요를 따라잡지 못할 위험이 있다는 주장은 다음과 같은 3가지 이유로 반박 가능하다. 첫째, 대부분의 최신 작업 부하에는 플래시가 제공하는 성능상의 이점이 필요하지 않다. 전 세계 데이터의 대부분은 클라우드와 대규모 데이터센터에 저장되어 있으며, 이러한 환경에서는 작업 부하 중 극히 일부에만 상당한 성능이 필요하다는 파레토 법칙을 따르고 있다. 둘째, 예산 제약이 있고 데이터 세트가 빠르게 증가하는 기업들은 성능뿐만 아니라 용량과 비용의 균형을 맞춰야 한다. 플래시 스토리지는 읽기 집약적인 시나리오에서는 탁월한 성능을 발휘하지만 쓰기 작업이 증가하면 내구성이 떨어져 오류 수정과 오버프로비저닝에 추가 비용이 발생한다. 또한, 대규모 데이터 세트나 장기 보존의 경우 영역 밀도가 증가하는 디스크 드라이브가 더 비용 효율적인 솔루션일 뿐만 아니라 수천 개의 하드 드라이브를 병렬로 활용하면 플래시를 보완하는 성능을 달성할 수 있다. 셋째, 수많은 하이브리드 스토리지 시스템은 다양한 미디어 유형의 강점을 단일 유닛에 원활하게 통합하고 최대한으로 활용할 수 있도록 세밀하게 조정된 소프트웨어 정의 아키텍처를 사용한다. 이러한 스토리지는 유연성을 제공하므로 기업은 지속적으로 변화하는 요구 사항에 따라 스토리지 구성을 조정할 수 있다. AFA와 SSD는 고성능의 읽기 집약적인 작업에 매우 적합하다. 하지만 하드 드라이브가 이미 훨씬 낮은 TCO로 제공하는 기능을 AFA로 불필요하게 비싼 방법으로 제공하는 것은 비용 효율적이지 않을 뿐만 아니라, AFA가 하드 드라이브를 대체할 수 있다고 주장하는 근거가 될 수 없다.