소셜 로그인 연결 방식

카카오·구글 로그인을 붙이는 방법이에요. 버튼 하나로 끝나는 게 아니라, 그쪽에 내 서비스를 등록하고 키를 발급받고 심사를 거치는 절차가 따로 있어요.

쉽게 말하면

우리 가게에서 멤버십 가입서를 새로 쓰게 하는 대신, 손님이 이미 들고 다니는 대형 프랜차이즈 회원 카드를 계산대에 대게 하는 거예요. 카드를 대면 그 본사가 "이분은 확실히 회원이 맞습니다" 하고 우리 쪽에 확인만 해 줘요. 손님은 가입서를 안 써서 편하고, 우리 가게는 손님의 비밀번호를 아예 만지지 않아서 안전해요. 대신 조건이 하나 있어요. 카드를 받으려면 본사에 우리 가게를 미리 제휴점으로 등록해야 해요. 이 등록 절차가 바로 키 발급과 심사예요.

여기서 본사 역할을 하는 곳이 카카오·구글·네이버·애플이에요. 손님 확인이라는 첫 관문만 그쪽에 맡기고, 확인이 끝난 손님을 우리 서비스 안에서 기억하는 일은 여전히 세션과 쿠키가 해요. 그래서 소셜 로그인을 붙여도 로그인의 나머지 부품이 없어지는 게 아니에요.

	직접 가입	소셜 로그인
손님이 하는 일	이메일 적고 새 비밀번호를 만들어요. 여기서 절반이 이탈해요	버튼 한 번 누르고 이미 아는 계정으로 동의만 해요
비밀번호 보관	내 서버가 보관해요. 유출되면 내 책임이에요	내 서버에는 비밀번호가 아예 안 와요. 보관 부담이 사라져요
붙이기 전 준비	가입 화면과 저장 공간만 있으면 돼요	각 회사 개발자 사이트에 등록하고 키를 받고 심사를 거쳐요
기대는 곳	전부 내 서비스 안에서 끝나요	그 회사가 장애 나면 그 버튼도 같이 멈춰요

표의 마지막 두 줄이 이 문서의 핵심이에요. 편해지는 대가로 준비 절차와 남에게 기대는 구조가 생겨요. 이 둘을 알고 시작하면 사고가 안 나요.

버튼을 누르면 벌어지는 일

손님이 "카카오로 시작하기"를 누른 뒤의 흐름을 알아 두면, 어디서 막혔는지 짚을 수 있어요. 다섯 걸음이고, 손님 눈에는 두세 번의 화면 전환으로 보여요.

1손님이 내 사이트에서 버튼을 눌러요. 여기까지는 내 화면이에요.
2화면이 카카오 쪽으로 넘어가요. 손님은 카카오 화면에서 카카오 계정으로 로그인해요. 비밀번호는 카카오에만 쳐요.
3동의 화면이 떠요. "이 서비스에 닉네임과 이메일을 제공할까요" 같은 안내예요. 여기 뜨는 항목은 내가 등록 때 정한 목록이에요.
4카카오가 손님을 내 사이트로 돌려보내요. 이때 미리 등록해 둔 돌아올 주소(리다이렉트 주소)로만 보내 줘요. 확인표 역할을 하는 임시 코드가 같이 와요.
5내 서버가 그 코드로 카카오에 조회해요. "이 코드 진짜인가요" 하고 물어서 손님 정보를 받고, 그때부터 내 서비스의 세션이 시작돼요.

비밀번호는 내 서버에 오지 않아요

다섯 걸음 어디에도 손님의 카카오 비밀번호가 내 서버를 지나가는 순간이 없어요. 이게 이 방식이 만들어진 이유예요. 반대로 말하면, 내 화면에 "카카오 비밀번호를 입력하세요"라는 칸이 생겼다면 그건 소셜 로그인이 아니라 사고예요. 그렇게 만들어 달라고 요청해서도 안 돼요.

네 번째 걸음의 돌아올 주소가 이 구조의 자물쇠예요. 카카오는 등록된 주소로만 손님을 돌려보내 줘요. 엉뚱한 가짜 사이트가 확인표를 가로채지 못하게 하는 장치예요. 그래서 주소가 한 글자만 달라도 로그인이 통째로 막혀요. 아래 사고 표에서 다시 나와요.

붙이기 전에 준비하는 것

코드보다 절차가 먼저예요. 그리고 이 절차의 앞 절반은 개발자가 아니라 계정 주인인 사장님이 해야 해요. 순서대로 이래요.

1그 회사의 개발자 사이트에 가입해요. 카카오·구글·네이버·애플마다 따로예요. 이 계정이 내 서비스의 열쇠 꾸러미라서, 외주 개발자 개인 계정이 아니라 사장님 계정으로 만들어요.
2내 서비스를 앱으로 등록해요. 서비스 이름·로고·주소를 적어요. 여기 적은 이름이 손님의 동의 화면에 그대로 떠요.
3키를 발급받아요. 보통 공개용 키와 비밀 키 두 가지가 나와요. 비밀 키는 API 키와 같은 급의 금고 물건이라, 화면 코드나 카톡으로 옮기면 안 돼요.
4돌아올 주소를 등록해요. 내 사이트의 실제 주소를 적어요. 개발용 주소와 실서비스 주소가 다르면 둘 다 등록해요.
5받을 정보 항목을 정해요. 닉네임·이메일처럼 꼭 필요한 것만 골라요. 항목에 따라 심사나 사업자 확인을 요구하는 곳이 있어서, 많이 고를수록 절차가 길어져요.

정보는 필요한 것만 받아요

동의 화면에 항목이 길게 늘어서면 손님이 그 자리에서 나가요. 그리고 받은 정보는 전부 개인정보 보관 책임이 돼요. 소셜 로그인의 장점이 부담을 줄이는 것인데, 항목을 욕심내면 장점이 사라져요. 시작은 닉네임과 이메일 정도면 충분하고, 필요해지면 그때 항목을 늘리는 쪽이 싸요.

확인해 보세요

외주 개발자가 "제 계정으로 카카오에 앱 등록해 둘게요"라고 해요. 어떻게 하는 게 맞을까요?

자주 나는 사고

소셜 로그인의 사고는 대부분 코드가 아니라 등록 정보와 실제가 어긋나서 나요. 증상으로 찾아보세요.

보이는 증상	실제로 벌어진 일	할 일
버튼을 누르면 오류 화면이 떠요. redirect 어쩌고라고 적혀 있어요	돌아올 주소가 등록된 것과 한 글자라도 달라요. http와 https, 마지막 빗금 하나 차이로도 나요	개발자 사이트에 등록된 주소와 실제 주소를 나란히 놓고 글자 단위로 비교해요
테스트에서는 되는데 정식 오픈하니 다른 손님은 로그인이 안 돼요	앱이 아직 개발 단계로 등록돼 있어요. 이 상태에서는 미리 적어 둔 테스트 계정만 통과시키는 곳이 있어요	개발자 사이트에서 앱을 정식 공개 상태로 전환해요. 심사가 필요한 항목이 있으면 여기서 걸려요
로그인은 되는데 이메일이 비어서 들어와요	그 항목을 선택 동의로 열어 둬서 손님이 체크를 풀었거나, 항목 등록을 안 한 거예요	이메일이 꼭 필요하면 필수 동의로 바꿔요. 항목에 따라 심사가 붙을 수 있어요
어느 날 갑자기 그 버튼만 전부 안 돼요	비밀 키가 재발급됐거나, 그 회사 쪽 장애거나, 심사 조건 위반으로 앱이 제한된 경우예요	그 회사의 공지와 개발자 사이트 알림부터 확인해요. 내 코드는 그대로인데 멈췄다면 원인은 대개 저쪽이에요

장면 · 오픈 첫 주에 외주 개발자가 말했다

“기능은 다 됐는데, 카카오 검수가 아직이라 이메일 항목은 다음 주부터 받을 수 있어요.”

코드 완성과 심사 통과는 다른 날짜예요. 심사는 며칠에서 몇 주가 걸리고 반려되면 다시 그만큼이에요. 오픈 날짜가 정해져 있다면 심사가 필요한 항목을 먼저 파악해서 절차를 제일 앞에 시작해야 해요. 일정표에서 심사는 코드 뒤가 아니라 맨 앞줄이에요.

AI에게 그대로 말하는 문장

용어를 몰라도 돼요. 왼쪽에서 내 상황을 찾아 오른쪽 문장을 그대로 보내면, 필요한 절차와 코드가 갈라져서 나와요.

내 상황	그대로 보낼 문장
처음 붙이려고 해요	"카카오 로그인을 붙이고 싶어요. 제가 직접 발급받아야 하는 키와 등록해야 하는 주소를 순서대로 목록으로 주세요."
받을 정보를 정하고 싶어요	"손님에게 닉네임과 이메일만 받을게요. 그 이상은 요청하지 말아 주세요."
여러 개를 붙일지 고민이에요	"카카오와 구글 두 가지를 넣으면 관리 부담이 얼마나 늘어나는지 먼저 알려 주세요. 보고 정할게요."
오류 화면이 떠요	"카카오 로그인 버튼을 누르면 나오는 오류 문구를 그대로 붙여 넣을게요. 등록 정보 문제인지 코드 문제인지 갈라 주세요."
직접 가입도 남길지 고민이에요	"소셜 로그인과 이메일 가입을 같이 두는 구조로 해 주세요. 한쪽이 멈춰도 로그인 길이 남게요."

직접 해보기

첫 줄 문장부터 보내 보세요

스튜디오에서 지금 만드는 것이 있으면 첫 줄 문장을 그대로 보내 보세요. 사장님이 할 일과 AI가 할 일이 목록으로 갈라져 나오는지를 확인하는 게 목적이에요. 키 발급과 주소 등록은 계정 주인만 할 수 있어서, 이 목록 없이 시작하면 중간에 반드시 한 번 멈춰요.

스튜디오에서 물어보기

자주 묻는 것

Q. 직접 가입을 없애고 소셜 로그인만 둬도 되나요?: 가능은 한데 두 가지를 재 보세요. 그 회사에 장애가 나면 내 서비스의 로그인 길이 통째로 닫히는 것, 그리고 그 소셜 계정을 안 쓰는 손님은 가입 자체를 못 하는 것이에요. 손님층이 넓다면 이메일 가입 하나는 남겨 두는 쪽이 안전해요.
Q. 카카오로 가입한 손님이 다음에 구글로 로그인하면 어떻게 되나요?: 아무 처리를 안 하면 같은 사람의 계정이 두 개 생겨요. 주문 이력이 갈라지고 손님은 "제 주문이 사라졌어요"라고 문의하게 돼요. 이메일이 같으면 하나로 합칠지, 아예 별개로 둘지를 만들기 전에 정해야 해요. 나중에 합치는 쪽이 훨씬 비싸요.
Q. 아이폰 앱으로도 낼 계획인데 뭘 미리 알아야 하나요?: 앱스토어에 앱을 내면서 다른 소셜 로그인을 넣으면 애플 로그인도 함께 넣으라고 요구하는 심사 규정이 있어요. 웹만 할 때는 상관없지만 앱 계획이 있으면 처음부터 자리를 잡아 두는 게 편해요. 심사 이야기는 앱 심사에 있어요.
Q. 손님이 탈퇴하면 카카오 쪽에도 뭘 해야 하나요?: 내 서비스의 계정 정보를 지우는 것과 별개로, 그 손님과 카카오 사이의 연결 끊기 처리를 같이 해 주는 게 깔끔해요. 안 하면 손님의 카카오 설정에 내 서비스가 계속 연결된 것으로 남아요. 지울 정보의 범위는 보관 기간과 파기 기준을 따라요.
Q. 소셜 로그인이면 세션이나 토큰은 몰라도 되나요?: 관문만 바뀐 거라 그 뒤는 똑같이 필요해요. 확인이 끝난 손님을 기억하는 건 세션과 쿠키고, 앱과 웹이 계정을 같이 쓰게 하려면 토큰으로 로그인 유지하기 이야기가 이어져요.

하나 더

테스트할 때는 잘 되던 카카오 로그인이, 정식 오픈 날 사장님 계정으로만 되고 다른 손님은 전부 막혔어요. 가장 먼저 볼 곳은?

더 깊이 (안 읽어도 괜찮아요)

임시 코드를 한 번 더 바꾸는 이유 · 카카오가 손님을 돌려보낼 때 손님 정보를 바로 주지 않고 임시 코드를 줘요. 내 서버가 그 코드에 비밀 키를 얹어 다시 조회해야 진짜 정보가 나와요. 번거로워 보이지만 이유가 있어요. 돌아오는 길은 손님의 브라우저를 지나는 길이라 엿보일 수 있는데, 임시 코드는 엿보여도 비밀 키가 없으면 못 써요. 즉 길에서 새도 안전한 것만 길로 보내고, 진짜 정보는 서버끼리의 직통으로만 오가는 구조예요.

비유가 다른 지점 하나 · 회원 카드 비유에서 본사는 회원이 맞는지만 확인해 줘요. 실제 소셜 로그인은 거기에 더해, 손님이 동의한 범위 안에서 정보를 건네주고 그 범위를 손님이 나중에 철회할 수도 있어요. 손님이 카카오 설정에서 내 서비스와의 연결을 끊으면, 다음 로그인 때 동의 화면이 다시 떠요. 연결이 한 번 맺으면 끝나는 제휴가 아니라 손님이 계속 쥐고 있는 스위치라는 점이 비유와 다른 부분이에요.

버튼 수와 관리 부담은 비례해요 · 카카오·구글·네이버·애플을 다 붙이면 화면은 그럴듯해 보여요. 대신 개발자 계정 네 개, 키 네 쌍, 심사 절차 네 벌, 정책 변경 공지 네 군데를 계속 따라가야 해요. 실제로는 내 손님이 주로 쓰는 한두 개로 시작해서, 가입 이탈 숫자를 보고 늘리는 쪽이 관리 비용 대비 이득이에요. 버튼 하나하나가 유지보수 대상이라는 걸 잊지 않으면 돼요.

이것만 기억하세요

·소셜 로그인은 손님 확인만 카카오·구글에 맡기는 제휴예요. 비밀번호는 내 서버에 아예 안 와요
·버튼보다 절차가 먼저예요. 개발자 사이트 등록, 키 발급, 돌아올 주소 등록, 정보 항목 심사예요
·등록 계정은 사장님 것으로 만들어요. 그 계정이 로그인 기능의 소유권이에요
·사고의 대부분은 등록 정보와 실제의 어긋남이에요. 주소 한 글자와 앱 공개 상태부터 봐요
·받는 정보는 필요한 것만요. 항목이 늘수록 동의 화면 이탈과 개인정보 책임이 같이 늘어요