Supabase를 연결하는 방법: 서버 접근을 추천하는 이유

Supabase를 연결해달라고 하면 AI는 보통 화면에서 Supabase SDK를 직접 호출하는 코드를 만들어줍니다.

브라우저
→ Supabase SDK
→ 데이터베이스

빠르게 앱을 만들 수 있는 좋은 방법입니다. 하지만 Supabase를 사용하는 유일한 방법은 아니에요.

브라우저가 데이터베이스에 직접 요청하지 않고, 서버가 중간에서 데이터 접근을 담당하게 만들 수도 있습니다.

브라우저
→ 앱의 서버
→ Supabase 데이터베이스

두 방식의 차이는 단순히 코드를 작성하는 문법에 있지 않습니다. 사용자 권한과 앱의 중요한 규칙을 어디에서 관리할 것인지가 달라져요.

프론트엔드, 애플리케이션 서버, 데이터베이스의 역할이 아직 낯설다면 웹 애플리케이션의 기본 구조를 먼저 읽어보세요.

Supabase는 데이터베이스이기도 해요

Supabase를 Firebase와 비슷한 백엔드 서비스로만 생각하기 쉽지만, Supabase 프로젝트 안에는 PostgreSQL 데이터베이스가 있습니다.

그래서 Supabase가 제공하는 JavaScript SDK를 사용할 수도 있고, 일반 PostgreSQL 데이터베이스처럼 서버에서 직접 연결할 수도 있어요.

중요한 것은 데이터베이스를 호출하는 도구가 아니라 데이터베이스 작업을 브라우저가 직접 실행하는지, 서버가 대신 실행하는지예요.

브라우저에서 Supabase SDK로 접근하는 방식

첫 번째 방식에서는 화면 코드가 Supabase에 직접 데이터를 요청합니다.

할 일 목록을 보여준다면 브라우저에서 todos 테이블을 조회하고, 사용자가 입력한 할 일을 같은 방식으로 저장해요.

별도의 서버 기능을 많이 만들지 않아도 되기 때문에 빠르고 간단합니다. 아이디어를 확인하기 위한 프로토타입이나 개인용 앱을 만들 때 특히 편리해요.

대신 브라우저에서 데이터베이스로 직접 요청을 보내기 때문에 RLS 정책이 필요합니다.

로그인한 사용자는 자신의 데이터만 볼 수 있다
다른 사용자의 데이터는 수정할 수 없다
관리자만 전체 데이터를 볼 수 있다

이런 권한을 데이터베이스 정책으로 만들어야 합니다. RLS가 무엇인지 먼저 알고 싶다면 Supabase를 연결했더니 RLS를 설정하래요 글을 참고해보세요.

사용자마다 자신의 데이터만 조회하고 수정하는 단순한 앱이라면 이 구조로도 충분할 수 있습니다.

하지만 앱에 결제, 관리자, 승인 절차, 사용자 역할 같은 기능이 추가되면 RLS 정책만으로 전체 권한을 파악하기 어려워질 수 있어요.

앱 서버를 통해 접근하는 방식

두 번째 방식에서는 브라우저가 Supabase 테이블을 직접 조회하지 않습니다.

브라우저는 앱의 서버에 필요한 작업을 요청합니다.

내 예약 목록을 보여줘
새 주문을 접수해줘
이 예약을 취소해줘

서버는 요청을 받은 뒤 다음 순서로 처리해요.

1. 로그인한 사용자를 확인한다
2. 이 작업을 할 권한이 있는지 확인한다
3. 앱의 업무 규칙을 확인한다
4. 서버가 데이터베이스를 조회하거나 수정한다
5. 필요한 결과만 브라우저에 돌려준다

데이터베이스 연결 정보는 서버만 가지고 있습니다. 브라우저에는 데이터베이스 비밀번호나 접근 코드가 포함되지 않아요.

바이브코딩이 연결 방식의 기준을 바꿨어요

예전에는 Supabase SDK로 브라우저에서 데이터베이스에 직접 접근하는 방식이 앱을 만드는 시간을 크게 줄여줬습니다.

서버를 직접 만들려면 API 주소를 설계하고, 요청을 검사하고, 데이터베이스 코드를 작성하고, 오류를 처리하는 작업이 필요했어요. 간단한 앱에도 작성해야 할 코드가 많았기 때문에 이 과정을 건너뛸 수 있다는 것은 큰 장점이었습니다.

Supabase SDK를 사용하면 화면에서 바로 데이터를 조회하고 저장할 수 있었습니다. 백엔드 개발 경험이 부족해도 작동하는 앱을 빠르게 만들 수 있었어요.

하지만 바이브코딩에서는 이 기준이 조금 달라졌습니다.

AI에게 앱의 기능과 규칙을 설명하면 서버 API, 데이터베이스 코드, 입력값 검사, 오류 처리 코드의 초안을 빠르게 만들 수 있습니다.

예약 생성 API를 만들어줘. 로그인한 사용자만 요청할 수 있고, 수업 정원이 남아 있을 때 예약을 저장해줘. 같은 사용자가 같은 수업을 중복 예약할 수 없게 하고, 실패 이유를 화면에 알려줘.

예전에는 직접 작성하기 부담스러웠던 서버 코드도 이제는 자연어로 요구사항을 설명하며 시작할 수 있어요.

물론 AI가 만든 서버 코드를 검토하고 테스트하는 일은 여전히 필요합니다. 하지만 단순히 “서버 코드를 많이 작성해야 한다”는 이유만으로 브라우저 직접 접근 방식을 선택할 필요는 줄어들었습니다.

초기 코드 몇 줄을 줄이는 것보다 다음 질문이 더 중요해졌어요.

사용자 권한을 어디에서 확인할 것인가?
앱의 중요한 규칙을 어디에 모을 것인가?
문제가 생겼을 때 어느 코드를 확인할 것인가?
기능이 늘어나도 구조를 이해할 수 있는가?

바이브코딩은 서버를 없애는 도구라기보다, 서버에 비즈니스 로직을 직접 만드는 비용을 낮춰주는 도구로 사용할 수 있습니다.

이유 1. 권한을 기능과 함께 관리할 수 있어요

사용자 권한은 단순히 “내 데이터인가?”만 확인하고 끝나지 않는 경우가 많습니다.

예약 앱을 예로 들어볼게요.

• 고객은 자신의 예약만 볼 수 있습니다.
• 강사는 자신이 담당한 수업의 예약만 볼 수 있습니다.
• 관리자는 모든 예약을 볼 수 있습니다.
• 고객은 수업 시작 24시간 전까지만 예약을 취소할 수 있습니다.
• 관리자는 시간이 지나도 특별한 사유가 있으면 취소할 수 있습니다.

이 규칙을 데이터베이스 정책만으로 관리하면 여러 테이블과 역할을 확인하는 SQL이 필요할 수 있습니다. 화면 코드에도 별도의 조건이 들어가면 실제 권한이 어디에서 결정되는지 찾기 어려워져요.

서버 중심 구조에서는 예약 취소 기능 안에 필요한 검사를 순서대로 모을 수 있습니다.

예약 취소 요청
→ 로그인 확인
→ 예약 주인 또는 관리자 확인
→ 취소 가능한 시간인지 확인
→ 환불이 필요한지 확인
→ 예약 상태 변경

기능을 읽으면 누가 어떤 조건에서 작업할 수 있는지 함께 알 수 있습니다. 권한 규칙을 바꿀 때 확인해야 할 범위도 분명해져요.

이유 2. 실제 서비스의 업무 규칙을 표현하기 쉬워요

앱의 중요한 규칙은 데이터 조회 권한보다 복잡합니다.

쇼핑몰에서는 재고가 있을 때만 주문을 받아야 하고, 예약 앱에서는 정원이 남아 있을 때만 신청을 받아야 합니다. 강의 서비스에서는 결제가 완료된 사용자에게만 영상을 보여줘야 할 수도 있어요.

이런 조건은 단순히 특정 행을 볼 수 있는지 판단하는 문제가 아닙니다.

현재 상태는 무엇인가?
마감 시간이 지났는가?
재고나 정원이 남아 있는가?
결제가 실제로 완료되었는가?
이전 단계가 정상적으로 끝났는가?

서버에서는 이 조건들을 하나의 기능 흐름으로 작성할 수 있습니다. 요구사항이 바뀌어도 관련 기능을 중심으로 수정할 수 있어요.

이유 3. 여러 데이터 변경을 하나의 작업으로 묶을 수 있어요

실제 기능은 한 테이블만 수정하고 끝나지 않는 경우가 많습니다.

주문이 완료되면 다음 작업이 함께 실행될 수 있어요.

주문 상태 변경
재고 차감
결제 기록 저장
쿠폰 사용 처리
알림 생성

중간에 재고 차감은 성공했는데 주문 저장이 실패하면 데이터가 서로 맞지 않게 됩니다.

서버에서는 관련 데이터 변경을 트랜잭션으로 묶을 수 있어요. 전체 작업이 성공했을 때만 저장하고, 중간에 문제가 생기면 이전 상태로 되돌리는 방식입니다.

결제, 예약, 재고, 포인트처럼 여러 값이 함께 맞아야 하는 기능에서 특히 중요합니다.

이유 4. 외부 서비스와 안전하게 연결하기 쉬워요

앱은 데이터베이스만 사용하는 것이 아닙니다.

• 결제 서비스에 결제 상태를 확인합니다.
• 이메일이나 문자 메시지를 발송합니다.
• 지도나 주소 검색 API를 호출합니다.
• AI API에 요청을 보냅니다.
• 파일을 변환하거나 보고서를 생성합니다.

이런 작업에는 브라우저에 공개하면 안 되는 비밀 키가 필요할 수 있습니다.

서버 중심 구조에서는 비밀 키를 서버 환경변수에 보관하고, 외부 서비스 호출과 데이터베이스 변경을 같은 흐름에서 처리할 수 있어요.

예를 들어 결제 성공 화면이 열렸다는 이유만으로 주문을 완료하지 않고, 서버가 결제 서비스에 실제 결제 여부를 확인한 다음 주문 상태를 변경할 수 있습니다.

API 키와 환경변수가 낯설다면 API 키와 .env가 무엇인지 글에서 이어서 볼 수 있어요.

이유 5. 브라우저에는 필요한 결과만 전달할 수 있어요

브라우저에서 테이블을 직접 조회하면 화면에 필요한 컬럼과 공개하면 안 되는 컬럼을 계속 구분해야 합니다.

서버를 거치면 각 기능에 필요한 결과만 골라서 전달할 수 있어요.

관리자 화면
→ 고객 이름, 연락처, 결제 상태 반환

일반 사용자 화면
→ 자신의 예약 시간과 상태만 반환

데이터베이스의 테이블 구조를 화면에 그대로 노출하지 않아도 됩니다. 내부 구조가 바뀌어도 서버가 같은 형태의 결과를 돌려주면 화면 코드를 함께 바꾸지 않아도 될 수 있어요.

이것이 서버를 사용하면 자동으로 안전하다는 뜻은 아닙니다. 다만 브라우저가 접근할 수 있는 범위를 앱에서 만든 기능으로 제한하기가 쉬워집니다.

이유 6. 문제가 생긴 위치를 찾기 쉬워요

바이브코딩에서 흔히 겪는 문제 중 하나는 데이터가 보이지 않거나 저장되지 않을 때 어디를 확인해야 할지 모르는 것입니다.

브라우저 직접 접근 방식에서는 화면 코드, 로그인 토큰, RLS 정책, 테이블 권한을 함께 살펴봐야 할 수 있어요.

서버 중심 구조에서는 각 요청의 처리 과정을 서버 로그로 남길 수 있습니다.

로그인 확인 성공
예약 조회 성공
취소 가능 시간 확인 실패
요청 거절: 수업 시작까지 12시간 남음

단순한 데이터베이스 오류인지, 로그인 문제인지, 앱의 규칙에 걸린 것인지 구분하기 쉬워집니다. 운영 중 발생한 문제를 재현하고 수정할 때도 도움이 돼요.

이유 7. AI에게 기능 단위로 요청하기 쉬워요

AI에게 “Supabase 연결해줘”라고만 요청하면 화면 곳곳에서 테이블을 직접 조회하는 코드를 만들 수 있습니다.

처음에는 금방 완성되지만 기능이 늘어날수록 데이터 접근 코드가 여러 파일에 흩어질 수 있어요.

서버 중심 구조에서는 요청의 범위를 기능 단위로 정할 수 있습니다.

예약 취소 API를 만들어줘. 로그인한 사용자가 자신의 예약만 취소할 수 있고, 수업 시작 24시간 전까지만 가능해야 해. 결제된 예약이라면 환불 결과를 확인한 뒤 예약 상태를 변경해줘.

AI가 수정해야 할 위치와 지켜야 할 규칙이 분명합니다.

테이블을 직접 수정하는 화면 코드보다 “주문 접수”, “예약 취소”, “관리자 승인”처럼 앱의 기능이 코드에 드러나기 때문에 나중에 다시 작업을 요청하기도 쉬워요.

서버 접근도 자동으로 안전하지는 않아요

데이터베이스를 서버에서 호출한다고 앱이 자동으로 안전해지는 것은 아닙니다.

브라우저 직접 접근 방식에서 RLS가 맡던 권한 검사를 이제 서버가 책임져야 해요.

서버는 요청을 받을 때마다 다음 내용을 확인해야 합니다.

• 로그인한 사용자인가?
• 이 데이터의 주인이 맞는가?
• 이 작업을 할 역할과 권한이 있는가?
• 현재 상태에서 이 작업을 실행해도 되는가?

데이터베이스 연결 정보도 서버 환경변수에만 보관해야 합니다. 브라우저 코드나 공개 저장소에 들어가면 안 돼요.

서버 방식으로 정했다면 사용하지 않는 브라우저의 데이터베이스 직접 접근 경로도 닫아야 합니다. RLS만 끄고 기존 접근 경로를 그대로 열어두는 것은 서버 중심 구조가 아니에요.

서버 접근을 추천하는 이유는 보안이 저절로 해결되기 때문이 아닙니다. 권한, 업무 규칙, 데이터 변경을 서버 한 곳에서 관리하기 쉽기 때문입니다.

Supabase Auth는 계속 사용할 수 있어요

서버에서 데이터베이스에 접근한다고 Supabase의 모든 기능을 포기하는 것은 아닙니다.

회원가입과 로그인은 Supabase Auth를 사용하고, 로그인한 사용자를 서버에서 확인한 다음 데이터베이스에 접근할 수 있어요.

즉 Supabase는 로그인과 PostgreSQL 운영을 맡고, 앱의 서버는 사용자 권한과 중요한 기능을 관리하는 구조입니다.

바이브코딩으로 이 방식을 요청할 때는 다음처럼 설명할 수 있습니다.

Supabase Auth는 로그인에 사용하고, 브라우저에서는 데이터베이스를 직접 조회하지 않게 해줘. 데이터 조회와 저장은 모두 서버 API를 거치고, 서버에서 Supabase PostgreSQL에 연결해줘. 모든 API에서 로그인과 사용자 권한을 확인해줘.

어떤 방식을 선택하면 좋을까요?

다음과 같은 앱이라면 Supabase SDK와 RLS로 빠르게 시작해도 좋습니다.

• 아이디어를 확인하기 위한 프로토타입
• 개인이 사용하는 간단한 앱
• 사용자별 단순 조회·추가·수정·삭제가 대부분인 앱
• RLS 정책을 직접 확인하고 테스트할 수 있는 프로젝트

반면 다음과 같은 앱이라면 서버를 통한 데이터베이스 접근을 기본 구조로 두는 편이 좋습니다.

• 결제나 환불이 있는 앱
• 관리자 기능이 있는 앱
• 사용자 역할이 여러 개인 앱
• 예약, 주문, 재고처럼 업무 규칙이 있는 앱
• 외부 API와 데이터 변경을 함께 처리하는 앱
• 고객의 개인정보나 중요한 업무 데이터를 다루는 앱
• 앞으로 기능을 계속 추가하고 운영할 앱

서버 방식은 처음 만들어야 할 코드가 조금 더 많습니다. 하지만 실제 서비스에서는 기능을 추가하고 문제를 수정하는 시간이 훨씬 길어요.

이전에는 서버 코드를 직접 작성하는 시간이 큰 부담이었지만, 바이브코딩에서는 AI의 도움으로 초기 구현 시간을 줄일 수 있습니다. 처음 몇 시간을 줄이는 것보다 권한과 데이터 흐름을 이해할 수 있는 구조를 만드는 것이 더 중요할 수 있어요.

정리

• 브라우저에서 Supabase SDK를 사용하면 빠르게 시작할 수 있지만 RLS 정책을 잘 설계해야 합니다.
• 서버 접근 방식을 사용하면 브라우저가 데이터베이스를 직접 호출하지 않습니다.
• 서버에서는 로그인, 권한, 업무 규칙, 데이터 변경을 하나의 기능 흐름으로 관리할 수 있습니다.
• 바이브코딩으로 서버 코드의 초안을 빠르게 만들 수 있어 서버 구조를 선택하는 초기 부담도 줄었습니다.
• 결제, 예약, 관리자 기능처럼 복잡한 작업을 구현하고 문제를 추적하기도 쉬워집니다.
• 서버 접근이 보안을 자동으로 해결하지는 않으므로 서버에서 모든 권한을 확인해야 합니다.
• 단순한 프로토타입보다 계속 운영할 애플리케이션에서 서버 중심 구조의 장점이 커집니다.

Supabase SDK와 RLS는 빠르게 앱을 만드는 좋은 도구입니다. 하지만 여러 사용자가 이용하고 중요한 데이터를 다루는 앱이라면 편리함만으로 연결 방식을 정하기 어렵습니다.

브라우저가 데이터베이스를 직접 다루게 하기보다, 서버가 사용자의 요청을 확인하고 허용된 작업만 실행하게 만드는 구조가 장기적으로 이해하고 관리하기 쉽습니다.

서버 접근 방식을 선택한 뒤에도 데이터베이스 서비스로 Supabase를 사용할 이유는 서버에서 DB에 직접 연결해도 Supabase를 추천하는 이유에서 이어서 확인할 수 있습니다.

서버 접근 구조를 선택한 뒤 AI가 Prisma나 Drizzle을 설치했다면 ORM이 무엇이고 왜 필요한지에서 이어서 확인해보세요.