G-1: 프론트엔드 인증 ① — 진짜 로그인을 만듭니다

안녕하세요, 홍순구 튜터입니다.

시작하기 전에 우리 앱으로 실험을 하나 해봤어요. 브라우저 개발자 도구를 열어서 쿠키 하나를 손으로 만들었습니다. 이름은 me, 값은 nobody. 그런 사람은 우리 앱에 없어요.

그 상태로 재훈이의 프로필을 열어봤습니다.

  요청   GET /jaehoon      (쿠키: me=nobody)
  응답   200
  머리말  @nobody

들어가졌습니다. 그리고 앱은 저를 @nobody라고 부르고 있어요.

여기서 멈추지 않았습니다. 그 상태로 민지의 프로필에 가면 팔로우 버튼이 그대로 있어요. 눌러봤더니 서버까지 요청이 갔습니다. 우리 앱은 제가 누구인지 물어본 적이 한 번도 없어요.

지난 시간 마지막에 이렇게 말씀드렸죠. D-8에서 세운 문지기는 쿠키가 있는지만 봤다고요. 그 쿠키가 진짜인지, 누구 것인지는 안 봤다고요.

오늘 그 자리를 채웁니다.

💡 오늘 수업의 핵심 — "서버만 아는 열쇠로 서명한 쿠키라야 신원입니다"

🎯 학습 목표

• 지금 우리 로그인이 왜 로그인이 아닌지를 직접 위조해보고 확인합니다.
• 인증 서버를 앱 안에 세우고, 비밀번호를 진짜로 확인하게 만듭니다.
• 서명된 세션 쿠키가 위조를 어떻게 막는지 눈으로 확인합니다.

Step 1: "버튼 하나로 남이 됩니다"

지금 우리 머리말에는 버튼이 두 개 있습니다. "재훈으로 보기"와 "민지로 보기" 요.

D-7에서 이 버튼을 만들 때 제가 가짜라고 말씀드렸어요. 눌러보면 무슨 일이 벌어지는지 다시 봅시다.

// apps/web-next/app/actions/session.ts  (지금 상태)
export async function signIn(formData: FormData) {
  const username = formData.get('username');

  if (typeof username !== 'string' || username === '') {
    return;
  }

  (await cookies()).set('me', username, {
    httpOnly: true,
    path: '/',
    maxAge: 60 * 60 * 24,
  });
}

버튼이 보낸 이름을 그대로 쿠키에 적습니다. 확인하는 줄이 한 줄도 없어요.

문지기는 무엇을 보고 있나

D-8에서 만든 문지기를 다시 읽어봅시다.

// apps/web-next/proxy.ts  (지금 상태)
if (request.cookies.get('me') === undefined) {
  return NextResponse.redirect(new URL('/', request.url));
}

undefined인지만 봅니다. 값이 무엇인지는 안 봐요. 그래서 이렇게 됩니다.

  쿠키 없음        → 307   (막힌다)
  me=jaehoon      → 200
  me=minji        → 200
  me=nobody       → 200    없는 사람인데 통과
  me=             → 200    빈 값도 통과

마지막 두 줄이 중요합니다. nobody라는 사람은 우리 데이터 어디에도 없어요. 빈 문자열은 아예 이름도 아니고요. 그런데 둘 다 들어와집니다.

화면은 그 값을 그대로 믿습니다

머리말은 쿠키에 적힌 글자를 그대로 이름으로 씁니다.

  me=jaehoon  →  @jaehoon
  me=minji    →  @minji
  me=nobody   →  @nobody

그리고 행동까지 됩니다

여기가 진짜 문제예요. 위조한 쿠키로 민지의 프로필을 열면 팔로우 폼이 통째로 옵니다. 그 폼을 그대로 제출해봤더니, 백엔드 로그에 이렇게 찍혔습니다.

  [api-stub] POST /api/users/minji/follow

요청이 서버까지 갔어요. 우리 앱은 이 요청을 막을 근거를 하나도 갖고 있지 않습니다.

다만 여기서 한 번 걸립니다. 우리 연습용 백엔드는 요청에 실려온 이름이 계정 목록에 있는지를 봐요.

  X-Actor: nobody     → 401
  X-Actor: seungwoo   → 401     게시물은 있지만 로그인 계정이 아니다
  X-Actor: jaehoon    → 200     팔로워 8500 → 8501

세 번째 줄을 보세요. 실존하는 계정 이름으로 위조하면 그대로 통과합니다. 백엔드가 한 것은 "그 이름이 목록에 있나"를 확인한 것뿐이에요. 비밀번호도 서명도 안 봤습니다.

즉 지금 우리 앱과 백엔드 어디에도 신원을 확인하는 곳이 없습니다.

무엇이 없는 걸까요

두 가지가 없습니다.

 없는 것 1   비밀번호
             본인만 아는 것을 물어본 적이 없다

 없는 것 2   서명
             쿠키에 적힌 값을 우리가 발급했다는 증거가 없다

오늘 이 둘을 채웁니다. Step 3이 첫 번째, Step 4가 두 번째예요.

💡 한 줄 정리

지금 우리 로그인은 이름을 적어내면 그 사람이 되는 방식이고, 문지기는 그 종이가 있는지만 봅니다.

Step 2: "인증 서버를 앱 안에 세웁니다"

여기서 도구를 하나 들이는데, 그 전에 이름 이야기를 먼저 해야 해요.

검색하면 다른 이름이 나올 겁니다

"Next.js 인증"으로 검색하면 대부분 NextAuth라는 이름이 나옵니다. 나중에 Auth.js로 이름을 바꿨고, 자료가 굉장히 많아요.

그 프로젝트는 지금 Better Auth라는 프로젝트의 일부가 됐습니다. 공식 문서 맨 위에 그렇게 적혀 있고, 새 프로젝트를 시작한다면 Better Auth를 쓰라고 안내하고 있어요. NextAuth 쪽은 보안 문제만 고쳐주는 상태로 남아서 우리는 Better Auth를 쓰는데, 검색으로 만날 예제의 절반 이상은 아직 NextAuth로 되어 있을 거예요. 그 이름이 보이면 옛 자료라고 생각하시면 됩니다.

이런 일이 처음은 아니죠. C-1에서 라우터 패키지 이름이 바뀐 것을, D-2에서 주소 관련 훅을 가져오는 곳이 바뀐 것을 이미 겪었습니다. 프론트엔드에서는 검색 결과가 옛것인지 아닌지를 가려내는 것 자체가 일입니다.

설정 파일 하나

npm install better-auth --workspace apps/web-next

// apps/web-next/lib/auth.ts
import { betterAuth } from 'better-auth';
import { memoryAdapter } from 'better-auth/adapters/memory';

// 사람과 세션을 담아둘 곳. 지금은 서버 메모리라 서버를 끄면 사라진다.
// 표(배열)를 미리 만들어 둬야 한다 — 빈 객체를 주면 "Model user not found" 로 죽는다.
const db = { user: [], session: [], account: [], verification: [] };

export const auth = betterAuth({
  database: memoryAdapter(db),
  // 아이디와 비밀번호로 로그인하겠다는 선언.
  emailAndPassword: { enabled: true },
});

사람과 세션을 어딘가에는 담아야 합니다. 진짜 서비스라면 데이터베이스를 연결해요. 우리는 강의라서 서버 메모리에 담습니다. 서버를 끄면 다 사라지고요.

주석에 적어둔 것을 한 번 겪어보시면 좋습니다. const db = {}로 두면 빌드도 통과하고 서버도 뜨는데, 로그인을 시도하는 순간 500이 나요. 서버 로그에 이렇게 찍힙니다.

  [MemoryAdapter] Model user not found in the DB []

담을 칸을 안 만들어놓은 겁니다.

주소를 여는 파일

// apps/web-next/app/api/auth/[...all]/route.ts
import { auth } from '@/lib/auth';
import { toNextJsHandler } from 'better-auth/next-js';

// 주소 하나가 아니라 /api/auth 아래 전부를 이 파일이 받는다.
export const { GET, POST } = toNextJsHandler(auth);

폴더 이름이 [...all]입니다. D-1에서 [username]을 배웠죠. 대괄호 하나는 칸 하나였는데, 점 세 개가 붙으면 그 아래 전부를 받습니다.

빌드해보면 라우트 표에 한 줄이 늘어요.

  ƒ /api/auth/[...all]

나머지 줄은 그대로입니다. D-5·D-6에서 정한 캐시 설정과 부딪히지 않아요.

한 줄로 여러 주소가 생깁니다

이 파일 하나가 무엇을 열었는지 직접 두드려봤습니다.

  GET  /api/auth/ok             → 200  {"ok":true}
  GET  /api/auth/get-session    → 200  null
  POST /api/auth/sign-up/email  → 400  (본문이 비어서)
  POST /api/auth/sign-in/email  → 400
  POST /api/auth/sign-out       → 200

우리가 만든 것은 파일 하나인데 주소는 여러 개가 생겼습니다.

한 가지 짚고 갈 것이 있어요. POST로만 여는 주소에 GET을 보내면 404가 옵니다.

  GET /api/auth/sign-up/email   → 404

D-7에서 우리가 손으로 만든 Route Handler는 같은 상황에서 405를 줬어요. 그때 우리가 POST만 내보냈기 때문이었죠. 여기는 라이브러리가 정한 방식이라 404입니다. 없는 주소로 취급하느냐, 있는데 방법이 틀렸다고 알려주느냐는 만든 쪽이 정합니다.

💡 한 줄 정리

파일 두 개로 인증 서버가 앱 안에 생겼고, [...all] 덕분에 주소 하나가 여러 엔드포인트를 받습니다.

Step 3: "비밀번호를 진짜로 묻습니다"

여기서 없던 것 첫 번째를 채웁니다.

우리 앱은 이메일로 사람을 안 부릅니다

Better Auth의 기본은 이메일과 비밀번호인데, 우리 인스타그램 클론은 @jaehoon처럼 아이디로 사람을 부르고 주소도 /jaehoon이라서 아이디 로그인을 얹어줄 것을 하나 붙입니다.

// apps/web-next/lib/auth.ts
export const auth = betterAuth({
  database: memoryAdapter(db),
  // 비밀번호로 로그인하겠다는 선언.
  emailAndPassword: { enabled: true },
  // 우리 앱은 이메일이 아니라 @jaehoon 같은 아이디로 사람을 부른다.
  plugins: [username()],
});

이 한 줄이 sign-in/username이라는 주소를 새로 엽니다.

계정을 심어둡니다

저장소가 메모리라서 서버를 켤 때마다 비어 있어요. 실습을 하려면 계정이 있어야 하니 둘을 심어둡니다.

// apps/web-next/lib/auth.ts
// 강의용 씨앗 계정. 저장소가 메모리라 서버를 켤 때마다 새로 심는다.
// 진짜 서비스라면 가입 화면이 이 일을 한다.
const DEMO_USERS = [
  { username: 'jaehoon', name: '재훈', password: 'hunter22!' },
  { username: 'minji', name: '민지', password: 'hunter22!' },
];

진짜 서비스라면 가입 화면이 이 일을 합니다. 우리는 가입 화면을 만들지 않으니 서버가 켜질 때 대신 심어요.

그런데 여기에 함정이 하나 있었습니다

심는 것은 시간이 걸리는 일입니다. 서버를 켜자마자 로그인을 시도하면 아직 안 심겼을 수 있어요. 실제로 그랬습니다.

  기동 직후 첫 로그인   → 401
  두 번째부터          → 200

서버 로그에는 User not found가 한 번 찍히고요. 두 번째부터 되기 때문에 눈치채기가 어렵습니다. 새로고침 한 번 하면 되기 때문에, 주소를 받는 파일이 심는 것을 기다렸다가 넘기게 했습니다.

// apps/web-next/app/api/auth/[...all]/route.ts
const handlers = toNextJsHandler(auth);

// 씨앗 계정을 심는 동안 로그인 요청이 먼저 도착하면 "그런 사람 없다" 가 된다.
// 서버를 켠 직후 딱 한 번 벌어지는 일이라 눈치채기 어렵다. 심는 것을 기다렸다 넘긴다.
export async function GET(request: Request) {
  await demoUsersReady;
  return handlers.GET(request);
}

export async function POST(request: Request) {
  await demoUsersReady;
  return handlers.POST(request);
}

Step 2에서 한 줄이었던 파일이 늘어났죠. 대신 기동 직후 첫 요청부터 200이 나옵니다.

이제 비밀번호를 확인합니다

  {"username":"jaehoon","password":"hunter22!"}   → 200
  {"username":"jaehoon","password":"wrong"}       → 401
  {"username":"nobody","password":"hunter22!"}    → 401

두 번째와 세 번째를 보세요. 응답이 완전히 같습니다.

  {"message":"Invalid username or password","code":"INVALID_USERNAME_OR_PASSWORD"}

비밀번호가 틀린 건지, 그런 아이디가 없는 건지 안 알려줘요. 일부러 그렇게 만든 겁니다.

만약 "그런 아이디는 없습니다"라고 알려주면, 공격자는 아이디를 하나씩 넣어보면서 어떤 아이디가 존재하는지를 알아낼 수 있어요. 그것만으로도 이미 정보가 새는 겁니다.

Step 1에서 우리 연습용 백엔드는 X-Actor: nobody에 "로그인이 필요합니다"라고 답했고, 없는 프로필에는 "그런 사람이 없습니다"라고 404를 줬죠. 그건 프로필 조회라 공개 정보지만, 로그인 창에서는 이야기가 다릅니다.

⚠️ 한글 아이디는 기본값으로 막힙니다

우리 학생들이 반드시 밟는 곳이라 미리 말씀드릴게요.

  aa         → USERNAME_TOO_SHORT
  jae_hoon   → 통과            (밑줄은 된다)
  jae hoon   → INVALID_USERNAME  (공백)
  재훈        → USERNAME_TOO_SHORT
  재훈이       → INVALID_USERNAME

마지막 두 줄이 눈에 띄죠. 재훈은 두 글자라 길이에서 먼저 걸리고, 재훈이는 세 글자인데도 막힙니다. 기본 검사가 영문자·숫자·밑줄만 받기 때문이에요.

한글 아이디를 받고 싶으면 검사 규칙을 직접 주면 되는데, 그 전에 한 번 생각해볼 것이 있어요. 아이디가 주소에 들어가는 앱이라면(/재훈이) 주소 인코딩까지 함께 따라옵니다.

비밀번호도 검사합니다. 1234는 PASSWORD_TOO_SHORT로 거절돼요.

💡 한 줄 정리

아이디로 로그인하는 주소가 열렸고, 비밀번호가 틀렸을 때와 아이디가 없을 때가 같은 답으로 돌아옵니다.

Step 4: "쿠키에 서명이 붙습니다"

없던 것 두 번째입니다. 오늘의 중심이에요.

로그인이 성공하면 응답에 쿠키가 실려옵니다. 그 쿠키를 뜯어봅시다.

  set-cookie: better-auth.session_token=X7jr4eHKzjwGl72zsY5VLIkcksGcrBX7.t42blc8wvTOV8yS80mSbcUtl14pSNlT8z0MLy6LxVi4%3D;
              Max-Age=604800; Path=/; HttpOnly; SameSite=Lax

길지만 구조는 단순합니다. 가운데 점을 기준으로 두 조각이에요.

 X7jr4eHKzjwGl72zsY5VLIkcksGcrBX7 . t42blc8wvTOV8yS80mSbcUtl14pSNlT8z0MLy6LxVi4%3D
 └────────── token 32 ──────────┘ . └─────────────── signature 46 ───────────────┘

앞쪽 32자가 세션을 가리키는 번호표입니다. 뒤쪽 46자가 오늘의 주인공이에요. 서버만 아는 열쇠로 앞쪽을 계산해서 만든 값입니다.

끝의 %3D는 =를 주소에 실을 수 있게 바꿔 적은 것이라 서명의 일부입니다.

왜 이게 위조를 막을까요

D-8의 쿠키와 비교해보면 분명해집니다.

 D-8         me=jaehoon
             누구나 적을 수 있다. 우리가 발급했다는 증거가 없다.

 오늘        better-auth.session_token=<토큰>.<서명>
             서명은 서버만 아는 열쇠가 있어야 만들 수 있다.

값을 고치면 서명이 안 맞고, 서명을 맞추려면 열쇠가 필요합니다.

직접 위조해봤습니다

말로만 하면 안 되니 실제로 해봤어요. 다섯 가지를 보냈습니다. 첫 줄은 대조군입니다. 진짜 쿠키가 통과하는지부터 봐야 나머지 결과가 의미를 가져요.

  진짜 (대조군)              → 세션이 돌아온다
  쓰레기 값                  → null
  서명을 떼어냄               → null
  토큰은 진짜 + 서명만 위조     → null
  서명은 진짜 + 토큰만 바꿈     → null

세 번째부터 다섯 번째가 핵심입니다. 절반이 진짜여도 안 통해요. 토큰과 서명은 짝이라서 둘이 같이 맞아야 합니다.

쿠키에 붙은 나머지 표시들

  HttpOnly        페이지의 자바스크립트가 못 읽는다
  SameSite=Lax    다른 사이트에서 우리 앱으로 보내는 요청에는 잘 안 딸려간다
  Path=/          앱 전체 주소에서 보낸다
  Max-Age=604800  7일 (60×60×24×7)

Max-Age를 보세요. 7일입니다. 새로고침해도 로그인이 안 풀리는 이유가 여기 있어요. 브라우저를 껐다 켜도 7일 동안은 이 쿠키가 남아 있습니다.

SameSite=Lax는 다른 사이트가 우리 앱에 요청을 보내도록 유도했을 때 쿠키가 딸려가는 것을 줄여줍니다. 이 이야기는 커리큘럼의 보안 시간에서 제대로 다뤄요.

💡 한 줄 정리

세션 쿠키는 번호표와 서명의 짝이고, 서버만 아는 열쇠가 있어야 그 짝을 만들 수 있습니다.

Step 5: "기본 시크릿의 값"

서명을 만들려면 열쇠가 있어야 한다고 했죠. 그 열쇠를 우리가 준 적이 없습니다. 그런데 지금까지 잘 돌아갔어요. 왜일까요.

라이브러리가 기본값을 갖고 있기 때문입니다. 그 값을 찾아봤어요.

  better-auth-secret-12345678901234567890

이게 전부인데, 이 문자열은 여러분이 설치한 패키지 안에 그대로 들어 있어서 누구나 아는 값입니다.

누구나 아는 열쇠로 서명하면 어떻게 될까요. 누구나 서명을 만들 수 있습니다. Step 4에서 막았던 위조가 다시 뚫려요.

라이브러리는 막으려고 합니다

라이브러리 코드를 열어보면 이렇게 되어 있습니다.

  if (isDefaultSecret && isProduction)
    throw new BetterAuthError("You are using the default secret. ...")

기본 열쇠를 쓰면서 프로덕션이면 던집니다. 개발 중에는 안 던져요. 그래서 지금까지 우리가 못 느꼈던 겁니다.

그런데 빌드는 통과합니다

프로덕션으로 빌드해봤습니다.

  next build   →  종료 코드 0

통과했어요. 그리고 배포한 다음 열어보면 이렇게 됩니다.

  GET  /                        → 200    화면이 다 뜬다
  GET  /explore                 → 200
  GET  /jaehoon                 → 200
  GET  /api/auth/ok             → 500
  POST /api/auth/sign-in/...    → 500    로그인만 죽는다

모든 화면이 멀쩡한데 로그인만 안 됩니다. 빌드가 통과했으니 배포까지 갔고, 사용자가 로그인을 눌러야 드러나요. D-6에서 겪었던 "통과했는데 틀린 것"과 같은 종류입니다.

⚠️ 우리가 쓴 한 줄이 경고를 삼켰습니다

여기서 재미있는 것을 발견했어요. 라이브러리는 사실 빌드할 때도 알려주려고 합니다. 그런데 우리 빌드 출력에는 그 메시지가 없었어요.

Step 3에서 계정을 심는 코드를 다시 보세요.

// apps/web-next/lib/auth.ts
auth.api.signUpEmail({ /* ... */ }).catch(() => undefined)

마지막의 .catch(() => undefined)요. 이미 있는 계정을 또 심으려 할 때 나는 오류를 무시하려고 붙인 건데, 이 한 줄이 열쇠 경고까지 같이 삼켰어요.

확인해봤습니다.

  .catch 있음   →  빌드 출력에 BetterAuthError  0건
  .catch 없음   →  빌드 출력에 BetterAuthError  1건

두 경우 다 빌드 종료 코드는 0입니다. 삼키지 않았어도 빌드는 통과했겠지만, 화면에 한 번은 보였을 기회를 우리가 없앤 셈입니다.

넓게 잡은 catch가 무엇을 삼키는지는 이렇게 나중에야 드러납니다.

열쇠를 줍니다

openssl rand -base64 32

이 명령이 아무나 못 맞출 값을 만들어줍니다. 그 값을 .env.local에 넣어요.

BETTER_AUTH_SECRET=여기에-방금-만든-값
BETTER_AUTH_URL=http://localhost:3000

두 번째 줄도 함께 넣습니다. 이게 없으면 서버가 시작할 때 자기 주소를 모른다고 경고를 내요.

이제 다시 재보면 이렇습니다.

  GET  /api/auth/ok             → 200
  POST /api/auth/sign-in/...    → 200
  서버 로그의 오류               → 0건

🌟 이 열쇠는 브라우저로 안 갑니다

D-10에서 환경 변수 이야기를 했었죠. 이름 앞에 NEXT_PUBLIC_이 붙으면 브라우저가 받아가는 파일에 그 값이 그대로 박힌다고요.

BETTER_AUTH_SECRET에는 그게 안 붙어 있어서 서버에서만 읽혀요. 여기에 NEXT_PUBLIC_을 붙이면 서명 열쇠를 전 세계에 공개하는 셈이 되고, .env.local 파일 자체도 저장소에 안 올라갑니다. .gitignore에 이미 들어 있어요. 대신 무엇이 필요한지는 알려줘야 하니 예시 파일을 하나 남겨둡니다.

// apps/web-next/.env.example
# 세션 쿠키에 붙는 서명을 만드는 열쇠. 서버만 알아야 한다.
# 이 파일을 .env.local 로 복사한 뒤 아래 값을 직접 만든 것으로 바꾼다.
#   openssl rand -base64 32
BETTER_AUTH_SECRET=여기에-직접-만든-값을-넣으세요

값은 안 들어 있고 이름만 들어 있습니다. 새로 온 사람이 무엇을 채워야 하는지 알 수 있고, 열쇠는 새지 않아요.

💡 한 줄 정리

서명 열쇠의 기본값은 누구나 아는 문자열이고, 그것을 안 바꾸면 빌드는 통과하지만 배포된 앱에서 로그인만 죽습니다.

Step 6: "화면을 진짜 로그인 폼으로"

마지막으로 화면을 바꿉니다.

폼을 만듭니다

두 개의 버튼을 아이디와 비밀번호 칸으로 바꿉니다.

// apps/web-next/app/components/SignInFields.tsx
'use client';

const initial: SignInState = { message: null };

export function SignInFields() {
  const [state, formAction] = useActionState(signIn, initial);

  return (
    <form action={formAction} className="ml-2 flex items-center gap-2">
      <input name="username" aria-label="아이디" placeholder="아이디" autoComplete="username" />
      <input name="password" type="password" aria-label="비밀번호" autoComplete="current-password" />
      <SubmitButton pendingLabel="확인 중…">로그인</SubmitButton>
      {state.message !== null && (
        <p aria-live="polite" className="text-black/60">
          {state.message}
        </p>
      )}
    </form>
  );
}

D-7에서 배운 useActionState와 D-8의 SubmitButton을 그대로 씁니다. 새로 배우는 것은 없어요.

받는 쪽은 이렇습니다.

// apps/web-next/app/actions/session.ts
export async function signIn(previous: SignInState, formData: FormData): Promise<SignInState> {
  const username = formData.get('username');
  const password = formData.get('password');

  if (typeof username !== 'string' || typeof password !== 'string') {
    return { message: '아이디와 비밀번호를 입력해주세요' };
  }

  try {
    // 성공하면 서명된 세션 쿠키가 응답에 실린다.
    await auth.api.signInUsername({ body: { username, password } });
  } catch (error) {
    // 아이디가 없을 때와 비밀번호가 틀릴 때가 같은 답이다.
    // 어느 쪽인지 알려주면 "이 아이디는 있다" 는 것을 알려주는 셈이 된다.
    if (error instanceof APIError) {
      return { message: '아이디 또는 비밀번호가 올바르지 않아요' };
    }
    throw error;
  }

  return { message: null };
}

비밀번호는 이 함수 안에서만 다뤄집니다. 몸통이 서버에서만 도니까요.

액션이 심은 쿠키가 응답에 실리려면 설정에 한 줄이 더 필요합니다.

// apps/web-next/lib/auth.ts
  plugins: [
    // 우리 앱은 이메일이 아니라 @jaehoon 같은 아이디로 사람을 부른다.
    username(),
    // 액션이 심은 쿠키를 응답에 실어준다. 반드시 마지막에 둔다.
    nextCookies(),
  ],

🌟 이 폼은 자바스크립트 없이도 제출됩니다

렌더된 결과를 보면 평범한 HTML 폼이에요.

  <form action="" encType="multipart/form-data" method="POST">

그런데 같은 화면의 좋아요 버튼은 이렇게 되어 있습니다.

  <form action="javascript:throw new Error('React form unexpectedly submitted.')">

D-8에서 봤던 그 모습이죠. 낙관적 업데이트를 붙이려고 액션을 클라이언트 함수로 감쌌기 때문에 자바스크립트 전용이 된 겁니다.

한 화면에 두 형태가 나란히 있어요. 서버 함수를 useActionState에 그대로 건네면 평범한 폼으로 남고, 클라이언트 함수로 감싸면 자바스크립트가 있어야 동작합니다. 로그인은 화면이 뜨자마자 누를 수 있어야 하니 앞쪽이 맞습니다.

화면이 세션을 읽습니다

// apps/web-next/app/components/SignInForm.tsx
// 지시어가 없다. 서버 컴포넌트다 — 세션을 서버에서 직접 확인한다.
export async function SignInForm() {
  const session = await auth.api.getSession({ headers: await headers() });

  if (session !== null) {
    return (
      <form action={signOut} className="ml-2 flex items-center gap-2">
        <span className="text-black/60">@{session.user.username}</span>
        <button type="submit">나가기</button>
      </form>
    );
  }

  return <SignInFields />;
}

⚠️ 여기서 이상한 일이 벌어졌습니다

이 상태로 로그인을 해봤어요. 응답은 200이고 쿠키도 왔습니다. 그런데 머리말은 여전히 로그인 폼이었어요.

주소로 직접 물어보면 세션이 있다고 나옵니다.

  GET /api/auth/get-session   →  세션이 돌아온다
  화면의 SignInForm 안에서     →  null

같은 요청, 같은 쿠키인데 답이 다릅니다. 쿠키가 화면 쪽까지 잘 도착하는지부터 찍어봤어요. 잘 도착하고 있어서, 저장소를 의심했습니다. 설정 파일에 표식을 하나 심어서, 이 파일이 몇 번 만들어지는지 찍어봤어요.

  lib/auth.ts 인스턴스  ebra71
  lib/auth.ts 인스턴스  aykips
  lib/auth.ts 인스턴스  3yujz3

세 개입니다. Next는 이 파일을 한 번만 읽지 않아요. 화면이 쓰는 것과 주소가 쓰는 것이 따로 만들어집니다. 우리 저장소는 파일 안의 변수라서, 만들어질 때마다 빈 저장소가 새로 하나씩 생긴 거예요.

주소 쪽에서 로그인해서 만든 세션은 주소 쪽 저장소에 있고, 화면 쪽 저장소는 그것을 모릅니다.

저장소를 한 곳에 매답니다

// apps/web-next/lib/auth.ts
// globalThis 에 매다는 이유: Next 는 이 파일을 한 번만 읽지 않는다.
// 화면이 쓰는 것과 주소가 쓰는 것이 따로 만들어져서, 그냥 두면 저장소가 둘이 된다.
// 그러면 로그인은 됐는데 화면은 모르는 상태가 된다.
const store = globalThis as typeof globalThis & { __authDb?: AuthDb };
type AuthDb = { user: unknown[]; session: unknown[]; account: unknown[]; verification: unknown[] };

const db = (store.__authDb ??= { user: [], session: [], account: [], verification: [] });

globalThis는 어디서 접근하든 같은 하나입니다. 여기에 매달아두면 파일이 몇 번 만들어져도 저장소는 하나예요. ??=는 이미 있으면 그대로 쓰고 없을 때만 만듭니다.

되돌려서도 확인했습니다. 이 줄을 빼고 프로덕션으로 빌드해서 띄우면 머리말이 다시 로그인 폼으로 돌아가요. 개발 서버만의 문제가 아닙니다.

신원을 얻는 함수도 바꿉니다

D-8에서 신원을 얻는 곳을 한 곳으로 모아뒀죠. 그 안쪽만 바꿉니다.

// apps/web-next/lib/session.ts
export async function currentUser(): Promise<string | null> {
  const session = await auth.api.getSession({ headers: await headers() });
  return session?.user.username ?? null;
}

app/actions/follow.ts와 app/actions/like.ts는 한 글자도 안 고쳤습니다. D-8에서 이렇게 될 거라고 말씀드렸던 것이 그대로 됐어요.

문지기도 한 줄만 바꿉니다.

// apps/web-next/proxy.ts
// 세션 쿠키가 있는지만 본다 — 진짜인지는 화면과 액션이 각자 확인한다.
if (getSessionCookie(request) === null) {
  return NextResponse.redirect(new URL('/', request.url));
}

여기서 세션이 진짜인지까지 확인하지 않는 이유는 다음 시간에 제대로 다룹니다. D-8에서 우리가 속도 때문에 내렸던 결정과 이어져요.

오늘의 결과

전부 바꾼 다음 다시 재봤습니다.

  로그아웃 상태 머리말   아이디·비밀번호 칸과 로그인 버튼
  로그인 뒤 머리말      @jaehoon 과 나가기

  /jaehoon  (세션 있음)  → 200
  /zzzzz    (세션 있음)  → 404
  me=jaehoon            → 307
  me=nobody             → 307
  (쿠키 없음)            → 307

아래 세 줄이 오늘의 답입니다. 오프닝에서 통과했던 위조가 전부 막혔어요. /zzzzz가 여전히 404인 것도 함께 봐주세요. D-7에서 첫 바이트 405ms 를 내주고 되찾았던 그 404입니다. 인증을 갈아 끼우면서도 안 잃었어요.

팔로우도 확인했습니다. 새 세션으로 민지를 팔로우하니 팔로워가 8500에서 8501로 올라갔습니다. 액션 코드는 안 고쳤는데도요.

💡 한 줄 정리

로그인 폼과 세션이 이어졌고, 신원을 얻는 함수 하나를 바꾸자 액션들이 저절로 따라왔습니다.

마무리

오늘은 쿠키 하나를 손으로 만들어서 남이 되어보는 것으로 시작했고, 그게 왜 됐는지 무엇을 채워야 안 되는지를 하나씩 붙였어요.

 Step 1    위조가 그냥 된다              무엇이 없는지 확인
 Step 2    인증 서버를 앱 안에 세운다
 Step 3    비밀번호를 진짜로 묻는다        없던 것 첫 번째
 Step 4    쿠키에 서명이 붙는다           없던 것 두 번째
 Step 5    그 서명의 열쇠를 우리 것으로
 Step 6    화면과 신원을 세션에 잇는다

오늘 배운 핵심 세 가지

💡 하나 — 신원은 값이 아니라 증거입니다. me=jaehoon은 누구나 적을 수 있는 글자였고, 서명된 세션 쿠키는 서버만 아는 열쇠가 있어야 만들 수 있는 짝입니다. 절반이 진짜여도 안 통한다는 것을 네 가지 위조로 확인했어요.

💡 둘 — 기본값은 비밀이 아닙니다. 서명 열쇠의 기본값은 패키지 안에 그대로 들어 있는 공개된 문자열이에요. 빌드는 통과하고 화면도 다 뜨는데 로그인만 죽는 모습으로 드러납니다.

💡 셋 — 신원을 얻는 곳이 하나여서 갈아 끼울 수 있었습니다. D-8에서 currentUser()로 모아둔 덕분에 오늘 그 안쪽만 바꿨고, 액션 두 개는 손대지 않았어요.

다음 시간 예고

오늘 로그인은 만들었는데, 아직 이야기가 끝나지 않은 것이 몇 개 남아 있습니다.

문지기부터요. 오늘 우리는 문지기에게 "세션 쿠키가 있는지"만 보게 했어요. Step 4에서 그 쿠키가 진짜인지 아닌지를 그렇게 열심히 확인해놓고, 정작 문지기는 존재만 봅니다. 이상하게 들리시죠. 여기에는 이유가 있고, 그 이유가 D-8에서 우리가 속도 때문에 내렸던 결정과 정확히 이어집니다. 로그인이 막아 세운 사람을 어디로 보낼지도 남았어요. 지금은 /minji를 열려던 사람도 로그인 후에 홈에 남습니다. 원래 가려던 곳으로 보내주는 것이 맞겠죠.

여기까지가 다음 시간입니다. 문 앞에서 누구를 들여보내고 어디로 보낼 것인가요.

그다음 시간에는 신원을 들고 다니는 이야기로 넘어갑니다. Step 4의 🙋 에서 잠깐 미뤄뒀던 것이 거기서 나와요. 세션을 번호표로 들 것이냐, 쿠키 안에 정보를 담을 것이냐요. 둘을 나란히 놓고 고릅니다. 가장 큰 것은 마지막에 남았는데, 우리 앱에는 지금 신원이 두 개 있습니다. 오늘 만든 세션이 하나고, C-6에서 백엔드로부터 받아오던 토큰이 다른 하나예요. 화면을 그리는 서버는 오늘 만든 것을 알고, 인스타그램 데이터를 들고 있는 백엔드는 그것을 모릅니다.

그 둘을 화해시키는 것으로 인증 이야기를 닫습니다.

과제

[구현] 가입 화면 만들기

Step 3에서 계정 둘을 코드로 심으면서 "진짜 서비스라면 가입 화면이 이 일을 한다" 고 했죠. 그 화면을 만들어봅시다.

/signup 주소를 새로 만들고, 아이디·비밀번호를 받아 계정을 만드는 폼을 놓으세요. 계정을 만드는 일은 auth.api.signUpEmail이 합니다. 로그인 액션과 모양이 거의 같아요.

만들고 나면 Step 3에서 표로만 봤던 규칙들이 화면에서 그대로 드러납니다. 두 글자 아이디, 한글 아이디, 짧은 비밀번호를 각각 넣어보고 무엇이 어떻게 거절되는지 확인하고, 하나 더 살펴보세요. /signup은 로그인 안 한 사람이 가야 하는 주소인데, 페이지를 만들자마자 열어보면 아마 화면이 안 나올 거예요.

로그아웃 상태로 한 번, 로그인 상태로 한 번 열어보세요. 두 경우의 응답이 서로 다릅니다. 각각 왜 그렇게 나오는지를 proxy.ts를 읽고 설명해보세요. 로그인 상태에서 나오는 쪽은 D-7에서 우리가 공들여 만든 것이 엉뚱하게 동작한 결과입니다.

고치는 것까지 해보시면 더 좋은데, matcher를 건드릴지 함수 안에서 거를지는 선택이에요. D-8에서 문지기의 검사 순서를 정할 때 했던 이야기를 떠올려보세요.

[구현] 로그인 실패 횟수를 세어 잠그기

같은 아이디로 비밀번호를 여러 번 틀리면 잠시 잠기게 만들어보세요. Better Auth가 이 기능을 갖고 있진 않으니, signIn 액션 안에서 직접 세면 됩니다.

세는 값을 어디에 둘지가 이 과제의 핵심입니다. 컴포넌트 안에 두면 안 되는 이유부터 생각해보세요.

그다음이 재미있는 부분이에요. Step 6에서 우리는 저장소를 파일 안 변수에 뒀다가 그게 여러 개가 되는 일을 겪었는데, 이 횟수도 그렇게 될지 한번 생각해보세요.

추측하지 말고 확인해보세요. 파일 안 변수로 먼저 만들고, 그 변수가 몇 번 만들어지는지 표식을 심어서 찍어보면 됩니다. Step 6에서 제가 했던 방법 그대로요. 결과가 Step 6과 같은지 다른지 보고, 다르다면 무엇이 그 차이를 만드는지 설명해보세요.

잠긴 동안의 메시지도 정해야 해요. "5번 틀려서 잠겼습니다"라고 알려주는 것과 그냥 "아이디 또는 비밀번호가 올바르지 않아요"를 유지하는 것 중 어느 쪽이 나을까요. Step 3에서 같은 답을 준 이유를 떠올려보세요.

[탐구] 기기 두 대로 로그인한 뒤 한쪽만 나가보기

같은 계정으로 두 번 로그인해보세요. 브라우저 두 개를 써도 되고, 요청 도구로 쿠키를 따로 받아도 됩니다.

먼저 두 쪽이 받은 쿠키를 비교해보세요. 같은가요, 다른가요. 그다음 한쪽에서만 로그아웃하고, 두 쪽이 각각 어떻게 되는지 확인하세요.

여기서 두 가지를 알 수 있습니다. 하나는 세션이 계정 단위가 아니라 무엇 단위로 만들어지는가이고, 다른 하나는 로그아웃이 브라우저에서 쿠키를 지우는 일인지 서버에서 무언가를 지우는 일인지입니다.

⚠️ 요청 도구로 로그아웃을 직접 불러보면 아마 막힐 거예요. 그때 돌아오는 상태 코드를 보고, 무엇을 확인해서 막은 것인지 찾아보세요. 브라우저에서는 안 막히는데 도구에서만 막히는 이유가 답입니다.

[탐구] 열쇠를 바꾸는 실험이 왜 아무것도 증명하지 못하는지 밝히기

로그인한 상태에서 .env.local의 BETTER_AUTH_SECRET을 다른 값으로 바꾸고 서버를 다시 띄우면, 예상대로 로그아웃됩니다. "역시 서명이 안 맞아서 그렇구나" 하고 넘어가기 쉬운 결과지만, 이 실험은 아무것도 증명하지 못합니다.

확인해보세요. 열쇠를 그대로 둔 채 서버만 다시 띄워도 결과가 같습니다. 왜 그런지 설명하고, 이 실험에서 한 번에 두 가지가 바뀌었다는 것을 짚은 뒤, 열쇠 때문이라는 것을 진짜로 보이려면 무엇이 달라져야 할지 설계해보세요. 우리 지금 설정으로 가능한 일인지도 함께 판단해보시고요.

생각해볼 주제

1. 왜 "아이디가 없습니다"라고 알려주면 안 될까요

Step 3에서 비밀번호가 틀렸을 때와 아이디가 없을 때가 같은 메시지로 돌아온다고 했습니다. 사용자 입장에서는 불친절해 보여요. 오타를 냈는지 비밀번호를 잊었는지 알려주면 훨씬 편할 텐데, 우리 앱의 다른 곳을 보면 이미 아이디의 존재 여부를 알려주고 있습니다. /jaehoon은 200이고 /zzzzz는 404 니까요. 프로필 주소만 봐도 그 사람이 있는지 알 수 있어요.

그렇다면 로그인 창에서만 감추는 것이 의미가 있을까요. 이 앱에서는 어떻게 정하는 것이 맞을까요.

2. 강의용 씨앗 계정은 실무에서 어떻게 바뀌어야 할까요

우리는 서버가 켜질 때 계정 두 개를 코드로 심었습니다. 비밀번호도 코드 안에 그대로 적혀 있고요.

실무에서 이런 코드가 배포본에 들어가면 어떤 일이 벌어질지, 그리고 초기 관리자 계정처럼 처음 한 번은 누군가 만들어야 하는 계정은 실제로 어떻게 만들지 생각해보세요.

Step 5에서 열쇠를 환경 변수로 뺐던 것과 같은 방법을 쓸 수 있을지, 아니면 다른 방법이 필요할지 생각해보세요.

3. 신원이 두 개인 앱을 어떻게 정리할까요

다음 시간 예고에서 말씀드린 것을 미리 생각해봅시다.

우리 앱에는 지금 신원이 두 개 있습니다. Next 서버가 아는 세션과, 백엔드가 발급하던 토큰이요. C-6에서 만든 SPA는 후자를 쓰고, 오늘 만든 Next 앱은 전자를 씁니다.

두 개를 하나로 만드는 방법이 여럿 있습니다. Next 서버가 세션을 확인한 뒤 백엔드에게 대신 물어봐 주는 방법도 있고, 백엔드를 신원의 주인으로 두고 Next 서버는 그냥 옮겨주기만 하는 방법도 있어요.

각각 무엇을 얻고 무엇을 잃는지, 그리고 브라우저가 백엔드를 직접 부르는 화면(우리 SPA)이 함께 있을 때는 어느 쪽이 나을지 생각해보세요.