8회 · 로그인과 보안: 내 글은 나만 고치게

오늘의 흐름링크 복사

지금 웹앱의 문제링크 복사

7회까지 만든 웹앱은 이런 상태입니다.

• 누구나 모임을 만들 수 있습니다. 장난으로 모임을 100개 만들어도 막을 방법이 없습니다.
• 누구나 남의 모임을 고치거나 지울 수 있습니다.
• 공개 키는 화면 코드에 실려 있어 누구나 볼 수 있습니다. 마음만 먹으면 웹앱을 거치지 않고 데이터베이스에 직접 요청을 보낼 수도 있습니다.

인증과 권한은 다릅니다링크 복사

보안 이야기에서 가장 먼저 구분해야 할 두 단어가 있습니다.

로그인만 붙이고 권한을 정하지 않으면 반쪽짜리 보안입니다. "누구인지는 아는데 아무거나 다 할 수 있는" 상태가 되기 때문입니다. 실제 사고는 대부분 이 두 번째를 빠뜨려서 생깁니다.

Supabase Auth: 로그인을 빌려 쓰기링크 복사

로그인을 직접 만드는 것은 전문가에게도 어렵고 위험합니다. 비밀번호를 안전하게 저장하고, 비밀번호 찾기 메일을 보내고, 로그인 상태를 유지하는 일이 모두 까다롭습니다. 그래서 요즘은 검증된 서비스의 로그인을 빌려 쓰는 것이 상식입니다.

Supabase Auth가 해 주는 일:

• 이메일·비밀번호 회원가입, 로그인, 로그아웃
• 비밀번호는 원래 글자가 아니라 되돌릴 수 없게 바꾼 값(해시) 으로 저장
• 이메일 확인 메일, 비밀번호 재설정 메일
• 원하면 구글·카카오 같은 소셜 로그인도 연결 가능

RLS: 줄마다 채우는 자물쇠링크 복사

RLS(Row Level Security, 행 수준 보안)는 데이터베이스의 한 줄 한 줄마다 "누가 읽고, 누가 만들고, 누가 고칠 수 있는지"를 정하는 규칙입니다.

7회의 엑셀 비유로 말하면, 모임 시트를 모두에게 공유하되 각 줄에 "이 줄은 하늘 님만 고칠 수 있음"이라는 자물쇠를 다는 것과 같습니다.

RLS 꺼짐

방문자회원 하늘관리자

RLS가 꺼져 있으면 공개 키만 있으면 누구나 모든 행을 고치고 지울 수 있습니다.

모임	등록자	해 보기
11월 정기 모임	하늘	수정삭제
북토크 번개	바다	수정삭제
연말 모임	하늘	수정삭제

우리 모임의 규칙링크 복사

auth.uid()는 "지금 요청한 사람의 회원 번호", owner_id는 "이 줄을 만든 사람의 회원 번호"입니다. 둘이 같을 때만 허락한다는 뜻입니다. 이 문장 하나만 읽을 수 있어도 오늘의 목표는 달성입니다.

자세히RLS를 켜기만 하고 규칙을 안 만들면 어떻게 되나요펼치기

RLS를 켜면 기본값은 "아무도 안 됨" 입니다. 그래서 규칙을 하나도 안 만들면 목록이 텅 비어 보입니다. 7회에 "목록이 비어 있어요"라는 문제를 겪었다면 바로 이 상태였습니다.

반대로 RLS를 아예 끄면 "누구나 다 됨" 입니다. 공개 키만 있으면 누구나 읽고, 고치고, 지울 수 있습니다. 가장 위험한 상태입니다.

상태	결과	위험
RLS 꺼짐	누구나 무엇이든	매우 위험
RLS 켜짐, 규칙 없음	아무도 아무것도 못 함	안전하지만 안 쓰임
RLS 켜짐, 규칙 있음	규칙대로	올바른 상태

열쇠는 금고에: 환경변수와 두 가지 키링크 복사

환경변수링크 복사

환경변수는 비밀번호나 키처럼 코드에 직접 적으면 안 되는 값을 따로 보관하는 칸입니다.

• 내 컴퓨터: .env.local 파일 (.gitignore 덕분에 GitHub에 안 올라감)
• 배포 서버: Vercel의 Settings → Environment Variables

공개 키와 비밀 키링크 복사

Supabase 공개 키 (anon/publishable) Supabase 비밀 키 (service_role) Claude API 키 데이터베이스 비밀번호

브라우저(화면) 코드방문자 누구나 개발자 도구로 볼 수 있음 서버 환경변수.env.local · Vercel 환경변수 · 방문자는 볼 수 없음

키가 새어 나갔다면링크 복사

실수로 키를 GitHub에 올렸거나 채팅창에 붙여 넣었다면, 파일을 지우는 것만으로는 부족합니다. Git은 모든 기록을 남기기 때문에 예전 커밋에 키가 그대로 남아 있습니다.

1. 해당 서비스 대시보드에서 키를 즉시 다시 발급(rotate) 합니다. 예전 키는 쓸모없어집니다.
2. 새 키를 .env.local과 Vercel에 넣습니다.
3. 파일을 저장소에서 빼고 .gitignore에 추가합니다.

요즘 업계에서는링크 복사

170개 앱의 문이 열려 있었다링크 복사

2025년 봄, 한 보안 연구자가 AI 앱 빌더 Lovable로 만든 공개 앱 1,645개를 조사했더니 170개(약 10%) 에서 로그인하지 않은 누구나 개인정보를 읽을 수 있는 문제가 발견됐습니다. 원인은 오늘 배운 바로 그것, Supabase 표에 RLS가 제대로 걸려 있지 않아 공개 키만으로 데이터에 접근할 수 있었던 것입니다. 이 문제는 CVE-2025-48757이라는 번호로 등록됐습니다. (위키백과 · Vibe coding, CVE-2025-48757)

이 사건이 알려 주는 것:

• AI가 만든 앱도 동작은 완벽해 보였습니다. 화면에서는 아무 문제가 보이지 않습니다. 보안 구멍은 눈에 안 보입니다.
• 플랫폼 회사는 "앱 데이터를 지키는 책임은 앱을 만든 사람에게 있다"는 입장이었습니다. 즉, 만든 사람이 여러분이면 책임도 여러분에게 있습니다.
• 해결책은 어렵지 않았습니다. 규칙 몇 줄과 직접 막히는지 시험해 보는 습관이면 충분했습니다.

개발자들도 AI를 다 믿지는 않는다링크 복사

2025년 Stack Overflow 설문에서 개발자의 46%가 AI 도구의 정확성을 믿지 않는다고 답했습니다. 믿는다는 응답(33%)보다 많습니다. (Stack Overflow 2025 설문 · AI) 전문가들도 AI가 만든 결과를 검증하는 것을 당연한 일로 여긴다는 뜻입니다. 보안은 그중에서도 가장 먼저 검증할 부분입니다.

시연링크 복사

강사가 다음을 보여 줍니다.

1. RLS 없이 공개 키만으로 데이터를 읽고 지우는 모습을 시험용 프로젝트에서 보여 줍니다. (실제 서비스에 해 보면 안 됩니다.)
2. Claude Code에게 RLS 규칙을 만들게 하고, 같은 시도가 막히는 것을 보여 줍니다.
3. 브라우저 두 개(일반 창과 시크릿 창)에 각각 다른 계정으로 로그인해, B 계정으로는 A의 모임에 수정 버튼이 안 보이고, 억지로 시도해도 거절되는 것을 확인합니다.

실습링크 복사

오늘의 주제: "책 읽는 저녁" 웹앱에 회원가입·로그인을 붙이고, 모임마다 "만든 사람" 칸을 추가해 만든 사람만 고치고 지울 수 있게 합니다. 시험용 계정은 실제로 쓰는 이메일 대신 별칭을 써도 됩니다.

필수

실습 8-1 · 회원가입·로그인 붙이기

약 20분

1. 계획 먼저 받기

   Claude Code에서 웹앱 프로젝트를 열고 플랜 모드로 요청합니다.

   PROMPT회원가입·로그인 붙이기 플랜 모드 권장

   Supabase 로그인으로 이메일 회원가입·로그인·로그아웃을 붙여줘. 로그인한 사람만 모임을 만들 수 있게 하고, 계획부터 보여줘.

   복사로그인 · 기본

   이렇게 되면 성공

   계획

   1. Supabase 로그인 도구 설치 (@supabase/ssr)

   2. /login 화면: 이메일·비밀번호로 회원가입과 로그인

   3. 상단에 로그인 상태 표시와 로그아웃 버튼

   4. meetups 표에 owner_id(만든 사람) 칸 추가

   5. 로그인하지 않으면 "모임 만들기" 대신 "로그인하고 모임 만들기" 안내

   이대로 진행할까요?

   계획을 읽고 궁금한 점을 물어본 뒤 진행을 허락합니다.

   이 단계 완료
2. Supabase에서 이메일 로그인 확인

   Supabase 대시보드 → Authentication → Sign In / Providers에서 Email이 켜져 있는지 확인합니다. 실습 중에는 확인 메일을 기다리기 번거로우니 Confirm email을 잠시 꺼 둬도 됩니다. 실제로 운영할 때는 다시 켜세요.

   이 단계 완료
3. 회원가입하고 로그인해 보기

   localhost:3000/login에서 시험용 계정 A를 만들고 로그인합니다. Supabase Authentication → Users에 계정이 생겼는지 확인하세요. 비밀번호가 보이지 않는 것도 확인해 보세요. 원래 글자가 저장되지 않기 때문입니다.

   PROMPT로그인 흐름 쉽게 설명 듣기

   방금 만든 회원가입·로그인이 어떤 순서로 동작하는지, 놀이공원 입장권에 빗대어 처음 배우는 사람이 알아듣게 설명해줘. 비밀번호는 어디에 저장되는지도.

   복사

   막혔을 때

   Email not confirmed 라고 나와요

   로그인했는데 새로 고치면 풀려요

   너무 많이 시도했다고 막혔어요

   이 단계 완료

필수

실습 8-2 · 보안 규칙(RLS) 만들기

약 15분

규칙을 표로 읽고 이해한 뒤 실행합니다.

1. 규칙 설계와 SQL 받기
   PROMPT보안 규칙(RLS) 만들기

   모임 테이블에 RLS 정책을 만들어줘. 누구나 읽기 가능, 로그인한 사람만 만들기, 만든 사람만 고치고 지우기. 각 정책이 무슨 뜻인지 표로 설명해주고 SQL을 줘.

   복사왜 이렇게 쓰나요?로그인 · 기본

   이렇게 되면 성공

   | 정책 이름 | 할 일 | 누구에게 |

   | 누구나 모임 보기 | select | 모두 |

   | 로그인하면 모임 만들기 | insert | 로그인한 사람 |

   | 내 모임만 고치기 | update | auth.uid() = owner_id |

   | 내 모임만 지우기 | delete | auth.uid() = owner_id |

    

   alter table meetups enable row level security;

   create policy "누구나 모임 보기" on meetups for select using (true);

   …

   이 단계 완료
2. SQL 읽고 실행
   PROMPTSQL 한 줄씩 설명 듣기

   이 SQL을 한 줄씩 엑셀에 빗대어 설명해줘. 데이터를 지우거나 바꾸는 줄이 있으면 따로 표시해줘.

   복사

   지우는 문장이 없는지 확인한 뒤 Supabase SQL Editor에서 실행합니다. Authentication → Policies(또는 Table Editor의 표 옆 방패 아이콘)에서 정책 4개가 보이면 성공입니다.

   막혔을 때

   policy already exists 라고 나와요

   예전에 만든 모임을 아무도 못 고쳐요

   이 단계 완료

필수

실습 8-3 · 두 계정으로 막히는지 시험

약 15분

"만들었다"가 아니라 "막히는 것을 봤다"가 완료 기준입니다.

1. 시험 순서 받기
   PROMPT두 계정으로 보안 시험하기

   보안 규칙이 제대로 동작하는지 시험하고 싶어. 계정 A와 계정 B로 각각 해 볼 일을 순서대로 적어줘. 특히 B가 A의 모임을 고치거나 지우려 할 때 막히는지, 로그아웃한 상태에서는 무엇이 보이는지 확인하는 단계를 넣어줘.

   복사왜 이렇게 쓰나요?보안·점검 · 기본

   이 단계 완료
2. 일반 창과 시크릿 창으로 시험
   Windows 기준

   WindowsmacOS

   크롬·엣지에서 Ctrl + Shift + N으로 시크릿(InPrivate) 창을 엽니다. 일반 창은 계정 A, 시크릿 창은 계정 B로 로그인합니다.

   받은 순서대로 해 보고 결과를 기록합니다.

   이렇게 되면 성공

   [계정 A] 모임 만들기 → 성공, 내 모임에 "수정" 버튼 보임

   [계정 B] A의 모임 → "수정" 버튼 안 보임

   [계정 B] 주소창에 /meetups/1/edit 직접 입력 → "권한이 없어요"

   [로그아웃] 목록은 보이고, "모임 만들기"는 로그인 안내로 바뀜

   막혔을 때

   B 계정으로도 A의 모임이 고쳐져요

   버튼은 숨겨졌는데 그걸로 충분한가요

   이 단계 완료
3. 커밋하고 배포
   PROMPT바뀐 내용 커밋하기

   지금까지 바뀐 내용을 한글 메시지로 커밋해줘.

   복사

   푸시 후 배포 주소에서도 로그인이 되는지 확인합니다. 배포 주소에서 로그인 후 이상한 주소로 돌아간다면 Supabase Authentication → URL Configuration에 배포 주소를 추가해야 합니다. "배포 주소에서 로그인하려면 Supabase에 무엇을 설정해야 해?"라고 물어보세요.

   이 단계 완료

선택

실습 8-4 · 키가 제자리에 있는지 점검

약 10분

1. 키 위치 점검
   PROMPT키가 제자리에 있는지 점검

   이 프로젝트에서 쓰는 키와 비밀값을 모두 찾아서 표로 보여줘. 각각 어디에 저장돼 있는지(.env.local, 코드, 브라우저로 내려가는 코드), 브라우저에 노출돼도 되는 값인지, .gitignore에 들어 있는지 확인해줘. 값 자체는 화면에 보여 주지 마.

   복사왜 이렇게 쓰나요?보안·점검 · 기본

   이 단계 완료
2. 전체 보안 점검
   PROMPT보안 점검

   이 프로젝트의 보안을 점검해줘. 키가 코드에 노출돼 있거나, 보안 규칙(RLS) 없이 누구나 쓸 수 있는 테이블, 앱 안에 들어간 비밀 키가 있는지 확인해서 목록으로 보여줘.

   복사왜 이렇게 쓰나요?보안·점검 · 기본

   점검 결과에서 "위험"으로 나온 것이 있으면 하나씩 고치고, 고친 뒤 다시 점검합니다. 판단이 어려우면 다음 수업에 가져와 함께 봅니다.

   이 단계 완료

정리링크 복사

다음 시간 예고: 이제 안전한 뼈대가 생겼습니다. 9회에는 참석 신청, 사진, 검색을 붙여 실제로 쓸 만한 서비스로 완성합니다.

복습링크 복사

과제링크 복사

더 해 보기링크 복사

다음 수업 · 9회기능 완성하기: 참석 신청, 사진, 검색