당근의 인증은 어떻게 달라져 왔을까요?

안녕하세요? Identity Service Team의 Software Engineer 키(Key)입니다.

Identity Service Team은 당근의 회원과 인증을 책임지고 있는 팀이에요.

당근뿐 아니라 대부분의 서비스에서, 인증은 서비스를 시작하려면 꼭 한 번은 거쳐야 하는 단계예요. SMS 인증부터 본인인증까지 방식은 다양하지만, 모든 인증이 하려는 일은 결국 하나예요. '이 계정의 주인이 나'라는 걸 확인하는 것.

그럼 당근은 '이 계정의 주인이 나'라는 걸 어떻게 확인해 왔을까요? 서비스가 성장하면서 어떤 문제를 만났고, 그 문제를 어떻게 풀어왔을까요? 지금부터 당근 인증의 역사를 하나씩 들려드릴게요.

당근의 초창기 로그인

처음에는 SMS 인증이었어요.

당근마켓은 모바일 앱으로 시작한 서비스예요. 모바일 기기는 전화와 문자를 주고받을 수 있죠.

앱에 자신의 전화번호를 입력하면 그 번호로 인증 문자가 오고, 도착한 인증번호를 다시 당근에 입력하는 거예요.

문자로 온 인증번호를 입력할 수 있다는 건 "이 전화번호를 쓰는 단말기를 지금 손에 쥐고 있다"는 뜻이에요. 말 그대로 번호의 '점유'를 확인하는 거죠.

동네 사람끼리 중고거래를 하는 데 필요한 인증으로는 그 정도 확인으로도 충분했어요.

무엇보다 간편하고 직관적이었고요. 가입 문턱을 낮춰서 더 많은 사람이 당근을 쓰게 하는 데 집중한, 최소한의 인증이었어요.

"이 계정은 분명히 제 것이에요"

그런데 서비스가 성장하면서 문제가 하나둘 나타나기 시작해요.

가장 많이 마주친 건 계정을 잃어버린 사용자였어요.

전화번호는 영원히 내 것이 아니거든요. 쓰던 번호를 해지하면 통신사는 일정 기간이 지난 뒤 그 번호를 다른 사람에게 다시 배정해요. 그래서 번호를 바꾼 뒤 새 번호로 당근에 로그인하면, 내가 쓰던 계정이 아니라 새 계정이 만들어져요. 그동안 거래하고 대화한 기록은 예전 계정에 남은 채로요.

기기를 바꿔도 마찬가지였어요. 번호 말고는 이 사람이 예전의 그 사람이라는 걸 확인할 방법이 없으니까요.

"번호를 변경해서 인증은 못하지만, 이 계정은 분명히 제 것"이라며 계정을 되찾아 달라는 문의가 매일 들어왔어요.

번호가 곧 계정이던 시절엔, 이런 요청이 오면 고객센터에서 통신사 서류를 기반으로 옛 계정의 닉네임·동네·전화번호를 하나하나 대조해 손으로 계정을 옮겨 줘야 했어요. 사용자는 며칠을 기다려야 했고, 고객센터는 같은 일을 매일 반복해야 했죠.

백업 수단으로 이메일 인증도 추가해 봤어요. 번호를 잃어버려도 이메일로 계정을 되찾을 수 있게요. 그런데 미리 이메일을 등록해 두는 사용자가 많지 않았어요. 정작 계정을 잃어버린 사람에겐 등록된 이메일이 없었던 거예요.

여기에 사기 문제도 겹쳤어요. 알뜰폰처럼 번호를 쉽게 발급받을 수 있는 수단이 늘면서, 사기꾼들이 번호를 수백 개씩 만들어 계정을 찍어냈어요. 한 계정이 제재되면 다른 번호로 새 계정을 만들어 사기를 이어 갔고요.

번호를 확인하는 것만으로는, 계정을 잃은 사람도 되찾아 줄 수 없고 돌아오는 사기꾼도 막을 수 없었어요.

본인인증을 도입했어요

그래서 본인인증을 도입했어요. 본인확인기관을 통해 실명과 CI를 확인하는 단계예요. CI(연계정보)는 사람마다 하나씩만 부여되는 값이라, 번호가 바뀌든 기기가 바뀌든 '같은 사람'이라는 걸 증명할 수 있어요.

※ CI란? 주민등록번호를 한 번 비가역적으로 암호화해 만든 값이에요. 그래서 서비스가 달라도 같은 사람이면 같은 CI가 나와요.

사실 어려운 건 본인인증을 붙이는 일 자체가 아니었어요. 이미 당근을 쓰고 있는 수천만 명의 사용자를 어떻게 할 것인가였죠.

신규 가입자에게 본인인증을 요구하는 건 비교적 간단해요. 문제는 이미 번호만으로 가입해 잘 쓰고 있는 기존 사용자예요. 어느 날 갑자기 앱을 열었더니 "본인인증을 해야 계속 쓸 수 있어요"라는 화면이 뜬다면, 상당수는 인증 대신 앱을 닫아 버릴 테니까요.

새로 가입하는 사용자에게는 본인인증을 강제화하는 선택을 할 수 있었어요.

다만 기존 사용자에게는 본인인증을 강제하는 대신 본인인증을 할 이유를 만들어 주는 쪽을 택했어요. 본인 확인이 자연스럽게 필요한 서비스를 접점으로 삼은 거예요. 예를 들어 생년월일이 필요한 사주 서비스처럼, 사용자가 원해서 쓰는 서비스 안에 본인인증을 놓아두면 사용자는 운세를 보러 온 김에 본인인증까지 마치게 돼요. 본인인증하고 신년 운세 확인하기

그렇게 시간을 들여 본인인증을 확산시켰어요.

이제 전화번호를 여러 개 만들어 사기를 치는 일이 어려워졌어요. 일반 사용자도 본인인증만 해두면, 전화번호를 바꾸더라도 쓰던 당근 계정을 그대로 이어서 쓸 수 있게 됐고요. 고객센터가 손으로 계정을 옮겨 주던 일도 크게 줄었어요.

이제 '이 계정의 주인이 누구인가'를 정확하게 확인할 수 있게 됐어요. 그런데 이번엔 다른 종류의 문제가 생기기 시작해요.

앱 말고 PC에서도 당근을 쓰고 싶어요

당근이 중고거래를 넘어 부동산, 중고차, 알바로 넓어지면서, 당근을 앱 밖에서 쓰고 싶은 사람들이 나타나기 시작했어요.

부동산 중개인과 중고차 딜러는 PC로 매물을 등록하고 싶고, 카페 사장님은 태블릿으로 공고를 올리고 싶어요. 그런데 당근 계정은 아직 모바일 앱 안에서만 쓸 수 있었어요.

처음엔 웹도 앱과 같은 인증 방식을 그대로 사용했어요. 전화번호 문자 인증으로 시작해서, PC 환경에서 많이 사용하는 QR 로그인을 도입했어요.

그런데 예상하지 못한 곳에서 문제가 생겼어요. 바로 모바일 웹이었어요.

PC에서는 QR 로그인이 잘 동작했어요. 당근에 로그인되어 있는 휴대기기로 QR 화면을 찍기만 하면 되니까요. 그런데 휴대기기에서 브라우저를 통해 접속한 사람은 QR 인증을 할 수 없었어요. 남은 인증 수단은 문자 인증인데, 이건 브라우저와 문자 앱을 오가며 번호를 옮겨 적어야 하죠. 그 사이에 적지 않은 사람들이 로그인을 포기했고, 모바일 웹의 인증 전환율은 눈에 띄게 낮았어요.

그래서 모바일 웹에서는 클릭 한 번으로 끝나는 당근앱으로 로그인을 만들었어요. 이미 휴대기기에 로그인된 당근 앱이 있다면, 웹에서 버튼을 누르는 것만으로 당근앱이 열려 인증을 확인하고 다시 웹으로 돌아오는 방식이에요.

어떤 서비스를 사용해도 동일한 인증 경험과 보안을 챙기는 것도 필요했어요.

부동산, 중고차, 알바를 비롯해 새로운 서비스가 계속 생겼고, 앞으로도 더 생길 예정이었어요. 이 서비스들이 모두 같은 당근 계정으로 로그인되어야 해요. 그러려면 여러 도메인에 걸친 서비스가 동일한 인증 토큰을 다뤄야 해요. 그런데 인증 화면과 로직, 토큰 관리를 서비스마다 각자 맡게 두면, 보안이 가장 약한 서비스가 전체 계정의 보안 수준이 돼요. 보안 취약점이 한 군데만 있어도 모든 서비스의 계정이 위험해지는 구조인 거죠.

그래서 웹 인증을 accounts.daangn.com이라는 하나의 도메인으로 통합했어요.

당근부동산을 예로 들어 볼게요. 부동산 웹(realty.daangn.com)에서 '당근으로 로그인'을 누르면 브라우저가 accounts.daangn.com으로 넘어가요. 인증은 거기서만 이뤄져요. 전화번호와 본인인증 같은 인증 수단으로 '이 계정의 주인이 맞는지'를 확인해요. 확인이 끝나면 인증 토큰과 함께 다시 부동산으로 돌아오고요.

이 구조는 OAuth 2.0/OIDC 표준 위에서 동작해요. 당근만 아는 방식이 아니라 인증 업계 표준을 따랐어요.

덕분에 각 서비스는 사용자의 인증을 고민하지 않아도 돼요. 로그인 화면을 매번 새로 만들 필요도 없고요.

이러한 기반 위에서 2차 인증을 비롯해 각 서비스의 요구에 맞는 인증 수단도 하나씩 더해 나갔어요.

당근 SSO 덕분에 기업부터 소상공인까지, 여러 외부 서비스도 당근 계정으로 로그인할 수 있게 됐어요.

글로벌은요?

당근은 북미와 일본에서 Karrot이라는 브랜드로 성장해 나가고 있어요. 그런데 한국에서 해온 인증 방식이, 국경을 넘는 순간 잘 통하지 않게 돼요.

처음 보는 앱에 전화번호를 알려 주기는 싫어요

한국에서 당근은 이미 많은 사람이 아는 서비스예요. 하지만 북미와 일본에서 Karrot은 아직 초기 서비스예요.

처음 써보는 앱이 전화번호부터 요구하면, 상당수가 중간에 이탈해요. 한국에선 거부감 없이 사용되는 휴대전화 인증이, 글로벌에선 가입 퍼널의 가장 큰 장벽이 된 거예요.

그래서 소셜 로그인을 도입했어요. 이미 쓰고 있는 다른 서비스의 계정으로 시작할 수 있게 해서 첫 관문을 낮추고, 가입 전환율을 끌어올린 거죠.

다만 나라마다 많이 쓰는 계정이 달라요. 일본에서는 LINE이 생활 깊숙이 자리 잡아 많은 서비스가 LINE 로그인을 쓰거든요. 그래서 일본은 LINE·Google·Apple을, 북미는 Google·Apple·Facebook을 붙였어요. 같은 '소셜 로그인'이라도, 나라의 생활 방식에 맞춰 조합을 다르게 가져간 거예요.

문자가 오지 않아요

북미는 땅이 넓고 통신사도 제각각이에요. 인증 문자가 늦게 오거나 아예 안 오는 일이 한국보다 훨씬 잦아요. 통신사의 스팸 정책에 걸려 문자가 차단되는 경우도 있고요.

적지 않은 마케팅 비용을 들여 데려온 사용자가, 문자 한 통이 안 와서 가입을 포기하고 돌아가는 거예요.

그래서 인증 문자를 받지 못한 사용자를 위해 Voice Call 인증을 도입했어요.

"문자가 오지 않았나요? Voice Call로 인증하기" 같은 버튼을 보여 주고, 문자 인증 때 입력한 휴대전화번호로 전화를 걸어 음성으로 인증번호를 불러 주는 방식이에요.

SNA(Silent Network Authentication)라는 방식도 실험해 봤어요. 사용자가 인증번호를 입력하는 대신, 유심을 통해서 통신사 네트워크가 "이 번호가 지금 이 기기에서 실제로 쓰이고 있는지"를 확인해 주는 SIM 기반 인증 방식이에요. 퍼널도 단축되고 문자가 아예 오가지 않으니, 문자가 안 와서 이탈하는 문제 자체가 사라지죠.

실험 결과 인증 정확도와 사용성은 실제로 좋아졌어요. 그런데 정작 우리가 기대했던 가입 전환율 상승은 끝내 검증되지 않았어요. 그래서 배포하지 않기로 했어요.

모든 시도가 배포로 이어지진 않아요. 실험해 보고, 아니라고 판단되면 과감히 중단해요.

이 사람을 믿어도 될까요?

거래를 하다 보면 상대의 신원을 확인해야 할 때도 있어요. 북미에서도 사기 문제가 심해지면서, 사용자끼리 서로를 믿을 수 있게 만드는 일이 중요해졌어요.

한국에서는 본인인증이 이 문제까지 자연스럽게 풀어 줬지만, 북미엔 그런 공통 신원 체계가 없죠.

그래서 Karrot은 KYC(Know Your Customer) 서비스인 Persona를 도입했어요. 여권이나 운전면허증 같은 정부 발급 신분증을 촬영하면 위조 여부를 확인하고, 셀피를 찍어 신분증 속 사진과 같은 사람인지까지 대조하는 방식이에요.

한국에서 잘 되던 방식을 고집하기보다는, 그 나라의 통신·법·신원 환경에 맞는 인증을 계속 고민해 나가고 있어요.

AI가 당근에 로그인하려면요?

최근에는 새로운 종류의 '사용자'가 찾아왔어요. 사람이 아니라 AI예요.

Claude나 ChatGPT에게 "내 당근 광고 성과 좀 정리해 줘"라고 부탁하는 시대가 됐어요. 당근의 정보를 AI가 활용할 수 있도록 MCP(Model Context Protocol) 서버를 준비하면서, 새로운 인증 문제와 마주했어요.

AI가 당근에 접근할 때, 어떻게 인증하고, 어떤 권한으로 어디까지 허용할 것인가예요.

MCP 표준은 OAuth 2.1 기반 인증을 요구하고, 모든 연결은 반드시 사용자 본인의 동의를 거쳐야 해요. 다행히 당근 SSO는 처음부터 OAuth 표준 위에 만들어 뒀기 때문에, 표준을 따라 자연스럽게 확장할 수 있었어요.

'이 계정의 주인이 나'라는 걸 확인하던 인증이, 이제 '내가 허락한 만큼만 AI에게 위임하는' 인증으로 확장되고 있어요. AI 클라이언트는 사용자 동의를 거쳐, 필요한 만큼만 잘라낸 권한을 받아요

같이 만들어요

Identity Service Team은 가입 퍼널의 병목을 없애고 유저의 전환율을 높이면서도, 가장 안전한 인증 방식은 무엇일지 고민하는 팀이에요.

이런 고민을 같이 해나갈 분을 찾고 있어요. 당근의 회원/인증을 함께 만들어나가고 싶으시다면 주저하지 말고 지원해주세요! 2분기 워크샵, 우리가 풀어야 할 문제들을 좁혀 가는 중이에요

---

당근의 인증은 어떻게 달라져 왔을까요? was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.