데이터 + DB + 인증 흐름 따라가기

왜 이 레슨이 필요한가

1-1에서 큰 그림(브라우저 → 서버 → DB)을 봤어요. 이번에는 그 흐름의 가장 중요한 한 조각 — "가입 버튼을 누른 순간 데이터가 어떻게 안전하게 저장되는가"를 자세히 따라가요. 이걸 한 번 손에 잡으면 Ch.4 BUILD에서 회원가입·로그인·OAuth를 만들 때 막힘이 거의 없어요. 머릿속에 그림이 있으니까요.

이 레슨은 /v1-data-flow 스킬을 호출해서 진행해요. 스킬이 "본인이 가입 버튼을 누르면" 시뮬레이션을 단계별로 보여주면서, 본인 손으로 DB 표를 채워보고 비밀번호 해시를 직접 시도해 봐요.

스킬 호출 방법

Orca의 Claude Code 대화창에서 슬래시 입력 후 /v1-data-flow를 고르거나 직접 입력하고 엔터.

/v1-data-flow

DB 표 = 엑셀 시트

비개발자들이 DB(데이터베이스)라고 들으면 어렵게 느끼지만, 사실 엑셀 시트와 거의 똑같아요. 한 SaaS의 DB는 보통 여러 개의 표(table)로 이루어져요. 회원가입 SaaS라면 가장 단순하게 users 표 하나면 시작할 수 있어요.

• 행(row) = 사용자 한 명. 새 가입 = 새 행 추가.
• 열(column) = 그 사용자에 대한 항목 한 개 (email, name, created_at…)
• id = 자동으로 1, 2, 3… 부여되는 고유 번호. "이 사용자다"라고 가리킬 때 사용.
• password_digest(비밀번호 칸) = 비밀번호 원문이 아니라 암호처럼 변환된 결과가 들어가요. 위 표의 $2a$12$Kix3jL... 같은 알아볼 수 없는 글자가 그거예요. 절대 원문 그대로 저장하지 않아요 (바로 아래에서 이유 설명). 칸 이름은 안 외워도 돼요.
• created_at = 가입한 시각. 자동으로 채워줘요.

비밀번호는 왜 평문 저장 X?

가장 중요한 보안 원칙입니다. 비밀번호 원문(평문 = plain text)을 절대 DB에 저장하지 않아요. 왜냐하면 만약 누군가 DB를 훔쳐 가면(해킹), 그 안에 적힌 비밀번호로 우리 사용자들이 다른 사이트(네이버·카카오·은행)에서도 같은 비번을 썼다면 즉시 다 털려요. 이걸 막기 위해 해시(hash)라는 일방향 암호화를 써요.

해시의 핵심 특성:

• 일방향 — 평문 → 해시는 가능하지만, 해시 → 평문은 불가능. 우리도 사용자 비번을 알 수 없어요. 그래서 "비밀번호 분실 시 재설정 메일"이 필요한 거예요. 보내드릴 수가 없어요.
• 매번 다른 결과 — 같은 비번이라도 매번 약간 다른 해시가 나와요 (소금 = salt 추가). DB만 봐도 "어 이 두 사람 같은 비번 쓰네"를 알 수 없어요.
• 검증은 가능 — 로그인 시 사용자가 입력한 평문을 다시 해시해서 DB의 해시와 비교. 일치하면 로그인 성공.

이 해시 변환은 사실 이미 검증된 도구가 자동으로 해줘요 — 우리가 직접 만들 필요가 전혀 없어요. AI에게 "회원가입 만들어줘"라고 시키면 알아서 안전한 방식으로 비밀번호를 보관해요. (개발자들 사이에서 이 방식을 'bcrypt'라고 부르는데, 이름은 안 외워도 돼요. "비밀번호는 되돌릴 수 없게 변환해서 저장한다"만 기억하면 충분해요.)

로그인은 어떻게 일어나는가 — 5단계

1. 사용자가 로그인 폼에 이메일·비밀번호 입력 후 "로그인" 클릭
2. 브라우저가 그 데이터를 서버로 전송 (HTTPS로 암호화돼서 중간에 누가 봐도 못 알아봄)
3. 서버가 받은 이메일로 DB(엑셀 시트 같은 표)에서 그 사람을 찾음 — "a@a.com인 행 어디 있지?"
4. 찾은 사람의 저장된 비밀번호(되돌릴 수 없게 변환된 것)와 방금 입력한 비밀번호가 같은지 확인 — 맞으면 로그인 성공
5. 서버가 브라우저에 "이 사람은 로그인된 회원"이라는 출입증을 발급 — 다음부터 그 출입증을 보여주면 매번 비밀번호를 다시 안 물어봐요

OAuth — "구글로 로그인"이 더 안전한 이유

비밀번호를 우리가 직접 받는 방식은 안전하게 만들 수 있지만, 책임도 무거워요. 한 번 DB가 털리면 사용자들이 다 위험해요. 그래서 요즘은 OAuth (Open Authorization)를 많이 써요. 익숙한 표현으로는 "구글로 로그인" / "카카오로 로그인" / "애플로 로그인"이에요.

OAuth의 핵심: 사용자의 비밀번호를 우리가 직접 받지 않아요. 비번 검증은 구글/카카오가 해주고, 우리는 "이 사람 진짜 a@a.com 맞다"는 도장(토큰)만 받아요.

그래서 비개발자가 처음 SaaS를 만들 때는 OAuth부터 붙이는 걸 강하게 추천해요. 이메일/비번 직접 만드는 것보다 (1) 코드가 짧고 (2) 안전하고 (3) 사용자도 가입 빠름. Ch.4-8에서 진짜 붙여요.

스킬이 묻는 질문 + 시뮬레이션

/v1-data-flow 스킬은 본인에게 다음 질문들을 던져요. 답하면서 본인 SaaS의 user 표를 머릿속에 그려가요.

스킬이 만들어주는 결과물

답변이 다 모이면 스킬이 본인 SaaS의 DB 스키마(표 설계도) 초안을 텍스트로 출력해줘요. 이건 Ch.3 PLAN에서 다듬어지고, Ch.4-8에서 진짜 코드로 바뀌어요.

users 표
  id (자동)
  email
  name
  google_uid (OAuth 식별자)
  created_at (자동)

books 표
  id (자동)
  user_id  →  users.id 참조
  title
  author
  created_at

notes 표
  id (자동)
  book_id  →  books.id 참조
  body
  created_at

막히는 지점 — 미리 답

• "표를 직접 설계할 자신이 없어요." → 정상이에요. 1-2는 "감각 잡기"가 목표예요. 진짜 설계는 Ch.3 PLAN에서 AI가 자동으로 1차 만들어줘요.
• "변환된 비밀번호를 나중에 어떻게 비교해요?" → 이미 만들어진 도구가 "방금 입력한 비밀번호가 저장된 거랑 맞아요?"를 확인해줘요. 우리가 그 방법을 짤 필요 전혀 없어요 — AI가 자동으로 붙여줘요.
• "OAuth(구글로 로그인) 구현이 어렵게 느껴져요." → 직접 짜면 어렵지만, 이것도 이미 만들어진 도구가 핵심을 다 처리해요. AI에게 "구글로 로그인 붙여줘" 한 줄이면 돼요. Ch.4-8에서 함.
• "DB는 어떤 종류를 써야 해요?" → SQLite (개발용 + 작은 SaaS), PostgreSQL (대부분의 본격 운영). 1-1에서 본 Ch.4의 기본 모드는 SQLite로 시작해요. 심화 모드 또는 트래픽 늘면 PostgreSQL로 옮김.
• "비번을 원문 그대로 저장하면 절대 안 된다고 했는데, 작은 SaaS라도?" → 절대 X. 사용자가 한 명이라도 안 됨. AI 도구를 쓰면 자동으로 안전한 방식이 적용되니까 일부러 원문 저장하라고 시키지만 마세요.
• "읽다가 막히거나 용어가 도무지 안 잡혀요." → 막힌 문장이나 헷갈리는 표를 그대로 복사해서 Claude Code(또는 claude.ai 웹 채팅)에 붙여넣고 "이거 비개발자가 알아듣게 다시 설명해줘"라고 물어보세요. 이게 가장 빠른 길이에요.