내 페이지에 목록 붙이기, 서버 안 짜도 되는 이유

지금까지 만든 소개 페이지, 내용이 코드 안에 적혀 있죠. 프로젝트 하나 추가하려면 코드 파일을 열고, 고치고, 다시 배포해야 해요. 매번 이러면 금방 지쳐요.

이번 편에서 이걸 바꿔요. 화면에서 직접 항목을 추가하고, 수정하고, 지울 수 있게요. 그러려면 데이터를 어딘가에 저장해야 하는데, 그 ‘어딘가’를 직접 만들 필요가 없어요. 저장은 서비스에 맡기고, 연결 코드는 AI가 써줘요.

한 가지 미리 알아둘 게 있어요. 이 편은 시리즈에서 손이 제일 많이 가는 구간이에요. 새 서비스(Supabase)를 처음 만지거든요. 30분쯤 넉넉히 잡고, 막히는 데가 나와도 정상이려니 하고 가면 돼요.

제 실무는 백엔드 쪽이라, 서버랑 데이터베이스를 직접 짜는 게 원래 제 일이에요. 그런데 혼자 뭘 빠르게 만들 땐 저도 이렇게 서비스에 맡기고 넘어가죠. 직접 짜는 것보다 이 편이 나은 순간이 분명히 있거든요.

이 편에서 얻는 것:

• 왜 ‘데이터 저장’이 필요한지 직관적으로 이해하기
• 서버·데이터베이스를 직접 짜지 않고 서비스로 해결하기
• 추가·조회·수정·삭제 네 동작(CRUD)으로 목록 관리하기

데이터로 하는 일은 네 가지뿐이에요

데이터로 하는 일은 딱 네 가지예요. 넣고, 꺼내 보고, 바꾸고, 버리고. 영어 앞글자를 따서 CRUD라고 불러요. 이 네 가지 말고 특별한 건 없어요.

비유하면 화면(우리가 지금껏 만든 index.html)은 가게, 데이터 저장소는 창고예요. 손님은 가게 화면에서 보고 요청하지만, 실제 물건은 창고에 있죠. Supabase가 그 창고 역할을 해요.

왜 백엔드를 직접 안 짜나

서버와 데이터베이스를 직접 만드는 건 생각보다 할 일이 많아요. 서버 코드에 DB 설치, 보안, 운영, 비용까지 챙길 게 줄줄이 붙거든요.

비전공자한테는 진입 장벽이 너무 높죠. 그래서 저라면 서비스를 빌려 써요.

Supabase는 데이터베이스·로그인·파일 저장 같은 백엔드 기능을 묶어 제공하는 오픈소스 서비스예요. Postgres라는 검증된 데이터베이스를 기반으로 하고, 무료로 시작할 수 있어요.

핵심만 짚으면 이래요.

• 테이블(데이터 표)을 클릭으로 만들어요. SQL 문법 몰라도 돼요.
• 테이블을 만들면 데이터를 주고받는 통로(API)가 자동으로 생겨요. 별도 서버 코드 없이 데이터를 읽고 쓸 수 있어요. API가 뭔지는 다음 편에서 따로 다뤄요.
• 로그인·소셜 인증도 내장돼 있어요.

무료 플랜으로 시작할 수 있고, 소규모 사이드 프로젝트엔 충분한 수준이에요. 구체적인 한도는 변동이 있으니 supabase.com/pricing에서 최신 내용을 확인하는 게 정확해요.

Supabase를 고른 이유

백엔드를 빌려주는 서비스가 Supabase만 있는 건 아니에요. Firebase, AWS Amplify 같은 선택지도 있죠. 그래도 입문엔 Supabase가 가장 편해요. 무료로 시작되고, 테이블을 엑셀처럼 클릭으로 만들고, SQL을 몰라도 되니까요. 처음엔 가장 빨리 ‘되는’ 걸 눈으로 보는 게 제일 중요해요.

익숙해지고 서비스가 커지면, 그때 옮겨가도 돼요. 직접 서버(Node·Nest 같은 프레임워크)를 짜거나, AWS로 인프라를 통제하는 쪽으로요. 데이터가 민감하거나 트래픽이 커지면 직접 손봐야 할 게 생기죠. 저도 실무에선 그쪽을 써요. 다만 그건 필요해졌을 때 고민하면 돼요. 지금은 이걸로 충분해요.

따라하기: Supabase로 목록 저장하기

예제 목표는 하나예요. 지금까지 만든 소개 페이지에 프로젝트 목록을 붙이는 것. 이름·설명·링크를 내가 직접 추가하고 화면에 표시하는 구조예요.

2단계에서 만든 projects 테이블은 이런 모양이에요. 엑셀 시트랑 똑같죠. 행 하나가 프로젝트 하나예요.

3단계에서 쓸 AI 프롬프트 (복붙용)

나는 index.html 한 파일짜리 정적 웹페이지를 만들고 있어.
(빌드 도구 없이, 파일을 브라우저에서 바로 여는 방식)
Supabase에 'projects' 테이블이 있고, 컬럼은 id, title, description, link야.

이 한 파일 안에 <script>로 넣을 수 있게, CDN 방식(@supabase/supabase-js)으로 써줘:
1. projects 목록을 불러와 카드로 표시하는 코드
2. 폼으로 title, description, link를 입력하면 새 항목을 추가하는 코드

URL과 키(publishable key)는 내가 코드에 직접 넣을 거야. 자리만 비워둬.

AI가 주는 코드는 대개 이런 모양이에요. 통째로 이해할 필요 없어요. 표시한 두 줄에 내 값만 갈아끼우면 돼요.

<!-- index.html 안, </body> 바로 앞에 붙여요 -->
<script src="https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2"></script>
<script>
  const db = supabase.createClient(
    "https://xxxx.supabase.co",   // ← 여기에 Project URL
    "여기에-키-붙여넣기"       // ← 여기에 publishable key
  );
  // 목록 불러오기·추가하는 코드는 AI가 이 아래를 채워줘요
</script>

맨 위 <script src=...> 한 줄이 ‘CDN’ 방식이에요. 따로 설치할 것 없이, 남이 인터넷에 올려둔 Supabase 코드를 링크로 딸려오게 하는 거죠.

두 값은 Supabase의 Settings → API Keys 화면에 있어요. Project URL과 publishable key(sb_publishable_…로 시작하는 키)를 복사해 위 두 자리에 붙여넣으면 돼요. 브라우저 코드에 넣어도 되는, 공개돼도 안전한 키예요(왜 안전한지는 Part 9에서). 예전 튜토리얼에서 anon key라 부르던 자리에 이 키를 넣으면 돼요. 값 형식은 다르지만 역할(공개 클라이언트 키)은 같거든요. 그래서 여기선 숨기지 않고 코드에 그냥 둬요.

그다음 Part 3에서 배운 방법대로 이 index.html을 다시 올리면, 바뀐 화면이 인터넷에도 반영돼요. 수정 → 저장 → 업로드, Part 4에서 익힌 그 흐름 그대로예요.

목록이 비어 있으면, 접근 규칙(RLS) 때문이에요

여기서 한 번쯤 막혀요. 연결은 됐는데 목록이 안 뜨거나 추가가 거부되는 경우요. 대개 접근 규칙 때문이에요.

Table Editor로 만든 표는 바깥에서 함부로 못 건드리게 두 겹으로 닫혀 있어요. 하나는 표에 기본으로 켜지는 보안 규칙(RLS), 또 하나는 요즘 새로 만든 Supabase 프로젝트가 표를 브라우저에서 부를 수 있게 여는 권한까지 기본으로 꺼두는 설정이에요. 그래서 규칙을 안 열면 화면이 비어 보여요.

입문 단계에선 ‘일단 읽고 쓰기 허용’ 규칙을 하나 깔고 시작하면 돼요. AI에게 이렇게 시키세요.

Supabase projects 테이블이 화면에서 안 떠(권한·RLS 때문).
지금은 입문 단계니까, 익명(anon)이 이 표를 읽고 쓸 수 있게
① 표를 anon·authenticated 역할에 GRANT하고
② 익명 접근을 허용하는 임시 정책(policy)까지
한 번에 만드는 SQL을 줘. Supabase의 SQL Editor에 붙여넣을 거야.

받은 SQL은 이렇게 실행해요. 왼쪽 메뉴에서 SQL Editor를 열고 → New query를 눌러 → 받은 SQL을 붙여넣고 → 오른쪽 아래 Run을 눌러요. 성공 메시지가 뜨면 페이지를 새로고침해 보세요. 이제 목록이 떠요.

지금은 일단 떠야 다음으로 가니까 넓게 열어둬요. 이 상태는 누구나 쓸 수 있는 임시 설정이라, 공개 배포 전에 좁혀야 해요. 그 방법은 Part 9 보안에서 다뤄요.

추가만이 아니라 수정·삭제까지

목록을 보여주는 것만으로는 반쪽이에요. 항목을 고치거나 지울 수 있어야 진짜 ‘관리’죠.

수정과 삭제도 AI에게 시키면 돼요. 아래처럼요.

위 projects 목록에 수정·삭제 기능을 추가해줘.
- 각 카드에 '수정' 버튼: 누르면 제목·설명·링크를 고칠 수 있게
- '삭제' 버튼: 누르면 해당 항목이 Supabase에서 삭제되게

추가 폼·수정·삭제까지 붙이면, 화면이 이렇게 돼요. 코드에 적어두던 목록이 이제 화면에서 관리돼요.

여기까지 오면 자연히 “나만 수정할 수 있어야 하는데” 싶어져요. 솔직히 ‘나만’을 제대로 하려면 로그인(Authentication)을 붙여야 하는데, 그건 이 입문 시리즈가 다루는 정적 페이지 범위를 넘어가요. 지금 만든 목록은 아직 열려 있는 상태라는 걸 기억해 두고, 공개 전에 어디까지 잠글 수 있는지는 Part 9에서 정리해요.

자주 묻는 질문

레스덕의 정리

코드를 많이 아는 게 실력이라고 생각하기 쉬워요. 그런데 막상 만들다 보면, 뭘 직접 짜고 뭘 빌릴지 가르는 눈이 더 중요해요.

데이터 저장은 빌리는 쪽이 정답에 가까워요. 직접 서버를 세우면 관리할 거리가 끝없이 따라붙거든요. 저도 PoC나 초기 단계엔 이런 서비스가 딱 맞더라고요. 비전공자라면 더더욱, 잘 만들어진 걸 빌려서 빨리 만들어 보는 게 먼저예요.

목록이 내 손에 들어왔죠. Part 7에선 날씨·지도·결제처럼 남이 만든 기능을 빌려다 붙여요. 내가 안 만들어도 되는 것들이요.