Customer Support

2026년 현재, 노코드(No-code) 툴은 빠른 MVP 제작에 있어서 여전히 강력한 선택지입니다.
저 역시 초기 서비스는 Bubble을 활용해 빠르게 런칭할 수 있었습니다.

하지만 서비스가 성장하면서 한계는 분명히 드러났습니다.

오늘은 Bubble 기반 SaaS를 Supabase + Node.js 구조로 전환한 이유와 과정을 공유합니다.

왜 노코드를 버리게 되었나?

초기에는 정말 만족스러웠습니다.

• 개발 없이 빠른 출시
• UI/UX 즉시 구현 가능
• 간단한 로직 처리

하지만 사용자와 데이터가 늘어나면서 문제가 발생했습니다.

1. 성능 한계

데이터가 많아질수록 API 응답 속도가 느려졌고, 복잡한 쿼리는 처리하기 어려웠습니다.

2. 확장성 부족

• 외부 API 연동 제한
• 커스텀 로직 구현 어려움
• 서버 사이드 제어 불가

3. 비용 문제

트래픽이 늘어날수록 비용 구조가 비효율적으로 증가했습니다.

전환 아키텍처

전환 후 구조는 다음과 같습니다:

• Frontend: 기존 Bubble 유지 (점진적 전환)
• Backend: Node.js (API 서버)
• Database: Supabase (PostgreSQL + RLS)
• Auth: Supabase Auth

이 구조의 핵심은
“프론트는 유지하고, 백엔드만 먼저 분리” 입니다.

 Supabase를 선택한 이유

Supabase는 단순한 DB가 아니라
Backend-as-a-Service + 확장 가능한 구조를 제공합니다.

주요 장점

• PostgreSQL 기반 (확장성 확보)
• Row Level Security (보안 설계 가능)
• 실시간 데이터 처리
• REST / RPC 자동 생성

특히 RLS 정책 기반 데이터 제어는 SaaS 구조에 매우 적합했습니다.

Node.js API 서버 도입

Bubble의 가장 큰 한계를 해결하기 위해
API 서버를 별도로 구축했습니다.

역할 분리

• Bubble: UI 렌더링
• Node: 비즈니스 로직 처리
• Supabase: 데이터 관리

이 구조로 바꾸면서 얻은 것:

• 복잡한 로직 처리 가능
• 성능 개선
• 외부 서비스 연동 자유도 증가

전환 후 변화

전환 이후 체감한 변화는 확실했습니다.

• API 응답 속도 개선
• 데이터 처리 안정성 확보
• 개발 확장성 확보

무엇보다 중요한 건
“서비스 구조를 내가 통제할 수 있게 됐다”는 점입니다.

결론

노코드는 시작을 빠르게 만들어줍니다.
하지만 성장 단계에서는 반드시 구조 전환을 고민해야 합니다.

추천 전략은 다음과 같습니다:

1. MVP는 노코드로 빠르게
2. 트래픽 증가 시 백엔드 분리
3. 점진적으로 코드 기반 전환

마무리

2026년은 “AI + 노코드 + 코드”가 공존하는 시대입니다.

중요한 건 기술 선택이 아니라
지금 단계에서 가장 적합한 구조를 선택하는 것입니다.