원문: https://youtu.be/-Z_0KNu8uQg
채널: Cloud Codes | 길이: 9:21 | 처리일: 2026-07-13
1. 핵심 주장: AI가 코드를 쓰는 시대, 이기는 스택은 달라진다
1-1. 패러다임의 전환
- Go, HTMX, SQLite — 세 가지 모두 새로운 기술이 아니다. 지루하고 오래된 기술이다.
- 그런데 AI 시대에는 바로 이 "지루한 기술들"이 최강의 조합이 된다.
- AI가 코드 대부분을 작성하는 지금, 이기는 스택은 가장 큰 생태계가 있는 스택이 아니라, AI가 처음 시도에서 올바르게 생성할 수 있는 스택이다.
- 이것이 거의 모든 사람이 놓친 핵심적인 전환이다.
1-2. AI의 네이티브 출력은 HTML
- Anthropic 엔지니어가 올해 조용히 보여준 사실: AI 모델에게 태스크를 주고 내버려두면, 돌아오는 결과물은 HTML이다.
- 테이블, 레이아웃, 작은 인터랙티브 위젯 — 아무도 프롬프트하지 않아도 AI는 HTML로 돌아온다.
- 이유는 단순하다. HTML이 브라우저가 실제로 렌더링하는 것이기 때문이다.
- JSX, 템플릿 언어, 마크다운 패스 — 이 모든 것은 AI에게 "번역"을 요청하는 것이다.
- 번역은 새어나간다(translations leak). 번역이 적을수록 실수가 숨을 곳도 적다.
2. HTMX: 프론트엔드 번역 레이어 삭제
2-1. 왜 HTMX인가
- AI 모델은 HTML을 생각한다. 그런데 왜 우리는 AI에게 HTML로 다시 컴파일되는 JavaScript를 쓰라고 계속 요청하는가?
- React로 에이전트가 코드를 쓸 때, 아이디어는 두 개의 번역 레이어를 거친다:
AI 머릿속 HTML → JSX로 출력 → 빌드 스텝 → 다시 HTML- 각 홉(hop)마다 틀릴 기회가 생긴다.
- HTMX는 이 레이어들을 제거한다. 서버가 HTML을 보내고, 브라우저가 페이지에 교체한다. 그게 전부다.
2-2. HTMX 코드가 말하는 것
- 버튼 하나에 속성 하나:
hx-get="/url" hx-target="#here"— 이 URL에서 GET하고 답을 여기에 넣어라. - 서버는 평범한 HTML 스니펫을 반환한다. HTMX가 페이지에 끼워 넣고, 주소창을 업데이트한다.
- 이것이 전체 트릭이다. 빌드 스텝이 없다.
- 컴포넌트 트리 없음, 서버와 어긋날 수 있는 클라이언트 상태 없음, 자정의 hydration 불일치 없음.
- AI가 이것을 쓸 수 있다. 그리고 인간이 한 눈에 읽고 맞는지 볼 수 있다. 리뷰어가 병목이 되지 않는다.
2-3. HTMX의 강력함
- 검색창에 속성 몇 개를 추가하면: 타이핑하면서 서버에 쿼리, 디바운스, 결과가 목록에 스트리밍 — 100줄짜리 React 상태 관리가 몇 줄의 HTML이 된다.
- AI가 자꾸 범하는 React 실수들: Hook 순서 규칙, 오래된 effect 의존성, controlled vs uncontrolled 입력. 타입 체커를 통과하고 런타임에만 터지는 것들.
- "HTML은 와이어로 보내기엔 너무 장황하다"는 규칙은 8,000 토큰 시대의 규칙이었다. 지금 모델은 100만 토큰을 한 번에 읽는다. 장황함 비용은 거의 없고, 명확함의 가치는 크다.
- 스펙: 14KB 압축, 의존성 제로, GitHub 별 48,000개, 버전 4 베타 진행 중.
- 웹이 15년간 점점 복잡해졌다. 이것은 그 스프링이 드디어 풀리는 것이다.
3. Go: 배포 복잡성과 타입 실수 삭제
3-1. AI가 Go를 잘 쓰는 이유
- Go는 각 작업을 하는 명확한 방법이 하나뿐이도록 설계되었다.
- 작은 언어, 작은 표면적 → AI가 길을 잃고 환각(hallucinate)으로 빠질 영리한 구석이 거의 없다.
3-2. 완전한 웹 서버 예시
import net/http표준 라이브러리에서 핸들러 정의, 포트에 리슨.- 선택할 프레임워크 없음, 설치할 의존성 없음, 축복받을 설정 파일 없음.
- 실제 트래픽을 서빙하는 데 필요한 배터리가 이미 박스 안에 있다.
3-3. 단일 바이너리의 힘
- 빌드: 몇 초 만에 컴파일. 순환 임포트는 하드 에러 → 의존성 그래프가 깔끔한 트리 유지.
- 결과물: 단 하나의 정적 바이너리. 인터프리터 없음, 가상 머신 없음, 매칭해야 할 공유 라이브러리 없음.
- 배포하는 기계(AI 에이전트)에게 무엇을 주는지 생각해보라: node_modules 폴더 없음, lock file 복불복 없음. 바이너리 하나, 몇 메가바이트, 노트북과 5달러 서버에서 동일하게 작동.
3-4. AI 안전망으로서의 컴파일러
- AI가 타입을 잘못 추측하거나 에러 처리를 잊으면, Go는 빌드를 거부한다. 실수가 당신 컴퓨터에서 몇 초 만에 죽는다. 새벽 2시 프로덕션이 아니라.
- Go는 에러를 발생하는 곳에서 공개적으로 처리하도록 강제한다 → AI가 눈에 안 보이는 예외처럼 조용히 실패를 삼킬 수 없다. 무엇이 잘못될 수 있는지가 항상 평문으로 적혀있다.
- 동시성 내장: 요청당 하나의 고루틴, 수천 개가 동시에 실행. AI가 유창하게 쓰는 언어로.
3-5. Go의 진지한 채택 증거
- Microsoft가 TypeScript 컴파일러 전체를 Go로 재작성 → 대략 10배 속도 향상.
- JavaScript 세계 자체가 진짜 성능이 필요할 때 조용히 Go에 손을 뻗는다.
4. SQLite: 데이터베이스 티어 전체 삭제
4-1. SQLite가 조용히 제거하는 것들
- 실행할 두 번째 머신 없음.
- 데이터까지 네트워크 홉 없음.
- 조정할 연결 풀 없음.
- 로그로 새어나갈 환경 변수에 앉아있는 자격 증명 없음.
4-2. 성능: 왜 그렇게 빠른가
- 쿼리가 코드와 완전히 동일한 프로세스 안에서 실행된다.
- 읽기는 네트워크를 가로지르는 왕복이 아닌 함수 호출이다.
- 데이터는 이미 거기 있다. 메모리에, 요청한 코드 바로 옆에.
- 결과: 읽기 1밀리초 미만, 쓰기 초당 수만 건.
- 대부분의 앱에서 이것은 트레이드오프가 아니라 업그레이드다.
4-3. 지구상 가장 많이 배포된 데이터베이스
- 폰, 브라우저, 자동차에 들어있다.
- 2026년, SQLite는 조용히 프로토타입 장난감에서 프로덕션 기본값으로 졸업했다.
4-4. "백업은요? 내구성은요?" — Litestream
- Litestream: SQLite의 write-ahead 로그를 테일하고, 모든 단일 변경사항을 클라우드 오브젝트 스토리지로 지속적으로 스트리밍.
- 결과: 포인트인타임 복구, 그리고 여전히 데이터베이스 서버 없음.
4-5. 진짜 글로벌 스케일이 필요할 때 — Turso
- Turso: 동일한 파일을 30개 리전에 복제, 읽기가 600마이크로초에 착지.
- 국가 반대편 데이터센터의 managed Postgres보다 최대 1,000배 빠른 읽기.
- 멀티테넌트 SaaS를 더 단순하게: 고객마다 자체 데이터베이스 부여 — 데이터베이스가 그냥 파일이니까.
- 새 파일 생성 비용: 없음. 완벽한 격리. 계정 삭제 = 파일 삭제.
4-6. AI 시대의 핵심 기능
- SQLite에서 이제 **전문 검색(full-text search)과 벡터 검색(vector search)**을 같은 파일 안에서 할 수 있다.
- 임베딩, 문서, 앱 데이터 — 모두 함께. RAG 앱 전체 검색 레이어를, 추가 배포나 비용 없이.
- AI가 SQL 쿼리를 쓸 때: 쿼리를 쓰는 것과 실행하는 것이 정확히 같은 언어를 말한다. 중간에 번역하고 숨기는 ORM 레이어 없음.
5. 이 스택이 AI 시대에 완결되는 이유
5-1. 전체 코드베이스를 AI가 머릿속에
- 이 스택은 충분히 작아서 에이전트가 전체 코드베이스를 한 번에 머릿속에 담을 수 있다.
- 숨겨진 프레임워크 마법 없음, 생성된 파일 없음, 방대한 의존성 트리 없음.
- AI가 전체를 읽을 수 있다. AI가 이해하는 코드가 AI가 올바르게 쓰는 코드다.
5-2. 세 기술이 각각 제거하는 레이어
| 기술 | 제거하는 것 |
|---|---|
| HTMX | 프론트엔드 번역 레이어 |
| Go | 배포 복잡성 + 타입 실수 |
| SQLite | 데이터베이스 티어 전체 |
- 지루한 세 가지 선택. 그리고 각각은 AI가 그렇지 않았으면 미끄러질 레이어를 하나씩 지운다.
5-3. 요약 숫자 4가지
- 파일 1개 — 데이터베이스용
- 바이너리 1개 — 배포용
- 14KB — 프론트엔드
- 번역 레이어 0개 — 모델과 화면 사이
목적적으로 지루하고, 거의 우연처럼 강력하다.
6. 솔직한 한계 (약속한 catch)
6-1. SQLite의 한계
- 동시에 여러 머신에서 무거운 지속적인 쓰기가 필요하다면: 거래 엔진, 로그 파이어호스 → Postgres를 써라.
- SQLite는 한 번에 쓰기 하나만 — 이건 진짜 상한선이다.
6-2. HTMX의 한계
- Figma, 실시간 협업 스프레드시트, 깊은 클라이언트 사이드 상태가 있는 모든 것을 만든다면 → React와 그 생태계가 여전히 모든 킬로바이트를 정당화한다.
- HTMX는 하이퍼미디어 앱을 위한 것. 그것이 대부분의 앱이다. 전부는 아니다.
6-3. 이 스택이 빛나는 곳
- 거대한 중간 지대: 대시보드, 내부 툴, SaaS 제품 — AI가 지금 수천 개씩 쓰고 있는 바로 그것들.
- 이 조용한 트리오는 전체 판에서 가장 강력한 베팅 중 하나다.
핵심 요약 (20줄)
- AI 시대에 이기는 스택은 생태계가 가장 큰 스택이 아니라, AI가 처음 시도에서 올바르게 생성할 수 있는 스택이다.
- Anthropic 엔지니어 실험: AI에게 태스크를 맡기고 내버려두면 돌아오는 결과물은 항상 HTML이다.
- React 코드를 AI가 쓸 때는 "HTML→JSX→빌드→HTML"의 이중 번역 레이어를 거치며, 각 단계마다 실수가 숨을 공간이 생긴다.
- HTMX는 이 번역 레이어를 완전히 제거한다: 서버가 HTML을 보내고 브라우저가 페이지에 교체할 뿐이다.
- HTMX 코드는 버튼 하나에 속성 하나로 끝난다 — 빌드 스텝 없음, 컴포넌트 트리 없음, hydration 불일치 없음.
- 100만 토큰 컨텍스트 시대에 "HTML은 너무 장황하다"는 규칙은 이미 무효가 됐다.
- HTMX: 14KB 압축, 의존성 제로, GitHub 별 48,000개, 버전 4 베타.
- Go는 각 작업을 하는 명확한 방법이 하나뿐이도록 설계됐다 — AI가 환각으로 빠질 영리한 구석이 거의 없다.
- Go는 빌드하면 단일 정적 바이너리 하나가 나온다 — 설치할 것 없고, 파일 하나를 서버에 복사하면 끝.
- Go 컴파일러가 AI 안전망: 타입 실수나 에러 미처리 시 빌드 거부 — 새벽 2시 프로덕션 장애가 아닌 개발 머신에서 즉각 사망.
- Microsoft가 TypeScript 컴파일러 전체를 Go로 재작성해 약 10배 성능 향상 달성.
- SQLite는 데이터베이스 서버가 없다 — 실행할 두 번째 머신도, 네트워크 홉도, 연결 풀도, 새어나갈 자격 증명도 없다.
- SQLite 읽기는 네트워크 왕복이 아닌 함수 호출 — 데이터가 코드와 같은 프로세스에 있어 1밀리초 미만이 나온다.
- SQLite는 2026년 프로토타입 장난감에서 프로덕션 기본값으로 조용히 졸업했다.
- Litestream이 write-ahead 로그를 클라우드에 스트리밍 → 서버 없이 포인트인타임 복구 제공.
- Turso가 SQLite를 30개 리전에 복제하면 읽기 600마이크로초 — 원거리 Postgres보다 최대 1,000배 빠르다.
- SQLite에서 이제 전문 검색과 벡터 검색이 된다 — RAG 앱 전체 검색 레이어를 추가 인프라 없이 구현 가능.
- 이 스택은 작아서 AI 에이전트가 전체 코드베이스를 한 번에 머릿속에 담을 수 있다 — AI가 이해하는 코드가 AI가 올바르게 쓰는 코드다.
- 한계: 다중 머신 동시 쓰기(SQLite 상한선)나 깊은 클라이언트 상태(Figma 등)에는 Postgres/React가 여전히 답이다.
- 이 스택의 공식: 파일 1개(DB) + 바이너리 1개(배포) + 14KB(프론트엔드) + 번역 레이어 0개 = AI가 올바르게 쓸 수 있는 가장 강력한 조합.