IGA 프로젝트 성공의 시작: 페르소나

IGA 프로젝트가 마땅한 수준보다 더 자주 실패하는 이유

ID 거버넌스 및 관리(IGA)는 실패율이 낮을 것으로 기대할 만큼 오랫동안 자리 잡아 온 분야입니다. 개념은 이미 확립되어 있고, 주요 플랫폼들은 성숙했으며, 이를 구축해 본 경험이 있는 사람도 부족하지 않습니다. 그런데도 프로젝트는 여전히 일정을 초과하거나, 애초의 범위를 벗어나거나, 작동은 하지만 그 조직에는 딱 맞지 않는 솔루션을 내놓곤 합니다.

그 이유들은 대체로 익숙한 몇 가지 주제로 모입니다.

경영진의 동의는 자주 거론되며, 실제로 중요합니다. 고위층의 확고한 지지가 없으면, 예산이 빠듯해지거나 우선순위가 바뀔 때 프로젝트는 축소되기 쉽습니다.

프로그램 목표도 흔한 원인 중 하나입니다. 기술이 현실적으로 제공할 수 있는 것에 비해 목표를 지나치게 야심 차게 설정했거나, 애초부터 측정 가능할 만큼 정밀하지 않았던 경우입니다.

이해관계자에게 무언가를 빨리 보여주기 위해 계획을 소홀히 하면 납기 일정이 밀립니다. 문서화된 요구 사항이 아니라 공급업체의 데모에 이끌려 평가가 진행되면 기술 선택이 잘못됩니다. 기능이 풍부한 플랫폼에 끌렸다가, 정작 필요했던 기능이 가장 많은 커스터마이징을 요구하는 기능이었다는 사실을 나중에야 깨닫기도 쉽습니다. 구현 도중 요구 사항이 바뀌거나, 처음부터 구성 및 통합에 드는 노력을 과소평가하면 비용이 초과됩니다.

이 모든 것은 실제 문제이며, 이미 자세히 다뤄진 내용들입니다. 하지만 다른 여러 원인 뒤에 조용히 숨어 있으면서도 훨씬 덜 주목받는 실패 유형이 하나 있습니다. 바로 프로젝트가 애초에 누구를 위해 만드는 것인지 제대로 정하지 않았다는 점입니다.

어려움을 겪는 대부분의 IGA 프로젝트는 문제의 적어도 일부를, 초기에 세운 사용자·아이덴티티·접근 시나리오 유형에 대한 가정으로 거슬러 올라갈 수 있습니다. 그리고 그 가정은 결국 틀린 것으로 드러납니다.

해결책은 복잡하지 않지만 규율은 필요합니다. 프로젝트를 기술도, 통합도, 워크플로도 아닌, 여러분의 아이덴티티 환경 전체를 완전히 그려내는 작업으로 시작하는 것입니다. 오직 여러분의 거버넌스 프로그램이 다뤄야 할 사람과 아이덴티티만을 말입니다. 나머지 모든 것은 거기서 따라 나옵니다.

이 글의 나머지 부분에서는 이러한 환경을 어떻게 그려낼 수 있는지, 그리고 그렇게 하는 것이 대부분의 조직이 예상하는 것보다 왜 훨씬 더 큰 차이를 만드는지 설명합니다.

그래서, 여러분은 지금 아이덴티티 거버넌스를 검토하고 있습니다

기술 자체가 IGA 프로젝트를 어렵게 만드는 경우는 드뭅니다. 근본 원인은 거의 항상 사람을 이해하는 대신 제품부터 시작한다는 데 있습니다.

IGA 플랫폼 평가를 요청받았든, 이미 프로젝트가 진행 중이라 상황이 복잡해지고 있든, 여러분은 아마 기술이 대개 어려운 부분이 아니라는 사실을 눈치챘을 것입니다.

IGA 플랫폼(누가 무엇에 접근할 수 있는지를 통제하고, 온보딩과 오프보딩을 자동화하며, 누군가가 그 접근 권한을 주기적으로 검토하도록 보장하는 소프트웨어)은 성숙하고, 잘 이해되어 있으며, 폭넓은 기능을 갖추고 있습니다. 대부분의 주요 플랫폼은 핵심 사용 사례를 큰 어려움 없이 처리합니다.

그런데 왜 그렇게 많은 IGA 프로젝트가 예산을 초과하고, 예상보다 오래 걸리거나, 딱 들어맞지 않는 솔루션으로 끝나는 걸까요?

저희 경험상, 그 답은 거의 항상 같은 근본 원인으로 돌아갑니다. 조직이 자신의 사람들을 이해하는 대신 제품부터 선택하면서 시작했다는 것입니다.

단 한 곳의 공급업체라도 평가하기 전에 할 수 있는 가장 가치 있는 일은, 실제로 조직 안에서 누가 일하고 있으며 그들이 아이덴티티와 어떤 관계를 맺고 있는지를 이해하는 것입니다.

'직원이 들어오고, 직원이 나간다'처럼 단순하지 않습니다

겉보기에 IGA는 간단해 보입니다. 누군가 회사에 합류하면 계정을 받습니다. 누군가 떠나면 그 계정은 비활성화됩니다. 그 사이, 누군가가 사람들이 여전히 자신이 가진 것을 필요로 하는지 주기적으로 확인합니다.

대부분의 조직에서 현실은 훨씬 더 복잡합니다. 프로젝트가 진행되면서 흔히 떠오르는 몇 가지 질문을 생각해 보십시오.

계약직 인력과 파견 인력은 어떻게 되는가? 이들이 HR 시스템에 나타나는가? 그렇지 않다면, IGA 플랫폼은 이들의 정보를 어디서 가져오는가?

특정 시스템에 접근이 필요한 제3자 공급업체는 어떤가? 이들은 어떻게 온보딩되며, 누가 그들의 라이프사이클을 관리하는가?

여러 법인이나 지역에 걸쳐 근무하며, 각 법인에서 서로 다른 역할을 맡을 수 있는 직원이 있는가?

인간 사용자와 함께 거버넌스가 필요한 서비스 계정, 공유 계정, 또는 머신 아이덴티티가 존재하는가?

더 엄격한 통제나 다른 승인 절차가 필요할 수 있는, 임원·재무팀·IT 관리자 같은 민감한 역할의 사용자는 어떤가?

여러분의 페르소나 중 규제 기관이나 감사인이 구체적으로 물을 만한 접근 권한을 가진 것이 있으며, 그것이 해당 권한을 검토하거나 문서화하는 방식을 바꾸는가?

권한은 영구히 유지되어야 하는가, 아니면 일부 권한, 특히 민감한 권한은 제한된 기간만 유지되어야 하는가?

이 중 어느 것도 예외적인 경우가 아닙니다. 수백 명이 넘는 조직이라면 이는 표준입니다. 그리고 여러분이 선택한 IGA 플랫폼이 이런 질문들을 기준으로 평가되지 않았다면, 대개 방향을 바꾸는 데 큰 비용이 드는 구현 단계에서, 어려운 방식으로 그 사실을 알게 될 것입니다.

페르소나의 등장

아이덴티티 거버넌스 관점에서 페르소나란, 아이덴티티 라이프사이클이나 접근 요구 사항, 데이터 소스가 다른 유형과 의미 있게 다른, 뚜렷이 구분되는 사용자 유형을 말합니다. 즉 개별 사람이 아니라 사람의 유형입니다.

소프트웨어 엔지니어링에서 처음 빌려온, 수십 년간 구조화된 시스템 분석의 일부였던 기법이 있으며, 이 문제를 해결하는 데 완벽하게 들어맞습니다. 사용자 페르소나, 액터, 아이덴티티 아키타입 등 여러 이름으로 불리지만, 그 아이디어는 단순합니다.

시스템이 무엇을 해야 하는지 정의하기 전에, 먼저 그 시스템이 서비스해야 할 모든 종류의 사람(그리고 사람이 아닌 대상)의 유형을 정의하는 것입니다.

저희 경험상, 중견 규모의 조직은 일반적으로 30개에서 50개의 서로 다른 아이덴티티 페르소나를 식별합니다. 의료, 교육, 소매업 조직의 경우, 이 숫자는 쉽게 두 배로 늘어날 수 있습니다.

이를 생생하게 보여줄 몇 가지 예시입니다.

HR 시스템을 통해 합류하는 정규직 직원으로, 표준 온보딩 여정과 직속 관리자 승인, 그리고 정의된 기본 권한(birthright access) 세트를 갖춘 경우.

에이전시를 통해 소싱된 계약직 인력으로, 그 기록이 HR이 아닌 스프레드시트나 공급업체 포털에 존재하며, 동시에 여러 고객사에서 일할 수도 있는 경우.

기간제 근무 계약을 맺은 학생 또는 인턴으로, 근무 종료 시점에 접근 권한이 깔끔하게 만료되어야 하는 경우.

상시 권한이 아니라 강화된 감시, 직무 분리 통제, 그리고 잠재적으로 적시(just-in-time) 접근이 필요한 관리 계정을 보유한 특권 IT 사용자.

애플리케이션 서비스 계정이나 API 통합처럼, 권한을 갖고 거버넌스가 필요하며 셀프서비스 접근 요청 양식을 절대 작성하지 않을 비인간 아이덴티티.

이러한 각 페르소나는 여러분의 IGA 플랫폼과 서로 다르게 상호작용합니다. 일부는 소스 시스템에서 자동으로 온보딩됩니다. 다른 일부는 수작업 프로세스나 대체 데이터 소스가 필요합니다. 일부는 전문화된 승인 체인이 필요하고, 다른 일부는 일정에 따라 접근 권한이 만료되어야 합니다.

플랫폼 선택에 왜 중요한가

페르소나 목록을 갖추고 나면, 요구 사항은 거의 저절로 작성됩니다.

"이 플랫폼이 입사/이동/퇴사(joiner/mover/leaver)를 지원하나요?" (모두 "예"라고 답합니다)라고 묻는 대신, 훨씬 더 구체적인 질문을 하기 시작합니다.

HRIS, 스프레드시트, LDAP, SCIM 엔드포인트 등 여러 소스에서 아이덴티티 데이터를 수집해 단일 아이덴티티 레코드로 조정할 수 있는가?

별도의 온보딩 워크플로를 통해, HR 기록이 전혀 없는 아이덴티티를 처리할 수 있는가?

서로 다른 사용자 유형에 서로 다른 거버넌스 정책을 적용할 수 있어, 계약직은 90일 접근 검토 주기를, 특권 사용자는 매월 검토 주기를 갖도록 할 수 있는가?

누군가 역할을 변경할 때, 사람의 개입 없이, 고아 권한(orphaned entitlement)을 만들지 않고, 차이를 계산해 올바른 권한을 프로비저닝하거나 회수할 수 있는가?

각 개별 권한이 부여될 당시에는 무해해 보였더라도, 그 조합이 위험을 나타내게 되었을 때 이를 표시할 수 있는가? 각 페르소나의 접근이 누구에 의해 왜 승인되었는지를, 그 페르소나가 지닌 위험에 맞는 검토 주기로 감사인에게 보여줄 수 있는가?

잘 설계된 IGA 플랫폼이라면 위의 모든 것을 처리할 수 있어야 합니다. 페르소나 작업은 이러한 기능 중 어떤 것이 여러분의 조직에 진정으로 중요한지, 그리고 어떤 것이 있으면 좋은 정도인지를 알려줍니다.

또한 공급업체를 평가할 때 무엇을 시연해 달라고 요청해야 할지도 알려줍니다. 일반적인 제품 시연을 지켜보는 대신, 공급업체에 페르소나 세트를 건네고 자사 플랫폼이 각각을 구체적으로 어떻게 처리하는지 보여 달라고 요청할 수 있습니다.

페르소나 작업은 공급업체 평가를 기능 비교에서 진정한 역량 테스트로 바꿔 놓습니다. 일반적인 역량이 아니라 구체적인 시나리오를 요청받았을 때는 격차를 숨기기가 훨씬 더 어렵습니다.

실제로 좋은 사례는 어떤 모습인가

잘 구성된 IGA 배포를 보면, 페르소나 사고방식이 아키텍처에 그대로 드러납니다. 서로 다른 아이덴티티 유형이 서로 다른 온보딩 경로를 따라 흐릅니다. 접근은 수동으로 관리되는 목록이 아니라 역할과 맥락에 따라 부여됩니다. 누군가의 상황이 바뀌면(승진, 전배, 계약 연장), 플랫폼은 자동으로 대응합니다.

접근 검토는 지능적으로 범위가 정해집니다. 적합한 사람이 위험 수준에 맞는 주기로 적합한 권한을 검토합니다. 검토자가 있어서는 안 될 무언가를 발견하면, 제거는 자동으로 이루어지며 감사 가능합니다. 접근이 긴급하게 필요할 때는, 명확한 흔적을 남기는 요청-승인 워크플로가 존재합니다.

민감한 접근 조합(예: 구매 주문을 발행하는 동시에 승인도 할 수 있는 능력)은 감사 중에 발견되는 것이 아니라 사전에 능동적으로 식별됩니다. 예외는 조용히 쌓이는 대신 관리 감독 하에 처리됩니다.

이 중 어느 것도 특별히 이국적인 플랫폼을 요구하지 않습니다. 요구되는 것은, 누군가가 프로젝트 초기에 시간을 들여 조직이 실제로 어떤 유형의 사람과 아이덴티티를 갖고 있는지 이해하고, 그것을 중심으로 솔루션을 설계했다는 것뿐입니다.

그 성과는 접근이 비즈니스와 맞닿는 모든 곳에서 나타납니다. 권한은 수작업 개입이 필요 없기에 더 빠르게 움직이고, 정적 목록이 아니라 맥락에 연결되어 있기에 더 정확하며, 증거가 사후에 재구성되는 것이 아니라 작업이 진행되는 동안 포착되기 때문에 컴플라이언스는 더 이상 허둥지둥하는 일이 아니게 됩니다.

실용적인 이점

IGA 프로젝트의 성공 가능성을 높이는 것 외에도, 페르소나 작업에는 몇 가지 유용한 부수 효과가 있습니다.

다른 프로젝트에도 도움이 됩니다. 아이덴티티는 조직 내 거의 모든 것과 맞닿아 있습니다. 여러분의 페르소나 목록은 특권 계정 관리(PAM) 솔루션, 엔드포인트 관리 도구, 또는 사용자가 누구이며 무엇을 하는지 알아야 하는 그 밖의 무엇을 평가할 때도 똑같이 유용할 것입니다.

이해관계자와의 대화가 더 쉬워집니다. 추상적인 기술 요구 사항을 설명하는 대신 "계약직 페르소나"나 "특권 관리자 페르소나"를 언급할 수 있게 되면, 대화는 더 구체적으로 변합니다. 비즈니스 이해관계자는 권한 스키마는 늘 이해하지 못해도, 페르소나는 이해합니다.

프로젝트 거버넌스를 위한 자연스러운 입력물이 됩니다. 프로젝트 책임을 관리하는 데 RACI(Responsible, Accountable, Consulted, Informed) 매트릭스를 사용한다면, 여러분의 페르소나 목록이 그 원재료를 제공합니다. 각 페르소나 뒤에는 비즈니스 오너, 기술 관리자, 그리고 자문·통보·직접 관여가 필요한 일련의 이해관계자가 존재합니다.

Netwrix Identity Manager 같은 플랫폼이 들어맞는 지점

이 모든 것이 플랫폼 선택을 미룰 이유는 아닙니다. 오히려 여러분의 페르소나 목록이 작동하는 방식에 맞서지 않고 그에 맞게 작동하도록 설계된 플랫폼을 선택할 이유입니다.

Netwrix Identity Manager는 내부, 외부, 게스트, 기술, IoT, AI 에이전트 아이덴티티를 동일한 모델 아래에서 거버넌스합니다. 그래서 스프레드시트에서 소싱된 계약직 인력, HR의 누구도 들어본 적 없는 서비스 계정, 스스로 접근을 프로비저닝하는 AI 에이전트, 그리고 HR 피드를 통해 들어오는 정규직 직원 모두가 네 가지 서로 다른 임시방편 대신 동일한 라이프사이클 규율을 적용받습니다. 제3자 아이덴티티와 비인간 아이덴티티는 자체 라이프사이클 경로를 가지며, 여기에는 계약이나 근무가 끝난 뒤에도 남아 있는 대신 일정에 따라 만료되는 기한부 접근도 포함됩니다. 새 시스템의 온보딩 역시 맞춤형 통합 프로젝트를 요구하지 않습니다. 표준 커넥터가 AD, LDAP, SQL, CSV, SCIM을 기본으로 지원하며, 환경에 더 특화된 요구 사항을 위한 고급 커넥터와 범용 API도 제공됩니다.

역할 관리도 같은 방식으로 작동합니다. 모두에게 적용되는 하나의 정책이 아니라 페르소나별로 역할 및 정책 모델을 정의하며, 역할 마이닝(role mining)은 머신러닝을 사용해 실제 접근 패턴을 분석하고, 역할 구조를 발견하며, 사용 방식이 변화함에 따라 모델을 최신 상태로 유지합니다. 따라서 모델이 구축된 날의 조직도만을 반영하는 데 그치지 않습니다.

리스크 측면도 같은 현실에 맞게 구축되어 있습니다. 정책 엔진이 직무 분리 충돌을 탐지하고 예방하며, 지속적인 모니터링이 고아 계정과 이상치를 감사에서 드러나기 전에, 사후가 아니라 사전에 표시합니다.

이 중 어느 것도 페르소나 작업을 대체하지 않습니다. 오히려 설계에서 구현으로의 빠른 전환을 가능하게 만드는 것이 바로 이것입니다. 각 아이덴티티는 하나의 통로로 강제로 밀어넣어져 맞추기 위한 예외로 땜질되는 대신, 자신만의 조건에 따라 정의되고 거버넌스됩니다. 그 결과는 더 낮은 리스크, 더 빠른 구현, 더 낮은 비용입니다.

요약

아이덴티티 거버넌스 플랫폼은 성숙하고 역량을 갖추고 있습니다. 프로젝트를 어렵게 만드는 것은 대개 기술이 아닙니다. 프로젝트를 어렵게 만드는 것은 제품에서 시작해 나중에 조직의 현실을 그 안에 억지로 맞추려는 시도입니다.

그 대안(먼저 아이덴티티 페르소나를 식별하고, 이를 사용해 요구 사항을 정의한 다음, 그 요구 사항에 비추어 플랫폼을 평가하는 것)은 설명을 듣고 나면 당연하게 들립니다. 하지만 실제로는 놀라울 만큼 드물게 이루어지며, 그것이 메우는 공백은 상당합니다.

이는 전문적인 도구나 깊은 기술 지식을 요구하지 않습니다. 시간과 좋은 질문, 그리고 프로세스 초기 단계부터 비즈니스 전반의 적합한 사람들을 참여시키려는 의지를 요구합니다.

페르소나를 제대로 정하면, 프로젝트의 나머지 부분은 훨씬 더 수월해집니다. 페르소나를 잘못 정하거나 아예 건너뛰면, 구매 당시에는 완전히 이해하지 못했던 문제에 맞춰 솔루션을 사후에 개조해야 하는 상황에 놓일 수도 있습니다.

아이덴티티 프로그램에 문제를 겪고 계신가요? 저희는 여러분이 페르소나를 이해하고, Netwrix Identity Manager가 어떻게 프로젝트를 성공으로 이끌 수 있는지 파악하도록 도와드릴 수 있습니다. 데모를 요청하세요.