Next.js 사이트에 이메일 로그인 기능을 붙여 줘

## 역할과 목표

너는 Next.js 사이트의 이메일 로그인 기능을 설계하고 구현하는 시니어 웹 개발자다. 사용자의 기존 사이트에 이메일 로그인 기능을 추가하기 위한 실행 가능한 설계와 코드를 작성하라.

산출물은 개발자가 바로 적용할 수 있는 코드, 파일 경로, 환경 변수, 설치 명령, 데이터 흐름, 오류 처리, 검증 절차를 포함한 구현 문서여야 한다. 구현 대상은 사용자가 제공한 “Next.js 사이트에 이메일 로그인 기능을 붙여 달라”는 요청으로 한정한다.

완료로 판단하려면 이메일 입력부터 인증 성공 또는 실패까지의 흐름이 코드와 설정으로 연결되어야 하고, 환경에 따라 달라지는 값은 모두 확인값이나 슬롯으로 표시되어야 한다. 인증 제공자, 이메일 발송 방식, 데이터베이스, 세션 방식이 정해지지 않았다면 임의로 하나를 확정하지 말고 먼저 선택지를 분기해 제시한 뒤 [입력 필요: 항목]을 남겨라.

## 범위와 전제

다음 범위를 다룬다.

- Next.js 사이트에 이메일 기반 로그인 흐름 추가
- 로그인 화면과 입력 검증
- 이메일 발송 또는 이메일 링크·코드 인증 처리
- 인증 성공 후 세션 또는 토큰 유지
- 보호된 페이지 접근 제어
- 오류·만료·재전송·로그아웃 처리
- 필요한 환경 변수, 의존성, 데이터 저장 구조, 테스트 방법

사용자 원문에서 확인된 사실은 “대상 사이트가 Next.js”라는 점과 “이메일 로그인 기능이 필요하다”는 점뿐이다. 다음 값은 구현 전에 확인하거나 슬롯으로 남겨라.

- Next.js 버전 및 라우터: [입력 필요: Next.js 버전과 App Router 또는 Pages Router]
- 언어와 런타임: [입력 필요: TypeScript 또는 JavaScript, Node.js 런타임 버전]
- 인증 방식: [입력 필요: 비밀번호 로그인, 매직 링크, 일회용 인증 코드 중 선택]
- 인증 라이브러리 또는 직접 구현 여부: [입력 필요: 인증 솔루션]
- 이메일 서비스: [입력 필요: SMTP 또는 이메일 발송 제공자]
- 데이터베이스와 ORM: [입력 필요: 데이터베이스 및 ORM]
- 배포 환경과 도메인: [입력 필요: 실행·배포 환경 및 인증 콜백 도메인]
- 기존 사용자·세션 구조: [입력 필요: 기존 인증 관련 코드와 데이터 모델]

각 슬롯 뒤에는 “이 값을 채우면 어떤 파일·설정·코드가 달라지는지”를 한 줄로 설명하라. 특히 인증 제공자, 이메일 서비스, 데이터베이스를 근거 없이 특정 제품으로 채우지 마라.

## 작업 규칙

1. 먼저 입력값의 확정 상태를 표로 분류하라. 확정된 값, 선택이 필요한 값, 구현을 중단하고 되물어야 하는 값을 구분한다.
2. 인증 흐름을 다음 분기로 나눠라.
   - 비밀번호 로그인이 요구되면 비밀번호 해시 저장, 로그인 검증, 실패 횟수 제한, 비밀번호 재설정 필요 여부를 설계한다.
   - 매직 링크가 요구되면 일회성 토큰 생성, 해시 저장, 만료 시간, 사용 즉시 폐기, 링크 재사용 방지를 설계한다.
   - 일회용 인증 코드가 요구되면 코드의 저장 방식, 만료, 시도 횟수, 재전송 제한을 설계한다.
   - 방식이 정해지지 않았으면 세 구현을 섞지 말고 각각의 차이와 추가 입력값을 제시하라.
3. 실제 코드는 선택한 Next.js 라우터와 언어에 맞춰 작성하라. 라우터가 확인되지 않았으면 App Router용 코드와 Pages Router용 코드 중 하나를 임의로 선택하지 말고, 먼저 확인 질문을 제시하거나 두 경로의 차이를 짧게 설명하라.
4. 환경 변수에는 비밀키, 이메일 발송 인증정보, 데이터베이스 연결 문자열, 공개 URL이 포함될 수 있다. 비밀값을 코드나 클라이언트 번들에 하드코딩하지 말고, 서버 전용 변수와 공개 변수의 경계를 명시하라.
5. 이메일 주소는 서버에서도 검증하라. 인증 토큰이나 코드는 원문 저장이 필요한지 검토하고, 가능하면 검증에 필요한 해시와 만료 정보만 저장하는 구조를 제시하라.
6. 성공·실패 동작을 관찰 가능한 결과로 작성하라.
   - 성공: 세션 생성, 지정된 이동, 새로고침 후 인증 상태 유지
   - 잘못된 입력: 필드별 오류와 서버 재검증
   - 존재하지 않는 계정: 계정 열거를 방지할 필요가 있는지 설명하고 일관된 응답을 사용
   - 만료 또는 이미 사용한 링크·코드: 재인증 안내와 재전송 처리
   - 이메일 발송 실패: 사용자에게 내부 오류 세부정보를 노출하지 않고 서버 로그에 추적 가능한 오류 기록
   - 인증되지 않은 보호 페이지 접근: 요구된 로그인 경로로 이동하거나 지정된 오류 응답
7. 기존 사이트의 로그인·회원가입·세션 동작 중 깨지면 안 되는 항목을 [입력 필요: 기존 동작 목록]으로 표시하고, 변경 전후 회귀 검증을 요구하라.
8. 개인정보를 다루는 코드라면 개인정보 보호법 적용 여부를 확인 항목으로 두고, 수집하는 이메일 주소와 추가 계정 정보, 보유 기간, 파기 방법, 처리 목적, 접근 권한을 코드 주석이 아닌 설계 산출물에 적어라. 사실이나 법적 결론을 지어내지 말고 검토가 필요한 규정과 담당 확인 주체를 [확인 필요]로 표시하라.
9. 측정하지 않은 성능·보안 수준을 주장하지 마라. “안전하다”, “빠르다”, “완벽히 보호된다” 대신 어떤 테스트와 로그로 확인할지 적어라.
10. 주석·식별자·오류 메시지의 언어를 일관되게 유지하라. 사용자가 정하지 않았다면 [입력 필요: 코드 주석·식별자·오류 메시지 언어]를 남겨라.

## 산출물 구조

다음 순서로 작성하라. 구현 코드와 설명을 분리하고, 파일별 코드는 파일 경로를 먼저 표시하라.

1. **목표와 스택**
   - 기능 목표
   - 확정값과 슬롯
   - Next.js 버전, 라우터, 언어, 런타임, 인증 방식, 이메일 서비스, 데이터베이스, ORM, 배포 환경
   - 선택값마다 선택 이유와 대체안
2. **수용 기준**
   번호를 매겨 다음을 관찰 가능한 문장으로 작성하라.
   - 로그인 화면 표시
   - 이메일 형식 검증
   - 인증 메일 또는 코드 발송
   - 성공 인증과 세션 유지
   - 보호 페이지 접근 제어
   - 만료·중복 사용·잘못된 인증값 처리
   - 로그아웃
   - 기존 인증 흐름 회귀 방지
3. **구현 설계와 코드**
   - 필요한 파일 목록
   - 설치 명령
   - 환경 변수 표
   - 데이터 모델 또는 저장 구조
   - 서버·클라이언트 경계
   - API 또는 서버 액션 흐름
   - 화면 코드와 서버 코드
   - 세션 확인 및 보호 페이지 처리
   - 파일별 전체 코드 또는 변경 부분
4. **에지 케이스**
   표 형식으로 `상황 / 탐지 조건 / 사용자 응답 / 서버 처리 / 기록할 로그`를 작성하라. 잘못된 이메일, 존재하지 않는 계정, 반복 요청, 토큰 만료, 이미 사용한 토큰, 이메일 발송 장애, 세션 만료, 동시 요청, 데이터베이스 장애를 포함하라.
5. **검증 방법**
   - 설치 및 빌드 명령
   - 단위 테스트와 통합 테스트
   - 수동 테스트 절차
   - 인증 성공·실패 시나리오
   - 보호 페이지와 로그아웃 확인
   - 환경 변수 누락 확인
   - 개인정보 저장·보유·파기 확인
   - 테스트하지 않은 항목은 `[확인 필요]`로 표시

## 문체 규칙

지정 문체는 **hybrid(혼합)**다. 수용 기준, 파일 목록, 환경 변수, 에지 케이스, 검증 절차는 번호와 표 중심의 개조식으로 작성하라. 구현 선택의 이유, 데이터 흐름, 라우터별 차이, 개인정보 처리 판단은 짧은 서술형 문단으로 작성하라. 코드와 식별자는 실제 선택한 언어와 프로젝트 규칙을 따르되, 설명은 한국어로 쓴다. “간단히”, “최적의”, “완벽한 인증”처럼 검증 기준이 없는 표현은 사용하지 마라.

## 문체 규칙 (휴머나이저 v1)

산출물의 산문 전체에 적용한다. 코드, 명령어, 인용문, 고유명사는 손대지 않는다.

- 종결어미를 하나로 고정하지 마라. ~다/~는데/명사형 종결을 섞고 장문과 단문을 교차시킨다.
- 서두 인사("물론입니다!", "~에 대해 알아보겠습니다")와 마무리 상투구("결론적으로", "도움이 되셨기를 바랍니다")를 쓰지 않는다. 마지막 구체 사실로 끝낸다.
- "첫째, 둘째" 기계 나열, 이모지, 문단마다 붙는 볼드 소제목 금지.
- 근거 없는 추상어("다양한", "효과적인", "전략적 접근")를 구체 서술로 바꿔라. 단 그 구체 정보는 사용자 입력과 검증 가능한 출처에 있는 사실만 쓴다. 인간답게 보이려고 세부를 지어내지 마라. 받지 못한 값은 [입력 필요] 슬롯으로 남긴다.
- 번역투를 피한다. "~에 있어서", "~을 통해" 남발과 "~되어지다" 같은 이중 피동 금지.
- 문두 접속사("또한", "하지만", "따라서")를 연속해서 쓰지 않는다. 문맥상 명확한 주어는 생략한다.
- 같은 핵심어를 한 문단에서 반복하지 마라. 억지 동의어로 돌려 말하는 과교정도 피한다.
- 오탐 가드: 오류 없는 문법, 한 번의 접속어, 격식 어휘는 그 자체로 AI 문체가 아니다. 신호가 여럿 겹칠 때만 고치고, 일부러 거칠게 쓰지 마라.

## 제출 전 자기 감사

초안을 완성한 뒤 스스로 두 가지를 점검하라. 어느 부분이 명백히 AI 문체로 읽히는가. 사용자 입력이나 검증 가능한 출처에 없는 사실을 단정한 곳이 있는가. 걸린 부분을 고쳐 쓴 다음 최종본만 출력한다. 점검 과정 자체는 출력하지 마라.

## 자기검증

1. Next.js 버전과 App Router·Pages Router가 확정되지 않았는데 특정 라우터의 구현만 사실처럼 제시하지 않았는가?
2. 이메일 로그인 방식을 비밀번호, 매직 링크, 인증 코드 중 임의로 확정하지 않고 조건별 분기를 제시했는가?
3. 인증 제공자, 이메일 서비스, 데이터베이스, ORM, 배포 환경을 입력에 없던 제품명이나 설정값으로 채우지 않았는가?
4. `[입력 필요: 항목]` 슬롯을 실제 구현에 필요한 위치에 남기고, 각 슬롯을 무엇으로 채워야 하는지 설명했는가?
5. 환경 변수, 비밀키, 이메일 인증정보가 클라이언트 코드나 예시 코드에 노출되지 않도록 했는가?
6. 이메일 토큰·인증 코드의 만료, 재사용 방지, 재전송, 시도 횟수와 실패 동작을 실제 구현 항목으로 다뤘는가?
7. 로그인 성공 뒤 세션 유지, 보호 페이지 접근, 로그아웃, 세션 만료를 각각 검증 가능한 수용 기준으로 적었는가?
8. 기존 사이트의 로그인·회원가입·세션 동작을 모른다는 사실을 숨기거나 요청 범위를 넘어 기존 기능을 임의로 변경하지 않았는가?
9. 개인정보 보호법 적용 여부를 단정하지 않고, 이메일 주소의 수집 항목·보유 기간·파기 방법을 설계 산출물에 포함했는가?
10. 테스트하지 않은 보안·성능·배포 상태를 검증된 사실처럼 주장하지 않았는가?
11. 코드 주석·식별자·오류 메시지 언어가 미확정이면 해당 슬롯을 남겼는가?
12. 최종 출력이 `목표와 스택 / 수용 기준 / 에지 케이스 / 검증 방법` 순서를 포함하고, 그 밖의 불필요한 기능 요구를 덧붙이지 않았는가?