토스 디자인 콘퍼런스 Simplicity21 이 열렸다. UX라이팅 세션에서 소개한 보이스톤을 자동으로 검수해주는 툴, 보이스톤 메이커를 만들게 된 배경을 좀 더 자세하게 이야기해보려고 한다.
토스는 디자인 툴로 프레이머를 쓴다. 덕분에 여러 확장 프로그램들을 만들 수 있었는데, 그 중 하나가 보이스톤 메이커다. 프레이머에서 디자인을 하면, 토스의 보이스톤과 다른 문구를 썼을 때 틀린 단어를 표시해주고 교정할 단어를 추천해준다.
보이스톤 메이커는 토스의 라이팅 가이드라인을 시스템화한 것으로, 8,000개가 넘는 룰이 적용되어있다. 제품의 라이팅을 개선하기 위해, 토스 역시 처음에는 가이드라인을 만드는 것으로 시작했다. 궁극적으로 이 가이드라인을 모든 팀원이 학습하고 조직 자체가 라이팅에 강해지도록 만드는 것이 목표였다.
다양한 시도를 했으나 가이드라인을 완벽하게 학습하는 것은 예상보다 훨씬 어려운 일이었고, 또 신규 입사자가 들어올 때마다 매번 같은 과정을 반복해야 하는 것이 매우 비효율적으로 느껴졌다.
그래서, 토스 팀은 가이드라인이 아닌 시스템을 만들기로 했다. 즉, 규칙을 하나하나 학습하지 않고 자동으로 적용할 수 있는 방향으로 말이다.
다른 글(앱 안의 텍스트를 다룬다는 것)에서 쓴 적 있는데, 내 기준 UX라이팅의 가장 도드라진 특징은 '함께 쓴다'는 점이다. 이것은 내가 토스에 첫 UX라이터로 합류하면서 가장 먼저 깨달은 점이다.
솔직히 말해서, 나는 토스에 합류하기 전 토스가 라이팅 관련 자료를 전혀 공유한 바 없기에 딱히 기반이랄 게 없을 것이라 생각했다. '타사 사례를 조금씩 참고해서 그럴듯한 가이드라인부터 만들면 되겠군'그것만으로도 충분한 인사이트가 될 거라 생각했다. 하지만 그 생각이 안일한 착각이었다는 걸 깨닫는 데에는 단 1주일도 걸리지 않았다. (...^^)
토스 프로덕트 디자이너들은 이미 라이팅 실력이 수준급이었고, 라이팅의 중요성에 대해서도 공감대가 강하게 형성되어있는 상태였다. 외부에 공개되지 않았을 뿐 내부에 라이팅 가이드라인이나 러닝을 기록한 문서도 여럿 있었다.
문제는 좋은 라이팅의 기준과 공감의 수준이 디자이너마다 달랐고, 그것을 통합하려는 시도가 산발적으로 이루어졌다는 점이다. 문서가 있긴 했지만 잘 전파되지 않았고, 좋은 라이팅 사례는 개인의 암묵지로만 존재했다. 이는 제품 전체의 일관성 부족이라는 결과로 드러나고 있었다.
실제로 프로덕트 디자이너분들을 찾아다니며 "지금 토스 UX라이팅에서 가장 시급하게 해결해야 할 문제는 무엇일까"에 대해 1:1 인터뷰를 진행했는데, 정말 놀랍게도 모두에게서 공통적으로 '일관성'이라는 답변을 얻었다.
즉, 그때의 토스에 필요한 것은 새로운 인사이트가 아니라 이미 존재하는 인사이트를 정리하고 일관성을 부여하는 일이었다.
여기서 인사이트를 통합하는 것 외에 넘어야 할 산이 하나 더 있었는데, 보이스톤 메이커는 이 산을 넘기 위한 도구였다.
토스는 린하게 일하는 조직이다. 완벽한 준비보다는 빠른 출시를 통해 피드백을 덧대어가며 완벽한 제품을 만드는 것을 지향한다. 그래서 제품 기획부터 출시까지 굉장히 빠른 속도로 진행되는데, 이 과정에서 나오는 모든 텍스트를 라이터가 보는 것은 불가능하다.
QA 등을 통해서 라이팅 검수 후 제품 출시를 하는 방법도 있겠지만 토스의 속도와는 맞지 않는 방법이었으므로, 팀원들이 쓰는 텍스트가 처음부터 좋은 퀄리티로 생산되게 만드는 방법이 더 적합했다. 이런 이유로 라이터를 거치지 않고도 모든 팀원이 좋은 문장을 쓰는 것, 즉 조직 자체가 UX라이팅에 강해지는 것을 목표로 삼았다.
그러려면 라이터가 만든 가이드라인을 모든 팀원들이 학습해야 한다. 라이터의 뇌를 팀원들과 동기화하는 것이다. 하지만 콘퍼런스 영상에서도 말했듯, 가이드라인은 만드는 것도 어렵지만 그것이 적용되게 만드는 일은 훨씬 어렵다.
처음에는 라이터가 생각하는 사고 흐름 자체를 공유드리는 방법을 택했다. 라이팅 요청이 오면 개선안만 전달하는 게 아니라, 이 개선안을 도출하게 된 과정을 함께 전달하는 것이다. 또 좋은 문장이 왜 좋은 문장인지에 대해서도 최대한 설명해드리려고 했다.
이 방법을 거듭하며 한 번쯤이야 괜찮을 수 있지만, 모든 요청 업무를 매일 이렇게 처리하기에는 리소스 낭비라는 생각이 들었다.
조금 더 효율적인 방법을 찾기 위해, 라이터의 사고 흐름을 프로세스화 해서 그 방법을 전파하려고 했다. 라이터의 도움 없이도 좋은 문구를 쓸 수 있는 도구를 드린 것이다.
학습 비용이 높았음에도 팀원분들이 적극적으로 참여해주셨지만, 이 역시 라이팅 효율화라는 핑계로 학습이라는 노동의 짐을 팀원분들께 넘기는 방법이어서 베스트는 아니라는 생각이 들었다.
이전에는 요청받는 건을 개선하는 일만 했다면, 이번에는 먼저 디자인 시안에 접근해서 적극적으로 개선 제안을 해보기로 했다. '전체 사일로 워싱'이라는 이름으로, 디자인 화면을 돌면서 "여기 고쳐주세요"라는 코멘트를 다는 프로젝트를 진행했다. 규칙을 외우도록 강요하는 것보다는, 반복적으로 직접 개선해보면서 자연스럽게 학습하는 방법이다.
하지만... 이 역시 라이터가 하나의 문제에 하나의 댓글을 달아야 하는, 확장 불가능한 방식이라는 점에서 완벽하지는 않았다.
라이터가 하나하나 댓글을 다는 비효율 말고도 다른 문제도 있었다. 서문에서 말했듯 토스는 아주 빠르게 돌아가는 조직이어서, 하루에도 화면이 몇 번씩 바뀐다. 그런데 화면을 잡는 도중에 라이터가 문구를 고쳐달라고 댓글을 달면
"앗... 이거 아직 확정 디자인 아닌데 디자인 끝나면 공유드릴게요!" 하는 상황이 펼쳐졌다. 그럼 라이터는 확정된 디자인이 나올 때까지 기다렸다가 제품이 개발에 들어가기 전에 빠르게 대응해야 했다. 어쩌다 타이밍을 놓쳐버리면 그대로 배포가 되는 거고.
라이팅 개선을 적용하는 단계에서도 이슈가 있었다. 라이터가 직접 디자인 시안을 건드리거나 개발에 관여하는 것이 아니기 때문에 개선안이 반영되었는지 되지 않았는지 확인하는 과정이 또! 필요했다.
"XX님, 이거 반영해주셨나요?"라고 라이터가 재차 체크하거나, "여기 반영했습니다"하고 디자이너가 라이터에게 결과를 공유해야 하는 비효율이 발생했다.
이 문제를 모두 해결하려면, 팀원들이 낮은 비용으로 라이터 수준까지 가이드라인을 학습해서 셀프 검수를 하고, 그 검수는 디자인이 끝나는 시점이 아니라 실시간으로 이루어져야 했다.
이런 문제의식에서 나온 해결책이 바로 보이스톤 메이커다. (자세한 내용은 토스 디자인 콘퍼런스 영상에서 확인하실 수 있습니다.)
이전에 디자이너가 라이팅 가이드라인을 적용하기 위해서는 노션 문서를 통째로 외우거나, 디자인 도중에 어디에 문서가 있었는지 한참을 뒤적거리거나, 라이터를 호출해야 했다.
하지만 이제는 가이드라인을 하나하나 학습할 필요 없고, 라이터가 올 때까지 기다리지 않아도 된다. 프레이머 위에서 보이스톤과 어긋나는 부분을 실시간으로 체크해주니까!
물론 아직 고도화 단계에 있기 때문에 부족한 점도 많지만, 확장 불가능한 워크플로우를 확장 가능한 방식으로 바꾸었다는 점에서 큰 의의가 있다고 생각한다.
이제 토스 라이팅 팀은 절약한 리소스로 좋은 라이팅으로 정의할 수 있는 베스트 프랙티스를 더 발굴할 수 있게 됐고, 그것이 재생산될 수 있도록 패턴을 찾아 가이드라인화한 뒤 시스템에 적용해 라이터뿐만 아니라 모든 팀원이 베스트 프랙티스를 만들 수 있는 인프라를 갖게 된 것이다.
다음 글에서는 보이스톤 메이커를 만든 자세한 과정과 사용 전후가 토스 팀에 어떤 변화를 가져다줬는지 써볼 예정.
뿐만 아니라, 토스 피드 인터뷰(토스가 금융을 더 쉽게 만드는 또 하나의 방법, UX Writing)에서 소개한 라이팅 프린시플과 콘퍼런스 영상에 나온 Problem-of-writing(라이팅 제보) 채널과 해피 모먼트, 인터비즈 인터뷰에서 언급했던 5% inspiration 등 토스 UX라이팅 팀의 일하는 방식과 문화를 공유해보려고 한다.