실패하는 프로덕트팀은 조용한 가정을 안고 일해요.
“사용자도 우리처럼 생각할 거야.”
“이 정도는 기본이지, 다들 알잖아.”
“필요하면 설명하면 되지.”
이런 가정이 합리적으로 느껴지는 이유는, 우리 자신의 맥락에 기반하고 있기 때문이에요.
하지만 사용자 리서치는 이런 가정이 얼마나 쉽게 무너지는지 반복적으로 보여주죠.
구글에서 오랜 기간 검색 UX를 연구한 댄 러셀(Dan Russell)이 공유한 사례가 이 간극을 잘 보여줘요.
자격증 시험을 준비하는 버스 기사를 인터뷰하던 중, 그는 그녀가 100페이지짜리 웹 문서를 한 줄 한 줄 스크롤하며 특정 규정을 찾고 있는 것을 관찰했어요.
브라우저의 검색 단축키를 왜 쓰지 않느냐고 물었을 때, 그녀의 대답은 단순했어요.
그런 기능이 있는 줄 몰랐다는 거예요.
프로덕트팀에게는 놀라운 일이지만, 실제 사용 환경에서는 흔한 일이에요.
“기본”이라고 느끼는 것은 보편적 지식이 아니라, 기술에 익숙한 프로덕트팀의 도구, 습관, 멘탈 모델(Mental Model)이 만들어낸 친숙함인 경우가 많거든요.
그 친숙함이 바로 맥락(Context)이에요. 이번 시리즈에서는 맥락 기반 디자인(Contextual Design)의 핵심 개념부터 실전 활용법까지 단계적으로 살펴볼게요. 첫 편에서는 사용 맥락이 무엇인지, 그리고 사용자에게 직접 물어보는 방식이 왜 한계가 있는지 알아볼게요.
1. 맥락이 무시될 때 벌어지는 일
대부분의 사람들은 맥락이 중요하다는 데 동의해요. 그런데 실제로는 많은 팀이 맥락을 깨뜨리고 있죠.
부주의해서가 아니에요. 배포를 빨리 해야한다는 압박이 조용히 행동을 바꿔놓기 때문이에요.
1) 회의실에 갇혀버린 리서치
리서치가 현실에서 분리될 때 벌어지는 일이에요.
- 줌으로만 인터뷰한다
- 가정에 기반한 질문을 던진다
- 실제 사용자 대신 슬라이드 기반 퍼소나로 대체한다
환경이 사라지면, 방해 요소도, 우회 방법도, 제약 조건도 함께 사라져요. 결과물은 깔끔하고 전문적으로 보이지만, 불완전해요.
2) 관찰 없이 요약부터 시작하기
프로덕트팀은 종합과 요약을 너무 좋아하는 경향이 있어요. 바로 인사이트, 패턴, 해결책으로 뛰어들죠.
이렇게 하면 가장 중요한 단계인 관찰 데이터의 공통점과 인사이트 도출을 건너뛰게 돼요.
팀이 날것의 행동을 직접 보지 못하면, 결론을 덜 신뢰하고 더 많이 논쟁하게 되거든요. 요약은 마지막에 와야 해요. 처음이 아니라요.
3) 해결책을 너무 빨리 만들기
가장 흔한 실패 유형이에요.
문제가 익숙하게 들리는 순간, 프로덕트팀은 해결책으로 달려가곤 하죠.
- “단축키를 추가하면 돼요”
- “이걸 자동화합시다”
- “토글을 넣으면 되죠”
하지만 성급한 솔루션은 맥락을 지극히 단순하게 평면화(Flattening)시켜요. 문제가 완전히 이해되기 전에 사고를 잠가버리는 거죠.
4) “대표 사용자”라는 환상
페르소나(Persona)는 유용할 수 있지만, 사용자를 “평균화”하면 현실과 멀어지는 경우가 많아요.
실제 사용자는 이렇거든요.
- 서로 모순된다
- 비일관적으로 행동한다
- 제약에 다르게 적응한다
맥락 기반 리서치는 이러한 변이(Variation) 사항들을 드러내줘요.
지나친 단순화는 그 변이를 숨겨버리죠.
더 빠른 종합, 더 깔끔한 내러티브, 더 쉬운 정렬은 효율적으로 느껴질 수 있지만, 맥락 없는 속도는 실패에 빠르게 다다르게 하는 자신감을 만들어내요.
2. 사용 맥락(Context of Use)이 의미하는 것
제품은 그 자체로는 의미가 없어요.
- 기능은 기본적으로 유용한 게 아니에요
- UI는 기본적으로 사용하기 쉬운 게 아니에요
- 워크플로우는 기본적으로 직관적인 게 아니에요
이 모든 것은 특정 사용 맥락(Context of Use) 안에서만 의미를 가져요.
1) 제품은 실제 상황 안에서만 의미를 가진다
프로덕트팀 내부에서는 종종 기능을 사용 환경과 분리된 상태로 팀원들의 기준으로 평가하곤 해요.
- 이 기능이 명확한가?
- 이 플로우가 단순한가?
- 이 인터랙션이 효율적인가?
하지만 사용자는 프로덕트를 절대 프로덕트팀의 머릿속처럼 사용하지 않아요.
사용자가 프로덕트를 만나는 순간은 이렇죠.
- 어떤 작업을 완료하려고 하는 중이고 (= 작업과 목표)
- 시간과 주의력이 제한되어 있으며 (= 인지 부하)
- 불완전한 도구를 사용하고 있고 (= 장비 제약)
- 시끄럽거나 복잡한 물리적·사회적 환경 안에 있어요 (= 환경 제약)
디자인 리뷰에서는 명확하게 사용자에게 효용을 줄 것 같이 느껴지던 프로덕트가, 실제 상황에서는 혼란스럽거나 관련 없거나 심지어 스트레스를 줄 수 있는 이유가 여기에 있어요.
2) 사용자에게 원하는 것을 물어보면 왜 실패할까
“사용자에게 직접 물어보면 되지.”
이 말은 사용자 중심적으로 들리지만, 실제로는 엄청난 실패로 이어질 수 있어요.
설문조사, 인터뷰, 포커스 그룹은 선의로 가득한 질문들로 채워져 있지만, 자신감 넘치는 답변과 오해의 소지가 있는 결론을 만들어내곤 하죠.
문제는 사용자가 거짓말을 하는 게 아니에요. 문제는 사람들이 말하는 선호와 실제 상황에서 하는 행동이 자주 다르다는 거예요.
(1) 사람들은 자기가 원하는 것을 모른다
사용자에게 “뭘 원하세요?”라고 물으면, 보통 세 가지 중 하나를 해요.
- 이상적인 세계를 묘사한다
- 어딘가에서 본 기능을 묘사한다
- 자신의 현재 행동을 사후에 합리화한다
이 중 어느 것도 실제 상황에서의 행동을 반영하지 않아요.
이건 사용자의 도덕적 문제가 아니에요. 인간의 인지가 작동하는 방식이에요.
대부분의 행동은 습관적이고, 맥락에 따라 달라지며, 반응적이거든요.
(2) 설문조사와 포커스 그룹의 한계
설문조사와 포커스 그룹에는 구조적 제약이 있어요.
- 사용자를 실제 환경에서 분리
- 행동 대신 성찰을 강요
- 정확성이 아니라 자신감 있는 표현이 보상받음
그 결과, 현실이 아닌 의견을 수집하게 돼요. 의견 기반 리서치에서는 좋게 들렸던 기능이 출시 후에 저조한 성과를 보이는 이유가 여기에 있어요.
(3) 목표와 솔루션 구분하기
제품 발견(Product Discovery) 과정에서 일어나는 가장 흔한 실수 중 하나는 목적와 해결책을 혼동하는 거예요.
사용자가 이렇게 말할 때가 있죠.
- “더 빠른 대시보드가 필요해요”
- “필터가 더 많았으면 좋겠어요”
- “이게 자동화되면 좋겠어요”
이건 해결책이에요. 이러한 해결책은 제안하는 사람의 지식에 의해 제한되고 형성되죠. 그렇기 때문에 본질적인 배경을 부분적으로 다룰 수밖에 없어요.
그렇기에 진짜로 파악해야 하는 것들은 다음과 같아요.
- 왜 이게 필요할까?
- 무엇을 달성하려는 걸까?
- 현재 업무 흐름에서 무엇이 문제가 되고 있을까?
(4) 맥락 속 행동이 보여주는 것
사용자가 원하는 것을 묻는 대신, 프로덕트팀은 행동을 이해하는 데 집중해야 해요.
- 사용자가 달성하려는 것은 무엇인가?
- 오늘 그것을 어떻게 하고 있는가?
- 어디서 어려움을 겪거나 느려지는가?
- 어떤 우회 방법(Workaround)을 만들어냤는가?
이 질문들은 사용자가 겪고 있는 제약 조건을 드러내줘요. 이 제약 조건이야말로 가치를 창출하는 기회가 존재하는 곳이에요.
3. 사용 맥락의 네 가지 요소
사용 맥락(Context of Use)은 제품이 사용되는 전체 상황을 설명해요.
단순히 사용자만을 다루는 것이 아니에요. 사용자를 둘러싼 환경과 체계 모두를 다루는 것이예요.
이를 네 가지 요소로 나눠서 살펴볼 수 있어요.
| 요소 | 다루는 내용 | 왜 중요한가 |
|---|---|---|
| 사용자(Users) | 경험 수준, 멘탈 모델, 사전 지식, 기대치를 포함하여 누가 사용하는가 | 인구통계가 비슷한 사용자도 아는 것과 가정하는 것에 따라 전혀 다르게 행동 |
| 작업(Tasks) | 기능이나 UI가 시사하는 것을 넘어, 사용자가 실제로 달성하려는 것 | 프로덕트는 더 큰 목표의 작은 단계인 경우가 많고, 이것이 사용 방식을 결정 |
| 장비(Equipment) | 과업 완료에 사용되는 기기, 소프트웨어, 입력 방식, 우회 방법 | 도구의 제약이 행동에 강하게 영향을 미치며, 예상 밖의 사용자 행동을 설명 |
| 환경(Environment) | 소음, 방해, 압박, 위계 등 물리적·사회적 조건 | 단순한 워크플로우도 주변 환경을 고려하지 않으면 무너질 수 있음 |
1) 사용자
누가 이 프로덕트를 사용하는가?
- 경험 수준
- 멘탈 모델(Mental Model)
- 이미 알고 있는 것
- 프로덕트가 어떻게 작동할 것이라 가정하는 것
인구통계적으로 동일해 보이는 두 사용자도, 멘탈 모델이 다르면 완전히 다르게 행동할 수 있어요.
2) 작업
사용자가 실제로 하려는 것은 무엇인가?
우리가 생각하는 것이 아니에요. 기능 이름이 시사하는 것도 아니에요.
행동 뒤에 숨겨진 진짜 목표를 파악해야 해요. 제품은 종종 훨씬 더 큰 작업 안에서 이뤄지는 작은 한 단계에 불과하거든요.
3) 장비
어떤 도구가 관련되어 있는가?
- 기기 유형
- 소프트웨어 환경
- 입력 방식
- 우회 방법과 단축키
장비의 제약은 우리가 예상하는 것보다 행동에 훨씬 더 큰 영향을 미쳐요.
4) 환경
제품은 어디서 사용되는가?
- 물리적 환경 (소음, 움직임, 방해)
- 사회적 환경 (압박, 위계, 협업)
“단순한” 워크플로우도 환경이 바뀌면 완전히 무너질 수 있어요.
이런 핵심 원칙으로 이어지죠.
사용성(Usability)은 사용 맥락에 달려 있다. 맥락 없이는 사용성은 이론적 개념에 불과하다.
환경 요소를 비유하면, 조용한 카페에서 코딩하는 것과 시끄러운 오픈 오피스에서 코딩하는 것의 차이와 같아요. 같은 사람, 같은 노트북, 같은 코드인데, 환경이 바뀌면 집중력, 에러 발생률, 작업 방식이 모두 달라지죠. 프로덕트도 마찬가지로, 사용 환경을 무시하고 설계하면 “왜 사용자들이 이렇게 실수를 많이 할까?”라는 의문에 답을 찾지 못해요.
4. 맥락이 없을 때 vs. 맥락이 있을 때
| 의사결정 영역 | 맥락이 없을 때 | 맥락이 있을 때 |
|---|---|---|
| 프로덕트 논의 | “사용자에게 이게 필요해”, “경쟁사가 가지고 있어” 같은 기능 중심 주장 | 관찰된 워크플로우와 실제 상황에 기반한 논의 |
| 우선순위 결정 | 모든 게 중요해 보이고 트레이드오프가 자의적 | 맥락이 옵션을 좁혀주고 지금 왜 중요한지 명확 |
| 의사결정 역학 | 직급과 직관이 결정을 지배 | 관찰된 현실이 공유된 기준점이 됨 |
| 실행 품질 | 불명확한 제약 때문에 과도하게 만들고 느리게 실행 | 실제 제약에 맞춰 집중적으로 실행 |
| PRD와 요구사항 | 상황적 근거 없는 기능 목록 | 제약과 원하는 결과로 프레이밍된 요구사항 |
| 팀 신뢰 | 결정에 대해 반복적으로 정당화하고 논쟁 | 공동의 이해와 판단에 대한 신뢰가 형성 |
| 사용하는 언어 | “제 생각에는”, “이건 혼란스러운 것 같아요” | “우리가 관찰한 바로는”, “이게 사용자의 워크플로우를 깨뜨려요” |
맥락이 없으면, 팀은 의견, 직감, 과거 경험에 의존해서 빈 곳을 채우게 돼요. 결정은 내려지지만, 무겁고, 취약하고, 방어하기 어려운 결정이 되기 쉽죠.
맥락이 명확하고 공유되면, 의사결정의 성격 자체가 바뀌어요. 팀은 자신이 믿는 것을 논쟁하는 대신, 관찰한 것을 기반으로 추론하기 시작하거든요.
맥락이 의견 불일치를 없애주는 건 아니에요. 의견 불일치의 대상을 바꿔주는 거예요.
팀원의 선호에 대한 것을 놓고 다투는 대신, 사용자의 실제 현실에 대한 해석을 논의하게 되죠. 이 전환만으로도 의사결정이 빨라지고, 실행 속도가 올라가며, 팀 내 지속적인 신뢰가 형성될 수 있어요.
맥락의 과소평가된 이점 중 하나는, 맥락이 공통의 기준점이 된다는 거예요.
“이건 혼란스러운 것 같아요”라고 말하는 대신, “이게 우리가 관찰한 사용자의 워크플로우를 깨뜨려요”, “이 지점에서 중요한 마찰이 추가돼요”라고 말할 수 있게 되죠.
이것이 협업의 톤을 바꿔줘요.
다음 편에서는 사용 맥락을 실제로 파악하는 방법인 맥락적 탐구(Contextual Inquiry)의 정의와 핵심 원칙을 살펴볼게요.
맥락 기반 디자인 시리즈