• 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의 모든 기능 활용 가능

댓글과 토론