ssot 뜻을 검색하는 사람 상당수는 사실 sso라는 말과 함께 헷갈려서 들어온다. ssot는 단일 진실 공급원이라는 뜻으로, 여러 시스템에 흩어진 데이터 중 어느 것을 기준으로 삼을지 정해 두는 원칙을 말한다. 반면 sso는 여러 서비스를 하나의 계정으로 로그인하게 해 주는 인증 방식을 가리킨다. 두 말은 철자가 비슷해 자주 섞여 쓰이지만 다루는 대상이 전혀 다르므로, 이 글은 두 개념을 각각 정리하고 실제로 어디서 헷갈리는지까지 짚어 본다.
sso 뜻과 로그인 구조
sso는 single sign on의 줄임말로, 하나의 계정 정보로 로그인을 한 번만 하면 그와 연결된 여러 서비스에 다시 로그인하지 않고 들어갈 수 있게 만드는 방식이다. 회사에서 메일, 문서 도구, 사내 시스템을 따로따로 로그인하지 않고 한 번의 인증으로 넘나드는 경우가 대표적이다. 이 구조에서는 인증을 전담하는 서버가 따로 있고, 각 서비스는 그 서버가 내려 준 인증 결과를 확인한 뒤 접근을 허용한다. 즉 비밀번호를 없애는 기술이 아니라, 비밀번호를 확인하는 절차를 한 곳으로 모으는 기술이라고 보는 편이 정확하다.
이런 구조를 쓰는 이유는 단순하다. 서비스마다 따로 계정을 만들고 비밀번호를 기억해야 하면 사용자도 불편하고, 관리하는 쪽도 계정마다 접근 권한을 따로 관리해야 해서 허점이 생기기 쉽다. 인증을 한 곳으로 모아 두면 직원이 조직을 떠났을 때 계정 하나만 정지시켜도 연결된 모든 서비스 접근이 함께 막힌다는 관리상 장점도 있다. 그래서 sso는 개인용 서비스보다는 여러 업무 도구를 함께 쓰는 조직에서 먼저 자리를 잡았다.
ssot 뜻과 데이터 기준
ssot는 조직 안에서 같은 정보를 여러 시스템이 각자 저장하다 보면 값이 서로 어긋나는 문제를 막기 위한 원칙이다. 예를 들어 고객의 연락처가 영업 시스템과 고객지원 시스템에 각각 따로 저장되어 있으면, 한쪽에서만 정보를 고치는 순간 두 시스템의 값이 달라진다. ssot는 이런 정보 중 하나를 원본으로 정하고, 나머지 시스템은 그 원본을 참조하거나 그 원본에서 값을 가져오도록 설계하는 방식을 말한다. 로그인 기술이 아니라 데이터를 관리하는 사고방식에 가깝다.
sso와 ssot가 자주 함께 검색되는 이유는 두 말이 비슷하게 생긴 약자이기 때문이지, 같은 기술을 가리켜서가 아니다. sso는 인증이라는 좁은 영역을 다루고, ssot는 조직의 데이터 전반을 다루는 더 넓은 개념이다. 다만 둘 다 여러 곳에 흩어져 있던 것을 하나의 기준점으로 모은다는 점에서는 방향이 닮아 있어서, 업무 소프트웨어를 설명하는 글에서 나란히 언급되는 경우가 많다.
실제로 자주 헷갈리는 지점
sso를 두고 흔히 하는 오해 하나는 로그인 한 번으로 모든 보안 절차가 끝난다고 생각하는 것이다. 실제로는 인증 서버 자체의 보안이 뚫리면 연결된 모든 서비스가 함께 위험해지므로, 인증 서버를 얼마나 안전하게 관리하느냐가 오히려 더 중요해진다. ssot 쪽에서 흔한 오해는 모든 데이터를 물리적으로 한 시스템에 몰아넣는 것이라고 생각하는 경우다. ssot는 데이터를 한곳에 저장하라는 말이 아니라, 값이 여러 곳에 있더라도 어디가 원본인지를 명확히 정해 두라는 원칙에 가깝다.
검색어 중에는 sso 주가나 sso etf처럼 금융 쪽 표기와 겹치는 경우도 있는데, 이는 같은 세 글자를 다른 분야에서 종목이나 상품을 가리키는 표기로 쓰는 것이고 여기서 설명한 로그인 기술과는 관계가 없다. 이런 시세나 상품 정보는 시점에 따라 계속 바뀌므로, 필요하다면 해당 상품을 다루는 공식 창구에서 최신 내용을 직접 확인하는 것이 맞다. 이 글에서 다루는 sso와 ssot는 어디까지나 업무 소프트웨어에서 쓰이는 인증과 데이터 관리 개념이다.
도입 전에 먼저 확인할 것
조직에 sso를 들이려 한다면 먼저 지금 쓰고 있는 서비스들이 외부 인증을 받아들이는 방식을 지원하는지부터 확인해야 한다. 오래된 사내 시스템 중에는 이런 연동 방식을 지원하지 않는 경우가 있어서, 일부 서비스만 sso로 묶이고 나머지는 예전처럼 따로 로그인해야 하는 상황이 흔히 생긴다. ssot를 도입하려 한다면 기술보다 먼저 어떤 정보를 원본으로 삼을지, 그 정보를 누가 고칠 권한을 갖는지를 조직 안에서 정리하는 절차가 앞서야 한다. 기준을 정하지 않은 채 시스템만 연결하면 오히려 어느 값이 맞는지 더 헷갈리는 결과로 이어질 수 있다.
두 개념을 표로 견주어 보면 다음과 같다.
| 구분 | sso | ssot |
|---|---|---|
| 다루는 대상 | 로그인·인증 | 데이터의 기준점 |
| 목적 | 여러 서비스를 한 번의 로그인으로 이용 | 여러 시스템의 값이 어긋나지 않게 관리 |
| 도입 전 확인할 것 | 연결하려는 서비스의 외부 인증 지원 여부 | 어떤 정보를 원본으로 정할지, 수정 권한은 누구에게 있는지 |
sso 로그인을 도입했는데도 일부 서비스에서 다시 로그인을 요구한다면 그 서비스가 아직 연동되지 않았을 가능성부터 살펴보면 된다. 반대로 ssot를 갖추고 싶은데 어디서부터 시작해야 할지 막막하다면, 기술 도구를 고르기 전에 조직 안에서 어떤 데이터가 자주 어긋나 문제를 일으키는지부터 정리해 보는 편이 순서에 맞다. 결국 두 개념 모두 도구를 들이는 것보다 무엇을 기준으로 삼을지 먼저 정하는 쪽이 앞선다.
이 글에서 다루지 않은 세부 사항, 이를테면 특정 제품이 어떤 방식으로 이 기능을 구현하는지는 도입을 검토하는 서비스의 공식 안내 자료를 통해 확인하는 것이 정확하다. 조직마다 이미 쓰고 있는 시스템 구성이 다르기 때문에, 일반적인 개념을 이해한 다음에는 실제 담당 부서나 도구 제공처와 함께 세부 조건을 맞춰 보는 절차가 필요하다.
· · · · · · · · · ·
스페셜타임스는 AI 기술의 도움을 받아 더 빠르고 다양한 뉴스를 독자에게 전달하기 위해 노력하고 있습니다.