[5월 TIL #11] 실험에서 얼마나 깊이 배울 것인가

실험 리뷰를 하다가 동료 분께서 "꼭 실험으로 해야 할까요?"라는 말씀을 해주셨다. 결국 실험 설계의 핵심이 "더 깊은 배움"에 있다는 것을 놓치고 있었다는 걸 느꼈다.

🪜 배움의 레이어

실험에서 배울 수 있는 깊이는 대략 이렇게 나눠볼 수 있다.

Layer 0. 수치가 오르는가
: "아이콘 레일을 보여주면 라이브러리 도달률이 오를까?"처럼 거의 상식으로 답이 보이는 층.

Layer 1. 얼마나 오르는가
: 효과 크기를 확인하는 층. ROI 판단이나 다른 처방과의 비교에는 쓸 수 있지만, 여전히 현상 측정에 가깝다.

Layer 2. 왜 오르는가
: 같은 결과를 만든 원인을 분리하는 층. 발견성 때문인지, 마찰 감소 때문인지, 기능 가치 때문인지 구분하는 것.

Layer 3. 우리 유저는 어떤 멘탈모델을 가지고 있는가
: 특정 UI를 넘어, 유저가 기능을 어떻게 이해하고 기억하고 다시 찾는지를 배우는 층.

 
좋은 실험은 수치가 오르는지를 확인하는 데서 끝나지 않는다. 결과가 어느 방향으로 나오든, "그래서 우리는 유저에 대해 무엇을 새로 알게 되었는가?"가 남아야 한다.
 

🔍 이번 실험은 어디에 있었나

돌아보면 이번 실험은 Layer 0에 가까웠다. "아이콘 레일을 보여주면 라이브러리 도달률이 회복될 것이다." 진입점을 더 잘 보이게 하면 도달률은 오를 가능성이 높고, 반대로 떨어질 가능성은 잘 상상되지 않는다. 낮은 수치에서 너무 빠르게 UI 처방으로 넘어갔고, 그 사이에 빠진 질문들이 있었다. 유저가 라이브러리에 가지 않는 이유는 무엇인가? 진입점을 못 찾은 것인가, 라이브러리라는 개념에 가치를 못 느낀 것인가, 저장한 논문을 다시 찾을 때 라이브러리를 떠올리지 않는 것인가?

1. 이 실험의 결과가 내가 예상하는 방향으로 나오면 — 그건 새로운 지식인가, 아니면 상식의 재확인인가?
2. "결과가 예상과 반대 방향으로 나오면 — 그게 가능한가? 그러면 우리는 무엇을 배우는가?

 

1번이 "재확인"이고 2번이 "거의 불가능"이면, 실험할 가치가 적은 가설인데 그 관점으로 생각해보지 않았었다. 이번 일은 결국 Layer 2,3 수준의 배움을 목표로 두지 않았기 때문에 일어난 문제들로 정리된다. 그 부재가 세 갈래로 갈라져 있었다.
 

1) 문제 정의가 선명하지 않았다

초반에 문제 정의를 또렷이 하려고 인터뷰를 시작했고, 신호도 있었다 — “사이드바가 라이브러리의 메인 진입점은 아닐 수 있다”는 힌트가 나왔다. 그런데 그 신호로 기존 가설을 흔들 만큼 깊이 가지 않았다. 결국 무엇을 배울 것인지가 또렷해지지 못한 채로 실험 설계로 넘어가버렸다.

→ 다음에는: 문제 정의가 또렷해질 때까지 머무르기
무엇을 배울지가 또렷해질 때까지 인터뷰, 데이터 분석 등의 앞 단계에 머무르려고 한다. 실험은 그 정의에서 나온 가설을 정량적으로 확인하는 다음 단계로 여기는 게 맞고 최종 배움을 확정하는 단계로 생각해야겠다.
 

2) 시안을 답으로 봤다

배움이 목표였다면 시안은 답이 아니라 가설을 테스트하는 도구가 됐을 거다. 그런데 이번엔 시안을 답처럼 들고 있었다. 피드백을 받았을 때도 다른 시안을 만들어볼 생각이 들지 않았고, 이 시안을 어떻게 설득할지로 머리가 굴러갔다.

→ 다음에는: 시안을 도구로 다루기

• 시안 여러 개 만들기: 한 시안만 만들면 그게 답처럼 보이기 쉽다. 여러 개를 만들면 “어떤 시안이 맞나”가 아니라 “각 시안이 어떤 가설을 테스트하는가”로 자연스럽게 시각이 바뀐다.

• 작은 검증을 더 자주 끼워 넣기: 시안의 근본 가정만 먼저 동료에게 보여주고 “이 가정 말 돼?“를 묻는 식. 완성된 시안을 들고 가면 그때부터는 이미 시안이 답처럼 굳어 있다.

 

3) 처방 범위가 비대해졌다

막상 작업하다 보니 시안의 범위가 넓어졌고, 그걸 멈출 기준이 없었다. 무엇을 배우려는지가 또렷했다면 “이 가설을 테스트하는 데 필요한 것만”이 자연스러운 기준이 됐을 텐데, 그 기준이 없으니 시안이 계속 비대해질 수밖에 없었다.

→ 다음에는: 기준점 만들고, 나머지는 백로그로

• 언제 멈출지에 대한 기준점 정하기: 가장 기본은 실험의 목표 자체다. “이 가설만 테스트한다”가 명확하면 거기에 필요한 것만 건드리면 되고, 목표가 기준점을 대신해준다. 그 외에 디자인 시스템 같은 것도 기준점 역할을 해줄 수 있을 것 같다. 동료 분 말처럼 컴포넌트 정리가 본질이 아니라, “왜 이 영역은 건드리고 저 영역은 안 건드리는지”를 시스템이 대신 답해주게 만드는 것.

 

• 현재 작업과 무관한 아이디어는 잘 저장하기: 예를 들어 “디자인 개선 백로그” 노션 페이지를 만들어 저장하는 방식을 쓴다면 여러 사항들을 실험과 엮지 않을 수 있을 것. 초점을 흐리는 여러 사항들을 잘 관리할 체계가 필요하다.

 

 

🔁 예전 실험은 무엇이 달랐나

한 달 전쯤 다른 실험을 한 적이 있다.
툴바 스타일 실험

논문에서 텍스트를 선택했을 때 뜨는 툴바(설명, 하이라이트, 번역, 주석, AI 질문) 디자인을 바꾸면 기능 사용률이 오를지를 본 실험이었다

그때는 “툴바 사용률이 낮다”를 바로 “버튼을 더 잘 보이게 하자”로 연결하지 않았다. “유저가 아이콘 전용 팝오버에서 기능의 존재 자체를 인지하지 못하고 지나친다”는 정성적 판단까지 내려간 다음에, 그 발견성 가설을 테스트하기 위해 세 시안을 설계했다.

A (Control): 기존 아이콘 전용 팝오버 — 변경 없음
B (Progressive): 텍스트 버튼 가로 배열 (설명·하이라이트·번역·주석·AI 질문)
C (Context Menu): 아이콘+텍스트 세로 메뉴

1. 실험을 통해 얻고 싶은 지식이 멘탈모델 수준까지 갔다. “기능을 기능으로 인지하는가”가 명확한 질문이었기 때문에 처방 단계로 빨리 넘어가지 않을 수 있었다.

2. 시안은 답이 아니라 가설을 테스트하는 세 가지 변형으로 다뤄졌다. 어느 시안이 정답이냐가 아니라, 발견성 가설이 맞는다면 어떤 형태가 더 잘 작동할지를 같이 보는 구조.

3. 처방 범위가 팝오버 UI 안으로 또렷하게 정해졌다. 발견성 가설을 테스트하는 데 필요한 범위가 명확했으니, 다른 영역으로 시안이 번지지 않았다.

위 세 가지가 다 같이 풀려 있었던 셈이다.

리뷰 전에 알 수 있었을까

처음에는 “리뷰 전에 내가 이걸 메타인지가 됐더라면” 하는 현타가 왔었다. 그러나 “내가 만든 것”을 혼자서 객관적으로 보는 건 매우 어렵고, 매몰비용이 클수록 더 어렵다. 리뷰는 그래서 필요한 것이다.

그럼에도 이번 회고를 통해 스스로 리뷰할 수 있는 장치를 잘 만들어두고 싶다.

1. 무엇을 배울지가 또렷해질 때까지 유저 리서치 단계에 머무르기. 실험은 그 정의에서 나온 가설을 정량적으로 확인하는 다음 단계로.
2. 시안을 답이 아니라 도구로 다루기. 여러 시안을 만들고, 완성 전에 근본 가정부터 동료에게 보여주기.
3. 처방 범위를 가설이 요구하는 만큼으로 좁히기. 그 외 아이디어는 백로그로.

실험을 잘하게 되는 건 단번에 되는 일이 아닌 것 같다. 그래도 한 번 더 또렷해진 것에 만족한다!! 굿!