3기 2차 강의안 (2부) — 백엔드가 있는 랜딩페이지, 배포까지

진행 원칙

1. 여러분은 코드를 한 줄도 타이핑하지 않습니다. 모든 작업은 클로드 코드 CLI(Command Line Interface, 명령줄 도구)에게 말로 시킵니다.
2. 여러분이 직접 하는 일은 딱 두 가지 — ① 브라우저에서 로그인·승인 버튼 누르기 ② 토큰(token, 비밀 열쇠) 발급받아 클로드에게 건네주기.
3. 이 강의안의 복사 코드 블록은 그대로 복사해서 클로드 코드 CLI에 붙여넣으면 됩니다. [대괄호] 부분만 본인 것으로 바꾸세요.
4. 막히면 에러 메시지를 통째로 복사해서 클로드에게 붙여넣으세요. 그게 정답입니다.

가. 개발하기 — 도구의 스펙트럼 (5분)

"개발한다"는 것은 결국 어딘가에서 코드를 만들고 고치는 일. 그 "어딘가"의 선택지:

핵심: 도구는 여럿이지만 일하는 놈은 하나(클로드 코드 CLI). 나머지는 그에게 닿는 통로다.

나. git과 GitHub — 코드의 세이브 포인트와 클라우드 (10분)

• git = 내 컴퓨터 안의 게임 세이브 포인트. 코드의 모든 변경 기록을 남겨서, 언제든 과거 시점으로 되돌릴 수 있는 기록 장치. (2005년, 리눅스를 만든 리누스 토르발스가 개발 — 지금은 전 세계 개발의 표준)
• GitHub(깃허브) = 그 세이브 파일을 올려두는 클라우드 + 커뮤니티. git이 "내 컴퓨터 안의 기록 장치"라면, GitHub는 그 기록을 인터넷에 보관해주는 곳. 컴퓨터가 고장 나도 코드는 안전하고, 다른 서비스(Vercel 등)가 여기서 내 코드를 가져간다.
• 왜 필요한가 (옛날 방식의 악몽): git이 없던 시절엔 최종.zip, 진짜최종.zip, 진짜진짜최종_수정2.zip… 폴더 복사로 버전을 관리했다. 어디서 뭐가 바뀌었는지 아무도 모르고, 잘못 덮어쓰면 복구 불가. git은 이 문제를 "모든 변경의 역사를 자동 기록"으로 해결했다.
• 필수 개념 5개 (이것만 알면 됨):

• 클로드 코드 CLI와의 관계: 클로드는 git 명령을 전부 스스로 칠 줄 안다. 여러분은 "커밋해줘", "깃허브에 올려줘"라고 말만 하면 된다. (2교시에서 연결 실습)

다. 서버 · DB · 스토리지 필수 개념 (10분)

• 서버(server) = 그냥 24시간 켜져 있고 인터넷에 연결된 컴퓨터. "serve(시중들다)"라는 이름 그대로, 요청이 오면 응답을 차려주는 컴퓨터일 뿐, 신비한 물건이 아니다. 여러분의 노트북도 켜두고 인터넷에 연결하면 서버가 될 수 있다.
• 클라이언트(client) = 서버에게 요청하는 쪽. client는 원래 "의뢰인·손님"이라는 뜻 — 서버(시중드는 쪽)에게 "이 페이지 보여주세요", "이 문의 저장해주세요"라고 부탁하는 쪽이 클라이언트다. 방문자의 브라우저와 휴대폰이 바로 클라이언트. (변호사 사무실로 치면: 클라이언트 = 의뢰인, 서버 = 요청받아 일해주는 사무실)
  • 인터넷의 모든 대화는 이 한 문장이다: "클라이언트가 요청(request)하면, 서버가 응답(response)한다." 오늘 나오는 모든 것(페이지 열기, 문의 제출, 배포 확인)이 전부 이 요청↔응답의 반복이다.
• 프론트엔드(frontend) = 방문자의 브라우저(클라이언트)에 보이는 부분. 여러분의 랜딩페이지는 지금 프론트엔드만 있는 상태다.
• 백엔드(backend) = 서버 쪽에서 요청을 받아 일하고 데이터를 다루는 부분. 오늘 새로 붙일 부분.
• 🍽️ 식당 비유: 클라이언트 = 손님(주문하는 사람) / 서버 = 식당 건물 전체(홀·주방·냉장고가 다 들어 있고, 24시간 영업) / 프론트엔드 = 홀(손님이 보는 곳) / 백엔드 = 주방(요리가 만들어지는 곳) / DB = 냉장고 + 장부

• 데이터베이스(DB, Database) = 체계적으로 쌓이고, 검색되고, 다시 꺼내 쓸 수 있는 디지털 장부. DB가 없으면? 어제 받은 고객 문의가 메신저 스크롤 위로 사라지고, 같은 고객이 다시 연락해도 "처음 뵙겠습니다"가 된다.
• 관계형 데이터베이스(Relational Database, RDB) = 데이터를 엑셀 같은 표(table)로 저장하는 방식. 1970년에 나온 아이디어가 50년 넘게 세계를 지배 중.
  • 행(row) = 데이터 1건 (문의 1건)
  • 열(column) = 항목 (이름 / 연락처 / 문의 내용)
  • 표와 표를 연결(join)할 수도 있다 — "고객 표"와 "주문 표"를 이어서 "김○○ 고객의 모든 주문"을 한 번에 꺼내는 식.
• SQL(Structured Query Language, 구조화 질의 언어) = 이 표에서 데이터를 넣고 꺼낼 때 쓰는, 영어 문장처럼 읽히는 언어. 예: SELECT * FROM inquiries = "inquiries(문의) 표에서 전부 꺼내와". 오늘 여러분이 직접 쓸 일은 없다 — 클로드가 대신 쓴다. 다만 클로드가 화면에 이런 문장을 흘릴 때 "아, 장부에서 데이터 꺼내는 말이구나" 하고 알아보면 충분.
• 스토리지(storage, 저장소) = 표에 넣기 어려운 파일(사진·PDF·영상)을 넣는 창고. DB의 표에는 "그 파일이 창고 어디에 있다"는 위치표만 적는다. (장부에 사진을 풀로 붙이지 않고 "앨범 3권 12쪽"이라고 적는 것과 같다.)
• 창고는 두 종류가 있다 — 내 컴퓨터 안 vs 다른 곳(클라우드):

• 여러분은 이미 둘 다 쓰고 있다: 휴대폰 사진을 폰 안에 두는 것 = 로컬, 아이클라우드·구글 포토에 올려두는 것 = 클라우드.
• 오늘 우리가 만드는 사이트는 왜 클라우드 쪽인가: 방문자가 새벽에 접속해도 파일이 열려야 하는데, 내 컴퓨터(로컬)는 꺼져 있을 수 있다. 그래서 배포된 서비스의 파일 창고는 다른 곳(클라우드 스토리지)에 둔다 — 우리 실습에서는 Supabase가 DB(장부)와 함께 이 창고(Storage)까지 세트로 빌려준다.
• 그럼 내 컴퓨터로는 절대 안 되나? — 아니다, 이론적으로는 된다. 앞에서 본 대로 서버는 "24시간 켜져 있고 인터넷에 연결된 컴퓨터"일 뿐이므로, 내 컴퓨터를 항상 켜두고 인터넷에 연결해두면 내 컴퓨터가 곧 서버·창고가 될 수 있다. (실제로 클라우드 회사들의 데이터센터도 결국 "남의 컴퓨터를 잔뜩 켜둔 건물"이다.) 다만 그러려면 전기·인터넷이 한순간도 끊기면 안 되고, 고장·보안·백업을 전부 내가 책임져야 한다. 그 "항상 켜두고 관리하는 일"을 월 몇 천 원에 대신해주는 것이 클라우드라서, 오늘 우리는 빌리는 쪽을 선택하는 것뿐이다.

라. 배포 필수 개념 (8분)

• 배포(deploy) = 내 컴퓨터에만 있는 코드를 인터넷의 서버에 올려서, 전 세계 누구나 24시간 접속할 수 있게 만드는 일.
• 왜 "내 컴퓨터"로는 안 되나: 개발 중 보는 localhost:3000 같은 주소에서 localhost(로컬호스트)는 "내 컴퓨터 자신"을 가리키는 약속이다. 그래서 그 주소를 친구에게 보내도 친구 화면에는 안 뜬다 — 친구의 "localhost"는 친구 자신의 컴퓨터이기 때문. 남에게 보여주려면 반드시 배포가 필요하다.
• 옛날 방식 — FTP(File Transfer Protocol, 파일 전송 규약): 완성된 파일을 서버에 손으로 하나하나 업로드했다. 어떤 파일을 빠뜨렸는지 모르고, 실수하면 사이트가 그대로 죽고, 되돌리기도 어려웠다.
• 현대식 배포 (오늘 우리가 할 것):

코드 수정 → 커밋(세이브) → 푸시(GitHub에 업로드) → 자동 배포(Vercel이 감지해서 알아서 올림)

• CI/CD(Continuous Integration / Continuous Deployment, 지속적 통합 / 지속적 배포) = 푸시만 하면 점검·배포가 자동으로 이어지는 컨베이어 벨트. CI는 "새 코드가 문제없는지 자동 점검", CD는 "통과하면 자동으로 실제 서버에 반영". Vercel을 쓰면 이 벨트가 공짜로 딸려온다 — 3교시에 직접 체험.
• 도커(Docker) = 코드를 실행 환경째로 포장하는 컨테이너(container) 박스. "내 컴퓨터에선 되는데 서버에선 안 돼요" 문제를 없애려고, 코드와 그 코드가 도는 환경 전체를 하나의 박스로 포장해 어디서든 똑같이 돌게 만든 기술. 오늘은 쓰지 않지만 이름은 자주 만나게 된다.

마. 서비스 매칭 — 오늘의 등장인물 소개 (10분) ⭐

• 도메인과 DNS 개념 딱 하나만:
  • 인터넷의 모든 서버는 IP 주소(Internet Protocol address, 예: 76.76.21.21)라는 숫자 주소를 갖는다. 사람이 외우기 힘드니 내이름.com 같은 이름 = 도메인(domain)을 쓴다.
  • 이름 → 숫자 주소를 연결해주는 전 세계 전화번호부가 DNS(Domain Name System, 도메인 이름 체계)다.
  • "도메인 연결"이란 이 전화번호부에 "내이름.com으로 찾아오는 사람은 Vercel 서버로 보내시오"라고 한 줄 적는 일이다.
• CDN(Content Delivery Network, 콘텐츠 전송망) = 전 세계 곳곳에 사이트 복사본을 놓아두고 방문자에게 가장 가까운 곳에서 전달해 빠르게 만드는 망. Vercel·Cloudflare에 기본 포함 — 별도로 만질 일 없음.

🟠 클라우드플레어 조금 더 알기 — 오늘 직접 쓰지는 않지만, 여러분이 이미 가입했고 앞으로 반드시 다시 만나게 될 서비스라 조금 더 소개한다 (공식 문서 기준):

• 정체: 내 사이트 앞에 서는 경비실 겸 안내소다. 정식 용어로는 리버스 프록시(reverse proxy) — 방문자가 내 서버로 곧장 오는 게 아니라, 일단 클라우드플레어를 거쳐서 오게 만드는 구조. 전 세계 방문자와 내 서버 사이에 한 겹을 끼워 넣는 것이다.
• 앞에 세워두면 생기는 이득 4가지:
  1. 빨라진다 (CDN) — 전 세계 도시의 클라우드플레어 서버에 내 사이트 복사본(캐시)을 두고, 방문자에게 가장 가까운 곳에서 전달한다. 공식 문서의 예: 파리의 방문자가 로스앤젤레스 서버의 사이트를 열어도, 파리에 있는 복사본을 받아 훨씬 빠르다.
  2. 막아준다 (보안) — 내 진짜 서버의 IP 주소를 숨겨주고, DDoS(Distributed Denial of Service — 수많은 컴퓨터가 한꺼번에 몰려와 사이트를 마비시키는 공격)가 와도 경비실이 대신 맞아 걸러준다. 악성 로봇·해킹 시도도 문 앞에서 차단.
  3. 자물쇠를 달아준다 (HTTPS) — 통신 암호화 인증서를 무료로 자동 발급·관리해준다.
  4. 전화번호부를 맡아준다 (DNS) — 도메인의 DNS 레코드 관리가 빠르고 무료다. 그래서 실무에서 "도메인은 가비아에서 사고, 관리는 클라우드플레어로 옮기는" 조합을 아주 흔하게 쓴다.
• 쓰는 방법의 핵심 = 네임서버 이전: 가비아에서 산 도메인의 네임서버를 클라우드플레어 것으로 바꾸면, 그 순간부터 위 기능 전부가 내 도메인에 적용되기 시작한다. 도메인의 소유권은 그대로 가비아에 있고, 관리 사무소만 바뀌는 것이라 무섭게 생각할 필요 없다.
• 비용: 무료 플랜으로도 CDN·공격 방어·인증서가 모두 포함 — 개인·소규모 사이트에는 충분하다.
• 그럼 오늘은 왜 안 쓰나: 오늘 규모에서는 Vercel이 배포+CDN+인증서를 이미 다 해주기 때문. 클라우드플레어가 필요해지는 때는 — 사이트가 커져 보안·방문 통계·세밀한 DNS 관리가 필요할 때, 또는 Vercel이 아닌 곳(내 서버 등)에 배포할 때다. 그때도 클로드에게 "내 도메인 관리를 클라우드플레어로 옮기고 설정해줘"라고 말하면 된다.
• (참고) 강사 사이트 시연에 나오는 Turnstile(문의 폼의 스팸 로봇 차단 장치)도 클라우드플레어의 무료 서비스 중 하나다.

• 왜 Vercel이 메인인가: GitHub와 연결만 해두면 푸시할 때마다 자동 배포, 주소의 자물쇠(HTTPS, HyperText Transfer Protocol Secure — 암호화된 웹 통신)까지 자동. 무엇보다 클로드 코드 CLI가 터미널에서 전 과정을 직접 처리할 수 있어서, 여러분은 로그인 승인만 하면 된다.

바~사. 클로드 코드 CLI에 서비스 연결 + 배포까지 — 전체 흐름 예고 (3분)

오늘 2·3교시에 할 일을 한 장으로:

[2교시 — 연결]
클로드 코드 CLI ──① gh 로그인──→ GitHub
클로드 코드 CLI ──② vercel 로그인──→ Vercel
클로드 코드 CLI ──③ 토큰 전달──→ Supabase
가비아 ──④ 도메인 확인──→ (3교시에서 연결)

[3교시 — 배포]
내 랜딩페이지 + 문의폼(백엔드) → GitHub에 푸시 → Vercel 자동 배포
→ 가비아 도메인 연결 → 🎉 https://내이름.com 완성

아. 실제 사례 — 법알람조변 랜딩페이지의 연결 상태 (4분 시연)

🗣️ 안내 (10분) — 진행 패턴과 보안 규칙

Step 0. 준비 — 작업 폴더에서 클로드 실행 (실습 3분)

1차 과제로 만든 내 랜딩페이지 폴더에서 클로드 코드 CLI를 실행한다. (VS Code에서 폴더 열기 → 터미널 열기 → claude — 1차에서 배운 그대로)

실행했으면 첫 인사로 이것부터:

여기는 내가 만든 랜딩페이지 프로젝트 폴더야. 폴더 안의 파일들을 먼저 읽고, 이 랜딩페이지가 어떤 구조인지 나에게 아주 쉽게 3줄로 설명해줘. 나는 개발 지식이 거의 없어. 오늘 이 페이지에 백엔드 기능(문의 저장 또는 구글 로그인 중 하나)을 붙이고 인터넷에 배포할 예정이야.

Step 1. git + GitHub 연결 (실습 12분)

① 여러분이 준비할 것: GitHub 아이디·비밀번호 (이미 가입 완료 상태). 브라우저에서 github.com 에 로그인만 미리 해둔다.

② 클로드에게 — git 저장소 만들기:

이 폴더를 git 저장소로 만들고 첫 커밋까지 해줘. git이 설치 안 되어 있으면 설치부터 진행해줘. 각 단계마다 지금 무엇을 왜 하는지 한 줄씩 아주 쉽게 설명해줘.

②-보너스. 지난 시간에 이미 git에 올려본 분은 이걸로 (새로 만들지 말고 상태 점검부터):

이 폴더는 예전에 git 저장소로 만들어서 쓰던 곳이야. 처음부터 다시 만들지 말고, 지금 상태부터 점검해줘:
1. 이 폴더가 git 저장소가 맞는지, 마지막 커밋이 언제였는지 확인해줘.
2. 그 뒤에 수정했는데 아직 커밋 안 된 파일이 있으면, 무엇이 바뀌었는지 쉽게 설명해주고 커밋해줘.
3. GitHub 레포지토리와 이미 연결되어 있는지도 확인해서, 연결되어 있으면 알려주고, 연결이 안 되어 있거나 로그인이 풀려 있으면 그 부분만 이어서 진행해줘.
각 단계마다 지금 무엇을 왜 하는지 한 줄씩 아주 쉽게 설명해줘.

③ 클로드에게 — GitHub 로그인 (gh CLI):

GitHub CLI(gh)를 설치하고 로그인(gh auth login)을 진행해줘. 로그인 방식은 브라우저 인증으로 해줘. 내가 직접 해야 하는 일(브라우저에서 코드 입력, 승인 버튼 등)이 나오면 그때마다 멈추고, 무엇을 어떻게 눌러야 하는지 하나씩 알려줘.

③-보너스. 지난 시간에 이미 gh 설치·로그인을 해본 분은 이걸로 (다시 설치하지 말고 상태 확인부터):

GitHub CLI(gh)는 예전에 설치해서 로그인까지 해뒀던 것 같아. 다시 설치하지 말고 먼저 확인해줘:
1. gh가 설치되어 있는지, 어떤 계정으로 로그인되어 있는지 확인해서 알려줘.
2. 로그인이 살아 있으면 그대로 다음 단계로 넘어가면 된다고 알려줘.
3. 로그인이 풀려 있거나 문제가 있으면, 그 부분만 브라우저 인증 방식으로 다시 진행해줘. 내가 직접 해야 하는 일이 나오면 그때마다 멈추고 하나씩 알려줘.

④ 완료 확인:

GitHub 로그인이 잘 되었는지 확인하고, 이 랜딩페이지를 올릴 새 레포지토리를 GitHub 내 계정에 비공개(private)로 만들어서, 지금까지의 코드를 푸시해줘. 끝나면 내가 브라우저에서 확인할 수 있는 레포지토리 주소를 알려줘.

④-보너스. 지난 시간에 이미 레포지토리를 만들어 올려본 분은 이걸로 (새 레포지토리를 또 만들지 말 것):

이 프로젝트는 예전에 GitHub 레포지토리에 올려둔 적이 있어. 새 레포지토리를 만들지 말고 이렇게 진행해줘:
1. 이 폴더가 어느 레포지토리와 연결되어 있는지 확인해서 알려줘.
2. 지금까지의 변경사항을 그 레포지토리에 푸시해줘.
3. 끝나면 내가 브라우저에서 확인할 수 있는 레포지토리 주소를 알려줘.

→ 브라우저로 내 레포 주소에 접속해 내 코드가 GitHub에 올라간 것을 눈으로 확인 (첫 번째 작은 성공 🎉)

Step 2. Vercel 연결 (실습 8분)

① 여러분이 준비할 것: 없음. (Vercel 가입 완료 상태 — GitHub 연동 가입이므로 GitHub 로그인만 되어 있으면 됨)

② 클로드에게:

Vercel CLI를 설치하고 로그인(vercel login)을 진행해줘. 로그인 과정에서 브라우저 승인 등 내가 직접 해야 할 일이 생기면 그때마다 멈추고 알려줘. 로그인이 끝나면 정상 연결되었는지 확인해서 알려줘.

②-보너스. 과제 중에 이미 Vercel CLI를 설치·로그인해본 분은 이걸로 (다시 설치하지 말고 상태 확인부터):

Vercel CLI는 예전에 설치해서 로그인까지 해뒀던 것 같아. 다시 설치하지 말고 먼저 확인해줘:
1. Vercel CLI가 설치되어 있는지, 어떤 계정으로 로그인되어 있는지 확인해서 알려줘.
2. 로그인이 살아 있으면 그대로 다음 단계로 넘어가면 된다고 알려줘.
3. 로그인이 풀려 있거나 문제가 있으면, 그 부분만 다시 진행해줘. 브라우저 승인 등 내가 직접 해야 할 일이 생기면 그때마다 멈추고 알려줘.

Step 3. Supabase 연결 (실습 13분) — 오늘 유일하게 "토큰 발급"을 직접 해보는 곳

① 여러분이 브라우저에서 할 일 (강사가 화면으로 같이 진행):

1. https://supabase.com/dashboard 접속 → 로그인 (GitHub 연동)
2. 새 프로젝트 만들기: New project 클릭 → 프로젝트 이름(예: my-landing) 입력 → Database Password 설정 (⚠️ 자동 생성된 것을 복사해 안전한 곳에 보관 — 옵시디언 비공개 노트 등) → Region은 Northeast Asia (Seoul) 선택 → Create new project
3. Access Token 발급: 우상단 프로필 아이콘 → Account Settings → 왼쪽 메뉴 Access Tokens → Generate new token → 이름(예: claude-cli) 입력 → 생성된 토큰을 복사 (⚠️ 이 화면을 벗어나면 다시 볼 수 없음 — 지금 바로 다음 단계로)
   • 공식 문서: https://supabase.com/docs/reference/cli/supabase-login

② 클로드에게 — 토큰 건네주기 (이 토큰은 오늘 3교시까지 모든 실습을 마친 뒤 Supabase 화면에서 Revoke — 폐기 — 해도 됩니다. 필요할 때 새로 발급하면 그만):

Supabase CLI를 설치하고 로그인해줘. 내 Access Token은 이거야: [여기에 방금 복사한 토큰 붙여넣기]
이 토큰이 코드 파일이나 GitHub에 절대 올라가지 않도록 안전하게 보관해줘. 로그인이 되면 내 Supabase 프로젝트 목록을 보여줘.

③ 클로드에게 — 프로젝트 열쇠 2개 가져오기:

내 Supabase 프로젝트(my-landing)의 Project URL과 공개용 키(anon key — 새 프로젝트에서는 publishable key라는 이름일 수 있어)를 확인해서, 이 프로젝트 폴더의 .env 파일에 저장해줘. .env가 git에 올라가지 않도록 .gitignore 처리도 확인해줘. 그리고 URL과 anon key가 각각 무슨 역할인지 한 줄씩 쉽게 설명해줘.

Step 4. 가비아 — 도메인 상태 확인 (실습 4분)

① 여러분이 브라우저에서 할 일:

1. https://www.gabia.com 로그인 → 우상단 My가비아 → 서비스 관리 → 도메인 목록에서 내가 구입한 도메인이 보이는지 확인
2. 아직 도메인이 없는 분: 가비아 검색창에 원하는 도메인 입력 → 구매 (강의 중 5분 안에 완료 가능. .com 기준 연 2만 원 안팎, 가급적 영문)
3. 도메인 없이 진행해도 됨 — Vercel이 주는 무료 주소(프로젝트명.vercel.app)로 오늘 실습 전부 가능. 도메인 연결만 나중에 하면 된다.

② 클로드에게 (수업 흐름 유지용):

나는 가비아에서 [내도메인.com] 도메인을 가지고 있어. 다음 교시에 Vercel로 배포한 사이트에 이 도메인을 연결할 예정이야. 지금은 연결하지 말고, 이따가 무엇을 하게 될지 전체 순서만 3줄로 미리 설명해줘.

✅ 2교시 종료 체크리스트

• ☐ GitHub에 내 랜딩페이지 레포지토리가 올라가 있다 (브라우저로 확인됨)
• ☐ vercel login 완료
• ☐ Supabase 프로젝트 생성 + 클로드가 URL·anon key를 .env에 보관
• ☐ (해당자) 가비아에서 내 도메인 확인

🗣️ 안내 (10분) — 오늘의 완성 그림과 진행 리듬

• 이번 교시에는 1교시 "전체 흐름 예고" 그림의 오른쪽 절반(백엔드 추가 → 푸시 → 자동 배포 → 도메인 연결)을 완성합니다.
• Step 1은 선택제입니다: 🅰️ 문의 폼(기본 추천) vs 🅱️ 구글 가입·로그인 — 표를 보고 각자 하나를 고릅니다.
• 각 Step에서 무엇이 만들어지고, 어느 브라우저 화면에서 확인하는지: 🅰️ 문의 폼 → Supabase Table Editor / 🅱️ 구글 로그인 → Supabase Authentication Users / 배포 → *.vercel.app 주소 / 도메인 → 내 주소.

Step 1. 랜딩페이지에 백엔드 붙이기 — 둘 중 하나 선택 (실습 10분)

🅰️ 를 고른 분 — 문의 폼 + DB 저장

내 랜딩페이지에 "문의하기" 기능을 추가해줘. 요구사항:
1. 페이지 하단에 이름, 연락처, 문의 내용을 입력하는 폼을 만들어줘. 디자인은 지금 페이지 분위기에 맞춰줘.
2. 방문자가 제출하면 그 내용이 내 Supabase 데이터베이스에 저장되게 해줘. 필요한 테이블(inquiries)은 네가 직접 만들어줘.
3. 제출이 완료되면 "문의가 접수되었습니다"라는 안내가 뜨게 해줘.
4. 저장에는 .env에 보관한 Project URL과 anon key만 사용하고, 누구나 글을 쓸 수는 있지만 다른 사람의 문의 내용은 읽을 수 없도록 안전하게 설정해줘.
다 만들면 내 컴퓨터에서 미리보기로 확인하는 방법을 알려줘.

→ 클로드가 테이블 생성·폼 코드 작성·연결까지 진행. 로컬 미리보기(localhost — 내 컴퓨터 자신)에서 직접 문의를 하나 제출해본다.

🅰️ 확인 — DB에 진짜 쌓였나 (2가지 방법 모두 시연):

방금 내가 테스트로 제출한 문의가 Supabase 데이터베이스에 실제로 저장되었는지 확인해서, 저장된 내용을 표로 보여줘.

+ 브라우저: Supabase 대시보드 → 내 프로젝트 → Table Editor → inquiries 테이블 → 방금 데이터가 보인다 → "데이터베이스에 쌓인다"를 눈으로 확인하는 순간 🎉

🅱️ 를 고른 분 — 방문자의 구글 가입·로그인

② 클로드에게 먼저 (구글 쪽에서 받아올 열쇠가 무엇인지부터 안내받는다):

내 랜딩페이지에 방문자가 "구글 계정으로 로그인" 할 수 있는 기능을 추가하고 싶어. Supabase Auth의 구글 로그인을 사용해줘. 요구사항:
1. 페이지에 "구글로 로그인" 버튼을 만들고, 로그인하면 "○○님, 환영합니다"와 로그아웃 버튼이 보이게 해줘.
2. 이 기능에는 구글 클라우드 콘솔에서 발급받는 열쇠(클라이언트 ID와 클라이언트 보안 비밀번호)가 필요한 걸로 알아. 내가 구글과 Supabase의 어느 화면에서 무엇을 발급받고 어디에 붙여넣어야 하는지, 지금 단계별로 하나씩 안내해줘. 특히 Supabase가 알려주는 리디렉션 주소(콜백 URL)를 구글 쪽 어디에 넣는지 정확히 알려줘.
3. 코드 쪽 작업은 네가 전부 해줘. 나는 브라우저에서 발급·붙여넣기만 할게.
다 만들면 내 컴퓨터에서 미리보기로 확인하는 방법을 알려줘.

① 여러분이 브라우저에서 할 일 (클로드 안내에 따라 — 막히면 보조강사님을 바로 부르세요):

1. 구글 클라우드 콘솔: https://console.cloud.google.com → 새 프로젝트 만들기 → API 및 서비스 → OAuth 동의 화면 구성(앱 이름·본인 이메일 정도만) → 사용자 인증 정보 → 사용자 인증 정보 만들기 → OAuth 클라이언트 ID → 웹 애플리케이션 선택
2. "승인된 리디렉션 URI" 칸에 클로드(또는 Supabase 대시보드)가 알려준 콜백 주소(https://…supabase.co/auth/v1/callback 형태)를 붙여넣기 — 이것이 핵심. ("승인된 자바스크립트 원본"에는 내 사이트 주소를 넣어두면 좋지만, 비워도 로그인은 동작한다) → 만들기 → 클라이언트 ID / 클라이언트 보안 비밀번호 복사
3. Supabase 대시보드: 내 프로젝트 → Authentication → Sign In / Providers → Google 켜기 → 방금 복사한 클라이언트 ID·보안 비밀번호 붙여넣기 → 저장
   • 공식 문서: https://supabase.com/docs/guides/auth/social-login/auth-google

🅱️ 확인 — 회원 명부에 진짜 올라갔나: 로컬 미리보기에서 내 구글 계정으로 직접 로그인해본다. 그리고:

방금 내가 구글 계정으로 로그인했어. 내 Supabase의 회원 명부(Auth 사용자 목록)에 내 계정이 실제로 등록되었는지 확인해서 보여줘.

+ 브라우저: Supabase 대시보드 → Authentication → Users → 방금 로그인한 내 구글 계정이 보인다 → "내 사이트에 회원이 생겼다"를 눈으로 확인하는 순간 🎉

Step 2. GitHub에 올리기 (실습 4분)

지금까지 작업한 내용을 알기 쉬운 설명과 함께 커밋하고 GitHub에 푸시해줘. 단, .env 같은 비밀 정보가 절대 함께 올라가지 않는지 푸시 전에 다시 한 번 점검해줘.

Step 3. Vercel로 배포 (실습 10분)

이 프로젝트를 Vercel에 배포해줘. 진행 순서:
1. 이 폴더를 내 Vercel 계정의 새 프로젝트로 연결해줘.
2. .env에 있는 Supabase 관련 환경변수들을 Vercel 프로젝트 환경변수로도 등록해줘.
3. 이 Vercel 프로젝트를 내 GitHub 레포지토리와 연결해서(vercel git connect 또는 대시보드 연결), 앞으로 GitHub에 푸시하면 자동으로 배포되게 설정해줘.
4. 프로덕션 배포까지 진행하고, 완성된 사이트 주소(https://...vercel.app)를 알려줘.
중간에 선택지가 나오면 초보자에게 가장 무난한 기본값으로 진행하고, 내가 직접 해야 할 일이 생기면 멈추고 알려줘.

→ 배포 완료되면 각자 자기 *.vercel.app 주소를 휴대폰으로 접속 → 옆 사람과 주소 교환해서:

• 🅰️ 문의 폼: 서로의 사이트에 문의 남겨주기 → Supabase Table Editor에서 옆 사람이 남긴 문의가 실시간으로 쌓이는 것 확인 (오늘의 하이라이트 🎉🎉)
• 🅱️ 구글 로그인: 옆 사람이 자기 구글 계정으로 내 사이트에 로그인해보기 → Supabase Authentication → Users에서 옆 사람 계정이 내 회원 명부에 등록되는 것 확인 (오늘의 하이라이트 🎉🎉)

🅱️ 선택자 추가 확인 — 배포 주소에서 로그인이 이상하면 (로그인 후 localhost로 돌아오는 등):

배포된 실제 주소에서 구글 로그인을 하면 이상하게 동작해. Supabase의 사이트 URL과 리디렉션 허용 목록 설정을 배포 주소 기준으로 점검해서, 내가 대시보드에서 바꿔야 할 값이 있으면 정확히 알려줘.

+ 자동 배포(CI/CD) 체험 (시간 되면):

랜딩페이지 제목 문구를 [바꾸고 싶은 문구]로 수정하고, 커밋·푸시해줘. 푸시하면 Vercel이 자동으로 다시 배포하는지 배포 상태를 확인해서 알려줘.

→ 1~2분 뒤 사이트 새로고침 → 바뀌어 있음 → "이게 CI/CD(Continuous Integration/Continuous Deployment)입니다. 수정→푸시만 하면 배포는 자동."

Step 4. 내 도메인 연결 — 가비아 → Vercel (실습 12분)

② 클로드에게 먼저:

Vercel에 배포된 내 사이트에 내 도메인 [내도메인.com]을 연결하고 싶어. Vercel 쪽에 도메인을 추가하고, 가비아(도메인 등록대행 업체) 쪽에서 내가 직접 설정해야 하는 값을 화면에 정확히 표로 정리해서 보여줘. 나는 기존 설정을 건드리지 않도록 네임서버 변경이 아니라 DNS 레코드(A/CNAME) 추가 방식으로 진행하고 싶어. www가 붙은 주소도 함께 연결되게 해줘.

→ 클로드가 Vercel에 도메인을 추가하면, 가비아에서 설정해야 할 값을 알려준다. 방식은 두 가지 — 오늘은 레코드 방식이 기본이다:

• ⭐ DNS 레코드(record, 전화번호부의 한 줄) 추가 — 기본 권장: A 레코드(Address record — 도메인→IP 숫자 주소 연결)와 CNAME(Canonical Name — 도메인→다른 이름 연결) 값 몇 줄만 추가하면 되고, 기존 설정을 건드리지 않아 안전하다. (1교시 시연의 강사 사이트도 이 방식)
• 네임서버(name server, DNS 전화번호부의 관리 사무소) 변경: ns1.vercel-dns.com / ns2.vercel-dns.com — 더 간단해 보이지만, 이 도메인으로 이메일 등 다른 서비스를 이미 쓰고 있다면 그 연결이 끊길 수 있다. 오늘 새로 산 도메인일 때만 선택.

① 여러분이 가비아에서 할 일 (강사가 화면으로 같이 진행):

1. My가비아 → 서비스 관리 → 내 도메인 오른쪽 관리 버튼
2. DNS 관리툴(⭐ 레코드 방식 — 기본 권장) → 레코드 추가 → 클로드가 준 A/CNAME 값 입력 → 저장
   • 가비아 안내: https://customer.gabia.com/manual (도메인 → DNS 관리)
3. (네임서버 방식을 택한 경우에만: 네임서버 설정 메뉴 → 설정(변경) → 1차/2차 네임서버에 클로드가 알려준 값 입력 → 소유자 인증 → 적용)

③ 클로드에게 — 연결 확인:

방금 가비아에서 네임서버(또는 DNS 레코드) 설정을 마쳤어. 내 도메인 [내도메인.com]이 Vercel 사이트로 제대로 연결되는지 확인해줘. 아직이라면 DNS 전파라는 게 무엇이고 보통 얼마나 기다려야 하는지 쉽게 설명해줘. 연결이 확인되면 https 자물쇠(보안 인증서)까지 정상인지도 확인해줘.

Step 5. 이후의 운영 루틴 — "관리도 말로 한다" (실습 4분)

앞으로 사이트를 고치고 싶을 때의 전체 루틴은 단 한 문장:

랜딩페이지에서 [고치고 싶은 내용]을 수정하고, 커밋·푸시해서 실제 사이트에 반영까지 해줘. 반영이 끝나면 알려줘.

+ 쌓인 데이터를 보고 싶을 때 (🅰️ 문의 폼 선택자):

내 사이트에 지금까지 접수된 문의를 모두 조회해서 최신순 표로 보여주고, 눈에 띄는 특징이 있으면 한 줄로 요약해줘.

(🅱️ 구글 로그인 선택자):

내 사이트에 지금까지 가입한 회원(구글 로그인 사용자) 목록을 최신 가입순 표로 보여주고, 총 몇 명인지 알려줘.

✅ 3교시 종료 체크리스트

• ☐ 내 사이트가 *.vercel.app 주소로 인터넷에 떠 있다 (휴대폰으로 확인)
• ☐ 🅰️ 문의 폼 제출 → Supabase 테이블에 쌓이는 것 확인 / 🅱️ 구글 로그인 → Authentication Users에 계정 등록 확인 (선택한 것 하나)
• ☐ (시간이 되면) 수정→푸시→자동 재배포 1회 체험
• ☐ (해당자) 내 도메인으로 접속됨 (또는 DNS 전파 대기 중임을 이해)

가. 단순 AI vs AI 챗봇 vs AI 에이전트 (10분)

일상에서는 셋을 뭉뚱그려 "AI"라고 부르지만, 오늘 여러분이 하루 종일 부린 것이 정확히 무엇이었는지 여기서 갈라보자:

핵심 문장: 챗봇은 "말"만 하고, 에이전트는 "일"을 한다. 그 차이는 손발(도구)이 있느냐다. 오늘 여러분이 배포까지 해낸 것도, 클로드가 챗봇이 아니라 에이전트였기 때문.

나. 클로드 웹 · 앱 · CLI 구별 — 어디까지가 AI이고 에이전트인가 (7분)

• 같은 두뇌, 다른 몸: 셋 다 안에 들어 있는 AI(모델)는 같다. 다른 것은 그 AI에게 쥐여준 손발(도구)과 작업 공간.
• 클로드 웹(claude.ai) — 브라우저 속 챗봇 + 제한된 에이전트 (파일 업로드, 웹 검색, 문서 작성 등은 가능하지만 내 컴퓨터를 만질 수 없음)
• 클로드 앱(데스크탑/모바일) — 웹과 거의 같음 + 데스크탑 앱은 내 컴퓨터 일부 기능과 연결 가능
• 클로드 코드 CLI(터미널) — 내 컴퓨터 전체가 작업 공간인 완전한 에이전트. 파일 생성·수정, 프로그램 설치, 명령 실행, 인터넷 접속까지

다. 클로드 채팅 · 워크 · 코드 상호 비교 (7분)

두 쌍의 관계만 정리하면 헷갈리지 않는다:

① 워크 ↔ 코드 = 형제 사이 (공식 문서 기준)

• 공통점: 속은 같은 에이전트 엔진이다. 실제로 앤트로픽이 코드(Claude Code)를 먼저 만들었고, 그 엔진 위에 워크를 얹었다. 그래서 둘 다 "계획 세우기 → 여러 단계 실행 → 스스로 점검"이라는 같은 방식으로 일한다.
• 차이점: 누구를 위해, 어디서 일하느냐가 다르다.
  • 워크 = 개발자가 아닌 사람의 사무 작업용. 데스크탑 앱 안에서 설치·설정 없이 바로 쓰고, 인터넷과 격리된 안전한 별도 작업 공간(가상 컴퓨터) 안에서 파일을 다룬다. 폴더 하나를 맡기면 문서 정리·보고서·표 작성을 알아서 해준다.
  • 코드 = 개발·컴퓨터 작업용. 터미널·편집기에서, 내 컴퓨터 환경을 그대로 쓰며 일한다.
• 한 줄 비유: "같은 비서인데 — 워크는 사무실 책상에 앉힌 비서, 코드는 공구 벨트를 채워 현장에 내보낸 비서."

② 앱·웹의 코드 ↔ 클로드 코드 CLI = 같은 물건, 다른 문 (공식 문서 기준)

• 동일점: 둘 다 같은 Claude Code다. Claude Code는 CLI(터미널) · 데스크탑 앱 · 웹(claude.ai/code) · VS Code 같은 편집기 확장 — 여러 형태로 제공되는데, 문이 여러 개일 뿐 안에서 일하는 에이전트는 하나다.
• 차이점: 들어가는 문에 따라 작업장이 다르다 — 웹·앱의 코드는 준비된 환경에서 간편하게, CLI는 내 컴퓨터 그 자체에서.
• 그런데 같은 기능이면 왜 굳이 CLI를 쓰나? (이 강의가 CLI로 진행된 이유):
  1. 작업장이 내 컴퓨터 전체 — 내 폴더·내 파일·내 컴퓨터에 설치된 모든 프로그램을 직접 다룬다. 오늘 git·Vercel·Supabase 도구를 착착 설치해서 쓴 것도 CLI라서 가능했다.
  2. 확장이 내 마음대로 — MCP·스킬 같은 도구를 원하는 만큼 붙일 수 있다. (워크·웹 코드는 회사가 정해준 범위 안에서만.)
  3. 자동화의 부품이 된다 — 정해진 시간에 자동 실행시키거나, 다른 프로그램·봇과 연결하거나, SSH로 원격 조종하는 "부품"으로 끼워넣을 수 있는 것은 CLI뿐이다.
  4. 다른 모든 통로의 종착지 — 다음 라항에서 볼 앱 리모트 컨트롤도, 채널스 텔레그램 봇도, 결국은 내 컴퓨터에서 돌아가는 CLI에게 지시가 도착하는 구조다. CLI가 본체고 나머지는 리모컨이다.
• 한 줄 정리: "가볍게 쓸 땐 앱·웹의 코드로 충분하다. 하지만 내 컴퓨터를 본격적인 일터로 만들고 자동화까지 가려면 본체(CLI)를 쓴다."

라. 클로드 앱으로 원격 작업 — 리모트 컨트롤 · 디스패치 · 채널스 봇 구별 (8분)

전제 그림: 본체(내 컴퓨터의 클로드 코드)는 집에 있고, 나는 밖에 있다. 밖에서 본체를 부리는 공식 통로가 여러 개 있는데, 구별 기준은 딱 세 가지 — "하던 일을 이어가느냐 / 새 일을 시키느냐 / 내 컴퓨터가 켜져 있느냐."

공식 문서의 비교표를 쉽게 옮기면 (Claude Code 공식 문서 기준):

⭐ 공통점 겸 주의점: 위 셋(리모트·디스패치·채널스)은 전부 일하는 곳이 내 컴퓨터다 — 그래서 내 컴퓨터가 켜져 있어야 작동한다. 컴퓨터를 끄고도 시키고 싶으면 클라우드 세션(넷째 줄)뿐이다. 그리고 넷 다 결국 다항에서 본 대로 "본체는 하나, 리모컨이 여러 개"인 구조다.

🔍 심화 비교 — 리모트 컨트롤 vs 디스패치, 가장 헷갈리는 두 형제 (공식 문서 기준)

둘 다 "폰으로 내 컴퓨터의 클로드를 부린다"는 점이 같아서 제일 헷갈린다. 결정적 차이 하나만 기억하면 된다 — "세션(작업 대화)을 누가, 언제 만드느냐."

• 리모트 컨트롤 = 내가 나가기 전에 터미널에서 미리 켜둔 세션에, 폰·브라우저가 창(리모컨)으로 접속하는 것. 세션은 이미 존재하고, 폰 화면은 그 세션을 들여다보는 유리창일 뿐이다.
• 디스패치 = 미리 켜둔 세션이 없어도 된다. 폰에서 일을 문자 보내듯 던지면, 데스크탑 앱이 받아서 알아서 작업 세션을 만들어 처리한다. 클로드가 일의 종류까지 판단한다 — 문서·표 정리 같은 사무 일은 워크(Cowork)로, "버그 고쳐줘" 같은 개발 일은 코드 세션을 스스로 열어서 처리.

🧠 암기 비유: 리모트 컨트롤 = 집에서 틀어놓고 나온 방송을 밖에서 이어보는 것 / 디스패치 = 문자 한 통 보내면 집에 있는 일꾼이 알아서 움직이는 것.

각 통로 맛보기 — 복사해서 그대로 써보는 세트 (⏱️ 교시 내에는 ①만 함께 실습하고, ②~④는 시연으로 본 뒤 집에서 직접 해보세요):

① 리모트 컨트롤 — 지금 이 세션을 폰으로 이어가기. 먼저 터미널(클로드 코드 안)에서:

/remote-control

→ 대화에 세션 주소(URL)가 표시되고, 입력창 아래에 /rc active 표시가 켜진다. 폰에서 접속하는 방법은 3가지 (공식 문서 기준 — 아무거나 편한 것으로):

1. 가장 쉬움 (QR 필요 없음): 폰 클로드 앱 → Code 탭 → 세션 목록에 내 세션이 자동으로 떠 있다 (💻 컴퓨터 아이콘 + 초록 점) → 누르면 끝
2. 터미널에 표시된 세션 주소를 브라우저에서 열기
3. QR 코드로: /remote-control을 한 번 더 실행하면 세션 주소 + QR 코드가 있는 상태 패널이 열린다 → 폰 카메라로 스캔 (참고: claude remote-control 서버 모드에서는 스페이스바로 QR 표시/숨김)

💡 "요즘은 명령어 없이도 되던데?"의 정체: 클로드 코드에서 /config → Enable Remote Control for all sessions를 켜두면(데스크탑 앱은 Settings → Claude Code → Enable remote control by default), 모든 세션이 자동으로 원격 등록되어 명령어를 칠 필요조차 없다. 폰 앱 Code 탭에 항상 떠 있게 된다.

폰에서 세션에 들어갔으면:

지금까지 하던 랜딩페이지 작업을 폰에서 이어서 할게. 현재 상태를 3줄로 요약해주고, 사이트 하단에 "휴대폰에서 수정했습니다"라는 문구를 잠깐 넣었다가 확인 후 다시 빼줘. 끝나면 알림 보내줘.

(💡 "끝나면 알림 보내줘"라고 부탁하면 작업이 끝날 때 폰으로 푸시 알림이 온다 — 공식 기능. 단 미리 폰 클로드 앱에 로그인·알림 허용을 해두고, 클로드 코드에서 /config → Push when Claude decides를 켜두어야 한다)

② 디스패치 — 폰에서 새 일 던지기 (데스크탑 앱이 켜져 있어야 함). 폰 클로드 앱에서 새 작업으로:

내 컴퓨터의 랜딩페이지 프로젝트 폴더를 열어서, 지금까지 접수된 문의(또는 가입 회원)를 조회하고 "오늘의 현황.md" 파일로 알기 쉽게 정리해줘.

③ 채널스 — 1차에서 만든 텔레그램 봇에게 카톡 하듯:

랜딩페이지 사이트의 대표 문구를 "OOO에 오신 것을 환영합니다"로 바꾸고, 커밋·푸시해서 실제 사이트 반영까지 한 다음 결과를 알려줘.

④ 두 기능 비교 체험 — 같은 부탁을 두 방식으로 던져보면 차이가 몸으로 느껴진다:

🕹️ 리모트 컨트롤로 (미리 켜둔 세션에서 — 이미 맥락을 알고 있는 비서):

아까 하던 그 작업 이어서 — 방금 배포한 내 사이트 주소를 다시 알려주고, 방문자 입장에서 첫 화면 문구가 자연스러운지 검토해서 수정안을 제안해줘.

→ "아까 그 작업"이라고만 해도 알아듣는다. 세션이 이어지고 있기 때문.

📨 디스패치로 (새로 던지는 심부름 — 처음 듣는 일꾼이므로 대상부터 짚어줘야 함):

내 컴퓨터의 랜딩페이지 프로젝트 폴더(폴더 이름: [내 폴더명])를 열어서, 배포된 사이트 주소를 확인해 알려주고, 방문자 입장에서 첫 화면 문구가 자연스러운지 검토해서 수정안을 제안해줘.

→ 같은 부탁인데 폴더가 어디인지부터 알려줘야 한다. 미리 켜둔 세션이 없어도 되는 대신, 맥락은 내가 채워줘야 한다는 것 — 이것이 두 기능의 차이를 한 번에 보여준다.

구별 요령 (한 줄 암기):

• 하던 일 이어가기 → 리모트 컨트롤
• 새 일 맡기기 → 디스패치(클로드 앱으로) / 채널스(평소 메신저로)
• 컴퓨터가 꺼져 있는데도 시키고 싶다 → 클라우드 세션
• 화면 자체를 봐야 한다 (GUI — Graphical User Interface, 그림 화면) → 화면 공유 도구 (1차 과제에서 설정한 것)

마. 세션과 컨텍스트 — 컴팩트 · 서브에이전트 · 워크플로우 (10분)

• 세션(session) = 클로드와의 한 번의 작업 대화. / 컨텍스트(context, 맥락) = 클로드가 한 세션에서 기억하고 있는 대화·파일 내용의 총량. 책상 크기와 같아서 한계가 있다. (가항에서 본 대로, AI는 매번 대화 전체를 다시 읽기 때문에 이 책상은 말 한 마디마다 눈덩이처럼 차오른다.)
• 책상이 가득 차면? 세 가지 방법:
  1. 컴팩트(compact, 압축) — 책상 위 서류를 요약본 한 장으로 정리하고 계속 진행 (자동으로도 일어남)
  2. 서브에이전트(subagent, 부하 에이전트) — 큰 일 하나를 조수에게 통째로 맡기고 결과만 보고받기
  3. 워크플로우(workflow, 작업 흐름) — 여러 조수에게 동시에 일을 나눠주고 결과를 모으기

왜 서브에이전트·워크플로우가 내 책상(메인 세션의 컨텍스트)을 지켜주나?

• 핵심은 한 문장 — 조수의 책상은 따로 있다. 서브에이전트는 자기만의 별도 컨텍스트(자기 책상)를 새로 받아서 일한다. 조수가 서류 100장을 읽고 뒤지고 실험해도, 그 100장은 조수 책상 위에 쌓일 뿐이고, 내 책상(메인 세션)에는 "보고서 한 장"(최종 결과 요약)만 올라온다.
• 반대로 메인 세션에서 직접 하면? 클로드가 읽은 모든 파일 내용·중간 시도·실패 기록이 전부 내 책상에 쌓인다. 가항에서 배운 대로 그 뒤로는 말 한 마디 할 때마다 그 전부를 매번 다시 읽는다 — 책상이 금방 차고, 느려지고, 중요한 걸 흘리기 시작한다.
• 워크플로우는 여기서 한 걸음 더 — 조수 여러 명에게 작업 순서표까지 붙여서 동시에 실행하는 것이다 (예: "5명이 나눠 조사 → 조사 결과를 검증 담당이 검증 → 종합"). 조수들이 아무리 많이 읽어도 각자 자기 책상을 쓰고, 내 책상에는 최종 종합본 하나만 도착한다.
• 📌 비유 총정리: 컴팩트 = 내 책상 서류를 요약해 치우기 / 서브에이전트 = 조수 책상에서 일 시키기 / 워크플로우 = 조수 여러 명 + 작업 순서표.

🧪 직접 확인 실험 — 같은 일을 세 방식으로 시키고 책상 크기를 재본다 (강사 화면 시연 또는 각자 실습)

책상이 얼마나 찼는지 보는 계기판이 /context 명령이다. 각 단계 전후로 실행해서 숫자를 비교한다:

/context

실험 순서 — ① 방식(직접)이 책상을 가장 많이 채우므로, 순서대로 하고 단계마다 /context 숫자를 적어두면 차이가 한눈에 보인다:

(실험 주제는 아무거나 좋다 — 아래는 누구나 할 수 있는 "제주도 여행 계획" 예시. 폴더에 파일이 없어도 인터넷 검색만으로 가능하다.)

① 메인 세션에서 직접 (비교 기준 — 책상이 많이 찬다):

서브에이전트나 워크플로우를 쓰지 말고, 네가 이 세션에서 직접 인터넷 검색을 하면서 "제주도 2박 3일 가족여행"에 관해 다음 5가지를 모두 조사해서 정리해줘:
1. 항공권·렌터카 (대략적인 가격대와 예약 팁)
2. 숙소 (가족 여행에 좋은 지역과 형태)
3. 맛집 (현지인 추천 위주 5곳)
4. 관광 코스 (2박 3일 동선 예시)
5. 예상 총경비 (4인 가족 기준)

→ 끝나면 /context 실행 → 컨텍스트가 크게 늘어난 것 확인 (검색해서 읽은 페이지 내용이 전부 내 책상에 올라왔기 때문)

② 서브에이전트 5개를 동시에 (책상이 거의 안 찬다):

이번에는 같은 조사를 서브에이전트 5개를 동시에 띄워서 해줘. "제주도 2박 3일 가족여행"에 관해 각 서브에이전트가 하나씩 맡아 인터넷 검색으로 조사하게 하고, 너는 결과 보고만 받아서 종합해줘:
1. 항공권·렌터카
2. 숙소
3. 맛집 (현지인 추천 위주)
4. 관광 코스 (2박 3일 동선)
5. 예상 총경비 (4인 가족 기준)
각 서브에이전트의 결과를 5줄 이내로 요약해서 보고해줘.

→ 끝나면 /context 실행 → ①과 같은 양의 조사인데 내 책상은 조금만 늘어난 것 확인 (조수 5명이 각자 자기 책상에서 검색·읽기를 했고, 나에게는 요약 보고만 왔기 때문). 처리 속도도 5명이 동시에 일해서 더 빠르다.

③ 워크플로우로 (조수 + 작업 순서표):

워크플로우를 사용해서 "제주도 2박 3일 가족여행 계획"을 만들어줘. 순서는 이렇게:
1단계 — 에이전트 4개가 각각 (일정·동선 / 비용 / 맛집·숙소 후기 / 비 오는 날 대안 코스) 관점에서 병렬로 인터넷 조사
2단계 — 1단계 결과를 검증 에이전트가 재검증 (추천 장소가 지금도 영업 중인지, 가격 정보가 최신인지)
3단계 — 검증을 통과한 정보만 모아 하루 단위 일정표가 있는 최종 여행 계획서로 정리
최종 계획서만 나에게 보여줘.

→ 끝나면 /context 실행 → 4+1명의 조수가 조사·검증까지 했는데 내 책상에는 최종 계획서 하나만 도착한 것 확인. 특히 2단계(검증)처럼 조수의 결과를 다른 조수가 다시 확인하는 단계를 끼워 넣을 수 있는 것이 워크플로우의 힘이다.

• 오늘 실습으로 길어진 세션에서 /compact를 실행하면, 대화가 요약된 뒤 그대로 이어지는 모습을 시연으로 확인한다.

바. AI에게 맥락을 주고 요청하는 방법 (5분)

• 참고 글 붙여넣기 — 관련 문서·공지·예시를 그대로 붙여넣기 (가장 확실)
• 스크린샷 — 화면을 캡처해 터미널에 드래그앤드롭 ("이 화면에서 뭘 눌러야 해?" — 오늘 가비아 화면에서 써먹었던 그 방법)
• 옵시디언 노트 — "내 옵시디언의 ○○ 노트를 읽고 진행해줘" (1차에서 만든 기억장치 활용)
• 파일·폴더 지정 — "이 폴더의 코드를 먼저 파악하고 시작해줘" (오늘 Step 0에서 한 것)

사. AI가 맥락을 잃지 않게 하기 (3분)

• 작업 일지를 md 파일로 남기게 하기: "지금까지 한 일과 다음 할 일을 작업일지.md에 정리해줘" → 다음 세션에서 "작업일지.md 읽고 이어서 해줘"
• CLAUDE.md — "클로드에게 주는 상시 지침서." 클로드 코드를 켰을 때★ 자동으로 읽힌다 — 매번 말로 다시 시키지 않아도 되는 붙박이 메모. (★ 정확히 무엇을 "켰을 때"인지는 아래 표 바로 밑에서 설명)
  • 두 군데에 둘 수 있고, 역할이 다르다 (표 속 ★ 표시가 가리키는 곳):

• ★ 표의 "켰을 때"란 정확히 무엇을 켰을 때인가 (공식 문서 기준): 클로드 코드(Claude Code)의 새 세션이 시작될 때를 말한다. 터미널에서 claude를 실행할 때는 물론, 데스크탑 앱의 Code 탭, VS Code 확장에서 세션을 열 때도 똑같이 읽는다 — 전부 같은 클로드 코드이기 때문(다항의 "같은 물건, 다른 문"). 단, 클로드 웹 채팅(claude.ai의 일반 대화)은 클로드 코드가 아니므로 CLAUDE.md를 읽지 않는다.
• 어떻게 읽히나 (공식 문서 기준): 세션이 시작되면 전역 것을 먼저, 그다음 프로젝트 것을 이어붙여서 함께 읽는다 — 서로 덮어쓰는 게 아니라 합쳐져서 적용된다(공통 규칙 + 이 방 규칙). 프로젝트 지시가 나중에 읽히므로, 같은 주제가 겹치면 그 프로젝트 파일의 더 구체적인 지시 쪽으로 기운다 — "평소엔 이렇게, 이 프로젝트에서만 저렇게"가 자연스럽게 된다. (단, 두 파일에 서로 모순되는 지시를 적는 것은 피하자 — 어느 쪽을 따를지 흔들릴 수 있다.)
• 상황별로 정리하면 (둘 다 있으면? 하나만 있으면?):

• 즉 내가 "읽어줘"라고 시킬 필요가 전혀 없다 — 있는 만큼 알아서 다 읽는다. 그래서 자주 작업하는 프로젝트 폴더마다 프로젝트 CLAUDE.md를 만들어 두는 것이 이득이다(없어도 전역 규칙만으로 정상 작동).
• 알아두면 좋은 두 가지: ① 프로젝트 것은 하위 폴더에서 켜도 상위 폴더 것을 거슬러 올라가며 찾아 읽으므로, 프로젝트 안 어디서 켜든 적용된다. ② 지금 세션에 어떤 CLAUDE.md들이 읽혔는지 확인하려면 클로드 코드에서 /memory 명령을 치면 목록이 나온다.
• 만들 때도 클로드에게 시키면 된다:

내 전역 CLAUDE.md에는 "항상 한국어로 쉽게 설명해줘, 파일 삭제 전에 꼭 확인받아줘"를 넣어주고, 이 프로젝트 폴더의 CLAUDE.md에는 오늘 작업한 내용(어떤 사이트인지, GitHub·Vercel·Supabase 연결 상태, 배포 방법)을 정리해서 만들어줘. 각 파일이 어디에 생겼는지 알려줘.

• 핵심 습관: 긴 작업은 끊기 전에 기록시키고, 시작할 때 읽히기.

오늘 밤 집에 가기 전, 마지막으로 이것 하나만 클로드에게 시켜두면 완벽한 마무리:

오늘 이 프로젝트에서 한 일(GitHub 연결, Supabase 백엔드 기능 — 문의 저장 또는 구글 로그인, Vercel 배포, 도메인 연결)과 각 서비스의 역할, 그리고 앞으로 사이트를 수정할 때의 순서를 "작업일지.md" 파일로 아주 쉽게 정리해줘. 다음에 내가 "작업일지 읽고 이어서 하자"라고 하면 바로 이어갈 수 있게.

만능 구조 요청 (수업 중 언제든):

방금 뜬 에러야: [에러 메시지 전체 붙여넣기]
나는 개발 초보야. 이게 무슨 뜻인지 한 줄로 설명하고, 네가 직접 고쳐줘. 내가 해야 할 일이 있으면 하나씩 알려줘.

오늘 강의에서 비유로 스친 개념들이 어떤 흐름에서 나온 것인지를 네 영역으로 나눠 한 페이지에 정리했다. 외울 필요 없다 — "아, 이런 흐름이었구나" 정도로 한 번 읽어두면, 앞으로 클로드가 화면에 흘리는 용어들이 훨씬 덜 낯설어진다.

① 프론트엔드 — 웹은 어떻게 "보이는 화면"이 되었나 (핵심 4줄)

1. 웹은 1989년 "문서를 링크로 연결해 보자"에서 출발 — HTML(HyperText Markup Language, 문서 구조 언어) + URL(Uniform Resource Locator, 주소) + HTTP(HyperText Transfer Protocol, 문서를 주고받는 통신 규칙) 3형제가 뼈대.
2. 꾸밈은 CSS(Cascading Style Sheets, 스타일 정의 언어), 움직임은 자바스크립트(JavaScript)가 담당 — 구조/표현/동작의 3분업.
3. 페이지가 복잡해지자 React(리액트) 같은 도구가 등장 — 화면을 레고 블록(컴포넌트)처럼 조립하는 방식.
4. 여러분의 랜딩페이지가 바로 이 프론트엔드 — 방문자 브라우저에서 그려지는 모든 것.

② 백엔드 — 서버는 어떻게 "일하는 쪽"이 되었나 (핵심 4줄)

1. 초기 웹은 "미리 만든 문서를 그대로 주는 것"뿐 — 방명록처럼 사용자마다 다른 화면이 필요해지자, 요청받는 순간 화면을 만들어주는 백엔드가 탄생.
2. 2007년 아이폰 이후 백엔드의 역할이 "화면 제조"에서 "데이터 공급"으로 — 그 데이터 창구가 API(Application Programming Interface), 주고받는 데이터 형식이 JSON(JavaScript Object Notation).
3. 데이터를 다루는 기본 동작은 4가지 = CRUD (Create 생성 · Read 조회 · Update 수정 · Delete 삭제) — 오늘 문의 폼(🅰️)은 이 중 Create였다.
4. 서비스가 거대해지면 하나의 큰 덩어리(모놀리스, monolith)를 잘게 쪼갠 MSA(Microservices Architecture, 마이크로서비스 구조)로 진화 — 우리 규모에선 몰라도 되는 단어지만, 뉴스에서 만나면 "아, 쪼개기구나" 하면 됨.

③ DB·스토리지 — 데이터는 어디에 어떻게 쌓이게 되었나 (핵심 4줄)

1. DB가 없던 시절엔 파일로 관리 → 중복·불일치·검색 불가·동시 수정 충돌 4대 문제가 터짐.
2. 1970년 "데이터를 표로 저장하자"는 관계형 DB(Relational Database) 혁명 + 표를 다루는 언어 SQL(Structured Query Language)이 등장해 50년째 표준.
3. 사진·영상 같은 파일은 표에 안 맞으므로 별도의 스토리지(storage, 창고)에 — 클라우드 창고의 원조가 Amazon S3(Simple Storage Service).
4. Supabase(2020) = "DB(PostgreSQL 기반) + 스토리지 + 로그인 기능"을 클릭 몇 번에 빌려주는 서비스 — 오늘 우리가 장부로 쓴 것.

④ 배포 — 내 코드는 어떻게 세상으로 나가나 (핵심 5줄)

1. 서버 = 그냥 컴퓨터. 서버를 찾는 숫자 주소가 IP(Internet Protocol) 주소, 사람용 이름이 도메인(domain), 이름→숫자 연결 전화번호부가 DNS(Domain Name System).
2. 배포(deploy)의 역사는 "손 업로드(FTP, File Transfer Protocol)" → "git 기록 기반 자동 배포"로 진화 — 실수와 누락을 기계가 막아주는 방향.
3. git(2005) = 코드의 세이브 포인트, GitHub = 그 클라우드. 푸시가 배포의 출발 신호가 됨.
4. CI/CD(Continuous Integration/Continuous Deployment) = 푸시 후 점검·배포 자동 컨베이어 벨트, Docker = 환경째 포장하는 컨테이너 — 오늘 Vercel이 이 벨트를 공짜로 돌려줬다.
5. 주소창의 자물쇠 = HTTPS(HyperText Transfer Protocol Secure) — 통신을 암호화하는 인증서를 Vercel이 자동 발급해줬다.

(정렬: 한글 용어 가나다순 → 영어 용어 알파벳순)