spaceship, github, supabase, render 개념차이

 

spaceship, github, supabase, render 계정변경이 다 필요하다는데 각각은 다 무엇?

쉽게 생각해서 하나의 '완성된 건물(웹사이트)'을 통째로 매입하기 위해 토지 문서, 건물 열쇠, 전기/수도 인프라, 가구 보관소를 각각 명의 변경하는 과정이라고 보시면 됩니다.

각 서비스가 무엇이고 왜 이전받아야 하는지 명쾌하게 정리해 드릴게요.

1. Spaceship (스페이스쉽)

• 역할: 도메인(Domain) 등록업체

• 비유: 건물의 '도로명 주소'

• 설명: www.yourwebsite.com 같은 웹사이트 주소 자체를 관리하는 곳입니다. (Namecheap이나 GoDaddy 같은 곳의 경쟁사입니다.)

• 왜 이전받아야 하나?: 도메인 소유권이 넘어와야 매달/매년 도메인 연장 결제를 내가 할 수 있고, 사용자들이 내 주소를 치고 들어왔을 때 엉뚱한 곳으로 연결되지 않도록 완전히 내 통제 하에 둘 수 있습니다.

2. GitHub (깃허브)

• 역할: 소스 코드 저장소 (Repository)

• 비유: 건물의 '설계도면 및 자재 이력서'

• 설명: 웹사이트를 이루고 있는 모든 파일, 디자인 코드, 기능 프로그램(HTML, CSS, JS 등)의 원본 데이터가 안전하게 저장되어 있는 공간입니다. 개발자들이 협업하고 버전을 관리할 때 씁니다.

• 왜 이전받아야 하나?: 나중에 사이트를 수정하거나 기능을 추가하려면 이 원본 코드가 반드시 필요합니다. 판매자의 깃허브 계정에서 내 깃허브 계정으로 이 저장소(Repository)의 소유권을 이전(Transfer)받아야 합니다.

3. Supabase (수파베이스)

• 역할: 데이터베이스 (Database, DB)

• 비유: 건물의 '금고 및 회원 명부 서랍장'

• 설명: 사이트에 가입한 회원 정보, 게시글 내용, 주문 내역 등 모든 텍스트 데이터가 실시간으로 쌓이는 저장소입니다.

• 왜 이전받아야 하나?: 이게 없으면 주소와 껍데기(코드)가 있어도 로그인이나 데이터 조회가 안 되는 빈 껍데기 사이트가 됩니다. 판매자 조직(Organization)에서 내 계정을 관리자로 지정한 후 판매자가 나가는 방식으로 이전을 진행합니다.

4. Render (렌더)

• 역할: 클라우드 웹 호스팅 서비스 (Hosting)

• 비조: 설계도면을 받아 실제로 건물을 짓고 유지해 주는 '시공사/관리소'

• 설명: 2번(GitHub)에 있는 설계도면(코드)을 가져와서, 인터넷 세상에 24시간 실제로 웹사이트가 돌아가도록 컴퓨터 서버를 대여하고 구동해 주는 곳입니다. (AWS나 Vercel 같은 서비스와 유사합니다.)

• 왜 이전받아야 하나?: 매달 발생하는 서버 비용을 이제 내 카드로 결제해야 하고, 서버가 다운되거나 재부팅이 필요할 때 직접 관리해야 하기 때문입니다.

💡 깔끔한 이전을 위한 팁 (순서)

이전을 진행하실 때는 아래 순서대로 판매자에게 요구하시면 꼬이지 않습니다.

1. 준비: 본인 명의로 GitHub, Supabase, Render, Spaceship 계정을 먼저 다 가입해 둡니다. (가급적 하나의 이메일로 통일하는 게 관리상 편합니다.)

2. 1단계 (코드&DB): 판매자에게 내 GitHub 아이디와 Supabase 이메일을 주고 소유권 이전(Transfer Ownership)을 해달라고 합니다.

3. 2단계 (호스팅): Render는 내 GitHub 계정과 연동되어 작동하는 경우가 많으므로, GitHub을 넘겨받은 뒤 Render 계정 설정을 내 쪽으로 이전하거나 재연동합니다.

4. 3단계 (도메인): Spaceship 계정 간 도메인 푸시(Push) 기능을 이용해 도메인을 내 계정으로 받습니다.

모두 이전받은 후에는 반드시 결제 수단(Billing)을 판매자의 카드에서 본인의 카드로 변경하는 것을 잊지 마세요!

깃허브와 수파베이스 역할 차이가 이해가 안되는데? 둘다 데이터 저장인데 차이점은?

충분히 헷갈리실 수 있습니다! 두 서비스 모두 개발자들 사이에서 '저장소'라는 표현을 쓰다 보니 처음 접하면 똑같아 보이죠.

하지만 저장하는 '데이터의 성격'과 '목적'이 완전히 다릅니다. 아주 쉽게 요약하면 다음과 같습니다.

• GitHub: 웹사이트를 만드는 ‘설계도(코드)’를 저장하고 기록하는 곳

• Supabase: 웹사이트가 돌아가면서 생기는 ‘사용자들의 활동 데이터’를 저장하는 곳

더 명확하게 이해하실 수 있도록 비유와 예시로 쪼개서 비교해 드릴게요.

1. 직관적인 비유로 보기

비교 항목	GitHub (깃허브)	Supabase (수파베이스)
현실 비유	건물의 설계도면 가방	건물의 내부 금고 & 서랍장
저장 대상	프로그래밍 소스 코드 (파일)	회원 명부, 주문 내역 등 텍스트 데이터
수정 주체	개발자 (사이트를 고치고 업데이트할 때)	웹사이트 이용자 (회원가입, 글쓰기 등 활동할 때)
데이터 예시	index.html, style.css, 로그인 기능 구현 코드	홍길동 / 비밀번호123 / 2026-05-26 가입

2. 실제 웹사이트(쇼핑몰)를 예로 든 차이점

만약 인수한 웹사이트가 '온라인 쇼핑몰'이라고 가정해 보겠습니다.

💻 GitHub에 들어있는 것

개발자가 쇼핑몰의 디자인을 바꾸거나 "여기에 환불 버튼을 만들어야지" 하고 코딩을 합니다.

• "로그인 버튼은 노란색으로 하고, 크기는 가로 100px로 해라"라는 명령어 파일(코드)이 깃허브에 저장됩니다.

• 즉, 사이트의 '뼈대와 기능의 규칙'을 저장하는 곳입니다.

🗄️ Supabase에 들어있는 것

사이트가 오픈된 후, 실제 고객들이 들어와서 활동한 결과물이 쌓입니다.

• 고객 A가 회원가입을 하면 아이디: user1 / 가입일: 오늘이라는 실제 정보가 수파베이스에 저장됩니다.

• 고객 A가 상품을 주문하면 주문번호: 55번 / 상품명: 나이키 신발 / 결제금액: 10만 원이라는 영수증 데이터가 수파베이스에 저장됩니다.

• 즉, 사이트가 살아 움직이면서 생기는 '콘텐츠와 사용자 정보'를 저장하는 곳입니다.

3. 인수자(대표님) 입장에서 왜 둘 다 따로 받아야 할까?

• GitHub을 안 받으면? 나중에 사이트 디자인을 바꾸고 싶거나 새로운 기능을 추가하고 싶을 때, 원본 설계도가 없어서 사이트를 아예 처음부터 다시 만들어야 할 수 있습니다. (개발자를 고용해도 코드가 없으면 손을 못 댑니다.)

• Supabase를 안 받으면? 사이트 주소와 디자인(껍데기)은 살아있는데, 기존 회원 정보와 매출 장부가 통째로 날아갑니다. 사용자가 로그인을 하려고 해도 "없는 회원입니다"라고 뜨게 됩니다.

💡 최종 요약 GitHub은 사이트를 '개발'하기 위한 파일 저장소이고, Supabase는 개발된 사이트가 '운영'되면서 손님들의 정보가 쌓이는 데이터베이스입니다. 따라서 온전한 인수를 위해서는 반드시 두 계정의 소유권을 모두 넘겨받으셔야 합니다!

뉴스사이트인데 그럼 뉴스 글 관리해주는건 어느쪽 플랫폼?

인수하신 사이트가 뉴스 사이트라면, 뉴스 글(기사 제목, 본문, 작성일, 작성자, 조회수 등)을 실시간으로 관리하고 저장하는 곳은 Supabase(수파베이스)입니다!

왜 그런지 뉴스 사이트의 메커니즘을 두 플랫폼의 역할과 함께 바로 이해시켜 드릴게요.

📰 뉴스 사이트에서의 역할 분담

1. Supabase (수파베이스) $\to$ 뉴스 기사 '내용' 저장소

기자나 관리자가 관리자 페이지에서 뉴스 글을 작성하고 '등록' 버튼을 누르면, 그 글은 데이터베이스인 Supabase로 들어갑니다.

• 저장되는 데이터: 기사 제목, 본문 텍스트, 작성자 이름, 작성 시간, 카테고리(정치/경제/연예 등), 댓글 내용, 조회수 등

• 특징: 실시간으로 글이 수정되거나 추가될 때마다 Supabase 안의 데이터 표(Table)에 한 줄 한 줄 새로운 장부가 기록되는 방식입니다.

2. GitHub (깃허브) $\to$ 뉴스 사이트 '틀(레이아웃)' 저장소

뉴스 기사가 수백, 수천 개가 되어도 기사들이 보여지는 '전체적인 디자인과 틀'은 똑같습니다. 이 틀을 만드는 코드가 GitHub에 있습니다.

• 저장되는 데이터: "상단에 로고를 배치해라", "메뉴 바는 파란색으로 해라", "뉴스 제목은 굵은 글씨로 보여줘라", "Supabase에서 오늘 날짜 기사를 가져와서 화면에 뿌려라" 같은 명령어(코드)들입니다.

• 특징: 기사가 새로 올라온다고 해서 깃허브의 코드가 바뀌지는 않습니다. 깃허브는 그저 기사를 예쁘게 보여줄 '그릇'만 정의해 둘 뿐입니다.

💡 한눈에 보는 작동 원리

사용자가 대표님의 뉴스 사이트에 접속해서 특정 기사를 클릭하면 다음과 같은 일이 일어납니다.

1. Render(서버)가 GitHub에 있는 설계도를 읽어서 뉴스 사이트의 외관(껍데기)을 만듭니다.

2. 그 설계도 안에 적힌 명령어에 따라, 서버가 Supabase에게 *"방금 사용자가 클릭한 123번 뉴스 기사 본문 좀 보내줘"*라고 요청합니다.

3. Supabase가 보관 중이던 기사 텍스트를 보내주면, 사이트 화면에 기사가 짠 하고 채워져서 사용자에게 보여집니다.

🛠️ 결론: 그럼 대표님은 글 관리를 어디서 하나요?

실제로 사이트를 운영하실 때는 Supabase에 직접 들어가서 글을 쓰실 필요는 없습니다. (그건 엑셀 화면 같은 날것의 데이터라 다루기 어렵습니다.)

아마 판매자가 만들어 둔 '뉴스 관리자 페이지(Admin Panel)'가 따로 있을 것입니다. 대표님은 그 관리자 페이지(웹사이트 형태)에 로그인하셔서 글을 쓰고 수정하시면 됩니다.

다만, 내가 관리자 페이지에서 쓴 글들이 최종적으로 저장되는 "종착지(데이터 창고)"가 Supabase이기 때문에, 계정 소유권을 반드시 넘겨받으셔야 하는 것입니다. 소유권을 안 받으면 판매자가 창고 문을 닫아버려 그동안 쌓인 기사가 전부 날아갈 수 있습니다.

뉴스관리자 페이지는 어디서 구동되는거?

뉴스 관리자 페이지(Admin Panel)가 어디서 구동되는지 이해하려면, 이 페이지 역시 일반 독자들이 보는 뉴스 사이트와 마찬가지로 하나의 '웹사이트'라는 점을 기억하시면 쉽습니다.

결론부터 말씀드리면, 뉴스 관리자 페이지는 Render(서버)에서 구동되고, 그 설계도는 GitHub에 있으며, 거기서 작성한 글은 Supabase로 저장됩니다.

이해하기 쉽게 구조를 쪼개서 설명해 드릴게요.

🏗️ 관리자 페이지의 구동 메커니즘

관리자 페이지가 돌아가는 방식은 크게 두 가지 유형이 있습니다. 인수한 사이트가 어떤 방식으로 만들어졌느냐에 따라 다르지만, 원리는 같습니다.

유형 1. 뉴스 사이트 내부에 숨겨져 있는 경우 (가장 흔함)

일반 독자들이 보는 뉴스 사이트 주소 뒤에 /admin이나 /dashboard 같은 주소를 붙여서 들어가는 방식입니다. (예: www.yournews.com/admin)

• 어디서 구동되나?: 일반 뉴스 사이트와 한 몸이기 때문에, 똑같이 Render(서버) 위에서 구동됩니다.

• 작동 원리: GitHub에 "만약 관리자 계정으로 로그인하면 글쓰기 화면을 보여주고, 일반 독자가 들어오면 기사 화면을 보여줘라"라는 설계도가 함께 들어있습니다.

유형 2. 아예 독립된 별도의 사이트로 분리된 경우

독자들이 보는 사이트와 주소 자체가 완전히 분리된 경우입니다. (예: admin.yournews.com 또는 완전히 다른 주소)

• 어디서 구동되나?: 이 경우 Render에 뉴스 사이트용 서버(1번)와 관리자 페이지용 서버(2번)가 각각 따로 개설되어 구동되고 있을 확률이 높습니다.

• 작동 원리: 설계도(GitHub)도 분리되어 있을 수 있지만, 결국 로그인해서 글을 쓰면 데이터는 똑같은 Supabase(데이터 창고)로 보내도록 연결되어 있습니다.

🔄 한눈에 보는 데이터 흐름 (대표님이 글을 쓸 때)

대표님이 컴퓨터를 켜고 관리자 페이지에 접속해서 글을 쓰는 순간, 인프라들은 다음과 같이 일꾼처럼 움직입니다.

1. Render (구동): 대표님이 브라우저에 관리자 주소를 치면, Render 서버가 관리자 페이지 화면을 띄워줍니다.

2. GitHub (기능 규칙): 대표님이 제목을 쓰고 본문을 채운 뒤 '발행' 버튼을 누르면, GitHub에 저장된 코드(설계도)가 *"이 버튼을 누르면 입력된 텍스트들을 안전하게 포장해서 Supabase로 보내라"*라는 명령을 실행합니다.

3. Supabase (최종 저장): 포장된 뉴스 글 데이터가 Supabase 창고에 탁 저장됩니다.

4. 독자 화면 반영: 그 순간, 일반 독자가 메인 페이지에 접속하면 Render 서버가 Supabase에서 방금 저장된 따끈따끈한 글을 가져와서 독자들에게 보여주게 됩니다.