로그인 기능을 만들려면 무엇이 필요할까요? 회원가입·세션·권한 이해하기

예약 내역, 구매한 강의, 개인 기록처럼 사람마다 다른 내용을 보여주려면 로그인 기능이 필요합니다.

AI에게 “구글 로그인을 붙여줘”라고 말하면 버튼과 로그인 화면은 금방 생길 수 있어요. 하지만 버튼을 눌러 내 이름이 보인다고 로그인 기능 전체가 완성된 것은 아닙니다.

로그인은 크게 네 가지가 함께 움직이는 기능입니다.

회원가입
→ 본인 확인
→ 로그인 상태 유지
→ 볼 수 있는 데이터와 할 수 있는 일 제한

각 단계가 무엇을 맡는지 알아야 AI가 만든 기능도 제대로 확인할 수 있습니다.

먼저 로그인이 정말 필요한지 판단해요

모든 웹 애플리케이션에 회원가입이 필요한 것은 아닙니다.

누구나 읽는 소개 페이지나 한 번 제출하고 끝나는 문의 폼이라면 로그인 없이도 충분할 수 있어요. 주문번호와 이메일로 한 번만 조회하게 하거나, 이메일로 유효기간이 있는 전용 링크를 보내는 방식이 더 간단할 때도 있습니다.

반대로 다음과 같은 기능에는 사용자를 구분할 방법이 필요합니다.

• 내가 작성한 기록을 다시 봅니다.
• 구매한 콘텐츠만 이용합니다.
• 여러 기기에서 같은 데이터를 불러옵니다.
• 일반 사용자와 관리자가 다른 기능을 사용합니다.
• 개인정보나 결제 내역을 본인만 확인합니다.

로그인은 화면 하나가 아니라 앞으로 모든 기능의 데이터와 권한에 영향을 줍니다. 필요하지 않은 서비스에 미리 넣으면 가입 화면, 비밀번호 재설정, 탈퇴와 고객 문의까지 운영할 일이 함께 늘어납니다.

회원가입은 사용자 계정을 만드는 일이에요

회원가입은 서비스를 다시 찾아왔을 때 같은 사람이라고 알아볼 수 있도록 계정을 만드는 과정입니다.

가입 방법은 여러 가지가 있어요.

이메일 + 비밀번호
이메일 매직 링크 또는 인증 코드
구글·카카오·애플 같은 소셜 로그인
휴대전화 인증

어떤 방법이 가장 좋다고 정해져 있지는 않습니다. 고객이 자주 사용하는 계정, 서비스의 보안 수준, 개발과 운영 범위를 함께 봐야 해요.

이메일과 비밀번호 방식은 익숙하지만 비밀번호 저장과 재설정 기능이 필요합니다. 비밀번호를 직접 데이터베이스에 평문으로 저장해서는 안 되며, 검증된 인증 서비스를 사용하는 편이 안전합니다.

매직 링크나 이메일 인증 코드는 비밀번호를 외울 필요가 없지만 메일이 늦게 오거나 스팸함에 들어가는 상황을 안내해야 합니다. 소셜 로그인은 가입이 간편하지만 구글이나 카카오의 개발자 설정, 동의 화면과 되돌아올 주소를 정확히 구성해야 해요.

처음에는 고객에게 가장 자연스러운 방식 하나로 시작해도 됩니다. 로그인 방법을 많이 제공할수록 같은 사람이 이메일과 구글로 각각 가입해 계정이 나뉘는 문제도 고려해야 합니다.

인증과 권한은 서로 다른 일이에요

로그인 기능에서 가장 중요한 구분입니다.

인증 Authentication
→ 지금 요청한 사람이 누구인지 확인

권한 Authorization
→ 확인된 사람이 이 데이터와 기능을 사용해도 되는지 확인

로그인에 성공했다는 사실만으로 모든 데이터를 보여줘서는 안 됩니다.

예를 들어 민지가 로그인한 상태라고 해볼게요. 서버는 민지가 로그인했다는 사실을 확인한 다음, 요청한 주문이 실제로 민지의 주문인지 다시 검사해야 합니다.

민지가 로그인함
→ 인증 성공

민지가 주문 A의 소유자임
→ 주문 A 조회 권한 있음

민지가 주문 B의 소유자가 아님
→ 주문 B 조회 거부

화면에서 다른 사람의 주문 버튼을 숨기는 것만으로는 부족합니다. 주소나 요청값을 바꾸어 서버에 직접 요청할 수 있기 때문에 서버에서 매번 권한을 확인해야 합니다.

관리자 기능도 마찬가지예요. 메뉴를 숨기는 것과 관리자 권한을 검사하는 것은 다른 일입니다. 주문 상태 변경, 환불, 회원 정보 조회처럼 중요한 작업은 서버가 현재 사용자의 역할까지 확인해야 합니다.

세션은 로그인 상태를 이어주는 표식이에요

사용자가 로그인한 뒤 페이지를 이동할 때마다 이메일과 비밀번호를 다시 입력하게 할 수는 없습니다.

그래서 로그인에 성공하면 인증 서비스가 로그인 상태를 증명하는 정보를 발급합니다. 이 상태를 세션(session)이라고 해요.

로그인 성공
→ 세션 생성
→ 브라우저가 세션 정보를 보관
→ 다음 요청에 세션 정보 전달
→ 서버가 현재 사용자 확인

Supabase Auth 같은 인증 서비스는 짧게 사용하는 액세스 토큰과 세션을 갱신하기 위한 리프레시 토큰을 이용할 수 있습니다. 세션은 로그아웃하거나 정해진 조건에 도달하면 끝납니다. 자세한 구조는 Supabase의 세션 공식 문서 (새 탭에서 열림)에서 확인할 수 있어요.

토큰의 긴 문자열을 직접 해석하거나 임의로 만들 필요는 없습니다. 대신 다음을 확인해야 합니다.

• 로그인 뒤 새로고침해도 상태가 유지되나요?
• 로그아웃하면 보호된 페이지에 다시 들어갈 수 없나요?
• 만료된 세션을 적절히 갱신하거나 로그인 화면으로 보내나요?
• 브라우저 코드와 로그에 비밀 토큰을 불필요하게 출력하지 않나요?
• 서버가 화면에서 받은 사용자 ID를 그대로 믿지 않고 세션의 사용자를 확인하나요?

화면에서 userId를 보내게 한 뒤 서버가 그 값을 그대로 믿는 구조는 위험합니다. 공격자가 다른 사람의 ID로 바꾸어 요청할 수 있기 때문이에요.

인증 계정과 서비스 사용자 정보는 역할이 달라요

인증 서비스에는 로그인에 필요한 계정 정보가 있습니다.

하지만 내 서비스에는 로그인 외의 사용자 정보도 필요할 수 있어요.

인증 계정
→ 로그인 식별자
→ 인증 제공자
→ 이메일 확인 상태
→ 세션 관리

서비스 사용자 정보
→ 표시 이름
→ 프로필 이미지
→ 가입한 프로그램
→ 알림 설정
→ 서비스에서 사용하는 역할

두 정보는 연결할 수 있지만 같은 것으로 취급하지 않는 편이 좋습니다. 로그인 이메일이 바뀌더라도 주문과 작성한 글의 주인이 사라지면 안 되기 때문이에요. 서비스의 사용자 테이블은 인증 서비스가 발급한 변하지 않는 사용자 ID를 기준으로 연결할 수 있습니다.

또한 일반 사용자가 가입할 때 브라우저에서 role: admin을 보내 관리자 계정을 만들 수 있어서는 안 됩니다. 역할과 권한은 신뢰할 수 있는 서버나 운영 절차에서만 부여해야 해요.

소셜 로그인은 비밀번호를 대신 맡기는 방식이에요

“구글로 계속하기” 버튼을 누르면 내 서비스가 구글 비밀번호를 받는 것이 아닙니다.

내 서비스에서 구글 로그인 선택
→ 구글의 로그인·동의 화면으로 이동
→ 구글이 사용자를 확인
→ 미리 등록한 주소로 결과 전달
→ 내 서비스가 계정과 세션 생성

이때 중요한 값이 리디렉션 주소입니다. 로그인을 마친 뒤 어느 주소로 돌아올지 구글과 인증 서비스에 미리 등록해야 해요. 로컬 개발 주소와 실제 운영 도메인이 다르다면 두 환경을 구분해서 설정해야 합니다.

소셜 로그인은 OAuth라는 표준을 사용합니다. 비밀번호를 내 서비스와 공유하지 않고 외부 계정으로 로그인하는 전체 흐름은 Supabase 소셜 로그인 문서 (새 탭에서 열림)에서 볼 수 있습니다.

소셜 로그인에 성공한 뒤에도 내 서비스의 권한 검사는 별도로 필요합니다. 구글이 “이 사람의 구글 계정을 확인했다”는 사실은 알려줄 수 있지만, “이 사람이 내 서비스의 관리자다”까지 결정해주지는 않아요.

로그인 화면보다 실패 흐름이 더 많아요

정상적으로 가입하고 로그인하는 경우만 확인하면 실제 사용 중에 금방 막힙니다.

다음 상황도 함께 준비해야 해요.

• 이미 가입한 이메일로 다시 가입합니다.
• 이메일 인증 링크가 만료됩니다.
• 소셜 로그인 동의 화면에서 취소합니다.
• 비밀번호를 잊어 재설정을 요청합니다.
• 다른 브라우저나 휴대전화에서 로그인합니다.
• 로그인한 채 오래 두어 세션이 만료됩니다.
• 탈퇴한 계정으로 다시 접근합니다.
• 일반 사용자가 관리자 주소를 직접 입력합니다.

오류 코드를 그대로 보여주기보다 사용자가 다음에 무엇을 하면 되는지 안내해야 합니다.

잘못된 안내
Invalid login credentials

도움이 되는 안내
이메일 또는 비밀번호를 확인해주세요.
비밀번호가 기억나지 않으면 재설정할 수 있어요.

다만 “이 이메일은 가입되어 있지 않습니다”처럼 계정 존재 여부를 지나치게 자세히 알려주면 다른 사람이 가입자를 확인하는 데 악용할 수 있습니다. 편의성과 보안을 함께 검토해야 해요.

비밀번호 재설정과 탈퇴까지가 로그인 기능이에요

회원가입과 로그인 버튼만 만들고 끝내기 쉽지만 운영 단계에서는 다음 기능이 필요합니다.

• 이메일 또는 프로필 정보 변경
• 비밀번호 재설정
• 모든 기기 또는 현재 기기에서 로그아웃
• 소셜 계정 연결 문제 대응
• 계정 탈퇴
• 탈퇴 뒤 개인정보와 주문 기록 처리

탈퇴했다고 모든 기록을 즉시 삭제할 수 있는 것은 아닐 수 있습니다. 결제와 세무처럼 보관 의무가 있는 기록, 사용자가 작성한 공개 콘텐츠, 개인정보 삭제 범위를 서비스 정책과 관련 법률에 맞게 정해야 해요.

법적 보관 기간과 개인정보 처리 기준은 서비스와 국가에 따라 달라질 수 있으므로 실제 출시 전에는 최신 공식 안내나 전문가의 검토가 필요합니다.

Supabase Auth를 사용하면 무엇을 맡길 수 있나요?

Supabase Auth는 이메일·비밀번호, 매직 링크, OTP와 여러 소셜 로그인 방식을 제공하고 세션을 관리합니다. 공식 문서도 인증과 권한을 구분해서 설명하고 있어요. (Supabase Auth 공식 문서 (새 탭에서 열림))

인증 서비스를 사용한다고 서비스의 모든 권한이 자동으로 완성되지는 않습니다.

데이터를 브라우저에서 Supabase Data API로 직접 읽는 구조라면 RLS 정책으로 행마다 접근 권한을 제한할 수 있습니다. 반대로 Next.js 서버가 데이터베이스에 직접 연결하는 구조라면 서버 코드가 세션을 확인하고 데이터 소유자와 역할을 검사해야 합니다.

두 방식을 생각 없이 섞지 말고 현재 프로젝트가 어떤 경로로 데이터에 접근하는지 먼저 확인하세요. Supabase의 서버 접근 방식과 RLS의 역할을 함께 읽으면 차이를 이해하기 쉽습니다.

AI에게 먼저 설계를 확인시켜요

바로 코드를 수정하게 하기 전에 다음 질문에 답하게 해보세요.

이 웹 애플리케이션에 로그인 기능을 추가하려고 해.
아직 코드는 수정하지 말고 현재 구조와 요구사항을 먼저 확인해줘.

1. 로그인이 꼭 필요한 기능은 무엇인지
2. 이메일, 매직 링크, 소셜 로그인 중 어떤 방식이 적합한지
3. 인증 계정과 서비스 사용자 정보를 어디에 저장할지
4. 세션을 어디에서 확인하고 갱신할지
5. 일반 사용자와 관리자의 권한을 서버에서 어떻게 검사할지
6. 사용자가 자기 데이터만 조회·수정할 수 있는지
7. 가입 중복, 인증 실패, 세션 만료, 비밀번호 재설정 흐름
8. 로그아웃과 탈퇴 뒤 데이터를 어떻게 처리할지
9. 로컬과 운영 환경의 리디렉션 주소가 어떻게 다른지

현재 프로젝트가 Data API와 RLS를 사용하는지,
서버에서 DB에 직접 연결하는지도 확인해줘.
추측하지 말고 필요한 결정과 작업 순서를 표로 정리해줘.

설계를 검토한 뒤에는 기능을 작은 흐름으로 나눠 구현하는 편이 안전합니다.

회원가입
→ 이메일 확인
→ 로그인
→ 새로고침 뒤 세션 유지
→ 내 정보 조회
→ 다른 사람 데이터 접근 차단
→ 관리자 권한 차단
→ 로그아웃
→ 비밀번호 재설정

출시 전에 확인할 체크리스트

• 로그인이 필요하지 않은 페이지는 가입 없이 사용할 수 있나요?
• 가입과 로그인 방법이 고객에게 적합한가요?
• 비밀번호를 직접 평문으로 저장하지 않나요?
• 새로고침과 페이지 이동 뒤에도 세션이 정상적으로 유지되나요?
• 로그아웃한 뒤 보호된 주소를 직접 열어도 차단되나요?
• 서버가 요청값의 사용자 ID가 아니라 세션의 사용자를 기준으로 판단하나요?
• 사용자가 다른 사람의 데이터를 조회하거나 수정할 수 없나요?
• 관리자 메뉴를 숨기는 데서 끝나지 않고 서버에서 역할을 확인하나요?
• 실패, 취소, 만료와 중복 가입 상황을 안내하나요?
• 운영 도메인의 소셜 로그인 리디렉션 주소를 등록했나요?
• 재설정, 로그아웃과 탈퇴 흐름이 있나요?
• 토큰, 비밀번호와 개인정보를 로그에 남기지 않나요?

정리

• 회원가입은 사용자를 다시 알아보기 위한 계정을 만드는 과정입니다.
• 인증은 사용자가 누구인지, 권한은 무엇을 할 수 있는지 확인하는 일입니다.
• 세션은 로그인 상태를 다음 요청까지 이어줍니다.
• 인증 계정과 서비스에서 사용하는 프로필·역할 정보는 구분해서 관리할 수 있습니다.
• 소셜 로그인을 사용해도 내 서비스의 데이터 권한은 별도로 검사해야 합니다.
• 화면에서 버튼을 숨기는 것만으로는 부족하며 서버가 데이터 소유자와 역할을 확인해야 합니다.
• 로그인 성공뿐 아니라 중복 가입, 취소, 만료, 재설정, 로그아웃과 탈퇴까지 준비해야 합니다.

로그인은 문을 만들어주는 기능이 아닙니다. 누구인지 확인하고, 들어온 사람이 볼 수 있는 방을 정확히 나누는 기능입니다.

Supabase로 회원가입과 로그인을 직접 구현하고 사용자별 데이터 접근까지 확인하려면 바이브코딩 가이드 8장의 실습으로 이어가세요.