직접 인증 시스템을 만들지 말아야 하는 이유: 수십 번의 고객 인터뷰에서 얻은 교훈

인증은 직접 만들 수 있을 것처럼 보입니다. 이메일, 비밀번호, 해싱, 로그인 시 비교. 직접 인증 시스템 만들기가 뭐가 그리 어렵겠어?

만들 수 있습니다. 그게 함정입니다.

우리는 직접 인증 시스템을 만든 수십 개 팀과 이야기해왔습니다. 대부분 우리를 찾은 이유는 같았습니다: 비즈니스를 발목 잡고 있었기 때문입니다.

산업, 기술 스택, 규모는 달랐지만 결론은 같았습니다. 직접 만든 인증 시스템이 팀이 짊어진 부담, 즉 부채가 되어버렸습니다.

이상한 점은, 이런 문제는 장애로 드러나지 않는다는 것입니다. 시스템은 잘 로그인을 처리하고 정상적으로 운영되었습니다. 하지만 사업이 한번 바뀌는 순간에 그 부담이 고스란히 드러났습니다: 보안 심사, 처음으로 들어온 엔터프라이즈 고객, 인수합병, 두 제품에 걸친 기능 등.

불과 지난주만 해도 "문제없음"이었습니다. 그런데 다음 로드맵 과제가 그 뒤에 걸려 막힙니다.

직접 만든 인증에서 가장 큰 실수는 이것을 단순한 "기능"으로 여기는 것입니다. 출시 첫날은 코드를 금방 쓸 수 있습니다. 하지만 실제 유저 트래픽이 몰리면, 유저, 조직, 권한 관리 등과 얽히기 시작합니다.

인증은 기능이 아닙니다. 그건 정체성(Identity) 인프라입니다.

로그인 페이지 뒤에는 완전히 별개의 정체성 모델이 있다#

직접 만든 인증 시스템은 항상 비슷하게 시작합니다. 이메일과 비밀번호를 받아서, 해싱해 저장하고 로그인시 비교합니다. 40줄 코드로 끝내버리죠.

문제는 출시 이후 시작됩니다. 로봇이 회원가입 엔드포인트를 두드리기 시작하면, 속도 제한과 CAPTCHA, 디바이스 지문 채크를 덧붙입니다. 어느날 갑자기 문자 인증이 안나가면, 재전송과 일일 제한을 추가합니다. 다음은 더 어렵습니다: 안전한 비밀번호 재설정, MFA 및 복구 플로우, 세션/리프레시 토큰, 단순한 is_admin 불린을 넘는 권한 모델.

각 기능 자체는 어렵지 않아요. 각각은 스프린트 하나짜리입니다. 하지만 매번 하나씩 추가할 때마다, 제품의 더 큰 질문에 답하고 있는 겁니다.

이 답들이 쌓이면, 그게 곧 당신 제품이 조용히 가정하고 있는 정체성 모델이 됩니다: 누가 유저인지, 한 사람이 여러 조직에 속할 수 있는지, 엔터프라이즈 고객의 자체 인증시스템을 어떻게 연결할지, 누가 나갔을 때 액세스를 어떻게 회수할지.

이 후에 새로 쓰는 모든 기능은 그 답을 ‘당연한 것’으로 간주하게 되고, 운영 기간이 길어질수록 변경은 더 어려워집니다.

한 회사에서 이 문제를 봤습니다. 20년 된 B2B SaaS로, 오프라인 사업자를 대상으로 합니다. 십여 년 전에 자체 인증을 구축했고, 고객마다 로그인과 권한 검사를 사업 모듈에 직접 박아 넣었습니다. 그땐 적절했습니다.

20년 후, 이메일을 아이디로 하나의 통합 로그인 페이지를 원했습니다. 단순히 페이지 바꾸기가 아니었습니다. 그 체크 로직이 수백 모듈에 퍼졌고, 로그인 통합은 유저 그리고 조직 모델, 자격 증명 마이그레이션, 권한 경계까지 다 건드려야 한다는 뜻이었습니다. 누구도 쉽게 변경을 승인할 수 없어, 여러 해 동안 질질 끌렸습니다.

처음 로그인 페이지를 쓸 땐 기능 같았지만, 남긴 것은 전체 정체성 모델이었습니다.

비즈니스가 성장하면, 직접 만든 인증은 한계에 봉착한다#

공정하게 보자면 직접 만든 인증은 오랫동안 잘 돌아갑니다. 로그인 처리, 세션 관리, 하루하루 업무는 문제 없이 처리하죠. 복잡함은 느리게 쌓입니다. 여유 있어 보이니까 관리하는 데 부담 없다고 여깁니다.

하지만 그저 '충분하다'는 건, 비즈니스가 아직 벽에 박지 않았다는 뜻일 뿐입니다. 한 번 벽에 닿으면, 문제는 보통 인증 그 자체가 아닙니다. 함께 가던 비즈니스가 바뀌고, '충분하다'는 하루아침에 '발목'이 됩니다.

아래 상황들은 제품이 커지면서 대부분 겪는 일입니다. 겉모습은 다르지만 본질은 같습니다. 비즈니스는 성장했고, 옛 정체성 모델은 더 이상 버틸 수 없게 됐습니다.

엔터프라이즈 고객이 SSO를 요청한다#

상황: 고객이 자체 IdP(Identity Provider)로 로그인하고 싶어하는데, 인증 시스템에는 '타사 인증 제공자'라는 개념이 전혀 없다.

첫 대형 고객이 계약 단계에 들어가고, 조달 팀에서 요구사항을 보냅니다. 처음엔 마이크로소프트 Entra 나 구글 워크스페이스로 SSO 요청입니다. 다음은 SAML과 OIDC 둘 다, 왜냐하면 또 다른 고객은 또 다른 시스템을 사용하기 때문입니다. SCIM까지 요청하며 구성원 자동 프로비저닝/삭제도 요구합니다.

고객마다 프로토콜, 필드 매핑, 인증서 갱신, 조직 구조 매핑이 다 다릅니다.

그리고 대부분은 재사용되지 않습니다. 다음 고객이 또다른 IdP와 새로운 셋팅을 가져오면, 거의 처음부터 다시 시작입니다. SSO는 한번 만들면 끝나는 기능이 아닙니다. 새 고객 계약마다 다시 짓는데, 고객 수가 늘수록 비용은 계속 커집니다.

이젠 인증이 '프로덕트에 로그인'이 아닙니다. '프로덕트가 고객의 인증 시스템에 연결되게'가 본질이죠. 완전히 다른 일이 됐습니다.

어떤 회사는 SSO설정을 전부 사람 손으로 했고, 전체 상황을 아는 엔지니어가 한 명뿐이었습니다. 그가 있으면 고객이 출시되고, 휴가를 가면 세일즈와 온보딩이 줄을 섭니다. 나가버리면, 노하우도 사라집니다.

직접 인증 만들겠다고 했을 때는, 이런 일은 전혀 생각지 못했습니다.

흩어진 정체성 데이터를 통합해야 할 때#

상황: 정체성 데이터가 조직, 제품별로 분산되어 출발했는데, 사업 성장하며 통합 아이덴티티가 필요해졌다.

위에서 말한 20년 회사도 로그인 통합 도전 중 이걸 겪었습니다. 인수로 생긴 아홉 개의 제품이 각각 인증, 유저 데이터베이스를 따로 챙기고 있던 플랫폼과 같이요.

인수가 자동으로 인증을 통합해주진 않습니다. 제품을 살수록 인증 스택이 하나씩 늘고, 아홉 개를 병렬로 관리하려면 실제 리소스 투입이 필요해집니다.

질문이 쌓입니다. 같은 사람이 제품 A와 B에서 하나의 사용자인가, 둘인가? 같은 고객 조직을 두 제품에서 어떻게 일치시키나? 넘나드는 기능의 권한은? 직원이 퇴사하면 아홉 개 제품에서 동시 권한 회수, 로그 감사는 어떻게?

개별적으로는 다 문제없습니다. 하지만 한데 모이면, 거대한 벽이 됩니다.

“아이덴티티 통합”은 기능 같지만, 코드로 보면 제품의 근간인 “유저”와 “조직”의 정의 자체를 바꿔야 한다는 뜻입니다. 대부분의 기능이 그 구 정의 위에 얹혀 있기 때문에, 구조를 움직이면 윗단이 다 흔들립니다.

AI 시대, 에이전트와 CLI 도구가 유저를 대신해 접근한다#

상황: 이제는 브라우저로 직접 로그인하는 사람만 있는 게 아닙니다. 에이전트, 명령창, 스크립트가 유저를 대신해 행동한다고 주장하지만, 당신의 인증은 ‘사람이 페이지에 로그인한다’만 전제로 되어 있습니다.

에이전트가 내부 도구를 유저 대신 콜해야 합니다. MCP 서버는 보호 자원에 안전하게 노출해야 하고, CLI는 브라우저 없이 계정 데이터에 접근해야 하죠.

셋 다 묻습니다. 이 요청의 유저는 누구, 어떤 자원에 접근 가능, 토큰의 주체와 범위, 회수 방법, 로그는 유저 기준 or 에이전트 기준?

옛 시스템은 이런 클라이언트가 필요로 하는 메커니즘이 없습니다. MCP는 권한 부여용 OAuth에 의존하고, CLI는 OAuth 로그인을 통하거나 사용자 대신 쓰는 Personal Access Token을 돌립니다. 모두 로그인 페이지용이 아닙니다.

인증 시스템이 '사람 로그인'에 맞춰 설계됐다면, 이제 곧 대리 클라이언트 처리 메커니즘을 고민해야할 때입니다.

직접 만든 인증 시스템의 최대 비용은 유지보수다#

위 상황들은 단순히 '인증 다운됨'이 아닙니다. 시스템은 계속 돌아갑니다. 다들 단순해보이는 기능인데, 막상 착수하면 전략, 데이터 마이그레이션, 고객 전달 문제로 번집니다.

MFA가 대표적입니다. 겉으론 "로그인 후 한 번 더 검증"이죠.

두 걸음만 들어가도 "어떤 조직과 유저에 강제 적용할지", "관리자가 멤버에게 강제 적용 가능한지", "결제 정보 변경 등 민감 작업 추가 검증 필요 여부", "복구 코드 발급/초기화, 지원팀 리셋/권한 여부", "SSO 유저의 MFA가 내 것인지 고객 IdP의 것인지" 따위로 번집니다. MFA 도입은 보안 정책 레이어 전체를 깔아야 한다는 뜻입니다.

“유저 싱크만 하면 돼”도 똑같아요. 도입 뒤엔 온보딩·퇴직·조직 간 멤버십 등 결정이 연쇄적으로 따라오고, 이 모든 것이 유저/조직 모델이 애초 제대로 설계되었음을 가정합니다.

기능을 추가할수록, 실제로는 제품 안에 신원 인프라 제품 하나를 더 유지하는 셈입니다. 첫 버전은 싸게 며칠 만에 만들 수 있습니다. 하지만 매년, 계속 리소스를 쏟아야 합니다.

숨겨진 비용: 비용 구조만 달라졌을 뿐#

직접 만드는 가장 흔한 이유는 비용입니다. 단순한 것도 아닙니다.

어느 회원 조직이 다섯 해 전 계산기를 두드렸습니다. 회원은 10만명이 넘지만, 실제 로그인은 몇 천 명뿐이었습니다. 업체들은 전체 회원 수 기준 과금했고, 견적은 예산을 초과했습니다. 직접 개발이 당시엔 더 쌌죠.

5년 뒤, 계산이 완전히 달라졌습니다. 자체 로그인 유지·보안 관리에 이미 사서 쓰는 것보다 더 들었습니다.

1년차엔 절감한 비용은 눈에 보이고, 엔지니어링 시간은 안 보입니다. 5년차엔 절감분 숫자가 그대로지만, 엔지니어링 시간은 로드맵 지연, 보안 부채, 인수인계 불가로 바뀝니다.

자체 인증 시스템은 '무료'가 아닙니다. '인증 구독료' 청구서만 없을 뿐입니다. 대신 인건비, 일정 지연, 리팩토링, 보안 부채, 제품 본질에 쓰여야 할 엔지니어링 리소스로 대신 지불하게 됩니다.

소수의 엔지니어만이 모든 맥락을 책임진다#

위에서 봤던 손수 SSO를 관리하는 엔지니어는 흔한 케이스입니다. 직접 만든 인증 시스템을 오래 굴리다 보면 필수 맥락이 자연스레 한두 명에게 집중됩니다: "어떤 고객이 어떻게 구성되어 있나", "어떤 필드는 건드리면 안 되나", "왜 예전 이관은 저런 식으로 했나" 등. 문서화는 되지 않고, 누군가의 머릿속에만 남습니다.

그 사람이 있으면 인계·전달이 되지만, 떠나면 엔터프라이즈 구매부터 온보딩까지 멈추고 결국 가장 중요한 인프라는 아무도 주인 없이 "아는 사람" 몫이 됩니다.

어떤 팀은 아예 셀프 서비스 SSO 구성 플랫폼까지 만듭니다. 성숙해 보이지만, 실제로 이 구조를 활용하는 고객 수를 물으면 놀랍니다. 월간 150만 명 유저 제품에 이 시스템을 쓰는 고객이 겨우 12개였습니다.

기능 하나 만들었다 생각했지만, 실제로는 고작 몇몇 고객을 위해 내부 인프라 제품 하나를 운영한 것과 다름없습니다. 본업이 아이덴티티라면 그럴 가치가 있습니다. 아니라면, 그게 진짜 숨은 비용입니다.

당신의 엔지니어를 어디에 쓸 것인가?#

앞서 언급한 20년 된 SaaS 얘기로 돌아가봅시다. 그들은 약한 엔지니어가 아니었습니다. 20년 이상 업계 제품을 살아남게 한 게 곧 그들이 고객을 잘 안다는 증거입니다.

그게 바로 문제입니다. 단도직입적으로 말해서, 각 고객마다 SSO를 손수 관리하고, 20년치 권한 로직을 온갖 모듈에서 걷어내는 데 엔지니어들이 매달리는 게 맞을까요, 아니면 업계 소프트웨어 자체 깊이를 키우는 게 맞을까요?

이건 엔지니어링 완벽주의가 아닙니다. 리소스 배분의 문제입니다. 만약 당신이 송금 시스템, 버티컬 SaaS, 회원 포털, 업무 소프트웨어 업체라면, 누군가 당신이 직접 쓴 OAuth 서버 덕에 추가 돈 내진 않습니다.

한 송금팀도 명확히 말했습니다. 우리 IdP는 문제 없지만, 전략적 선택이다. 인증엔 코드를 적게 쓰고, 본질(송금)에 집중하자. 그리고 인증은 가장 검증된 걸 쓰면 “나머지는 그냥 끝”입니다.

인증은 반드시 안정적이어야 하지만, '직접 만들었음'이 곧 안정과 동의어는 아닙니다. 데이터베이스, 메일 발송, 클라우드 모두 안정적이어야 하지만, 웬만한 팀이라면 중대한 만큼 반드시 사내 구축을 고집하지는 않죠.

대부분의 제품에서 인증은 필수 의존성이지만, 차별화 포인트는 아닙니다. 아이덴티티가 본업이 아니라면, 내부에 신원 인프라 제품 하나를 끌어안는 건 경쟁력이라기보단 지속적인 리소스 소모입니다.

언제 직접 인증 시스템을 만들어도 괜찮을까?#

"절대 인증 코드 쓰지 말자"란 극단에 빠질 필요는 없습니다.

특정 단계에서는 직접(혹은 반 정도) 만드는 게 완전히 타당합니다: 내부 데모, 아주 초창기 프로토타입, 일회성 검증 프로젝트 등. 그리고 비즈니스에 정말 특화된, 기성 플랫폼이 표현 못 하는 정밀 권한 통제가 필요하다면 인증, 세션, SSO, MFA, 유저 디렉토리 등은 외부 플랫폼에 맡기고 핵심만 자체 유지하는 것도 당연히 합리적입니다.

다만 POC(개념검증)의 경사로에 주의해야 합니다. 흔히 봤던 경로: 두 개발자가 여섯~여덟 달을 투자해 외부 시스템과 연동하는 프로토타입을 만들었고, 방식 자체는 나쁘지 않지만, 그건 확장성 염두에 둔 시스템이 아니었습니다.

POC는 장기 아키텍처로 굳히기 가장 쉽습니다. 6개월 뒤 "임시 방안"이었고, 2년 뒤엔 "레거시 시스템", 5년 뒤엔 "누구도 손 못 대는 인프라"로 버티고 있죠. 직접 인증에서 벗어나야 할 최적기는 망가진 다음이 아니라, 근간이 되기 전에 빠지는 시점입니다.

결론은 이렇습니다: 인증 코드 한 줄이라도 썼냐가 아니라, 정형적 신원 인프라 ‘전체’를 팀에 장기 부담으로 끌어안았는지가 포인트입니다.

엣지 케파(핵심 경쟁력)는 직접 만들고, 신원 핵심 레이어는 조심하세요. 자기도 모르게 전체 CIAM 플랫폼(고객 신원/접근 관리)을 만드는 일이 없도록 하세요.

직접 만들지 않는다면, 어떤 인증 솔루션을 고르나?#

직접 만들지 않기로 했다면, 다음 질문이 바로 나옵니다. "그럼 뭘 사지?" "어떻게 고를까?"

성숙한 솔루션들은 이미 SSO, MFA, 다조직, 통합 로그인, 에이전트 접근 등 대부분의 기능은 갖추고 있습니다. 결과적으로 실질적인 차별점은 기능 표가 아닙니다.

의외로 간과하기 쉬우면서 중요한 비교 포인트는 다음 같습니다. 요지는 이렇습니다: 몇 천 줄 직접 짠 코드에서 해방된 뒤, 또 다른 시스템에 갇히는 실수를 반복하지 마세요.

• 벤더가 새로 만든 프로토콜 말고, 표준 프로토콜로 가세요. OIDC, OAuth, RS256 서명 JWT 등은 이미 이해하는 방식입니다. 표준 토큰에서 바로 클레임을 읽으면 되고, 벤더 전용 API를 배울 일이 없습니다.
• 진짜 나올 수 있는 출구를 확보하세요. 오픈소스고 셀프호스트라면 언제든 나올 수 있습니다. (셀프호스트 장기 운영도 별도 숨은 비용입니다.)
• 과금이 유저 테이블 기반이면 피하세요. 등록 유저/월간액티브 등은 계속 늘고, 몇 년만에 실제 로그인 안 하는 유저로 가득 채워지며 규모 커지면 '성장세'가 요금 폭탄으로 이어집니다. 아까 말한 회원 조직이 이 모델 때문에 직접 개발에 손댄 케이스입니다.
• 데이터를 언제든 추출 가능해야 합니다. 언제든 유저 데이터를 뽑을 수 있어야 하고, 민감 정보를 전문 호스트에 맡기면 애초에 직접 민감 데이터를 지키는 리스크도 줄입니다.

참고로 Logto는 바로 이 네 가지 포인트 극복을 위해 우리가 만든 인증 제품입니다. 오픈소스, 셀프호스트 가능, 매니지드 클라우드 제공: Cloud는 유지보수 없이, 오픈소스 버전은 완전 제어로. 언제든 옮길 수 있죠.

OIDC 표준 기반에, MFA/SSO/RBAC 나와서 바로 쓸 수 있습니다. 과금은 토큰 기준이라 실제 사용하는 만큼 냅니다.

이 외에도 성숙한 옵션은 많이 있습니다. 인증은 항상 정답이 하나뿐인 영역이 아닙니다. 혹시 비교 중이면, 인증 솔루션 선택법 글을 참고해도 좋습니다.

결론: 장기 신원 인프라를 ‘일반 기능’으로 착각하지 마세요#

직접 인증 시스템을 만드는 건 1일차엔 늘 괜찮아 보입니다. 실제로는 시간이 지나며 인프라로 변합니다.

비즈니스가 한 걸음 나아갈 때마다 다시 드러납니다: 엔터프라이즈는 SSO, 보안팀은 MFA, 제품은 통합 로그인, 여러 제품 연결, AI 에이전트가 유저를 대신해 리소스 접근 등. 작아보이는 기능마다 연쇄 정책 질문이 숨어 있고, 수년간 쏟아내야 할 엔지니어링 시간이 본질에 쓰이지 못합니다.

이 청구서는 1일차엔 오지 않습니다. 수년 뒤 드러나고, 그제야 알게 되죠. 그 로그인 페이지가 이미 제품 라이프 전체에 깔리는 신원 인프라였다는 걸요.

대부분 본업이 인증은 아닐 겁니다. 그걸 깨닫는 시점이 곧 자원, 시간, 에너지를 본질 제품에 다시 투자할 수 있는 시기입니다.

FAQ#

직접 인증 시스템은 절대 만들면 안 되나?#

아닙니다. 초기 데모·내부툴·일회성 검증·기성 제품이 커버 못 하는 세밀한 권한 통제 등은 직접/부분제작이 타당합니다. 피해야 할 것은 '장기 범용 신원 인프라' 전체를 자기도 모르게 맡아, 팀에 안착시키는 것입니다.

인증과 권한 부여(Authorization)의 차이는?#

인증은 "너 누구냐"에 답하고, 권한 부여는 "무엇을 할 수 있나"에 답합니다. 실제 SaaS에선 둘을 분리하기 어렵습니다. 유저, 조직, 역할, 권한, 세션, 토큰 클레임, 로그가 다 얽혀 있죠. 인증 교체는 로그인 페이지만 볼 문제가 아닙니다.

왜 엔터프라이즈 SSO가 직접 인증을 어렵게 하나요?#

고객의 아이덴티티 시스템에 내 제품을 연결해야 하기 때문입니다. 고객마다 IdP, 프로토콜, 클레임 필드, 인증서, 조직 매핑이 모두 다릅니다. 첫 연결만 통과해도 다 해결되는 게 아닙니다. 대부분은 엔지니어 한 명이 온갖 수작업을 해야만 처리됩니다.

우리는 수년째 직접 인증 중입니다. 이관 가능할까요?#

네, 그런데 완전 빅뱅식 교체는 보통 비추천입니다. 계층적으로 이전하세요: 신규 회원가입, 로그인, 엔터프라이즈 SSO부터 아이덴티티 플랫폼에 옮기고, 기존 유저는 다음 로그인 시점에 마이그레이션합니다. 항상 롤백과 로그 감사를 열어두어, 이관이 돌이킬 수 없는 일이 되지 않게 하세요.