사용자 피드백으로 바뀐 기능 3가지 (Before & After)

사용자 피드백으로 실제 기능이 바뀐 세 가지 사례를 Before와 After로 정리합니다. 지난 글에서 무료 공개의 이유 중 하나로 무료 사용자가 도구를 완성시킨다는 이야기를 했는데, 이번 글은 그 말의 증거입니다. Keyword Cockpit을 공개한 뒤 받은 의견 중에서 코드 수정까지 이어진 것만 골랐습니다. 개발자 혼자서는 절대 발견하지 못했을 문제들이었기에, 비슷한 도구나 서비스를 만드는 분들에게도 참고가 되리라 생각합니다. 세 사례 모두 코드보다 관점을 고친 쪽에 가까웠습니다.

사용자 피드백이 드러낸 첫 번째 문제, 무반응 화면

Before, 1~2초의 침묵이 고장으로 읽혔다

초기 버전은 키워드를 입력하고 검색 버튼을 누르면, 결과가 나올 때까지 화면에 아무 변화가 없었습니다. 개발자인 저는 내부적으로 데이터를 가져오는 중이라는 걸 알고 있으니 1초에서 2초의 침묵이 전혀 이상하지 않았습니다. 그런데 사용자 피드백 하나가 이 당연함을 깨뜨렸습니다. 버튼을 눌렀는데 반응이 없어서 고장 난 줄 알고 세 번 연속 눌렀다는 의견이었습니다. 확인해 보니 실제로 같은 키워드가 짧은 간격으로 중복 조회된 기록이 여럿 있었습니다. 사용자 입장에서 무반응은 처리 중이 아니라 고장으로 읽힌다는 것을 그때 알았습니다. 같은 사용자 피드백이 두 번째로 들어왔을 때는 더 미룰 수 없다고 판단했습니다. 인터랙션 설계에서 1초가 넘어가면 사용자가 지연을 인지하기 시작한다는 원칙이 정확히 우리 도구에서 재현된 셈입니다.

After, 도구가 지금 무엇을 하는지 말하게 했다

검색 버튼을 누르는 즉시 로딩 상태를 표시하고, 하단 상태 바에 준비 완료나 조회 중 같은 현재 상태 문구를 항상 노출하도록 바꿨습니다. 기능이 추가된 것은 아무것도 없습니다. 그저 도구가 지금 무엇을 하고 있는지 말해주게 했을 뿐인데, 중복 조회가 눈에 띄게 줄었고 느리다는 의견도 함께 줄었습니다. 체감 속도는 실제 속도만큼이나 소통의 문제였던 것입니다. 조회가 끝난 뒤에도 총 몇 개의 데이터를 가져왔는지 상태 바에 남겨두어, 결과가 제대로 나왔다는 확인까지 한 화면에서 되게 했습니다.

운영비까지 함께 줄어든 개선

이 개선은 비용 측면에서도 의미가 있었습니다. 고장인 줄 알고 반복해서 누르던 중복 조회가 줄어들면서, 같은 데이터를 불필요하게 다시 가져오는 요청도 함께 사라졌기 때문입니다. 무료로 운영하는 도구 입장에서 서버 자원과 데이터 처리량은 곧 운영비입니다. 사용자 경험을 고친 것뿐인데 운영 비용까지 아껴지는, 일석이조의 개선이었던 셈입니다. 작은 사용자 피드백 하나가 사용성과 운영비를 동시에 개선한 첫 사례였습니다.

사용자 피드백으로 다시 짠 결과 화면과 검색 기록

Before, 확보한 지표를 전부 나열했다

초기 결과 화면은 월간 검색량, 클릭수, 클릭률, 경쟁 정도까지 확보한 지표를 전부 테이블에 나열했습니다. 데이터를 많이 보여줄수록 좋은 도구라고 믿었기 때문입니다. 하지만 블로그 초보자들의 사용자 피드백은 정반대였습니다. 숫자가 많은데 뭘 보고 판단해야 할지 모르겠다는 의견이 반복해서 들어왔습니다. 돌이켜 보면 도구 설계 글에서 직관성을 그렇게 강조해 놓고, 정작 결과 화면에서는 그 원칙을 지키지 못하고 있었던 셈입니다.

After, 정보를 줄인 게 아니라 순서를 정했다

기본 화면에는 판단에 꼭 필요한 핵심 지표만 남기고, 나머지 상세 지표는 원하는 사람만 펼쳐 보는 구조로 바꿨습니다. 정보를 줄인 것이 아니라 정보의 순서를 정해준 것에 가깝습니다. 변경 후 이제 뭘 봐야 할지 알겠다는 반응이 돌아왔고, 첫 조회에서 이탈하는 비율도 낮아졌습니다. 처음에는 지표를 숨기면 왜 정보를 줄였냐는 항의가 나올까 걱정했지만, 실제로는 정반대였습니다. 상세 지표를 펼쳐 보는 사용자는 소수였고, 대부분은 핵심 지표만으로 판단을 끝냈습니다. 걱정했던 불만은 한 건도 들어오지 않았습니다. 많이 보여주는 것과 잘 보여주는 것은 다른 일이라는 걸 이때 배웠습니다.

Before, 있는 줄도 몰랐던 재조회 수요

초기 버전에는 검색 기록이라는 개념 자체가 없었습니다. 조회는 그때그때 하고 끝나는 일회성 동작이라고 생각했기 때문입니다. 그런데 여러 사용자 피드백에서 공통된 패턴이 발견되었습니다. 어제 조회한 키워드를 다시 보고 싶은데 또 입력해야 하느냐는 것이었습니다. 키워드 분석은 한 번으로 끝나는 작업이 아니라, 글감을 고민하는 며칠 동안 같은 키워드를 반복해서 들여다보는 작업이었습니다. 만든 사람은 도구를 쓰는 순간만 보지만, 쓰는 사람은 도구를 쓰는 기간을 산다는 차이였습니다.

After, 최근 검색과 전체 삭제를 함께 넣었다

최근 검색 기능을 추가해 조회했던 키워드를 클릭 한 번으로 다시 불러올 수 있게 했습니다. 전체 삭제 버튼도 함께 두어 기록을 원치 않는 사용자의 선택권도 남겼습니다. 작은 기능이지만 재방문 사용자들의 체류 흐름이 눈에 띄게 자연스러워졌습니다. 최근 검색 항목은 개별 삭제도 되도록 해서, 지우고 싶은 키워드만 골라낼 수 있게 했습니다. 기록을 남기는 기능일수록 지우는 방법을 같이 주는 것이 원칙이라고 판단했습니다. 공용 컴퓨터에서 쓰는 분도 있을 테니, 삭제 버튼이 한 번에 보이는 자리에 있어야 한다고 봤습니다.

세 가지 변화가 알려준 것

기술 문제가 아니라 관점 문제였다

돌아보면 세 사례 모두 기술 문제가 아니라 관점 문제였습니다. 개발자는 도구의 내부를 알기 때문에 오히려 사용자의 눈으로 볼 수 없습니다. 침묵이 고장으로 읽히는 것도, 많은 정보가 부담으로 읽히는 것도, 반복 조회 수요가 있다는 것도 전부 사용자 피드백이 아니었다면 지금도 몰랐을 것들입니다. 무료 공개가 도구를 성장시킨다는 지난 글의 주장은, 적어도 이 도구에서는 이렇게 사실로 확인되었습니다. 만든 사람이 볼 수 없는 자리를 대신 봐준 것이 결국 사용자였습니다.

의견을 분류해 관리하는 단순한 규칙

그래서 지금은 사용자 피드백을 받는 방식 자체도 하나의 기능처럼 관리하고 있습니다. 의견이 들어오면 버그와 개선 요청, 새 기능 제안 세 가지로 분류해 기록하고, 같은 의견이 두 번 이상 반복되면 우선순위를 올리는 단순한 규칙을 씁니다. 화려한 관리 도구는 없지만, 이 단순한 분류만으로도 무엇을 먼저 고쳐야 할지가 명확해집니다. 피드백은 모으는 것보다 버리지 않는 것이 중요하다는 게 지금까지의 결론입니다. 당장 반영하지 못하는 의견도 기록해 두면 나중에 같은 이야기가 다시 들어왔을 때 판단이 빨라집니다.

자주 묻는 질문

사용자 피드백은 어떻게 받고 있나요?

문의 페이지로 들어온 의견을 버그와 개선 요청, 새 기능 제안 세 가지로 분류해 기록합니다. 별도의 관리 도구 없이 분류만 해도 우선순위가 정리됩니다.

의견이 서로 충돌하면 무엇을 기준으로 정하나요?

같은 의견이 두 번 이상 반복되는지를 봅니다. 한 번뿐인 의견은 기록만 해두고, 반복되는 의견부터 우선순위를 올려 처리합니다.

기능을 줄이면 항의가 들어오지 않나요?

지표를 기본 화면에서 접었을 때 걱정했지만 불만은 한 건도 없었습니다. 숨긴 게 아니라 펼쳐 볼 수 있게 두면, 대부분은 핵심 지표만으로 판단을 끝냅니다.

무반응 화면은 왜 문제가 되나요?

사용자는 처리 중이라는 사실을 알 수 없어서 고장으로 읽습니다. 실제로 중복 조회가 늘어 서버 요청까지 함께 증가했고, 상태 표시를 넣자 양쪽 모두 줄었습니다.

직접 만든 네이버 키워드 검색량 조회 도구 Keyword Cockpit은 회원가입 없이 무료로 사용할 수 있습니다. 다음 글에서는 이렇게 도구를 다듬어 온 과정을 포함해, 1인 개발로 웹 도구를 운영하며 배운 것들을 정리해 보겠습니다.