휴리봇 이야기 #1: 토스는 AI 봇에게 사용자 인터뷰를 한다

🤔 ’사용자는 이 페이지를 어떻게 이해할까?’ 🤔 ‘화면이 복잡해 보이진 않을까?’ 🤔 ‘이 그래픽은 어떤 의미로 느껴질까?’

제품을 만들다 보면 사용자에게 궁금한 점이 참 많이 생기는데요, 내가 원할 때마다 사용자를 만나 궁금한 점을 물어볼 수 있다면 얼마나 좋을까요?

토스에서는 디자이너분들이 더 자주, 빠르게 제품의 사용성을 점검할 수 있게 토스 사용자처럼 학습된 AI ‘휴리봇’을 만들었어요. 휴리봇에게 내가 디자인한 화면을 보여주고 사용성과 관련된 질문을 하면 토스 사용자와 흡사한 의견을 줍니다. 단 몇 초만 에요.

혹시 AI 제품을 만들기 위해 그동안 ‘프롬프트 엔지니어링’만 신경 쓰고 계셨다면, 이번 글을 통해 실무에서 AI를 실제로 잘 활용하기 위해 프롬프팅 외에도 필요한 것들을 프롬프팅 전-중-후 단계 별로 알려드릴게요. 이해하기 쉽게 휴리봇을 제품화 하는 과정을 함께 설명해 드리면서요. *프롬프트(prompt)란? 생성형 AI에 특정 작업을 수행하도록 지시하는 자연어 텍스트로, 고품질의 아웃풋을 생성하기 위해 프롬프트를 최적화하는 프로세스를 ‘프롬프트 엔지니어링’이라고 함

01) 프롬프팅 전

해결하고자 하는 문제 좁히기

프로젝트를 시작할 때 우선으로 해야 하는 일은 해결하고자 하는 문제와 목표를 뚜렷하게 정의하는 것이에요. 어쩌면 당연한 이야기처럼 들릴 수 있지만, 그것이 명확해야 진행 과정에서 다시 처음으로 돌아가거나 막히는 일을 줄일 수 있어요.

휴리봇으로 해결하고자 했던 문제는 ‘UT의 스케일업’이었어요. 토스에는 ‘유저 무물데이’ 프로그램이 있어 디자이너가 원할 때면 언제든 사용자를 만나 온라인 UT 할 수 있는 환경이 잘 마련되어 있는데요. *유저무물데이란? 랜덤한 토스 사용자를 대상으로, 원하는 시간에 비대면 UT를 할 수 있는 프로그램 (자세한 내용은 아티클에서 확인할 수 있어요)

프로세스가 잘 마련되어있더라도, 디자이너가 UT를 하기 위해서는 UT용 프로토타입이나 질문지 등 필수적으로 준비해야 하는 것들이 있기 때문에 최소 1시간 이상의 준비 시간이 필요하고, 사용자를 만나는 게 심리적인 부담이 되어 더 많은 준비를 하게 될 때도 있어요.

아주 중요하거나 복잡한 제품일 경우, 사용자에게 사용성을 검증하는 것이 필수적이라 이 시간이 어쩔 수 없지만, 화면 내에 있는 작은 그래픽 하나, 한 문장, 작은 버튼의 사용성을 확인하기 위해서도 이런 준비 과정이 필요했기 때문에 빠르게 배포해야 하는 제품일 경우 UT를 진행하지 않고 바로 실험하거나, 주변에 있는 다른 직군의 팀원에게 “OO님, 이 문장 무슨 뜻인 것 같아요?”,”OO님, 이 그래픽 어떤 의미로 느껴져요?”라고 물어보며 게릴라 UT로 사용성을 확인하는 경우도 있었어요.

현재의 방식으로는 UT의 스케일업이 어렵고, 디자이너가 지금보다 훨씬 자주 가볍게 사용성을 점검하게 하려면 완전히 허들을 낮춘 새로운 UT 방식이 필요하겠다는 판단이 들었어요.

프로젝트 목표 정의하기

문제를 좁혔다면, 이것이 해결되었을 때 어떤 모습이길 기대하는지 목표를 정의해야 해요. 목표가 명확하면 AI 봇으로 만들고자 하는 상이 명확해지고, 그럼 프롬프팅을 훨씬 더 효율적으로 쉽게 할 수 있어요.

디자이너가 가벼운 사용성 점검을 자주 하게 하려면, UT를 준비하고 진행하는 것에 대한 허들을 완전히 부숴야겠다고 생각했고 AI를 활용해 보기로 했어요. 토스 사용자처럼 학습된 AI 봇이 있다면 사용자를 만나지 않고도 채팅으로 대화하며 제품의 사용성을 빠르게 점검할 수 있겠다고 생각했거든요. AI 봇을 만드는 것 외에도 UT 질문지를 템플릿화한다든지, 무물보다 훨씬 가벼운 프로그램을 기획한다든지 여러 가지 액션 아이템들이 떠올랐지만, 그 중 가장 임팩트 있고 빠르게 실험해 볼 수 있는 아이템으로 AI 봇을 선정했어요.

봇으로 달성하고자 하는 목표가 뚜렷해지니 봇이 해줘야 하는 역할을 쉽게 구체화하고 좁혀나갈 수 있었어요. 휴리봇의 목표는 ‘디자이너가 가볍게 훨씬 자주 사용성을 점검하게 되는 것’이에요. 그러려면 이 봇이 실제로 디자이너분들이 자주 만나는 사용자가 되어야겠죠. 그래서 디자이너분들이 자주 인터뷰하시는 사용자 그룹의 특성을 파악하고, 봇이 최대한 그 사용자를 닮게 만들어야겠다고 생각했어요. 예를 들면 전체 디자이너분들이 쓰시는 게 목적이니까 특정 제품에만 적용되는 10대 사용자보다는, 20~40대 사용자를 선택하는 게 맞는 거죠.

그다음에는, 디자이너분들이 UT에서 주로 어떤 질문을 하는지 살펴봤어요. 제품마다 여러 가지 질문이 있긴 했지만, 인터뷰마다 공통으로 하시는 질문들이 있더라고요. 예를 들면 “이 화면이 어떻게 이해되는지 설명해 주세요.” “이 버튼을 누르면 다음 화면에 뭐가 나올 것 같으세요?” 같은 질문들은 제품 종류와 상관없이 공통적으로 하는 질문이에요. 이 질문들을 봇에게 물어봐서 답변을 받을 수 있다면, 실제 사용자를 만났을 때는 이 질문을 생략하고 그 시간에 더 상세한 질문을 할 수 있게 되겠죠.

이렇게 봇으로 해결하고자 하는 문제와 봇이 해줘야 하는 역할, 기능에 대해 명확하게 정의해야 프롬프팅을 더 효율적으로 빠르게 할 수 있어요. 뚜렷한 목적 없이 막연히 ‘이것도 되고, 저것도 되는 봇’을 만들다 보면 프롬프팅은 더욱 복잡하고 어려워지거든요.

공감대 형성하기

팀원들이 잘 사용하는 AI 제품을 만들기 위해서는 문제와 목표에 대한 공감대를 형성하는 것이 매우 중요해요. AI를 도입하려는 이유가 명확하지 않거나 팀원들이 그 필요성을 느끼지 못한다면, 제품은 제대로 활용되지 않을 가능성이 크거든요.

휴리봇이 해결하려는 문제인 ‘UT의 확장’은 팀원들 모두가 공감하는 부분이었지만, 이를 해결하는 데 AI가 반드시 필요하냐는 점에 대해서는 일부 팀원분들의 우려가 있었어요. 토스에서 실제 업무에 AI를 많이 활용하고 있긴 하지만, AI는 사용자의 의견을 대체할 수 없으며 AI가 생성한 답변을 실제 사용자의 의견이나 검증된 답변으로 착각하는 것이 위험할 수 있다는 의견이었죠. 이는 AI 제품 도입에 있어 흔히 제기될 수 있는 우려이고 충분히 공감되는 부분이긴 했지만, 이러한 우려가 AI의 역할을 지나치게 제한하거나 가두는 이유가 되어서는 안 된다고 생각했어요. AI가 할 수 있는 것과 없는 것을 나누는 것보다는 AI를 우리가 ‘어떻게 활용하는지’가 더 중요하다고 생각했거든요.

그래서 저는 휴리봇의 역할은 사용자를 대상으로 하는 UT와는 명확히 다름을 설명해 드렸어요. 사용자분들을 통해서는 사용성을 ‘검증’할 수 있으나, 봇으로 할 수 있는 것은 검증의 영역 아닌 ‘점검’임을요. 사실 실제 사용자의 의견이라고 하더라도 결국 그것을 반영하는지는 디자이너의 판단이거든요. AI가 하는 말도 납득이 가능하다면 반영하는 것이고, 그게 아니라면 디자이너의 판단으로 반영하지 않을 수도 있다고 생각했어요.

이런 봇의 역할에 대해 명확히 알렸고, 제품 관점에서도 우려되는 부분을 방지할 수 있는 장치들을 고려했어요. 그 이후에도 실제 휴리봇의 결과값들을 공유해 드리며 긍정적인 기대감을 가질 수 있도록 했어요.

02) 프롬프팅 중

(프롬프트 엔지니어링 팁은 다음 아티클을 통해 공유 드릴게요.)

초기 제품으로 가치 검증하기

프롬프트 엔지니어링을 하다 보면 ‘완벽한 프롬프트’를 짜는 것에 매몰되어, 너무 많은 시간을 쏟게 될 수 있어요. 그래서 적정 시점에서 테스트를 멈추고, 실제 사용자의 의견을 들어보는 것이 중요해요. 사용자 피드백은 프롬프트를 개선하는 데에 있어 필수적이고, 이를 통해 AI 제품으로 주고자 했던 가치를 효과적으로 검증해 볼 수 있어요.

휴리에게 실제 사용자를 대상으로 진행한 UT와 똑같은 질문을 했을 때 사용자와 거의 흡사한 답변을 하던 시점에, 제 고객인 디자이너분들을 대상으로 테스트를 했어요. 중요한 건 너무 많은 개발 리소스를 쓰지 않고 저렴하게 검증해 보는 것이었기 때문에, 개발이 전혀 필요하지 않지만 커스텀이 가능한 챗봇을 활용했어요.

테스트 방식은 간단했어요. 디자이너 본인이 작업 중인 화면 이미지를 넣고 해당 화면에 대해 UT를 하게 했고, 휴리봇이 해주는 답변이 실제 사용자와 유사하다고 생각하는지, 적절한 피드백이라고 여겨지는지 다양한 의견을 수집했어요. 그리고 이때 얻은 피드백을 기반으로 프롬프트를 수정하며 개선해 나갔어요.

이 테스트 과정을 통해 휴리봇의 두 가지 가치를 검증 할 수 있었고, ‘휴리스틱 이슈를 빠르고 쉽게 확인할 수 있다’는 의미로 ‘휴리’라고 이름 짓게 되었어요.

1. 효율적인 사용성 점검 : 최소한의 리소스로 빠르게 사용성을 점검할 수 있는 점이 디자이너분들의 업무 효율성을 높여 매우 큰 가치인 것을 파악했어요. 이 제품을 통해 주고 싶던 핵심가치가 검증된 것이죠.
2. 제3자의 시각 제공 : 디자이너는 종종 작업 중인 디자인 화면에 매몰되어 객관성을 놓치기 쉬운데요. 휴리봇을 통해 제 3자의 시각으로 의견을 줌으로써 본인의 디자인을 메타적으로 바라보고, 환기할 수 있는 장치의 역할을 하는 것 또한 알 수 있었어요.

이렇게 챗봇을 활용해서 휴리봇으로 제공하고자 하는 가치는 검증이 되었지만, 챗봇 특성상 접근성과 사용성에 있어서 한계가 있었어요. 챗봇은 디자이너의 작업 워크플로에 없는 단계이기 때문에 접근성이 떨어졌고, 그렇다 보니 자주 사용하지 않게 되는 문제가 발생했어요. 또한 다른 사람의 대화 이력을 확인할 수 없기에 제가 봇을 좀 더 디벨롭하거나 관리하는 것도 어려웠고요. 이러한 문제 해결과 제품 확장을 위해 내재화를 결정하게 되었어요.

03) 프롬프팅 후

워크플로에 넣기 위한 스펙 아웃

진짜 ‘쓰기 위한 제품’을 만들기 위해서는 어떤 기능이 꼭 필요한지, 필요하지 않은지 정의해야 해요. 챗봇으로 휴리봇의 가치를 검증한 후 제품 확장을 위한 내재화 작업 중 MVP 제품을 만들기 위해 가장 먼저 했던 작업은 기능 우선순위를 정의하는 일이었어요. 휴리봇의 제품의 핵심 가치는 무엇이고, 이 가치를 전달하기 위한 최소한의 기능은 무엇일지 판단하는 과정이 있었죠. MVP란? 최소 기능 제품(Minimum Viable Product), 구현하고자 하는 제품의 핵심적인 가치를 골라 최소한의 기능만을 담아낸 제품

휴리봇 프로젝트의 목적은 ‘완벽한 봇을 만드는 것’이 아닌 ‘디자이너가 가볍게 자주 사용성 점검을 하게 하는 것’이에요. 봇을 만드는 것은 목적을 달성하기 위한 방법의 하나인 것이고요. 그렇기 때문에 완벽한 봇을 만들기 위해 불필요한 기능을 이것저것 넣는 실수를 하지 않도록 유의했어요.

휴리봇의 핵심 가치는 채팅을 통한 쉽고 빠른 사용성 점검이니 채팅 화면이 필수적이에요. (1) 화면 이미지를 넣고 (2) 질문하면 (3) 답변을 주는 기능이 꼭 필요하고, 그밖에 대화 목록을 다시 보는 등의 기능은 있으면 좋은 정도지 MVP에 들어가야 하는 필수 기능은 아니라고 판단해서 스펙에서 제외했어요.

그렇게 만들어진 휴리봇을 디자이너분들은 이렇게 사용하고 있어요.

휴리봇으로 빠르게 점검하기

시안 아이데이션 과정에서 빠르게 휴리봇을 돌려보고, 휴리봇의 의견이 공감될 경우 이을 바탕으로 개선 하기도 해요. UT를 위한 프로토타입을 준비할 필요도, 시간을 낼 필요도 없이 언제든 할 수 있기 때문에 디자이너가 혼자 고민하는 시간을 줄이고 사용자에게는 보다 더 중요한 검증을 할 수 있게 된거죠.

적용해보기

AI제품은 프롬프팅만으로는 성공할 수 없어요. 혹시 여러분도 AI를 실무에 도입하지 못해 걱정이라면, 혹시 프롬프트를 잘 짜기 위한 방법만 고민하고 있었던 건 아닌지 생각해 보세요. 그리고 프롬프팅 전/ 중/ 후로 나누어서 어떤 것을 놓치고 있었는지 체크해보시는 걸 추천해 드려요.

이렇게 만들어진 휴리봇의 프롬프트가 궁금하신가요? 다음 시간에는 휴리봇을 만들면서 얻게 된 ‘사람처럼 말하는 AI 프롬프팅 팁’에 대해 알려드릴게요!