안녕하세요! 그로스로그 입니다!😊 🌱
이번 회차를 정리하다 재미있는 걸 발견했어요. CSR이 두 편에 나오는데, 뜻이 완전히 다릅니다. 3기 8회차입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
한 편에서 CSR은 Client-Side Rendering이고, 다른 한 편에서는 Certificate Signing Request입니다. 프론트엔드와 보안에서 각각 쓰이는 약자가 우연히 겹쳤어요. 개발 용어의 세계가 얼마나 넓은지를 보여주는 회차입니다.
01
🖼️ SSR, CSR 그리고 SSG 렌더링
이종경 님
웹 페이지를 만드는 세 가지 방식 — CSR · SSR · SSG를 각각의 작동 원리, 장단점, 예시 코드와 함께 정리했습니다.
그리고 후반부가 이 글의 백미예요. SSR에서 왜 Hydration이 필요한지, React 18 이후의 Streaming SSR · Selective Hydration · Lazy Hydration, 그리고 Islands Architecture까지 갑니다.
개념 정리에서 최신 전략까지 한 번에 이어지는 구조입니다.
3기 1회차에서 신지훈 님이 Tanstack Query로 SSR을 구현했었죠. 이 글은 그 SSR이 무엇이고 왜 필요한지를 원리에서부터 짚습니다.
조금 더 들어가 보면
세 방식을 가르는 축은 하나입니다. HTML을 언제, 어디서 만드는가.
· CSR — 브라우저에서, 사용자가 접속한 뒤 만듭니다
· SSR — 서버에서, 요청이 올 때마다 만듭니다
· SSG — 빌드할 때, 미리 만들어둡니다
그리고 이 선택이 곧 비용을 언제 낼 것인가를 정합니다.
CSR은 서버가 편합니다. 빈 HTML만 주면 되니까요. 대신 사용자가 기다립니다. 자바스크립트를 받아 실행할 때까지요.
SSR은 사용자가 편합니다. 완성된 HTML이 바로 오니까요. 대신 서버가 매 요청마다 일합니다. 글이 짚은 "서버 부하가 증가하여 확장성 문제"가 이거죠.
SSG는 둘 다 편합니다. 미리 만들어둔 파일을 주기만 하면 되니까요. 대신 내용을 바꾸려면 다시 빌드해야 합니다.
공짜인 방식은 없고, 누가 언제 비용을 낼지가 다를 뿐입니다.
💧 Hydration — "보이는데 안 눌리는" 시간
이 글에서 가장 중요한 개념입니다. 글의 설명이 정확해요.
"화면은 보이는데 버튼이 안 눌리는" 그 순간이 실재한다는 겁니다.
SSR 페이지를 열면 내용은 즉시 나타납니다. 그런데 그건 그림에 가까워요. 자바스크립트가 도착해서 각 요소에 이벤트 핸들러를 붙여야 비로소 동작합니다. 그 연결 과정이 Hydration(수화)입니다. 마른 HTML에 물을 부어 살아나게 하는 이미지죠.
이게 실무에서 문제가 되는 이유가 있습니다. 사용자는 보이면 누릅니다. 화면이 떴는데 반응이 없으면 "이 사이트 이상하네" 하고 다시 누르거나 나가버려요. CSR의 "느린 로딩"보다 오히려 혼란스러울 수 있는 지점입니다.
그래서 React 18이 내놓은 전략들이 전부 이 시간을 줄이거나 나눠 쓰는 방법입니다.
· Streaming SSR — HTML을 조각으로 나눠 준비된 것부터 보냅니다
· Selective Hydration — 중요한 요소부터 먼저 살립니다
· Lazy Hydration — 스크롤이나 클릭 같은 사용자 행동이 있을 때까지 미룹니다
· Islands Architecture — 페이지를 독립적인 섬으로 나눠 각자 살아나게 합니다
Streaming SSR은 3회차에서 강단 님이 다룬 chunked transfer encoding과 정확히 같은 이야기입니다. 서버가 완성 전에 흘려보낼 수 있으니 가능한 전략이죠. 두 회차의 글이 서로를 설명해주고 있습니다.
Islands Architecture도 흥미로운 발상입니다. 블로그 글 하나를 생각해보세요. 대부분은 그냥 글자입니다. 댓글 창과 좋아요 버튼만 동작하면 돼요. 그런데 기존 방식은 페이지 전체를 살립니다. 섬 구조는 필요한 곳만 섬으로 만들어 살리고 나머지는 정적인 채로 둡니다.
큐레이터 노트
개념 정리에서 최신 전략까지 이어붙인 글이라 뽑았습니다.
CSR·SSR·SSG 비교는 자료가 아주 많은 주제입니다. 그런데 대부분 세 개를 나열하고 끝나요. 이 글은 "그래서 SSR의 남은 문제는 무엇이고, 어떻게 풀고 있는가"까지 갑니다. Hydration이 그 연결 고리예요.
Hydration을 "왜 필요한가"에서 시작한 것도 좋았습니다. 용어부터 설명하면 어렵게 느껴지는데, "보이는데 안 눌린다"는 문제를 먼저 보여주니 필요성이 바로 이해됩니다.
참고 자료를 일곱 개나 밝혀뒀더라고요. hydration mismatch 사례와 테스트 케이스까지 포함해서요. 그만큼 여러 각도로 찾아봤다는 뜻입니다.
이 저자는 3기에만 다섯 번 큐레이션되셨습니다. 자바스크립트 런타임 → BFF → 실행 컨텍스트 → 렌더링 → 모듈 시스템으로 이어지는데, 프론트엔드를 층층이 훑어 내려가고 계세요.
02
🔐 Certificate Signing Request (CSR) 이란
김영진 님
아주 짧은 글입니다. 두 문장으로 정리돼 있어요.
CSR은 공개키 인증서를 발급받기 위해 인증기관(CA)에 보내는 요청 데이터이고, 그 포맷을 정의한 표준이 PKCS #10이라는 내용입니다.
이 글은 단독으로 서 있지 않습니다. PKI · X.509 · PEM 파일 · ASN.1 · PGP로 이어지는 보안 용어 시리즈의 한 조각이에요.
앞선 글의 CSR과 철자가 같지만 완전히 다른 것입니다. 이쪽은 인증서 서명 요청이에요.
조금 더 들어가 보면
CSR이 어디에 쓰이는지부터 보면 이해가 빠릅니다. HTTPS 인증서를 발급받는 과정이요.
웹사이트에 자물쇠 아이콘을 붙이려면 인증서가 필요합니다. 그 인증서를 받는 절차가 이렇습니다.
1. 내 서버에서 키 쌍(공개키 + 개인키)을 만듭니다
2. 공개키와 내 정보(도메인, 조직명 등)를 묶어 CSR을 만듭니다
3. CSR을 인증기관(CA)에 보냅니다
4. CA가 확인한 뒤 서명해서 인증서를 돌려줍니다
여기서 가장 중요한 점이 있습니다. 개인키는 절대 밖으로 나가지 않습니다.
CSR에는 공개키만 들어갑니다. CA조차 내 개인키를 모르고, 알 필요도 없어요. "이 공개키의 주인이 맞다"는 것만 보증해주면 되니까요.
이게 공개키 암호의 핵심 구조입니다. 비밀을 넘기지 않고도 신뢰를 만들 수 있는 것.
📎 그리고 PKCS #10
글이 짚은 표준입니다. PKCS(Public-Key Cryptography Standards) 중 10번이 CSR 포맷을 정의해요.
이런 표준이 왜 필요할까요. CSR을 만드는 쪽과 받는 쪽이 다르기 때문입니다. 내 서버에서 OpenSSL로 만든 CSR을 어느 인증기관에 보내든 읽혀야 하거든요. 약속된 형식이 있어야 서로 모르는 시스템끼리 일할 수 있습니다.
그리고 이 글이 시리즈의 한 조각이라는 게 여기서 살아납니다. 같은 블로그의 다른 글들을 보면 이렇게 이어져요.
· PKI, 표준인증서 형식 X.509 — 전체 신뢰 구조
· 인증서 pem 파일 — 인증서를 담는 파일 형식
· CSR — 발급 요청 (이 글)
· x.509 인증서란 — 발급된 인증서의 구조
· ASN.1 — 이 모든 걸 표현하는 데이터 규격
하나의 주제를 조각내어 하나씩 채워가는 방식입니다. 각 글은 짧지만 모이면 지도가 돼요.
큐레이터 노트
짧아도 자리가 분명한 글이라 뽑았습니다.
솔직히 이 글만 떼어놓고 보면 두 문장짜리 메모입니다. 그런데 보안 카테고리 전체를 놓고 보면 성격이 달라져요. PKI·X.509·PEM·ASN.1·PGP 사이에 CSR이 놓여 있습니다. 빠지면 지도에 구멍이 나는 조각이에요.
성장일지를 쓰다 보면 "이 정도는 너무 짧은데" 싶어서 안 쓰게 되는 것들이 있습니다. 그런데 그런 것들이 안 쌓이면 나중에 정작 필요할 때 없어요. 짧아도 남겨두는 게 낫습니다.
그리고 이 저자의 블로그를 보면 분류가 아주 촘촘합니다. Spring, Vue, React, AWS, Java, SQL에 학교 수업 과목까지 따로 나뉘어 있어요. 380개 글이 그렇게 정리되어 있습니다. 오래 꾸준히 쓴 사람의 블로그가 어떤 모습인지 보여줍니다.
보안이라는 영역을 다루는 분이 성장일지에 계신 것도 반가웠어요. 커뮤니티 안에 없던 분야가 하나 더 들어오는 것이니까요.
03
🔷 TypeScript 개념·파이프라인 체크리스트
박지훈 님
TypeScript를 개념부터 컴파일 내부 동작, 고급 타입, 설정 파일, 실전 팁까지 여덟 장으로 정리한 글입니다.
특히 컴파일 파이프라인(파싱 → 타입 체크 → 트랜스파일)을 짚은 게 특징이에요. 타입이 어떻게 사라지는지를 다룹니다.
그리고
infer, satisfies, 템플릿 리터럴 타입 같은 고급 기능과 TS 5.0/5.5 릴리즈 노트까지 담았습니다.제목의 "체크리스트"가 성격을 말해줍니다. 처음 배우는 사람의 정리가 아니라 점검용 목록이에요.
조금 더 들어가 보면
이 글에서 가장 중요한 개념은 타입 소거(type erasure)입니다.
타입은 실행되지 않습니다. 컴파일이 끝나면 전부 사라져요. 브라우저가 받는 건 그냥 자바스크립트입니다.
이 사실이 실무에서 중요한 이유가 있습니다. TypeScript는 실행 중에 아무것도 막아주지 못하거든요.
API에서 받은 데이터에 User 타입을 붙였다고 해봅시다. 그런데 서버가 다른 모양을 보내면? 타입스크립트는 아무 말도 안 합니다. 이미 사라졌으니까요. 그래서 외부에서 들어오는 데이터는 실행 시점에 따로 검증해야 합니다.
"컴파일 타임의 안전"과 "런타임의 안전"은 다른 문제예요. 이걸 구분하는 게 타입스크립트를 제대로 쓰는 출발점입니다.
🧩 구조적 타입 — 이름이 아니라 모양
글이 짚은 또 하나의 핵심입니다.
interface A { x: number }
interface B { x: number; y: number }
const b: B = { x: 1, y: 2 };
const a: A = b; // OK: B가 A 구조 포함
B는 A를 상속받지 않았습니다. 그런데도 대입이 됩니다.
TypeScript는 "이름이 같은가"가 아니라 "모양이 맞는가"를 봅니다. A가 요구하는 x: number를 B가 갖고 있으니 통과예요. "오리처럼 걷고 오리처럼 운다면 오리다"에 가깝습니다.
Java나 C#은 반대입니다. 명시적으로 상속하거나 구현해야 하죠. 이 차이를 모르면 "왜 이게 되지?" 또는 "왜 안 되지?"에서 헤매게 됩니다.
⚙️ 유용한 최신 기능들
글이 다룬 고급 기능 중 실무에서 바로 쓸 만한 것들이 있습니다.
const config = {
url: 'https://api.example.com',
method: 'GET',
} satisfies RequestOptions;
satisfies는 최근에 나온 연산자인데 아주 유용합니다. const config: RequestOptions = {...}로 쓰면 타입이 넓어져서 config.method가 string이 돼버려요. satisfies를 쓰면 검증은 하되 구체적인 타입은 유지됩니다. 'GET' 그대로요.
type Success = { ok: true; data: string }
type Failure = { ok: false; error: string }
function handle(res: Success | Failure) {
if (res.ok) console.log(res.data);
else console.error(res.error);
}
판별 유니온(discriminated union)입니다. res.ok를 확인하는 것만으로 TypeScript가 나머지 필드를 알아서 좁혀줍니다. if 안에서는 data가, else에서는 error가 있다는 걸 컴파일러가 압니다. API 응답을 다룰 때 특히 좋은 패턴이에요.
그리고 점진적 도입 조언이 실용적입니다.
allowJs, checkJs 옵션으로 조금씩 TS 적용"전부 다 바꾸지 않아도 됩니다. .js 파일을 그대로 두고 새 파일만 .ts로 쓰면서 넓혀갈 수 있어요.
큐레이터 노트
"체크리스트"라는 형식을 정확히 살린 글이라 뽑았습니다.
입문서는 순서대로 읽어야 하지만, 체크리스트는 필요한 항목만 찾아보는 용도입니다. 이 글은 여덟 장이 각각 독립적이라 그렇게 쓸 수 있어요. tsconfig 설정이 궁금하면 5장만, 고급 타입이 필요하면 4장만 보면 됩니다.
컴파일 파이프라인을 넣은 것이 이 정리의 깊이를 만듭니다. 대부분의 TypeScript 정리는 문법만 다루는데, 이 글은 AST로 바뀌고, 타입이 검사되고, 그다음 타입이 사라진다는 과정을 짚었어요. "타입은 실행되지 않는다"를 이해하는 데 필요한 지식입니다.
릴리즈 노트까지 확인한 것도 눈에 띄었습니다. TS 5.0의 성능 개선, 5.5의 제어 흐름 분석 향상. 언어가 계속 바뀐다는 걸 아는 사람의 정리예요.
마지막 문장도 좋았습니다. "앞으로는 실제 프로젝트에 작은 단위로 적용해 보며 (…) 워크플로우를 차근차근 개선해 나갈 예정입니다." 정리로 끝나지 않고 다음 단계를 정해둔 기록입니다.
💡 세 편을 겹쳐 읽으며
CSR이 두 번 나온 우연으로 시작했는데, 세 글을 나란히 놓으니 다른 게 보입니다.
셋 다 "약속"에 대한 이야기입니다.
렌더링 방식은 서버와 브라우저 사이의 약속입니다. 누가 HTML을 만들 것인가, 언제 만들 것인가. 그리고 Hydration은 "이 그림은 곧 살아납니다"라는 약속이 지켜지는 순간이죠.
CSR(인증서 서명 요청)은 나와 인증기관 사이의 약속입니다. PKCS #10이라는 형식을 지켜야 서로 모르는 시스템끼리 대화가 돼요.
TypeScript는 개발자끼리의 약속입니다. "이 함수는 숫자 두 개를 받아 숫자를 돌려준다"를 코드에 적어두는 것. 그리고 그 약속은 실행 전에만 유효합니다. 컴파일이 끝나면 사라지니까요.
세 약속의 성격이 조금씩 다릅니다. 렌더링은 성능을 위한 약속이고, 인증서는 신뢰를 위한 약속이고, 타입은 사람을 위한 약속이에요.
그런데 공통점이 있습니다. 약속이 지켜지지 않는 지점을 알아야 제대로 쓸 수 있다는 것.
Hydration이 끝나기 전에는 버튼이 안 눌리고, 개인키가 새면 인증서는 의미가 없고, 타입은 런타임에 아무것도 막아주지 못합니다. 약속의 범위를 아는 것 — 세 글이 각자 그 지점을 짚었습니다.
이번 회차에서 가져갈 것
1. "보이는데 안 눌리는" 시간이 있다. SSR 페이지는 Hydration 전까지 그림입니다. 로딩 표시를 어떻게 둘지 생각해두세요. 사용자는 보이면 누릅니다.
2. 렌더링 방식은 "비용을 누가 언제 내는가". CSR은 사용자가, SSR은 서버가, SSG는 빌드 때 냅니다. 공짜인 방식은 없어요.
3. 개인키는 절대 내보내지 않는다. CSR에는 공개키만 들어갑니다. 인증서를 발급받는 과정에서 개인키를 어딘가에 올리라고 하면 그건 잘못된 절차예요.
4. 타입은 실행되지 않는다. 컴파일 후 전부 사라집니다. API 응답처럼 밖에서 오는 데이터는 런타임에 따로 검증해야 해요. 타입만 붙여두면 안전하다고 착각하기 쉽습니다.
5. 짧아도 남겨두기. 두 문장짜리 용어 정리도 시리즈 안에서는 자리가 있습니다. "이 정도는 너무 짧은데" 싶어 안 쓰면 나중에 지도에 구멍이 남아요.
좋은 글 남겨주신 이종경 님, 김영진 님, 박지훈 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.