최근에 게임 개발자들을 위한 지식 공유 사이트를 만들었습니다.
게임 개발자에게 유익한 자료의 링크를 서로 공유하고, 토론하는 작은 커뮤니티입니다.

자세한 설명은 이 곳에 작성해두었습니다.

텅 빈 사이트에 아무도 들어올리 없겠죠?
초기 데이터를 채우기 위해 AI 를 활용하고 있습니다.
AI 가 매일 아침 미리 준비된 매체들을 스캔한 다음, 사이트의 철학과 어울리는 글을 선별해 업로드합니다.

당장은 영어권 사용자가 타깃이지만,
트래픽이 많아지면 언어별 번역 + 요약본을 자동으로 생성해드릴 생각입니다.

게임 개발 생태계를 돕는 정보라면 무엇이든 환영합니다.
좋은 자료가 있다면 얼마든지 공유해주세요.

사이트 소개는 여기까지로 하구요.
오늘은 제작 과정에서 사용한 기술에 대해 적어보려구요.

Deno, Turso DB 같은 새로운 기술을 써봤는데,
후기나 레퍼런스 코드가 없어서 조금 외로웠거든요.

커뮤니티에 기여하는 마음으로 이 프로젝트를 오픈소스화 했으니 여기에서 소개하는 기술에 관심이 있으시다면 참고해주세요.

목차:

• Deno 2.0
• Deno Deploy
• Fresh
• Turso

Deno

NodeJS 제작자가 절치부심하고 다시 만든 런타임이라고 하니 어떤 점이 좋아졌을까 궁금했습니다.

그런데 이 사람, Deno 만 새로 만든 것이 아니라 한 세트를 만들었더라구요.
Deno Runtime
Deno Deploy (Deno Serverless Hosting Platform)
Deno Standard Library (Deno 팀이 제공하는 스탠다드 유틸리티 APIs)
JSR (npm 대체용 패키지 레지스트리)
Fresh (Deno Web Framework)

Deno 로 웹 서비스를 구축하기 위해 필요한 모든 것을 준비했다는 느낌이 들었습니다.
이번에 모두 사용해봤는데요.
과연 매끄럽게 진행됐을까요?

Deno 에 대해 이야기 하자면, 굉장히 만족스러웠습니다.
NodeJS 로 돌아가고 싶지 않아요.

Built-in Typescript,
Built-in Formatter,
Built-in Linter,
Built-in Test Runner,
Built-in Compiler,
...

Node 에서 저를 괴롭히던 설정 파일들이 전부 사라졌습니다.
모두 Deno 에 내장되어 있고, deno.json 파일에서 전부 관리할 수 있습니다.
JSON 대신, deno.config.ts 같은 이름의 .ts 파일이었다면 더 좋을것 같지만요.
package.json 에 주석을 달지 못하는 것이 참 아쉬웠거든요.

Node 는 NPM 과 버전이 연결되어 있다는 것이 정말 스트레스 인데요.
가끔 실수로 다른 노드 환경에서 npm install 커맨드를 실행하면 lockFileVersion 이 조용히 바뀌어 버립니다.
그렇게 은근슬쩍 git 에도 올라가고, 종종 pr 도 통과합니다.
나중에서야 알아차리고 되돌려 놓죠.

그럼에도 기업에서 사용하는 것은 아직 이르다고 생각합니다.
Deno 팀은 Node 앱을 바로 Deno 에서 돌릴 수 있다고 하지만요.

사용해본 입장에서 보면 장애물이 조금 있습니다.

1. node_modules 경로 문제
   Deno 는 기본적으로 프로젝트 경로에 node_modules 가 없습니다.
   문제는 일부 npm 패키지들이 node_modules 경로에 의존성이 위치할 것이라 가정하고 설계되었다는 점입니다.
   해결하기 위해서는 deno.json 에서 루트에 node_modules 를 만들도록 설정해야 합니다.
2. Deno 의 권한 플래그 문제
   Deno 는 프로그램 안전성을 위해 권한 요청 플래그를 사용해야만 중요한 기능들을 사용할 수 있도록 설계됐습니다.
   예. deno run --allow-net main.ts.
   이로 인해 npx 커맨드가 오류를 뱉는 경우가 있습니다.
3. AWS Deno 런타임 지원 문제
   아직 AWS 람다가 Deno 런타임을 네이티브로 지원하지 않습니다.
   직접 만들면 되는데 번거롭죠.
4. DB 드라이버 호환 문제
   일부 DB 드라이버가 Deno 에서 오류를 뱉습니다.
   예. better-sqlite3.
   취미 프로젝트라면 어렵지 않게 우회할 수 있지만, 회사에서 이런 문제를 마주하면 머리가 뜨거워집니다.

제가 마주한 크고 작은 문제들입니다.

Deno 정말 잘 만든 소프트웨어 이지만,
아직은 취미 영역에서 파이를 키워야 하는 단계가 아닐까 싶네요.

Deno Deploy

Deno 팀이 제작한 서버리스 호스팅 서비스입니다.
수익화에 대한 고민이 있었나봅니다.

아무래도 강력한 경쟁자인 Bun 이 VC로부터 지원을 받고 있으니 그럴 수밖에요.

Deno Deploy 의 마케팅 포인트는 크게 두 가지 입니다.

1. Deno 런타임을 First Class 로 지원.
2. Deno Cron, Deno KV, Deno Queue 를 서버리스 환경에서 지원
   Deno 는 위 기능을 네이티브로 지원하지만 서버리스 환경에서는 쉽게 사용할 수 없겠죠?

둘 다 잘 해줍니다. 그런데 왜 망하고 있을까요?

1. 공지 없이 줄어드는 Edge Region.
   35개 -> 12개 -> 6개 로 줄었습니다.
   어떤 사람이 이런 서비스를 믿고 사용할까요?
   사용자들의 반응도 싸늘합니다.
2. 너무 느린 Start Time.
   저의 경우, 콜드스타트가 아님에도 페이지 로딩에 1~2 초가 걸렸습니다.
   콜드스타트에는 5초 이상 걸렸구요.
   물론 다른 사이트를 확인해보면 그렇지 않은 경우도 많았지만, 저는 일관되게 느린 속도를 경험했습니다.
   결국 Railway.com 으로 옮길 수밖에 없었습니다.

요즘 호스팅 서비스들, 취미 유저 잡느라 박터지게 싸웁니다.
고작 cron job, kv 편하게 쓸 수 있다고해서 넘어오지 않아요.
Free Tier 늘리고, 리전 늘리고, 속도 최적화 하고, DX 개선하고... 해도 힘든 시장인데 너무 순진하게 진입한 것 같다는 생각이 듭니다.

+) Deno 팀은 왜 서버리스를 선택한걸까요?
취미 유저들이 많을텐데 이 사람들이 만든 서비스는 방문자가 없단 말입니다.
매 방문이 콜드스타트라구요.
바이럴이 일어나기 어려운 구조입니다.

Fresh

Deno 팀이 제작하는 웹 프레임워크입니다.

가볍고, 단순하고, 직관적입니다. 잘 만들었어요.
클라이언트 영역이 복잡한 프로젝트가 아니라면, 고민 없이 선택할 좋은 도구입니다.

Fresh 는 NextJS, SvelteKit 같은 SSR 프레임워크와 근본적으로 다른 점이 있어서 재미있습니다.

SSR 프레임워크는 첫 로딩시에만 서버에서 렌더링을 하는 Server Rendered Single Page App 인데 반해,
Fresh 는 정직한 Multi-Page 앱 입니다. 오히려 Reactive 한 템플릿 엔진에 가까워요.

SSR 프레임워크는 클라이언트 사이드 라우팅(CSR)이 필요해서 <a> 태그의 Wrapper 를 제공합니다. 사용자가 링크를 누르면 내부에서 JS 파일을 호출하죠.
하지만 Fresh 는 Native <a> 태그를 사용해 실제로 다음 페이지의 문서를 불러옵니다.

그래서 가볍고 직관적입니다.

제가 CSR 을 싫어하기도 해서 그렇게 느낄수도 있습니다.
저는 CSR 이 전통적인 Multi Page App 의 사용성을 모방하기 위해 너무나 많은 것을 덧씌웠다고 생각하거든요.
부작용은 말할것도 없구요.

유저가 페이지 전환을 정확히 인지하기 어려운 점,
페이지 전환시 스크롤 위치가 그대로 유지되는 점,
SEO 를 위해 온갖 꼼수를 부려야 하는 점,
브라우저 히스토리를 사람이 직접 관리해야 하는 점,
새로고침 하면 페이지가 어디로 바뀌어 있을지 모르는 불안함,
스크린리더가 페이지 변화를 인식하기 어려운 점,
...
모바일 웹으로 가면 더 합니다.

아무튼.
갑자기 화가 나서 조금 샜네요.

그럼 Fresh 는 CSR 을 지원하지 않는가?
그건 아닙니다.

Partials 라는 기능을 사용하면 유저가 <a> 태그를 누를때 페이지의 일부분만 갈아끼울 수 있습니다.
HTMX 를 사용해보셨다면 hx-target, hx-swap 과 동일하니 익숙하실겁니다.

다만, 개인적으로는 추천하지 않으며, Partials 를 자주 써야 하는 상황에 놓였다면 Fresh 대신 다른 SSR 프레임워크를 사용하시는 것이 맞습니다.
(Partial 영역들을 타입으로 관리할 수가 없어서 Magic String 이 많이 생길 수밖에 없는 구조입니다.)

마지막으로, “Fresh 망했나요” 가 종종 올라오는데요.
망한거 아닙니다.

그냥 Deno 팀이 벌려놓은 일이 많아서 손이 부족해 보여요.
v1.7 도 프로덕션에서 사용하기 충분합니다.

로드맵을 보면 v2 에서는 서버 프레임워크로서의 입지를 굳히려는 듯 합니다.
NextJS 와 비슷했던 문법을 Express 와 비슷하게 바꾼다고 하네요.

Turso DB

libSQL 기반 클라우드 DB 스타트업입니다.

취미 프로젝트에서 제일 비싼게 DB 호스팅인데요.
Turso 는 무료 사용자에게 DB 를 500 개나 줍니다.

창업자의 인터뷰 영상인데 아이디어가 정말 재미있습니다.
SQLite 는 파일 하나짜리 DB 라서 아주 저렴한 비용으로 DB-per-User 를 실현할 수 있답니다.

가장 마음에 드는 점은 DB 를 만들고, 연결하는 과정이 너무나 편하다는 것입니다.
이 팀이 DX 에 공을 들인다는 증거겠죠?

Turso 가 밀고 있는 기능 중 하나가 Embeded Replicas 인데요.
DB 의 레플리카를 서버 인스턴스에 직접 설치해서 주기적으로 동기화 하는 기능입니다.

game-news.dev 에서 사용중인데요. 장단점이 있습니다.
덕분에 READ 속도가 0 이 되었지만, WRITE 액션이 발생할 때 마다 레플리카에도 실시간으로 동기화를 해주기 때문에 WRITE 속도가 더 느려집니다. (Turso 는 이 기능을 Read-Your-Writes 라고 합니다.)
거기에 가끔 알 수 없는 이유로 레플리카가 폭발해서 사이트가 터집니다.
거슬릴 정도는 아니라서 사용자가 많아지면 고쳐보려구요.

마치며

더 많은 사람들이 Deno, Fresh, Turso 를 사용하길 바라는 마음에 작성한 글입니다.
그래서 소스코드도 공개한 것이구요.

궁금한 점이 있다면 메일로 보내주세요.

아, 물론 game-news.dev 도 많이 들어와주시길 바랍니다 ^_^