Wasp 팀은 왜 웹 개발용 새 언어를 만들었고, 무엇을 배웠으며, 이제 그 커스텀 언어를 TypeScript로 교체하기로 했는지 설명합니다.
At Wasp에서 우리는 풀스택 웹 프레임워크를 만들고 있습니다. JS를 위한 Rails / Laravel이라고 생각하면 되지만, 프런트엔드까지도 "확장된" 형태입니다. 저와 쌍둥이 형제는 2021년 Y Combinator를 거치던 때 이 프로젝트를 시작했고, 지금까지 총 500만 달러 이상을 투자받았습니다.
초기의 아이디어는 공통적인 웹 앱 패턴을 추상화하면서도, 더 깊이 들어가야 할 때는 어떤 스택과도 함께 동작하는 새로운 프로그래밍 언어를 만드는 것이었습니다. 우리는 React, Node.js, Prisma로 시작했습니다. 클라우드 인프라 대신 웹 앱 스택을 위한 Terraform이라고 생각하면 됩니다.
5년이 지난 지금, 우리는 그것이 실수였다는 것을 깨달았습니다. 새로운 언어를 만드는 것은 특정 문제와 도메인에서는 의미가 있지만, 이 경우에는 맞지 않았고 얻은 가치보다 더 많은 문제를 가져왔습니다.
이 글에서는 왜 우리가 그것이 좋은 아이디어라고 생각했는지, 무엇을 배웠는지, 그리고 Wasp 자체의 내부 구조는 그대로 유지하면서 왜 커스텀 언어를 TypeScript로 교체하고 있는지 이야기합니다.
이 글은 깁니다. 모든 내용을 읽지 않고도 관심 있는 부분으로 바로 갈 수 있도록, 핵심 내용을 먼저 정리하면 다음과 같습니다.
저와 형제는 둘 다 전통적인 Computer Science 배경을 가지고 있습니다. 우리는 주로 알고리즘과 그것을 bioinformatics, machine learning 같은 분야에 적용하는 데 집중했습니다. 우리는 스스로를 웹 개발자라고 생각한 적이 없었고, 오히려 어느 정도는 웹 개발을 낮게 보기도 했습니다. "저 사람들은 하루 종일 버튼에 색칠만 하고 있는데, 나는 멋진 알고리즘을 짜고 있잖아." 물론 우리는 충분히 알지 못했습니다.
그래도 우리 무리에는 항상 사이드 프로젝트를 하던 창업가 기질의 친구가 한 명 있었고, 더 큰 프로젝트를 따낼 때마다 우리를 끌어들였습니다. 이런 프로젝트들은 우리에게 "흥미로운" 요소를 하나씩 가지고 있었습니다. 예를 들어 추천 엔진도 필요한 뉴스 포털을 만든다거나, 옵션 트레이딩 분석 플랫폼을 만든다거나 하는 식이었죠. 하지만 결국 대부분은 전형적인 웹 개발 일이었습니다.
그렇게 해서 우리는 PHP에도 노출되었고, 그걸로 완전한 CMS를 처음부터 만들었다가 나중에야 우리가 사용할 수 있었던 프레임워크와 기성 솔루션들이 있었다는 사실을 알게 되었습니다. 또 Java/JBoss도 접했고, Backbone.js, Angular.js, React가 등장하던 시기에 그것들과 함께 빌드 도구들도 경험했습니다. Bower, Grunt, Gulp 기억하시나요?
2013년 이후는 반응형 프런트엔드 프레임워크의 시대였고, 새로 나오는 프레임워크는 최신 프로젝트에서 반드시 써야 하는 것이었습니다. 그래야 당신의 프로젝트나 스타트업이 멋져 보였으니까요. 그 결과, 새 프로젝트를 시작할 때마다 이전 프로젝트와 거의 완전히 다른 스택으로 시작했고, 막 익혔던 패턴들, 예를 들어 인증, 라우팅, 상태 관리 같은 것들을 다시 배워야 했습니다.
예전에는 Spring Boot, Django, Rails 중 하나를 고르면 모든 것이 처리되고 관리되었습니다. 그런데 이제는 먼저 각 라이브러리를 고른 다음, React, Redux, Webpack, Express, Passport, Sequelize가 함께 동작하도록 만들어야 했습니다.
웹 앱 전체를 완전히 이해하고 책임지는 시스템은 없었고, 그런 책임감의 공백은 Martin과 저에게 꽤 불편하게 느껴졌습니다.
이런 스택 갈아타기 춤을 몇 번 겪고 나서, 결국 당시에는 React, Node.js, Mongoose 조합에 정착했습니다. 그리고 우리는 생각했습니다. 더 나은 방법은 없을까? 우리는 끊임없이 같은 것을 다시 만들고 있었고, 고유한 비즈니스 로직을 작성하는 대신 대부분의 시간을 스택 관리에 쓰고 있다는 느낌이 들었습니다.
이런 현상을 가리키는 이름이 있습니다. 바로 accidental complexity 입니다. 실제 문제와는 상관없지만, 사용 중인 도구 때문에 피할 수 없는 작업이죠. 우리가 정확히 그런 상태였습니다.
우리는 스스로에게 물었습니다. 원하는 것을 그냥 쓰기만 하면 된다면 어떨까? 예를 들면:
물론 이건 너무 대화체에 가깝습니다. 그래서 우리는 이를 더 구조화된 형태로 줄여 보면 어떨지 상상했습니다.
auth: Google, GitHubpage Profile -> /profile, authRequired: truejob updateStats: run function doSomeCalc from stats.js every day at 5pm이것은 본질적으로 앱의 요구사항을 더 높은 수준, 즉 구현으로부터 자유로운 수준에서 정의하는 방식이었을 것입니다. 다시 말해 specification입니다. 우리는 이런 것이 가능해야 하고 또 가능할 수 있다고 느꼈지만, 당시 가지고 있던 도구들로는 이런 요구사항 각각을 스택 곳곳에 흩뿌려 구현해야 했고, 그것은 너무 낮은 추상화 수준처럼 느껴졌습니다.
우리의 목표는 기존 스택을 대체하는 것이 아니었습니다. 대부분의 로직은 여전히 특정 런타임, 예를 들어 React나 Node.js에서 구현하게 될 것입니다. 다만 모든 것을 하나로 묶어 주는 중심 골격이 생기는 것이죠.
우리가 상상했고 실제로 구현한 Wasp의 방식입니다. 고수준 선언이 담긴 config .wasp 파일과 React & Node.js로 작성한 커스텀 로직을 입력하면, 완전히 동작하는 풀스택 앱이 빌드 결과물로 생성됩니다.
궁금하실 수 있으니, 아래는 최종 형태의 DSL이 어떻게 생겼는지를 보여 주는 코드 일부입니다.
app todoApp { title: "ToDo App", // 브라우저 탭에 표시됨 auth: { // 즉시 사용할 수 있는 풀스택 인증 userEntity: User, methods: { google: {}, gitHub: {}, email: {...} } }}route RootRoute { path: "/", to: MainPage }page MainPage { authRequired: true, // 로그인한 사용자로 접근 제한. component: import Main from "@client/Main" // <-- 당신의 React 코드.}query getTasks { fn: import { getTasks } from "@server/tasks", // <-- 당신의 Node.js 코드. entities: [Task] // 자동 캐시 무효화.}
우리에게 핵심적인 통찰은 웹 앱 도메인은 웹 개발 구현 기법이 진화하는 속도에 비해 매우 천천히 변한다는 점이었습니다. 10년 전에도 지금도 우리는 페이지, 라우트, API endpoint, 데이터 모델을 이야기합니다. 그 사이 UI 구현은 서버 템플릿에서 리치 클라이언트로 갔다가 다시 server actions로 돌아왔습니다.
Wasp를 통해 우리의 목표는 개발자가 가능한 한 많은 것을 도메인 수준에서 표현하게 하고, 시스템이 그 아래의 최신 구현 세부사항을 처리하게 하는 것이었습니다. 그렇게 하면 개발자가 만드는 것은 훨씬 더 오래 살아남고, 이해하기도 쉬워집니다.
문제에 대한 우리의 이해는 직접 겪은 덕분에 대부분 맞았지만, 잘못된 방향으로 꺾인 지점은 바로 여기였습니다.
TypeScript나 Python 같은 언어를 "호스트" 언어로 쓰는 대신, 자체 커스텀 컴파일러를 가진 새 언어를 처음부터 설계하기로 한 데에는 두 가지 주요 이유가 있었습니다.
TypeScript를 사용하는 것도 고려했습니다. 실제로 초기에 받았던 피드백 중 일부도 내장 DSL, 즉 명시적 DSL이 아니라 사실상 라이브러리인 형태를 두자는 것이었습니다. 하지만 당시 우리에게는 그것이 "틀린" 것처럼 느껴졌습니다. 마치 Wasp에 대해 우리가 갖고 있던 핵심 원칙과 큰 비전을 배신하는 것처럼 말입니다.
어떤 면에서는 Wasp를 독립된 언어로 내놓는 것이 매우 기대되었습니다. 그렇게 하면 이것이 또 하나의 전형적인 언어 종속 프레임워크, 예를 들어 Rails나 Django가 아니라, 더 일반적인 무언가라는 점을 더 강하게 보여 줄 수 있다고 믿었습니다.
2021년 당시 우리의 첫 랜딩 페이지입니다. 우리는 자랑스럽게 "language"를 전면에 내세웠습니다.
완전히 솔직히 말하자면, 언어와 컴파일러처럼 그렇게 "멋지고" 기반적인 것을 다룬다는 사실 자체도 우리를 신나게 했습니다. Martin과 저는 둘 다 Haskell 애호가였고, 이것은 우리의 함수형 망치로 두드리기에 완벽한 못처럼 보였습니다.
Wasp를 약 1년 동안 개발하고 Alpha 버전을 출시한 뒤 개발자들에게 공개했을 때, 우리는 작지만 열정적인 얼리 어답터 집단을 찾았고 Y Combinator에도 받아들여졌습니다. 그 직후 프리시드 라운드를 유치했고, 이를 통해 팀을 꾸려 첫 번째 "진짜" 버전을 만들 수 있게 되었습니다.
초기에는 모든 것을 궤도에 올리는 과정이라 속도가 느렸지만, 개발자들은 boilerplate의 고통을 예민하게 느끼고 있었고 스택을 억지로 이어 붙이는 일에 지쳐 있었습니다. 그래서 특히 Beta에 들어선 이후 Wasp는 탄력을 받기 시작했습니다.
아마 기억하실 수도 있겠지만, 비슷한 시기인 2021년에는 RedwoodJS와 BlitzJS 같은 다른 "JS를 위한 Rails" 프레임워크들도 등장했습니다. 전자는 GitHub 창업자가 만든 것이었죠. 이들은 빠르게 강한 커뮤니티 지지를 얻었고, 우리는 매우 중요한 문제를 해결하는 길 위에 있다는 사실을 분명히 느꼈습니다.
가끔은 이상한 점이 도움이 된다
어떤 의미에서 Wasp의 "이상함"은 오히려 그것을 Redwood와 Blitz의 운명으로부터 구해 주었습니다. 특정 기술에 강하게 결합되는 것을 피했기 때문입니다. Redwood는 GraphQL에, Blitz는 Next.js에 강하게 묶여 있었죠. 반면 Wasp는 충분히 일반적인 형태를 유지해 빠르게 적응할 수 있었고, 구식이 되는 것도 피할 수 있었습니다.
그래도 개발자들과 이야기하다 보면, "그런데 왜 새 언어를 만든 거죠?"라는 질문은 계속 다른 맥락에서 반복해서 등장했습니다. 우리가 계속 들었던 주요 반대 의견은 몇 가지로 정리할 수 있었습니다.
우리는 기존 웹 개발 스택을 대체하려는 것이 아니라 보완하려는 것이었습니다. Wasp를 써도 여전히 코드의 90%는 React & Node.js로 작성합니다. 하지만 이름 뒤에 붙은 "lang"이라는 접미사는 그 사실을 전달하기에는 너무 강력한 의미를 가지고 있었습니다.
개발자가 "wasp-lang.dev"를 읽는 순간, 머릿속에서는 자동으로 "아, 이건 Rust/Java 같은 거구나"라고 받아들였고, 한 번 그렇게 보이기 시작하면 그 렌즈를 벗기기가 매우 어려웠습니다. 그러면 즉시 Wasp는 "멋져 보이긴 하지만 아직은 너무 이르다"라는 범주로 들어가 버렸습니다.
우리는 언어를 만든다는 사실에 매우 들떠 있었고 그것을 강조까지 했지만, 그 용어가 이미 얼마나 강한 의미를 갖고 있는지는 과소평가했습니다.
설령 새로운 언어라는 점을 한 번 믿어 보자고 하더라도, 다음 질문은 곧바로 이어집니다. "그럼 이건 자체 생태계도 따라오는 건가요?" 개발자들은 새로운 표준을 만든다는 것이 얼마나 큰 일인지, 그리고 그 주위에 생태계를 키우는 데 얼마나 많은 시간이 드는지 잘 알고 있습니다.
우리는 내부적으로 컴파일러를 위해 Haskell을 사용하지만, 최종 사용자는 그것을 볼 일도 없고 오직 TypeScript만 사용하게 됩니다. 이는 Prisma의 핵심이 처음에는 Rust로 개발되었고, Terraform의 HCL이 Go로 만들어진 것과 비슷합니다.
그럼에도 불구하고, Haskell을 사용한다는 우리의 초기 마케팅은 우리에게 너무 잘 먹혀 버렸습니다. Haskell 커뮤니티는 작지만 참여도가 높고, 열정적이며, 특히 개발자 도구 분야의 실제 프로젝트에 굉장히 목말라 있습니다.
우리의 진행 상황을 그 커뮤니티에 공유하면 대개 매우 좋은 반응을 얻었지만, 동시에 Wasp를 "Haskell 기반 언어"로 인식하게 만드는 효과도 있었습니다. 특히 제목만 얼핏 보면 더 그랬습니다.
거기에 GitHub 저장소 페이지의 "Languages" 막대가 "Haskell: 90%"라고 표시되었다는 사실까지 더해졌습니다. 우리는 나중에 이를 우회하는 방법을 찾았습니다. 그렇게 해서 완벽하게 잘못된 포지셔닝이 완성된 것이죠.
실제로 Wasp를 써 본 많은 개발자들은 그것을 좋아했고, 언어 자체도 크게 신경 쓰지 않았습니다. 그들은 스택을 배우느라 몇 주를 허비하지 않고도 그 어느 때보다 빠르게 제품을 출시할 수 있었고, 계속해서 React & Node.js를 사용할 수 있었습니다. 하지만 개발자가 "이게 뭐지?" 에서 "한번 써 봐야겠다" 로 넘어가게 만드는 것은 정말 어려웠습니다.
일단 Wasp를 써 보면 많은 개발자들이 정말 좋아했습니다. 어려운 부분은 그들이 한번 써 보게 만드는 것이었습니다.
우리는 계속 밀어붙였습니다. Beta에 들어서면서 채택은 급증했고, Wasp로 만든 스타트업이 인수되는 사례도 나타났으며, 엔터프라이즈에서 내부 도구를 만들고 자체 인프라 환경에 배포하는 경우도 생겼습니다. 결국 Wasp 앱은 정적 프런트엔드 파일들과 백엔드를 위한 단일 Docker image에 불과하니까요.
"이상한 새 프레임워크인데 왜 내가 이걸 써 봐야 하지?"라는 장벽을 넘기 위해, 우리는 Wasp 위에 제품도 만들었습니다. 오픈소스 SaaS boilerplate starter와 우리만의 "초기" Lovable이 그것입니다. 이는 의사결정의 초점을 더 높은 수준으로 옮겨 주었고, 매우 잘 작동하면서 많은 사람들을 Wasp로 이끌었습니다.
하지만 근본적인 문제는 여전히 남아 있었습니다. Wasp를 찾아온 개발자들은 우리가 무엇을 만들고 있는지 이해하지 못했고, 그래서 그 일에 흥분할 수도 없었습니다.
우리는 항상, 만약 우리의 언어 선택이 잘못된 것이라면 그것은 사용자들이 그렇게 말해 주기 때문일 거라고 생각했습니다. 그런데 실제로는 정반대였습니다. Wasp를 채택한 개발자들은 계속 만족하며 사용하고 있었지만, 내부적으로는 그 언어 때문에 점점 더 많은 문제를 겪기 시작한 것입니다.
우리가 과소평가했던 주요 요소 중 하나는 커스텀 언어에 필요한 툴링, 특히 IDE/editor 지원을 개발하는 데 얼마나 많은 일이 드는가였습니다. 오늘날 개발자들이 기대하는 기준, 특히 JS 세계에서의 기준은 믿기 어려울 정도로 높고, IDE와 컴파일러의 경계도 점점 흐려지고 있습니다.
커스텀 언어를 위한 툴링을 직접 만들기 시작하자, 우리는 금방 전체 생태계가 "표준" JavaScript와 TypeScript 프레임워크를 중심으로 만들어져 있다는 사실을 깨달았습니다. 그 외의 것은 전부 스스로 해결해야 했고, 벽에 아주 빨리 부딪혔습니다.
Wasp 언어를 위한 VS Code extension
결국 우리는 자체 language server와 이를 위한 VS Code extension까지 개발했지만, Wasp는 Prisma의 DSL을 내장 언어로 사용하고 있었고 React & Node.js 파일에 대한 참조도 많았기 때문에, 우리가 원하던 수준의 80% 정도에만 도달할 수 있었습니다.
커스텀 언어를 유지하면서 쌓여 온 모든 고통, 그리고 새로운 개발자들이 한번 써 보도록 설득하는 과정에서의 지속적인 마찰을 겪고 나서, 우리는 문제의 근본 원인이 단순히 "개발자들이 새로운 웹 프레임워크를 두려워한다"는 것보다 더 깊다는 사실을 깨달았습니다.
사용량은 계속 증가했고, 점점 더 많은 사람들이 Wasp 앱을 프로덕션에 배포하고 있었지만, 무엇을 시도하든 결국 항상 "Wasp로 하려는 일은 정말 마음에 드는데, 왜 커스텀 언어죠?"라는 질문으로 되돌아왔습니다. 마치 우리는 늘 손브레이크를 당긴 채 운전하고 있는 느낌이었습니다.
마침내, 우리가 언어를 통해 얻고자 했던 ergonomics도 생각만큼 중요하지 않았다는 점이 드러났습니다. 개발자들은 몇 줄과 중괄호가 조금 더 필요하더라도, 자신이 익숙한 TypeScript를 사용하는 데 전혀 불편함을 느끼지 않았습니다.
Wasp를 시작했을 때, 우리에게 "language"와 "specification"이라는 용어는 사실상 동의어였습니다. 둘 중 하나 없이 다른 하나를 상상할 수 없었습니다.
하지만 개발자들이 Wasp를 사용하는 모습을 보고, 그들이 실제로 무엇에 흥분하는지를 보면서, 핵심은 언어가 아니라는 사실이 분명해졌습니다. 핵심은 Wasp가 고수준 명세, 예를 들어 main.wasp 그리고 이제는 main.wasp.ts를 통해 앱 전체를 완전히 이해하고 있다는 점이었습니다. 그래서 개발자는 자신의 앱이 어떻게 동작하는지 한눈에 쉽게 파악하고, 통제하고 있다는 느낌을 받을 수 있었습니다.
이를 더 실감 나게 전달하기 위해 우리가 시도한 방법 중 하나가 wasp studio 명령이었습니다. 터미널에서 실행하면, Wasp가 컴파일 시점에 당신의 앱을 어떻게 "보고" 있는지, 그리고 대상 코드를 생성하기 전에 그것에 대해 어떻게 추론하는지를 확인할 수 있습니다.
wasp studio - Wasp가 당신의 앱 구조를 "보는" 방식
이런 종류의 "지원 시스템"이 있다는 것은 앱을 만드는 과정을 훨씬 더 관리된 경험으로 만들어 주었습니다. AI가 점점 더 많은 코드를 작성하고, 개발자들이 생성된 코드를 덜 자주 리뷰하게 되면서, 이는 더더욱 가치가 커졌습니다. 특히 기술적 배경이 덜한 새로운 세대의 빌더들, 이른바 "vibe-coders"에게는 더욱 그렇습니다.
그리고 이런 앱 수준의 이해는 Wasp의 커스텀 언어에서 TypeScript로 전환해도 전혀 바뀌지 않습니다. 우리가 바꾼 것은 컴파일러의 "프런트엔드"뿐, 즉 Wasp에서 고수준 앱 명세를 정의하는 방식뿐입니다.
// Page & route definitionconst loginPage = app.page('LoginPage', { component: { importDefault: 'Login', from: '@src/pages/auth/Login' }});app.route('LoginRoute', { path: '/login', to: loginPage });// Queryapp.query('getTasks', { fn: { import: 'getTasks', from: '@src/queries' }, entities: ['Task']});// Async jobapp.job('mySpecialJob', { executor: 'PgBoss', perform: { fn: { import: 'foo', from: '@src/jobs/bar' }, executorOptions: { pgBoss: { retryLimit: 1 } } }, entities: ['Task']});export default app;
우리는 피드백을 살피기 위해 Wasp용 TypeScript SDK를 실험적 초기 프리뷰 기능으로 도입했습니다. 그리고 매우 긍정적인 반응을 받았습니다. 일부 신규 사용자는 곧바로 이 방식을 선택했고, Wasp 언어는 아예 써 보지도 않았습니다. 이것은 우리가 계속 나아가야 한다는 신호였습니다.
내부적으로, 그리고 Wasp 커뮤니티 안에서 충분히 테스트한 뒤, 이제 우리는 이것이 앞으로 나아갈 길이라고 확신합니다. 처음 마주하는 "왜 새 언어인가요?"라는 질문을 우회할 수 있을 뿐 아니라, 수년간 싸워 온 문제들을 모두 해결해 주기 때문입니다.
모든 editor가 별다른 설정 없이 즉시 동작합니다. 개발자들은 conditionals, loops, imports를 사용할 수 있습니다. 예를 들어 자신만의 file-based routing을 구현할 수도 있습니다. 명세를 여러 파일로 나누는 것도 아주 쉬워집니다. 그리고 Full Stack Modules 같은 우리가 오래전부터 만들고 싶었던 고급 기능들을 위한 견고한 기반도 제공해 줍니다.
돌이켜보면, Wasp는 아마 우리가 처음에 그런 방식으로 시작하지 않았다면 세상에 나오지 못했을 것입니다. 그것은 당시 우리가 만들고 싶었던 것을 표현하는 최선의 방식이었고, 개인적인 편향도 조금 섞여 있었으며, 솔직히 말해 그냥 재미있다고 생각했던 일이기도 했습니다. "미친 아이디어처럼 들리는 건 알지만, 정말 이게 되는지 보고 싶다"는 호기심이 아무도 지켜보지 않을 때조차 우리를 계속 앞으로 밀어 주었습니다.
DSL 접근법은 specification이 implementation과 분리되어야 한다는 우리의 비전에 충실하도록 만들어 주었습니다. 우리는 여전히 다른 언어와 런타임, 예를 들어 Python이나 Rust를 지원하는 가능성에도 관심이 있고, 컴파일 시점에 앱의 전체 그림을 갖고 대상 코드를 생성하기 전에 그것에 대해 추론할 수 있다는 점이 주는 이점에도 관심이 있습니다. 이것은 서로 다른 아키텍처 지원, 최적화 등 다양한 가능성을 열어 줍니다.
마지막으로, AI agent가 점점 더 많은 코드를 작성하게 되면서, 우리는 더 많은 개발자들이 처음부터 더 많은 구조와 opinion을 제공하는 도구를 찾고 있는 것을 봅니다. 그렇게 하면 기능 추가가 더 예측 가능해지고, 생성된 코드도 더 이해하고 리뷰하기 쉬워집니다.
Wasp는 여기에서 완벽하게 들어맞습니다. Wasp는 앱의 전체 스택에 걸쳐 있고, 모든 것이 항상 함께 잘 동작하도록 보장하기 때문입니다. 그래서 많은 개발자들이 Django, Rails, Laravel 같은 "올드스쿨" 모놀리식 프레임워크에 다시 매력을 느끼는 것이기도 합니다. Wasp는 JS 생태계를 위해 동일한 경험, 그리고 "그냥 다 잘 된다"는 느낌을 제공하는 것을 목표로 합니다.
우리는 Wasp를 사용하는 개발자들로부터, 이것이 AI와 가장 잘 맞는 스택이라는 이야기를 반복해서 듣고 있습니다. 어떤 이들은 심지어 Wasp에 정착하기 전에 10가지 다른 솔루션을 시도해 보기까지 했습니다.
앞으로 몇 주 안에 우리는 Launch Week를 진행할 예정이며, 그 기간 동안 TypeScript SDK를 Wasp를 사용하는 기본 방식으로 출시할 것입니다. 우리는 이미 커뮤니티 내부에서의 기대감을 확인했고, 여러분이 어떻게 생각할지 빨리 듣고 싶습니다.
Wasp가 궁금했던 적이 있다면, 지금이 시도해 보기에 완벽한 시점입니다. 더 이상 새로운 언어를 배울 필요가 없습니다. 그저 TypeScript만 있으면 되고, 나머지는 Wasp가 내부에서 모두 처리해 줍니다.
계속 소식을 받아보고 싶다면 Discord에 참여하거나, X/Twitter에서 Wasp 또는 저를 팔로우해 주세요.