AI는 작동하는 데모를 만드는 것을 매우 쉽게 만듭니다. 하지만 실제 트래픽을 견뎌내는 무언가를 만드는 것은 다른 차원의 기술입니다. 제가 이를 어떻게 접근하는지 설명하겠습니다. 최근에 진행한 강연의 원칙들을 담았으며, 영상 전문은 마지막에 첨부되어 있습니다.

단순하게 시작하고 — 복잡성을 획득하라

Gall의 법칙 (Gall's Law): 작동하는 복잡한 시스템은 예외 없이 작동하는 단순한 시스템으로부터 진화했습니다. AI 도구들은 첫날부터 방대한 아키텍처를 구축하고 싶은 유혹을 느끼게 합니다. 이를 저항하십시오. 문제를 해결하는 가장 단순한 것을 출시한 다음, 실제 제약 조건들이 당신을 복잡성으로 이끌게 하십시오. 그 반대가 되어서는 안 됩니다.

모델을 당신이 관리하는 엔지니어링 팀처럼 대하라
Claude Code와 잘 협업하는 것은 영리한 프롬프트 (Prompt)의 문제라기보다 설정 (Setup)의 문제입니다. 실제로 성과를 내는 요소들은 다음과 같습니다:

CLAUDE.md — 프로젝트를 위한 고정된 컨텍스트 (Context) 및 컨벤션 (Conventions)
Skills (SKILL.md) — 일회성 프롬프트가 아닌, 재사용 가능한 노하우 폴더
MCP 서버 (MCP servers) — 모델에게 추측 대신 실제 도구와 데이터를 제공
하위 에이전트 (Subagents) 및 플랜 모드 (Plan mode) — 작업을 세분화하고, 코드가 작성되기 전에 계획을 검토

당신은 소규모 팀의 CTO입니다. 프롬프트 엔지니어링 (Prompt engineering)은 계획이 아닙니다.

에지 (Edge)에서 구축하라
저의 기본 스택과 각 구성 요소에 대한 이유는 다음과 같습니다:

Workers — 사용자 근처에서 실행되는 상태 비저장 (Stateless) 컴퓨팅 및 라우팅
Durable Objects — 상태를 가진 엔티티(채팅방, 문서 등)당 하나씩 할당되며, 강력한 일관성 (Strongly-consistent) 상태를 위한 자체 SQLite를 보유
D1 — 관계형, 엔티티 간 쿼리: 단일 Durable Object가 소유해서는 안 되는 것들
KV — 읽기 집약적인 설정 및 캐시

중요한 구분점: Durable Object는 하나의 엔티티 상태를 소유하고, D1은 엔티티 간의 관계를 소유합니다. 이 경계를 올바르게 설정하면 대부분의 아키텍처가 제자리를 찾게 됩니다.

기본을 건너뛰지 마라

AI는 데모에서는 작동하지만 프로덕션(Production)에서는 무너지는 코드를 기꺼이 작성할 것입니다. 당신이 직접 강제해야 하는 세부 사항들은 다음과 같습니다:

상태를 변경(mutate)하는 모든 작업에 대한 멱등성 (Idempotency)
N+1 쿼리(N+1 queries) 제거; 실제로 쿼리하는 항목에 인덱스 (index) 설정
첫날부터 시작하는 관측성 (Observability) — 엣지 (edge)에서는 느린 것이 곧 비용입니다
프론트엔드에서의 시맨틱 HTML (Semantic HTML) 및 접근성 (accessibility)

관통하는 핵심 원칙 (The throughline)

당신이 구축하는 모든 것에 대해 인지 상태를 유지하세요. "바이브 코딩 (Vibe coding)"은 이러한 인지를 건너뛰지만, 의도적인 코딩 (intentional coding)은 이를 유지합니다. AI는 판단력 (judgment) 위에 얹어진 지렛대 (leverage)이지, 판단력을 대체하는 것이 아닙.

전체 강연 (~59분, 설명란에 챕터 표시):