heene

하이드레이션과 렌더링 전략별 차이

T없이맑은I — Mon, 6 Jul 2026 15:59:51 +0900

1. 기본 전략

Static Generation (SSG): 빌드 타임에 HTML을 미리 생성 → CDN에서 초고속 서빙. ISR(Incremental Static Regeneration)로 freshness 문제 해결 (revalidate). Edge Rendering으로 지연도 최소화.
Client-Side Rendering (CSR / SPA): 서버는 빈 shell만 주고, 클라이언트에서 JS 번들 + 데이터 페칭 후 모든 UI 생성. 하이드레이션 없음. 하지만 첫 페인트 느리고 SEO 불리.
Server-Side Rendering (SSR): 서버에서 HTML 생성 후 클라이언트에서 하이드레이션 (React가 DOM에 이벤트 핸들러 등 붙임). 콘텐츠 즉시 보이고 SEO 좋지만, 작업 중복 (서버 렌더 → 클라이언트 재렌더)과 하이드레이션 mismatch 문제가 있음.

2. 현대적 개선 전략

Streaming SSR + Suspense: 페이지 전체를 기다리지 않고 청크 단위로 스트리밍. Suspense boundary로 느린 부분(skeleton) 분리 → perceived performance 크게 향상. Progressive hydration (스크롤/인터랙션 시 지연 하이드레이션) 결합 가능.
Islands Architecture (Astro 대표): 대부분 정적 HTML로 두고, 인터랙티브한 부분만 "섬"처럼 JS + 하이드레이션. client:visible, client:load 등 directive로 제어. JS 번들 최소화에 최고 (콘텐츠 중심 사이트: 블로그, docs, 마케팅 페이지에 이상적).
React Server Components (RSC): 서버 전용 컴포넌트는 클라이언트에 JS 전혀 안 보냄 (Flight 형식으로 UI 설명만 직렬화). "use client"만 JS 번들. DB 직접 쿼리 가능, 번들 크기 대폭 감소. Partial Prerendering (React 19)으로 static shell + dynamic hole 결합.
기타:
- Fine-grained reactivity (e.g. Solid): 한 번 하이드레이션 후 re-render 거의 없음.
- Resumability (Qwik): 하이드레이션 자체를 거의 안 함.
- TanStack Start: ownership flipped 접근.
- Next.js 16.3: Instant navigations 등으로 마지막 갭 메움.

선택 가이드 (How to actually choose)

콘텐츠 중심 (블로그, docs, 마케팅): SSG/Islands/Astro
인터랙티브 앱 (대부분 동적): RSC + Streaming SSR (Next.js)
극한 성능: Fine-grained/Resumability 고려
항상 Lighthouse 점수, JS 번들 크기, 인터랙션 지연을 기준으로 판단.

출처: "Different hydration and rendering strategies" (Neciu Dan, 2026.6.28)

웹 앱의 초기 로딩 속도와 인터랙티브성 사이의 트레이드오프를 해결하기 위해 진화해 온 다양한 렌더링 + 하이드레이션 전략을 체계적으로 비교·설명합니다. 핵심은 "HTML이 보이는 순간"과 "실제로 클릭이 되는 순간" 사이의 갭(하이드레이션)을 줄이는 것.

모든 페이지를 하나의 전략으로 해결하려 하지 말고, 페이지 특성에 맞게 (또는 부분별로) 최적의 조합을 선택.

Gemma 4 12B LoRA 파인튜닝

T없이맑은I — Tue, 16 Jun 2026 13:48:50 +0900

로컬 맥북에서 Gemma 4 12B 모델을 내려받고, 작은 데이터셋으로 LoRA 파인튜닝을 진행했다. 실험은 체스 다음 수를 맞히는 형태로 구성했다. 다만 목표는 체스 엔진을 만드는 것이 아니라, 모델이 정해진 출력 형식을 더 잘 따르게 만들 수 있는지 확인하는 것이었다.

이번 실험에서 사용한 출력 형식은 UCI 체스 표기다. 예를 들어 일반 체스 표기에서는 Nf3라고 쓰지만, UCI 표기에서는 출발 칸과 도착 칸을 모두 포함해 g1f3라고 쓴다.

프로그램에서 후처리하려면 Nf3보다 g1f3가 더 명확하다. 그래서 모델에게 “답은 UCI 형식으로만 출력하라”는 작은 규칙을 학습시키는 실험을 진행했다.

사용한 모델

사용한 모델은 MLX용 Gemma 4 12B 모델이다.

처음에 막힌 부분

처음에는 mlx-lm CLI만으로 바로 실행하려고 했다. 하지만 Gemma 4 12B의 gemma4_unified 모델 타입을 읽지 못하는 문제가 있었다.

이 문제는 프로젝트 전용 Python 가상환경을 만들고, mlx-optiq와 GitHub 최신 mlx-lm을 설치해서 해결했다.

설치 명령은 다음과 같다.

.venv/bin/python -m pip install -U mlx-optiq "mlx-lm @ git+https://github.com/ml-explore/mlx-lm.git"

핵심은 실행 코드에서 import optiq를 먼저 호출하는 것이었다. 이 import가 Gemma 4 unified 모델 타입을 등록해준다. 이 과정을 거친 뒤에는 모델 로딩과 생성이 정상 동작했다.

데이터셋 구성

데이터셋은 의도적으로 작게 만들었다. 큰 성능 실험이 아니라, 로컬 파인튜닝 파이프라인이 실제로 동작하는지 확인하는 목적이었기 때문이다.

구성은 다음과 같다.

학습 데이터: 32개
검증 데이터: 8개
테스트 데이터: 8개
전후 비교용 평가 데이터: 16개

데이터는 채팅 형식 JSONL로 만들었다. 한 줄은 하나의 학습 예제다.

예시는 다음과 같다.

{
  "messages": [
    {
      "role": "system",
      "content": "You are a chess next-move assistant. Return exactly one legal UCI move and no explanation."
    },
    {
      "role": "user",
      "content": "Chess drill italian_develop_knight. Moves so far: 1. e4 e5. Side to move: White. Plan: develop the king-side knight toward the center. Reply with the best next move in UCI."
    },
    {
      "role": "assistant",
      "content": "g1f3"
    }
  ]
}

베이스라인 평가

파인튜닝 전 모델에 평가 질문 16개를 먼저 입력했다. 이 값을 베이스라인으로 사용했다.

결과는 0개 정답이었다.

베이스라인: 0/16 = 0.0%

이 결과만 보면 모델이 체스를 전혀 모르는 것처럼 보일 수 있다. 하지만 실제 출력은 그렇지 않았다.

예를 들어 정답이 g1f3인 문제에서 모델은 Nf3라고 답했다. 정답이 e7e6인 문제에서는 e6라고 답했다. 정답이 c7c6인 문제에서는 c6라고 답했다.

즉, 체스 수 자체는 어느 정도 맞췄지만, 내가 요구한 UCI 형식은 지키지 못했다. 이번 평가에서는 출력 형식을 엄격하게 봤기 때문에 Nf3, e6, c6는 모두 오답으로 처리했다.

LoRA 튜닝 설정

최종 실험에서는 다음 설정으로 LoRA 튜닝을 진행했다.

iters: 300
num_layers: 16
batch_size: 1
learning_rate: 1e-4
max_seq_length: 1024
mask_prompt: on

mask_prompt 옵션을 켠 것이 중요했다. 이 옵션은 질문 부분보다 assistant의 답변 부분에 학습을 집중하게 한다.

이번 실험의 목적은 질문을 외우게 하는 것이 아니라, 답을 UCI 형식으로 출력하게 만드는 것이었다. 그래서 mask_prompt를 켠 설정이 더 적합했다.

학습 가능한 파라미터는 전체 모델의 0.092%였다.

Trainable parameters: 0.092% (10.930M / 11907.350M)

걸린 시간

실행 시간은 다음과 같았다.

단계	시간
베이스라인 평가	8초
LoRA 튜닝	84초
LoRA 적용 후 평가	10초
전체 실행	214초

작은 데이터셋을 사용했기 때문에 학습 자체는 오래 걸리지 않았다.

튜닝 후 결과

LoRA 튜닝 후 같은 16개 평가 질문을 다시 입력했다.

결과는 다음과 같다.

LoRA 적용 후: 10/16 = 62.5%

베이스라인은 0/16이었고, LoRA 적용 후에는 10/16을 맞췄다.

0.0% -> 62.5%

표현을 바꿔서 물어본 평가 데이터에서도 8개 중 6개를 맞췄다. 단순히 학습 문장을 그대로 외운 결과만은 아니라고 볼 수 있다.

다만 모든 문제가 해결된 것은 아니다. French Defense나 English Opening 관련 일부 케이스에서는 여전히 다른 UCI 수를 출력했다.

결과 해석

이번 결과는 Gemma 4 12B의 체스 실력이 전반적으로 좋아졌다는 뜻은 아니다.

이번 실험에서 확인한 것은 더 좁은 내용이다.

작은 체스 지시 데이터에서, 모델이 UCI 형식으로 답하는 능력이 개선됐다.

베이스라인 모델은 체스적으로 그럴듯한 수를 일반 표기로 답하는 경우가 많았다. LoRA 튜닝 후에는 지정한 UCI 형식으로 답하는 비율이 올라갔다.

따라서 이 실험은 “체스 엔진 성능 개선”이 아니라 “출력 형식 교정” 실험으로 보는 것이 맞다.

한계

이번 실험에는 한계가 있다.

데이터셋이 작다.
오프닝 중심의 단순한 예제만 사용했다.
합법수 검증을 별도로 하지 않았다.
Stockfish 같은 체스 엔진과 비교하지 않았다.
체스 실력 전체가 아니라 출력 형식만 평가했다.

정확한 체스 성능 평가를 하려면 더 큰 데이터셋과 별도 검증 환경이 필요하다.

정리

이번 실험에서는 로컬 Apple Silicon 환경에서 Gemma 4 12B LoRA 튜닝을 실제로 실행했다.

이번 실험은 작은 규모였지만, 로컬 맥북에서 모델 다운로드, 평가, LoRA 튜닝, 결과 비교까지 한 번에 진행할 수 있다는 점을 확인했다.

우리는 모두 시스템 아키텍처 전문가가 되어야 한다

T없이맑은I — Sat, 6 Jun 2026 08:41:51 +0900

AI 시대가 본격화되면서 개발자의 역할이 근본적으로 바뀌고 있다. 과거에는 개인 전문성에 의존해 직접 코드를 작성하고 문제를 해결했다면, 이제는 전문성 에이전트(Expert Agents) 를 설계하고, 이들이 제품 개발 생애주기(SDLC) 전체에서 원활하게 협력할 수 있는 시스템 아키텍처를 구축하는 것이 핵심 역량이 되었다.

과거의 개발 방식 (Pre-AI)

프론트엔드 개발자는 디자인 시안과 백엔드 API 설계도를 받아 제품을 직접 완성했다.
개발 완료 후 QA 팀에게 수동 핸드오프를 했다.
각 역할(기획, 디자인, 프론트, 백엔드, QA)이 비교적 명확하게 분리되어 있었고, 개인의 숙련도와 경험에 크게 의존했다.

현재의 개발 방식 (AI 에이전트 시대)

프론트엔드 개발자는 더 이상 UI를 하나하나 코딩하지 않는다. 대신 프론트엔드 전문 에이전트를 설계·구현한다.
이 에이전트는 주어진 디자인 시스템, 컴포넌트 라이브러리, API 스펙을 이해하고, 요구사항에 따라 화면을 자동으로 생성·수정한다.
개발이 완료되면 QA 에이전트에게 자동으로 핸드오프된다.
QA 에이전트는 기능 검증, 엣지 케이스 테스트, 성능·접근성·보안 체크 등 최종 출시를 위한 검증을 수행한다.
전체 과정은 시스템적으로 관리되며, 각 에이전트 간의 입력·출력 인터페이스, 상태 관리, 에러 핸들링, 재시도 로직 등이 명확하게 정의된다.

핵심 메시지: 시스템 아키텍처 사고방식의 전환

이제 개발자에게 가장 중요한 역량은 다음과 같다:

에이전트 설계 능력
- 특정 도메인(프론트엔드, 백엔드, QA, DevOps 등)의 전문성을 에이전트 형태로 추출하고 체계화하는 능력
시스템 오케스트레이션 능력
- 여러 에이전트가 SDLC 전 단계(기획 → 디자인 → 개발 → 테스트 → 배포 → 모니터링)에서 자연스럽게 연결되고 협력할 수 있는 워크플로우 설계
인터페이스와 거버넌스 설계
- 에이전트 간 데이터 교환 형식, 프롬프트 엔지니어링 표준, 검증 기준, 인간 개입 지점(Human-in-the-Loop) 정의
전체 시스템의 신뢰성·확장성 확보
- 에이전트가 실패했을 때의 fallback 전략, 성능 병목 지점 관리, 비용 최적화 등

결론

AI 시대의 진짜 고수는 더 이상 코드 잘 쓰는 사람이 아니다.
최고의 전문 에이전트들을 설계하고, 그들이 하나의 유기적인 시스템으로 작동하도록 아키텍처를 그릴 수 있는 사람이다.

우리는 이제 개인 생산성 시대를 넘어 시스템 생산성 시대로 진입하고 있다.
이 변화에 빠르게 적응하는 개발자만이 앞으로도 경쟁력을 유지할 수 있을 것이다.

2026년 6월

T없이맑은I — Thu, 4 Jun 2026 09:36:59 +0900

코드가 저렴해지면 무엇이 남는가?

엘라스틱서치의 영구적인 에이전트 메모리 계층 설계

AI 시대에 쿠버네티스 활용
- LLM 개발: Kubernetes는 확장성과 유연성을 바탕으로 AI 및 LLM 모델의 사전 학습, 미세 조정, 배포 및 신속한 엔지니어링을 위한 효율적인 플랫폼으로 매우 적합
- AI 에이전트 오케스트레이션: 클라우드 네이티브 기술과 널리 사용되는 프로토콜을 결합함으로써 이제 에이전트는 임시 데모에서 쿠버네티스와 같은 시스템에서 실행되는 복잡한 에이전트 클러스터로 발전하고 있습니다.

루프 엔지니어링

- 프롬프트 > 컨텍스트 > 하네스 > 루프

리액트 성능 개선

- 내용을 바탕으로 스킬로 별도로 제작.

시니어 엔지니어에게 필요한 LLM의 모든것.

Tanstack Start 의 멘탈 모델, Nextjs 개발자를 위한.

- Tanstack Start: 더 명시적이고 타입 안정성이고 라우터 퍼스트.
- Next.js: 더 암시적이고 엄격한 컨벤션이며 서버 퍼스트.

Tanstack Table 에서 메모리를 90% 줄인 방법

- 테이블에서 발생하는 수백만개의 객체의 중복된 메서드들을 매번 새로 생성 -> 테이블에서 하나의 인스턴스로 프로토타입을 생성하여 모든 객체가 동일한 메서드를 가지고 값(데이터)만 별도로 정의.

2억 4천만 개의 도메인 이름에 대한 p99 0ms 자동 완성

- 인기 있는 상위 도메인 (Tranco Top 1M): 메모리 기반 Trie(트라이) 구조로 초고속 검색.
- 전체 도메인 (2.4억 개, CZDS): SSD에 메모리 맵핑 + 블록 인덱싱으로 효율적으로 검색 (디스크 2.5GB).

LLM 앱을 만들기 위한 12가지 원칙

- https://12factor.net/

서비스 워커가 필요없을 수도?

- 오프라인 지원·푸시 알림·백그라운드 싱크 같은 핵심 기능 외에는 대부분 HTTP 캐싱, 콘텐츠 해싱, 서버사이드 처리 등 더 간단한 방법으로 대체할 수 있다.

Linear 앱의 초고속 성능을 가능하게 하는 핵심 웹 성능 최적화 방법

T없이맑은I — Fri, 29 May 2026 14:58:12 +0900

1. 브라우저 내 데이터베이스 (Local-First Architecture) — 가장 중요한 기반

IndexedDB를 실제 DB로 사용하고, MobX observable로 in-memory 그래프를 만듦.
UI는 항상 로컬 데이터를 읽음 → 네트워크 요청 없이 즉시 반영.
Mutation(변경)은 로컬에서 먼저 적용 → UI 즉시 re-render → 백그라운드에서 서버 동기화.
- issue.title = "new title"; issue.save(); 형태 (optimistic update).
서버는 Sync Target (동기화 대상)이지 Truth Source가 아님.
Sync Engine: WebSocket으로 delta(변경분)만 주고받음. 변경 시 granular re-render (필드 단위 MobX observer).

효과: Spinner, skeleton, loading state를 거의 없앰. 네트워크가 가장 큰 병목인데, 이를 사용자 경험에서 완전히 숨김.

실무 적용 팁:

TanStack Query + SWR의 optimistic update로 비슷하게 구현 가능.
대규모 데이터는 lazy hydration (Issue, Comment 테이블 등).

2. 초기 로드(First Load) 극한 최적화

Linear는 Client-Side Rendering(CSR)을 유지하면서도 첫 로드가 매우 빠름.

번들 최적화:
- Parcel → Rollup → Vite → Rolldown으로 여러 번 마이그레이션.
- Legacy 브라우저 지원 포기 (polyfill, ES5 transpilation 제거) → JS 크기 50% 감소.
- Aggressive Code Splitting: Route-level + Vendor per package chunk.
- 결과: Cold cache 로드 10~30% 빨라짐, 메모리 70-80% 감소.
Preloading & Parallel Fetch:
- <link rel="modulepreload">로 entry script가 필요로 하는 모든 chunk를 병렬로 미리 로드.
- Waterfall 방지 → import 시 이미 캐시에 있음.
Service Worker Precache:
- 로그인 화면에서 background로 ~1,200개 asset (route chunks, icons, fonts) precache.
- 이후 navigation은 네트워크 완전 스킵 (Cache-first).
- 오프라인 지원까지 제공.
Inlined App Shell:
- <head>에 critical CSS + JS 인라인 (테마, sidebar width, login 상태 등 localStorage 기반).
- 첫 페인트 전에 사용자 맞춤 shell 렌더링 → "앱이 바로 준비된" 느낌.
Font 최적화:
- Variable Font (Inter Variable.woff2 하나로 100-900 weight).
- font-display: swap + crossorigin preload로 FOUT/FOIT 방지.
Render First, Auth Second:
- 로컬에 데이터 있으면 바로 렌더링 → 백그라운드에서 auth/ sync 검증.
- Happy path 가정 (optimistic auth).

3. Designed for Speed (설계/UX 측면)

성능은 엔지니어링뿐 아니라 디자인 문제:

Keyboard-first: 거의 모든 액션에 shortcut (단축키).
Command Palette (⌘K): 로컬 MobX 데이터 검색 → 네트워크 없이 초고속.
마우스 경로 최소화 → 사용자 체감 속도 극대화.

4. Animations

100ms 이하 duration (인간이 즉시 반응으로 느끼는 threshold).
GPU acceleration (transform, opacity 위주).
Layout shift 유발 속성 (width, height 등) 애니메이션 금지.

전체 아키텍처 요약 (성능의 본질)

계층	전통적 방식	Linear 방식	성능 영향
데이터	Server → API	Browser (IndexedDB + MobX)	즉시 반영
Mutation	Await network	Optimistic + background sync	No spinner
Initial Load	Heavy bundle + sequential	Tiny chunks + preload + SW	Instant feel
Update	Full re-render	Granular observable	Smooth even with many changes
Navigation	Network each time	SW cache	Instant

핵심 교훈:

네트워크를 숨겨라 (Local-first + Optimistic + Preload/SW).
작은 것들의 집합이 큰 성능 차이를 만든다 (번들, font, shell, animation 등 세부 디테일).
단순함을 유지 (React + MobX + Postgres, fancy framework 최소).

이 접근은 모든 웹 앱에 적용할 수 있습니다. 특히 생산성 도구, 대시보드, 협업 앱에서 Local-first + Optimistic update + 철저한 code splitting + SW를 조합하면 Linear에 가까운 경험을 낼 수 있어요.

더 구체적인 부분(예: sync engine 세부나 코드 예시)이 필요하시면 말씀해주세요!

출처: https://performance.dev/how-is-linear-so-fast-a-technical-breakdown

2026년 5월

T없이맑은I — Fri, 8 May 2026 11:52:53 +0900

경력과 상관없이 당신을 아마추어 처럼 보이게 하는 4가지 행동

에이전트 메모리 작동 방식

20가지 엔지니어링 법칙

2025년 4월

T없이맑은I — Sat, 11 Apr 2026 16:16:17 +0900

Tanstack ai code mode

- AI 에이전트 구축시 코딩이나 수학적 계산에 특화된 에이전트를 개발할 때 매우 유용할 도구

Research-driven Agents

- 코드 작성같이 직접적인 액션 전에 '연구 단계(논문 읽기 + 경쟁 프로젝트 분석)' 같은 액션을 사전에 취함으로써 더욱더 품질을 높일수 있는 방법에 대해서 말한다. 한계가 있지만 적절한 환경과 시점에 해당 과정을 진행하게 된다면 품질을 높일 수 있을 것으로 본다.

LLM에 대해서 이야기 해봅시다

- 저자는 LLM이 본질적 어려움을 해결하지는 못하고 있다고 본다. 본질적 어려움(명세·설계·테스트)을 공략해야 한다고 말한다. 미래에 나타날 모델은 이런 부분까지 해결해줄 수 있을지 모르겠지만 현재로선 저자의 주장에 동의한다.

유출된 Claude Code 아키텍처와 정보를 쉽게 확인할 수 있는 웹사이트

여전히 MCP를 더 선호합니다. Skills 보다.

LLM Wiki

- 안드레이 카파시의 RAG의 한계를 극복하기 위한 제안

IAM 의 모든 것

- 인증을 처리하는 과정

마티파울러가 말하는 지금 AI 시대에 승리할 수 있는 길
- 최근 읽었던 글들 중 가장 심플하면서 임팩트 있는 글.

더 나은 UI 스킬

보이스 에이전트
- 일레븐랩스의 scratch 를 통해서 어떻게 500ms 레이턴시 응답을 구축했나?

AEM(Agentic Engineering Management)은 무엇이고 어떻게 할 수 있나?

AEM을 구현하려면 회피보다는 발견과 복구에 더 많은 투자를 하는 특정한 조직 문화와 사고방식이 필요합니다. 에이전트의 자율성은 설계상 저위험 영역을 목표로 하며, 적절한 관측성과 신속한 복구를 병행하면 실제 리스크는 상당히 낮습니다. 하지만 이러한 에이전트를 도입하고 자율적으로 작동하게 하려면, 실수를 일상적인 일로 받아들이고 신속한 완화, 복구 및 학습에 초점을 맞추는 문화적 변화가 필요합니다. 두려움과 안전에 기반한 예방 중심의 문화는 이러한 접근 방식을 도입하는 데 어려움을 겪을 것입니다.

- 너무 공감하는 내용이다. 실수를 적극적으로 회피할수록 시스템은 경직되고 변화 유연성을 희생해야만 한다. 누구나 실수한다. 이 실수를 빠르게 복구하고 대처할 수 있는 시스템을 구축하는게 더 중요하다.

AI가 사고방식을 대체하는 것이 아니다

2026년 3월

T없이맑은I — Mon, 16 Mar 2026 12:14:03 +0900

SSE, tRPC, Redis를 이용한 실시간 데이터 처리 아키텍처

소프트웨어 엔지니어링의 미래 with Anthropic

클로드 코드가 우리 팀을 망치는 걸까?

- 코딩 에이전트 때문에 본인의 타이틀을 넘어서 다른 직군의 업무도 소화할 수 있다 보니 서로에게 영향(부정적인)을 끼칠 수 있는 상황을 말함. 비유적으로 Mexican standoff 라고 한다. 코딩 에이전트 때문에 전통적인 조직의 구성과 역할이 빠르게 무너지고 있는 상황.

당신이 코딩해서 돈을 버는건 아니에요.

- 엔지니어라면 당연히 코딩이 자신의 전부가 아니고 가장 중요한 부분도 아니라는 것을 이해해야만 한다.

사고력이 코딩 보다 중요한 시대: 어떻게 AI 시대에 엔지니어를 고용해야 할까?

시각화로 변환

- AI 덕에 시각화 비용이 낮아졌으므로 모든 커뮤니케이션은 시각화 자료가 우선 되야할 것으로 본다.

OpenAI 에서 배운 것들

- 이 글에서 AI 시대에 중요한 도전과제들이 여전히 남아있으며 AI 로 인해서 파생될 또 다른 도전과제들이 여전히 인간의 몫으로 주어지지 않을까 생각한다.