페르소나
IT 위키
더 많은 작업
페르소나(Persona)는 실제 사용자 조사 결과를 바탕으로, 시스템의 대표적인 사용자 유형을 이름·배경·목표·행동 특성을 가진 가상의 한 인물로 구체화한 사용자 모델이다.
요구사항을 "사용자" 라는 막연한 대상으로 받으면, 개발자와 기획자가 저마다 다른 사용자를 머릿속에 그리고 결국 자기 자신을 기준으로 설계하게 된다. 페르소나는 이 문제를 풀기 위해 앨런 쿠퍼(Alan Cooper)가 1999년 『The Inmates Are Running the Asylum』에서 상호작용 설계 기법으로 제안했다. 사용자 집단을 평균값으로 뭉뚱그리지 않고, 목표와 행동 패턴이 뚜렷한 몇 명의 인물로 그려 이해관계자 모두가 같은 사용자를 보며 의사결정하게 한다.
소프트웨어 공학에서는 요구사항 분석 단계에서 누구를 위한 시스템인가를 분명히 하는 도구로 쓰인다. 유스케이스의 액터나 사용자 스토리의 "~로서(As a ~)" 를 구체적인 사람으로 채워, 요구사항의 우선순위와 범위를 정하는 근거가 된다. 디자인 싱킹의 정의(Define) 단계, UX 설계에서도 핵심 산출물이다.
| 항목 | 내용 | 예 |
|---|---|---|
| 이름·사진 | 기억하기 쉬운 가상 인물 | 김민지, 34세 |
| 인구통계 | 나이, 직업, 거주지, 가족 | 중소기업 회계 담당, 두 아이 엄마 |
| 목표 | 시스템으로 이루려는 것. 페르소나의 중심 | 월말 정산을 야근 없이 끝내고 싶다 |
| 행동 패턴 | 사용 빈도, 사용 환경, 쓰는 기기 | 주로 PC, 이동 중에는 스마트폰으로 승인만 |
| 불편·요구(Pain Point) | 지금 겪는 문제 | 같은 자료를 여러 시스템에 반복 입력 |
| 기술 수준 | IT 활용 능력 | 엑셀은 능숙, 새 프로그램 학습은 부담 |
| 시나리오 | 시스템을 쓰는 하루의 장면 | 출근 후 30분 안에 전날 거래를 확인한다 |
| 인용문 | 태도를 드러내는 한 문장 | "버튼 하나로 끝났으면 좋겠어요" |
- 주 페르소나(Primary): 설계의 1차 대상. 이 사람이 만족하지 않으면 실패다. 보통 하나, 많아도 셋
- 보조 페르소나(Secondary): 주 페르소나의 요구로 대부분 충족되지만 추가 요구가 몇 가지 있는 사용자
- 부정 페르소나(Negative, Anti-persona): 의도적으로 지원하지 않는 사용자. 범위를 좁히고 기능 과잉을 막는다
- 이해관계자 페르소나: 직접 쓰지는 않지만 영향을 받는 사람(관리자, 고객)
- 사용자 조사: 인터뷰, 현장 관찰, 설문, 사용 로그 분석으로 실제 데이터를 모은다
- 행동 변수 식별: 목표, 사용 빈도, 숙련도, 사용 환경처럼 사용자를 가르는 변수를 뽑는다
- 패턴 도출: 조사 대상을 변수 축에 놓고 비슷한 사람끼리 묶어(군집) 유형을 찾는다
- 페르소나 정의: 유형마다 목표·행동·불편을 담은 인물을 쓰고, 주·보조·부정 페르소나로 우선순위를 정한다
- 시나리오 작성: 페르소나가 시스템을 쓰는 상황을 이야기로 쓰고, 여기서 기능·비기능 요구사항을 뽑는다
- 검증·갱신: 실제 사용자와 비교해 검증하고, 사용자층이 바뀌면 고친다
- 요구사항 도출: 페르소나의 목표와 불편에서 기능 요구사항을, 사용 환경과 기술 수준에서 사용성·성능 같은 비기능 요구사항을 뽑는다
- 우선순위 결정: "주 페르소나에게 필요한가" 로 기능을 거른다
- 의사소통: 개발자·기획자·고객이 "민지 씨라면 이 화면을 이해할까" 처럼 같은 기준으로 토론한다
- 범위 관리: 부정 페르소나로 하지 않을 일을 명시해 요구사항이 부풀지 않게 한다
- 검증: 사용성 평가에서 페르소나에 맞는 참가자를 뽑고, 시나리오를 과업으로 쓴다
- 장점
- 사용자 중심 사고를 팀 전체에 공유한다
- 개발자가 자기 자신을 사용자로 착각하는 자기 참조 설계를 막는다
- 요구사항 우선순위의 근거가 명확해진다
- 단점·주의
- 조사 없이 상상으로 만들면 고정관념을 강화하는 허구가 된다
- 페르소나가 너무 많으면 초점이 흐려진다
- 사용자층이 바뀌어도 갱신하지 않으면 잘못된 기준이 된다