오늘은 저희 KPI에 대한 문제와 이에 따른 문제를 해결하기 위해 면접 인터페이스에 대해서 어떻게 접근하고 해결했는지에 대한 글을 적어보려 합니다.
문제
저희의 KPI는 ‘인당 면접수’를 가장 최우선적으로 생각하고 이를 개선하기 위해 다양한 노력을 하고 있습니다. 하지만 최근들어 인당 면접 수는 1.5개밖에 되지 않았습니다. 사용자 분들이 가입한 후 한 번 인터뷰를 체험하고 이후에는 제대로 완료하지 않았다는 의미로도 해석할 수 있었습니다.
저희는 이 문제에 대해 심각성을 느꼈습니다. 한 번 하고 그 이상을 안한다는 의미는 결국 서비스를 체험만 해보고 갈 정도로 매력도가 떨어지거나 불편한 부분이 있다는 의미기도 하니까요. 더불어 저희가 느끼는 문제점이 사용자가 가지는 문제점과 같지 않다는 문제 또한 발견했습니다. 개발자가 보는 시선과 사용자가 보는 시선은 확실히 다를 수밖에 없는 것 같습니다.
원인 찾기
이에 저희는 문제를 두 가지로 분류하고 이를 발견할 수 있도록
- 서비스에서 가졌던 불편한 점을 발견하기 - 유저 인터뷰를 통해 문제점을 발견하고 개선하기
- 면접 내부의 UX 개선하기 - 히트맵, 세션 리플레이를 통해 인터페이스 불편사항 개선 두 가지의 접근 방식을 택했습니다.
서비스에서 가졌던 불편한 점을 발견하기 - 유저 인터뷰를 통해 문제점을 발견하고 개선하기
저희 서비스는 MVP부터 시작하여 꾸준히 사용해주시는 고마운 사용자 분들도 계시고 주기적으로 들어와서 면접을 진행해주신 분들도 계셨습니다. 이에 상대적으로 오랫동안 서비스를 이용해준 사용자 분들께 직접 연락을 드려 양해를 구하고, 사용자분들 당 30분정도의 유저 인터뷰를 진행했습니다.
해당 유저 인터뷰와 저희 피드백 오픈채팅으로 온 피드백들 중 가장 많은 의견을 차지했던 것은 ‘면접 질문이 랜덤이다’라는 점이었습니다. 사용자에게 선택권이 없는 면접 서비스는 예상치 못한 문제나 굳이 싶은 문제를 만날 확률이 크고, 이에 따라 중간에 면접을 완료하지 않고 이탈한 사용자분들 또한 많았습니다.
면접 내부의 UX 개선하기 - 히트맵, 세션 리플레이를 통해 인터페이스 불편사항 개선
저희 서비스에는 모니터링 도구인 Posthog가 사용자의 행동을 모니터링 하고 있습니다.
간단한 DAU, MAU 뿐만 아니라 각 사용자의 이벤트를 화면에 출력해주는 Session Replay와 사용자가 많은 이벤트를 발생시켜 준 곳을 시각화 해주는 Hitmap 기능을 제공합니다.
Session Replay의 경우 사용자가 해당 서비스를 이용하는 과정에 있어서 처음부터 끝까지 이벤트가 일어나는 때를 MutationObserver를 통해서 검출하며, 이를 통해 해당 프레임의 스냅샷을 찍어 이벤트를 추적할 수 있게 해줍니다.
위와 같이 Hitmap의 경우에는 사용자가 클릭과 같은 특정 행동에 대해서 어느 부분이 많이 클릭되었는지를 위치에 기반하여 시각화해줍니다.
저희는 해당 기능을 기반으로 세션 리플레이들을 보면서 사용자가 어느 부분에서 불편함을 느끼는지를 파악하려 노력했습니다.
해당 모니터링들을 통해서는 크게 두 가지 개선사항을 발견할 수 있었습니다.
- 꼬리 질문의 생성 시간이 너무 길다 - 사용자가 꼬리 질문 생성 시간동안 마우스를 흔드는 등 불편함을 느낄 때의 행동을 발견
- 질문을 직접 버튼을 눌러 제출해야 한다. - 히트맵 내에서 제출 버튼을 클릭하는 비율이 높음
가설 설정
위를 통해 발견한 문제는 세 가지가 있습니다.
- 시작 면접 질문을 선택할 수 없다.
- 꼬리 질문의 생성 시간이 너무 길다
- 답변을 작성 후 직접 버튼을 눌러 제출해야 한다.
이를 통해 저희는 이
세 가지를 개선하게 된다면, 자연스럽게 핵심 KPI가 상승할 것이다라는 가설 설정을 하였고, 이에 따라 각각 문제에 대한 해결 방법을 도출해내었습니다.
| 문제 | 개선 후 |
|---|---|
| 시작 면접 질문을 선택할 수 없다 | 면접 질문을 직접 선택할 수 있는 기능을 추가한다 |
| 꼬리 질문의 생성 시간이 너무 길다 | 프롬프트 엔지니어링과 병렬 요청을 통한 꼬리질문 생성 시간 개선 |
| 질문을 직접 버튼을 눌러 제출해야 한다 | enter 버튼을 통한 답변 제출 |
개선하기
이렇게 문제에 대한 해결 방법을 도출해낸 뒤, 각각 개선 작업을 진행했습니다.
면접 질문을 직접 선택할 수 있는 기능 추가
각 인터뷰 객체의 경우에는 root_question의 id를 참조하는 컬럼이 있었습니다. 그렇기 때문에 루트 질문에 대한 id를 넘겨주면 해당 Id를 기반으로 새로운 인터뷰 객체를 생성할 수 있도록 새로운 POST API를 개발하였고, 루트 질문에 대해서도 질문을 볼 수 있도록 GET API를 만들어 준 뒤 빠르게 기능에 추가하였습니다.
프롬프트 엔지니어링과 병렬 요청을 통한 꼬리질문 생성 시간 개선
원래의 꼬리 질문 생성 로직은 AI에게 프롬프트 엔지니어링을 통해 저희가 필요한 데이터를 json 형태로 모두 출력하여 바로 파싱해서 사용할 수 있도록 하였습니다. 하지만 해당 방법은 가끔씩 AI가 파싱이 안되는 자료구조를 출력할 때도 있었으며, 무엇보다 평균적으로 20초 이상이 소모되었습니다.
이에 저희는 각각 필요한 AI 출력에 대해서 하나의 출력에 의존하는 것이 아닌, 각각의 객체에 필요한 필드값들을 병렬적으로 프롬프트 요청을 진행하고, 해당 출력에 대해서 Lambda로 조합하여 output으로 리턴하게 하였습니다.
// 개선 전
{
A : ""
B : ""
C : ""
} 로 만들어줘!
-> output
// 개선 후
A에 대해서 만들어줘!
B에 대해서 만들어줘!
C에 대해서 만들어줘!
-> Lambda -> output이러한 과정을 통해서 각각의 프롬프트는 output을 만들어 내는 절대적인 토큰의 양이 줄고, 병렬적인 요청으로 시간은 prompt(A + B + C) 에서 max(prompt(A),prompt(B),prompt(C)) 로 개선하여 평균 20초 이상이 걸리던 꼬리 질문 생성을 평균 5초 이하로 4배 이상 개선할 수 있었습니다.
enter 버튼을 통한 답변 제출
해당 UX 개선사항은 어찌보면 사소할 수 있지만 중요한 역할을 합니다. AI 서비스는 대부분 대화형으로 이루어져 있기 때문에 Enter를 통해 프롬프트를 하는 것이 사용자에겐 익숙합니다. 하지만 저희는 이러한 점을 간과하고 있었습니다.
따라서 저희는 면접 질문 form에 대해서 shift+enter를 통한 줄바꿈, enter를 통한 제출 기능을 추가했습니다.
결과
이러한 개선 작업이 이루어진 후 약 1주일이 지난 후에 KPI를 다시금 측정했습니다. 그 결과 KPI는 약 1.5회에서 2회정도로 약 30%를 개선할 수 있었습니다. 또한 기존에 인터뷰를 요청드렸던 사용자 분들께 다시금 개선 사항을 알려드렸더니 직접 다시금 체험해보시고 훨씬 서비스가 좋아졌다는 긍정적인 피드백을 받을 수 있었습니다.
해당 KPI를 개선하기 위해 작업을 하면서 가장 크게 느꼈던 점은 개발자와 사용자의 시선이 다르다는 점입니다. 개발자가 불편하게 느껴 우선순위가 크게 느껴졌던 부분들도 사용자에게는 사소한 것이 될 수 있으며, 정작 더 큰 문제가 있을 수도 있다는 점을 깨달았습니다. 결국 서비스는 사용자를 위한 것이기 때문에 개발자가 서비스를 개선하기 위해서는 사용자의 불편함을 우선순위화하여 이를 제대로 개선해야 함을 알게 되었습니다.