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

왜 이 레슨이 필요한가

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

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

스킬 호출 방법

Claude Desktop 새 채팅에서 슬래시 입력 후 /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 = 비밀번호 원문이 아니라 해시(암호화된 결과). 절대 원문 저장 X.
• created_at = 가입한 시각. 자동으로 채워줘요.

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

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

해시의 핵심 특성:

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

가장 많이 쓰이는 해시 알고리즘은 bcrypt예요. Rails나 Django 같은 프레임워크는 한 줄(has_secure_password)이면 자동 적용. AI에게 "회원가입 만들어줘"라고 시키면 알아서 bcrypt 써요.

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

1. 사용자가 로그인 폼에 이메일·비밀번호 입력 후 "로그인" 클릭
2. 브라우저가 그 데이터를 서버로 전송 (HTTPS로 암호화돼서 중간에 누가 봐도 못 알아봄)
3. 서버가 받은 이메일로 DB 검색 — SELECT * FROM users WHERE email = 'a@a.com'
4. 찾은 사용자의 password_digest와 입력 비번을 bcrypt로 비교 — 일치하면 로그인 성공
5. 서버가 "로그인 됨" 표시(세션 또는 JWT 토큰)를 브라우저로 보냄. 다음 요청부터 그 표시로 "이 사람은 a@a.com" 알 수 있음

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차 만들어줘요.
• "해시를 만든 비밀번호를 어떻게 비교해요?" → bcrypt 같은 라이브러리에는 "이 평문이 이 해시랑 매치돼요?" 하는 함수가 있어요(authenticate). 우리가 알고리즘을 짤 필요 X.
• "OAuth 구현이 어렵게 느껴져요." → 직접 짜면 어렵지만 Devise/Omniauth 같은 라이브러리가 핵심을 다 처리해요. AI에게 "구글 OAuth 붙여줘" 한 줄이면 돼요. Ch.4-8에서 함.
• "DB는 어떤 종류를 써야 해요?" → SQLite (개발용 + 작은 SaaS), PostgreSQL (대부분의 본격 운영). 1-1에서 본 Ch.4의 기본 모드는 SQLite로 시작해요. 심화 모드 또는 트래픽 늘면 PostgreSQL로 옮김.
• "비번 평문 저장 절대 안 된다고 했는데, 작은 SaaS라도?" → 절대 X. 사용자가 한 명이라도 안 됨. AI 도구를 쓰면 자동으로 안전한 방식이 적용되니까 일부러 평문 저장하라고 시키지만 마세요.