릴스를 보는데 토스에서 휴리봇을 사용하여 UT를 진행한다고 하길래 한번 찾아봐서 테스트도 해보았다.[LINK]
생각보다 의미있는 상황이라서 왜 테크 블로그에까지 기고 했는지 알것 같았다.
1. 왜 토스는 AI 가상 유저 리서치 툴인 휴리봇을 만들었을까?
ㄱ. 게릴라 UT의 한계와 디자이너의 심리적 허들
서비스를 만드는 기획자와 디자이너는 항상 사용자의 목소리를 듣고 싶어 한다. 토스(Toss)팀 역시 온라인으로 빠르게 실제 유저를 만나 피드백을 받는 ‘유저 무물데이’ 같은 훌륭한 리서치 프로그램을 운영하고 있었다.
하지만 아무리 가벼운 UT(사용자 테스트)라고 해도 질문지를 작성하고, 프로토타입 시안을 준비하고, 실제 사용자를 섭외하는 데에는 최소 1시간 이상의 리소스가 소요되곤 했다. 또한, 낯선 사용자를 직접 만나 인터뷰를 진행한다는 것 자체가 실무자에게는 은근한 심리적 부담감으로 작용하기도 했다.
상황이 이렇다 보니 버튼의 위치나 화면 속 작은 문구 하나를 검증하기 위해 매번 정식 UT를 열 수는 없었다. 결국 팀 내 동료들에게 슬쩍 화면을 보여주며 의견을 묻는 ‘게릴라 UT’로 대체하는 경우가 많았으나, 이는 동료들의 집중을 방해하고 객관적인 유저의 시선을 온전히 담아내기 어렵다는 한계가 있었다.
ㄴ. ‘검증’이 아닌 ‘점검’을 위한 도구의 필요성
토스 팀은 이러한 문제를 해결하기 위해 디자인 작업실에서 단 몇 초 만에 가볍게 화면의 사용성을 점검할 수 있는 가상 인터뷰 AI 에이전트, ‘휴리봇’을 기획하게 되었다.
여기서 핵심은 AI의 답변을 진짜 유저의 의견을 100% 대변하는 ‘검증’의 수단으로 보지 않았다는 점이다. 대신 디자이너가 자신의 결과물에 매몰되어 미처 놓치기 쉬운 UI/UX적 약점이나 오류를 빠르게 짚어내는 ‘점검(휴리스틱 이슈 확인)’의 목적으로 역할을 철저히 제한했다.
그 결과, 20~40대의 가장 대중적인 일반 사용자 페르소나를 베이스로 삼고, 이미지 인식 기능(OCR)을 결합하여 화면 시안을 툭 던지면 즉시 피드백을 주는 똑똑한 AI 리서치 파트너가 탄생했다.
2. 사람처럼 말하는 UT 에이전트를 만드는 5가지 프롬프트 엔지니어링 원칙
토스 테크 블로그에서 밝힌 휴리봇의 핵심 비결은 결국 프롬프트 엔지니어링(Prompt Engineering)에 있다.
LLM(대형 언어 모델)이 일반적인 AI의 딱딱한 답변 스타일을 버리고, 실제 인터뷰에 참여한 날것의 사용자처럼 행동하게 만드는 5가지 핵심 작성 원칙은 다음과 같다.
ㄱ. 규칙 나열 대신 구체적인 역할과 상황 부여하기
AI에게 “부정적으로 답변해”, “솔직하게 말해”와 같은 단순 규칙을 나열하는 것은 효과가 떨어진다. 그 대신 구체적인 서사를 부여해야 한다. 예시로 “너는 토스를 3년째 쓰고 있는 20대 대학생이야” 같은 명확한 페르소나를 주입하고, “지금 새로운 송금 완료 화면을 처음 본 상황이야”라는 맥락을 설계했을 때 AI는 비로소 인격체처럼 움직이기 시작한다.
ㄴ. 구체적인 구어체와 추임새 지시하기
AI에게 그냥 자연스럽게 말하라고 하면 여전히 정제된 문장을 출력하기 일쑤다. 프롬프트에 “실제 만나서 대화하는 것처럼 사람처럼 말해줘”라거나 “음…”, “아~” 같은 추임새를 섞어달라고 명시해야 한다. 이를 통해 AI는 실제 유저가 고민할 때 내는 소리나 멈춤 현상까지 재현하며 현실감을 극대화한다.
ㄷ. 금지(Don’t)보다 권장(Do) 문장 사용하기
“전문가처럼 분석하지 마라”, “화면을 다 읽지 마라” 같은 금지형 명령어는 AI가 프로세스를 수행할 때 종종 혼선을 빚게 만든다. 이보다는 “일반 사용자의 시선에서 느껴지는 감정을 말해줘”, “눈에 띄는 큰 글씨나 버튼 위주로 인지해 줘”와 같이 긍정형 권장 명령어를 사용할 때 지침을 훨씬 더 명확하게 준수한다.
ㄹ. OCR(이미지 인식) 활성화 유도하기
와이어프레임이나 캡처본 화면을 올렸을 때, AI가 화면 속 텍스트와 UI 컴포넌트 간의 관계를 정확히 인지하도록 유도해야 한다. 텍스트 정보뿐만 아니라 시각적인 배치 체계까지 함께 고려하여 답변하도록 프롬프트 구조를 짜는 것이 중요하다.
ㅁ. 문자를 덜 꼼꼼하게 읽게 제약 걸기 (현실성 부여)
실제 유저들은 화면에 적힌 상세한 안내 문구를 정독하지 않는다.
대충 훑어보고 본능적으로 버튼을 누른다. AI에게도 이러한 현실성을 부여해야 한다. “화면의 모든 글을 꼼꼼하게 읽지 말고, 흐릿하게 훑어보며 직관적으로 눈에 띄는 요소 위주로 먼저 행동해 줘”라는 제약을 걸었을 때, 비로소 진짜 유저다운 날카롭고 현실적인 피드백이 도출된다.
3. 실무 정착을 위한 토스팀의 MVP 전략과 실제 활용 사례
ㄱ. 무거운 개발 대신 가볍게 가치를 검증한 MVP
토스 팀은 휴리봇을 만들 때 처음부터 거창한 시스템을 개발하지 않았다. 이미지 업로드가 가능하고 프롬프트를 미리 심어둘 수 있는 기존의 사내 챗봇 툴을 활용하여 프로토타입을 빌딩했다.
디자이너들에게 먼저 사용해 보게 한 결과, 업무 속도가 비약적으로 빨라졌을 뿐만 아니라 본인의 디자인을 제3자의 시각에서 바라보는 ‘메타인지’ 향상에 엄청난 도움을 준다는 가치를 확인했다. 이후 정식 사내 서비스로 내재화할 때도 불필요한 부가 기능은 과감히 제외하고 [이미지 넣기 > 질문하기 > 답변 받기]라는 본질적인 핵심 유저 저니(User Journey)만 남겨 UI를 극도로 단순화했다.
ㄴ. 디자인 약점을 잡아낸 실제 활용 사례
현재 토스의 디자이너들은 시안 아이데이션 단계나 최종 배포 직전에 이 AI 에이전트를 적극적으로 활용하고 있으며, 다음과 같은 크리티컬한 문제들을 미리 잡아내고 있다.
- 의도와 다른 해석 발견: 기획 의도와 무관한 그래픽 요소를 보고, 가상 유저가 전혀 다른 이벤트 페이지로 오해하는 현상을 포착하여 그래픽을 수정함.
- 다크 패턴 및 이탈 요소 감지: 상품 해지 페이지를 점검할 때, 가상 유저가 “탈출할 수 있는 취소나 닫기 버튼이 너무 안 보여서 답답하다”는 피드백을 남겨 유저 중심의 UI로 개선함.
- 모호한 카피라이팅 수정: 복잡한 금융 상품 안내 문장을 AI 에이전트가 제대로 이해하지 못하고 헤매는 모습을 확인한 뒤, 초등학생도 이해할 수 있는 쉬운 문구로 텍스트를 다듬음.
4. AI 에이전트로 만드는 나만의 가상 리서치 환경
토스의 휴리봇 사례가 주는 가장 큰 교훈은 AI를 인간의 완벽한 대체재로 보지 않고, 실무자의 가려운 곳을 긁어주는 든든한 서포터로 정의했다는 점이다.
Claude의 ‘프로젝트(Projects)’ 기능이나 ChatGPT의 ‘GPTs’를 활용하면, 토스 팀이 구축한 프롬프팅 원칙을 그대로 이식하여 나만의 가상 UT 환경을 만들 수 있다.
특히 여러 명의 페르소나를 심어두고 혼자서 난상 토론을 벌이게 만드는 ‘멀티 페르소나’ 방식을 적용하면, 혼자 일하는 1인 기획자나 디자이너도 언제든 수많은 가상 패널의 피드백을 실시간으로 수렴하는 놀라운 경험을 할 수 있게 될 것이다.
5. AI 가상 UT 에이전트 대화 모음
나는 나를 끼고 대화하지말고, 너네끼리 토론을 벌이라고 요청 했다. [프롬프트 자세히보기]
