첫 UX writer는 무슨 일을 해야 할까

김자유 · 토스 코어 UX Writer
2023년 4월 14일

라이팅 팀은 토스 제품 안에 있는 문구를 관리하고 있어요.

저희 팀의 강점은 라이팅 팀뿐만 아니라 조직 전체가 라이팅을 잘할 수 있게 만드는 것인데요. 매끄러운 커뮤니케이션을 위한 문구 개선은 물론, 그 문구를 라이팅 팀뿐 아니라 모든 팀원이 쓸 수 있도록 원칙을 만들기도 하고, 시스템으로 구현하는 일도 하고 있어요.

토스의 8가지 라이팅 원칙들 >

토스 라이팅 팀은 앱 안에 들어가는 제품 라이팅을 중점적으로 관리하고 있어요.

처음에는 저도 제가 어디까지 일해야 할지 정하기가 어렵더라구요. 그래서 문장 교정도 하고, 웹사이트도 하고, 채용 콘텐츠 관련된 일도 하고 이것저것 다 했죠. 개발자가 보는 문서를 교정하는 일도 했었네요.

입사 첫 주에 받았던 요청

업무를 하면서 이게 정말 UX writer만 할 수 있는 일일까? 내가 해야 하는 일이 이것일까? 생각했을 때 확신이 없었어요. 당시엔 신규 입사자였으니까, 일단은 모든 업무를 가리지 않고 다 받아서 무작정 열심히 처리했었어요.

하지만 시간이 갈수록 업무가 엄청 불어났어요. 그때 프로덕트 디자이너가 30명 가까이 됐었거든요. 디자이너가 30명인데 라이터는 1명이었던 거죠. 선택과 집중을 해야 했어요. 그때 디자이너분들을 한 분씩 찾아가서 1:1 커피챗을 했어요. ‘제가 무슨 역할을 하면 좋을까요’라고 여쭤봤죠.

복사 붙여 넣기로 디자이너분들께 DM 돌리기 (하지만 절대 15분 안에 끝나지 않았다 ^^…)

사실 만나기 전에는 ‘엥? 저도 모르겠는데요’라고 반응하시면 어쩌지 싶어서 걱정도 했어요. 놀랍게도 실제로 만나고 보니 정말 많은 인사이트를 갖고 계신 거예요. 이런 고민이 있었고, 예전에 이런 시도를 해봤고, 라이터에게 이런 걸 기대하고, 이런 아이템도 생각해 봤다 등등…

그때 인터뷰한 내용을 바탕으로, ‘일단 제품에 집중해야겠다’는 결정을 내릴 수 있었어요. 직접 말씀해 주셨던 문제를 푸는 일이니, 공감대도 잘 형성돼서 설득도 어렵지 않았어요.

첫 직군으로서 어디에 집중해야 할지 모르겠다면, 이해관계자를 인터뷰하는 걸 추천드려요. 기대했던 것과 완전 다른 답을 얻게 될 때가 많더라구요.

라이팅은 모두가 쓸 수 있기 때문에, 제 업무를 디자이너분들께 위임해야겠다고 생각했어요.

처음에는 요청 업무를 처리하는 것만으로도 급급했어요. 하지만 점점 업무에 적응하게 되면서, 요청받지 않은 영역들도 챙기기 시작했죠. 그러다 제 손길이 굉장히 랜덤하게 닿는 것 같다는 생각을 하게 된 거예요.

친한 디자이너분과 밥을 먹다가 얘기해서 살펴보거나, 어쩌다 들어간 디자인 리뷰에서 살펴보거나, 제가 직접 앱을 쓰다가 발견하거나… 그렇게 발견하지 못한 영역들은 충분히 챙기고 있지 못하다는 생각이 들었고, 저 혼자서 모든 문구를 직접 본다는 건, 제품의 어느 부분을 늘 놓치는 것과 같다고 생각하게 됐어요.

그렇다고 모든 제품을 배포하기 전에 제가 검수를 할 수는 없었어요. 속도가 빠른 토스의 문화와 맞지 않았죠. 그래서, 접근 방식을 바꾸기로 했어요. 바로 다른 사람이 잘 쓰게 만드는 일에 집중한 거예요. 제가 글을 쓸 때 생각하는 것들을 규칙으로 만들어서 전파했죠. 그 규칙이 더 고도화된 것이 시스템이고요.

출처: 어느 날 토스가 말을 걸기 시작했다 (토스 디자인 콘퍼런스 Simplicity21)

그렇게 열심히 규칙을 전파하고 시스템을 만든 결과, 지금은 ‘이렇게 쓰면 안 된다’, ‘토스의 보이스톤은 이런 것이다’라는 공감대가 팀 내에 어느 정도 형성되어 있어서, 라이팅 팀이 미처 보지 못하더라도 어느 정도 퀄리티는 챙겨서 나가게 됐어요. 라이팅 팀뿐만 아니라, 토스 팀의 라이팅 실력이 높아지게 된 거죠.

보이스톤을 만들 때 우리 사례에서 시작하지 않았던 거요.

보이스톤이라는 걸 처음 만들어보니까, 타사 레퍼런스를 되게 많이 찾아봤어요. 구글, 우버, 에어비앤비, 메일침프, 듀오링고… 유명한 회사에서 내놓은 자료란 자료는 다 봤는데, 딱이다 싶은 게 없는 거예요. 너무 두루뭉술했거든요.

예를 들어 메일 침프의 문서가 좋았는데, ‘와, 드라이한 유머라니 멋지다! 근데 이걸 어떻게 하지? snobbish하지 않으려면 어떻게 말해야 하는 걸까?’ 도저히 모르겠는 거예요.

메일침프 콘텐츠 스타일 가이드

그러다 <strategic writing for UX>라는 책에서 본 보이스 차트라는 프레임 워크가 생각났죠. 어차피 다른 회사들 것을 그대로 가져다 쓸 수 없다면, 좋은 틀을 가지고 작업해봐야겠다 싶었어요.

출처: <Strategic writing for UX>, Torrey podmajersky

그래서 바로 가져와서 빈칸을 채워봤어요. 만들면서 ‘오, 보이스톤을 만들 때는 이런 걸 고려해야 하는구나’하면서 뭔가 되는 듯한 느낌이었어요. 예를 들면 이런 식이었어요.

제품 콘셉트: Reliable, 안심하고 돈을 맡길 수 있을 정도의 신뢰감 라이팅 콘셉트: 신뢰를 주는 글쓰기(일관적인, 퀄리티 높은), 비문이 없고 일관적이며 퀄리티 높은 문장을 지향한다. 어휘: 명료하지만 기계 같지 않다. 어투: 문장형(명사형X), 청유형 문장(강요나 지시X) …

만들고 보니 너무 뜬구름 잡는 이야기만 하는 것 같고, 만든 저조차도 이 문서를 보고 우리 톤에 맞는 문장을 써보라고 하면 못 쓸 것 같은 거예요. 되게 멋있는 말인데 하나하나 뜯어보면 너무 추상적이고, 사실 대부분의 상황에서는 Do와 Don’t 중에 고르는 게 아니라 Do와 Better를 가려내야 하는 경우가 많았기 때문에 큰 도움이 되지 않았죠.

그래서 일단 제품에서 ‘이건 우리 톤이야’싶은 화면을 무작정 끌어모았어요. 그렇게 사례를 찾는 과정에서 ‘이건 우리 톤이 아닌데(아니었으면 좋겠는데)?’싶은 것들도 자연스럽게 찾게 되고요. 중요한 건 우리 톤인지 아닌지를 엄밀하게 검증하려고 하지는 않았다는 점이에요.

‘이 정도면 괜찮은 듯?’, ‘이건 좀 그런가’ 정도의 애매한 감정을 가지고서 구분해보려고 했어요. 그렇게 사례를 모으니 좋은 문장과 그렇지 않은 문장의 패턴들이 보이기 시작하더라구요. 그렇게 조금씩 토스의 보이스톤을 명문화하기 시작했죠.

라이팅 원칙을 만들기 위해 사례를 한 곳에 모으는 중. 이렇게 모은 사례들에서 공통점을 찾아 원칙으로 만들어요.

그 이후로 모든 가이드라인은 사례를 수집하는 것부터 시작해요. 연역적으로 접근하는 게 빠르고 효율적이라고 느껴질 수 있지만, 실제로 쓸 수 있는 규칙을 만들려면 언젠가는 귀납적으로 접근할 수밖에 없어요.

‘전체 사일로 워싱’이란 걸 했었어요.

말 그대로 전체 사일로를 돌아다니면서 문구를 개선하는 거예요. 모든 디자인 화면의 문구를 저 혼자서 하나하나 다 뜯어보는 거죠. 지금 생각하면 비효율도 그런 비효율이 없는데, 그때는 다른 방법이 생각 안 났어요.

갑자기 댓글이 달리면 당황스러우실 것 같아 디자이너분들께 개인적으로 메시지를 보냈던 기억이 나네요.

사실 그 작업의 목적은, 실제로 그 문구를 고친다기보다는 라이팅에 대한 관심도를 올리기 위함이었어요. 이렇게 한 번 피드백 받으시면 다음에 문구를 쓸 때는 제가 말씀드린 내용을 기억하실 거라고 생각했어요.

그래서 ‘이 문구는 이렇게 바꿔주세요’하고 대안만 던지는 게 아니라, 왜 그렇게 바꾸는 게 좋은지 이유를 함께 남겼었죠. 지금 생각해 보면 그런 노력들이 규칙을 전파하고 공감대를 형성하는 데에 큰 기여를 한 것 같아요.

제플린에 하나하나씩 남겼던 댓글들 모음(왠지 죄송한 마음에 귀여운 말투로…)

디자이너분들을 설득하는 일이 제일 어려웠던 것 같아요.

사실 입사하기 전에는, 라이터는 저 하나니까 글은 제가 제일 잘 쓸 거라고(…) 생각했어요. 그런데 제가 지금까지 써오던 글이랑 제품 안에 들어가는 문구의 세상이 엄청 다른 거예요.

예를 들면 독자가 이해하기 쉽게 맥락을 충분히 설명하고 배경 지식 없이도 읽을 수 있는 단어로 풀어써도, 그 문장을 굉장히 좁은 영역에 넣어야 했기 때문에 정보를 덜어내야 했어요. 즉, 제가 생각해 온 좋은 문장이 여기에서는 좋은 문장이 아니었죠. 그게 좀 충격이었어요.

그러니 어떻게 설득해야 할지 막막하더라구요. 저만의 기준으로 아무리 ‘이렇게 써야 합니다’라고 해도 그 분들의 기준은 달랐을 테니까요. 제가 단순히 예쁜 글을 쓰는 사람이 아니라, 실용적인 글을 잘 쓰는 사람이기도 하다는 걸, 제 전문성을 다시 입증해야 하는 상황이었어요.

그때 발견한 건 토스 안에 있는 사람들이 모두 지표 중심으로 일하고 있다는 점이었어요. 그들을 설득하기 위해선 그게 가장 빠른 길이겠구나 싶었죠. 그래서 그동안 디자이너분들이 실험했던 화면들을 다 모아서 ‘이렇게 썼더니 이기더라’라는 규칙을 만들었어요.

토스가 금융을 더 쉽게 만드는 또 하나의 방법, UX writing >

그게 라이팅 프린시플의 초기 버전이었어요. 사실 이 원칙만 봤을 때는 당연한 말처럼 느껴질 수 있지만, 실제 지표 상승을 이끌어낸 사례들을 기반으로 한 것이기 때문에 공감대를 얻을 수 있었어요.

물론 지금은 지표만이 유일한 기준은 아니에요. 지표 자체보다는, 제가 디자이너 분들과 ‘같은 곳을 보고 있다’라는 공감대를 형성하는 게 중요했던 거죠. 그렇게 라포가 쌓이니, 이제는 라이팅 팀이 중요하다고 생각하는 부분들도 존중을 해주시더라구요. 예를 들면 지표에는 크게 영향을 주지 않지만 브랜딩 적으로 임팩트 있는 해요체 적용 같은 거요.

처음 가이드라인을 만들 때는, 만드는 사람이 아니라 사용하는 사람이 공감할 수 있게 만드는 게 중요한 것 같아요. 그게 실제로 유용한 가이드라도, 내가 중요하게 생각하는 가치가 빠져있다면 와닿지 않으니까요. 지금 해요체가 토스의 톤을 구성하는 데에 가장 큰 역할을 하고 있지만, 제가 처음부터 말투를 고쳐야 한다고 설득했다면 아무도 공감하지 않았을 것 같거든요.

‘갖고 있는 것들을 활용하기’요.

회사에 나 하나뿐이고, 내가 제일 전문가여야 한다는 생각에 회사 안에서 정보를 더 찾아보는 건 크게 중요하지 않다고 생각했었어요. 이미 잘하고 있는 다른 회사를 참고하거나 책이나 아티클 같은 외부의 정보를 정말 많이 찾아봤던 것 같아요.

물론 그 정보들이 어떤 면에서 도움이 되기는 했지만, 실질적인 문제를 찾아주지는 않았어요. 근본적으로는 우리 조직이 실제로 갖고 있는 문제를 해결해야 하는 것 같거든요. 지금 우리 팀원들이 느끼는 문제는 무엇인지, 우리 제품에서 문제는 무엇인지. ‘지금 우리’에 집중하라고 말해줄 것 같아요. 제가 디자이너 분들을 인터뷰하고, 가이드라인을 만들기 전에 사례를 먼저 수집했던 것처럼요.

댓글 0댓글 관련 문의: toss-tech@toss.im
연관 콘텐츠
㈜비바리퍼블리카 Copyright © Viva Republica, Inc. All Rights Reserved.