인증 시스템, 하루 만에 만들 수 있습니다. 그게 바로 함정입니다.
수십 개 B2B 팀 모두 같은 이야기를 들려줬습니다. 단순한 로그인 페이지로 시작합니다. 하지만 트래픽이 몰리면, 조용히 아이덴티티 인프라 — 제품 전체가 떠받치는 기반 — 로 바뀌어 버립니다.
기능처럼 보였지만, 결국은 전체 아이덴티티 모델을 남겼습니다.
모든 직접 만든 인증(auth)은 몇 줄의 코드로 시작됩니다. 문제는 출시 이후에 시작되며, 작은 결정 하나하나가 제품 전체가 기본으로 가정하는 모델로 굳어집니다.
첫날: 40줄짜리 코드
이메일, 비밀번호, 해시 저장, 로그인 시 비교. 깔끔하게 끝.
200일째: 조용한 아이덴티티 모델
누가 유저인지, 어느 조직 소속인지, 어느 세션이 아직 신뢰할 수 있는지, 접근 권한을 어떻게 회수할지.
5년차: 건드릴 수 없는 기반
종이 위에서 로그인 페이지를 바꾸는 일, 실제로는 아이덴티티 기반 전체 재구축이었습니다.
직접 만든 인증, 문제없이 돌아갑니다 — 사업이 움직일 때까지.
몇 년이나 별 탈 없이 로그인을 처리합니다. 하지만 사업 변화 한 번에 “충분히 괜찮다”가 “발목을 잡는” 상황이 벌어집니다. 아래 세 가지는 규모가 커지는 거의 모든 제품에서 나타납니다.
엔터프라이즈 고객이 SSO를 요구하기 시작한다
첫 대형 계약이 성사되면, 고객사는 엔트라나 구글 워크스페이스 SSO를 요구하기 시작합니다. 다음 고객은 또 다른 SAML, OIDC를 요청합니다. 고객마다 아이덴티티 환경은 달라서, 작업 대부분이 재사용되지 않습니다.
- 고객마다 다른 프로토콜, 필드 매핑, 인증서 교체 작업
- SSO는 한 번에 구축 끝이 아니라, 엔터프라이즈마다 재구현
- 결국 처음부터 끝까지 아는 담당자 한 명에게 모든 지식이 집중됨
흩어져있던 아이덴티티, 이제는 통합되어야 한다
조직 혹은 제품마다 분리, M&A로 얻어온 시스템 등. “통합 아이덴티티”가 기능처럼 들리지만, 실제로는 “한 사용자, 한 조직”의 정의 자체를 코드에서 바꿔야 합니다.
- 하나의 이메일로 여러 조직에 속할 수 있을까? 기존 사용자이름은 어떻게 이전?
- M&A로 얻은 9개 제품 = 9개의 인증 스택이 동시에 동작
- 퇴사자를 전부에서 한번에 권한 해제, 그리고 단일화된 감사 로그
AI 에이전트와 CLI가 사용자를 대신해 동작하기 시작한다
이제 단순히 웹 브라우저의 사람이 아니라, 에이전트, MCP 서버, 커맨드라인 도구들이 “누구”의 이름으로 행동합니다. 그런데 기존 인증(auth)은 로그인 페이지만 알 뿐입니다.
- 토큰은 누구에게 발급됐고, 범위(scope) 및 대상(audience)은 무엇인지?
- 특정 툴 혹은 데이터의 일부만 허용, 나중에 언제든 권한 취소
- MCP 및 CLI 접근은 로그인 폼 대신 OAuth 기반
진짜 비용은 개발이 아닙니다. 수년간 떠안게 되는 부담입니다.
처음엔 쉽습니다. 몇 명의 엔지니어가 몇 주 투자해서 빠르게 완성합니다. 이후에는 매년 핵심 제품에 들어갔어야 할 개발 시간이 여기에 쓰이게 됩니다.
비용 구조만 달라졌을 뿐
“인증”이라는 이름의 청구서를 받는 일은 없습니다.
조용히 한두 명에게 의존하게 된다
핵심 컨텍스트는 문서가 아니라 누군가 머릿속에 있습니다.
엔지니어가 머물 곳은 어디인가요?
직접 OAuth 서버를 썼다고 고객이 더 돈을 내지는 않습니다.
직접 만들지 않는다면, 무엇을 써야 할까요?
성숙한 인증 시스템들은 이미 SSO, MFA, 조직, 통 합 로그인, 에이전트 접근 등 대부분 지원합니다. 정말 중요한 건 “언제든 떠날 수 있느냐”입니다. 수천 줄 직접 만든 것에서 벗어나려다가, 남의 폐쇄 시스템에 갇히지 마세요.