앱에 로그인을 추가하는 방법: 비밀번호, 매직 링크, Google, 역할

앱에 로그인을 추가하려면 방법을 정하세요. 이메일과 비밀번호, 매직 링크(이메일로 보내는 일회용 로그인 링크), 또는 "Google로 로그인" 중 하나예요. 그리고 처음부터 직접 구현하지 말고 검증된 인증 라이브러리나 호스팅된 제공업체를 쓰세요. 그다음 각 종류의 사용자가 무엇을 할 수 있는지(역할) 정하고, 모든 페이지와 API 요청에서 서버가 이를 강제하게 하세요. 세션은 보안 쿠키를 쓰고, 만료되며, 로그아웃할 때 확실히 끝나야 해요.

이 가이드는 각 선택지와, 제대로 작동하는 로그인과 안전한 로그인을 가르는 세부 사항을 차례로 설명해요. 개념적인 배경은 인증이란 무엇인가를 참고하세요.

먼저 정하세요: 로그인이 정말 필요한가요?

로그인은 불편함과 책임을 더해요. 다음과 같은 경우에 필요해요:

• 사용자에게 개인 데이터가 있을 때(예약, 문서, 청구서)
• 사용자가 다른 사람들이 볼 내용을 바꿀 수 있을 때
• 접근에 요금을 받을 때
• 사람마다 다른 권한이 필요할 때(소유자, 직원, 고객)

마케팅 사이트, 공개 디렉터리, 이메일을 보내 주는 양식이라면 로그인이 필요 없을 수도 있어요. 대기자 명단은 계정이 필요하지 않아요. 이메일 입력란이면 충분해요.

흔한 네 가지 로그인 방식

많은 앱이 두 가지를 조합해요. Google 로그인과 이메일 매직 링크의 조합은 비밀번호를 전혀 저장하지 않으면서 대부분의 사람을 포괄해서 인기가 많아요.

이메일과 비밀번호

비밀번호 로그인을 제공한다면 다음은 타협할 수 없는 부분이에요:

• 느린 비밀번호 해싱 알고리즘으로 해시하세요. OWASP의 비밀번호 저장 지침은 Argon2id를 권장하고, 대안으로 scrypt, bcrypt, PBKDF2를 들어요. 비밀번호를 평문이나 빠른 일반 해시로 저장하지 마세요.
• 비밀번호 재설정은 무작위, 일회용, 만료되는 링크를 써서 인증된 이메일로 보내세요.
• 어떤 이메일이 계정을 가지고 있는지 드러내지 마세요. "해당 이메일이 등록되어 있다면 재설정 링크를 보냈어요"가 "계정을 찾을 수 없어요"보다 나아요.
• 로그인과 재설정 시도를 제한하세요(속도 제한). 비밀번호 추측을 늦출 수 있어요.
• 긴 비밀번호와 비밀번호 관리자를 허용하세요. 이상한 문자 조합을 강제하는 규칙은 빼세요.

매직 링크와 일회용 코드

매직 링크는 사용자에게 이메일로 보내는 로그인 링크예요. 클릭하면 로그인돼요. 일회용 코드는 같은 개념이지만, 클릭 대신 입력하는 방식이에요.

• 링크와 코드는 빨리 만료되고 한 번만 작동해야 해요.
• 링크는 사용자가 클릭한 기기에서 로그인되어야 하며, 토큰이 로그나 분석 도구에 남으면 안 돼요.
• 신뢰할 수 있는 이메일 발송이 필요해요. 앱에서 이메일 보내는 방법을 참고하세요. Gmail과 Outlook에서 테스트하고 스팸 폴더도 확인하세요.

Google로 로그인 (그리고 기타 OAuth 제공업체)

"Google로 로그인"은 OAuth와 OpenID Connect를 사용해요. Google이 사용자가 누구인지 확인하고, 앱에 이메일과 이름을 알려 줘요. 2026년 9월 기준 설정은 Google Cloud Console의 Google Auth Platform 섹션에서 해요:

1. 프로젝트를 만들거나 선택하고, Branding 페이지를 채우세요. 동의 화면에 보이는 내용(앱 이름, 지원 이메일, 로고)이에요.
2. Clients 페이지에서 "웹 애플리케이션" 유형의 클라이언트를 만드세요.
3. 승인된 JavaScript 출처와 리디렉션 URI를 추가하세요. 앱이 실행되는 정확한 주소와, 로그인 후 Google이 사용자를 돌려보낼 주소예요.
4. 클라이언트 ID와 클라이언트 시크릿을 앱의 시크릿에 저장하세요.

Google의 OAuth 문서에 따라 흔히 문제가 생기는 부분은 다음과 같아요:

• redirect_uri_mismatch: 리디렉션 주소는 http와 https, 대소문자, 끝의 슬래시까지 정확히 일치해야 해요. 미리보기 주소와 실제 도메인 각각에 하나씩 추가하세요.
• HTTPS 필수: 리디렉션 URI는 HTTPS를 써야 해요. 개발 중의 localhost는 예외예요.
• state 매개변수는 돌아올 때 확인해서 사이트 간 요청 위조(CSRF)를 막아야 해요. 좋은 라이브러리는 이를 자동으로 처리해요.

기본 로그인 정보(이름, 이메일, 프로필)만 요청한다면 Google은 앱 확인이 필수가 아니라고 말해요. 사용자의 Gmail, Drive, 캘린더에 접근을 요청하는 것은 다르며, 확인이 필요해요.

직접 만들까, 제공업체를 쓸까?

앞의 두 가지는 모두 합리적이에요. 호스팅 제공업체는 더 많은 것을 대신해 주지만 의존성이 생기고 활성 사용자당 요금이 붙기도 해요. 현재 요금은 각 사이트에서 확인하세요. 라이브러리는 모든 것을 여러분의 데이터베이스에 두지만, 올바르게 설정해야 할 부분이 더 많아요. 무엇을 고르든, 비밀번호나 세션 로직을 손으로 직접 짜지 말고 AI에게 그 도구를 쓰도록 요청하세요.

역할과 권한

로그인은 누구인지를 알려 주고, 권한은 무엇을 할 수 있는지를 정해요. 처음에는 단순하게 유지하세요:

역할 이름보다 더 중요한 규칙은 다음과 같아요:

• 매번 서버에서 확인하세요. 페이지에서 버튼을 숨겨도 누군가 API를 직접 호출하는 것을 막지 못해요.
• 소유자 기준으로 범위를 제한하세요. 회원이 "예약 123"을 요청하면 그 예약이 본인 것일 때만 돌려줘야 해요.
• 사용자는 스스로 권한을 올릴 수 없어야 해요. 프로필 업데이트에서 브라우저가 보낸 역할 필드는 무시하세요.
• 기본값은 접근 불가. 새 라우트는 여러분이 다르게 결정하지 않는 한 로그인을 요구하게 하세요.

계정 두 개로 테스트하세요. 한 계정으로 로그인해 레코드의 ID를 기록하고, 다른 계정으로 로그인해서 그 레코드를 열어 보려고 하세요. 전체 테스트 방법은 보안 체크리스트에 있어요.

세션 보안

로그인 후 앱은 세션으로 사용자를 기억해요. 보통은 쿠키예요. OWASP의 세션 관리 지침은 다음을 권장해요:

• 세션 쿠키에 Secure(HTTPS에서만), HttpOnly(페이지 스크립트가 읽을 수 없음), SameSite를 설정
• 로그인할 때 새 세션 ID를 발급하고, 권한이 바뀔 때도 다시 발급
• 서버에서 강제하는 유휴 시간 제한과 절대 최대 수명
• 쿠키만 지우는 것이 아니라 서버에서 세션을 끝내는 로그아웃
• 사용자가 비밀번호를 바꾸면 세션 무효화

튜토리얼에서는 로그인 토큰을 브라우저의 로컬 스토리지에 저장하는 방식이 흔하지만, 이러면 페이지에서 실행되는 모든 스크립트가 토큰에 접근할 수 있어요. 웹 앱에서는 보통 보안 쿠키가 더 나은 기본값이에요.

핵심을 담은 프롬프트

이 앱에 사용자 계정을 추가해 줘. 사용자는 이메일과 비밀번호로 가입하고 로그인할 수 있고, Google로도 로그인할 수 있어야 해. 직접 만든 인증 코드 대신 [라이브러리 또는 제공업체]를 써 줘. 비밀번호는 Argon2id나 bcrypt로 해시해. 이메일로 비밀번호 재설정을 추가하고, 1시간 후 만료되는 일회용 링크를 써 줘. 세션은 보안이 설정된 HttpOnly 쿠키에 보관해. /dashboard와 모든 /api 라우트는 로그인한 사용자만 쓸 수 있게 하고, 사용자는 자신의 프로젝트만 보게 해 줘. "admin" 역할을 추가해서 모든 사용자를 볼 수 있게 하고, /admin은 서버에서 확인해서 관리자만 들어갈 수 있게 해 줘.

그다음 테스트하세요: 가입, 로그아웃, 로그인, 비밀번호 재설정, 로그아웃 상태에서 비공개 URL 열어 보기, 다른 사용자의 레코드 열어 보기.

AI로 만든 로그인의 흔한 실수

• 페이지에서만 보호. 페이지는 로그아웃한 사용자를 리디렉션하지만, API는 누구에게나 데이터를 돌려줘요.
• 브라우저에 있는 시크릿. OAuth 클라이언트 시크릿과 인증 제공업체의 관리자 키는 서버에 있어야 해요.
• 미리보기와 실제 URL 혼동. Google의 리디렉션 URI나 재설정 이메일 링크가 미리보기를 가리키면, 공개 후 로그인이 깨져요.
• 이메일 인증 없음. 누구나 anyone@company.com으로 가입할 수 있어요. 그 주소에 연결된 무언가를 주기 전에 이메일을 인증하세요.
• 정상 경로만 테스트. 잘못된 비밀번호, 만료된 링크, 두 번째 계정으로 시도해 보세요.

Mythex에서 로그인 추가하기

Mythex에서 여러분 앱의 사용자를 위한 로그인은 앱에 추가하는 기능이며, Mythex 계정 자체와는 별개예요. Mythex는 내장 인증 제품을 제공하지 않으니, 인증 라이브러리나 제공업체와 그 키를 가져와야 해요:

1. 방식을 고르세요. 예를 들어 여러분의 데이터베이스에 저장하는 이메일과 비밀번호, 또는 호스팅 제공업체의 SDK.
2. 사용자를 직접 저장한다면 앱에 데이터베이스가 필요해요. 채팅에서 요청하거나 /database를 사용하세요.
3. 제공업체 키는 프로젝트 시크릿(/secrets 또는 프로젝트 설정)에 두세요.
4. 위의 프롬프트처럼 요청하고 미리보기에서 테스트하세요. Google 로그인이라면 미리보기 주소와 공개된 주소 둘 다에 리디렉션 URI를 추가하세요.

자세한 내용은 문서의 앱에 로그인 추가하기를 참고하세요. 유료 제품을 만든다면 SaaS MVP를 만드는 방법에서 계정과 결제를 함께 다뤄요.

자주 묻는 질문