사이트에 로그인 만들기, 화면과 데이터 양쪽에 규칙을 거세요
내 사이트에 로그인을 붙이려는 분께 맞는 글입니다. 인증 서비스를 쓰는 세 단계와, 화면만 막으면 안 되는 이유(행 단위 보안)를 알게 됩니다.
로그인은 화면 하나가 아니라 화면과 데이터베이스 양쪽에 같은 규칙을 걸어야 완성됩니다. 직접 다 짜기보다 검증된 인증 서비스를 쓰는 편이 안전합니다.
내 사이트에 로그인 기능을 붙이려고 해. 직접 비밀번호를 다루지 말고 검증된 인증 서비스(예: Supabase Auth)를 쓰는 방향으로 설계해 줘. - 로그인 성공 후 세션을 유지하는 방법 - 로그인한 사람만 볼 수 있는 화면과 누구나 볼 수 있는 화면 구분 - 화면뿐 아니라 데이터베이스에도 행 단위 보안(RLS)을 거는 방법 공식 문서의 세션 관리 안내를 기준으로 알려 줘.
로그인 기능은 누가 접속했는지 확인하고, 그 사람만 볼 수 있는 화면을 구분해 주는 장치입니다. 겉으로는 이메일과 비밀번호 입력창 하나처럼 보입니다.
하지만 뒤에서는 그 사람이 맞는지 확인하고, 이후 요청마다 "이 사람이 맞다"는 증명을 계속 들고 다니게 하는 구조가 돌아갑니다.
로그인이 필요한 이유
모든 사이트에 로그인이 필요한 건 아닙니다. 방문자가 그냥 글만 읽는 사이트라면 없어도 됩니다.
다만 사용자마다 다른 데이터를 저장하거나(내 글, 내 설정), 특정 사람만 볼 수 있는 화면이 있다면 그때부터 로그인이 필요해집니다.
인증 서비스 고르기
직접 비밀번호 암호화·세션 관리를 다 짜는 대신, 이런 기능을 전문으로 제공하는 서비스(예: Supabase Auth 같은 것)를 붙이는 방식이 널리 쓰입니다.
공식 문서에 따르면 이메일·비밀번호 방식 외에 매직 링크(이메일로 받은 링크 클릭만으로 로그인), 소셜 로그인(구글 등 외부 계정으로 로그인) 같은 방식도 지원됩니다.
화면과 연결하기
로그인 화면에서 입력한 정보를 인증 서비스로 보내고, 성공하면 그 사람의 로그인 상태를 세션(로그인 유지 정보)으로 저장합니다.
화면 나누기
로그인한 사람만 볼 수 있는 화면과 누구나 볼 수 있는 화면을 구분합니다.
이 구분을 프론트(화면)에서만 걸어두면 우회당할 수 있어서, 서버(데이터를 실제로 담고 있는 쪽)에서도 같은 규칙을 걸어야 합니다.
보안 확인 사항
가장 중요한 지점은 화면에서 막았다고 끝난 게 아니라는 것입니다. 데이터를 저장하는 쪽(데이터베이스)에서도 "이 사람만 이 데이터를 볼 수 있다"는 규칙을 별도로 걸어야 합니다.
Supabase 같은 서비스는 이런 규칙을 행 단위 보안(Row Level Security, 표의 한 줄 한 줄마다 누가 볼 수 있는지 정하는 규칙)이라는 기능으로 제공합니다.
자주 하는 실수
처음엔 화면에서 로그인 여부만 확인하면 되는 줄 알았습니다. 나중에야 화면 코드를 우회하면 데이터에 그냥 접근할 수 있다는 걸 알고, 데이터베이스 쪽 규칙도 따로 설정해야 한다는 걸 배웠습니다.
가장 흔했던 오류는 로그인은 됐는데 다음 화면에서 "로그인 안 한 사람"으로 다시 표시되는 문제였습니다. 세션이 제대로 유지되지 않은 것이었고, 원인은 세션을 저장하는 방식과 화면을 새로고침하는 방식이 서로 안 맞았던 것입니다. 공식 문서의 세션 관리 안내를 그대로 따라가며 해결했습니다.
자주 묻는 질문
직접 비밀번호를 암호화해야 하나요?
직접 짤 수도 있지만, 실수하면 보안 사고로 이어지기 쉬운 영역입니다. 이미 검증된 인증 서비스를 쓰는 게 안전합니다.
소셜 로그인이 꼭 필요한가요?
필수는 아닙니다. 다만 이메일·비밀번호를 새로 만드는 걸 귀찮아하는 사용자가 많아, 있으면 가입률에 도움이 되는 경우가 많습니다.
로그인 정보는 어디에 저장되나요?
쓰는 인증 서비스의 서버에 저장됩니다. 어떤 정보가 어떻게 저장·암호화되는지는 서비스 공식 문서에서 확인해야 합니다.
정리
로그인은 화면 하나가 아니라 화면과 데이터베이스 양쪽에 같은 규칙을 걸어야 완성되는 기능입니다. 직접 다 짜기보다 검증된 인증 서비스를 쓰는 편이 안전합니다.