결론부터 말하면 TypeScript 풀스택입니다.
뻔한 결론 같지만, 선택 과정에는 여러 방향과 고민이 있었고 결과적으로 개인적 취향과는 전혀 다른 선택을 하게 됐습니다.
풀스택의 두 가지 의미
하나는 프론트엔드와 백엔드 두 역할을 혼자 모두 개발한다는 의미의 풀스택이고, 다른 하나는 단일 웹 프레임워크로 하나의 제품을 개발하는 방식입니다.
전자는 지금까지 현업에서 해온 방식이라 익숙하고, 역할 구분이 외부에서 물리적으로 이루어져 경계가 명확하지만 초기 개발 오버헤드가 있습니다. 후자는 보다 전통적인 웹 개발 방식으로 초기 진행이 빠르지만, 서비스를 고도화하려면 레이어 분리와 추가 개발이 필요해질 수도 있습니다.
이 선택은 쉬웠습니다. 전편에서 언급했듯이, 성공할지 아직 모르는 서비스에 많은 비용과 시간을 들이는 것보다, 서비스 성장과 함께 점진적 개선을 추구하는 린 스타트업 방식에는 풀스택 웹앱이 더 잘 맞습니다.
성능과 스케일 이슈가 생기면 기존 웹앱을 BFF(Backend for Frontend)로 남기고 백엔드를 분리·확장하고, 모바일 앱이 필요하면 하이브리드로 감싼 뒤 모바일 고도화 시점에 웹뷰를 점진적으로 네이티브로 전환하고, SaaS라면 마케팅 사이트와 웹앱을 SPA로 분리합니다.
물론 라이브 서비스를 리팩토링하고 시스템 아키텍처를 변경하는 일은, 달리는 차에서 엔진을 교체하는 것에 비유될 만큼 리스크가 크고 어려운 작업입니다. 하지만 이런 요구사항이 생긴다는 것 자체가 서비스의 성공 가능성이 보인다는 신호이고, 막상 이런 리팩토링을 해보면 나름의 쾌감이 있기도 합니다. 무엇보다 불확실성에 필요 이상의 비용을 투입하지 않아야 합니다.
취향보다 생태계
풀스택 웹 프레임워크 선택은 여기서부터 상당히 고민스러웠습니다.
메인 후보는 Ruby on Rails, PHP Laravel, Python Django, C# .NET(Blazor), Swift Vapor였고, Elixir Phoenix, Rust Rocket, Go Gin, Kotlin Ktor는 마이너 후보로 두었습니다. 어디까지나 개인적인 분류입니다. 선택 기준은 취향에 맞는 언어, 배터리 포함(batteries included) 여부, 생태계 성숙도였습니다.
웹 개발로 전환하기 전에는 C/C++로 윈도우와 임베디드 리눅스를 개발하고, Objective-C/Swift로 iOS를 개발해 왔습니다. 모두 컴파일 언어이자 정적 타입 언어입니다. 이런 경력이 쌓이다 보니 Ruby, Python, JavaScript 같은 스크립트 언어에서는 미묘한 이질감을 느낍니다. 특히 JavaScript는 누군가는 쉽다는 이유로 웹 개발 입문자에게 추천하는 언어이지만, 복잡한 생태계는 차치하고서라도 그 동작 방식이 난해하게 느껴져서 JavaScript 웹 프레임워크는 후보에서 제외했습니다. 이때는 그랬습니다.
컴파일 언어를 좋아하고 Swift가 가장 익숙하다 보니 Vapor를 공부해 봤지만, 생태계가 너무 미성숙해서 실망했습니다. API 서버로는 나쁘지 않지만 풀스택 웹 프레임워크로는 턱없이 부족합니다. Rails, Laravel, Django, .NET을 제외하면 나머지 후보들도 생태계 성숙도 측면에서 부족한 부분이 있었습니다. 물론 저마다 성공적인 실제 사례가 있지만, 1인 개발자가 선택하기에는, 특히 API 서버가 아닌 풀스택 웹앱 개발을 목표로 하기에는 진입 문턱이 높을 것으로 예상됐습니다.
Laravel과 .NET
네 후보 중 Laravel과 .NET을 두고 오래 고민했습니다. Laravel은 인디, .NET은 엔터프라이즈 성격이 강하고, 둘 다 풍부한 배터리와 성숙한 생태계를 갖추고 있습니다.
풍부한 배터리 내장이 중요한 이유는, 프레임워크가 추구하는 '하나의 올바른 정답'이 생산성을 높인다고 보기 때문입니다. 굳이 비유하자면 Vue와 React의 관계와 비슷합니다.
10여 년 전, TIPS(정부 기술창업 지원 프로그램) 단계의 소규모 팀을 리딩한 적이 있습니다. SPA가 주류로 자리 잡기 시작한 지 얼마 지나지 않았을 때라, 프론트엔드 담당자와 함께 React, Vue, Angular 세 가지를 검토해야 했습니다. 지금도 그렇듯 당시에도 React가 대세였지만, 팀은 Vue를 선택했습니다. 프레임워크가 추구하는 하나의 올바른 방식과 쉬운 사용법이, 담당자가 바뀌어도 제품의 균질한 품질과 생산성을 보장해 줄 것이라는 판단에서였습니다.
1인 개발자에게는 이런 판단이 필요하지 않을 수도 있습니다. 하지만 라이브러리를 직접 검증하고 선택하는 시간과 실수를 줄여 준다는 점에서는 여전히 유효하고, Laravel과 .NET은 그 조건을 충분히 만족시킵니다.
.NET Blazor는 꽤나 심각하게 고민했습니다. C#을 HTML, CSS와 함께 JavaScript를 대체하는 언어로 쓸 수 있다는 점, 그리고 웹어셈블리(WebAssembly)를 편리하게 통합할 수 있다는 점이 좋아 보였습니다. (웹어셈블리로 프론트엔드의 언어 선택을 넓히려는 흐름은 웹의 진보 방향이라고 봅니다. 다만 아직 엣지 기술이라 실무 허들은 큽니다.) 게다가 .NET은 웹, 모바일, 데스크탑, 서버, 게임까지 거의 모든 것을 아우르는 강력한 플랫폼입니다. 거대 빅테크에 영혼만 팔면 고민 없이 편안함을 누릴 수 있습니다. 마이크로소프트와 애플의 지배 아래 수년간 개발해 와서 잘 압니다. 나름의 어려움이 있더라도 확실히 편할 겁니다.
Laravel은 특히 해외 인디해커(Indie Hacker) 사이에서 인기가 많습니다. 많은 것이 갖추어져 있고, Laravel Cloud라는 인프라까지 서비스하고 있어서 다른 걱정 없이 제품에만 집중하면 될 것처럼 보입니다. 한국에서 PHP의 인식이 좋지 않지만, 최근 PHP는 많이 개선됐고 Swift가 익숙한 입장에서 봐도 상당히 모던한 언어로 보입니다. $로 시작하는 변수만 빼면 그렇습니다.
태생이 백엔드 언어인 PHP와 달리, 동갑내기 JavaScript는 열흘 만에 설계된 초기의 결함을 이미 퍼져 나간 웹과의 호환 때문에 고치지 못한 채 안고 왔습니다. 언어 자체의 진화라는 조건은 PHP 쪽이 나았지만, 정작 지금의 웹을 지배하는 쪽은 JavaScript입니다.
Livewire를 사용하면 .NET Blazor처럼 JavaScript 없이 프론트엔드를 구성할 수 있다는 것도 큰 장점입니다. 지금도 두 프레임워크의 홈페이지와 개발 문서, 공식 유튜브 채널을 가끔 다시 찾습니다. 볼 때마다 무언가 만들어 보고 싶어집니다.
그럼에도 선택은 TypeScript 풀스택이었습니다. 결정을 바꾼 것은 직접 만들 제품이 아니라, 외주 개발 고객의 기술 스택을 정하던 과정이었습니다.