순서와 상호작용 바꿔보기, 퍼소나 기법

개념

화면이 가정하는 "정상 순서" 는 없다

화면을 만드는 사람의 머릿속에는 흐름이 하나 있다. 1단계 → 2단계 → 3단계. 코드도 그 흐름을 전제로 쓰인다. 그런데 사용자는 그 흐름을 모른다.

실제로 사용자가 하는 일을 나열해 보면 이렇다.

• 2단계에서 전화를 받고 10분 뒤에 돌아온다
• 브라우저 뒤로가기로 1단계로 가서 값을 바꾸고 다시 온다
• 3단계 주소를 즐겨찾기 해 뒀다가 다음에 거기부터 연다
• 결제가 느려서 새로고침한다
• 친구가 보낸 링크를 눌러 중간 단계로 바로 들어온다

전부 악의가 없고 전부 흔하다. 개발자가 "그렇게 쓰면 안 되는데" 라고 말하는 순간, 그건 결함이다 — 사용자는 설명서를 안 읽는다.

이 레슨은 그 "그렇게 쓰면 안 되는 길" 을 일부러 걷는 방법이다. 세 가지 축이 있다 — 순서·상호작용·사람.

순서를 바꿔본다

사용자는 화면이 의도한 "정상 순서"대로만 움직이지 않는다. 결제 페이지에서 갑자기 뒤로 가서 장바구니 수량을 바꾸고 다시 결제로 돌아오거나, 회원가입 중간에 이메일 인증 없이 다음 단계로 넘어가려 시도하기도 한다. 탐험할 때 의도적으로 다음을 시도한다.

• 단계를 건너뛰기 (2단계를 안 거치고 3단계로 직접 이동 시도)
• 뒤로 갔다가 다시 진행하기
• 같은 단계를 여러 번 반복하기
• 브라우저 뒤로가기 버튼을 앱 내 "뒤로" 버튼 대신 사용하기
• 주소를 복사해 두고 한참 뒤에 다시 열기
• 완료한 뒤 다시 처음부터 같은 흐름을 시작하기

모듈 3(레슨 3)에서 상태 전이를 명세 기반으로 미리 설계했다면, 여기서는 실시간으로 순서를 흐트러뜨리며 그 상태 모델이 실제로 방어되고 있는지 확인한다. 그림에 없는 화살표를 손으로 그어 보는 셈이다.

순서를 흐트러뜨릴 때 무엇을 볼 것인가도 정해 두면 좋다. 세 가지가 전형적인 고장 모양이다.

세 번째가 보안과 직결된다. 단계를 건너뛰어 들어갔는데 화면이 열린다면, 그 검증이 화면에만 있고 서버에는 없다는 뜻이다. 주소를 직접 입력해 보는 것만으로 확인되고, 모듈 50 레슨 2의 인가 우회가 바로 이 이야기다.

되돌아가는 경로를 특히 본다. 앞으로 가는 길은 설계되지만, 되돌아오는 길은 대개 설계되지 않는다. 취소·수정·뒤로가기가 들어간 자리가 거의 항상 약하다.

상호작용을 바꿔본다

한 가지 방식으로만 조작하지 않는다.

• 같은 계정으로 브라우저 탭 두 개를 열어 동시에 조작하기
• 키보드 단축키와 마우스를 함께 쓰기
• 붙여넣기(clipboard)로 예상 밖의 값 넣기
• 자동완성 기능이 채운 값을 그대로 제출하기
• 키보드만으로 끝까지 가 보기 — 탭 키로만 이동하고 마우스를 안 쓴다
• 화면을 확대한 채로 조작하기 — 버튼이 가려지거나 겹치는가

이런 상호작용은 "정상적인 한 가지 방법"만 테스트했을 땐 절대 안 드러나는 결함(예: 두 탭에서 동시에 재고를 줄이는 동시성 결함)을 드러낸다.

두 창 띄우기는 가장 값싸고 가장 자주 통하는 방법이다. 일반 창과 시크릿 창을 나란히 두면 세 가지를 한 번에 할 수 있다.

첫 줄이 특히 중요하다. 두 창에서 같은 것을 열어 두고 한쪽에서 수정한 뒤 다른 쪽에서 저장하면, 뒤에 저장한 쪽이 앞의 변경을 조용히 지워 버리는 경우가 많다. 사용자는 자기 수정이 사라진 것을 한참 뒤에 안다. 혼자 한 창으로 테스트하면 절대 안 나온다.

붙여넣기도 과소평가되는 입력 경로다. 화면의 입력 제한은 대개 타자 기준으로 만들어져서, 붙여넣기로는 글자 수 제한을 넘기거나 줄바꿈·탭 문자가 섞여 들어간다. 다른 문서에서 복사한 값에는 보이지 않는 문자가 따라오는 경우도 흔하다.

퍼소나 기법

퍼소나(Persona) 는 특정 성격·습관을 가진 가상의 사용자가 되어 그 사람처럼 탐험하는 기법이다. 중립적인 "일반 사용자"로 탐험하는 대신, 구체적인 캐릭터를 입으면 완전히 다른 경로로 탐험하게 된다.

퍼소나는 앞선 레슨의 "숨은 변수 찾기"를 사람의 행동 패턴 관점에서 체계적으로 하는 방법이라고도 볼 수 있다.

퍼소나가 왜 효과가 있나

같은 사람이 같은 화면을 봐도, "나" 로 볼 때와 "그 사람" 으로 볼 때 떠오르는 행동이 다르다. 이유는 단순하다 — QA 는 제품을 너무 잘 안다.

• 어느 버튼이 어디 있는지 안다 → 헤매지 않는다
• 어떤 값이 통과하는지 안다 → 틀린 값을 안 넣는다
• 로딩이 몇 초 걸리는지 안다 → 기다린다

세 가지 다 실제 사용자는 안 하는 행동이다. 퍼소나는 그 아는 것을 잠시 끄는 장치다.

그래서 퍼소나를 고를 때 기준은 하나다 — 나와 가장 다른 사람을 고른다. 내가 성격이 느긋하면 급한 사람을, 내가 키보드를 잘 쓰면 터치만 쓰는 사람을 고른다.

퍼소나를 더 만들어 보면

표의 넷 말고도 쓸 만한 것이 많다. 제품마다 위험한 퍼소나가 다르다.

"돈을 아끼려는 사용자" 는 쇼핑·구독 제품에서 특히 생산적이다. 이 사람은 무료 배송 기준 금액을 정확히 맞추려고 장바구니를 넣었다 뺐다 하고, 쿠폰을 조합해 보고, 할인 적용 순서를 바꿔 본다. 경계값을 가장 성실하게 찔러 보는 사용자이고, 그래서 계산 결함을 잘 드러낸다.

"대신 해 주는 사용자" 도 자주 빠진다. 설계는 "본인이 본인 것을" 을 가정하는데 현실은 아니다. 고객센터 상담원, 보호자, 비서, 총무 담당자가 남의 것을 대신 처리한다. 그 경로의 권한 처리가 거의 항상 덜 다듬어져 있다.

퍼소나로 한 세션을 돌려 보면

"성격 급한 사용자" 로 결제 화면을 30분 보면 이런 식이 된다.

- 결제 버튼을 누르고 1초 기다렸다가 한 번 더 누른다
  → 요청이 두 번 나가는가? 주문이 두 건 생기는가?
- 로딩 중에 뒤로가기를 누른다
  → 결제는 진행됐는데 화면은 장바구니로 돌아오는가?
- 완료 화면에서 새로고침한다
  → 또 결제되는가? 아니면 "이미 처리됨" 이 뜨는가?
- 완료 화면 주소를 복사해 두고 나중에 다시 연다
  → 남의 주문도 번호만 바꾸면 보이는가?
- 결제 중에 창을 닫고 다시 들어온다
  → 돈은 빠졌는데 주문이 없는 상태가 되는가?

다섯 줄 전부 "급한 사람" 이라는 한 가지 설정에서 나왔다. 중립적으로 "결제를 테스트한다" 고 했으면 첫 줄 정도에서 멈췄을 것이다.

그리고 다섯 줄 중 네 줄이 "돈과 주문이 어긋나는" 쪽을 겨냥한다. 퍼소나를 입으면 그 사람이 겪을 피해 쪽으로 자연스럽게 손이 간다 — 이것이 퍼소나의 진짜 효과다.

세 축을 섞으면 더 세진다

순서·상호작용·퍼소나는 따로 쓰는 것이 아니라 겹쳐 쓸 때 효과가 크다. 레슨 5에서 본 조합의 원리와 같다.

퍼소나(성격 급한 사용자) × 상호작용(두 창) × 순서(뒤로가기)

두 창에서 같은 주문을 열어 두고, 한쪽에서 결제를 누른 직후 다른 쪽에서 뒤로 갔다가 다시 결제를 누른다.

이런 조합은 아무도 케이스로 적지 않는다. 적으려면 그 상황이 생길 수 있다는 것을 먼저 알아야 하는데, 알면 이미 고쳤을 것이다.

다만 조합을 늘릴수록 재현 절차가 길어진다. 결함을 찾았으면 최소한의 절차로 줄이는 작업을 따로 해야 한다 — 세 가지 중 어느 것이 꼭 필요한지 하나씩 빼 보는 것이다(레슨 5의 "하나씩 되돌리기").

흔히 깨지는 순서 열 가지

막혔을 때 꺼내 쓰는 목록이다. 어느 제품에서나 그대로 시도할 수 있다.

1. 완료 화면에서 새로고침한다
2. 완료 화면 주소를 복사해 두고 나중에 다시 연다
3. 중간 단계 주소로 직접 들어간다
4. 제출 버튼을 빠르게 두 번 누른다
5. 처리 중에 뒤로가기를 누른다
6. 처리 중에 창을 닫고 다시 들어온다
7. 두 창을 띄워 한쪽에서 바꾸고 다른 쪽에서 저장한다
8. 한쪽에서 로그아웃하고 다른 쪽을 계속 쓴다
9. 오래 켜 둔 화면에서 그대로 제출한다(세션 만료)
10. 외부(결제·인증)에 갔다가 아주 늦게 돌아온다

열 가지를 다 하면 20분쯤 걸리고, 처음 보는 제품에서도 한두 건은 나온다. 특히 1·4·7번이 생산성이 높다.

9번은 자주 빠지는데 실제로 흔하다. 사용자는 화면을 열어 두고 점심을 먹으러 간다. 돌아와서 제출하면 세션이 끊겨 입력이 통째로 날아가는 경우가 많고, 그건 사용자에게 꽤 큰 피해다.

상태를 가진 화면이 특히 위험하다

순서 바꾸기가 잘 통하는 자리는 정해져 있다. 여러 단계에 걸쳐 무언가를 모아 두는 화면이다.

마지막 줄이 가장 약하다. 우리 화면을 떠났다가 돌아오는 순간, 그 사이에 사용자가 무엇을 했는지 우리는 모른다. 결제창에서 10분을 머물렀을 수도, 뒤로가기로 돌아왔을 수도, 아예 다른 탭에서 장바구니를 비웠을 수도 있다.

그래서 외부를 다녀오는 흐름에서는 돌아온 뒤의 상태를 다시 확인하는지를 본다. "결제는 성공했는데 그사이 재고가 떨어진 경우" 같은 것이 여기서 나온다. 모듈 3 레슨 3의 상태 전이 다이어그램을 그려 두면 어디로 돌아올 수 있는지가 눈에 보인다.

실무에서 왜 필요한가

실제 사용자는 QA가 상상하는 "정상적인 순서"를 그대로 따르지 않는다. 멀티탭, 뒤로가기 남용, 성급한 반복 클릭은 실무에서 정말 흔하게 일어나고, 이로 인한 결함(중복 제출, 동시성 문제, 상태 꼬임)은 사용자에게 직접적인 피해를 준다. 퍼소나 기법은 이런 다양한 실제 사용 패턴을 체계적으로, 그러나 스크립트 없이 탐험하게 해주는 실용적인 도구다.

여기서 나오는 결함들에는 공통점이 하나 있다. 대부분 "가끔" 터진다. 두 창을 동시에 쓰는 사용자는 전체의 몇 퍼센트이고, 뒤로가기를 쓰는 순간도 흔치 않다. 그래서 운영에서는 "재현이 안 되는 이상한 문의" 로 들어온다.

이 레슨의 기법을 아는 사람은 그 문의를 받았을 때 먼저 묻는 질문이 다르다 — "혹시 두 군데서 열어 두셨나요", "중간에 뒤로 가셨나요", "두 번 누르셨나요". 세 질문이면 상당수가 재현된다. 레슨 12의 재현 불가능한 버그 대응이 실제로는 이 목록에서 시작된다.

퍼소나를 쓸 때 조심할 것

유용한 만큼 오해를 만들기도 쉽다. 두 가지를 조심한다.

하나, 사람을 비하하지 않는다. "기술에 익숙하지 않은 사용자" 를 "못하는 사람" 으로 쓰면 팀 안에서 반감이 생기고, 실제로 그 집단을 깔보는 설계로 이어진다. 퍼소나는 능력이 아니라 상황을 가리킨다 — 급한 것은 성격이 아니라 지하철에서 한 손으로 쓰는 상황일 수 있다.

둘, 실제 사람을 모델로 삼지 않는다. "영업팀 OO 과장님 같은 사용자" 처럼 쓰면 그 사람 이야기가 되어 버린다. 퍼소나에는 역할과 상황만 넣고 이름은 넣지 않는다. 레슨 3에서 헤드라인에 사람을 안 넣는 것과 같은 이유다.

접근성 퍼소나는 특히 조심한다. "화면을 못 보는 사용자" 는 보조 기술을 쓰는 사용자다. 그 사람은 못 쓰는 것이 아니라 다른 방식으로 잘 쓰는 사람이고, 못 쓰게 만든 것은 제품 쪽이다. 이 관점이 모듈 49의 출발점이다.

퍼소나는 팀의 자산이 된다

퍼소나를 그때그때 떠올리면 매번 비슷한 것만 나온다. 제품에 맞는 퍼소나 대여섯을 정해 두고 돌려 쓰는 편이 낫다.

정할 때는 두 곳에서 가져온다.

• 실제 데이터 — 고객 문의가 많은 유형, 이탈이 많은 구간, 지원 요청이 몰리는 기능. 진짜 겪는 사람들이다
• 안 보이는 사람 — 데이터에 안 나타나는 사람들. 접근성이 필요해서 아예 못 쓰고 떠난 사람은 데이터에 안 남는다

두 번째가 자주 빠진다. 데이터만 보면 이미 쓰고 있는 사람의 문제만 보이고, 쓰지 못해 떠난 사람은 숫자에 없다. 접근성과 초보 사용자 퍼소나가 그 공백을 메운다(모듈 49).

정해 둔 퍼소나는 레슨 2의 차터와 짝지어 쓴다 — "결제를, 성격 급한 사용자가 되어 탐험해서…" 처럼 차터의 자원 칸에 넣으면 된다.

찾은 것을 어떻게 보고하나

순서·동시성 결함은 재현 절차가 길어지는 특성이 있다. 그대로 적으면 개발자가 읽다가 포기한다. 세 가지를 지킨다.

하나, 결정적인 조건을 맨 위에 쓴다. 절차 열 줄보다 "두 창을 동시에 열어 둔 상태에서만 발생" 한 줄이 먼저다. 그 한 줄이 있으면 개발자가 나머지를 빠르게 따라온다.

둘, 타이밍을 숫자로 적는다. "빠르게 두 번" 은 사람마다 다르다. "1초 안에 두 번", "응답이 오기 전에" 처럼 기준을 적는다. 못 재겠으면 "로딩 표시가 사라지기 전에" 같은 관찰 가능한 기준으로 대체한다.

셋, 어느 쪽이 틀렸는지 적는다. 두 창을 쓴 결함이면 어느 창의 결과가 남았는지가 핵심이다. "A 창에서 저장한 값이 사라지고 B 창의 옛 값이 남는다" 처럼 방향을 적는다.

이 셋이 들어가면 재현 절차가 길어도 읽힌다. 모듈 6 레슨 2의 결함 리포트 원칙을 이 레슨의 상황에 맞춘 것이다.

이 기법이 안 통하는 곳

사람이 직접 조작하지 않는 기능에는 퍼소나가 안 먹는다. 배치 처리, 시스템 간 연동, 자동 정산 같은 것들이다.

대신 그쪽에는 다른 종류의 "순서 바꾸기" 가 있다. 호출 순서를 바꾸고, 응답을 늦게 주고, 중간에 끊고, 같은 요청을 두 번 보낸다. 사람 대신 다른 시스템이 비정상적으로 행동하는 경우를 상상하는 것이다.

오른쪽은 레슨 10(화면 없는 곳 탐험)과 모듈 12(창구 테스트)에서 다룬다. 발상은 같고 대상만 다르다.

채용시장에서의 위치

이 레슨의 내용은 "어떻게 그런 걸 생각하셨어요" 라는 반응을 만드는 쪽이다. 면접에서는 두 형태로 확인된다.

• "테스트 케이스에 없는 걸 어떻게 찾으시나요?" — 순서·상호작용·퍼소나 세 축을 말할 수 있으면 방법이 있는 사람으로 읽힌다
• "동시성 결함을 다뤄 본 적 있나요?" — "두 창을 띄워 같은 데이터를 수정했더니 뒤에 저장한 쪽이 앞의 변경을 지웠습니다" 처럼 구체적인 사례로 답할 수 있어야 한다

두 번째는 특히 중요하다. 동시성은 말로만 아는 사람과 실제로 재현해 본 사람이 바로 갈리는 주제다. 두 창 실험은 10분이면 되므로, 지금 쓰는 서비스에서 한 번 해 보고 그 경험을 가져가는 편이 낫다.

공고 문구로는 "다양한 사용자 시나리오 설계", "크로스 브라우저·멀티 디바이스 검증", "동시성·경쟁 상태 분석" 같은 형태로 나온다.

실습 과제

과제 1 — 순서 바꿔보기 (10분)

"3단계로 이뤄진 회원가입"(①기본정보 ②이메일인증 ③약관동의)에서 정상 순서가 아닌 시도를 3가지 적는다.

과제 2 — 퍼소나로 탐험 계획 짜기 (12분)

"성격 급한 사용자"와 "기술에 익숙하지 않은 사용자" 두 퍼소나를 골라, 각각이 "온라인 설문조사 응답 제출" 기능을 어떻게 다르게 탐험할지 3줄씩 적는다.

과제 3 — 두 창으로 겹쳐 보기 (12분)

자주 쓰는 서비스에서 같은 계정으로 창 두 개를 띄우고(일반 창 + 시크릿 창 또는 다른 브라우저), 한쪽에서 바꾼 것이 다른 쪽에 어떻게 반영되는지 본다.

• 한쪽에서 수정 → 다른 쪽에서 먼저 열어 둔 화면으로 저장
• 한쪽에서 로그아웃 → 다른 쪽에서 계속 쓸 수 있는가
• 한쪽에서 삭제 → 다른 쪽에서 그것을 열면 어떻게 되는가

자가 체크리스트

• 순서를 바꿔가며 탐험하는 것이 왜 상태 전이 결함을 잡는 데 유효한지 설명할 수 있다
• 여러 상호작용 방식(멀티탭, 붙여넣기 등)을 예시로 들 수 있다
• 퍼소나 기법을 최소 3가지 만들어 각각 다른 탐험 경로를 상상할 수 있다
• 퍼소나 기법이 "숨은 변수 찾기"(레슨 5)와 어떻게 연결되는지 설명할 수 있다
• 순서를 흐트러뜨렸을 때의 세 가지 고장 모양(뒤섞임·중복·통과)을 구분할 수 있다
• 두 창(일반+시크릿)으로 동시성·권한·로그아웃 전파를 확인할 수 있다
• 퍼소나를 고를 때 나와 가장 다른 사람을 고르는 이유를 말할 수 있다
• 외부(결제·인증)를 다녀오는 흐름이 왜 특히 약한지 설명할 수 있다
• 조합으로 찾은 결함의 재현 절차를 최소한으로 줄일 수 있다

흔한 실수

• "정상 순서"만 계속 반복해서 탐험한다. 이미 스크립트 테스트로 충분히 다뤄진 경로다. 탐색적 테스팅의 가치는 그 바깥에 있다.
• 퍼소나를 형식적으로만 만들고 실제로 그 캐릭터가 되어 행동하지 않는다. 퍼소나의 힘은 "이 사람이라면 정말 이렇게 했을 것"이라는 몰입에서 나온다.
• 동시성(멀티탭 등)을 시도할 자원이나 시간이 없다고 아예 생략한다. 간단한 시나리오(같은 계정 두 탭)는 시간이 오래 걸리지 않으니 최소한 한 번은 시도해볼 가치가 있다.
• 앞으로 가는 길만 본다. 취소·수정·뒤로가기처럼 되돌아오는 경로가 거의 항상 덜 설계돼 있다. 거기부터 본다.
• 단계를 건너뛰어 들어갔을 때 화면이 열리는 것을 그냥 넘긴다. 그건 검증이 화면에만 있고 서버에는 없다는 뜻이고, 보안 결함이다.
• 퍼소나를 자기와 비슷한 사람으로 고른다. 효과가 거의 없다. 나와 가장 다른 사람을 골라야 안 가던 길로 간다.
• 조합으로 찾은 뒤 절차를 안 줄인다. 재현 절차가 열 줄이면 개발자가 재현을 포기한다. 하나씩 빼 보며 꼭 필요한 조건만 남긴다.

참고 자료

• 이 커리큘럼 안: 레슨 5(숨은 변수 — 조합의 원리), 레슨 8(상태와 전이 발견), 레슨 12(재현 절차 줄이기)
• 이 커리큘럼 안: 모듈 3 레슨 3(상태 전이 — 되돌아올 수 있는 길을 그린다), 모듈 49(접근성 — 보조 기술을 쓰는 퍼소나), 모듈 50 레슨 2(인가 우회)
• Elisabeth Hendrickson, Explore It! — 순서·상호작용 변주와 퍼소나 기법을 다룬 장
• Alan Cooper, The Inmates Are Running the Asylum — 퍼소나 개념의 원류가 된 UX 설계 고전 (테스트 목적으로 응용됨)
• 이 레슨의 "흔히 깨지는 순서 열 가지" 는 새 제품을 맡았을 때 가장 먼저 돌려 볼 목록이다. 레슨 14의 치트시트에도 같은 항목이 들어 있다