서비스 회원 로그인

최종 수정: 2026년 7월 3일

옷가게 쇼핑몰 사이트를 운영한다고 생각해 보세요. 손님이 직접 회원 가입을 하고, 회원만 후기를 쓰거나 등급별 혜택을 받게 하고 싶을 때가 있습니다. 그러려면 "손님이 스스로 가입하고 로그인하는 회원 시스템"이 필요합니다. 이 회원 시스템을 내 사이트에 붙여 주는 Space 기능이 ServiceLogin(내 서비스에 손님이 직접 가입해 쓰는 로그인 설정)입니다.

ServiceLogin을 켜면 손님은 Google 같은 소셜 계정으로 누구나 직접 가입할 수 있습니다. 가입한 손님 한 명 한 명이 ServiceUser(내 서비스에 가입한 회원)가 됩니다. 로그인 과정과 로그인 상태 유지는 WEEGLOO가 대신 처리하므로, 비밀번호를 직접 보관하거나 소셜 로그인을 처음부터 만들 필요가 없습니다.

이 페이지에서는 ServiceLogin이 무엇이고 운영진 계정과 어떻게 다른지 먼저 살펴본 뒤, 옷가게 Space에서 ServiceLogin을 직접 켜고 설정해 봅니다.

회원은 운영진과 다릅니다

WEEGLOO에는 로그인하는 사람이 두 종류 있습니다. 헷갈리기 쉬우니 먼저 경계를 그어 둡니다.

  • 운영진/팀은 상품을 등록하고 사이트를 관리하는 사람입니다. 손님처럼 ServiceLogin으로 가입하는 것이 아니라, WEEGLOO 계정으로 이 Space의 멤버가 되어(이미 안에 있는 사람의 초대와 역할 부여로) 들어옵니다. 운영진의 권한은 역할과 권한에서 다룹니다.
  • ServiceUser는 그 사이트를 쓰는 손님/회원입니다. 내가 운영하는 옷가게 사이트에서 소셜 계정으로 직접 가입한 사람입니다. 운영진과는 완전히 별개의 로그인입니다.

한마디로 운영진은 "가게를 꾸리는 사람", ServiceUser는 "가게에 찾아온 손님"입니다. ServiceLogin은 이 손님들이 드나드는 출입문을 만드는 일입니다.

함께 움직이는 세 가지

회원 시스템은 세 가지가 맞물려 돌아갑니다.

  • ServiceLogin: 로그인 설정 자체입니다. 어떤 소셜 로그인을 쓸지, 가입한 회원에게 어떤 권한을 기본으로 줄지 같은 것을 여기서 정합니다.
  • ServiceUserRole: 회원에게 줄 권한 묶음입니다. 회원이 무엇을 보고 무엇을 쓸 수 있는지를 정해 둡니다.
  • ServiceUser: 가입한 회원 한 명 한 명입니다. 손님이 가입할 때마다 하나씩 생깁니다.

이 페이지는 출입문을 여는 ServiceLogin 설정에 집중합니다. 회원이 실제로 무엇을 보고 쓸 수 있는지(권한)를 정하는 ServiceUserRole회원 역할과 권한에서 따로 다룹니다. 아래 설정에서 고르는 기본 Role이 바로 그 페이지에서 만드는 역할입니다.

ServiceLogin 켜기

옷가게 Space에서 회원 로그인을 켜 보겠습니다.

회원 로그인 설정은 한 Space에 하나만 있습니다. 여러 개를 새로 만드는 것이 아니라, 이 하나를 켜 두고 필요할 때 고쳐 가며 씁니다.

ServiceLogin은 처음에는 꺼져 있습니다. 설정 화면을 열면 "ServiceLogin이 비활성화되어 있습니다"라는 안내와 함께 활성화 버튼이 보입니다. 안내에는 "ServiceLogin을 활성화하면 운영 중인 사이트에서 Google 등의 소셜 로그인을 사용할 수 있습니다. OAuth와 세션은 Weegloo가 처리합니다"라고 적혀 있습니다.

  1. 왼쪽 메뉴에서 서비스를 펼쳐 ServiceLogin을 누르세요.
  2. 기본 정보 화면에서 활성화 버튼을 누르세요.

ServiceLogin이 아직 켜지지 않은 상태. "ServiceLogin이 비활성화되어 있습니다" 안내와 활성화 버튼이 보입니다

활성화를 누르면 설정 폼이 열립니다. 이 폼에서 소셜 로그인을 하나 이상 켜고 저장해야 회원 로그인이 실제로 동작합니다.

설정 폼 채우기

설정 폼은 기본 정보와 소셜 로그인 설정으로 나뉩니다. 먼저 기본 정보를 채웁니다.

항목무엇을 적나
서비스 이름로그인할 때 손님에게 보이는 서비스 이름입니다. 옷가게라면 가게 이름을 적습니다.
담당자 이메일로그인에 문제가 생겼을 때(예: 가입 가능 인원이 다 찼을 때) 손님에게 보여 줄 연락처입니다.
Callback URI손님이 로그인을 마친 뒤 돌아갈 내 사이트의 주소입니다.
기본 Role새로 가입한 손님에게 자동으로 주어지는 권한 묶음입니다. 옆의 Role 관리를 누르면 권한을 만드는 화면으로 넘어갑니다.
  1. 서비스 이름에 손님에게 보일 이름을 입력하세요. 옷가게라면 포근한 옷장처럼 가게 이름을 적습니다.
  2. 담당자 이메일에 문의를 받을 주소를 입력하세요. 예: help@pogeun-otjang.com.
  3. Callback URI에 로그인 후 손님이 돌아올 내 사이트 주소를 입력하세요. 예: https://pogeun-otjang.com/auth/callback.
  4. 기본 Role에서 새 회원에게 줄 권한을 고르세요. 아직 만든 권한이 없다면 옆의 Role 관리에서 먼저 만들고 돌아오세요.

기본 Role에 무엇을 골라야 할지, 회원에게 어떤 권한을 줄지는 회원 역할과 권한에서 다룹니다.

가입을 받기 전에 운영진이 한 번 확인하고 싶다면, 신규 가입자 관리자 승인 필요를 켜 둘 수 있습니다. 이 옵션을 켜면 새로 가입한 손님은 바로 로그인하지 못하고, 운영진이 승인해 주기 전까지 기다립니다. 이미 가입해 있는 회원에게는 영향이 없습니다.

  1. 가입 즉시 누구나 로그인하게 하려면 신규 가입자 관리자 승인 필요를 꺼 두세요. 가입을 일일이 확인하고 싶다면 켜 두세요.

활성화 후 열리는 ServiceLogin 설정 폼. 서비스 이름·담당자 이메일·Callback URI·기본 Role과 소셜 로그인 목록이 보입니다

소셜 로그인 켜기

손님이 어떤 계정으로 가입할지는 Login Providers에서 정합니다. Google, GitHub, Facebook, GitLab, LINE, 카카오, 네이버를 각각 켤 수 있습니다.

소셜 로그인은 두 곳을 잇는 일입니다. 그 제공자 쪽(예: Google이라면 Google Cloud Console)에 내 사이트를 등록하고, 거기서 받은 값을 WEEGLOO에 입력합니다. Google을 켜면 화면이 이 두 단계를 그대로 안내합니다.

  1. Google을 켜세요. 두 단계 안내가 나타납니다.
  2. Step 1에 보이는 승인된 리디렉션 URI를 복사해, Google Cloud Console의 OAuth 클라이언트에 등록하세요. 이 주소는 로그인 결과를 어디로 돌려보낼지 Google에게 알려 줍니다.
  3. Google Cloud Console에서 발급받은 값을 Step 2Client IDClient Secret 칸에 입력하세요.
  4. 다른 소셜 로그인도 쓰려면 GitHubFacebook도 같은 방식으로 켜고 값을 입력한 뒤, 저장을 누르세요.

Google을 켜면 나오는 자격증명 안내. Step 1의 승인된 리디렉션 URI와 Step 2의 Client ID·Client Secret 입력 칸이 보입니다

켠 소셜 로그인이 목록에 켜진 상태로 보이고 저장까지 마치면, 손님이 그 계정으로 로그인할 수 있게 됩니다.

provider마다 다른 것: 스코프와 이메일

연결 절차는 어느 provider든 위와 같습니다. 리디렉션 주소를 등록하는 칸의 이름은 provider마다 조금씩 다릅니다(승인된 리디렉션 URI, 콜백 URL, Redirect URI 등). 이름이 달라도 값은 provider를 켰을 때 나오는 안내의 Step 1에 보이는 주소를 그대로 붙여 넣으면 됩니다.

아래 표의 스코프(로그인할 때 손님에게 요청하는 정보의 범위)는 WEEGLOO가 로그인 시점에 provider에게 요청하는 값입니다. Google·GitHub·Facebook은 콘솔에서 미리 지정할 것이 없고, 손님이 로그인할 때 동의하면 됩니다. 나머지 provider는 콘솔에서 미리 켜 두어야 하는 것이 있으니 표에서 확인하세요.

WEEGLOO는 가입한 회원을 이메일로 구분합니다. 그래서 provider가 이메일을 넘겨주지 않으면 그 계정으로는 로그인이 되지 않습니다. OAuth 앱을 만드는 자세한 절차는 각 provider의 공식 문서를 따릅니다.

providerWEEGLOO가 요청하는 스코프provider 콘솔에서 미리 켤 것공식 문서
Googleemail, profile없음Google 문서
GitHubread:user, user:email없음GitHub 문서
Facebookemail, public_profile없음Facebook 문서
GitLabread_user앱을 만들 때 스코프에서 read_user를 체크합니다GitLab 문서
카카오profile_nickname, profile_image, account_email비즈 앱 전환 후 이메일 동의항목의 사용 승인이 필요합니다Kakao 문서
네이버email, profile, nickname앱을 등록할 때 제공 정보에 이메일 주소를 포함해야 합니다Naver 문서
LINEprofile, email채널에서 이메일 권한을 신청해 승인받아야 합니다LINE 문서

가입한 회원 보기

손님이 가입하면 그 회원은 서비스 > ServiceLogin > Users에서 확인할 수 있습니다. 여기서 가입한 회원 목록을 보고 관리합니다.

앞에서 신규 가입자 관리자 승인 필요를 켜 두었다면, 새로 가입한 회원은 이 화면에서 승인을 기다립니다. 회원을 활성화해 주면 그때부터 로그인할 수 있습니다.

사이트가 여러 개일 때 회원 로그인

한 사람이 서로 다른 서비스를 여럿 운영하기도 합니다. 옷가게 포근한 옷장을 운영하면서, 전혀 다른 업종인 동네 빵집 사이트도 함께 꾸린다고 생각해 보세요. 두 사이트는 찾아오는 손님도, 다루는 내용도 다릅니다. 옷가게에 가입한 손님이 빵집 회원일 이유는 없습니다.

회원 로그인은 Space 하나에 하나씩 둡니다. 그래서 이렇게 서로 다른 사이트는 각각 Space를 만들고, 그 Space에서 회원 로그인을 따로 설정합니다. 회원 명단도 Space별로 나뉘어, 옷가게 회원과 빵집 회원은 서로 다른 회원으로 관리됩니다.

Space의 회원 로그인은 그 Space로 운영하는 사이트에서 쓰입니다. 하나의 회원 로그인을 여러 사이트에 붙여 한 번에 통과시키는 방식은 아닙니다. 회원이 한 번의 로그인으로 함께 쓰길 바라는 화면이라면, 그 화면들을 한 사이트에 모으세요.

다음으로 할 일

  • 회원 역할과 권한: 가입한 회원이 무엇을 보고 쓸 수 있는지 정하는 ServiceUserRole을 만들고, 위에서 고른 기본 Role로 연결합니다.
  • API 레퍼런스: 가입한 회원의 로그인을 내 사이트 코드에 붙이려면 공식 클라이언트 SDK와 요청 형식 같은 기술 명세가 필요합니다. 회원이 보고 쓰는 콘텐츠를 프로그램에서 직접 다룰 때의 명세도 여기서 다룹니다.