전체 글 (64) 썸네일형 리스트형 제어의 역전으로 다시 읽는 Promise 들어가며: 내가 너무 단순하게 보고 있었다나는 Promise를 단순하게 이해하고 있었다. "콜백 지옥을 평평하게 만들어주는 문법." 그게 전부였다. .then을 체이닝하면 코드가 오른쪽으로 안 밀리고 아래로 죽 내려가니까, 그래서 좋은 것 — 딱 그 정도였다.그 정도만 이해하고 넘어갔다. 그러던 어느날 "그럼 .then().then().then() 길어지면 결국 똑같이 지저분한데? 그게 왜 콜백의 대체제야?" promise는 그럼 왜 나온거지?이 질문을 파고들다 보니, 사실 나는 Promise가 만들어진 진짜 이유의 절반도 모르고 있었다. "들여쓰기를 평평하게 만든다"는 건 부수효과였고, 본질은 따로 있었다. 그걸 깨닫고 나서야 Promise가 완전히 다른 도구로 보이기 시작했다.이 글은 그 다시 읽.. Next.js 렌더링 전략 : SSG, ISR, SSR을 언제, 왜 쓰는가 "Next.js가 이렇게 많은 렌더링 방식을 제공하는 이유가 뭘까?" 처음 Next.js를 배울 때 가장 많이 하는 질문이다. 정답은 간단하다. 상황마다 최적의 전략이 다르기 때문이다.이 글에서는 SSG, ISR, SSR 각각이 어떤 방식으로 동작하는지, 언제 써야 하는지, 그리고 각 전략의 트레이드오프를 실전 관점에서 정리한다. 렌더링 전략을 결정하는 두 가지 축전략을 고르기 전에 반드시 이 두 가지를 먼저 따져야 한다.데이터가 얼마나 자주 바뀌는가? (정적 ↔ 실시간)모든 유저에게 동일한 데이터인가, 아니면 개인화된 데이터인가? (공용 ↔ 개인)이 두 축만 명확하면 전략 선택은 자연스럽게 따라온다.SSG (Static Site Generation)어떻게 동작하나빌드 타임 (next build 실행 시.. Hydration이 뭔지, Mismatch가 왜 일어나는지 — 직접 겪으면서 이해한 것들 Next.js로 SmartMark를 개발하다가 이런 에러를 만났다.Error: Hydration failed because the initial UI does not match what was rendered on the server.처음엔 뭔 말인지 몰랐다. 이 글은 그 에러를 직접 겪고 나서 이해한 것들을 정리한 거다.Hydration이 뭔지한 줄로 말하면:서버에서 만든 정적 HTML에 클라이언트에서 JS를 붙여서 상호작용 가능하게 만드는 과정조금 더 풀어서 설명하면:1. 서버에서 HTML 생성 → 클라이언트로 전송 (이 시점엔 버튼 클릭해도 반응 없음)2. 클라이언트에서 JS 다운로드 + 실행3. React가 HTML에 이벤트 핸들러, useState 등 연결 (이게 Hydration)4. .. 서버 컴포넌트 vs 클라이언트 컴포넌트 — 뭐가 다르고 언제 쓸까 지난 글에서 RSC가 왜 나왔는지 정리했다. 이번엔 실제로 서버 컴포넌트와 클라이언트 컴포넌트가 뭐가 다른지, 언제 어떤 걸 써야 하는지 정리한다.가장 먼저 — "use client"에 대한 오해처음에 "use client"를 보고 이렇게 생각했다."use client" = 클라이언트에서만 실행되는 컴포넌트틀렸다. "use client"는 "클라이언트에서만 실행"이 아니라 클라이언트 경계를 만드는 것이다.공식 문서에 따르면 클라이언트 컴포넌트는 요청 상황에 따라 다르게 동작한다.첫 방문 (Full page load)서버에서 HTML 미리 생성 (클라이언트 컴포넌트 포함) ↓클라이언트에서 Hydration→ 총 두 번 실행이후 페이지 이동 (Subsequent navigation)클라이언트에서.. RSC는 왜 나왔을까 — CSR, SSR(Page Router)의 한계에서 시작된 이야기 React를 쓰면서 Next.js를 자연스럽게 접하게 됐고, 그러다 보니 서버 컴포넌트라는 개념을 마주쳤다. 처음엔 그냥 "서버에서 렌더링하는 거구나"라고 넘겼는데, 실제로 사이드 프로젝트를 개발하면서 Hydration Mismatch 에러를 직접 겪고 나서야 제대로 이해해야겠다는 생각이 들었다.Josh Comeau의 Making Sense of React Server Components 글을 읽으면서 정리한 내용이다. (참고: 이 글에서의 SSR은 전통적인 서버 렌더링이 아니라 Next.js Pages Router의 SSR, 즉 getServerSideProps 방식을 말한다.)CSR의 문제기존 React는 CSR(Client Side Rendering) 방식이었다.사용자 접속 ↓빈 HTML 받음.. [보안] A01 Broken Access Control 북마크 서비스를 만들면서 이런 API를 만들었다.GET /api/bookmarks/123근데 그렇게 개발을 하면서 잘 되는지 확인도 하면서 개발을 하고 있는데 문득 생각이 들었다 나처럼 누군가가 이렇게 접근할 수 있는거 아닌가 ? "로그인한 다른 사용자가 /api/bookmarks/124 를 그냥 요청하면 어떻게 되지?" 찾아보니 이게 실제 보안 취약점이었다. OWASP Top 10 2021 기준 1위. A01 Broken Access Control이었다.Broken Access Control이 뭔가한 줄로 정의하면: 내가 볼 수 없어야 하는 걸 볼 수 있거나, 할 수 없어야 하는 걸 할 수 있는 것 여기서 두 가지 개념을 구분해야 한다.인증 (Authentication): 로그인한 사람인가? 인가 (.. [보안] URL 크롤링 기능을 만들다가 알게 된 SSRF(방어) 북마크 서비스를 만들고 있었다. 사용자가 URL을 입력하면 서버가 그 페이지에 접속해서 제목, 설명, 썸네일을 가져오는 기능이었다. 개발하면서 문득 이런 생각이 들었다. "사용자가 URL을 마음대로 입력할 수 있으면... 아무 주소나 넣어도 서버가 요청하는 거 아닌가?" 그게 SSRF였다.SSRF가 무엇인가Server-Side Request Forgery. 직역하면 서버 측 요청 위조다.공격자가 서버를 대리인으로 이용해서, 서버가 공격자 대신 내부 네트워크에 요청을 보내게 만드는 취약점이다.건물 비유가 이해하기 쉬웠다.[외부인/공격자] [경비/방화벽] [내부 사무실]외부인은 경비가 막아서 내부에 직접 못 들어간다.근데 내부 직원(서버)한테 전화해서"저 대신 내부 창고에서 서류.. JWT를 쿠키에 담을 때 알아야 할 것들 개발을 하다가 궁금증이 생겼다 그럼 쿠키에 4KB 이상으로 넣게 되면 어찌 되는가 ~Set-Cookie 보안 속성부터 4KB 제한의 실체, 그리고 실무에서 선택하는 해결 전략까지.1. Set-Cookie 3대 속성서버가 쿠키를 발행할 때 아래 세 가지 속성을 빠뜨리면 보안 구멍이 생긴다.Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=LaxHttpOnly자바스크립트 document.cookie로 이 쿠키를 읽을 수 없게 만든다. XSS 공격으로 악성 스크립트가 실행되더라도 토큰은 가져갈 수 없다.SecureHTTPS 연결에서만 쿠키를 전송한다. 공공 와이파이 환경에서 패킷을 가로채도 쿠키 값은 노출되지 않는다.SameSite다른 도메인에서 요청이 들어올 .. 이전 1 2 3 4 ··· 8 다음