Building Workflow: 모든 일에는 흐름이 있다는 것을

얼마 전 기획부터 프로토타이핑, 개발을 주도했던 기능을 배포했다. Quick Search라는, Mac의 Spotlight 같은 기능을 백엔드 도움 없이 만들었다. 남는 시간에 틈틈이 해서 배포까지 한 달이 조금 안 걸린 것 같다.

처음에는 단순히 ‘있으면 멋질 것 같다’라며 시작했지만 만드는 과정에서 고민하고 배운 점들이 있다. 짧게는 제품의 문서나 자료와의 접근성이나 필요한 기능부터, 더 나아가면 좋은 SaaS Tool이 되기 위해서는 무엇이 필요할지. 간단하게 작업을 되돌아보며 정리해보려고 한다.

_{Quick Search Demonstration}

지금 만드는 Airbridge의 대시보드에는 리포트부터 서드파티 연동, 복잡한 설정까지, 50개가 넘는 크고 작은 기능들이 있다. 제품이 커지다보니 원하는 기능이 메뉴의 어디에 있었는지 가물가물해지기 시작했다. 매 번 메뉴에 커서를 올려보는 그 짧은 시간도 아까웠다.

하지만 메뉴의 UX를 고치는 일은 천지를 개벽할 일. 혼자서 할 수 없기에 고민을 하다 문득 이전에 본 글이 생각났다. 학생들이 ‘검색’에 익숙해진 나머지 ‘폴더’라는 개념을 어려워해 교수들이 힘들어한다는 내용이었다.

검색은 정보와 사용자 간의 거리와 계층을 줄여준다. 폴더 깊이 숨은 자료도 모두 꺼내어 하나의 선상에 놓아버리기 때문이다. 자료가 많을 수록 검색은 진가를 발휘한다. 지금의 문제를 검색이 해결해줄 수 있지 않을까?

대시보드에 Spotlight, Raycast, Command E 같은 것을 넣으면 어떨까. 새로운 UX가 들어갈 공간은 충분해 보였고, 개발 역시 간단해 보였으며, 무엇보다 있으면 멋있을 것 같았다. 무작정 Figma를 열어 스케치를 시작했다.

Spotlight의 주요 기능을 꼽으라면 검색(내부/외부 리소스), 단축어(빠른 실행), 유틸리티 기능(계산기 등)이 있다. 이 중 유틸리티는 구현하지 않으므로 제외하고, 단축어 기능과 외부 리소스의 검색을 만드는 데 고민할 것이 많았다.

먼저 단축어의 경우, 무엇을 쉽게 만들어줄 것인지 고민했다. 사용자들이 반복하는 작업을 알 필요가 있었다. Airbridge는 Amplitude와 LogRocket으로 사용성을 측정하는데, PV와 Operation 빈도를 기준으로 5개 정도를 추려 구현했다. 단축어는 ‘입력량을 줄이면서 기능과의 거리를 좁힐 수 있는 것’이면서 ‘빠르게 구현 가능한 것’을 우선으로 선택했다. 아래는 그 예시이다.

입력한 채널이 채워진 상태로 트래킹링크 생성 페이지로 이동
Raw Data Export의 데이터 추출 화면을 바로 열어줌
초대할 사용자의 이메일을 입력하면 바로 초대할 수 있음

_{팀원분들께서 수집해주시는 사용성 데이터 예시}

다음으로 검색, 특히 외부 리소스의 검색이다. Airbridge의 이용가이드, 개발자 가이드 등 여러 가이드들을 연동해 검색하면 좋을 것 같았다.

대시보드 내에 사용법이나 응용법, 주의사항 등을 모두 담을 수는 없으며, 애초에 그래서는 안 된다. 화면을 가득 채운 Tooltip과 Callout들을 보면 사용자들이 겁부터 먹지 않을까?

그래서 보통 서비스와 가이드는 분리되어 운영되는데, 이로 인해 둘의 연결성이 떨어지게 된다. 연결성이 떨어지면 사용자들이 제품을 쓰며 스스로 문제를 해결하거나 필요한 정보를 얻을 수 없음을 말한다.

다행히 각 가이드는 Algolia를 사용하고 있었기에 간단하게 이를 묶는 Edge Function을 만들어 쉽게 검색을 구현했다. 또한 조언을 받아 대시보드 → 가이드로 이동할 때 입력한 검색어를 담아 보내도록 했다. 이를 통해 무엇을 많이 검색하고 보는지 측정하여 가이드를 개선할 수 있을 것이다.

Quick Search를 모두 만들고 나니 뜻하지 않게 얻은 것들이 있었다. 대표적으로 기능 간 연속성을 구현하기 쉬워졌다.

단축어를 구현하며 URL 내에 정보를 담아 전달할 수 있는 간단한 인터페이스를 구현했는데, 이를 다른 곳에도 쉽게 적용할 수 있을 것 같다. 예를 들어, 데이터 구조가 비슷하다면, 리포트를 보다가 문제가 되는 부분의 원본 데이터를 바로 추출하는 기능을 쉽게 구현할 수 있게 되었다.

또한 가이드 검색을 위해 만든 Edge Function은 슬랙봇 등을 만드는 데에 사용할 수 있다. Attribution과 관련된 도메인 지식은 정말 많고 복잡하다. 도메인 지식이 어려울수록 지식을 검색하는 도구는 빛을 발한다.

돌아보면 사용자들은 커뮤니케이션 비용을 낮춰주거나(ex. 리포트 설정 복사 및 공유), 귀찮은데 반복이 잦은 일을 자동화해주었을 때(ex. Google Sheet에서 트래킹링크 대량 생성), Airbridge를 쓰면서 좋아했던 것 같다.

제품의 엣지(Edge)라고 해야 하나... 일의 흐름(Workflow)라고 해야 하나...

이번 작업을 하며 마치 누군가의 흐름에 같이 올라타 흘러가는 느낌이 들었다. 모든 일에는 하나의 흐름이 있고, 그 안의 걸리적거리는 부분을 찾아 고치는 것이, 나의 일이자 제품의 경쟁력이라고 생각했다.

동시에 각자가 ‘나만의 일의 흐름’을 만들 수 있도록 도와주고 싶다고 생각했다. 많은 SaaS 들은 정보를 본인의 제품 안에서만 흐르게끔 벽을 치곤 한다.

하지만 현실의 일은 제품의 바깥에서 일어난다. 흐름의 바탕은 우리의 제품이되, 이득을 보거나 쓰는 곳까지 제품 안으로 가둘 필요는 없다. 오히려 정보가 흐를 수 있도록 판을 열어주는 것이 더욱 중요하지 않을까?

당연한 정보도 모아서 사용자들이 쉽게 닿을 수 있는 곳에 두고. API를 열어주고. 연동을 추가하고. 플러그인을 만들고 공유할 수 있도록 해주고. 정 애매하다면 Zap이라도 제공해야 한다. 이러한 것이 없는 제품을 SaaS라고 부를 수 있을까. 나는 조금 힘들지 않을까 생각했다.

같은 맥락에서 Airbridge도 아직 갈 길이 멀다. 그래도 이런 지점들이 재밌어서 B2B SaaS를 만드는 일을 계속하는 것 같다.

B2B SaaS를 만드는 곳에 들어온 것은 우연이 맞다. 하지만 이곳에 계속 있는 것은 나의 선택이다. 일의 흐름을 만드는 파도를 만들어보고 싶다는 생각 하나로... 아니었으면 말고.