만든 앱을,
믿고 나눌 수 있게.

5일차 · 내보내기부터 발표까지

1~4일차에 만든 과제 앱을 이어서 내보내기·권한 검사·최종 배포·발표까지 완주한다. 화면의 언어/프런트엔드·서버와 PostgreSQL DB 역할을 기존 프로젝트 사례와 비교하고 검증 가능한 결과를 남긴다.

전날 시작·CSV 완성·제출 양식 ZIP · 4일차 이어 보기

4교시×50분 실습과 휴식40분으로 하루4시간을 구성한다. 휴식은1교시후10분·2교시후10분·3교시후20분 예시다. 이론은 각 교시5~8분으로 줄이고 나머지는 구현·검증·발표에 쓴다.

1. 014일차 앱

   SNS·MFA·DB

2. 02CSV

   본인 전체 재조회

3. 03보안

   실제 API·실패

4. 04릴리스

   staging→main

5. 05발표

   근거·인수인계

강사 사전 준비

• 수업용 staging/production Supabase 두 환경과 Vercel Preview/Production을 준비한다. 무료 계정 한도·실습 제공 범위를 수업 전에 확인한다. 기존 운영 프로젝트는 재사용하지 않는다.
• staging 브랜치를 main에서 미리 생성·push하고 Production Branch=main, 두 환경의 DB·Auth 설정을 대조한다.
• 가상 A/B 계정·인증앱·발표용 과제와 실제 교실 스프레드시트의 UTF-8/텍스트 가져오기 방식을 리허설한다.
• 필요한 Google/Kakao/Naver 테스트 계정·동의·고정 어댑터·메일 발신을 미리 점검한다. 미완료는 미확인으로 남긴다.
• ZIP은 비교용 starter/solution이다. 기존 .git/.env.local을 보존하고 실제 값은 본인 로컬/서비스 설정에만 입력한다.

이번 일차의 관련 내용과 선택 심화

이 날의 생성도구·Git·구축 절차·프로젝트 사례를 각 교시에서 연결한다. 핵심은 아래에서 읽고 긴 원문은 선택 심화 링크로 연다.

D5-1 · 과제 앱 본인 과제 CSV 내보내기

이 교시 전체 교재 · 발표로 이동

D5-2 · 과제 앱 계정별 권한·보안 최종 검증

이 교시 전체 교재 · 발표로 이동

D5-3 · 과제 앱 staging→main 최종 배포

이 교시 전체 교재 · 발표로 이동

D5-4 · 과제 앱 3분 발표와 인수인계

이 교시 전체 교재 · 발표로 이동

Codex 예제 요청3종과 통합 검증

4일차 과제 체크 앱의 이메일/SNS 로그인, TOTP MFA, 소유자 RLS를 유지하고 CSV 내보내기를 추가해줘.
먼저 현재 파일·DB 정책·세션 전환 처리를 읽고 변경할 파일과 검증 기준을 제시해줘.
검색 화면의 배열 대신 로그인한 본인의 과제 전체를 DB에서 새로 조회해. getUser의 uid와 currentLevel=aal2를 확인하고 user_id 필터와 DB의 소유자 RLS AND restrictive AAL2를 모두 유지해.
500행씩 created_at,id 순으로 페이지 조회하고 exact count와 중복/누락을 검사해. 10,000행 초과·중간 오류·건수 변경은 부분 파일 없이 실패시켜. 동시 편집의 일관된 스냅샷을 보장한다고 설명하지 마.
열은 과제명/과목/마감일/완료만. UTF-8 BOM, CRLF, 모든 셀 큰따옴표, 내부 따옴표 두 번 처리. 수식 위험 시작문자(공백 뒤 = + - @와 전각 변형, 탭/개행)에는 quoted 셀 안에 탭을 앞붙여 스프레드시트 열람 위험을 줄이고 원본 DB는 바꾸지 마. 모든 앱/재저장에 안전하다거나 원본 복원 백업이라고 설명하지 마.
조회 중 progress와 aria-busy, 중복 실행 방지, 완료/오류 알림, Blob URL 해제를 구현해. 계정/토큰 변경·로그아웃은 AbortController와 epoch 확인으로 취소하고 늦은 A 응답을 B 화면에서 다운로드하지 않게 해.
빈 목록·한글·쉼표·따옴표·줄바꿈·수식 위험·1,000행 초과·중간 실패·계정 전환을 검증하고 npm run build 결과와 미확인 범위를 알려줘. 비밀값을 출력하거나 RLS/MFA를 끄지 마.

현재 과제 앱을 staging→main 최종 릴리스할 수 있도록 점검해줘.
git status, remotes, 브랜치, PR base/head와 배포 설정을 먼저 읽어줘. git staging area와 staging 브랜치를 구분해 설명해줘.
feature/csv-release→staging PR에서 검토하고 staging 브랜치는 Preview로 빌드해. 강사가 준비한 별도 수업 staging Supabase와 production Supabase에 같은 검토된 스키마·소유자 RLS·restrictive AAL2가 있는지 먼저 읽기 전용으로 확인해줘. 기존 운영 DB를 초기화하거나 임의 변경하지 마.
VITE_SUPABASE_URL과 VITE_SUPABASE_PUBLISHABLE_KEY의 Preview/Production 매핑, 실제 build commit·URL·DB 프로젝트 이름을 비밀값 없이 기록해. SNS callback/Redirect URL·SMTP·Naver 서버 어댑터도 환경별로 확인해줘.
검증표에 실패나 미확인이 남으면 완료로 표시하지 마. 통과 후 staging→main PR을 준비하고 main Production 재빌드 후 운영 URL에서 로그인/MFA/CRUD/CSV/계정 분리를 다시 확인해.
Preview 검증이 Production의 같은 환경 검증이라고 단정하지 마. 실패 시 이전 앱 배포 복원과 DB 복구가 다름을 설명하고 릴리스 기록 양식을 채워줘. 강제 push·보호 해제·비밀 커밋 없이 진행해줘.

완성한 과제 체크 앱의 3분 시연과 인수인계 자료를 만들어줘.
1일차 문제/사용자와 웹 선택→2일차 Git·개선→3일차 DB·Auth→4일차 SNS·MFA→5일차 CSV·검증·배포를 연결해줘.
0:00~0:30 문제/대상, 0:30~1:30 실제 과제 CRUD·검색·CSV, 1:30~2:15 A/B 권한 검증 근거와 MFA, 2:15~2:45 staging/Production URL·commit, 2:45~3:00 한계/다음 기능으로 구성해줘.
실제 확인한 결과와 모의/미확인을 구분하고 비밀키·토큰·TOTP QR/코드·학생 개인정보를 화면/문서에 넣지 마. 발표용 가상 계정을 사용하고 MFA는 청중에게 비밀을 보이지 않게 사전 완료해.
README에는 실행/환경변수 이름/SQL 적용 순서/CSV 열람 범위/테스트 방법/배포·복구·미확인 항목을 적어줘. 동료 피드백 1건을 이슈로 남길 수 있는 양식과 100점 평가표도 포함해줘.

내 과제 앱의 최종 검증을 실행 가능한 범위에서 진행하고 checks.csv에 근거를 남겨줘.
가상 A/B 계정, 익명, AAL1과 AAL2로 직접 Data API를 검사해. 본인 CRUD 허용, 타인 조회/수정/삭제의 0행 또는 거절과 원본 불변, user_id 위조 추가/변경 거절을 확인해. UI가 숨겨졌다는 이유로 권한 검사를 통과시키지 마.
CSV가 본인 전체 DB 과제만 새 조회하는지, 검색 결과와 무관한지, 한글/인용/CRLF/위험 입력/빈 목록/1,203행을 처리하는지 검사해. AAL1 내보내기 거절, 페이지 실패와 계정 전환에서 다운로드 0회를 확인해.
비밀은 값 대신 존재 여부와 변수 이름만 보고해. git diff --cached, .gitignore, 번들에 secret/service_role/SMTP/OAuth secret이 없는지 점검해. publishable key는 공개 식별값이며 RLS를 대신하지 않음을 명시해.
빌드·PR·배포상태와 실제 URL 기능 검사를 분리해. 로컬 통과, 모의 통과, staging 실제, Production 실제, 미실행을 구분해 결과/시각/commit/검증자를 기록해. 실패·미확인 항목이 남으면 출시 완료라고 쓰지 마.

E01 · 전날 앱 복원과 두 환경 준비

4일차 완성 앱이 있는 본인 clone 폴더를 연다. ZIP의 starter는 비교용이며 기존 .git과 .env.local을 덮어쓰지 않는다. 강사는 staging 브랜치와 수업용 staging/production Supabase 두 환경을 사전 준비한다. 학생은 main의 최신 이력에서 feature/csv-release를 만들고 로컬 가입·로그인·MFA·과제 CRUD부터 확인한다.

본인 저장소에서 한 줄씩 실행

git status -sb
git fetch origin
git switch main
git pull --ff-only
git switch -c feature/csv-release
npm ci
npm run dev

학생 확인

미커밋 변경을 먼저 정리하고 잘못된 저장소에서 실행하지 않는다. 환경표에 URL·브랜치·DB 이름만 적는다. 두 환경은 같은 DB를 가리키지 않는다.

E02 · 본인 전체 과제를 CSV로 내보내기

요청1을 Codex에 입력하고 변경 파일을 검토한다. solution의 csv-export.js·task-store.js·main.js·HTML/CSS와 비교한다. 추가 인증 후 내 과제 CSV 내보내기를 누른다. 검색 결과가 1건이어도 본인 전체 DB 과제가 들어가는지 확인한다. 내려받은 파일은 스프레드시트에서 텍스트로 가져오고 한글·열 이름·완료 상태를 확인한다.

4일차 과제 체크 앱의 이메일/SNS 로그인, TOTP MFA, 소유자 RLS를 유지하고 CSV 내보내기를 추가해줘.
먼저 현재 파일·DB 정책·세션 전환 처리를 읽고 변경할 파일과 검증 기준을 제시해줘.
검색 화면의 배열 대신 로그인한 본인의 과제 전체를 DB에서 새로 조회해. getUser의 uid와 currentLevel=aal2를 확인하고 user_id 필터와 DB의 소유자 RLS AND restrictive AAL2를 모두 유지해.
500행씩 created_at,id 순으로 페이지 조회하고 exact count와 중복/누락을 검사해. 10,000행 초과·중간 오류·건수 변경은 부분 파일 없이 실패시켜. 동시 편집의 일관된 스냅샷을 보장한다고 설명하지 마.
열은 과제명/과목/마감일/완료만. UTF-8 BOM, CRLF, 모든 셀 큰따옴표, 내부 따옴표 두 번 처리. 수식 위험 시작문자(공백 뒤 = + - @와 전각 변형, 탭/개행)에는 quoted 셀 안에 탭을 앞붙여 스프레드시트 열람 위험을 줄이고 원본 DB는 바꾸지 마. 모든 앱/재저장에 안전하다거나 원본 복원 백업이라고 설명하지 마.
조회 중 progress와 aria-busy, 중복 실행 방지, 완료/오류 알림, Blob URL 해제를 구현해. 계정/토큰 변경·로그아웃은 AbortController와 epoch 확인으로 취소하고 늦은 A 응답을 B 화면에서 다운로드하지 않게 해.
빈 목록·한글·쉼표·따옴표·줄바꿈·수식 위험·1,000행 초과·중간 실패·계정 전환을 검증하고 npm run build 결과와 미확인 범위를 알려줘. 비밀값을 출력하거나 RLS/MFA를 끄지 마.

학생 확인

한글·쉼표·큰따옴표·줄바꿈·=1+2·전각＝1+2와 빈 목록을 검사한다. 위험한 자유 입력 앞의 탭은 열람용 변환이며 DB 원본은 유지된다. 토큰·이메일·uid가 CSV에 없다.

E03 · A/B·익명·인증 강도별 권한 검사

가상 A/B 계정을 서로 다른 브라우저 프로필에서 사용한다. 두 계정 모두 TOTP를 준비하고 본인 과제를 하나씩 만든다. A의 id를 검사에만 사용해 B의 실제 Data API로 조회·수정·삭제·user_id 위조를 시도한다. 로그아웃 뒤 재로그인한 AAL1과 추가 인증 후 AAL2를 비교한다. 아래 개발 서버 전용 검사 예시와 checks.csv에 실제 결과를 적는다.

학생 확인

AAL2는 관리자 권한이 아니다. B의 A행 조회/수정/삭제는0행 또는 거절이며 A원본 불변. 익명은 거절. AAL1은 본인 조회0행·쓰기거절/0행이며 내보내기 불가. 소유권 위조 추가/변경은 거절.

E04 · 페이지 실패·계정 전환·비밀 노출 점검

네트워크 차단 또는 모의 테스트로 CSV 조회 중간 실패를 재현한다. 다운로드가 한 번도 발생하지 않아야 한다. 조회 중 로그아웃/다른 계정으로 전환했을 때 이전 계정 파일이 생성되지 않는지도 검사한다. 로컬 가상 데이터1,203건으로 페이지 조회를 확인한다. .gitignore·git diff·빌드 산출물을 검사하고 실패/미확인 사유를 남긴다.

본인 저장소에서 한 줄씩 실행

npm run build
git status --short
git diff --check
git diff -- src index.html styles.css
git ls-files .env.local .env.production

학생 확인

부분 CSV·이전 계정 CSV·중복 다운로드0회. 예제 상한10,000건을 넘으면 명시 오류. 위 git ls-files 결과는 비어야 한다. 공개 URL/key 외 secret·service_role·SMTP·OAuth 비밀이 소스/번들에 없다.

E05 · staging Preview와 DB·Auth 설정 대조

환경표를 채운다. Vercel Production Branch=main을 확인하고 staging은 Preview로 연결한다. Preview의 VITE_ 두 값은 별도 staging Supabase, Production 값은 production Supabase로 지정한다. 각 새 수업 DB를 inspect.sql로 확인하고 검토한 setup.sql→mfa-required.sql을 한 번 적용한다. 환경별 Auth·메일·SNS callback/redirect·Naver 어댑터를 점검한다.

현재 과제 앱을 staging→main 최종 릴리스할 수 있도록 점검해줘.
git status, remotes, 브랜치, PR base/head와 배포 설정을 먼저 읽어줘. git staging area와 staging 브랜치를 구분해 설명해줘.
feature/csv-release→staging PR에서 검토하고 staging 브랜치는 Preview로 빌드해. 강사가 준비한 별도 수업 staging Supabase와 production Supabase에 같은 검토된 스키마·소유자 RLS·restrictive AAL2가 있는지 먼저 읽기 전용으로 확인해줘. 기존 운영 DB를 초기화하거나 임의 변경하지 마.
VITE_SUPABASE_URL과 VITE_SUPABASE_PUBLISHABLE_KEY의 Preview/Production 매핑, 실제 build commit·URL·DB 프로젝트 이름을 비밀값 없이 기록해. SNS callback/Redirect URL·SMTP·Naver 서버 어댑터도 환경별로 확인해줘.
검증표에 실패나 미확인이 남으면 완료로 표시하지 마. 통과 후 staging→main PR을 준비하고 main Production 재빌드 후 운영 URL에서 로그인/MFA/CRUD/CSV/계정 분리를 다시 확인해.
Preview 검증이 Production의 같은 환경 검증이라고 단정하지 마. 실패 시 이전 앱 배포 복원과 DB 복구가 다름을 설명하고 릴리스 기록 양식을 채워줘. 강제 push·보호 해제·비밀 커밋 없이 진행해줘.

학생 확인

환경 변수 변경 뒤 새 빌드를 만든다. 프런트엔드 URL/key 외 비밀값은 VITE_로 만들지 않는다. DB migration은 Vercel 코드 배포와 별도다. 기존 정책이 있으면 SQL을 무작정 재실행하지 않는다.

E06 · feature→staging 검토 후 main 최종 배포

변경을 커밋·push하고 GitHub PR base=staging, compare=feature/csv-release를 만든다. 동료가 diff·비밀·검사표를 검토하고 병합한다. Vercel staging Preview의 READY와 commit을 확인한 뒤 실제 URL에서 검증한다. 모두 통과하면 PR base=main, compare=staging을 검토·병합한다. main의 새 Production 배포에서 같은 검사를 다시 하고 release-record.md를 완성한다.

본인 저장소에서 한 줄씩 실행

npm run build
git add index.html styles.css src README.md
git diff --cached
git commit -m "Add secure task CSV export"
git push -u origin feature/csv-release

학생 확인

PR별 base/head·commit·실제 URL·DB 이름·검증자·결과가 남는다. Preview 통과와 Production 재빌드 통과를 별도로 기록한다. 실패하면 배포 완료 표시를 멈추고 원인을 수정한다.

E07 · 3분 발표·짝 피드백

요청3으로 발표 원고를 작성하고 발표용 가상 과제3개와 CSV를 준비한다. 청중에게 비밀이 보이지 않게 MFA를 사전 완료한다. 문제/사용자→핵심 동작→권한 검증 근거→두 배포 환경→한계 순서로3분 시연하고 짝에게 개선점1개를 받는다. 실SNS 연결 미완료는 미확인으로 설명한다.

완성한 과제 체크 앱의 3분 시연과 인수인계 자료를 만들어줘.
1일차 문제/사용자와 웹 선택→2일차 Git·개선→3일차 DB·Auth→4일차 SNS·MFA→5일차 CSV·검증·배포를 연결해줘.
0:00~0:30 문제/대상, 0:30~1:30 실제 과제 CRUD·검색·CSV, 1:30~2:15 A/B 권한 검증 근거와 MFA, 2:15~2:45 staging/Production URL·commit, 2:45~3:00 한계/다음 기능으로 구성해줘.
실제 확인한 결과와 모의/미확인을 구분하고 비밀키·토큰·TOTP QR/코드·학생 개인정보를 화면/문서에 넣지 마. 발표용 가상 계정을 사용하고 MFA는 청중에게 비밀을 보이지 않게 사전 완료해.
README에는 실행/환경변수 이름/SQL 적용 순서/CSV 열람 범위/테스트 방법/배포·복구·미확인 항목을 적어줘. 동료 피드백 1건을 이슈로 남길 수 있는 양식과 100점 평가표도 포함해줘.

학생 확인

저장소/운영 링크·화면 시연·권한 근거·staging/Production commit·다음 개선1개가 있다. QR·OTP·토큰·실제 학생 정보가 발표 화면/CSV/캡처에 없다.

E08 · 인수인계·릴리스 기록·다음 이슈

README에 실행/환경 변수 이름/SQL 순서/검사 방법/CSV 범위/배포·복구를 정리한다. checks.csv와 release-record.md를 채우고 peer-feedback.md의 개선점 하나를 GitHub 이슈로 남긴다. 최종 main commit·운영URL·발표 원고·가상 CSV·미확인 항목을 제출한다.

본인 저장소에서 한 줄씩 실행

git status -sb
git log -5 --oneline
git diff --check

학생 확인

본인이 하지 않은 실SNS·운영 검증을 통과로 표시하지 않는다. 발표용 CSV도 본인 가상 자료만 제출한다. 미커밋 작업·열린 PR·실패 검사·복구 담당자가 분명하다.

CSV의 범위·형식·수식 위험·취소

버튼은 현재 검색/필터와 무관하게 로그인한 본인 과제 전체를 새로 조회한다. 현재 화면 목록은 최대1,000건, 내보내기는 최대10,000건이다. 상한 초과·페이지 오류·건수 변경·계정 전환에는 부분 CSV를 생성하지 않는다.

수식 위험 변환은 사람의 스프레드시트 열람을 위한 처리다. 탭이 실제 셀 값에 포함되므로 원본 복원/재가져오기용 백업으로 쓰지 않는다. OWASP는 인용/이스케이프만으로 모든 스프레드시트 및 재저장을 보장할 수 없다고 설명한다. 교실의 Excel/Sheets에서 텍스트 가져오기로 실제 열람을 확인한다. DB 원본은 그대로 둔다.

CSV 생성·다운로드·인증/취소 전체 코드

// 사람의 스프레드시트 열람용입니다. 원본 복원/재가져오기 형식이 아닙니다.
function cell(value, userInput = false) {
  let text = String(value ?? '');
  // 인용만으로 수식이 막히지 않습니다. 전각·선행 공백/제어문자도 검사합니다.
  if (userInput && (/^\s*[=+\-@＝＋－＠]/u.test(text) || /^[\t\r\n]/u.test(text))) text = '\t' + text;
  return '"' + text.replaceAll('"', '""') + '"';
}

export function toTaskCsv(tasks) {
  const rows = [['과제명', '과목', '마감일', '완료'].map(v => cell(v)).join(',')];
  for (const task of tasks) rows.push([
    cell(task.title, true), cell(task.subject, true), cell(task.due), cell(task.done ? '완료' : '미완료')
  ].join(','));
  return '\uFEFF' + rows.join('\r\n') + '\r\n';
}

export function downloadTaskCsv(csv) {
  const url = URL.createObjectURL(new Blob([csv], {type:'text/csv;charset=utf-8'}));
  const link = document.createElement('a');
  link.href = url;
  link.download = `my-tasks-${new Date().toISOString().replaceAll(':','-').slice(0,19)}Z.csv`;
  document.body.append(link);
  try { link.click(); }
  finally { link.remove(); setTimeout(() => URL.revokeObjectURL(url), 1000); }
}

export function createCsvExporter(client, store, download = downloadTaskCsv) {
  let active = null;
  return {
    cancel() { active?.abort(); },
    async run(userId, isCurrent, onProgress) {
      if (active) throw {code:'EXPORT_BUSY'};
      const controller = new AbortController();
      active = controller;
      function check() {
        controller.signal.throwIfAborted();
        if (!isCurrent()) throw {code:'EXPORT_CANCELLED'};
      }
      try {
        check();
        const {data, error} = await client.auth.getUser();
        check();
        if (error || data.user?.id !== userId) throw {code:'EXPORT_AUTH'};
        const aal = await client.auth.mfa.getAuthenticatorAssuranceLevel();
        check();
        if (aal.error || aal.data.currentLevel !== 'aal2') throw {code:'EXPORT_AUTH'};
        const tasks = await store.listForExport(userId, controller.signal, onProgress);
        check();
        const csv = toTaskCsv(tasks);
        check();
        download(csv);
        return tasks.length;
      } finally {
        if (active === controller) active = null;
      }
    }
  };
}

DB 페이지 조회와 실패 처리

const FIELDS = 'id,user_id,title,subject,due,done,created_at';
function item(row) {
  return {id:row.id,title:row.title,subject:row.subject,due:row.due,done:row.done,createdAt:Date.parse(row.created_at)};
}
function requireResult(result) { if(result.error)throw result.error;return result.data; }
export function createTaskStore(client) {
  return {
    async listForExport(userId, signal, onProgress) {
      const pageSize=500, maxRows=10000, result=[], seen=new Set();
      let expected=null;
      for(let offset=0;;offset+=pageSize){
        signal.throwIfAborted();
        const response=await client.from('tasks')
          .select('id,title,subject,due,done,created_at',{count:'exact'})
          .eq('user_id',userId).order('created_at').order('id')
          .range(offset,offset+pageSize-1).abortSignal(signal);
        signal.throwIfAborted();
        const rows=requireResult(response);
        if(expected===null)expected=response.count;
        if(!Number.isSafeInteger(expected)||expected<0||response.count!==expected)throw {code:'EXPORT_CHANGED'};
        if(expected>maxRows)throw {code:'EXPORT_LIMIT'};
        if(rows.length!==Math.min(pageSize,expected-offset))throw {code:'EXPORT_CHANGED'};
        for(const row of rows){if(seen.has(row.id))throw {code:'EXPORT_CHANGED'};seen.add(row.id);result.push(row);}
        onProgress?.(result.length,expected);
        if(result.length===expected)return result;
      }
    },
    async list(userId) {
      const rows=requireResult(await client.from('tasks').select(FIELDS).eq('user_id',userId).order('created_at').limit(1000));
      return rows.map(item);
    },
    async add(userId,values) {
      return item(requireResult(await client.from('tasks').insert({user_id:userId,title:values.title,subject:values.subject,due:values.due}).select(FIELDS).single()));
    },
    async addMany(userId,values) {
      const rows=requireResult(await client.from('tasks').insert(values.map(v=>({user_id:userId,title:v.title,subject:v.subject,due:v.due}))).select(FIELDS));
      return rows.map(item);
    },
    async update(userId,id,values) {
      const allowed={};
      for(const key of ['title','subject','due','done'])if(key in values)allowed[key]=values[key];
      return item(requireResult(await client.from('tasks').update(allowed).eq('id',id).eq('user_id',userId).select(FIELDS).single()));
    },
    async remove(userId,id) {
      const rows=requireResult(await client.from('tasks').delete().eq('id',id).eq('user_id',userId).select('id'));
      if(rows.length!==1)throw {code:'NO_ROW'};
    },
    async restore(userId,task) {
      return item(requireResult(await client.from('tasks').insert({id:task.id,user_id:userId,title:task.title,subject:task.subject,due:task.due,done:task.done,created_at:new Date(task.createdAt).toISOString()}).select(FIELDS).single()));
    }
  };
}

계정별 권한과 실제 API 검사

아래 코드는 가상 계정·본인 로컬 Vite 개발 서버에서만 DevTools Console로 실행한다. B는 별도 브라우저 프로필에서 로그인·MFA를 마친다. targetId/targetOwner는 A가 만든 가상 과제의 UUID와 A의 uid로 바꾼다. 배포 번들에는 /src 경로가 없으므로 운영 Console에 그대로 붙이지 않는다. JWT·브라우저 세션·전체 client 객체를 출력하지 않는다.

const {supabase: qa} = await import('/src/supabase-client.js');
const targetId = 'A의-가상과제-UUID';
const targetOwner = 'A의-user-UUID';
const read = await qa.from('tasks').select('id').eq('id',targetId);
console.log('조회행',read.data?.length,'오류코드',read.error?.code);
const change = await qa.from('tasks').update({done:true}).eq('id',targetId).select('id');
console.log('수정행',change.data?.length,'오류코드',change.error?.code);
const remove = await qa.from('tasks').delete().eq('id',targetId).select('id');
console.log('삭제행',remove.data?.length,'오류코드',remove.error?.code);
const forged = await qa.from('tasks').insert({user_id:targetOwner,title:'위조 검사',due:'2026-11-11'});
console.log('소유자위조추가 거절',!!forged.error);
const mine = await qa.from('tasks').select('id').limit(1);
if(mine.data?.[0]) {
  const transfer = await qa.from('tasks').update({user_id:targetOwner}).eq('id',mine.data[0].id);
  console.log('소유자변경 거절',!!transfer.error);
}
// A 프로필에서 원본의 존재·done·소유자가 바뀌지 않았는지 새로고침해 확인

UUID 자리표시자를 그대로 두면 단순 형식 오류만 검사하게 된다. 실제 가상 UUID를 넣고 표와 대조한다. 익명은 로그아웃한 개발 서버에서 동일 SDK로 SELECT/INSERT를 시도한다. AAL1은 등록된 계정의 재로그인 직후, AAL2는 인증앱 코드 확인 후 검사한다. QR/코드는 보고서에 넣지 않는다. 소유자 정책4개 AND AS RESTRICTIVE AAL2를 함께 유지한다.

staging→main 최종 배포 실행표

1. GitHub에서 기존 main을 기준으로 staging 브랜치를 준비한다. staging area는 git add로 만드는 커밋 대기 영역이며 브랜치와 다르다.
2. Vercel Settings에서 Production Branch=main을 확인한다. staging push는 보통 Preview다. Preview 두 VITE_ 값은 staging DB, Production 두 값은 별도 production DB로 설정한다. 다른 Preview도 쓰면 staging branch override를 확인한다.
3. 본인 수업용 새 DB를 sql/inspect.sql로 먼저 확인한 뒤 setup.sql→mfa-required.sql을 검토·적용한다. 이미 존재하면 중복 실행하지 말고 변경 migration을 검토한다. Auth 가입·이메일/비밀번호·TOTP 설정은 DB SQL과 별도다.
4. staging/production Supabase의 Site URL·Redirect URLs, 제공자마다 표시하는 Supabase callback, SMTP/Resend 발신·이메일 확인/복구, Naver 고정 서버 어댑터를 환경별 점검한다. 비밀은 각 서비스 설정에 보관한다.
5. feature/csv-release→staging PR을 검토·병합한다. Preview READY·commit·URL·DB 이름을 대조하고 로그인→MFA→과제 추가/완료/재조회→CSV→B분리 검사를 한다.
6. 모두 통과하면 staging→main PR을 검토·병합한다. main은 Production 환경으로 새 빌드한다. 운영 URL의 동일 smoke 검사를 반복하고 기록한다.
7. 실패/미확인이 있으면 출시 완료 표시를 멈춘다. 필요하면 이전 정상 앱 배포를 복원하고, DB 스키마/데이터 복구는 별도 검토한다.

이 수업은 main의 Git 자동 배포를 사용한다. Preview 검증만으로 Production의 환경·메일·SNS가 검증되지는 않는다. Vercel에서 Preview를 promote하는 별도 기능도 Production 설정으로 다시 빌드될 수 있으므로 Preview URL을 그대로 운영 검증 결과로 적지 않는다. Vercel 배포는 Supabase SQL을 자동 적용하지 않는다.

릴리스 기록과 복구 담당자

# 과제 체크 앱 최종 릴리스 기록
검증 일시/확인자:
저장소 / feature PR → staging:
staging commit / Preview URL / Supabase 프로젝트 이름:
staging 빌드 상태 / 실제 검사 근거:
staging PR → main:
main commit / Production URL / Supabase 프로젝트 이름:
Production 빌드 상태 / 실제 검사 근거:
DB SQL 검토·적용 순서/기록 (키/연결문자열 제외):
이메일·각 SNS·MFA 실제/모의/미확인:
실패·미확인 / 출시 판단:
이전 정상 앱 배포 / 복원 담당자:
DB 변경 유무 / 별도 DB 복구 절차:
다음 이슈 / 동료 피드백:

ZIP의 environments.csv와 release-record.md에 실제 값을 기록하되 키·비밀번호·연결 문자열은 넣지 않는다. URL/commit/프로젝트 이름과 검사 시각이면 근거를 대조할 수 있다.

3분 발표 원고·100점 평가·인수인계

발표3분+피드백2분을6명 소그룹으로30분 운영한다. 발표용 MFA는 사전 완료하고 비밀 QR/OTP를 화면 공유하지 않는다. CSV도 본인 가상 과제만 포함한다. 개선점1개는 peer-feedback.md와 GitHub 이슈에 남긴다.

최종 제출 묶음

• main 저장소·PR2개·Preview/Production URL과 commit
• README: 실행·환경 변수 이름·SQL 적용 순서·검증·CSV 한계·배포/복구
• checks.csv·environments.csv·release-record.md
• 3분 발표 원고·가상 CSV·동료 피드백·후속 이슈1개
• 실제/모의/미확인 목록과 다음 확인 담당자

최종 통합 검사표

내 과제 앱의 최종 검증을 실행 가능한 범위에서 진행하고 checks.csv에 근거를 남겨줘.
가상 A/B 계정, 익명, AAL1과 AAL2로 직접 Data API를 검사해. 본인 CRUD 허용, 타인 조회/수정/삭제의 0행 또는 거절과 원본 불변, user_id 위조 추가/변경 거절을 확인해. UI가 숨겨졌다는 이유로 권한 검사를 통과시키지 마.
CSV가 본인 전체 DB 과제만 새 조회하는지, 검색 결과와 무관한지, 한글/인용/CRLF/위험 입력/빈 목록/1,203행을 처리하는지 검사해. AAL1 내보내기 거절, 페이지 실패와 계정 전환에서 다운로드 0회를 확인해.
비밀은 값 대신 존재 여부와 변수 이름만 보고해. git diff --cached, .gitignore, 번들에 secret/service_role/SMTP/OAuth secret이 없는지 점검해. publishable key는 공개 식별값이며 RLS를 대신하지 않음을 명시해.
빌드·PR·배포상태와 실제 URL 기능 검사를 분리해. 로컬 통과, 모의 통과, staging 실제, Production 실제, 미실행을 구분해 결과/시각/commit/검증자를 기록해. 실패·미확인 항목이 남으면 출시 완료라고 쓰지 마.

통과/실패/미확인과 실제 결과·시각·확인자를 CSV 양식에 적는다. 테스트 계정/키/QR/코드/토큰을 근거로 첨부하지 않는다.

문제 해결과 예제의 검증 범위

완성 소스는 격리된 로컬 Supabase의 실제 TOTP/AAL/RLS와1,203행 CSV 페이지 조회, 타인 제외·소유자 위조·계정 전환·실패 처리를 검사한다. ZIP 클린 빌드와 HTML 발표·교재를 검수한다. 학생의 실제 cloud staging/Production DB 연결, 이메일 발송, 세 SNS 제공자 승인/동의 왕복, 실제 교실 스프레드시트 열람은 각 수업 계정에서 최종 확인해야 한다. 강의 사이트 게시와 학생 앱의 두 환경 릴리스는 별개다.