#web
노트 82개
Frontend › CSS
CSS의 역사로 본 CSS가 어려워진 이유문서를 꾸미려고 만든 CSS가 웹 애플리케이션을 만들게 되면서 생긴 두 구조적 문제(전역 범위와 명시도)와, 이를 풀려고 등장한 시맨틱·Sass·BEM·Flexbox·CSS Modules·CSS-in-JS·유틸리티 CSS, 그리고 @layer·@scope·네이티브 중첩처럼 문제를 CSS 스스로 푸는 최근 스펙까지의 흐름을 정리했다.
Frontend › JavaScript
책임감 있는 자바스크립트JS는 압축해도 파싱·실행 비용이 그대로 남아 저사양 기기에서 가장 비싼 자원이다. 웹 플랫폼(HTML·CSS)을 먼저 쓰고, 트리 셰이킹·코드 분할·최신 문법 빌드·작은 대체재로 줄이고, 서드파티 스크립트는 담당자를 두고 관리한다. 성능은 저사양 Android와 느린 4G, 표준 지원은 Baseline으로 기준을 잡는다.
Frontend
Web브라우저가 문서를 해석하고 서버와 상태를 주고받는 웹의 기본 구조.
Frontend › Web
구조화된 콘텐츠와 기계가 읽는 웹음성 비서·검색 엔진·AI 답변 엔진은 웹 페이지를 그대로 보여 주지 않고 내용을 뽑아 합치고 추론한다. 화면에만 맞춘 마크업은 기계가 오해한다. 시맨틱 HTML로 관계를 드러내고, schema.org 어휘의 링크드 데이터(JSON-LD)로 개념의 의미를 붙이고, CMS가 구조를 강제하게 만들면 어떤 인터페이스에서도 정확한 답이 나간다.
Frontend › Web
다국어 페이지: lang·hreflang과 국제화여러 언어로 페이지를 제공할 때 언어마다 URL을 나누고 lang·dir·hreflang으로 표시하는 법, Accept-Language를 쓰되 강제로 넘기지 않는 언어 선택, 문자열 연결 금지·Intl API·텍스트 길이·방향·이미지 속 글자 같은 국제화 설계 주의점을 정리했다.
Frontend › Web
데이터 최소화와 프라이버시 실천개인정보는 모으지 않는 것이 가장 안전하다. 수집하지 않기 → 뭉개서 모으기(구간화·무작위 응답·차등 프라이버시) → 쓰고 지우기(Clear-Site-Data) → 왜 필요한지 설명하기 순으로 효과가 크고, 조직에서는 데이터 목록 문서화·정기 감사·목적 외 사용 차단으로 유지한다.
Frontend › Web
동영상 성능: 형식·poster·자동 재생·임베드동영상은 컨테이너와 코덱을 고르고 FFmpeg로 줄여 여러 source로 준다. 움직이는 GIF는 muted·loop·playsinline 자동 재생 video로 바꾼다. 사용자가 누를 동영상은 preload='none'과 poster, 화면 밖은 지연 로딩, 무거운 서드파티 플레이어는 퍼사드로 늦춘다. poster와 첫 프레임은 LCP 후보다.
Frontend › Web
리소스 힌트와 미리 불러오기: preconnect·preload·fetchpriority·Speculation Rules브라우저가 스스로 늦게 발견하는 자원을 앞당기는 힌트. 다른 출처 연결은 preconnect·dns-prefetch, 늦게 발견되는 중요한 자원은 preload, 우선순위는 fetchpriority로 조정한다. 다음 이동을 위해서는 prefetch, Speculation Rules의 prefetch·prerender, 서비스 워커 프리캐싱을 쓰되 확신이 있을 때만 쓴다.
Frontend › Web
링크와 내비게이션 마크업<a href>가 가리킬 수 있는 곳(절대·상대 URL, 프래그먼트, mailto·tel, blob·data), download로 내려받기, target과 rel=noopener·noreferrer, 이름 붙은 브라우징 맥락으로 탭 폭증 막기, rel·hreflang·type·ping, 그리고 링크 목록을 <nav>로 묶는 건너뛰기 링크·목차·브레드크럼·로컬·전역 내비게이션 패턴을 정리한다.
Frontend › Web
목록과 표 마크업ul·ol·dl의 허용 자식과 중첩 규칙, ol·li의 번호 속성, dl을 div로 묶는 법, 그리고 표의 자식 순서(caption → colgroup → thead → tbody → tfoot), th·scope·headers, colspan·rowspan, colgroup·col로 열 꾸미기, 표 CSS를 정리한다. 목록인지·용어 쌍인지·표인지 고르는 기준도 함께 둔다.
Frontend › Web
문서 head와 메타데이터<head>는 화면에 보이지 않지만 인코딩·제목·뷰포트·스타일·스크립트·아이콘·대체 버전·대표 URL·검색과 SNS 미리보기 정보를 모두 담는다. 모든 페이지에 넣을 다섯 줄, 성능을 위한 요소 순서, link의 rel 종류, meta의 세 갈래(charset·http-equiv·name)와 이제 쓰지 않는 태그, Open Graph와 SEO의 관계, 미리보기가 안 나오는 이유, base의 함정, 웹 앱 매니페스트로 정리한다.
Frontend › Web
반응형 이미지: srcset·sizes와 picture같은 이미지를 크기만 바꿔 줄 때는 srcset·sizes로 브라우저에 선택을 맡기고(서술형), 자르기·형식 대체처럼 규칙을 강제할 때는 picture를 쓴다(지시형). 크기만 맞춰도 작은 화면의 이미지 용량이 70% 넘게 준다. sizes는 레이아웃에서의 폭이라 도구가 알 수 없으니 근삿값을 주거나, 지연 로딩 이미지는 sizes="auto"에 맡긴다.
Frontend › Web
브라우저 기본 동작을 존중하기스크롤바·스크롤·선택 강조색·글자 크기·고대비·키보드 포커스·클립보드·방문 기록은 OS와 브라우저가 모든 앱에 같은 방식으로 제공하는 기능이다. 사이트가 이를 바꾸면 외부 일관성이 깨져 일부 사용자가 밀려난다. 덮어쓰지 말고, 필요하면 기본 위에 선택지를 더한다.
Frontend › Web
브라우저 아키텍처: 다중 프로세스, 내비게이션, 렌더러 스레드, 입력 처리Chrome을 예로 브라우저가 프로세스를 어떻게 나누는지(브라우저·렌더러·GPU·네트워크 등, 사이트 격리), 주소를 입력한 뒤 어느 프로세스가 무엇을 하며 페이지를 커밋하는지, 렌더러 안의 메인·컴포지터·래스터 스레드가 프레임을 만드는 방식, 입력 이벤트가 컴포지터를 거쳐 메인 스레드로 가는 길과 passive 리스너·이벤트 병합까지.
Frontend › Web
브라우저 지문 채취와 User-Agent 축소지문 채취는 UA·글꼴·화면·캔버스 렌더링처럼 오래 변하지 않는 특성을 모아 쿠키 없이 사용자를 식별한다. 수동·능동 방식과 엔트로피로 이해하고, 브라우저는 API 미구현·권한 요청·값 뭉개기·UA 동결로 대응한다. 사이트는 UA 스니핑을 기능 감지와 Client Hints로 바꾸고 넓은 환경에서 시험한다.
Frontend › Web
서드파티 쿠키와 브라우저 추적 방지사파리 ITP와 파이어폭스 Total Cookie Protection은 서드파티 쿠키를 막거나 사이트별로 분할하고, 크롬은 단계적 폐지를 철회해 일반 창에서는 사용자 설정에 맡긴 뒤 Privacy Sandbox API 대부분을 정리했다. 브라우저를 가리지 않고 동작하려면 임베드 상태는 CHIPS(Partitioned)로, 꼭 필요한 교차 사이트 접근은 Storage Access API로 처리한다.
Frontend › Web
서드파티와 프라이버시: 감사와 Referrer·Permissions 정책광고·임베드·분석·스크립트·패키지 같은 서드파티는 IP·Referer·쿠키를 받고, 스크립트는 페이지 전체 권한을 가진다. 기술·비기술 감사로 실제 요청을 파악하고, 정적 공유 링크·퍼사드·nocookie 임베드로 줄이며, Referrer-Policy·Permissions-Policy·CSP Report-Only로 범위를 묶는다.
Frontend › Web
서비스 워커 등록·스코프·생명주기와 업데이트서비스 워커는 페이지와 서버 사이에서 스코프 안의 요청을 가로채는 별도 스레드의 스크립트다. 등록 → 설치 → 활성화 순서로 생명주기를 밟고, 파일이 한 바이트라도 바뀌면 새 버전이 설치되지만 옛 버전이 모든 창에서 물러날 때까지 대기한다. skipWaiting·clients.claim의 위험, 메모리 상태가 사라지는 수명, 브라우저별 디버깅 도구를 정리한다.
Frontend › Web
서비스 워커 캐싱과 응답 전략Cache Storage API로 요청·응답 쌍을 저장하고, fetch 이벤트의 respondWith()로 캐시 우선·네트워크 우선·stale-while-revalidate·네트워크 전용·캐시 전용 중 하나를 URL별로 골라 응답한다. 무엇을 언제 프리캐시할지, 불투명 응답과 addAll의 원자성 함정, 오프라인 대체 페이지, Workbox로 줄이는 코드, 페이지를 조각별로 캐시하는 서비스 워커 인클루드와 스트리밍까지 정리한다.
Frontend › Web
성능 측정 API: Navigation·Resource·User Timing과 PerformanceObserver브라우저가 실제 사용자 환경에서 기록하는 성능 항목(performance entry)을 읽는 API들. 문서 요청은 Navigation Timing, 하위 자원은 Resource Timing, 앱이 직접 찍는 구간은 User Timing의 mark·measure로 재고, 모두 PerformanceObserver에 buffered로 구독해 모은다. 교차 출처 자원은 Timing-Allow-Origin 헤더가 있어야 세부 시간이 보인다.
Frontend › Web
스크립트·스타일 로딩 순서와 점진적 렌더링<script>, async, defer, type=module이 HTML 파싱과 실행 순서에 주는 차이, 프리로드 스캐너가 못 보는 늦게 발견되는 자원, CSS는 <head>에 두고 스크립트는 defer로 미루는 이유와 예외, @import를 피하고 중요 CSS만 인라인하는 CSS 경량화, 콘텐츠를 받는 대로 먼저 보여 주는 점진적 렌더링 기법을 정리했다.
Frontend › Web
스트리밍 SSRHTML을 한 번에 다 만들어 보내지 않고 Suspense 경계 단위로 나눠 흘려보내는 SSR. React 18에서 도입됐고, 지금은 React 19의 부분 사전 렌더링과 Next.js Cache Components의 기반이 되어 기본 동작으로 자리 잡았다.
Frontend › Web
웹 개발에 대한 이상한 믿음들브라우저 엔지니어·표준 제정자·웹 개발자가 웹 개발을 잘 안다는 믿음, 브라우저는 SPA에 맞지 않는다, MPA가 SPA를 대체한다, 모든 사이트는 JS 없이 동작해야 한다, 빌드 단계는 필요 없다는 주장을 하나씩 따져 본다. 공통된 오류는 내가 겪는 웹이 웹 개발 전체를 대표한다고 여기는 것이다.
Frontend › Web
웹 보안: CSRF와 XSS사용자의 권한을 도용하는 CSRF와 악성 스크립트를 주입하는 XSS의 원리와 방어법. 문자열 HTML을 innerHTML에 넣을 때의 위험과 setHTML·DOMPurify·Trusted Types도 다룬다.
Frontend › Web
웹 성능 지표와 LighthouseFCP·LCP·INP·CLS·TTFB 같은 웹 성능 지표의 뜻과 기준값, Core Web Vitals 세 지표가 무엇을 어떻게 재는지(LCP 후보 요소, INP의 세 구간, CLS의 세션 창), 실험실·필드 데이터와 web-vitals 라이브러리로 재는 법, Lighthouse를 정리했다. 지표별 개선법은 따로 나눈 최적화 노트로 연결한다.
Frontend › Web
웹 아키텍처의 다음 전환: MPA에서 PESPA까지MPA → PEMPA → SPA를 거쳐 온 웹 앱 아키텍처가 '점진적으로 향상된 SPA(PESPA)'로 옮겨 가고 있다. 코드가 어디에 사는지, 각 단계가 무엇을 풀고 무엇을 남겼는지 비교한다.
Frontend › Web
웹 앱 매니페스트웹 앱 매니페스트는 설치된 PWA의 이름·아이콘·시작 URL·표시 방식·색·바로 가기를 정하는 JSON이다. 앱을 식별하는 id, 내비게이션 범위 scope, 마스크 가능 아이콘, display와 display_override의 대체 순서, 설치 화면을 키우는 description·screenshots, iOS가 따로 쓰는 link·meta, 그리고 바뀐 메타데이터가 플랫폼마다 언제 반영되는지 정리한다.
Frontend › Web
웹 이미지 형식: 벡터·래스터와 GIF·PNG·JPEG·WebP·AVIF·JPEG XL도형으로 된 그림은 SVG, 사진처럼 실제 세계의 디테일이 있는 그림은 래스터다. 래스터는 손실 압축이 가능한 형식을 고르되, 사진은 AVIF·WebP를 먼저 주고 JPEG로 받친다. PNG는 반투명이 필요한 단순 그림과 원본 보관용, GIF는 거의 쓸 곳이 없다. JPEG XL은 크롬·파이어폭스·사파리가 지원하지만 엣지가 빠져 있어 picture로 대체를 둔다.
Frontend › Web
웹 폰트 성능 최적화: 발견·내려받기·렌더링웹 폰트는 레이아웃이 필요로 할 때에야 요청되는 늦게 발견되는 자원이다. preload나 인라인 @font-face로 일찍 발견되게 하고, 자체 호스팅·WOFF2·서브셋으로 빨리 받고, font-display로 글자가 숨거나 밀리는 방식을 고른다.
Frontend › Web
웹 표준은 어떻게 만들어지나: W3C·WHATWG·WICG웹 플랫폼의 표준은 W3C 권고안 트랙(WD → CR → REC), WHATWG의 리빙 스탠더드, WICG의 인큐베이션, TC39의 단계별 제안이라는 서로 다른 절차로 만들어진다. 권고안의 성숙 단계와 '독립적인 구현 둘' 같은 진입 조건, CSS가 레벨 단위 모듈로 쪼개진 이유, WHATWG가 HTML·DOM을 맡게 된 경위, 표준 상태와 브라우저 구현 상태를 확인하는 곳을 정리한다.
Frontend › Web
이미지 압축과 인코딩 자동화JPEG는 밝기보다 색을 더 버리고(크로마 서브샘플링) 고주파 디테일을 양자화해 줄인다. WebP는 블록 예측과 영역별 양자화로 같은 품질에서 더 작다. 품질 값은 0~100 하나로 조절하되 도구마다 뜻이 달라 눈으로 확인한다. 실제 서비스에서는 사람이 아니라 빌드 도구·정적 사이트 생성기·CMS가 원본에서 여러 형식과 크기를 만든다.
Frontend › Web
이전 페이지 URL 알아내기사용자가 어느 페이지에서 왔는지 알아내는 세 가지 방법(document.referrer, 직접 기록, 쿠키·sessionStorage)과 각각의 한계.
Frontend › Web
자바스크립트 코드 분할시작할 때 받는 JS가 크면 파싱·컴파일·실행 동안 메인 스레드가 막혀 TBT와 INP가 나빠진다. 커버리지로 시작 때 안 쓰는 코드를 찾고, 동적 import()로 나중에 필요한 코드를 별도 청크로 떼어 상호작용할 때 불러온다. 청크 크기는 캐시·압축·평가 시간의 균형으로 정한다. 로딩 전략 전체는 PRPL(Preload·Render·Pre-cache·Lazy load)로 묶는다.
Frontend › Web
정적 사이트 생성기와 Jamstack정적 사이트 생성기(SSG)는 마크다운 콘텐츠와 템플릿을 빌드 때 HTML로 합쳐 CDN에 올린다. 서버·DB가 없어 빠르고 안전하며, Git push가 곧 배포다. 콘텐츠 사이트는 JS를 거의 보내지 않는 Eleventy·Hugo·Astro가 맞고, 상호작용이 많으면 Next.js 같은 프레임워크를 쓴다. WordPress에서 옮기는 흐름도 정리한다.
Frontend › Web
지속 가능한 웹 디자인웹사이트의 에너지 사용은 전송 데이터·CPU·서버 자원으로 어림할 수 있고, 이를 줄이는 일은 곧 성능·접근성·SEO 개선이다. 필요 없는 요청과 기능을 빼고, 이미지·폰트·영상·분석 도구를 의심하고, 서버 캐시와 재생 에너지 호스팅을 쓴다.
Frontend › Web
지연 로딩: 이미지·iframe·퍼사드화면 밖 이미지·iframe은 loading='lazy'로 미뤄 첫 화면 자원에 대역폭을 몰아 준다. 첫 화면 이미지와 LCP 후보에는 절대 쓰지 않는다. 무거운 서드파티 임베드는 가짜 UI(퍼사드)를 보여 주다 상호작용할 때 바꾸고, 네이티브로 미룰 수 없는 video·배경 이미지는 IntersectionObserver 기반 라이브러리로 미룬다.
Frontend › Web
쿠키와 세션상태가 없는 HTTP에서 브라우저와 서버가 사용자를 기억하기 위해 쓰는 쿠키와 세션.
Frontend › Web
클라이언트 사이드 라우팅: 해시, History API, Navigation APISPA가 새로고침 없이 화면을 바꾸면서도 페이지마다 고유한 URL과 뒤로 가기를 유지하는 방법. 링크·AJAX·해시(hashchange)·History API(pushState·popstate) 방식의 차이, 새로고침 때 서버가 해야 할 일(index.html 폴백, Accept 헤더로 HTML·JSON 나눠 응답), 모든 이동을 한 이벤트로 받는 Navigation API를 정리한다.
Frontend › Web
텍스트 의미 요소와 문자 참조문단·인용·강조·기술 문서·정의·수정 이력·줄 바꿈을 표현하는 HTML 텍스트 요소를 용도별로 고르는 법. blockquote·q·cite의 구분, em·strong·mark·i·b·u·s의 의미 차이, code·kbd·samp·var·data·time, abbr·dfn, br·hr·wbr, 그리고 꼭 이스케이프해야 하는 문자 참조를 정리한다.
Frontend › Web
프라이버시를 위한 암호화: 전송·저장·종단 간사용자 데이터를 남이 읽지 못하게 하는 세 겹의 암호화. 전송 중은 HTTPS·리다이렉트·HSTS로, 저장 중은 클라우드 기본 암호화와 직접 관리 키로, 운영자조차 못 읽게 하려면 Web Crypto로 클라이언트에서 암호화하는 종단 간 암호화로 지킨다. 각 층이 막는 위협과 한계를 정리한다.
Frontend › Web
프론트엔드 개발자가 알아야 할 지연 시간 숫자네트워크 왕복, 파싱, 프레임 예산, 사람의 체감 한계를 밀리초 단위로 정리한 표. 지연은 워터폴로 곱해지므로 요청 체인을 서버로 옮기고, JS를 줄이고, 사용자 가까이 배포한다.
Frontend › Web
프론트엔드 성능 최적화: 언제, 무엇을최적화는 측정한 뒤에, 최악의 사용자(p95·p99)를 기준으로, 무엇을 희생하는지 알고 한다. 느림은 초기 로딩(대역폭·지연 시간·JS 실행)과 런타임(실제 성능과 체감 성능)으로 나눠 본다. 캐싱·프리패치·코드 분할, 긴 작업 줄이기와 쪼개기, 파생 상태와 리렌더링 범위 좁히기를 각 원인에 맞춰 고른다.
Frontend › Web
프론트엔드 웹 개발 용어집API부터 Yarn까지 프론트엔드 개발에서 자주 듣는 용어 70여 개를 주제별로 묶어 한두 줄로 설명하고, 자세한 노트가 있는 용어는 그 노트로 연결했다.
Frontend › Web
프론트엔드 출시 전 체크리스트웹 페이지를 배포하기 전에 확인할 항목을 head·HTML·CSS·이미지·폰트·JavaScript·보안·성능·접근성·SEO 열 가지로 나눠, 우선순위와 자세한 설명이 있는 노트로 잇는 점검표. 항목은 사람이 외우지 않고 린터·Lighthouse·CI로 자동화하는 것이 기본이다.
Frontend › Web
프론트엔드의 등장 배경초기 웹에는 프론트엔드라는 개념이 없었다. 이미지·CSS·JavaScript·AJAX가 차례로 등장하고 Flash가 물러나고, 구글·페이스북이 웹을 앱 플랫폼으로 밀어붙이면서 화면을 만드는 일이 전문 영역이 되었고, 트래픽이 커지자 프론트엔드와 백엔드가 나뉘었다. React 이후에는 프레임워크·상태 관리·타입·스타일링·빌드 도구·렌더링 방식이 해마다 바뀌었지만, 갈래별로 보면 방향은 일정했다.
Frontend › Web
AMP: 규칙으로 빠르게 만드는 모바일 페이지AMP(Accelerated Mobile Pages)는 HTML에 제약을 걸고(외부 JS 금지, 인라인 CSS 상한, 자원 크기 명시) 전용 런타임과 캐시 CDN으로 페이지를 빠르게 만드는 프레임워크다. 성능 원리는 일반 페이지에도 그대로 쓰이지만, URL 이원화와 플랫폼 종속 때문에 비판을 받았고 검색 우대가 사라진 뒤로는 Core Web Vitals를 직접 맞추는 쪽이 일반적이다.
Frontend › Web
CLS 최적화: 자리를 먼저 잡기레이아웃 이동은 늦게 도착한 것이 자리를 비집고 들어올 때 생긴다. 이미지·동영상에는 width·height나 aspect-ratio, 광고·임베드에는 min-height, 늦게 뜨는 배너는 자리 확보나 오버레이, 애니메이션은 transform, 웹 폰트는 font-display와 대체 폰트 지표 보정으로 막는다. 필드와 실험실 값의 차이로 로딩 중 이동인지 이후 이동인지 가른다.
Frontend › Web
DOM과 BOM브라우저가 HTML 문서를 파싱해 메모리에 올린 객체 트리와, 이를 다루는 API. window의 두 역할과 DOM·CSSOM·HTML 명세의 구분, 공백·주석까지 노드가 되는 규칙과 파서의 자동 교정, 노드 클래스 계층과 확인 방법, 문자열 HTML 대신 DOM이 필요해진 이유와 프레임워크 시대에 DOM API를 익히는 법도 다룬다.
Frontend › Web
HTML 기초와 HTML5웹 문서의 구조와 의미를 태그로 표현하는 마크업 언어와 그 핵심 문법. 요소와 태그, 대체·빈 요소, 생략 가능한 태그, 불리언·열거형·전역 속성, data-* 속성, 속성 하나로 끝나는 기능(enterkeyhint·form·download·loading·fetchpriority·integrity·popover 등), DOCTYPE, form 데이터 규칙, HTML5까지 다룬다.
Frontend › Web
HTTPS 전환: 인증서 고르기부터 리다이렉트까지사이트를 HTTPS로 옮기는 실무 흐름. 인증서는 검증 수준(DV·OV·EV)과 도메인 범위(단일·다중·와일드카드)로 고르는데, 웹사이트에는 ACME로 자동 발급·갱신하는 DV가 표준이다. 설치 뒤 301 리다이렉트·혼합 콘텐츠 제거·HSTS·서버 설정 점검까지 해야 전환이 끝난다.
Frontend › Web
INP 최적화: 긴 작업 쪼개기와 양보INP는 입력 지연, 처리 시간, 표시 지연의 합이다. 필드 데이터로 느린 상호작용을 찾고, 시작할 때의 스크립트 평가를 줄여 입력 지연을, 핸들러를 가볍게 하고 메인 스레드에 양보해 처리 시간을, DOM 크기·content-visibility·클라이언트 HTML 렌더링을 손봐 표시 지연을 줄인다.
Frontend › Web
Intersection Observer와 관찰자 API스크롤 이벤트로 위치를 계산하는 대신, 요소가 화면(또는 스크롤 영역)에 얼마나 보이는지 브라우저가 알려 주는 IntersectionObserver. root·rootMargin·threshold 옵션, 무한 스크롤·지연 로딩·끝까지 읽음 감지 패턴, 크기 변화를 보는 ResizeObserver와 DOM 변화를 보는 MutationObserver를 정리한다.
Frontend › Web
LCP 최적화: 네 구간으로 나눠 줄이기LCP는 TTFB, 자원 로드 지연, 자원 로드 시간, 요소 렌더 지연의 합이다. 두 「지연」 구간은 0에 가깝게, 나머지 둘은 40%씩이 목표다. LCP 자원을 HTML에서 바로 발견되게 하고, fetchpriority로 앞당기고, 지연 로딩하지 않고, 작게 만들고, 막는 CSS·JS와 긴 작업을 걷어 낸다.
Frontend › Web
OAuth 2.0비밀번호를 넘기지 않고 다른 서비스의 자원 접근 권한을 위임하는 OAuth 2.0. 네 역할, Authorization Code + PKCE 흐름, 토큰 종류, OIDC와의 차이, 프론트엔드 보안 주의점, OIDC로 구현하는 SSO를 정리한다.
Frontend › Web
PWA 기능과 OS 통합PWA가 운영 체제와 이어지는 기능을 지원 범위별로 정리한다. 웹 푸시와 알림(iOS는 16.4부터 홈 화면 웹 앱에서만, 18.4부터 선언적 웹 푸시), 앱 배지, 공유하기와 공유 대상, 파일 시스템 접근과 파일 핸들러, 프로토콜 핸들러, 링크 캡처, 연락처 선택기, 하드웨어 API, 그리고 Project Fugu·오리진 트라이얼로 새 기능을 시험하는 법과 기능 감지·권한 요청 원칙을 다룬다.
Frontend › Web
PWA 설치와 설치 유도설치 기준은 브라우저마다 다르다. Chrome은 HTTPS, name·아이콘(192·512px)·start_url·display를 갖춘 매니페스트와 최소한의 사용자 참여를 본다. 데스크톱 Chromium·Android(WebAPK와 바로 가기)·iOS 홈 화면·macOS Safari의 Dock 추가·Firefox의 Windows 작업 표시줄 웹 앱까지 플랫폼별 설치 방식, beforeinstallprompt로 직접 띄우는 설치 버튼, display-mode로 실행 방식을 알아내는 법, 앱 스토어 배포를 정리한다.
Frontend › Web
PWA 앱 경험 설계와 창 관리설치된 PWA는 브라우저 탭이 아니라 자기 창을 가진다. 200×100px 미니 모드까지 견디는 반응형·점진적 향상의 기초와 오프라인을 기본 상태로 보는 오프라인 우선 원칙(마지막 상태 지키기, 동작 큐, 충돌 해결) 위에, display-mode 미디어 쿼리, 창 제목, 선택·당겨서 새로고침·safe area 같은 앱다운 CSS를 더한다. 스코프 밖 링크가 여는 앱 안 브라우저와 OAuth 흐름, 창 이동·크기·새 창, 제목 표시줄 오버레이, 여러 화면 배치, 화면 꺼짐 방지, 가상 키보드 API까지 정리한다.
Frontend › Web
PWA 오프라인 데이터와 저장소 관리URL로 요청하는 자산은 Cache Storage에, 검색·조합할 구조화 데이터는 IndexedDB에 둔다. 저장소 할당량은 출처 단위로 묶이고 StorageManager.estimate()로 확인한다. 브라우저는 압박이 생기거나 오래 쓰지 않으면 데이터를 지우므로 persist()로 영속 저장을 요청하고, 지워진 뒤에도 앱이 온라인에서 다시 뜨게 만든다. 데이터를 뒤에서 최신으로 유지하는 백그라운드 동기화 계열 API도 정리한다.
Frontend › Web
PWA와 서비스 워커 캐시 전략PWA는 HTTPS·웹 앱 매니페스트·서비스 워커 세 가지를 갖춘 웹사이트일 뿐이고, 사이트 종류와 상관없이 득이 된다. 서비스 워커로 캐시를 직접 다룰 수 있게 된 만큼, 필요한 것만 작게 요청하고 미디어를 중요도별로 나눠 캐시하고, 캐시 크기를 제한해 사용자의 데이터와 디스크를 아낀다.
Frontend › Web
SEO 기초: 크롤링부터 메타 태그까지검색 엔진이 페이지를 크롤링·색인·순위 매기는 흐름과, 프론트엔드가 챙길 robots.txt·사이트맵·메타 태그·canonical·리다이렉트·렌더링 방식, 링크와 버튼의 구분을 정리했다.
Frontend › Web
SPA와 CSR·SSR한 페이지에서 필요한 부분만 다시 그리는 SPA와, 렌더링 주체·시점에 따른 CSR·SSR·SSG·ISR의 차이.
Frontend › Web
TTFB 줄이기: 리디렉션·HTML 캐시·압축·CDN페이지의 첫 요청인 HTML이 빨리 와야 FCP·LCP가 기준을 넘는다. 리디렉션 체인을 없애고, HTML은 짧게 캐시하거나 ETag로 재검증하고, Server-Timing으로 서버 시간을 재고, 텍스트 자원은 Brotli로 정적 압축하고, CDN 엣지에서 내려 준다.
Frontend › Web
Web Storage: localStorage와 sessionStorage브라우저에 키-값 문자열을 저장하는 localStorage·sessionStorage의 API, 객체를 JSON으로 직렬화해 저장하고 복원하는 법, 다른 탭과 동기화하는 storage 이벤트, 예외 처리와 보안상 넣지 말아야 할 것을 정리한다.
Frontend › Web
WebAssembly: 브라우저의 두 번째 언어C·C++·Rust 같은 언어를 컴파일해 브라우저에서 거의 네이티브 속도로 돌리는 바이트코드 형식 WebAssembly(Wasm)를 정리한다. JavaScript와 비교해 어디서 시간이 줄어드는지(받기·파싱·컴파일·재최적화·실행·GC), Module·Memory·Table·Instance라는 네 개념과 JS API, 툴체인, MVP 이후 Wasm 2.0·3.0에 들어간 기능, 브라우저 밖 실행(WASI)과 쓸 곳·안 쓸 곳까지.
Backend › Architecture
대규모 웹 크롤러 설계하루 10억 페이지 규모로 웹을 크롤링하는 시스템의 설계 원칙. 예의(robots.txt, 도메인당 지연)를 첫 제약으로 두고, 기능별 머신 풀 대신 도메인 샤드마다 모든 기능을 담은 독립 노드로 나누며, 프런티어·준비 큐·블룸 필터를 인메모리 저장소에 둔다. I/O에 묶인 페처는 비동기로, CPU에 묶인 파서는 프로세스로 늘리고, 요청당 과금되는 객체 스토리지보다 로컬 스토리지를 검토한다. 병목은 네트워크·DNS가 아니라 커진 페이지의 파싱과 TLS 핸드셰이크(CPU)이고, 메모리는 인기 도메인의 프런티어라는 꼬리에서 터진다.
Backend › Architecture
URL 단축기 설계긴 URL을 짧은 코드로 바꿔 주고 그 코드로 원래 주소에 리다이렉트하는 서비스(Bitly 같은)의 설계다. 요구 사항과 규모 추정, 301과 302 리다이렉트의 차이, 해시·고유 ID+Base62·무작위 코드 생성 방식 비교, 데이터 모델과 저장소, 캐시 중심의 읽기 경로, 사용자 지정 별칭·만료·클릭 분석·악용 방지를 다룬다.
Backend › Web Basics
2단계 인증: TOTP와 패스키인증기 앱의 6자리 코드(TOTP)는 등록 때 공유한 비밀 키와 현재 시각으로 서버와 앱이 같은 숫자를 각자 계산하는 방식이다. 패스키는 비밀을 공유하지 않는다: 기기가 사이트마다 키 쌍을 만들고 공개키만 서버에 주며, 로그인 때 서버의 챌린지에 개인키로 서명한다. 도메인에 묶여 있어 피싱에 강하다.
Backend › Web Basics
웹 서버, WAS, 그리고 Nginx정적 자원을 내주는 웹 서버(Apache·Nginx)와 동적 처리를 맡는 WAS(Tomcat 등)의 역할 분담, 리버스 프록시·로드밸런싱, Nginx의 마스터-워커 구조와 겸하는 역할(웹 서버·프록시·캐시·TLS 종료), 그리고 Nginx의 location·rewrite·proxy_pass로 404를 다른 서버로 넘기는 설정.
Backend › Web Basics
웹 앱의 요청·응답 구조브라우저·프론트엔드 서버·백엔드(API) 서버·데이터베이스가 요청과 응답을 주고받는 웹 애플리케이션의 기본 흐름과, 한 컴퓨터 안에서 프로세스를 구분하는 포트의 역할.
Backend › Web Basics
API 보안 체크리스트API를 공개하기 전에 점검할 보안 항목을 전송·입력·인증과 인가·노출 범위·운영 단계로 묶었다. 한 가지 방어에 기대지 말고 여러 겹을 쌓는 게 핵심이다.
Backend › Web Basics
Base64 인코딩바이너리 데이터를 ASCII 문자 64개만으로 바꿔 텍스트용 채널로 안전하게 보내는 인코딩. 6비트씩 끊어 변환하는 원리, 패딩, 약 33% 커지는 비용, 이미지를 API에 보내는 예를 정리한다.
Computer Science › Network
브라우저에 URL을 입력하면 일어나는 일주소창에 URL을 입력한 뒤 화면이 그려지기까지의 흐름. HSTS·서비스 워커·HTTP 캐시 확인, DNS 조회, TCP 연결, TLS 핸드셰이크, HTTP 요청·응답, 렌더링을 순서대로 잇고 각 단계의 상세 노트로 연결한다.
Computer Science › Network
CDN전 세계 엣지 서버에 콘텐츠를 캐시해 사용자 가까운 곳에서 응답하는 CDN. 동작 방식, 얻는 것과 비용·위험, 캐시 무효화와 프론트엔드 배포에서의 쓰임을 정리한다.
Computer Science › Network
DNS도메인 이름을 IP 주소로 바꿔 주는 DNS. 이름 공간의 트리 구조(레이블, FQDN·PQDN, gTLD·ccTLD·역방향 도메인), UDP와 TCP를 쓰는 경우, 재귀·반복 질의 흐름과 DNS 포워더, hosts 파일의 우선순위, 손실 재시도, 주요 레코드 종류, TTL과 캐시(잘못된 캐시 바로잡기), 프론트엔드에서 쓰는 dns-prefetch·preconnect를 정리한다.
Computer Science › Network
HTTP 프로토콜웹 통신 규약 HTTP의 Stateless·Connectionless 성질, 요청·응답 메시지 형식, 아홉 가지 메서드와 안전·멱등(PUT·PATCH·POST의 차이), 상태 코드(API에서 자주 쓰는 코드와 비표준 코드), 헤더 종류, URL의 구성 요소와 URI·URL·URN의 차이, HTTP/1.1·2·3 비교와 HTTP/2가 빠른 이유.
Computer Science › Network
HTTPS와 TLSHTTP를 TLS로 감싸 도청·변조·위장을 막는 HTTPS. 대칭키·공개키를 섞어 쓰는 TLS 핸드셰이크, 첫 HTTP 요청의 빈틈을 막는 HSTS와 preload, HTTPS만으로는 부족한 경우를 정리한다.
Computer Science › Network
RFC와 요구 수준 키워드인터넷 표준 문서인 RFC가 무엇이고 어떻게 읽는지, 그리고 명세에서 MUST·SHOULD·MAY가 정확히 무엇을 뜻하는지 정한 RFC 2119·8174의 요구 수준 키워드를 정리한다.
Computer Science
디지털 오디오 기초: 표본화부터 입체 음향까지소리를 주파수·진폭·음색으로 나누고, 아날로그 소리가 표본화·양자화·부호화를 거쳐 디지털이 되는 과정, 나이퀴스트 정리와 파일 크기 계산, PCM·ADPCM·MP3 같은 부호화와 파일 포맷, MIDI, 서라운드와 HRTF 기반 입체 음향을 정리한다.
AI & Data
웹 AI 플랫폼 고르기: 클라이언트, 서버, 하이브리드웹 AI는 모델이 어디서 도나(브라우저 / 서버)와 얼마나 고칠 수 있나(가중치 접근)로 네 가지 선택지가 생긴다. 내장 AI·커스텀 클라이언트 모델·관리형 API·자체 호스팅을 모델 성능·비용·프라이버시·호환성·유지 보수로 비교하고, 요구 사항에서 플랫폼을 고르는 법과 클라이언트 우선 하이브리드 라우팅을 정리한다.
AI & Data
클라이언트 사이드 웹 AI: 내장 AI API, 라이브러리, 런타임브라우저에서 AI를 돌리는 방법은 브라우저가 들고 있는 모델을 부르는 내장 AI(Chrome의 Summarizer·Translator·Prompt API 등)와, Transformers.js·WebLLM 같은 라이브러리로 직접 고른 모델을 돌리는 방식 두 가지다. Chrome 내장 AI API의 현재 상태와 쓰는 법, 라이브러리별 쓰임, Wasm·WebGPU·WebNN 런타임을 정리한다.
AI & Data
AI 기능 기획: 시스템 블루프린트와 유스케이스 발굴웹 서비스에 AI 기능을 넣기 전에 기회(유스케이스·가치) → 솔루션(데이터·지능·UX) → 거버넌스의 세 관점으로 지도를 그린다. 가치 범주로 아이디어를 내고, 사용자 여정에 배치하고, 데이터 준비도·비용·실패 모드를 따져 우선순위를 정한 뒤 끝에서 끝까지 이어지는 프로토타입으로 검증한다.
Tools
GA4 시작하기GA4 계정·속성을 만들고 gtag.js 또는 Google Tag Manager(Google 태그)로 웹사이트에 추적 태그를 설치하는 과정.