AI 도입의 진짜 질문은 'how'
"모든 React 앱은 18개월 안에 AI 기능을 필요로 할 것이다." dev.to에 게재된 React + AI: Building Intelligent Web Applications in 2026의 첫 문장이다. 도발적이지만 반박하기 어렵다. 문제는 그 다음이다. 대부분의 팀은 fetch()로 OpenAI API를 호출하고 스피너를 붙이는 것을 'AI 통합'이라고 부른다. 하지만 그건 API 호출이지, 아키텍처가 아니다. AI를 진짜로 프로덕트에 녹이려면 다른 출발점이 필요하다.
아키텍처부터: 프론트는 LLM을 직접 보지 않는다
같은 글에서 제안하는 '3계층 패턴'은 단순하지만 강력하다. React 컴포넌트 → API 레이어 → LLM 프로바이더. 프론트엔드는 절대로 LLM에 직접 요청을 보내지 않는다. API 키 노출은 보안 재앙이고, 레이트 리밋·비용 추적·프롬프트 인젝션 필터링은 모두 API 레이어에서 처리해야 한다.
스트리밍 구현도 마찬가지다. WebSocket이 아닌 SSE(Server-Sent Events)를 써야 하는 이유가 있다. LLM 스트리밍은 단방향이고, SSE는 CDN·로드밸런서와 기본 호환되며 재연결도 자동으로 처리된다. 실제 코드에서 X-Accel-Buffering: no 헤더 하나가 없으면 nginx가 전체 응답을 버퍼링해 스트리밍 효과가 사라진다는 디테일도 놓쳐선 안 된다. 캐시 전략도 빠뜨리면 안 된다. 프로덕션에서 동일 프롬프트의 30~60% 캐시 히트율은 곧 30~60% 비용 절감이다.
상태 관리 측면에서는 useState 대신 useReducer를 써야 한다. 스트리밍 중 stale closure와 race condition이 발생하는 건 시간 문제다. 모든 상태 전환을 원자적으로 처리하는 구조가 필요하다.
주말 이틀, 풀스택 SaaS: 순서가 전부였다
From Zero to Shipped: How We Built Indiefy.xyz in a Weekend (With AI as Co-Founder)는 다른 종류의 증거를 제시한다. 인증·DB·결제·i18n·리더보드까지 갖춘 풀스택 SaaS를 단 한 번의 스프린트로 출시한 사례다. 이 팀이 가장 먼저 한 일은 터미널을 여는 게 아니었다.
indiefy.md라는 스펙 문서를 먼저 썼다. 한 문장의 컨셉, 타깃 유저 프로파일 5종, 기능 목록, 모네타이제이션 모델, 기술 스택, 5일 빌드 타임라인. 이 작업에 시간을 쓴 이유는 명확하다. 스펙이 있어야 프롬프트가 생기고, 프롬프트가 있어야 AI가 추측 대신 빌드를 한다. 스펙 없이 AI에게 물어보는 건 목적지 없이 내비게이션을 켜는 것과 같다.
디자인 시스템도 코드보다 먼저 왔다. Spotify 다크 테마를 레퍼런스로 삼고, 색상 토큰을 정확한 hex 값으로 정의한 다음 AI에게 줬다. 프롬프트는 "Spotify 느낌의 다크 디자인"이 아니라 #0a0a0a, #1DB954, DM Sans, Syne처럼 구체적인 값의 나열이었다. 결과는 한 번에 완성된 디자인 시스템이었다. Garbage in, garbage out—그 역도 성립한다.
DB 스키마도 마찬가지였다. Prisma 스키마를 AI에게 생성시키기 전에 45분 동안 손으로 직접 모든 모델과 릴레이션, 인덱스를 작성했다. 덕분에 이후 마이그레이션 세 번을 피했다. showFinancials 같은 불리언 하나도 제품 의사결정의 결과물이었다—돈은 숨기고 프로필은 공개하고 싶은 유저 세그먼트가 있다는 인사이트에서 나왔다.
252줄에서 86줄로: 시간이 지나도 유효한 원칙
I Deleted 66% of My AI Coding Guide — Here's What Survived는 더 근본적인 질문을 던진다. AI 코딩 생산성을 어떻게 측정하고 있는가? 생성된 코드 줄 수, 프롬프트 횟수, 응답 속도, 커밋 수—이 중 하나라도 목표로 삼고 있다면 잘못된 것을 최적화하고 있는 것이다. 코드 줄 수 목표는 bloat을 장려하고, 프롬프트 횟수 목표는 생각하는 것을 패널티로 만든다.
저자가 252줄 가이드를 4라운드 리뷰 끝에 86줄로 압축해 남긴 세 원칙은 모델이 바뀌어도 유효하다.
1. 되돌릴 수 있게 유지하라 (전제조건). 타입 체크, 린터, 테스트 스위트, CI—이것들은 제약이 아니라 대담한 위임을 가능하게 하는 기반이다. AI에게 모듈 리팩토링을 맡기려면 먼저 되돌릴 수 있어야 한다.
2. 의도를 명시하라 (출발점). 컨텍스트에는 세 요소가 있다: 목적(무엇을 달성할 것인가), 제약(무엇이 일어나선 안 되는가), 지식(의사결정에 필요한 배경). 셋 중 하나만 빠져도 출력 품질이 떨어진다. 타입 정의, 테스트, 네이밍 컨벤션, 디렉토리 구조처럼 프로젝트 레벨의 의도는 한 번 설정하면 모든 세션에 복리로 작용한다.
3. 출력을 검증하라 (비협상). 병목이 생성에서 검증으로 이동했다. 생성은 초 단위지만 검증은 인간의 시간이 필요하다. 가장 빠르게 생성된 코드일수록 가장 꼼꼼하게 읽어야 한다. "테스트 통과, 머지" 결정이 AI 코딩에서 가장 비싼 실수다.
세 사례가 수렴하는 지점
이 세 자료는 서로 다른 레이어를 다루지만 같은 방향을 가리킨다.
아키텍처 기사는 기술 레이어를 다룬다—API 키는 서버에, 스트리밍은 SSE로, 비용은 첫날부터 추적하라. Indiefy 사례는 프로세스 레이어를 보여준다—스펙이 먼저고, 디자인이 다음이고, 코드는 그 다음이다. AI 코딩 가이드는 마인드셋 레이어를 정리한다—측정하는 것이 최적화되고, 의도가 없으면 AI는 추측한다.
세 레이어가 정렬될 때 비로소 AI는 '코드 자동완성 도구'에서 '공동 창업자'가 된다. Indiefy 팀이 주말 이틀에 풀스택 SaaS를 출시할 수 있었던 건 AI가 뛰어나서가 아니라, 그들이 AI에게 줄 수 있는 컨텍스트를 먼저 만들어뒀기 때문이다.
프론트엔드 개발자에게 남는 질문
AI 워크플로우의 실질적 전환은 도구 교체가 아니라 순서의 교체에서 온다. 스펙 없이 컴포넌트를 만들고, 검증 없이 배포하고, 의도 없이 프롬프트를 보내는 패턴—이건 AI 이전에도 나쁜 습관이었고, AI 이후에는 그 결과가 더 빠르게, 더 크게 나타난다.
빠른 프로토타이핑과 사용자 검증, 그리고 점진적 고도화. 이 흐름은 AI가 등장하기 전에도 좋은 프로덕트 개발의 원칙이었다. AI는 각 단계의 속도를 높였을 뿐, 순서를 바꾸지는 않았다. 오히려 순서를 틀렸을 때의 대가를 더 선명하게 만들었다.
결국 남는 질문은 하나다. 당신은 AI에게 무엇을 위임하고 있는가—생성인가, 아니면 판단인가.