기업용 SSO를 한 달 써봤더니 로그인보다 먼저 보인 것

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

입사자는 늘었는데 사용하는 업무 서비스의 계정은 더 빠르게 늘어납니다. 메일, 메신저, 전자결재, 협업 도구, 고객관리 시스템마다 아이디와 비밀번호가 다르면 직원은 로그인에 시간을 쓰고, IT 담당자는 비밀번호 초기화 요청을 처리하느라 정작 중요한 업무를 미루게 됩니다.

저도 처음에는 기업용 SSO를 ‘한 번 로그인하면 여러 서비스에 들어가는 편의 기능’ 정도로 생각했습니다. 하지만 한 달 동안 실제 업무 흐름에 적용해보니 핵심은 로그인 횟수를 줄이는 데 있지 않았습니다. 누가 어떤 서비스에 접근할 수 있는지 한곳에서 관리하는 구조가 만들어진다는 점이 더 큰 변화였습니다.

SSO를 연결하기 전에 알아둔 가장 기초적인 구조

한 번의 인증으로 여러 업무 서비스에 들어가는 원리

SSO는 Single Sign-On의 약자로, 한 번의 인증을 통해 여러 시스템을 이용하게 해주는 기술입니다. 사용자가 각각의 SaaS에 비밀번호를 직접 입력하는 대신, 회사가 지정한 인증 시스템이 사용자의 신원을 확인하고 각 서비스에 인증 결과를 전달합니다. IT의 넓은 개념이 낯설다면 지식백과의 IT 용어 설명을 함께 읽어두면 정보 처리와 업무 시스템의 관계를 이해하는 데 도움이 됩니다.

예를 들어 직원이 회사 포털에서 로그인한 뒤 메일과 협업 도구를 차례로 열었다고 가정해보겠습니다. 각 서비스가 회사의 인증 시스템을 신뢰하도록 연결되어 있다면 다시 비밀번호를 요구하지 않습니다. 직원의 비밀번호가 여러 서비스로 전달되는 것이 아니라, 인증 시스템이 발급한 제한적인 확인 정보가 오간다는 점이 중요합니다.

초보자가 자주 혼동하는 부분은 SSO와 비밀번호 관리 솔루션의 차이입니다. 비밀번호 관리 도구는 여러 비밀번호를 안전하게 저장하고 입력을 돕지만, SSO는 회사의 중앙 인증을 외부 또는 내부 서비스와 연결합니다. 두 기술은 경쟁 관계가 아니며, SSO를 지원하지 않는 오래된 시스템에는 비밀번호 관리 도구를 함께 사용하는 방식이 현실적입니다.

• 사용자: 회사 계정으로 인증하고 허용된 업무 서비스에 접근합니다.
• 인증 제공자: 계정 상태, 비밀번호, 다중 인증 결과를 확인합니다.
• 서비스 제공자: 전달받은 인증 결과를 검증한 뒤 사용자를 로그인시킵니다.
• 관리자: 직원과 조직, 앱, 접근 정책을 연결하고 기록을 확인합니다.

입문자 팁: “비밀번호를 없애는 기술”로 이해하기보다 “로그인 판단을 회사가 관리하는 한곳으로 모으는 기술”로 이해하면 제품 설명서를 훨씬 쉽게 읽을 수 있습니다.

SAML과 OIDC는 이름보다 사용 환경부터 보면 쉽습니다

SSO 제품을 알아보면 SAML, OAuth, OIDC 같은 약어가 한꺼번에 등장합니다. 처음부터 규격 문서를 외울 필요는 없습니다. 기업용 웹 서비스에서 오랫동안 널리 사용된 SAML은 인증 정보를 XML 기반으로 전달하며, OIDC는 OAuth 2.0 위에서 사용자 인증 정보를 다루는 비교적 현대적인 방식이라고 이해하면 출발하기에 충분합니다.

실무에서는 내가 원하는 서비스가 어떤 연결 방식을 지원하는지가 먼저입니다. 관리 콘솔에 ‘SAML SSO 설정’만 있다면 SAML로 연결하고, 새로 개발하는 웹이나 모바일 서비스가 OIDC를 지원한다면 OIDC를 검토할 수 있습니다. OAuth는 본래 다른 애플리케이션이 특정 자원에 접근하도록 권한을 위임하는 데 초점이 있으므로, OAuth 표시만 보고 곧바로 SSO가 된다고 판단해서는 안 됩니다.

원격근무와 비대면 협업이 확산된 배경은 포스트 코로나 관련 설명에서도 확인할 수 있습니다. 업무 장소와 단말이 다양해진 환경에서는 사무실 네트워크 안에 있다는 이유만으로 사용자를 신뢰하기 어렵습니다. 그래서 SSO는 단순한 편의 기능을 넘어 다중 인증, 접속 조건, 퇴사자 차단을 이어주는 출발점이 됩니다.

작은 팀에 한 달 적용하며 체감한 변화와 시행착오

로그인보다 입사와 퇴사 절차가 먼저 달라졌습니다

처음 일주일은 전 직원에게 적용하지 않고 IT 담당자와 협업 도구를 자주 쓰는 소수 인원만 대상으로 시험했습니다. 대상 앱도 메일, 메신저, 문서 협업 서비스처럼 업무 영향은 크지만 복구 절차가 비교적 명확한 세 가지로 제한했습니다. 연결 자체보다 사용자 이름 형식을 맞추고 기존 계정과 회사 계정을 정확히 연결하는 일이 더 오래 걸렸습니다.

두 번째 주부터는 신규 입사자의 흐름이 눈에 띄게 단순해졌습니다. 예전에는 담당자가 서비스마다 초대 메일을 보내고 임시 비밀번호를 안내해야 했지만, 중앙 계정을 만들고 적절한 그룹에 넣는 것으로 여러 앱의 접근 권한을 준비할 수 있었습니다. 자동 계정 생성 기능인 프로비저닝까지 지원되는 서비스에서는 이름과 부서 같은 정보도 일정한 형식으로 전달할 수 있었습니다.

더 크게 체감한 부분은 퇴사 처리였습니다. SaaS별 계정을 사람이 하나씩 찾아 차단하면 누락 가능성이 있지만, 중앙 계정을 먼저 비활성화하면 SSO로 연결된 서비스의 신규 로그인을 빠르게 막을 수 있습니다. 다만 이미 발급된 세션이나 API 키가 즉시 사라지는지는 제품마다 다르므로, SSO 차단만으로 퇴사 절차가 끝난다고 생각하면 위험합니다.

1. 인사 담당자가 입사·이동·퇴사 정보를 확정합니다.
2. IT 담당자가 중앙 디렉터리에서 사용자와 부서 그룹을 반영합니다.
3. 그룹 규칙에 따라 필요한 서비스 접근 권한을 부여하거나 회수합니다.
4. 퇴사 시 중앙 계정 차단과 함께 기존 세션, 개인 토큰, 공유 문서를 확인합니다.
5. 처리 결과와 예외 항목을 티켓이나 승인 기록으로 남깁니다.

직원에게도 변화가 있었습니다. 비밀번호를 잊었다는 문의는 줄었지만, 초반에는 ‘로그인 버튼이 두 개인데 무엇을 눌러야 하나요?’라는 질문이 늘었습니다. 서비스 자체 로그인과 회사 SSO 로그인이 함께 표시되기 때문입니다. 화면 캡처가 포함된 한 페이지짜리 안내서와 “회사 이메일 입력 후 조직 로그인 선택”이라는 문구를 배포하자 문의가 빠르게 감소했습니다.

비용표보다 먼저 확인해야 했던 운영 조건

기업용 SSO의 가격은 사용자 수, 월간 또는 연간 계약, 지원 앱 수, 다중 인증, 자동 프로비저닝, 로그 보관 기간에 따라 크게 달라집니다. 어떤 SaaS는 기본 요금제에서도 SSO를 지원하지만, 일부 서비스는 상위 기업용 요금제로 올려야 SAML 연결을 제공합니다. 따라서 SSO 솔루션의 구독료만 계산하면 실제 예산과 차이가 생길 수 있습니다.

초기 검토에서는 ‘직원 수 × SSO 계정 단가’만 보지 말고 연결 대상 SaaS의 요금제 상승분과 구축 시간을 함께 계산해야 합니다. 내부 담당자가 설정에 쓰는 시간, 사용자 교육, 비상 계정 관리, 인증서 갱신도 비용입니다. 반대로 비밀번호 초기화 문의 감소, 입퇴사 권한 처리 시간 단축, 휴면 계정 정리 같은 절감 효과도 기록해야 투자 판단이 공정해집니다.

실제로 한 번은 이름이 같은 테스트 계정과 실사용 계정을 잘못 연결해 권한이 예상과 다르게 부여될 뻔했습니다. 표시 이름만 보지 않고 변경되지 않는 고유 식별자와 회사 이메일을 기준으로 매칭해야 한다는 교훈을 얻었습니다. 또한 관리자 계정까지 일반 사용자와 똑같은 정책으로 한꺼번에 전환하면 장애 때 설정 화면에도 들어가지 못할 수 있어 비상용 관리자 계정을 별도로 마련했습니다.

• SSO를 지원하는 앱과 지원하지 않는 앱을 먼저 구분합니다.
• 서비스별 사용자 이메일과 중앙 계정 형식이 일치하는지 확인합니다.
• 관리자용 비상 계정에는 강한 비밀번호와 별도 다중 인증을 적용합니다.
• 테스트 그룹에서 로그인, 로그아웃, 계정 차단, 복구 절차를 반복합니다.
• 인증서 만료일과 담당자 변경 시 인수인계 항목을 운영 문서에 기록합니다.

운영 조언: 연결 성공 화면만 확인하지 말고 잘못된 비밀번호, 퇴사 처리, 인증 시스템 장애처럼 실패하는 상황을 시험해야 실제 도입 준비가 끝납니다.

두 번째 달의 운영 품질을 가르는 질문과 변화 변수

도입 전후에 가장 많이 나온 초보자 FAQ

Q. SSO를 쓰면 비밀번호가 완전히 없어지나요?
아닙니다. 사용자는 중앙 인증 시스템에 로그인하기 위한 비밀번호나 패스키, 생체 인증 수단을 여전히 사용할 수 있습니다. 달라지는 점은 여러 서비스가 각각 별도의 비밀번호를 요구하는 대신 중앙 인증 결과를 신뢰한다는 것입니다. 비밀번호 없는 인증을 원한다면 SSO와 별도로 패스키 또는 인증 장치 지원 여부를 확인해야 합니다.

Q. 다중 인증만 적용하면 SSO는 필요하지 않나요?
두 기능의 역할이 다릅니다. 다중 인증은 비밀번호 외에 추가 수단으로 본인을 확인하고, SSO는 인증 결과와 접근 정책을 여러 서비스에 연결합니다. 중앙 SSO 로그인에 다중 인증을 적용하면 사용자는 반복 인증 부담을 줄이고 회사는 중요한 접속 지점의 보안을 강화할 수 있습니다.

Q. 작은 회사도 도입할 가치가 있나요?
직원 수만으로 결정하기는 어렵습니다. 다섯 명이 열다섯 개의 SaaS를 쓰는 팀은 오십 명이 몇 개의 내부 시스템만 쓰는 조직보다 계정 관리가 복잡할 수 있습니다. 퇴사자 계정 누락, 반복되는 비밀번호 초기화, 서비스별 권한 현황 파악이 이미 문제라면 작은 조직에서도 검토할 이유가 충분합니다.

• Q. 인증 서버가 멈추면 모든 서비스가 막히나요? 기존 세션이 유지되는 시간과 서비스별 비상 로그인 정책에 따라 다릅니다. 장애 공지 경로와 비상 계정을 미리 준비해야 합니다.
• Q. 개인 휴대전화에서도 사용할 수 있나요? 가능하지만 단말 상태, 지역, 네트워크, 다중 인증 조건을 어떻게 적용할지 회사 정책이 필요합니다.
• Q. SSO만 연결하면 권한도 자동으로 정리되나요? 로그인 인증과 앱 내부 권한은 별개일 수 있습니다. 자동 프로비저닝과 역할 매핑 지원 여부를 확인해야 합니다.
• Q. 모든 앱을 한 번에 전환해야 하나요? 아닙니다. 사용 빈도가 높고 복구가 쉬운 앱부터 단계적으로 전환하는 편이 안전합니다.

업무에서 말하는 IT는 하드웨어 한 종류가 아니라 정보의 수집, 처리, 전달을 아우르는 넓은 영역입니다. 다른 관점의 정의가 필요하다면 IT 개념을 설명한 지식백과 자료도 참고할 수 있습니다. SSO 역시 로그인 화면 하나의 문제가 아니라 인사 정보, 업무 데이터, 접근 권한과 감사 기록이 연결되는 IT 서비스로 봐야 합니다.

정책과 제품 기능은 고정값이 아니라 계속 움직입니다

한 달이 지나자 처음 만든 접근 정책에도 손볼 부분이 보였습니다. 모든 직원에게 매번 다중 인증을 요구했더니 반복 업무의 불편이 커졌고, 반대로 접속 조건을 너무 느슨하게 두면 분실 단말이나 낯선 지역에서의 로그인 위험을 놓칠 수 있었습니다. 그래서 일반 업무는 신뢰된 단말과 정상적인 접속 상황을 고려하고, 관리자 화면이나 민감한 데이터에는 더 강한 인증을 요구하는 식으로 정책을 나눴습니다.

다음 단계에서는 로그인 성공률만 볼 것이 아니라 실패 원인, 비활성 계정, 관리자 권한 보유자, 장기간 사용하지 않은 앱도 함께 살펴야 합니다. 실패 로그가 많다고 무조건 공격은 아니며, 잘못 저장된 브라우저 정보나 사용자 안내 부족이 원인일 수도 있습니다. 반대로 로그인 횟수가 적다는 이유만으로 안전하다고 판단해서도 안 됩니다.

1. 첫째 주: 로그인 실패율과 사용자 문의 유형을 기록합니다.
2. 둘째 주: 부서 이동자와 휴직자의 권한이 올바른지 표본 점검합니다.
3. 셋째 주: 관리자 계정, 비상 계정, 외부 협력자 계정을 따로 검토합니다.
4. 넷째 주: 인증 장애 상황을 가정해 연락망과 복구 절차를 시험합니다.
5. 분기 단위: 사용하지 않는 앱 연결과 과도한 그룹 권한을 정리합니다.

제품 선택 시에는 현재 기능뿐 아니라 업데이트 공지 방식과 지원 체계도 살펴볼 필요가 있습니다. 브라우저 정책, 모바일 운영체제, 패스키 지원, SaaS의 SSO 제공 요금제는 시간이 지나며 달라질 수 있습니다. 처음 작성한 설정 문서를 영구적인 답으로 두지 말고 제품 업데이트가 있을 때 담당자, 인증 방식, 복구 절차, 비용 조건을 다시 확인하는 일정까지 운영 계획에 넣어야 합니다.

특히 인증서 유효기간과 오래된 프로토콜 지원 정책은 어느 날 갑자기 업무를 멈추게 할 수 있는 변수입니다. 월별 점검에는 인증서 만료 알림을 넣고, 분기별 점검에는 연결 앱의 공식 문서 변경 여부를 포함해두는 편이 좋습니다. 오늘 정상적으로 작동한 기업용 SSO도 조직 구조와 서비스 요금제, 보안 기능이 바뀌면 최적 설정이 달라질 수 있으므로, 다음 달에는 지난달의 성공 여부보다 달라진 조건부터 확인해야 합니다.