Background
Bento의 부드러운 UX와 시각적 자유도를 좋아했지만 서비스 종료 후 이를 대체할 서비스를 찾기 어려웠습니다. Linktree와 여러 대안을 사용하며 기능의 수보다 페이지를 직접 구성하는 자유, 자연스러운 편집 경험, 세심한 상호작용이 더 중요하다는 점을 확인했습니다.
그래서 Link in Bio의 본질은 유지하면서도, 링크를 나열하는 데 그치지 않고 자신만의 아이덴티티를 표현할 수 있는 서비스를 만들고자 Grabbin을 시작했습니다.
Contributions
API를 별도 Hono 서버로 완전 분리한 구조 설계
문제 배경
기존에는 Route Handler를 통해 DB에 직접 접근했습니다. 초기 개발은 빠르지만 API와 도메인이 복잡해질수록 프론트엔드와 서버 책임이 강하게 얽혔고, 엔드포인트가 늘어날수록 Route Handler 내부 로직이 비대해져 가독성과 유지보수성이 떨어졌습니다.
또한 프론트엔드와 서버가 하나의 프로젝트로 구성되어 있어 서버 API 계약만 수정해도 웹 전체를 다시 빌드해야 했습니다. 프론트엔드 코드에 변경이 없어도 빌드와 배포를 반복해야 해 서버 변경 사항을 빠르게 검증하기 어려웠습니다.
접근 방식
API를 완전히 분리해 별도의 Hono 서버로 구축하고, 클라이언트는 정의된 API 계약만 바라보도록 정리했습니다. 필요에 따라 OpenAPI 문서도 함께 맞춰 프론트엔드와 백엔드가 동일한 스펙을 기준으로 개발할 수 있게 했습니다.
성과
프론트엔드와 백엔드의 책임이 분리되어 구조가 단순해졌고, 두 영역의 배포 독립성도 확보했습니다. 또한 프론트엔드 빌드 시간이 평균 140초에서 90초로 줄어 서버 변경 사항을 더 빠르게 검증할 수 있게 되었습니다.
Cloudflare Workers와 Hono 선택 근거
빠른 프로토타입 개발과 무료에 가까운 운영 비용, 콜드 스타트가 거의 없는 환경이 필요했습니다. 초기에는 Render와 Railway도 사용해 보았지만 무료 요금제의 제약과 체감되는 콜드 스타트가 있었습니다.
이러한 요구사항을 만족하는 플랫폼으로 Cloudflare Workers를 선택했습니다. 소규모 프로젝트는 무료 요금제로도 충분히 운영할 수 있고, 안정적인 응답 속도를 제공할 수 있다는 점이 장점이었습니다.
Cloudflare Workers에서 사용할 수 있는 FastAPI는 Python을 새로 학습해야 했지만, Hono는 JavaScript와 TypeScript 기반이라 기존 기술 스택을 그대로 활용할 수 있었습니다. 공식 문서도 잘 정리되어 있어 러닝 커브가 낮다고 판단해 Hono를 API 프레임워크로 선택했습니다.