# 5년과 500만 달러의 교훈: 웹 개발용 새 프로그래밍 언어를 만든 것은 실수였다 | Wasp > Clean Markdown view of GeekNews topic #29778. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29778](https://news.hada.io/topic?id=29778) - GeekNews Markdown: [https://news.hada.io/topic/29778.md](https://news.hada.io/topic/29778.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-23T09:19:02+09:00 - Updated: 2026-05-23T09:19:02+09:00 - Original source: [wasp.sh](https://wasp.sh/blog/2026/05/13/new-language-for-web-dev-was-a-mistake) - Points: 1 - Comments: 0 ## Topic Body - Y Combinator 출신 풀스택 웹 프레임워크 Wasp가 5년간 **자체 DSL 기반 언어** 개발을 시도한 끝에 이를 포기하고 TypeScript로 전환하는 결정을 공개 - "JS판 Rails/Laravel"을 지향하며 React·Node.js·Prisma 위에서 **앱 사양을 선언적으로 기술**하는 구조로 출발, 총 500만 달러 이상의 투자 유치 - "lang" 접미사가 JavaScript 대체 언어로 오해받고, **IDE 지원과 도구 생태계 구축** 부담이 예상보다 훨씬 컸음 - 실제 핵심 가치는 새 언어 자체가 아니라, 컴파일 타임에 **풀스택 앱 전체에 대한 고수준 사양**을 유지하는 데 있었음 - 향후 Launch Week를 통해 **TypeScript SDK를 기본 인터페이스**로 정식 출시 예정, 내부 동작은 그대로 유지 --- ### 배경: 왜 새 언어를 만들려 했는가 - Wasp는 2021년 쌍둥이 형제가 창업, Y Combinator를 거치며 총 **500만 달러 이상 투자 유치** - 초기 구상은 어떤 스택과도 동작 가능한 "**범용 프레임워크**"였고, 이를 위해 새 언어가 필요하다고 판단 - 클라우드 인프라용 Terraform처럼, 웹 앱 스택에 대해 동일한 추상화를 제공하는 것이 목표 ### 스택 전환 피로와 우발적 복잡성 - 과거에는 Spring Boot, Django, Rails 중 하나를 고르면 인증·라우팅·상태관리가 일괄 해결됨 - 현재는 React, Redux, Webpack, Express, Passport, Sequelize 등을 **직접 조합·연결**해야 함 - 이로 인해 비즈니스 로직보다 스택 관리에 더 많은 시간 소모, 이를 "**우발적 복잡성(accidental complexity)**"으로 정의 ### "한 번만 선언하면 되는" 구조 구상 - "Google·GitHub 인증을 쓰고 싶다", "/profile 라우트는 인증된 사용자만 접근", "매일 오후 5시 cron job 실행" 같은 요구를 **구현 무관 사양(specification)** 으로 표현하는 방식 구상 - 예시 형태 - `auth: Google, GitHub` - `page Profile -> /profile, authRequired: true` - `job updateStats: run function doSomeCalc from stats.js every day at 5pm` - 기존 스택 대체가 아닌, **로직은 React·Node.js에 두고 중심 백본만 별도로** 두는 구조 - 핵심 통찰: 웹 앱 도메인(페이지, 라우트, API, 데이터 모델)은 거의 변하지 않지만, **구현 기법은 빠르게 변화** ### 왜 기존 언어가 아닌 새 언어를 택했나 - 새 언어를 처음부터 설계한 두 가지 이유 - **문법에 대한 완전한 제어**, 보일러플레이트 최소화 - **런타임 비종속(runtime-agnostic)** 도구 지향 — 예: 일부 로직은 Node.js, 데이터 집약 부분은 Python - TypeScript 기반 임베디드 DSL을 쓰자는 초기 피드백도 있었으나, 당시에는 비전을 배신하는 듯해 거부 - Wasp을 독립 언어로 출시하는 것이 **Rails·Django 같은 언어 종속 프레임워크와의 차별화**에 더 강한 메시지를 준다고 판단 - 창업자들이 Haskell 애호가였고, 언어·컴파일러 제작 자체가 매력적인 작업이었음을 솔직히 인정 ### 시장 반응: 아이디어는 사랑받았지만 언어는 견뎌야 했음 - 알파 출시 후 약 1년 만에 초기 사용자층 형성, Y Combinator 합격 및 프리시드 라운드 유치 - 베타 이후 채택률 본격 상승, 보일러플레이트 피로와 스택 조합 피로가 큰 동인으로 작용 - 비슷한 시기 RedwoodJS, BlitzJS 등 "**JS판 Rails**" 프레임워크도 등장 - 다만 RedwoodJS는 GraphQL, BlitzJS는 Next.js에 강하게 결합되어 한계, Wasp는 특정 기술에 종속되지 않은 점이 생존 요인으로 작용 - ## "wasp-lang"이 JavaScript를 대체하는가? - "lang" 접미사 때문에 개발자가 자동으로 Rust·Java 같은 범용 언어로 인식 - 실제로는 코드의 90%를 여전히 React·Node.js로 작성하지만, **포지셔닝 자체가 오해를 유발** - "멋있어 보이지만 시기상조"라는 인식 카테고리에 묶이는 결과 초래 - ## 기존 IDE·도구와 호환 가능한가 - "자체 생태계까지 구축해야 하는가"라는 의문이 자연스럽게 따라옴 - 새 표준을 만들고 생태계를 키우는 데 드는 비용을 개발자들이 잘 알고 있음 - ## "Haskell을 배우긴 싫다"는 반응 - 컴파일러 내부는 Haskell로 작성되지만 **최종 사용자는 TypeScript만 사용** - Prisma 코어가 Rust, Terraform HCL이 Go로 작성된 것과 동일한 구조 - Haskell 커뮤니티 대상 마케팅이 너무 잘 먹혀, Wasp가 "**Haskell 기반 언어**"로 잘못 각인됨 - GitHub 저장소 "Languages" 바에 "Haskell: 90%"로 표시된 점도 잘못된 포지셔닝 강화 - ## 패키징의 문제 - 실제로 써본 개발자들은 대부분 만족, React·Node.js를 유지하면서 **빠른 출시 가능** 확인 - 그러나 "이게 뭔지 모르겠다"에서 "한 번 써보겠다"로 넘어가게 만드는 단계가 가장 어려움 - 진입 장벽을 낮추기 위해 Wasp 위에 오픈소스 SaaS 보일러플레이트 starter, 초기형 Lovable 같은 **상위 제품** 구축 - 사용자 유입에는 효과적이었으나 핵심 문제는 잔존 - ## 결정타: IDE 지원 구현의 난이도 - 사용자가 아닌 **내부 개발 과정에서 한계 도달** - JS 생태계에서 요구되는 IDE 경험 수준이 매우 높고, IDE와 컴파일러의 경계가 모호해짐 - 전체 도구 생태계가 표준 JS·TS 프레임워크 기반으로 구축되어 있어, **그 외 언어는 즉시 한계** 봉착 - 자체 language server와 VS Code 확장을 개발했으나, Prisma DSL과 React·Node.js 파일 참조까지 결합되면서 목표의 80% 수준에 그침 ### 자체 언어와의 작별, TypeScript로 전환 - 채택은 계속 늘었지만 "왜 자체 언어인가"라는 질문은 사라지지 않음, 마치 "**핸드브레이크를 당긴 채 주행하는 느낌**"으로 비유 - 결국 언어가 주는 문법적 이점은 생각만큼 결정적이지 않았으며, 개발자들은 **익숙한 TypeScript**에 추가 괄호 몇 줄 정도는 기꺼이 수용 - ## 진짜 해자(moat)는 언어가 아니라 컴파일 타임의 앱 전체 이해 - 창업 초기에는 "language"와 "specification"을 동의어로 인식했으나, 사용자들이 진짜 좋아한 것은 **고수준 사양(`main.wasp`, 현 `main.wasp.ts`)을 통한 앱 전체 파악** - `wasp studio` 명령으로 컴파일 타임에 Wasp가 앱 구조를 어떻게 인식하는지 시각화 가능 - AI 도구와 코드 자동 생성이 늘면서, 비기술 배경의 "**vibe-coders**" 세대에게 이러한 구조적 지원의 가치가 더 커짐 - 이번 전환은 컴파일러의 "프런트엔드"(사양 정의 방식)만 교체, **내부 동작은 동일하게 유지** - ## TypeScript SDK — 실험에서 정식 제품으로 - 실험적 프리뷰로 도입된 TypeScript SDK에 신규 사용자 다수가 곧장 채택, Wasp 언어를 한 번도 사용하지 않은 경우도 발생 - 코드 예시 - `app.page`, `app.route`로 페이지·라우트 정의 - `app.query`로 쿼리 정의, entities 지정 가능 - `app.job`으로 비동기 잡 정의, **PgBoss executor**, retry 옵션 지원 - 전환의 실질적 이점 - 모든 에디터에서 **별도 설정 없이 동작** - 조건문, 반복문, import 사용 가능 — 예: 자체 file-based routing 구현 가능 - 사양을 **여러 파일로 분할**하기 쉬움 - Full Stack Modules 같은 고급 기능의 기반 마련 ### DSL에 대한 회고 - DSL 방식이 없었다면 Wasp 자체가 존재하지 않았을 것이라는 점은 인정 - DSL 접근은 "**사양과 구현의 분리**"라는 비전에 충실하도록 강제 - 향후 Python, Rust 등 다른 언어·런타임 지원과, 컴파일 타임 전체 앱 파악을 활용한 **아키텍처 다양화·최적화** 가능성에 대한 관심은 유지 ### AI 에이전트와의 궁합 - AI가 코드 작성 비중을 키우면서, 개발자들이 **구조와 의견(opinion)이 명확한 도구**를 선호하는 경향 증가 - 풀스택 전반을 아우르고 항상 일관성을 보장하는 Wasp가 이러한 흐름에 적합 - Django, Rails, Laravel 같은 "**구식" 모놀리식 프레임워크가 재조명**되는 현상과 동일한 맥락, Wasp는 이를 JS 생태계에 제공하는 것을 지향 - 실제로 10개 스택을 시도한 끝에 Wasp을 선택한 개발자 사례 존재 ### TypeScript-First Wasp 출시 예고 - 향후 몇 주 내 Launch Week를 통해 **TypeScript SDK를 Wasp의 기본 사용 방식**으로 정식 출시 예정 - 신규 사용자는 새 언어 학습 없이 TypeScript만으로 Wasp의 모든 기능 활용 가능 ## Comments _No public comments on this page._