🎩 서비스 문구 전반의 오케스트레이터, UX라이터 글쓰는개미핥기

🧑‍💻 오늘의 메이커 : AI시대, 새로운 UX Writer의 역할을 제시하는 '글쓰는개미핥기' 메이커

오늘 함께할 메이커는 우리 서비스를 수평적인 시선으로 바라보며, 서비스의 모든 언어를 잘 굴러가도록 조율하는 ‘오케스트레이션’을 담당하는 6년차 UX Writer(이하 UX 라이터) 글쓰는개미핥기 메이커입니다.

글쓰는개미핥기님은 브런치에서 AI시대에 변화해가는 UX 라이터의 역할과 갖춰야할 역량, 그리고 라이터로서 활용하는 바이브 코딩 등 다양한 시도를 이끌어가고 있습니다.

오늘 인터뷰에서는 “오케스트레이션” 역할의 UX 라이터로서 최근 시대에 맞춰 겪고있는 변화와 문제를 풀어가는 방식, 그리고 AI 시대의 한 사람으로서 준비해야할 역량에 대해 이야기 나눠보도록 할게요.

레시피 하나, UX 라이터에서 Text 엔지니어로의 성장

Q. 먼저 구독자분들께 본인과 담당하시는 업무 소개 부탁드립니다!

안녕하세요. UX 라이터라는 세계에 발을 들인지 6년차가 된 글쓰는개미핥기입니다.

지금은 UX 라이터에서 Text 엔지니어로 성장해가고 있는데요. 단순히 문구를 작성하고 수정하는 것을 넘어서 서비스에서 Text가 어떻게 쓰이면 좋을지, AI를 어떻게 활용하면 더 좋을지 고민하며 업무를 수행하고 있습니다. 

Q. 직접 경험한 UX 라이터의 세계는 어떠셨나요? 직무로서 가장 큰 매력은 무엇인지도 궁금해요.

음, 처음 UX 라이터라는 직무를 선택할 때만 해도, ‘아, 문구만 수정하면 되는구나’라고 생각했어요. 아무런 고려도 없이, 무작정 문구만 수정하면 된다고 생각한 거죠.(웃음)

하지만 실제로는 UX를 고려하고, 사용자는 어떻게 서비스를 이용하는지, 그때, 우리는 어떻게 전달해야 비즈니스적인 관점에서 최적의 안내를 할 수 있는지 등 많은 부분을 고려해야 할 사항이 상당히 많았어요.

어떻게 보면 ‘인문학’적 관점으로 접근해야 하는데, 인간의 역사를, 인간의 문화를, 인간의 마음을 꿰뚫어야 정확한 안내가 가능했기 때문이죠. 저는 이와 같이 결합해서 최대한 도전해 볼 수 있다는 점이 매력이라고 생각했어요.

특히 사용자 플로우는 단절되어 있는게 아니라, 전체 여정이 하나의 지도를 이루듯 연속성을 지니고 있어요. 쉽게 말하면, 우리가 읽는 문학과 같이 하나의 ‘서사’처럼 연결되어 있는 거죠. 이에 따라 ‘연속성’을 재설계하는 방식으로 접근해요.

대표적인 예시로 온보딩이 기능 나열식이라고는 하지만, 화면은 하나의 선으로 연결되어 있잖아요. 이에 따라 각 화면이 다음 화면과 어떻게 이어지는지, 다음 스텝으로 나아간다면, 점점 결말로 이어지는 행동을 어떻게 이끌어낼 것인지, 각 기능별로 나열만 했다면, 동등한 조건에서 어떻게 이야기를 다루고 있는지 등을 고민하고 문구를 작업하는 거죠.

하지만 늘 그렇듯 우리가 의도한 대로 흘러가지 않는게 인간이잖아요? 저는 ‘인간’ 그 자체가 어렵더라고요. 그래도 매번 마주하게 되는 그 어려움이 꼬여서 풀리지 않는 비닐 봉투의 손잡이를 풀어냈을 때 느끼게 되는 쾌감처럼, 결과가 좋으면 행복해 지더라고요.

에디터 : 인문학적인 요소를 업무에 적절히 반영하는 것도 많은 노력이 필요할 것 같아요!

아무래도 문구 하나를 쓸 때에도 통계 데이터를 사용하는게 객관적이라 가장 좋겠지만, 사용자들이 잘 이해하는가의 범주는 다른 측면이 있는데요.

예를 들어 UX Writing은 독립적으로 ‘좋다’라는 케이스를 데이터로 측정하기 상당히 어려워요. 물론, 버튼 하나의 문구만 수정한다면 객관적인 데이터로 접근할 수 있지만, 그 하나만 변경하는 케이스는 드물기 때문인데요. 이때, ‘이 표현이 실생활에서 어떤 맥락에서 쓰이는가’를 많이 생각하고 작업하고 있어요. 또한, 단순히 사전적 정의를 들이미는게 아니라, ‘이 단어가 주는 심리적 거리감’은 어떤지, ‘우리 서비스에서 쉬운 단어일지’, ‘실생활과 교차해서 보면은 어떤 관점으로 접근할 수 있는지’ 등을 많이 고려해요.

Q. 최근 AI의 진화로 직무 수행 방식도 빠르게 변화했는데, 1년 사이 직무 경험에 변화가 있을까요?

AI는 신이 주신 도구로 성장하고 있어요. 이제는 AI가 없으면 일을 못한다기 보다는 ‘하기 싫다’라는 게 더 정확할 것 같은데, 그 정도로 AI는 우리의 효율을 비약적으로 성장시켜줬어요. 물론, 제대로 쓴다는 전제 하에 말이죠.

우리가 분석하고, 해석하기 어려운 것을 명령만 정확히 내리면, 우리가 의도한 바, 우리가 생각한 바, 우리가 예측한 바 그대로 안내해 주기 때문이죠.

하지만 처음부터 이런 결과가 나오지는 않더라고요. 항상 엉뚱한 말을 했고, 흔히 말하는 AI 슬롭(Slop)을 항상 내밀었어요. 그럴 때마다 진짜 맞아? 라는 말을 되새기며, AI의 뇌에 심는 다양한 작업과 시도를 반복해서 진행했죠. 마치, 신입사원에게 제가 가지고 있는 암묵지를 욱여넣듯이 말이에요.

특히 *AI 슬롭(Slop)을 피하기 위한 방법으로 다들 많이 이야기할 텐데요. ‘신입사원 다루듯이’ 모든 맥락을 차근차근 단계별로 이해시키면 편해요. 갑자기 중간 맥락을 건너띄고 이야기하면, AI는 ‘환각’이라 불리는 할루시네이션 기반으로 자기가 웹서치를 하거나, 여태까지 이야기해왔던 맥락 중 뜬금없는 것을 하나 꺼내서 이야기하는 등 주제 범위를 벗어난 내용들을 답변하게 되더라고요.

에디터 : AI가 없음 하기싫다는 표현이 너무 공감되네요(웃음) AI를 본격적으로 활용하기 전과 현 시점에서 업무의 단계는 어떻게 변화가 되었나요? 

AI를 활용하기 전에는 Jira 티켓으로 날라오는 모든 질문에 대해 일일이, 모든 문구와 화면을 뒤져가면서 일을 했어요. 실제로 문제의 원인과 해결책을 만들어 내는데 2시간 가까이 걸릴 때도 많았죠. 하지만 그 문제를 정의하는 일, 문제의 원인을 파악하고 해결하는 일이 이제는 단 5분이면 돼요. 

출처 : 글쓰는개미핥기 브런치 - UX 라이팅에 RSI 끼얹기

예를 들어, AI는 Jira 티켓의 본문과 댓글을 모두 확인하고 온톨로지 시스템이라는 문구를 모두 모아둔 로컬에 접근해 관련된 문구를 찾아보게 돼요. 이때, ‘why’ Jira 티켓이 발행된 이유를 살펴보고, ‘How’ 어떻게 수정하면 좋을지 알려주고, ‘What’ 어떤 문구로 변경하면 좋을지 안내해주는 흐름이에요.

제가 만든 툴이지만, 아직은 베타기간이라, Jira 티켓 검수 하단에 있는 ‘문구 검색’을 통해, 이게 실제로 맞는지 한 번 더 검증을 해요. 그리고 각 담당자에게 전달을 하죠. 온톨로지 시스템은 우리 서비스의 문구 전체를 관장하는 서비스이기 때문에, AI에 전달하는 정보가 나뉘어져 있지 않아요.

기존 방식에서는 제가 일일이 어떤 키가 잘못되었고, 어떤 언어가 잘못 되었는지 다 찾아봐야 해서 길게는 2시간도 걸릴 때가 많아요. 해당 기능이 맞는지도 살펴봐야 하고, 맥락도 맞는지 살펴보고, 담당자에게 질문할 때도 있거든요. 하지만 온톨로지 시스템 기반으로 진행할 때는 해결책까지 한 번에 추출되기 때문에 기능 담당자에게 해당 결과를 질문하면 곧바로 답변이 오는 케이스가 많아요. 짧게는 1분만에 답할 수 있는 것도 있고, 길게는 20분 내외로 모든게 해결되는 경우가 많죠. 다만, 답은 어떤 상황이냐에 따라 다르기 떄문에 소요되는 시간이 모두 동일하지 않아요.

레시피 둘, 문제 정의와 문제를 풀어가는 방식

Q. 본격적으로 UX 라이터 시선에서 정의되는 문제는 무엇이고 풀어가는 방식에 대해 이야기 나눠보려해요.

UX 라이터가 자주 받는 요청 중 하나는 ‘이 문구 어때요?, 여기 문구 좀 바꿔주세요’와 같은 요청이에요. 그런데 이 문제를 해결할 때, 사실 문장은 뒷전이에요.

왜 그 문장이 나왔는지, 그 문장의 히스토리는 무엇인지, 이 문장이 사용자에게 와닿는 것은 무엇인지, 사용자가 이 문장을 보고 다음 행동을 어떻게 취할 것인지 등을 고려하죠. 즉, 비즈니스 적으로는 왜 이 문장이 탄생했는가?를 본다면, 사용자 입장에서는 어떻게 반응할지를 예측하고 예측한 결과에 따라서 달라질 행동에 맞춰 문구를 새롭게 쓰는 거죠.

이런 전반적인 과정을 파악하려면 업계마다 조금 방식은 다른데요. IT 업계에 재직할때는 PRD과 Figma에 그려져 있는 프로덕트 기반으로 파악을 했어요. 어떤 상황에서 나왔는지 등을 따라가면서 사용자의 여정과 히스토리를 파악했어요. 정통 제조업에 있는 지금은 사양에 따라 다 달라지기 때문에 그 사양이 어떤 상황에서 태어났으며, 어떤 상황에서 해당 기능이 사용되는지 그리고 사용자는 어디서 마주하는지 등을 기반으로 살펴보고 있어요.

에디터 : 그렇다면 사용자 맥락, 제품 정책, 화면 상태, 예외 상황 등을 파악하는 특별한 순서가 있나요? 

순서는 정해져 있지 않아요! 어느 순서로부터 튀어나올지 정확히 아는게 더 중요하죠. VOC가 들어오면 사용자 맥락부터 푸는게 맞죠. 하지만, QA에서 걸렸다면 제품 정책에 따라 바꿔야 하는지, 화면 상태가 변해서 바꿔야 하는지, 갑자기 사양에 따라서 해당 상황이 엣지 케이스로 변한다든지 등을 모두 고려해야 하는 거죠.

담당하고 있는 프로젝트 사례나 자세한 내용은 회사 내 기밀로 유지되고 있어서 쉽게 말씀 드리기가 어렵네요. 궁금하면 저를 찾아오세요(웃음)

Q. 지난 팟캐스트에서 UX 라이터로서 페르소나가 중요하다는 점을 강조하셨어요. AI가 페르소나에 맞는 문장을 만들게 하려면, 어떤 점을 신경써야 할까요?

우선 페르소나가 중요하지만 하나의 페르소나로 정의할 수 없는 경우들도 있어요. 그래서 페르소나를 정의하기 보다는 말 그대로 얼마나 직관적이냐, 사용자가 얼마나 이해하기 쉽냐, 이 사양에 따라서 어떻게 풀어낼 수 있느냐를 기준으로 삼고 있죠.

이는 제가 속한 프로젝트가 지닌 제조업의 특성이자 3개의 브랜드를 단 1개의 보이스로 풀어내야 하는 회사의 숙명이라고 할 수 있죠. 문제는 32개 언어로 나가는데 그 또한 다 일치시켜야 하기 때문에, 우리는 색깔을 없앨 수밖에 없어요.

출처 : UX Writing, 피그마 플러그인이 답일까? 

그래서 AI가 서비스에 온전히 맞는 문장을 만들게 하기 위해서는 AI가 우리의 서비스 전체 맥락을 이해할 수 있는 시스템을 만들어야 해요.

저는 최근까지도 Figma 플러그인과 Frame을 가지고 하면 가능할 거라고 생각했어요. 하지만 매번 질문을 던질 때마다 다른 답을 내놓고 방향성도 항상 달라지더라고요. 그래서 도입한게 온톨로지 시스템이에요. 여기에 모든 문구가 지니는 정보를 AI가 읽을 수 있게, 어쩌면 AI가 읽을 수 있는 데이터로 시각화해서 전달했죠. 자세한 이야기는 아래 글을 함께 참고해 주세요.

에디터 : 온톨로지 시스템을 처음 만들어보려는 작은 팀이라면 무엇부터 정리해야 할까요?

저는 운이 좋게도 앞선 담당자분들이 설계를 잘해두신 덕분에 비교적 수월하게 작업하고 있어요. 핵심은 모든 문구를 AI가 인식할 수 있도록 레이블을 정확하게 지정해두는 것이에요.

위의 기준으로 예를 들어볼게요. Figma의 특정 화면에서 Frame 명칭이 'Text_1'이고, 거기 들어갈 문구가 '첫 번째 텍스트'라고 해봐요. "이 값이 제대로 들어갔는지 확인해줘"라고 AI에게 명령을 내리면, 문구를 관리하는 툴에서도 레이블이 똑같이 'Text_1'이고 값이 '첫 번째 텍스트'여야 AI가 '일치한다'고 판단해요.

반대로 레이블이나 값 중 하나라도 어긋나 있으면 어떻게 될까요. AI는 "레이블은 일치하는데 값이 다르다" 혹은 "레이블은 다른데 값은 같다"는 식으로 정확히 짚어내고, 그에 맞춰 "레이블을 수정해라" 혹은 "값을 수정해라"는 해결책까지 스스로 도출해주는 구조죠.

Q. 이제는 유저뿐만 아니라 AI 에이전트가 잘 해석할 수 있도록 구조를 고려해야 하는데, 구조상 문장 간의 충돌은 어떻게 해결해야 하나요? 

그 허들을 낮춰주는게 Text Engineering을 담당하는 UX 라이터의 역할이라 생각해요. 사람에게 자연스러운 문장과 AI가 정확하게 해석할 수 있는 구조가 충돌하지 않게, AI를 잘 다뤄야겠죠. 쉽게 말해, 하네스 엔지니어링, RAG과 같이 AI가 올바른 방향으로 나아갈 수 있도록 잡아주는 기계적 장치를 잘 만들어야 해요.

출처: AI 생성

예를 들어 현재 시스템안에서 문장 검토, 수정 요청을 받으면 Jira 내의 요청 본문, 댓글, 스크린샷이 실제 데이터로 들어가요. 그러면 온톨로지 시스템에서 RAG이 작동해서, 관련 데이터를 찾아내, 키를 추출해서 계층을 확인하고, 로컬 스냅샷의 번역 데이터와 온톨로지 도메인/카테고리 정보와 즉시 대조한 다음에, 역방향 매칭으로 ‘이 문구가 실제로 어느 키의 값인가’를 전체 로케일 데이터에서 거꾸로 찾아내요.

그 다음 온톨로지와 하네스가 이제 초안을 분석하고 생성하게 되죠. 앞서 찾은 근거 데이터를 온톨로지 정보와 함께 프롬프트에 강제로 주입해요. 이때, 하네스가 ‘문구가 잘못 표시됐다고 바로 번역값을 수정하라고 결론짓지 말라’와 같은 규칙을 불어넣죠. 이를 통해 AI가 성급한 결과를 뱉어내지 못하게 제한하는 것도 중요해요.

그리고 RSI 루프를 통해 우리 서비스에 최적화된 UX Writing 가이드라인이 있는데, 이를 통해 누적된 규칙을 학습한 엔진이 이를 토대로 AI 결과를 통과 시키거나 반려시켜요. 예를 들어 키와 도메인의 정합성이 맞는지, 플랫폼 간 문구값이 일치하는지, 글로벌 스펙인지 국내 스펙인지 등을 모두 고려하는 거죠.

엔진이 반려시키면 AI는 다시 근거 데이터를 찾아내어 프롬프트 구조로 생성하는거죠. 그래도 반복되면 최종적으로는 제가 관여하는 형태죠. 이 결과가 번역 수정 건인지 개발 이슈인지에 따라 담당 부서가 완전히 달라지고, 담당자가 달라지기 때문에, 이 판단과 전달만큼은 사람이 계속 가져가야 하는 영역이죠. 특히, Jira 티켓에는 각 담당자가 표시되지 않아서 더욱 그래요. 즉, 과거에는 모든 실무를 맡는 사람이었다면, 이제 실무는 AI가 하고, 책임을 지고 명령하는 책임자의 포지션으로 옮기게 된 거죠.

에디터 : 이 모든 검토 과정에서 제품 정책의 빈틈이나 예외 상황을 발견했을 때는 어떻게 확인을 하시는 편이세요?

그런 상황은 항상 발생하는 문제예요. 결국 여기서도 ‘이 문구 좀 바꿔주세요’라고 하는 것으로부터 출발하거든요. 이게 문구만 바꾼다고 해결되는 일이 아닌데, 계속 문구만 바꿔달라고 요청이 오는 케이스죠.

그럴 떄는 UX부터 수정해야 하는데, 제조업 특성상 기계적 형태를 바꾸지 않는 이상 UX를 변경할 수 없는 케이스도 많아요. 그럴 경우에는 어쩔 수 없이 문구를 요청한 방향대로 수정하거나 혹은 지금이 더 나은 상황이라 전달하고 종료되는 경우도 많아요.

레시피 셋, 업무 과정에서 마주한 현실

Q. 앞서 말씀주신 것처럼 AI를 적극적으로 활용하고 계신 것 같아요. AI에게 비교적 안심하고 맡기는 일과 여전히 직접 처리하는 것이 낫다고 판단하는 업무가 있으신가요?

우선 티켓으로 오는 문제 분석, 문제 해결책에 대해선 AI가 전달해 주고 있어요. 하지만, 해결책을 전달하는 일은 제가 하고 있는데요.

AI가 저와는 상호작용이 잘 되지만, 함께 일하는 저를 제외하면 타인과는 커뮤니케이션 등 상호작용이 원활하지 않기 때문이죠. 게다가 저는 해외 권역 검수자들과 이야기를 해야 해서, 전체 맥락을 어디서부터 설명해야 할지 정하고 그에 따른 결과물을 전달하기 때문에 쉽지 않은 일이에요.즉 변화에 대한 것, 문제에 대한 것을 파악하고 안내하는 일은 AI가 잘하지만 커뮤니케이션은 어려운 측면이 있어요.

그리고 자동 평가 규칙을 통과했더라도, 앞서 설명드린 규칙 엔진은 ‘이 키가 도메인과 용어집에 일치하는가’까지만 보기 때문에 안내 문구의 책임 소재, 동의 문구의 법적 표현 등은 규칙에 없는 정책이라 AI가 통과시켜도 반려해요. 이런 건 애초에 온톨로지에 ‘이 시장은 법무 검토 대상’이라는 태그가 달리지 않으면 AI가 알 수 없기 때문이죠.

그래서 그 문구가 등장하는 ‘상황의 무게’는 AI가 아직 알 수 없어서 동일한 안내 문구라고 하더라도 각 지역에 따라서 그 ‘기능의 중요도’에 따라 제가 담당자와 상의해서 판단하는 작업은 필요해요.

에디터 : 말씀주셨던 AI가 타인과 커뮤니케이션 하는 과정에서 가장 어려웠던 점은 무엇인가요?

아무래도 AI는 문제를 있는 그대로 동료에게 전달하거든요. 제가 생각한 바, 제가 의도한 바를 무시하고 자기가 맘대로 생각하고 전달할 떄도 있어요.

AI로 테스트해 보면 알 수 있는 데요. 가끔씩 AI가 그래요. ‘아 제가 마음대로 추측해서 결과물을 안내해 드렸네요. 죄송해요.’라고 말이죠. 여전히 할루시네이션이 곳곳에서 발생하고 있다보니, 그 부분을 검증하고 보완하는 방식이 중요하다고 생각해요. 자칫 잘못하면 동료와 언쟁을 벌일 수 있는 문제가 생기기도 하죠.

추가로 담당자와 커뮤니케이션할 때, AI가 전달하는 말투에는 무게가 없어요. 그래서 무게에 따라 제가 톤을 조절해 담당자에게 전달하면서 커뮤니케이션을 진행해요.

Q. 반대로 AI로 인해 부담이 커지거나 업무시간이 늘어난 경우도 있을까요?

아무래도 바이브코딩이 유행하면서, 수많은 사람들이 ‘딸깍’으로 이 프로덕트, 저 프로덕트를 만들었다고 해요. 그러다보니 그런 현상이 당연하게 받아들여지는 경우가.. 저희한테도 동일하게 있는 것 같아요. 하지만 서비스를 런칭해 본 분들은 알 거예요. 만들어서 배포하는 것은 Phase1일 뿐이고, 운영하고 유지보수하는 일이 Phase2라는 사실을 말이죠. 그래서 어디서 발생할지 모르는 모든 문제들을 커버하고 해결하는 일이 상당히 많이 늘어났어요.

하지만 많은 분들이 공감해주시겠지만, 운영 업무가 참 티가 안나요. 그렇다면 이걸 가시화하는게 중요한데, 저 같은 경우는 관여한 모든 일들을 AI를 통해 기록하게 해 뒀어요. 또한 리드 타임을 측정해 얼마나 빠르게 문제를 해결했고 넘겼는지 기록해 두는 거죠. 그렇다 보니 저는 일반적으로 4명이 하고 있는 일을 AI와 함께 혼자하고 있네요(웃음).

에디터 : 운영하고 유지보수에 시간이 더 많이 든다는 말이 너무 공감되네요(눈물). 유지보수 하는 과정에서 규칙 엔진 오류로 문제가 있는데도 검수 결과가 ‘0건’으로 나온 적도 있다고 들었어요.

맞아요. 시스템이 고장났다는 신호 자체가 없는 고장이라, 사람이 의심하지 않으면 영원히 못 잡아요. 그래서 운영하며 지속적으로 관찰하는 것이 중요한 거죠.

특히 저는 직접 코딩하는게 아니라 바이브 코딩으로 유지보수하기 때문에, 매일 코드 보수 관점에서 AI를 돌리고 있어요. 그냥 반복해서 계속 검토를 할 뿐이죠. ‘딸깍’ 한 번이면 한 순간 결과는 튀어나오지만, 그 딸깍을 위해 보수는 매일매일 해야 해요.

그래서 아직 자동화된 재발 방지 장치는 없지만, 대신 사람이 주기적으로 직접 샘플을 열어서 확인하는 걸로 대신하고 있어요. 완벽한 답은 아니라는 걸 알지만 지금은 ‘시스템을 완전히 믿지 않는 태도’를 유지하는 게 그나마 가장 현실적인 안전장치라고 생각해요.

Q. AI를 활용해 직접 UX 라이팅을 해야하는 메이커들에게 전달할 수 있는 꿀팁이 있을까요?

단문이 아니라 복문이 중요하고, 단절된 정보가 아니라 연속된 정보가 중요해요.

우리의 서비스가 하나의 선으로 이어지도록 설계하고, 그 안에서 UX 라이팅이 잘 굴러가도록 탑을 쌓는게 중요하다고 말씀드릴 수 있을 거 같네요. 모든 문구가 하나처럼 움직일 수 있게 AI를 교육해 주셔야해요. 관련해서 인사이트를 얻기 좋은 사례 3가지도 함께 소개해드릴게요.

구름(goorm) PX팀의 ‘UX 구르미’ 피그마 플러그인

텍스트를 선택하고 컴포넌트·맥락·상황을 입력하면 즉시 검수 결과를 받아볼 수 있게 만든 사례예요. 저희 온톨로지 시스템의 초기 버전과 문제의식이 비슷해서, ‘왜 맥락 정보를 함께 넣어야 하는가’를 이해하기 좋아요. 

라포랩스(퀸잇)

Claude + Figma 플러그인 기반 AI UX 라이팅: UX 라이터 없이 제품을 만드는 스타트업이 ‘하나의 서비스는 하나의 목소리를 내야 한다’는 문제의식에서 시작해 AI로 일관성을 잡아간 과정이 나와요. 조직이 작을 때 어디서부터 시작하면 좋을지 감을 잡기 좋은 사례예요.

AI와 UX 라이팅

제가 존경해 마지않는 두 분이 쓴 책이에요. 바로 라인의 국/영문 UX 라이터, 전주경님과 이재익님이에요. AI에게 UX 라이팅 시스템을 직접 입히며, 어떤 방식으로 접근하는게 최적의 결과물을 뽑아내는지 테스트한 결과를 담아둔 책이죠. 쉬운 언어와 쉬운 표현으로 적혀 있으니, 누구나 읽기 좋은 책이에요.

Q. 하나의 제품을 운영하는 작은 팀이 가장 단순한 형태로 AI를 활용한 UX 라이팅 시스템을 준비한다면, 어떻게 접근하면 좋을까요?

앞서 소개한 시스템 기준으로 아래와 같이 각각 축소할 수 있을 거 같아요.

출처: AI생성

온톨로지의 경우 결국 개념을 정의하는 형태다 보니 그래프 DB 대신 스프레드시트 한 장으로 대체 가능해요. ‘이 키가 어느 화면과 컴포넌트에 쓰이는가’만 컬럼으로 정리해도 저희가 하는 도메인, 카테고리, 기능 3단 분류의 핵심 기능을 살려 사용할 수 있을 것 같아요.

RAG((Retrieval-Augmented Generation) 또한 AI가 정확한 답변을 생성하기 전 관련 정보를 검색하기 위한 기술이기 때문에, 역방향 매칭 같은 별도 계층 없이 앞서 생성한 스프레드시트를 AI에게 그냥 통째로 던져주고 ‘이 안에서 찾아라’고 시키는 정도로 충분해요. 데이터 양 자체가 적으면 벡터 검색이나 역탐색 로직을 짤 이유가 없어요.

하네스(Harness)와 같은 거창한 규칙 엔진 없이도 ‘이런 결론은 내리지 마라’는 문장 몇 줄을 프롬프트에 고정해두는 것만으로도 방향은 잡힐 수 있죠.

마지막으로 AI가 스스로 성능을 반복적으로 개선하기 위해 필요한 루프/RSI도 팀 규모에 따라 매주 자동 파이프라인 대신 한 달에 한 번 사람이 직접 훑어보는 정도로도 충분히 준비할 수 있을 것 같아요.

에디터 : 혹시 온톨로지나 RAG 등을 구축하기 어려운 팀도 있을까요?

규모에 따라 다르겠지만, 초기 스타트업은 무조건 비추예요.

예를 들어 제품의 언어가 1~3개로 데이터 양이 적어 시스템을 만드는 비용이 더욱 큰 경우나 아직 PMF를 찾는 중이라 화면과 컴포넌트 구조가 자주 바뀌는 초기 스타트업 단계는 온톨로지를 만들어도 구조가 계속 바뀌면서 매번 깨지니까, 유지 비용만 늘어나는 셈이죠.

또한 팀에 UX 라이터가 1명이고 전체 문구를 이미 머릿속에 다 담고 있는 규모여도 이미 사람이 온톨로지 역할을 하고 있는 거라, 시스템화가 오히려 비효율적이라고 생각해요.

결국 기준은 ‘사람의 기억력으로 감당이 안 되는 규모(제품 수 × 언어 수 × 화면 수)가 됐을 때’예요. 그 전에는 시스템보다 스프레드시트 한 장이 더 정확하죠. 그리고 무엇보다 초기 스타트업이라면 사업의 안정성이 더욱 중요한 시기기 때문에, UX 라이팅은 부가적인 요소로 챙겨주시면 좋을 것 같아요.

레시피 넷, AI 시대의 한 사람의 메이커로서

Q. 최근엔 각 직무간 협업 방식도 굉장히 큰 변화를 겪고 있는데요. UX라이터로서 AI로 인해 가장 체감되는 변화는 무엇인가요?

우선 너무 많은 것을 관여하게 됐어요. 위에서 원하는 것도 ‘AI를 활용한 검수 자동화’ 비롯한 모든 서비스 영역에 관여하는 것이라, , 모든 직무를 깊지 않지만 넓게 생각하고 판단할 수 있는 시야를 가져가야 하죠. 그러다보니 모든 사람을 고려해야 하는 골치아픈 일들이 종종 생기는 것 같아요.

그리고 다른 면으로는 AI의 영향으로 UX 라이팅의 수요가 사라진 것도 체감하는 편이에요. 하지만 저는 직무에 대한 깊은 이해없이 AI가 모든 것을 해줄 수 있다고 판단하는 거 자체가 문제라 생각하고, 아쉽기도 합니다.

AI 시대에 성공하거나 급격히 성장하는 사람들은 주로 그 직무에서 어느 정도 오를 때까지 오른 사람들이 AI로 프로덕트를 만들었을 때 성공하는 사례가 많아요. 그래서 지금이야말로 스페셜 T를 어떻게 구성해야 좋은 인재가 되는지 알 수 있는 대목이기도 하죠.

그리고 이러한 흐름에 따라 채용 공고가 급속도로 줄었어요. 채용 공고가 사라진다는 건 우리의 미래 성장 동력이 사라진다는 의미기도 하고, 그래서 직무 전환하는 사례가 많이 생기고 있어요. 슬픈 현실이죠.

하지만 원래 많은 것에 관심을 가지고 시도했지만 실패했던 저는, 오히려 AI가 다재다능한 UX 라이터를 만들 수 있는 새로운 기회를 창출해준다고 생각해요. 개발은 1도 모르던 제가 프로덕트를 뚝딱 만들잖아요. (물론 유지보수 하느라 머리가 아파요.ㅎㅎ) 빠르게 배포하고 테스트하고, 보완하고, 보수하고, 이런 것들로부터 제 미래는 UX 라이터로 정해진게 아니라, Text와 관련된 모든 것을 시도해 볼 수 있는 가능성으로 나아가고 있어요.

에디터 : 작성해주신 포스팅에서 속상하게도 “차가운 감자가 된 UX라이팅”이라는 문장이 있더라고요. 글쓰기가 정말 AI에게 쉽게 대체될 수 있는 영역일까요?

글쓰기는 복제할 수 있어요. 그대로 넣으면 비슷하게 만들어 주니까요. 하지만 그 안에서 차별점은 만들 수 있어요. 제 아무리 제 말투를 습득하게 한다고 해서 복잡하게 돌아가는 사고까지는 따라잡기 어렵거든요. 특히, 엉뚱함을 달고 사는 저는 그 자체로 빛날 수 있는 존재라고 봐요.

추가적으로 하나의 예를 들자면, 라인 UX 라이터 전주경님이 내뱉는 생활에서 나오는 그 개그들은 아무리 따라하려고 해도 따라할 수 없을 거예요. 그 개그들은 전주경님의 생애를 담고 있는 현실로부터 나왔으니까요(웃음).(주경님 죄송합니다ㅎㅎ..)

그래서 UX 라이터의 업무는 축소되지 않아요. 오히려 더 많은 일을 담당하게 되겠죠. 실제 AI를 쓰고 계시는 분들은 효율은 좋아졌으나, 맡은 일들은 많아졌다고 해요.

UX 라이터는 UX 뿐만 아니라 이제 BX의 관점에서 사용자에게 ‘어떤 말을 건내면 되는지’, ‘우리 서비스의 핵심 가치는 어떻게 드러낼 수 있는지’ 등을 관철하는 직무로서도 충분히 활용될 수 있다고 생각해요. 일종의 회사 내부 컨설턴트로 업무를 확장하는 거죠.

Q. 또 현실에서는 데이터, 시스템 구조, 이해관계자 조율, 성과 측정 등 요구되는 역량도 참 많이 늘어나고 있는 것 같아요.

맞아요. 데이터 중요하죠. 시스템 구조도 중요하고요. 이해관계자를 열심히 설득해야죠. 이 사람은 저 문구 좋고, 저 사람은 이 문구 좋다고 하니까요. 비즈니스 성과, 에이 문구 하나만으로 어떻게 바뀌어요. UX가 함께 따라가야 하는 문제인데요.

그래서 제가 드리고 싶은 말씀은, 그저 AI 활용을 열심히 하세요. 직무 간의 바운더리가 옅어지고 흐려지는 지금이 AI를 사용해서 특정 직무로 전환하거나, Text 씬을 다 씹어먹는 역할을 할 수 있는 기회이니까요.

다만 프로덕트 전반을 다 이해해야 해요. 비즈니스적으로 우리가 어떻게 돈을 벌고 있으며, 어떻게 사용자에게 다가가야 우리를 익숙한 친구, 친근한 친구로 인식하는지, 윗 사람들은 어떻게 설득해야 우리의 의도를 잘 이해하고 받아들이는지 등 말이죠. 이건 어쩌면 끝없는 눈치싸움이에요. 우리의 향방은 항상 정해지지 않았고, 정해지지 않을 것이기 때문이죠.

그리고 주변 동료를 잘 살피시면 좋겠어요. 그들이 어떤 것을 원하는지, 내가 무엇을 해주면 좋아하는지, 그들이 진짜 UX 라이팅에서 어렵게 느끼고 페인포인트라 여겨지는 부분이 무엇인지, 그것을 해결하는 프로덕트를 AI로 만들었을 때 독립할 수 있을 거라 생각합니다!

에디터 : 나아가 1~2년 뒤에는 UX 라이터는 어떤 모습일 것 같으세요?

음.. Writer는 유지 될 거예요. 제가 요새 밀고 있는 건 ‘AI Writer’라는 단어인데요.

사용자의 마음을 꿰뚫는 우리 서비스만의 서사를 잘 만들어야 해요. 그게 UX든, BX든 말이죠. 특히, 우리 서비스의 narrative를 잘 이해하고 스토리텔링을 설계할 수 있는 사람이 되세요. 그래야 넷플릭스로 억대 연봉 받고 이직할 수 있어요!!(웃음)

Q. 마지막으로 UX라이터로서 구독자들에게 이번 인터뷰를 통해 전하고 싶은 단 하나의 문장을 적어주신다면?

UX 라이터는 끝나지 않을 거예요. 서비스에서 문구가 사라지지 않는 이상, 모든 것이 음성 언어로 대체되지 않는 이상, 아니 대체되어도 보이지 않는 음성 언어를 스토리텔링으로 설계해 살아남을 거예요. 그러니까 너무 걱정하지 말고, UX 라이터가 되고 싶다면, 꿈을 향해 나아가 보세요.

AI와 적대적 M&A를 시도하지 마세요. 항상 친근하고, 친하게 그리고 공손하게 대하세요. 안 그러면 미래에 AI한테 혼날지도 몰라요(웃음). 저는 거기서부터 모든 것이 시작된다고 생각해요. 미래의 자산을 우리 것으로 흡수하는 일, 그것을 시도했을 때 새로운 길을 개척할 수 있고 현재의 직무도 성장시킬 수 있으니까요.

메이커의 이야기와 함께한 플레이북을 활용해보세요!

이번 인터뷰에서 특히 중요하게 본 건 UX 라이터의 역할이 단순히 문장을 쓰고 고치는 데서 끝나지 않고, 사용자 흐름과 제품 정책을 함께 보고, 반복되는 언어 업무를 AI가 다룰 수 있는 기준과 구조로 바꿔가는 방향으로 확장되고 있다는 점이었습니다.

그래서 플레이북도 “좋은 문장을 어떻게 쓸까?”보다 아래 질문에 답할 수 있도록 구성했습니다.

플레이북 체험해보기

실제 UX 라이팅 요청 중 하나를 다시 정의하고, AI에게 전달할 업무 지시서와 사람이 확인할 기준까지 완성할 수 있어요. 이 모든 내용은 팁스터 인스타그램 게시물에 댓글을 남기면, 활용 가이드가 담긴 노션 페이지와 체험판 파일을 DM으로 보내드릴게요.

좀 더 디테일한 플레이북 확장판 

추가로 UX 라이터와 프로덕트 디자이너가 제품 언어를 문장 → 판단 기준 → AI가 이해할 맥락 → 사람이 확인할 지점 → 운영 시스템까지 13단계에 거쳐 확장하는 플레이북도 함께 살펴보세요. 확장판 플레이북은 직접 작성한 답변을 기반으로 공유용 요약과 실행 기록으로 자동 정리되고, 업무에 바로 사용해볼 수 있는 프롬프트 3종도 함께 제공해드려요! 

오픈채팅방을 통해 뉴스레터로 다 소개하지 못한 정보를 확인해보세요!

팁스터가 인스타그램을 시작했어요!