적합한 페르소나에 집중하기

2022년 11월 10일

작성자: 짐 베노 - 사용자 경험 담당 이사, Skyhigh Security

보안 회사로서 저희 제품의 사용자는 일반적으로 정보 보안(InfoSec) 조직에서 근무합니다. 하지만 점점 더 많은 사용자들이 보안팀 외부의 사용자, 즉 주로 정보 기술(IT)과 엔지니어링/운영 부서의 사용자를 대상으로 하는 Security Service Edge (SSE) 기능을 찾고 있습니다. 이들은 클라우드에서 애플리케이션을 개발 및 배포하고, 애플리케이션에 대한 액세스를 제어하며, 네트워크의 성능을 보장하는 사람들입니다.

보안 조직 외부의 역할을 대상으로 하는 최소 네 가지 주요 SSE 워크플로 또는 기능이 있습니다:

• 애플리케이션에 대한 액세스 권한 부여 - 기업이 더 많은 인프라를 퍼블릭 클라우드로 이전함에 따라 퍼블릭 클라우드에서 호스팅되는 애플리케이션에 대한 액세스 권한을 제어해야 합니다. 저희 Zero Trust Network Access (ZTNA) 솔루션은 이 기능을 제공합니다. 이러한 액세스 정책을 관리하고 직원의 액세스 요청에 대응하는 것은 보안 운영 센터(SOC)의 업무가 아닙니다. 이는 IT 및 IT 헬프 데스크의 책임입니다.
• 방화벽 정책 관리 - 퍼블릭 클라우드에 이러한 모든 인프라가 있으므로 보안을 위해 기업은 이러한 애플리케이션을 사용할 수 있는 '대상'을 지정하는 것뿐만 아니라 어떤 프로토콜, 포트, 장치, 위치 등을 '어떻게' 사용할 수 있는지에 대한 세부 사항도 지정하여 액세스를 제어해야 합니다.
• 디지털 경험 모니터링 - 사무실이 전 세계에 흩어져 있고 재택 근무를 하는 사람이 많기 때문에 일부 직원이 애플리케이션이나 서비스에 액세스하는 데 문제가 발생하는 것은 불가피한 일입니다. 이러한 문제의 범위와 원인을 파악하는 것은 악몽 같은 일이 될 수 있습니다. IT 헬프데스크에 전화가 걸려오면 보안팀은 전화를 받지 않을 것입니다.
• 잘못된 구성 및 취약점 수정 - IT 및 엔지니어링 팀 내에서는 다양한 팀에서 AWS(Amazon Web Services), GCP(Google Cloud Platform) 또는 Microsoft Azure에서 애플리케이션을 구축하고 있을 수 있습니다. 저희의 임무는 클라우드 인프라를 담당하는 IT 아키텍트, 애플리케이션을 개발하고 구성하는 계정 소유자, 애플리케이션을 배포하는 DevOps/DevSecOps 담당자 등 기업이 이러한 애플리케이션을 안전하게 보호하도록 돕는 것입니다. 취약점이나 잘못된 구성을 발견하면 보안팀은 이를 해결할 수 있는 '성의 열쇠'를 가지고 있지 않기 때문에 변경을 수행할 수 있는 IT 또는 엔지니어링 소유자에게 문제를 전달해야 합니다.

페르소나 만들기

Skyhigh Security 에서는 고객을 이해하고 제품 요구사항과 디자인에 필요한 인사이트를 도출하는 전담 사용자 연구원을 보유하고 있습니다. 새로운 제품 기능을 출시할 때마다 올바른 사용자를 타겟팅하고 그들에 대해 가능한 모든 정보를 파악해야 합니다: 무엇이 그들에게 동기를 부여하는가? 어떤 작업을 수행하는가? 어떤 애플리케이션이나 시스템을 사용하나요? 다른 사용자와는 어떻게 협업하는가? 가장 큰 불만 사항은 무엇인가요?

먼저 제품 관리 및 영업 분야의 내부 팀원들에게 이러한 질문을 던집니다. 그리고 종종 업무 세션을 열고 가상 화이트보드에 집단 지식을 기록합니다. 어떤 직무를 타겟팅할지 파악한 다음에는 고객을 인터뷰하고 그들의 업무 방식을 관찰합니다. 이러한 세션을 몇 차례 진행하면 몇 가지 공통된 주제가 나타나기 시작합니다. 그런 다음 사용 사례와 디자인 작성의 초점이 되는 가상의 캐릭터, 즉 '페르소나'를 만들어 모든 인사이트를 종합합니다.

프레드와 카와카를 소개합니다

최근 저희 연구원들은 디지털 경험 모니터링과 방화벽 정책을 담당하는 두 명의 새로운 페르소나를 조사하고 있습니다: "IT 헬프 데스크에서 근무하는 '프레드'와 네트워크 관리자인 '카와카'입니다. 이 역동적인 듀오로부터 얻은 몇 가지 인사이트를 소개합니다:

• Kawika는 네트워크의 성능을 책임지고 있습니다. 모든 것이 잘 작동하면 삶이 좋습니다. 하지만 문제가 발생하면 모든 것을 내려놓고 바로 실행에 옮겨야 합니다. 이를 방지하기 위해 그는 네트워크의 중요한 애플리케이션을 사전에 모니터링하고 싶어하며, 수많은 문제 티켓이 들어올 때까지 기다릴 수 없습니다.
• SOC와 마찬가지로 IT에는 지원 문제를 처리하는 여러 계층이 있습니다. 직원이 애플리케이션에 액세스하는 데 문제가 발생하면 IT 헬프 데스크에서 처리하는 티켓을 열게 됩니다. 즉, 프레드가 가장 먼저 문제를 조사하게 됩니다. 그는 문제 해결을 안내하는 플레이북을 가지고 있습니다. 네트워크 문제인 것 같으면 네트워크 팀에 에스컬레이션합니다. 이제 카와카의 차례입니다.
• 네트워크 문제를 진단하는 것은 쉽지 않습니다. 네트워크 아키텍처는 복잡합니다. 클라우드 서비스에 액세스할 때 직원의 디바이스에서 발생하는 트래픽은 다양한 네트워크를 통해 이동합니다. 성능에 영향을 줄 수 있는 변수가 많고 시간이 지남에 따라 조건이 변할 수 있습니다. 이러한 문제를 조사하기 위해 Kawika는 필요한 정보를 얻기 위해 많은 도구와 콘솔을 사용해야 합니다.

모호성 피하기

이러한 모든 인사이트는 프레드와 카와카, 그리고 그들의 동료들을 위해 만든 한 페이지짜리 데이터 시트에 요약되어 있습니다. 또한 여러 부서 팀에 페르소나를 소개하는 교육 세션도 개최합니다. 제품 관리자와 엔지니어가 페르소나의 이름을 언급하는 것을 들으면 우리가 할 일을 다했다는 것을 알 수 있습니다!

Figma의 모든 UX 디자인 흐름은 대상 페르소나와 사용 사례를 보여주는 아트보드로 시작됩니다. 이렇게 하면 모든 사람이 같은 페이지에 있고 "관리자" 또는 "보안 아키텍트"와 같은 모호한 참조를 피할 수 있습니다. 디자인을 검토하는 중에 누군가 대상 페르소나에 대해 의문을 제기하면 좋습니다! 저희는 그러한 토론을 환영합니다. 실제로 프레드와 카와카는 바로 그런 토론을 통해 탄생했습니다.

새로운 기능을 설계하고 구축했는데 출시 후에 대상 사용자에 대한 가정이 틀렸다는 사실을 알게 되는 것보다 더 나쁜 일은 없습니다. 이는 워크플로에 중대한 영향을 미칠 수 있으며 전면적인 점검이 필요할 수 있습니다. 사전에 약간의 사용자 조사에 투자하여 가정을 검증하고 목표에 맞는지 확인하는 것이 훨씬 낫습니다.

블로그로 돌아가기