Lessons from Building an AI App Builder on Convex

🖼️ 인포그래픽

Lessons from Building an AI App Builder on Convex 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Chef의 사례는 AI 코딩 에이전트가 잘 작동하려면 좋은 추상화, 제한된 선택지, 타입 안전한 피드백 루프, 검증 가능한 평가 체계가 필요하다는 점을 보여준다.

📌 핵심 요약

Chef는 Convex 위에 구축된 AI 앱 빌더로, 사용자의 프롬프트를 바탕으로 Vite, React, Convex 인증이 포함된 템플릿을 만들고 서버에서 시스템 프롬프트와 함께 에이전트 루프를 실행한다.
Chef의 핵심은 LLM이 코드 작성·수정·조회 도구를 사용하고, npx convex dev로 타입체크와 오류 확인을 반복하면서 잘못된 출력을 고치는 구조에 있다.
Convex는 백엔드부터 프론트엔드까지 타입 안전성을 제공하므로 LLM 출력의 정확성을 판단하기 쉽고, 오류가 발생했을 때도 모델이 수정에 활용할 수 있는 명확한 에러 메시지를 제공한다.
Chef가 잘 작동하는 이유는 단순하고 의견이 반영된 템플릿, 위험한 파일 수정을 막는 프로그램적 보호장치, 코드로 정의되는 백엔드, 재사용 가능한 Convex 컴포넌트가 결합되어 있기 때문이다.
저자는 AI 에이전트 애플리케이션을 만들 때 좋은 추상화, 잘못된 결정의 제한, 정확한 예시 제공, 사용 사례에 맞춘 eval 구축이 기술 방향과 품질 개선의 핵심 원칙이라고 정리한다.

🧩 주요 포인트

Chef는 Convex 위에 구축된 AI 앱 빌더로, 사용자의 프롬프트를 바탕으로 Vite, React, Convex 인증이 포함된 템플릿을 만들고 서버에서 시스템 프롬프트와 함께 에이전트 루프를 실행한다.
Chef의 핵심은 LLM이 코드 작성·수정·조회 도구를 사용하고, npx convex dev로 타입체크와 오류 확인을 반복하면서 잘못된 출력을 고치는 구조에 있다.
Convex는 백엔드부터 프론트엔드까지 타입 안전성을 제공하므로 LLM 출력의 정확성을 판단하기 쉽고, 오류가 발생했을 때도 모델이 수정에 활용할 수 있는 명확한 에러 메시지를 제공한다.
Chef가 잘 작동하는 이유는 단순하고 의견이 반영된 템플릿, 위험한 파일 수정을 막는 프로그램적 보호장치, 코드로 정의되는 백엔드, 재사용 가능한 Convex 컴포넌트가 결합되어 있기 때문이다.
저자는 AI 에이전트 애플리케이션을 만들 때 좋은 추상화, 잘못된 결정의 제한, 정확한 예시 제공, 사용 사례에 맞춘 eval 구축이 기술 방향과 품질 개선의 핵심 원칙이라고 정리한다.

🧠 상세 정리

1. Chef의 출발점과 Convex의 역할

글은 Chef가 단순한 앱 생성 도구가 아니라 Convex 위에 만들어진 백엔드를 이해하는 AI 앱 빌더라는 점에서 출발한다. 저자는 Chef의 개발 과정이 Chef 자체에서 시작된 것이 아니라, 그 기반이 되는 데이터베이스이자 백엔드 플랫폼인 Convex를 만드는 과정에서 시작되었다고 설명한다. Convex 팀은 인간이 좋은 추상화를 가질 때 더 잘 일한다는 가설을 세웠고, 실제로 AI도 같은 종류의 추상화에서 이익을 얻는다고 본다. 이 관점이 Chef의 구조와 제품적 강점을 이해하는 핵심 배경으로 제시된다.

2. 프롬프트에서 앱 생성까지의 아키텍처

Chef에서 Notion 클론 같은 앱을 만들 때 사용자는 먼저 최소 기능 제품에 해당하는 프롬프트를 입력하고, 시스템은 그 요청을 바탕으로 작업을 시작한다. 내부적으로는 Convex 인스턴스를 프로비저닝하고, Vite와 React를 사용하는 템플릿을 생성하며, 이 템플릿에는 Convex 인증이 이미 통합되어 있다. 이후 사용자의 프롬프트는 Chef의 시스템 프롬프트와 함께 서버로 전달된다. 시스템 프롬프트는 Convex 규칙을 Chef 템플릿에 맞게 조정한 것이며, LLM이 사용할 수 있는 도구 정보와 작업 방식 예시도 포함한다.

3. 에이전트 루프와 타입 안전성의 효과

Chef의 에이전트 루프는 LLM이 write, edit, view 같은 도구를 사용해 코드를 살펴보고 작성한 뒤, npx convex dev로 타입체크를 실행하고 오류를 고치는 방식으로 작동한다. 저자는 이 루프가 Convex를 특별하게 만드는 지점이라고 설명한다. Convex는 백엔드부터 프론트엔드까지 타입 안전성을 제공하기 때문에, LLM이 작성한 코드가 맞는지 판단할 수 있는 좋은 휴리스틱을 제공한다. 또한 LLM이 틀렸을 때 Convex의 명확한 에러 메시지를 활용해 문제를 수정할 수 있어, Chef가 다른 앱 빌더보다 더 복잡한 문제를 다룰 수 있게 된다.

4. Chef 자체의 데이터 저장 방식

Chef로 만들어지는 앱들이 Convex를 백엔드로 사용하는 것뿐 아니라, Chef 자체도 Convex를 백엔드로 사용한다. 글에서는 Chef가 이메일, 팀 ID, 채팅 이름 같은 메타데이터를 Convex 데이터베이스에 저장한다고 설명한다. 또한 파일시스템 스냅샷과 채팅 기록은 Convex storage를 사용해 보관한다. 이 구조는 Chef가 자신이 권장하는 플랫폼 위에서 직접 동작한다는 점을 보여주며, 앱 생성 결과물과 빌더 자체가 같은 백엔드 철학을 공유한다는 점도 드러낸다.

5. 의견이 반영된 템플릿과 위험 상태 방지

Chef가 잘 작동하는 첫 번째 이유는 선택지를 넓히기보다 의도적으로 좁힌 의견 있는 템플릿을 사용한다는 점이다. 저자는 Vite와 React를 프론트엔드에, Convex를 백엔드에 사용한 이유가 단순하고 잘 알려져 있기 때문이라고 설명한다. 다른 플랫폼처럼 더 많은 설정을 허용하면 LLM이 혼란을 겪을 수 있으므로, 프레임워크와 인증 같은 어려운 결정은 미리 해결해 둔다. 특히 Convex 인증을 통합했을 때 LLM이 인증 관련 파일을 건드려 앱을 망가뜨리는 문제가 있었고, 이를 막기 위해 특정 파일에는 쓰기 변경을 저장하지 않도록 프로그램적으로 제한했다.

6. 코드로 정의되는 백엔드와 컴포넌트의 장점

Convex는 백엔드 전체를 코드로 정의할 수 있게 하며, 저자는 이 점이 코드 작성에 강한 LLM과 잘 맞는다고 본다. 타입 안전성이 끝까지 이어지기 때문에 LLM 출력의 정확성을 확인하고, 틀린 경우 다시 고치도록 할 수 있다는 점도 강조된다. SQL 기반 데이터베이스와 비교하면 SQL 코드의 정확성이나 타입 일치를 실행 전까지 확인하기 어렵다는 한계가 언급된다. 또한 Convex의 components 프레임워크는 자체 테이블을 가진 모듈화된 코드 조각을 만들 수 있게 해, LLM이 기존 해결책을 활용하면서 더 높은 수준의 작업에 집중하도록 돕는다.

7. AI 코딩 에이전트를 위한 원칙

저자는 Chef를 만들며 얻은 원칙을 좋은 추상화, 잘못된 결정의 제한, 좋은 예시, eval의 중요성으로 정리한다. 좋은 추상화는 에이전트가 해야 할 결정을 줄이는 것뿐 아니라, 올바른 결정을 하도록 도구와 기본값을 설계하는 것을 의미한다. LLM은 금지해도 잘못된 결정을 할 수 있으므로, 되돌리기 어려운 상태로 들어가는 경로를 줄이고 창의성은 UI와 애플리케이션 로직처럼 문제 해결에 유익한 영역에 집중시켜야 한다. 또한 예시는 모델이 패턴을 학습하는 기준이 되므로 정확하고 일관되어야 하며, eval은 좋은 결과가 무엇인지 정량적으로 정의하고 모델·프롬프트를 더 빠르고 자신 있게 비교하게 해준다.

🧾 핵심 주장 / 시사점

AI 앱 빌더의 품질은 모델 성능만이 아니라, 모델이 움직이는 환경을 얼마나 잘 제한하고 검증 가능하게 설계하느냐에 크게 좌우된다.
타입 안전한 개발 루프와 명확한 오류 메시지는 LLM이 스스로 수정할 수 있는 피드백을 제공하므로, 에이전트형 코딩 시스템에서 중요한 기반이 된다.
좋은 예시와 eval은 프롬프트 감각에 의존한 개발을 줄이고, 원하는 행동과 결과를 반복적으로 개선할 수 있게 만드는 실용적인 장치다.

✅ 액션 아이템

Chef 패턴을 모방해 사용자 프롬프트 기반으로 Vite/React/Convex 인증 템플릿을 생성하는 추상 계층을 정의한다.
LLM이 작성·수정·조회 도구를 돌려 npx convex dev형 타입체크를 반복 수행하고 오류를 근거로 출력을 정정하도록 에이전트 루프를 구성한다.
타입 안전성과 에러 메시지를 활용해 위험 파일 수정 가능성을 낮추는 보호장치와 사용사례별 eval 기준을 함께 점검한다.