핵심부터 말하자면: WMS·OMS·TMS에 SSO를 구축하기 전에 프로토콜 문서부터 들이밀지 마라. 오후 시간 하나를 내어 세 열짜리 스프레드시트를 만들어라—사람, 각 시스템에서의 역할, 퇴사 시 누가 계정을 비활성화하는지. 이 시트를 못 채우면 SAML이든 OIDC든 아무 의미가 없다. 똑같은 망함을 세 번 봤다. 붕괴 지점은 항상 같다: ID 공급자는 깔끔하게 붙는데, 비즈니스 쪽 역할 매핑이 엉망이다.
왜 항상 고라이브 전날 밤에 터지는가
2023년 9월. 남부 캘리포니아에 있는 60,000제곱피트 규모의 3PL. 같은 주에 WMS·OMS·TMS를 한꺼번에 오픈한다. 단순하게 하려고 클라이언트는 현장에 세 시스템 공통 공유 아이디와 비밀번호 하나를 줬다. 효율적으로 들리지 않는가?
3일째에 터졌다. OMS에서 주문을 볼 수 있던 고객서비스 담당자가 TMS의 운송사 운임까지 수정할 수 있었던 것이다—'CSR'이라는 역할이 시스템마다 완전히 다른 뜻이었고, 공유 로그인이 세 시스템 중 가장 넓은 권한을 그대로 물려받았기 때문이다. 사장이 물었다. '이게 싱글사인온 아니에요? 왜 더 엉망이 되는 거죠?' 내 대답: '그건 싱글사인온이 아닙니다. 로그인 화면이 달린 단일 장애점이죠.'
구해낸 방법은 추했지만 효과적이었다: 공유 계정 40여 개를 하룻밤에 동결하고, 사람-시스템-역할로 매핑한 120개의 개별 계정을 다시 만들고, 업무를 돌린 뒤, 역할 매트릭스를 맞추고 모든 것을 단일 ID 소스에 연결하는 데 2주를 썼다. 그 프로젝트에서 배운 교훈 하나가 뼈에 새겨졌다. SSO가 답하는 건 '당신은 누구인가'다. 권한이 답하는 건 '무엇을 할 수 있는가'다. 전혀 다른 문제이며, 후자를 전자에 떠넘기면 안 된다.
체크리스트: 제로에서 SSO까지, 단계별로
1단계: 모든 계정을 전수 조사하라. 세 시스템의 전 계정을 스프레드시트에 세 열(사용자명·시스템·현재 역할)로 뽑아라. 세 가지 유형에 플래그를 달아라—퇴사자 좀비 계정(거의 모든 프로젝트에 5–10%가 있다), 공유 '퍼블릭' 로그인(피킹 태블릿에 가장 많다), 권한 과다 '신 계정'. 고라이브 전에 이걸 청소하지 않으면 SSO는 아무것도 바꾸지 못한다.
2단계: 역할 매핑 매트릭스를 만들어라. 행은 비즈니스 역할(피커·CSR·디스패처·창고 슈퍼바이저·재무·IT 관리자), 열은 세 시스템, 각 셀은 그 역할이 그 시스템에서 누를 수 있는 버튼을 정확히 적는다. 주의: TMS의 '디스패처'와 WMS의 '디스패처'는 같은 게 아닐 가능성이 높다. 이름은 같고 권한은 다르다. 비즈니스 오너에게 이 시트에 서명을 받아라. 서명 없으면 고라이브 없다.
3단계: ID 소스를 정하라. 회사에 이미 기업 ID 시스템이 있으면 그걸 ID 공급자로 써라—두 개 만들지 마라. 아무것도 없을 때만 4단계의 프로토콜 결정으로 간다.
4단계: 프로토콜을 골라라. 신규 시스템: OIDC 우선. 레거시: SAML 2.0 지원 여부를 확인하라. 전통적인 WMS 제품 중에는 SAML만 지원하는 게 많다—OIDC를 억지로 밀어넣고 코드를 뜯어고치지 마라. 프로토콜 적응의 토끼굴은 생각보다 깊다.
5단계: 사용자 속성을 매핑하라. ID 공급자가 하류로 무엇을 넘길지 정하라: 사번·이메일·부서·역할. 안정적이고 전역적으로 유일한 식별자를 최소 하나는 넘겨라—이메일이 아니라 사번. 이메일은 바뀐다. 각 필드마다 정통 소스를 지정하라: 부서는 HR, 끝.
6단계: 퇴사 플로우를 연결하라. 계정 비활성화는 HR의 퇴사 처리와 엮어야 하며, 목표는 '마지막 날 비활성화'다. 자동화가 안 되면? IT가 매주 금요일 오후에 퇴사자 명단을 수동으로 대조한다. 이 구멍을 세 번 봤다. 2024년 초, 생활용품 이커머스 창고가 깔끔한 SSO 오픈 6개월 뒤 권한 감사를 하다가, 3개월 전에 그만둔 디스패처가 여전히 TMS에 로그인해 운송사 운임을 조회할 수 있음을 발견했다—HR의 퇴사자 명단이 IT와 한 번도 동기화된 적이 없었기 때문이다.
7단계: 단계적으로 확산하라. IT 직원 5–10명으로 일주일 파일럿, 다음에 창고 하나, 그다음 전체. 파일럿 동안에는 롤백용으로 기존 로그인 경로를 남겨둬라—이 줄은 내 고라이브 전날 체크리스트 맨 위에 영구적으로 있다.
먼저 계산해 봐라: SAML vs OIDC vs 자체 구축
| SAML 2.0 | OIDC | 자체 구축 계정 | |
|---|---|---|---|
| 적합 대상 | 레거시 시스템, 전통적 WMS/ERP | 신규 시스템, 클라우드 네이티브 앱 | 시스템 하나 또는 둘의 소규모 팀 |
| 구현 공수 | 중간 (장황한 XML 설정) | 낮음 (JSON, 성숙한 생태계) | 초기엔 낮고 나중엔 높음 |
| 지속 유지보수 | 낮음 (성숙한 표준) | 낮음 | 높음 (비밀번호 정책, 감사, MFA — 전부 직접) |
| 모바일/태블릿 지원 | 약함 | 강함 | 코드에 따라 다름 |
| 장기 총비용 | 오래됐지만 안정적 | 신규 프로젝트의 기본 선택 | 두 시스템을 넘기면 손해 — 하지 마 |
의사결정 프레임워크는 단순하다: 세 시스템 중 하나라도 SAML만 지원하면 SAML로 올인하라. 다 신규 시스템? OIDC. 앞으로 2년 안에 시스템을 두 개를 넘지 않을 확신이 있을 때만 자체 구축을 고려하라. 자체 계정 시스템의 진짜 비용은 구축비가 아니다—네 번째 시스템을 붙이는 날, 앞의 세 개가 각자 지 맘대로 비밀번호 정책을 만들었다는 걸 알게 되는 날의 비용이다.
고라이브 전날 밤 체크리스트: 모든 실패가 여기 산다
- 테스트 계정을 삭제하라. 거의 모든 프로젝트에서 고라이브 전날 밤에도 살아 있는 test01류 계정이 세 개에서 다섯 개 나온다.
- 관리자 계정은 SSO로 돌리지 마라. ID 공급자가 죽는 날을 대비해 시스템마다 로컬 슈퍼관리자 계정을 최소 하나씩 남겨둬라. 비밀번호는 종이에 적어 금고에 잠가라—원시적이지만, 그게 고라이브를 구한 적이 있다.
- 세 시스템의 세션 타임아웃을 맞춰라. WMS는 8시간, TMS는 30분이면 디스패처가 미쳐버린다. 4–8시간으로 표준화하고, 잠금이 걸리지 않는 성수기 태블릿용은 별도 정책을 둬라.
- 데드존 시나리오를 테스트하라. 창고 와이파이가 끊기면 SSO 리다이렉트 페이지가 태블릿에 안 뜨고, 피커는 랙 앞에서 멍하니 서 있게 된다. 저하 모드 폴백은 실제 현장에서 진짜 테스트를 해야 한다.
- 감사 로그가 조인 가능한지 확인하라. 뭔가 터지면 '어제 오후 2시에 이 사용자가 TMS에서 뭘 바꿨는가'에 답할 수 있어야 하고, 세 시스템의 로그가 모두 같은 사용자 식별자를 가지고 있어야 한다.
마지막으로 역설 하나: SSO가 올라간 뒤 마음이 놓인다는 사람이 많다. 진실은 반대다—SSO는 '열쇠 하나, 문 하나'를 '열쇠 하나, 문 세 개'로 바꾼다. 그러니 열쇠를 잃어버리면 비용이 세 배다. SSO에서 MFA는 선택 사항이 아니라 패키지의 일부다. 마찰이 너무 크다고? 그러면 최소한 관리자와 재무 역할에는 강제하라.
내일 당장 할 수 있는 일: 세 시스템의 계정을 뽑아 1단계의 세 열에 펼쳐놓는 것. 처음 발견하게 될 진실은 보통 이거다—80개라고 생각했던 계정이 사실은 110개다.
Lin Xiao, WMS 구축 컨설턴트 지음
영어판 번역본입니다. 내용이 다를 경우 영어판을 우선합니다.
