가이드라인을 시스템으로 만드는 법

지난 아티클에서는 좋은 에러 메시지의 기준을 이야기했어요.

하지만 기준이 있어도 아무도 그것을 따르지 않고 실제로 적용되지 않으면 의미가 없겠죠. 기준을 만드는 일은 라이팅 팀 단독으로 할 수 있지만, 그것이 팀에 전파되게 하려면 팀원분들의 공감대를 얻어야 해요.

그러기 위해서 좋은 기준을 만드는 것을 넘어, 그 기준을 ‘쓰고 싶다’ 혹은 ‘써야겠다’라는 생각이 들게 문화를 만드는 일이 훨씬 더 중요해요. 이번 글에서는 잘 만든 기준을 팀에 전파하고, 제품에 적용하기 위해 어떤 노력들을 했는지 공유해드리려고 해요.

유저 경험에서 중요한 역할을 하는 에러 메시지

사실 처음부터 에러 메시지의 기준이 있었던 건 아니었어요. 처음에는 어떤 라이팅 문제를 먼저 해결해야 할까? 라는 고민에서 출발했어요. 사용자가 앱을 처음 접하고 팬이 되기까지 어떤 과정을 겪는지 생각해봤고, 거기서 에러 메시지가 굉장히 중요한 역할을 하겠다는 생각이 들었어요.

매력을 느껴 앱을 다운로드받고, 사용하면서 점점 익숙해질 즈음, 에러 상황을 만났을 때. 바로 그때 치명적으로 부정적인 경험을 한다면 그 다음 단계인 팬으로 이어지는 게 어려울 것 같았거든요.

무작정 워싱부터 시작했던 처음

문제 의식은 있었지만, 어떻게 시작해야 할지 모르겠더라고요. 그래서 무작정 사일로로 찾아가 각 제품에 있는 모든 에러 메시지를 하나하나 고치는 것으로 시작했어요.

라이터가 각각 다른 제품을 맡고, 이해되지 않는 것들은 메모를 남겨 가며 꼼꼼하게 워싱했어요. 각자 워싱한 후에 크로스 체크를 하며 비슷한 에러 메시지는 똑같은 문구로 통일하고, ‘Navigating error’라는 큰 기조 아래에서 서로 다르게 생각하는 세세한 부분들을 논의하며 작은 규칙들을 정해갔어요.

*Navigating error: 토스 에러 메시지의 기조. 에러 메시지의 역할은 다음 화면으로 넘어갈 수 있게 안내하는 것이라는 뜻.

그렇게 문구를 한 판씩 완성하고 나서 개발자분들께 새로운 문구를 적용해달라고 요청했어요. 물론 이 작업들이 물 흐르듯 진행되지는 않았고, 여러 문제점들이 있었어요. 저희가 쓴 에러 메시지가 정말 좋은 방향이 맞는지부터, 개발자 분들의 리소스를 써야했기 때문에 이 일이 그만큼 중요하다는 것까지 하나하나 설득하는 과정을 거쳐야 했거든요.

에러 메시지에 어떤 내용이 담겨야 하는지, 팀원들을 설득했던 스레드

한 예로는 “(우리 잘못인데)에러 메시지에도 해요체를 적용해야 할까요?”라는 물음에 지금은 당연하게 “네!”라고 답할 수 있지만, 긴 근거를 대며 설득해야 했을 때가 있었어요. 물론 그런 시기가 있었기 때문에 지금은 좋은 에러 메시지에 대해 다들 비슷한 기준과 공감대가 형성되어있고요.

감사하게도 공감해주신 팀원분들께서 적극적으로 협조해주신 덕에, 워싱된 메시지들을 차근차근 적용할 수 있었어요. 특히 사일로에 계신 개발자 분들께 몇 백 개에 육박하는 에러 메시지를 하나씩 뜯어보면서 이 에러가 왜 발생했는지, 어떻게 해결할 수 있는지, 아예 발생하지 않을 수는 없었는지를 귀찮을 정도로 여쭤봤었는데요.

하나하나 싱크하며 적용하느라 100개 가까이 되는 스레드

시트를 하나하나 체크해가며 행 단위로 답변해주시고, 다른 곳에서 비슷한 게 쓰이고 있는지, 더 좋은 문구를 쓸 순 없을지 적극적으로 논의해주셨어요. 그렇게 마무리 되었다가도, 더 좋은 문구가 생기면 흔쾌히 이전 버전을 지우고 다시 적용해주시기도 했고요. (함께 해주신 에러 용사님들 정말 감사합니다🥲)

에러 메시지 템플릿

그렇게 모든 에러 메시지를 하나하나 고치다보니 패턴이 보이기 시작했어요. 똑같은 내용인데 다른 문구를 쓰고 있거나, 전혀 다른 내용인줄 알았는데 하나로 통일할 수 있는 메시지, 다른 상황이지만 해결책이 똑같은 에러들… 이런 메시지를 규격화할 수 있겠다는 생각이 들었죠. 그래서 반복해서 나타나는 상황들을 카테고리화하고 각각의 상황에 맞는 문구를 템플릿으로 만들고, 원칙도 만들었어요.

서비스 점검 템플릿

예를 들면 은행에서 시스템 점검을 할 때 안내 다이얼로그를 띄워야 해요. 근데 은행 이름과 점검 시간만 바뀌고, 나머지 내용은 동일하기 때문에 문구를 하나로 통일할 수 있죠. 그래서 통일된 템플릿 문구를 만들었어요.

상황별로 세분화된 템플릿

그런데 이 템플릿을 쓰다 보니, 문구를 그대로 쓸 수 없는 상황도 있는 거예요. 정기 점검이 아니라서 점검 시간이 정해져 있지 않거나, 정기 점검이긴 하지만 그 시간이 2분 정도로 너무 짧아서 시간을 기재해줄 필요가 없는 경우처럼요. 그래서 이런 예외 상황별로도 문구 세트를 만들었고, 이제 시스템 점검 에러는 템플릿으로 대부분 커버되는 상태가 됐어요. 그런 식으로 여러가지 상황별 템플릿을 하나씩 추가했어요.

에러 메시지 시스템

사실 이렇게 템플릿이 있는 것만으로도 문구를 쓰기가 훨씬 쉬워졌지만, 더 간편해질 수는 없을까? 라는 생각이 들었어요. 왜냐하면 템플릿이 노션이나 스프레드 시트 등 디자인 툴 밖에 있었기 때문에, 문구를 쓸 때마다 디자인 화면 밖으로 나갔다가 다시 돌아와야 했기 때문이에요.

게다가 검색에 최적화된 툴들도 아니어서 원하는 문구를 바로 찾기도 어려웠고, 문구만 있었기 때문에 컴포넌트에 하나하나 직접 붙여 넣어야 한다는 점도 번거로웠죠.

이런 접근성 문제를 해결하기 위해, 메시지를 작업 환경 위에서 바로 검색할 수 있으면 좋겠다는 생각이 들었어요. 에러 메시지는 주로 개발자와 디자이너, 두 직군이 작성하고 계신데요.

이전에는 메시지를 전부 직접 써야 했지만, 에러 메시지 라이브러리로 한 줄이면 충분해진 코드

개발자 분들을 위한 기능으로는 에러 메시지 라이브러리가 있어요. 코드를 쓰면서 에러 메시지 컴포넌트를 불러올 수 있는 기능인데요. 에러 메시지 작업에 처음부터 함께 해주셨던 개발자 홍욱님께서, 워싱된 문구를 직접 적용하시다가 필요성을 느껴 만들어주셨어요.

이전에는 개발자가 에러 메시지를 쓸 때 디자이너에게 문구를 물어봐야했어요. 그걸 들은 디자이너는 자세한 맥락을 모르니까 PO나 서버 개발자에게 설명을 들어야 했고, 그 후에 다시 디자이너가 문구를 직접 써서 iOS/안드로이드/서버 개발자에게 다시 전달했죠. 이 과정이 너무 번거로워서 디자이너와 논의하지 않고 직접 쓰시거나 다른 제품에서 비슷한 메시지를 복사하시는 경우도 많았고요.

그런데 에러 메시지 라이브러리가 생기고부터는 개발자가 디자이너와 커뮤니케이션할 일도 줄어들고, 하더라도 템플릿이라는 기본값에서 논의가 시작되니 금방 끝낼 수 있게 됐죠. 비슷한 에러끼리는 똑같은 문구로 규격화되어있으니 검색하기도 쉬워지고, 제품에 일관성을 부여하기도 좋아졌고요.

(지금은 일부 사일로에 적합한 메시지들로 구성되어있지만, 라이브러리를 더 풍성하게 채워서 전사로 확장하는 게 앞으로의 과제예요. 💪)

관련 키워드를 검색하면 나오는 문구 템플릿

토스는 디자인 툴로 프레이머를 쓰고 있는데요. 디자이너 분들을 위한 기능으로는 프레이머링을 만들었어요. 디자인을 하면서 프레이머 안에서 필요한 문구를 검색하고 바로 붙여넣을 수 있는 기능이에요. ‘구글링 대신 프레이머링 해보세요’라는 의미에서 지은 이름이에요.

프레이머에서는 검색창을 열어 TDS(토스 디자인 시스템)에 등록되어있는 컴포넌트를 검색하고, 스티커처럼 붙여서 디자인할 수 있어요. 이전에는 컴포넌트 안에 ‘동해물과 백두산이’ 같은 더미 텍스트가 들어가있었는데, 자주 쓰는 문구들이 들어가있는 컴포넌트를 프리셋으로 쓸 수 있게 한 게 프레이머링이에요.

상황별 템플릿

프레이머링의 좋은 점은 노션이나 스프레드 시트과 다르게, 컴포넌트를 통째로 붙여넣을 수 있다는 점이에요. 노션으로 문구를 검색해서 쓸 때는 문구를 타이틀 따로, 디스크립션 따로 복사해서, 적절한 컴포넌트에 맞게 직접 붙여넣었어야 했어요. 프레이머 안에서는 문구가 들어있는 컴포넌트 자체를 바로 붙여넣을 수 있기 때문에 훨씬 간편해졌죠.

이후에는 개발자 현수님, 현지님, 규진님과 플랫폼 디자이너 정현님의 도움을 받아, 컴포넌트를 불러오면 그 컴포넌트에서 자주 쓰이는 문구 템플릿을 미리보기할 수 있는 기능도 추가했어요.

문구를 직접 쓰지 않고 프레이머링을 써달라고 요청하는 라이팅 팀

이전에는 프로덕트 디자이너분들이나 개발자분들이 타사 앱을 참고하거나 슬랙을 검색해서 라이터가 썼던 문구를 참고해서 직접 쓰셔야 했는데요. 이제는 이 템플릿을 복사해서 붙여넣기만 하면 되니까 디자이너분들은 라이팅 팀에 요청할 필요 없고, 라이팅 팀도 매번 같은 문구를 직접 쓰지 않아도 돼서 시간을 많이 아낄 수 있었죠. 게다가 모두가 같은 문구 템플릿을 쓰니 제품 전체의 일관성도 챙길 수 있게 됐고요.

UX 라이팅의 핵심은 함께 쓰기

UX 라이팅과 카피라이팅의 가장 큰 차이점은 카피라이터는 개인이 잘 쓰는 것이 중요하지만, UX 라이터는 함께 잘 쓰는 것이 중요하다는 점이에요. 카피라이팅은 광고 하나가 제품이지만, UX 라이팅은 앱 전체가 하나의 제품이기 때문이죠.

모든 화면에서 일관적인 커뮤니케이션을 해야 하기 때문에, 좋은 문구를 쓰는 것은 물론 그 문구를 다른 팀원들도 똑같이 써낼 수 있게 만드는 일이 중요해요. 처음에는 모든 에러 메시지를 라이터가 직접 썼지만, 그 에러 메시지를 다른 팀원분들도 직접 쓸 수 있게 만들기 위해서 여러가지 시도들을 한 것처럼요.

모두가 좋은 문장을 쓰게 만드는 일은 직접 메시지의 중요성을 이야기해서 문화적으로 풀 수도, 에러 메시지 라이브러리나 프레이머링처럼 작성의 허들을 낮춰 기술적으로 풀 수도 있어요. 토스에서 시도한 방법들 외에도, 조직마다 잘 맞는 새로운 방법들이 많을 거예요.

이 글을 시작으로 업계에 더 다양하고 효과적인 해결책들이 자주 공유되었으면 해요!