HTML over WebSockets: 거의 JavaScript 없이 실시간 SPA 만들기 (Andros Fenollosa)핵심 아이디어전통적인 SPA는 JS 프레임워크가 뷰를 그리고, API가 JSON을 주고받으며 두 코드베이스가 계약을 맞춰야 한다.이 글은 그 대신 서버가 이미 렌더링한 HTML을 WebSocket으로 보내고, 클라이언트는 그걸 제자리에 꽂기만 하는 방식(HTML over the wire / hypermedia)을 소개한다.동작 방식클라이언트의 JS 역할은 렌더링이 아니라 WebSocket 채널 생성 + 받은 HTML 삽입(애니메이션, 이벤트 처리 등 보조 작업 포함).서버가 템플릿 엔진으로 HTML을 만들고 WebSocket으로 전송.채널이 항상 열려 있어서 서버가 클라이언트의 요청..

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 좋지만, 작업 중복 (서버 렌..

로컬 맥북에서 Gemma 4 12B 모델을 내려받고, 작은 데이터셋으로 LoRA 파인튜닝을 진행했다. 실험은 체스 다음 수를 맞히는 형태로 구성했다. 다만 목표는 체스 엔진을 만드는 것이 아니라, 모델이 정해진 출력 형식을 더 잘 따르게 만들 수 있는지 확인하는 것이었다.이번 실험에서 사용한 출력 형식은 UCI 체스 표기다. 예를 들어 일반 체스 표기에서는 Nf3라고 쓰지만, UCI 표기에서는 출발 칸과 도착 칸을 모두 포함해 g1f3라고 쓴다.프로그램에서 후처리하려면 Nf3보다 g1f3가 더 명확하다. 그래서 모델에게 “답은 UCI 형식으로만 출력하라”는 작은 규칙을 학습시키는 실험을 진행했다.사용한 모델사용한 모델은 MLX용 Gemma 4 12B 모델이다.처음에 막힌 부분처음에는 mlx-lm CLI만..

AI 시대가 본격화되면서 개발자의 역할이 근본적으로 바뀌고 있다. 과거에는 개인 전문성에 의존해 직접 코드를 작성하고 문제를 해결했다면, 이제는 전문성 에이전트(Expert Agents) 를 설계하고, 이들이 제품 개발 생애주기(SDLC) 전체에서 원활하게 협력할 수 있는 시스템 아키텍처를 구축하는 것이 핵심 역량이 되었다.과거의 개발 방식 (Pre-AI)프론트엔드 개발자는 디자인 시안과 백엔드 API 설계도를 받아 제품을 직접 완성했다.개발 완료 후 QA 팀에게 수동 핸드오프를 했다.각 역할(기획, 디자인, 프론트, 백엔드, QA)이 비교적 명확하게 분리되어 있었고, 개인의 숙련도와 경험에 크게 의존했다.현재의 개발 방식 (AI 에이전트 시대)프론트엔드 개발자는 더 이상 UI를 하나하나 코딩하지 않는다..

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 ..

기존 프로젝트 기존에는 CRA(create-react-app)로 구축되어 있었고 정적 파일로 빌드되어 단순히 S3에 호스팅 되는 구조로 심플하고 인프라 관리가 쉬운 형태이다. 브라우저 환경에서만 구동되는 것을 가정하고 작성한 아주 심플한 프로젝트였다. 규모는 비교적 작은 수준으로 서버 API는 graphQL 사용해서 아폴로 클라이언트가 API 레이어를 담당하고 styled-components로 스타일링 하고 있었다. Next.js로 전환 니즈는 방대한 컨텐츠에 대한 동적 SEO 지원이었다. 정적 파일로는 규모가 큰 콘텐츠의 SEO를 지원하는 데에 분명한 한계가 있었고 이를 해결하고자 SSR(server-side-rendering)이 필요했다. 브라우저 환경과 서버(Node)환경 두 가지 환경에서 동시에 ..