AI에게 UX 라이팅을 맡겼더니 뻔한 말만 하더라

라이팅 AI 잘 사용하고 있나요?

팀스파르타에는 '수택이'라는 UX 라이팅 AI가 있어요. Figma 화면이나 기획 문서를 건네면 그 화면의 맥락을 읽고 버튼, 안내, 에러 같은 문구를 만들어주는 사내 AI 도구예요. 이제 좀 쓰이나 싶던 어느 날, 해커톤 피드백에서 이 한 줄을 봤어요.

UX 라이팅의 경우 말투만 잡아주고, 전체적인 맥락에서 내용 자체를 매끄럽게 만들어주는 것에는 한계가 있는 듯했습니다.

곱씹어 보니 이런 뜻이더라고요. 수택이가 작성한 문장은 겉보기엔 흠잡을 데 없죠. 그런데 이 작업이 지금 뭘 하려는 건지, 그 맥락 위에서 무슨 말을 해야 하는지는 충분히 담지 못하고 있는 거예요. 그래서 '뻔한 말'처럼 느껴진 거죠.

수택이 라이팅 요청 예시

지난 글에서는 '아무도 안 쓰는 도구가 되지 않으려면'을 이야기했어요. 열심히 만든 가이드가 노션 안에서 잠들어 있던 문제요. 그건 어느 정도 풀렸어요. 업무 워크플로우에 수택이가 들어왔고, 누가 언제 얼마나 쓰는지 사용현황을 쌓고 있는데 이곳에 꾸준히 쌓이고 있거든요.

1탄이 궁금하다면? 글 보러 가기

이 사용현황 데이터가 힌트가 됐어요. 이 피드백이 나온 작업 로그를 열어봤어요. 수택이에게 라이팅 작업을 시키는 방법은 Figma 링크 주기, 노션 문서 주기, 이미지 주기, 직접 입력하기 총 4가지예요. 어떤 유형으로 입력했는지 남아 있었는데, 이분은 텍스트로 직접 작업을 설명한 케이스였어요.

“화면이나 맥락을 꼭 첨부하게 해야 할까?”

화면을 다 읽어도 이 사람이 지금 이 작업에서 뭘 하려는지는 어디에도 안 적혀 있어요. 맥락은 화면에 있어도, 의도는 사람 머릿속에 있으니까요. 이번에 받은 피드백 한 줄을 해결하지 못하게 돼요.

“대화를 통해 사용자에게서 끌어내야 할까?”

좋은 방향이 아니라는 건 바로 느낌이 왔어요. 수택이의 최종 결과물의 품질을 올라가겠지만, 입력을 더 내놓으라고 요구하는 순간 결국 귀찮아져요. 귀찮아지는 순간 아무도 안 쓰게 될 거고요.

결국 클로드 코드 스킬(수택이도 클로드 코드라는 AI 도구 위에 얹어 만든 스킬이에요)도 제품이더라고요. 배포하면 끝이 아니라 어떻게 하면 더 잘 쓰게 할지, 어떻게 해야 좋은 품질을 제공할지 다시 고민이 시작돼요.

'제품에 맞는 UX 라이팅'이면 충분한 줄 알았어요.

사실 저 피드백을 받기 전부터, 라이팅 품질은 주된 고민이었어요. 그리고 제가 세워둔 답은 명확했어요. 더 많은 컴포넌트 가이드를 추가하고, 더 많은 제품 정보를 넣자. 우리 디자인 시스템을 이해하고, 우리 제품의 맥락을 아는 라이팅을 주면 되는 거라고 생각했거든요.

그런데 그걸로는 충분하지 않다는 것을 피드백을 받고 알게 된 것 같아요. 라이팅이 내 상황, 내 의도, 내가 지금 필요한 것을 충분히 읽어주지 못하면, 아무리 우리 제품에 맞아도 결국 누구나 할 법한 말이나 맞춤법·비문을 잡아주는 수준에 그친 것처럼 느껴질 수 있겠더라고요.

제품에 맞는 라이팅을 위한 보수 작업과 업데이트는 물론이고, 이제 사용하는 팀원분들이 내 상황에 맞는 라이팅을 수택이를 통해 찾으려면 어떻게 해야 할지 고민하기 시작했어요.

묻지 않고 '의도'를 읽게 하기.

방향은 분명했어요. 내 상황에 맞추려면, 수택이가 내 상황을 알아야 해요. 즉 입력(input)이 필요하죠.

사용자에게 이것저것 써넣으라고 하면, 귀찮아서 안 써요. 아무도 안 쓰는 도구로 돌아가는 가장 빠른 길이죠. 목표를 적어라, 타깃을 적어라, 톤을 골라라… 이렇게 폼을 늘리는 건 답이 아니었어요.

그래서 새로 받지 말고, 이미 받고 있는 것에서 읽어내기로 했어요.

수택이가 함께 챙겨야 할 정바카라이나, 더 나은 라이팅을 위해 더 알아야 할 정보를 스스로 판단해서 필요한 것만 되묻게 했어요. 폼을 잔뜩 채우게 하는 대신, 진짜 필요한 한두 개만 물어보는 거예요.(수택이가 라이팅을 시작하기 전에 거치는 사용자 확인 단계예요.)

백오피스 공지는 1개만 걸 수 있는데, 이미 공지가 있는 상태에서 새 글을 공지로 지정할 때 뜨는 모달 문구를 작업을 실제 예시로 비교해 볼게요.

먼저 개선 전 수택이의 플로우를 살펴볼게요.

수택이 개선 전 UX라이팅 플로우

스킬을 호출하면 먼저 제품과 지면을 선택해요.

제품과 지면은 라이팅을 크게 좌우하는 요소거든요. 같은 문구라도 어떤 제품의 어떤 지면이냐에 따라 톤도, 표현도 달라져요. 그런데 이걸 매번 직접 적게 하면 귀찮기도 하고 빠뜨리기도 쉽어서, 입력하지 않고 선택만 하면 되게 만들어 뒀어요.

그다음 어떤 라이팅이 필요한지 텍스트로 설명하거나 참고 자료(Figma, 노션 등)를 넣으면, 수택이가 그 제품과 지면에 맞는 원칙을 살펴보고 라이팅을 시작해요.

수택이 개선 전 공지모달 라이팅근거

수택이는 라이팅을 제안할 때 근거를 꼭 보여주도록 설계가 되어있어요. 근거를 보면 모달과 버튼 컴포넌트 특성에 맞게 UX 라이팅을 작성한 것을 볼 수 있어요.

공통 원칙에 따라 타이틀인 “공지를 등록하시겠어요?”는 불필요한 어미 늘림을 없애기 위해 “공지를 등록할까요?”로 제안을 했어요. 그리고 모달 설명은 경어체 통일을 위해 ‘-해요’체로, 모달 컴포넌트 원칙에 따라 결과를 구체적으로 안내하는 문구로 다듬었어요.

개선 후엔 뭐가 달라졌을까요?

개선 전에도 수택이는 문장 자체는 잘 만들었어요. 톤도 지키고, 근거도 꼼꼼히 달아줬죠. 모달 설명 "등록하면 기존 공지가 이 글로 변경돼요"도 제품 톤이나 컴포넌트 원칙으로 보면 틀린 데가 없어요.

다만 원칙에 맞게 다듬는 것과, 이 화면에서 사용자가 꼭 알아야 할걸 짚어주는 건 조금 다른 일이더라고요. 개선 전 수택이는 앞쪽은 잘했지만 뒤쪽까진 못 갔어요. 말투는 잡아주는데 내용까지는 아쉽다던 그 피드백도 아마 여기서 나왔을 거예요. 그래서 개선 후에는, 라이팅을 시작하기 전에 꼭 필요한 것만 골라 되묻게 했어요. 이것저것 다 확인하려 들면 귀찮아서 아무도 안 쓰게 되니까요.

수택이 개선 후 되묻기 공지모달

수택이가 되물을 게 있는지 판단하는 기준은 딱 두 가지예요.

맥락에 따라 라이팅이 달라져야 하는 동작이나 정바카라 분기가 있는가

입력받은 값에는 없지만 반드시 들어가야 할 정보가 있는가

공지 모달 예시에서는 마침 둘 다 걸렸어요.

[정바카라·동작] 새 공지를 걸면 기존 공지가 자동으로 교체되나요, 아니면 먼저 수동으로 해제해야 하나요?

[핵심 정보] 모달에 기존 공지 제목을 함께 보여줄까요?

첫 번째 질문을 한 이유는 자동 교체냐 수동 해제냐에 따라 문장이 정반대가 되기 때문이에요. 자동 교체라면 '기존 공지가 해제된다'라고 알려야 하고, 수동 해제라면 '먼저 기존 공지를 내려달라'라고 안내해야 하죠. 넘겨짚어 한쪽을 골랐다 틀리면 사용자는 엉뚱한 안내를 보게 돼요. 그래서 추측하는 대신 물어본 거죠.

결과를 비교하면,

개선 전 "등록하면 기존 공지가 이 글로 변경돼요"는 바뀐다는 방향은 알려줘요.

그런데 알려주는 건 딱 방향까지고, 정작 중요한 세 가지가 비어 있어요. 왜 하나로 합쳐지는지(공지는 1개만 가능), 어느 공지가 영향을 받는지(그 공지의 이름), 어떻게 처리되는지(자동으로 해제) 요. 그래서 사용자는 확인을 누르는 순간 뭐가 어떻게 되는지 확신하지 못한 채 눌러야 해요.

수택이 공지모달 개선전후 비교

개선 후 "이 글을 공지사항으로 변경할까요?"는 교체라는 걸 첫 줄부터 알려줘요.

모달 설명도 이제는 왜(1개 제한), 무엇이(그 공지 이름), 어떻게(자동 해제)까지 담고 있어요. 문장만 놓고 보면 둘 다 톤과 문법은 크게 다르지 않아요.

차이는 '얼마나 매끄럽게 썼나'가 아니라 '이 화면에서 사용자가 꼭 알아야 할걸 짚었나'에서 갈려요. 이렇게 수택이는, 사용자를 귀찮게 하지 않으면서도 '지금 여기서 무슨 말을 해야 하는지'를 먼저 이해하고 라이팅을 할 수 있게 되었어요.

만들 때는 안 보이던 것.

이번에 배운 걸 한 줄로 요약하면 이래요.

좋은 라이팅은 제품에 맞는 표현으로, 상황에 맞는 정보를 주는 것이다.

원칙으로 세운 말투나 용어는 결국 정보를 잘 담아내기 위한 그릇이에요. 이번 개선의 핵심은 좋은 그릇에 어떤 음식을 담아 사용자에게 전달할지, AI가 스스로 질문하고 제안할 수 있도록 설계하는 일이었어요.

이걸 깨닫게 된 건 스킬을 잘 만들어서가 아니라 배포하고 실제로 굴려봤기 때문이에요. '보편적인 라이팅 같다'는 그 한 줄이 없었다면 저희는 계속 컴포넌트 가이드만 늘리고 있었을 거예요. 만들 때는 안 보이던 벽이, 팀원들이 써보고 남긴 흔적에서 보였거든요.

이렇게 수택이는 열심히 크고 있는 중이에요. 스킬도 제품이니까요.

by. 장여주, 프로덕트 엔지니어