나의 구축 순서와 인증 설정

나의 구축 순서와 인증 설정 · 별도 원문

본문의 관련 교시에서 연결한 선택 심화다. 각 항목 끝의 교시 링크로 발표와 교재에 돌아갈 수 있다.

일차별 배치표 ↗

F01 · 나의 구축 순서

Codex에서 구현하고 GitHub에 기록한 뒤 DB·공개 앱·메일·SNS를 연결한다.

1. 0101 Codex

   요구·로컬 구현·검증

2. 0202 GitHub

   branch·commit·PR

3. 0303 Supabase

   DB·Auth·RLS

4. 0404 Vercel

   URL·환경·배포

5. 0505 Resend

   가입·복구 메일

6. 0606 SNS

   Google·Naver·Kakao

이 내용을 사용하는 교시

• D1-4 교재 · 발표로 돌아가기

F02 · Codex에서 GitHub까지

작은 요구를 구현하고 검토 가능한 기록으로 남긴다.

절차와 실습

1. 사용자·입력·처리·출력·완료 기준을 한 장으로 쓴다.
2. README·설계·기존 코드·실행 명령을 먼저 읽힌다.
3. 수업용 branch 또는 Worktree에서 한 기능씩 구현한다.
4. 관련 검사와 실제 동작을 확인하고 diff를 읽는다.
5. 비밀값 없는 변경만 commit하고 원격 branch와 PR을 연결한다.

현재 저장소의 문서와 구조를 먼저 읽고 미니 교육 포털의 구현 계획을 작성해줘. 목록·본인 신청·가입·로그인·복구·내보내기를 작은 작업으로 나눠줘. 각 작업의 변경 파일, 데이터와 권한, 검증 방법을 적어줘. 구현 후 diff와 실제 확인 범위를 남기고 다음 단계와 구분해줘.

이 내용을 사용하는 교시

• D2-1 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F03 · Supabase 프로젝트 기본 설정

PostgreSQL·Auth·Storage와 프로젝트의 키를 구분한다.

절차와 실습

1. 새 수업용 프로젝트와 지역을 선택하고 DB 비밀번호를 비밀 관리 위치에 보관한다.
2. 프로젝트 URL과 publishable key를 앱의 공개 설정에 넣는다.
3. programs·applications 관계와 입력 제약·인덱스를 만든다.
4. 노출할 테이블의 Data API 권한과 RLS를 함께 설정한다.
5. 방문자·계정 A·계정 B로 조회·수정·삭제 범위를 확인한다.

이 내용을 사용하는 교시

• D3-1 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F04 · Supabase 보안과 로그인 설정표

화면에 보이는 옵션과 서버·DB가 강제할 조건을 함께 정한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)
• D5-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F05 · 설정 이름과 보관 위치

모든 키를 Vercel에 복사할 필요는 없다.

이 내용을 사용하는 교시

• D1-4 교재 · 발표로 돌아가기
• D3-4 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F06 · Vercel 첫 연결과 환경 매핑

공개 URL과 서버 설정을 실제 배포에 연결한다.

절차와 실습

1. GitHub 저장소를 Import하고 모노레포라면 앱의 Root Directory를 지정한다.
2. 실제 framework·install·build·output 설정과 lockfile을 확인한다.
3. 수업용 클라우드 Supabase에 검토한 migration·RLS·가상 seed를 적용하고 로컬과 대조한다.
4. Production branch를 확인하고 기능 branch는 Preview로 검증한다.
5. Development·Preview·Production의 Supabase 연결 대상을 기록한다.
6. 환경변수 변경 뒤 새 배포에서 적용 여부를 확인한다.
7. 배포 commit·Ready·실제 URL의 동작을 따로 기록한다.

이 내용을 사용하는 교시

• D3-4 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F07 · Resend 도메인과 DNS 준비

발송 도메인 검증을 수업 전에 끝낸다.

절차와 실습

1. Resend에서 사용할 발신 도메인 또는 전용 하위 도메인을 등록한다.
2. Resend가 표시한 DNS의 이름·형식·값을 DNS 관리자에 정확히 추가한다.
3. DKIM과 SPF 관련 안내를 따르고 Verify 상태를 확인한다.
4. 기존 회사 메일의 MX·SPF를 임의 교체하지 않고 기존 레코드와 충돌을 검토한다.
5. 검증 도메인의 발신 주소와 이름, 수업용 키·환경별 용도를 정한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F08 · Supabase Auth에 Resend SMTP 연결

메일을 발행하는 Auth와 전달하는 Resend를 연결한다.

절차와 실습

1. Supabase Auth의 Email/SMTP 설정 화면에서 Custom SMTP를 켠다.
2. 위 항목을 입력하고 저장한다. 키를 자료·Git·로그에 남기지 않는다.
3. 가입·초대·복구 템플릿과 redirect 설정을 점검한다.
4. 허용된 테스트 주소로 실제 메일과 링크 동작을 확인한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F09 · Site URL·Redirect URL·메일 링크

주소 세 종류의 목적을 구분한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F10 · 가입·초대·로그인·비밀번호의 차이

사용자가 출발하는 인증 상태가 다르다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F11 · 비밀번호 재설정의 전체 흐름

요청 성공에서 멈추지 않고 새 비밀번호 로그인까지 확인한다.

1. 01복구 요청

   resetPasswordForEmail

2. 02메일 수신

   Resend·수신함

3. 03링크 검증

   템플릿과 맞는 교환

4. 04복구 세션

   검증된 사용자

5. 05새 비밀번호

   updateUser

6. 06재로그인

   변경 결과 확인

절차와 실습

1. 등록 여부를 드러내지 않는 동일한 요청 안내를 쓴다.
2. 메일 템플릿과 앱 callback이 사용하는 token_hash 검증 또는 PKCE 방식을 맞춘다.
3. 허용된 복귀 주소와 복구 세션을 확인한다.
4. 새 비밀번호·확인 입력과 Auth 비밀번호 정책을 적용한다.
5. 만료·재사용 링크와 새 로그인, 기존 세션 처리 정책을 시험한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F12 · 메일 실패를 찾는 다섯 지점

요청·처리·배달·링크·세션을 나누면 원인을 찾기 쉽다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F13 · uc-anchor의 Resend 구축에서 읽을 점

SMTP 자격 확인과 최종 사용자 검증을 구분한 기록이다.

• 2026-09-28 Preview Resend 보고서는 SMTP TLS 인증과 hosted Auth 설정 확인을 기록했다.
• 실제 회원 메일은 발송하지 않았으며 테스트 초대·복구 수신 확인을 다음 검증으로 남겼다.
• 후속 설계는 환경과 키를 분리하고 Production을 읽기 전용으로 취급했다.
• 수업에서도 설정·발송 처리·수신·링크·로그인을 별도 칸으로 기록한다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F14 · 현재 메일 정책에서 확인할 점

기본 메일과 Custom SMTP의 제공 범위를 구분한다.

• Supabase 기본 SMTP는 탐색용이며 일반 서비스 수신자에게 보낼 운영 발송 경로로 가정하지 않는다.
• 2026-06-03 이후 새 Free 프로젝트의 기본 SMTP 템플릿 편집 제한을 확인한다.
• Custom SMTP를 설정한 경우의 템플릿 기능과 발송 한도를 실제 계정에서 확인한다.
• 고정된 무료 발송량이나 모든 계정의 같은 한도를 강의자료에 약속하지 않는다.

이 내용을 사용하는 교시

• D3-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F15 · SNS 로그인 공통 왕복 구조

외부 계정 인증 뒤 Supabase 세션과 앱 가입 상태를 확인한다.

1. 01앱 로그인

   signInWithOAuth

2. 02외부 제공자

   본인 인증·정보 동의

3. 03Supabase callback

   외부 code·토큰 처리

4. 04앱 callback

   PKCE 세션 교환

5. 05앱 가입 조건

   이메일·동의·프로필

6. 06업무 기능

   서버 역할·RLS

이 내용을 사용하는 교시

• D4-1 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F16 · Google Cloud 로그인 연결

Google OAuth Client를 Supabase Google 제공자에 등록한다.

절차와 실습

1. Google Cloud에서 수업용 프로젝트와 Google Auth Platform을 연다.
2. Branding·지원 연락처·도메인·개인정보 URL, Audience와 Data Access 범위를 검토한다.
3. 웹 애플리케이션 OAuth Client를 만들고 Authorized redirect URI에 Supabase callback을 등록한다.
4. Supabase Google 제공자에 Client ID와 Secret을 보관한다.
5. 앱에서 Google OAuth와 허용된 앱 callback을 연결한다.
6. 계정의 대상 사용자·게시/검증 상태를 확인하고 최초 가입·취소·재로그인을 시험한다.

이 내용을 사용하는 교시

• D4-1 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F17 · Kakao Developers 로그인 연결

REST API 키와 카카오 로그인 설정을 Supabase에 맞춘다.

절차와 실습

1. 수업용 앱을 등록하고 웹 서비스 플랫폼·도메인 정보를 확인한다.
2. 카카오 로그인을 활성화하고 Redirect URI에 해당 Supabase callback을 등록한다.
3. 필요한 동의 항목과 제공 가능 여부를 확인한다.
4. REST API 키와 현재 Secret 설정을 Supabase Kakao provider의 해당 항목에 넣는다.
5. 앱 버튼을 연결하고 미완료 가입·이메일 누락·동의 취소를 처리한다.
6. 로그아웃·재로그인·기존 회원 연결과 역할 검증을 확인한다.

이 내용을 사용하는 교시

• D4-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F18 · Naver Developers와 Custom OAuth

u-livet은 custom:naver와 서버 userinfo 어댑터를 사용한다.

절차와 실습

1. Naver Developers에서 서비스 URL·callback·개인정보 URL과 테스트 계정을 준비한다.
2. Client ID·Secret과 Supabase Custom OAuth 제공자 항목을 맞춘다.
3. 서버 어댑터에서 Bearer 토큰으로 고정 네이버 userinfo를 확인한다.
4. 검증한 response.id를 sub로 바꾸고 필요한 필드만 반환한다.
5. 잘못된 토큰·이메일 누락·취소·재로그인과 가입 조건을 확인한다.

이 내용을 사용하는 교시

• D4-3 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F19 · 네이버 최초 가입과 이메일 확인

외부 identity를 유지하며 앱에서 요구할 이메일을 실제 확인한다.

• 네이버 응답에 확인 상태가 없으면 email_verified를 true로 만들지 않는다.
• u-livet 후속 구현은 이 provider만 email_optional=true로 가입 대기 OAuth 세션을 만들었다.
• 사용자가 앱에서 선택한 이메일을 별도 검증하고 동의·프로필 완료 후 회원 기능을 연다.
• 재로그인은 같은 네이버 identity에 연결하며 이메일 일치만으로 기존 역할을 복사하지 않는다.

// 합성 사용자 정보 변환 예시
{
  "sub": "synthetic-naver-user-001",
  "email": "learner@example.invalid",
  "email_verified": false
}

이 내용을 사용하는 교시

• D4-3 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F20 · MFA 등록과 보호된 작업

추가 인증 강도와 데이터 소유권을 동시에 검사한다.

절차와 실습

1. 서비스 이용자 계정의 TOTP factor를 등록한다.
2. QR 또는 수동 키를 본인 인증앱에 넣고 코드를 검증한다.
3. 다시 로그인해 challenge 또는 challengeAndVerify로 AAL2를 확인한다.
4. 본인 내보내기에서 서버와 DB가 AAL2·소유권을 함께 확인한다.
5. 틀린 코드·중복 요청·분실 안내와 안전한 내부 복귀 주소를 확인한다.

이 내용을 사용하는 교시

• D4-4 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)
• D5-1 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F21 · 계정 A/B와 인증 통합 점검

정상 결과와 실패 결과를 같은 표에 남긴다.

이 내용을 사용하는 교시

• D3-3 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)
• D5-2 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F22 · staging에서 main으로 전달할 기록

설정은 Git에 모두 들어 있지 않다.

• PR base/head, 검증 commit, 배포 commit·URL·환경을 연결한다.
• migration·RLS와 기존 코드 호환성을 확인한다.
• Vercel 환경변수, Supabase Auth·SMTP·Redirect, 공급자 callback을 별도 점검한다.
• Production Ready 뒤 실제 목록·저장·로그인·복구·SNS 핵심 흐름을 확인한다.

이 내용을 사용하는 교시

• D5-3 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)

F23 · 처음 구축한 뒤 남길 운영 안내

다음 사람이 실행·검증·복구할 수 있게 기록한다.

• 로컬 실행·의존성·빌드와 Git 작업 규칙.
• 환경별 URL·Supabase 대상·설정 이름과 담당자.
• 가입·초대·SNS·비밀번호·MFA의 실제 지원 범위.
• 메일 실패 확인 순서, 미완료 기능과 다음 개선.
• 정상 배포와 데이터 복구의 서로 다른 기준.

실제 확인한 결과만으로 운영 README를 작성해줘. Codex·GitHub·Supabase·Vercel·Resend·SNS 제공자별 역할, 환경별 설정 이름, 실행과 검증, 비밀번호와 MFA 안내, 장애 확인 순서를 넣어줘. 키·토큰·개인정보는 제외해줘. 코드 배포·DB·Auth/SMTP·외부 제공자 설정의 복구 범위와 미확인 항목을 명시해줘.

이 내용을 사용하는 교시

• D5-4 교재 (온라인 안내) · 발표로 돌아가기 (온라인 안내)