프로젝트를 저장하고 공개하고 자동화하는 방법

먼저 세 단어를 구분합니다

쉬운 설명 — 안내서를 펴내는 일로 예를 들어 보겠습니다

안내서를 하나 만들어 계속 새 판을 낸다고 해 보겠습니다. 원고를 고치고 새 판을 내는 순서가 방법입니다. 내 컴퓨터에서 원고를 다루는 프로그램은 도구입니다. 계정을 만들어 원고와 사진을 맡기거나 웹에 공개하는 제품은 온라인 서비스입니다.

이 수업에서 방법은 일을 진행하는 순서를, 도구는 내 컴퓨터에서 실행하는 소프트웨어를, 온라인 서비스는 계정과 인터넷 연결로 사용하는 제품을 뜻합니다. Git은 도구이고 GitHub, Cloudflare, Vercel, Supabase와 Cloudinary는 온라인 서비스입니다.

제품부터 고르면 필요 없는 계정과 비용이 늘어납니다. 만들 결과를 먼저 정한 다음 지도에서 필요한 단계만 선택합니다.

전체 흐름을 눌러서 살펴봅니다

쉬운 설명 — 지도를 읽는 법

무엇을 펴낼지 정하기 전에 서버와 자료실부터 계약하면 쓰지도 않는 계정에 매달 돈이 나갑니다. 위 지도에서 원고를 정리하는 공통 단계를 먼저 확인한 다음 웹페이지를 공개할지, 정해진 조건에 맞춰 자동화를 실행할지 선택합니다.

상자를 누르면 그 항목의 자세한 설명으로 이동합니다.

공통

작업을 나누고 기록합니다

샌드박스AI가 접근할 범위 워크트리동시에 쓰는 별도 폴더 Git변경 기록 GitHub저장소 공유와 변경 검토

웹페이지

방문자가 주소로 엽니다

웹 배포코드를 실행 가능한 화면으로 만듭니다. 데이터글, 상품과 사용자 정보를 저장합니다. 이미지·영상큰 파일을 저장하고 전달합니다. 운영 확인공개 주소와 핵심 화면을 확인합니다.

자동화

조건이 맞으면 실행합니다

시작 조건시간, 새 파일, 새 주문과 같은 신호입니다. 실행 방법정해진 순서로 앱과 코드를 실행합니다. 기록과 알림성공과 실패를 기록하고 검토할 항목을 알립니다. 결과 확인실제 입력 한 건과 결과 한 건을 비교합니다.

Git과 GitHub

쉬운 설명 — 원고와 출판사 서버

원고를 고칠 때마다 파일을 덮어쓰면 이전 내용으로 돌아가기 어렵습니다. Git은 확인한 원고를 따로 저장하고 필요할 때 그 상태로 되돌리는 도구입니다. 변경 기록은 내 컴퓨터에 남습니다.

GitHub는 저장한 원고를 출판사 서버에 올려 두는 온라인 서비스입니다. 서버에 올리면 다른 사람이 같은 원고에서 바뀐 내용을 검토하고 의견을 남깁니다.

Git은 내 컴퓨터에서 파일의 변경 기록을 관리하는 도구입니다. GitHub는 Git 저장소를 인터넷에서 공유하고 검토하는 온라인 서비스입니다.

내 컴퓨터

2파일 수정웹페이지나 자동화 코드를 바꿉니다.

GitHub

4GitHub에 기록 저장다른 사람도 변경 기록을 봅니다.

GitHub에서 배포 서비스로배포main의 파일로 웹사이트를 만듭니다.

공개 웹

8운영 주소 확인방문자가 보는 화면을 직접 엽니다.

그림에 나온 단어의 정확한 뜻

브랜치: 변경 기록을 나눠 진행할 때 붙이는 이름입니다. main을 유지하면서 별도 브랜치에서 작업할 수 있습니다.
쉬운 설명
본 원고에 바로 새 문장을 쓰면 되돌리고 싶을 때 원래 문장이 남지 않습니다. 그래서 본 원고는 그대로 두고 사진 설명 손보기처럼 이름을 붙인 작업본을 하나 만들어 거기에만 씁니다.
이 작업본을 브랜치라고 하며, 만드는 데 드는 것은 이름 하나뿐입니다.
커밋: 확인한 변경을 하나의 기록으로 묶습니다. 커밋에는 변경 내용, 작성자, 시각과 설명이 남습니다.
쉬운 설명
확인한 수정 내용을 묶어 원고를 따로 저장하고 날짜와 이름과 한 줄 메모를 붙입니다.
이렇게 저장해 둔 원고가 커밋입니다. 아직 내 컴퓨터에만 있습니다.
푸시: 내 컴퓨터에 만든 커밋을 원격 저장소로 보냅니다. 커밋만 하고 푸시하지 않으면 GitHub에는 새 기록이 보이지 않습니다.
쉬운 설명
원고를 여러 번 저장해도 출판사 서버에는 이전 원고만 있습니다. 저장해 둔 원고를 서버로 올리는 동작이 푸시입니다.
푸시해야 다른 사람이 최신 원고를 확인합니다.
Pull Request: PR(Pull Request, 브랜치를 합치기 전에 검토를 요청하는 기능)은 작업 브랜치와 main의 차이를 함께 확인하는 방법입니다.
쉬운 설명
작업본을 본 원고에 바로 넣으면 손보다 만 문장까지 같이 들어갑니다. 넣기 전에 이 작업본을 본 원고에 넣어도 될지 봐 주세요라고 서버에 검토를 요청합니다. 이 요청을 Pull Request라고 하며 줄여서 PR이라고 부릅니다.
머지: 한 브랜치의 변경 기록을 다른 브랜치에 합칩니다. 검토를 마친 작업 브랜치를 main에 합칠 때 사용합니다.
쉬운 설명
검토가 끝난 작업본은 본 원고로 들어가야 다음 판에 실립니다. 작업본에서 수정한 내용을 본 원고에 반영하는 동작을 머지라고 하며, 같은 부분을 양쪽에서 고치지 않았다면 손으로 옮겨 적지 않아도 그대로 합쳐집니다.
main: 프로젝트가 기본으로 사용하는 브랜치 이름입니다. Git이 정해 놓은 완성본은 아니므로 팀이 기본 브랜치를 다르게 정할 수도 있습니다.
쉬운 설명
인쇄에 넘어가는 본 원고가 하나는 있어야 합니다. 그 원고에 보통 main이라는 이름을 붙입니다.
Git이 정해 준 완성본이 아니므로 팀이 다른 이름을 기본으로 쓰기도 합니다.
origin: 원격 저장소 주소에 붙이는 별명입니다. 흔히 GitHub 주소를 가리키지만 GitLab이나 다른 서버를 가리킬 수도 있습니다.
쉬운 설명
서버 주소를 매번 길게 적으면 오타가 납니다. 그래서 주소에 짧은 별명을 붙여 두고 그 별명으로 부르며, 이 별명이 보통 origin입니다.
서버를 GitHub가 아닌 다른 회사 것으로 빌려도 별명은 그대로 씁니다.
origin/main: 원격 main에서 마지막으로 받아 온 상태를 내 컴퓨터에서 가리킵니다. git fetch(GitHub의 최신 기록을 받아오는 명령)를 실행하기 전에는 GitHub의 최신 main과 다를 수 있습니다.
쉬운 설명
서버의 본 원고가 바뀌어도 내 컴퓨터에는 바로 나타나지 않습니다. 마지막으로 서버에서 내려받은 본 원고 사본을 origin/main이라고 부릅니다.
git fetch로 다시 내려받기 전까지는 서버의 실제 내용과 다를 수 있습니다.

내 컴퓨터에서 작업main내가 현재 보고 있는 기본 브랜치

푸시 →← fetch

GitHub에 있는 실제 저장소origin의 mainorigin은 이 주소에 붙인 별명

내 컴퓨터에 남은 원격 상태origin/main마지막 fetch 때 확인한 GitHub의 main

처음 저장할 때는 변경 → 확인 → 커밋 → 푸시로 진행합니다. 작업을 별도 브랜치로 나누었다면 그림처럼 브랜치 → 파일 수정 → 커밋 → 푸시 → 검토 요청 → 머지 → main → 배포 확인으로 이어집니다.

샌드박스

쉬운 설명 — 열어도 되는 서랍

보조 편집자에게 열쇠를 통째로 주면 손대지 말아야 할 서랍까지 열립니다. 샌드박스는 AI와 프로그램이 읽고 고칠 파일, 실행할 명령과 인터넷 연결 범위를 미리 정하는 규칙입니다.

Git이 수정 내용을 기록한다면 샌드박스는 수정 범위를 제한합니다.

샌드박스는 AI나 프로그램이 읽고 고치고 실행할 수 있는 범위를 정합니다. 프로젝트 폴더만 수정하도록 제한하거나 인터넷 사용 전에 승인을 받도록 설정하는 방식입니다. Git이 변경을 기록한다면 샌드박스는 변경할 수 있는 범위를 제한합니다.

워크트리

쉬운 설명 — 책상을 하나 더

긴 장을 쓰는 중에 급한 오타 신고가 들어오면 한 책상에서 두 원고를 펼치다가 종이가 섞입니다. 워크트리는 같은 원고를 보면서 책상을 하나 더 놓는 방법이라, 한쪽에서 긴 작업을 이어 가는 동안 다른 쪽에서 급한 수정을 끝낼 수 있습니다.

워크트리를 나눠도 파일 접근 권한은 그대로입니다. 접근 범위는 샌드박스에서 따로 정합니다.

워크트리는 같은 Git 저장소에 연결된 별도 작업 폴더입니다. 한 폴더에서 긴 기능을 만드는 동안 다른 폴더에서 급한 오류를 고칠 수 있으며, 보통 폴더마다 다른 브랜치를 사용합니다. 워크트리는 파일이 섞이는 문제를 줄이지만 접근 권한을 제한하지는 않으므로 샌드박스를 대신하지 않습니다.

워크트리

동시에 진행하는 작업의 파일과 브랜치를 나눕니다.

샌드박스

AI와 프로그램이 접근할 수 있는 파일, 명령과 인터넷 범위를 정합니다.

웹페이지 만들기

쉬운 설명 — 새 판을 찍어 내놓기

원고를 아무리 잘 써도 독자는 내 책상을 볼 수 없습니다. 웹 배포 서비스는 서버의 원고를 웹페이지로 만든 다음 공개 주소에 연결합니다. 주소를 아는 사람은 누구나 그 페이지를 봅니다.

실린 내용이 늘 같은 소개 페이지라면 여기까지로 끝납니다. 독자가 주문하거나 글을 남기면 아래에 나오는 별도 데이터 표가 더 필요합니다.

웹 제작은 GitHub의 코드를 배포 서비스가 읽어 브라우저에서 열 수 있는 파일로 만들고 공개 주소에 연결하는 흐름입니다. 글과 이미지가 고정된 소개 페이지라면 데이터베이스 없이 시작할 수 있습니다. 로그인, 주문, 글 등록처럼 내용이 계속 바뀌면 데이터 저장 기능을 더합니다.

코드 공유 서비스

쉬운 설명 — 코드 저장 서비스 고르기

팀이 이미 쓰는 업무 도구와 배포 서비스에 바로 연결되는지, 자체 서버 운영이 필요한지 확인한 뒤 고릅니다.

선택	잘 맞는 경우	확인할 점
GitHub	현재 프로젝트처럼 GitHub 기반 검토와 GitHub Actions를 함께 쓸 때	팀과 저장소 권한을 먼저 정합니다.
GitLab	저장소, Merge Request(브랜치 합치기 전 검토 요청)와 CI/CD(Continuous Integration/Continuous Delivery, 코드 검사·배포 자동 실행)를 한 제품에서 관리하거나 자체 서버 운영이 필요할 때	기존 배포 서비스가 GitLab과 직접 연결되는지 확인합니다.
Bitbucket	Jira와 같은 Atlassian 제품을 이미 쓰는 팀일 때	선택한 배포 서비스의 직접 연결 범위를 확인합니다.

웹 배포 서비스

쉬운 설명 — 웹 배포 서비스 고르기

사용하는 웹 제작 방식, 브랜치별 미리보기, 파일 저장 연결과 오류 확인 방법을 비교한 뒤 고릅니다.

선택	잘 맞는 경우	확인할 점
Cloudflare Workers Builds	Workers와 R2를 함께 쓰거나 여러 지역에서 실행되는 웹 기능이 필요할 때	지원하는 실행 방식과 Git 연결 범위를 확인합니다. 현재 studio.soluta가 사용합니다.
Vercel	브랜치별 미리보기와 웹 화면 배포를 빠르게 연결할 때	사용하는 웹 제작 방식과 서버 기능이 Vercel 환경에 맞는지 확인합니다. 기존 이미지 포트폴리오 실습이 사용합니다.
Netlify	Git 배포와 배포 미리보기, 파일을 직접 올리는 배포를 함께 검토할 때	빌드 방식과 서버 기능의 지원 범위를 확인합니다.

세 제품 모두 모든 프로젝트에 같은 답이 되지는 않습니다. 지금 쓰는 웹 프레임워크, 미리보기 방식, 파일 저장소와 팀이 오류를 확인할 화면을 함께 보고 고릅니다.

데이터와 파일

쉬운 설명 — 별도 데이터 표와 자료실

가격이 바뀔 때마다 웹페이지 파일을 고치고 다시 배포하면 관리하기 어렵습니다. 데이터베이스는 상품 이름, 가격, 주문 상태처럼 자주 바뀌고 찾아 고쳐야 하는 값을 칸에 맞춰 따로 저장하는 표입니다.

사진과 영상은 이 표에 넣기에는 크고 무거워서 자료실을 따로 빌립니다. 표에는 자료실의 어느 칸에 두었는지만 적습니다.

데이터베이스는 상품명, 가격, 주문 상태처럼 검색하고 수정할 정보를 저장합니다. 이미지와 영상은 크고 전달 방식이 달라 별도 파일 저장 기능을 쓰는 경우가 많습니다.

데이터 서비스

쉬운 설명 — 데이터 서비스 고르기

상품과 주문처럼 여러 표의 관계를 다룰지, 문서 형태 데이터를 빠르게 주고받을지 확인합니다. 로그인과 파일 저장을 같은 서비스에서 쓸지도 함께 봅니다.

선택	잘 맞는 경우	확인할 점
Supabase	표 사이의 관계가 중요하고 Postgres(표와 관계를 다루는 데이터베이스), 로그인과 파일 저장을 한 계정에서 연결할 때	RLS(Row Level Security, 행 단위 접근 규칙)를 직접 정하고 검사합니다.
Firebase Cloud Firestore	문서 형태 데이터와 실시간 갱신, 모바일 앱의 오프라인 사용이 중요할 때	관계형 표와 조인이 필요한 데이터인지 먼저 확인합니다.
Neon	서버를 직접 관리하지 않는 Postgres와 데이터베이스 브랜치가 필요할 때	로그인과 파일 저장은 별도 제품을 연결해야 합니다.

이미지·영상 파일 서비스

쉬운 설명 — 파일 저장 서비스 고르기

원본만 보관할지, 화면 크기에 맞춰 이미지 크기와 형식도 바꿀지 확인한 뒤 고릅니다.

선택	잘 맞는 경우	확인할 점
Cloudinary	이미지와 영상의 크기, 형식과 품질을 주소 옵션으로 바꾸고 관리할 때	원본 보관 정책과 변환 사용량을 확인합니다. 기존 이미지 포트폴리오 실습이 사용합니다.
Cloudflare R2	S3(Simple Storage Service, 인터넷 파일 저장 방식)와 호환되는 파일 저장을 Cloudflare 배포 흐름과 함께 쓸 때	이미지 변환과 자산 관리 화면이 추가로 필요한지 확인합니다. 현재 studio.soluta가 사용합니다.
Supabase Storage	Supabase 로그인과 접근 규칙으로 파일까지 관리할 때	전문 이미지·영상 변환 기능이 필요한지 확인합니다.

시스템 자동화하기

쉬운 설명 — 자동 실행

매달 1일에 개정판을 내는 일을 사람이 기억하면 언젠가 한 번은 잊습니다. 자동화는 시간이나 새 주문 같은 시작 신호를 정해 둡니다. 신호가 오면 앱과 코드가 정해진 순서대로 실행됩니다.

실행 결과와 실패 원인을 기록하면 다음 실행 전에 무엇을 고칠지 확인합니다. 환불과 금액 변경처럼 사람이 판단해야 하는 일은 검토 목록에 남깁니다.

자동화는 시작 조건 → 실행 단계 → 결과 저장 → 오류 기록 → 사람이 확인할 항목으로 설계합니다. 예를 들어 새 주문이 들어오면 고객 정보를 표에 기록하고 담당자에게 알리되, 환불이나 금액 변경은 사람이 확인하도록 남길 수 있습니다.

코드가 GitHub에 올라왔다는 신호로 검사와 배포를 실행한다면 GitHub Actions가 자연스럽습니다. 매일 같은 시각에 Cloudflare Worker를 실행한다면 Cloudflare Cron Triggers를 검토합니다. 여러 업무 앱을 화면에서 연결한다면 다음 온라인 서비스를 비교합니다.

자동화 서비스 고르기

쉬운 설명 — 자동화 서비스 고르기

연결할 앱과 한 달 실행 횟수, 코드를 직접 관리할 수 있는지 적은 뒤 서비스를 비교합니다.

선택	잘 맞는 경우	확인할 점
Zapier	시작 조건과 실행 한두 단계를 빠르게 연결하고 지원 앱 수를 우선할 때	실행 횟수, 여러 단계와 오류 처리에 필요한 요금제를 확인합니다.
Make	조건 분기와 여러 앱의 데이터 변환을 화면에서 보고 구성할 때	처리 단위와 재실행 방법을 확인합니다.
n8n	코드 실행을 넣고 서버를 직접 운영하면서 실행 방식을 세밀하게 관리할 때	자체 운영을 고르면 업데이트, 백업과 보안을 맡을 사람이 필요합니다.
GitHub Actions	코드 변경, 검사, 빌드와 배포를 GitHub 기록에 연결할 때	일반 업무 앱 자동화보다 저장소 작업에 맞습니다.
Cloudflare Cron Triggers	Cloudflare Worker를 정해진 시각에 실행할 때	실행 코드, 실패 기록과 재시도 정책을 직접 관리합니다.

온라인 서비스의 요금과 무료 한도는 바뀔 수 있습니다. 가입 직전에 공식 요금 화면에서 예상 실행 횟수, 파일 크기, 데이터 양과 팀 인원을 다시 확인합니다.

studio.soluta와 이미지 포트폴리오 실습

쉬운 설명 — 실제로 내는 판과 연습용 판

같은 안내서라도 독자에게 실제로 내는 판과 연습용으로 만들어 보는 판은 갖춰 놓는 것이 다릅니다. studio.soluta 공개 웹은 실린 내용이 정해져 있어 서버와 배포 서비스와 자료실만 쓰고 별도 데이터 표는 연결하지 않습니다.

이미지 포트폴리오 실습은 데이터와 이미지 저장 서비스를 각각 연결해 보려고 만든 연습용 판이라 네 가지를 모두 붙입니다.

studio.soluta 공개 웹

GitHub + Cloudflare + R2

GitHub의 main 변경은 Cloudflare가 배포하며 공개 파일은 R2에 저장합니다. 데이터베이스가 필요 없는 화면에는 Supabase를 붙이지 않습니다.

이미지 포트폴리오 실습

GitHub + Vercel + Supabase + Cloudinary

Vercel은 웹을 배포하고 Supabase는 프로젝트 정보를 저장하며 Cloudinary는 이미지를 저장합니다. 네 서비스의 연결을 연습하기 위한 예시입니다.

같은 수업에서도 결과와 운영 조건이 바뀌면 조합이 달라집니다. 현재 프로젝트의 조합은 확인된 운영 사례이며 실습 조합은 각 서비스의 역할을 나누어 배우는 예시입니다.

선택 순서

쉬운 설명 — 계정을 만들기 전에 정할 것

독자가 찾아와 읽는 웹페이지인지 조건에 맞춰 실행하는 자동화인지 먼저 정합니다. 데이터베이스와 파일 저장 기능이 필요한지 확인합니다. 매달 나갈 비용과 계정 권한을 누가 관리할지 정한 뒤에 계정을 만듭니다.

방문자가 열 웹페이지인지, 조건에 따라 실행할 자동화인지 정합니다.
고정된 내용만 보여 주는지, 계속 바뀌는 데이터를 저장할지 정합니다.
이미지와 영상에 크기·형식 변환이 필요한지 확인합니다.
팀이 이미 쓰는 코드 공유와 업무 앱을 확인합니다.
계정 권한, 비밀키, 백업과 오류 기록을 누가 관리할지 정합니다.
실제 예상 사용량으로 공식 요금과 한도를 다시 확인합니다.
공개 주소나 실행 기록에서 실제 입력과 결과를 확인합니다.

마지막 확인

쉬운 설명 — 배포가 끝났는지 확인하기

명령 성공, 빌드 통과와 배포 완료는 서로 다른 상태입니다. 독자가 여는 주소를 직접 열어 화면을 확인합니다. 자동화는 실제 입력 한 건이 결과 한 건으로 이어졌는지 확인합니다.

명령이 성공했다는 메시지, 빌드 통과와 공개 주소 생성은 서로 다른 증거입니다. 웹페이지는 운영 주소를 직접 열어 핵심 화면과 HTTP(Hypertext Transfer Protocol, 웹페이지를 주고받는 규칙) 응답을 확인합니다. 자동화는 실제 입력 한 건이 예상 결과 한 건으로 이어졌는지 확인하며 GitHub에서는 main의 최근 커밋과 반영된 파일을 봅니다.

이 수업을 마치면 내 프로젝트에 필요한 단계, 선택한 온라인 서비스, 선택 이유와 완료 증거를 워크북에 적고 카드 전체 보기에서 필요한 세부 수업을 이어서 확인합니다.

쉬운 설명 모아 보기

이름이 헷갈릴 때 이 표를 폅니다.

이름	없을 때 곤란한 일	원고와 출판에서는
커밋	무엇을 왜 바꿨는지 나중에 찾을 수 없습니다.	확인한 수정 내용을 묶어 원고를 따로 저장합니다.
푸시	내 책상의 원고만 최신이고 편집자는 모릅니다.	저장해 둔 원고를 출판사 서버로 올립니다.
브랜치	손보던 문장이 본 원고를 덮어씁니다.	본 원고는 두고 이름 붙인 작업본을 하나 만듭니다.
Pull Request	손보다 만 문장까지 본 원고에 들어갑니다.	넣기 전에 봐 달라고 검토를 답니다.
머지	검토가 끝난 수정 내용이 작업본에만 남습니다.	작업본에서 수정한 내용이 본 원고에 반영됩니다.
origin/main	서버의 최신 변경을 모른 채 작업합니다.	마지막으로 내려받은 본 원고 사본입니다.
샌드박스	보조가 손대지 말아야 할 서랍까지 엽니다.	열어도 되는 서랍과 명령을 미리 정합니다.
워크트리	한 책상에서 두 원고를 펼치다 섞입니다.	같은 원고를 보면서 책상을 하나 더 놓습니다.
웹 배포	독자가 내 책상을 볼 수 없습니다.	원고를 새 판으로 찍어 서점에 내놓습니다.
데이터베이스	값이 바뀔 때마다 웹페이지를 다시 배포해야 합니다.	자주 바뀌는 값을 별도 데이터 표에 둡니다.
파일 저장	사진과 영상이 커서 표에 들어가지 않습니다.	자료실에 두고 표에는 위치만 적습니다.
자동화	정해진 때의 일을 사람이 잊습니다.	신호가 오면 앱과 코드가 정해진 순서로 실행됩니다.