블로그 목록으로
소프트웨어

시스템마다 비밀번호가 다른 회사: 사내 시스템 통합 로그인(SSO) 도입과 SAML·OIDC 연동 가이드

직원 200명이 시스템 10개를 쓰면 관리할 계정은 2,000개가 됩니다. IdP와 SP의 역할, SAML·OIDC 선택 기준, 레거시 연동, SCIM 기반 계정 생명주기 자동화, IdP 장애 대비까지 사내 SSO 도입 방법을 정리합니다.

POLYGLOTSOFT 기술팀2026-10-187분 소요5
SSO통합로그인SAMLOIDC계정관리

계정이 시스템 수만큼 있을 때 생기는 문제

그룹웨어, ERP, MES, 전자결재, 사내 위키, 클라우드 콘솔까지 회사가 쓰는 시스템이 늘어나면 계정도 그만큼 늘어납니다. 직원 200명이 시스템 10개를 쓰는 회사라면 관리해야 할 계정은 2,000개가 됩니다. 시스템마다 비밀번호 규칙과 변경 주기도 다릅니다.

이런 구조에서는 몇 가지 문제가 반복해서 나타납니다.

  • 비밀번호 재사용: 외우기 어려우니 같은 비밀번호를 여러 시스템에 씁니다. 한 곳에서 유출되면 나머지 시스템도 함께 뚫립니다.
  • 초기화 문의: 직원 200명 중 매달 30%가 한 번씩 비밀번호를 잊어버린다고 가정하면 월 60건입니다. 건당 10분이면 IT 담당자가 매달 10시간을 비밀번호 초기화에 씁니다.
  • 퇴사자 계정 잔존: 퇴사 처리를 할 때 시스템 10곳을 하나하나 찾아 계정을 막아야 하므로 한두 곳은 빠지기 쉽습니다. 남은 계정은 외부에서 접근할 수 있는 통로가 됩니다.
  • 계정 관리가 시스템마다 흩어져 있으면 "누가 무엇에 접근할 수 있는가"를 회사가 한눈에 파악할 수 없습니다. 보안 사고는 대개 이 빈틈에서 시작됩니다.

    SSO의 구성 요소 이해하기

    인증 제공자(IdP)와 서비스(SP)의 역할 분리

    통합 로그인(SSO)의 핵심은 로그인을 한 곳에서만 처리하는 것입니다. 사용자를 확인하는 IdP(Identity Provider, 예: Microsoft Entra ID, Okta, Keycloak)와 실제 업무 기능을 제공하는 SP(Service Provider, 각 사내 시스템)의 역할을 나눕니다. SP는 비밀번호를 저장하지 않고, IdP가 서명해서 보낸 "이 사용자는 인증되었다"는 증명만 검증합니다.

    SAML과 OIDC의 차이와 선택 기준

  • SAML 2.0: XML 기반 표준으로 2005년에 제정되었습니다. 그룹웨어, ERP 같은 기업용 패키지 소프트웨어와 기존 웹 시스템에서 폭넓게 지원합니다.
  • OIDC(OpenID Connect): OAuth 2.0 위에 인증 계층을 얹은 JSON/JWT 기반 표준입니다. 모바일 앱, SPA, API 중심 서비스에 잘 맞고 구현이 비교적 가볍습니다.
  • 선택 기준은 단순합니다. 상용 패키지는 해당 제품이 지원하는 방식을 따르고, 새로 개발하는 시스템은 OIDC를 기본으로 하는 것이 일반적입니다. 대부분의 IdP는 두 방식을 모두 지원하므로 회사 안에 함께 운영해도 문제없습니다.

    기존 시스템을 SSO에 붙이는 방법

    시스템 유형별 연동 전략

  • 표준 지원 시스템: SaaS나 최신 패키지는 설정 화면에서 IdP 메타데이터만 등록하면 연동됩니다. 가장 먼저 처리할 대상입니다.
  • 커스텀 개발 시스템: 자체 로그인 모듈을 OIDC 클라이언트 라이브러리로 바꿉니다. 보통 로그인·로그아웃·세션 처리 부분만 고치면 됩니다.
  • 레거시 시스템: 소스 수정이 어렵다면 앞단에 인증 프록시(리버스 프록시)를 두어 프록시가 SSO를 처리하고 사용자 정보를 헤더로 전달하게 합니다. 이때는 프록시를 거치지 않는 직접 접근 경로를 반드시 막아야 합니다.
  • 기존 계정과 통합 계정의 매핑과 이행

    가장 손이 많이 가는 작업은 시스템마다 다른 ID(사번, 이메일, 임의 ID)를 통합 계정 하나로 연결하는 일입니다. 바뀌지 않는 사번이나 IdP의 고유 식별자를 기준 키로 삼고, 매핑 표를 먼저 만들어 중복·고아 계정을 정리합니다. 이행은 시스템별로 일정 기간 기존 로그인과 SSO를 함께 열어 두었다가 단계적으로 기존 로그인을 닫는 방식이 안전합니다.

    계정 생명주기 자동화

    인사 데이터와 연동

    SSO만으로는 절반만 해결됩니다. 입사·부서 이동·퇴사가 인사 시스템에 등록되는 순간 계정에 자동으로 반영되어야 합니다. 퇴사일에 IdP 계정이 비활성화되면 그 계정으로 연결된 모든 시스템의 로그인이 함께 막힙니다. 부서 이동 시에는 이전 부서의 권한을 회수하는 규칙도 함께 넣어야 권한이 누적되지 않습니다.

    SCIM 활용과 한계

    SCIM 2.0(RFC 7643·7644)은 IdP가 각 시스템에 사용자를 생성·수정·삭제하도록 하는 표준 API입니다. 주요 SaaS는 대부분 지원합니다. 다만 사내 개발 시스템과 레거시 시스템은 SCIM을 지원하지 않는 경우가 많고, 시스템 내부의 세부 권한(메뉴·데이터 범위)까지 표준으로 다루기는 어렵습니다. 이런 시스템에는 SCIM 엔드포인트를 직접 개발하거나 배치 동기화를 함께 운영합니다.

    보안 강화와 장애 대비

    다단계 인증 적용 범위와 예외 관리

    SSO를 도입하면 로그인 지점이 하나로 모이므로 그 지점을 다단계 인증(MFA)으로 단단히 지켜야 합니다. 관리자 계정과 외부 접속은 예외 없이 적용하고, 사내망 일반 업무는 위험 기반 정책으로 부담을 조절할 수 있습니다. 공용 단말이나 생산 현장 키오스크처럼 예외가 필요한 곳은 예외 목록과 만료일을 문서로 관리해야 예외가 영구화되지 않습니다.

    IdP 장애에 대비한 비상 접근 설계

    IdP가 멈추면 모든 시스템 로그인이 함께 멈춥니다. 이에 대비해 다음을 미리 설계합니다.

  • 비상 계정(break-glass): SSO를 거치지 않는 최소한의 관리자 계정을 두고, 자격 증명은 봉인 보관하며 사용할 때마다 기록과 알림을 남깁니다.
  • 세션 유지 정책: 이미 로그인한 사용자는 IdP 장애 중에도 일정 시간 작업을 이어갈 수 있도록 세션 만료 시간을 조정합니다.
  • IdP 이중화와 정기적인 장애 전환 훈련을 함께 계획합니다.
  • POLYGLOTSOFT의 SSO 구축 지원

    POLYGLOTSOFT는 사내 시스템 현황 진단부터 시작합니다. 시스템별 인증 방식, SAML·OIDC 지원 여부, 계정 수와 중복 현황을 정리한 뒤 표준 지원 시스템 → 커스텀 시스템 → 레거시 시스템 순서로 단계적 통합 계획을 세웁니다. IdP 구성, 자체 개발 시스템의 OIDC 전환, 레거시용 인증 프록시, 인사 데이터 연동과 SCIM 엔드포인트 개발, 비상 접근 설계까지 한 팀에서 진행합니다. 비밀번호 문의와 퇴사자 계정 관리에 지쳐 있다면 지금 사용 중인 시스템 목록과 함께 문의해 주십시오. 회사 상황에 맞는 통합 로드맵을 제안해 드리겠습니다.

    기술 상담이 필요하신가요?

    스마트공장, AI, 물류자동화 분야의 전문 컨설턴트가 귀사의 요구사항을 분석해 드립니다.

    무료 상담 신청