Writone 개선기 공부 정리 | 도구가 어디에 있어야 하는가

pxd Story에서 Writone 개선기를 읽었다. AI 라이팅 어시스턴트를 만드는 얘기인데, 단순히 “AI로 글을 더 잘 쓰게 해준다”는 방향이 아니라 “이 도구가 실무자의 어디에 있어야 하는가”에 대한 고민이 글 전체를 꿰고 있었다.

처음엔 제품 소개 글인 줄 알았는데, 웹 버전에서 Figma 플러그인으로 전환하는 판단이 나오면서 더 흥미로워졌다. 그 전환에 이유가 있었고, 그 이유가 꽤 UX적이어서 읽으면서 정리해봤다.

1️⃣ 이게 뭐냐?

Writone은 회사의 UX 라이팅 가이드라인을 학습해, 디자이너가 문구를 작성하는 순간 바로 교정 제안을 해주는 도구다. pxd가 내부 실험을 마치고 정식 출시를 준비하면서 방향을 크게 바꿨다.

문제 의식은 이거였다. 기업마다 수백 페이지의 UX 라이팅 가이드라인이 있지만, 실제 업무 중에 여는 사람이 거의 없다. 이유는 단순한데, 확인하려면 Figma를 떠나 PDF를 열고, 맞는 규칙을 찾고, 다시 돌아와야 하기 때문이다. 이 흐름이 끊기는 비용이 너무 커서, 결국 감으로 처리하게 된다는 거다.

Writone이 택한 방향은 그 자리에 있는 것이었다. Figma 안에서 텍스트를 선택하고 버튼 하나를 누르면, AI가 레이어 이름(노드 정보)을 읽어 맥락을 파악하고 규칙을 적용해 제안을 내놓는다. 이 텍스트가 버튼 라벨인지, 에러 메시지인지, 토스트인지를 AI가 이미 알고 시작하는 셈이다.

규칙을 적용하는 방식도 계층화되어 있었다. 용어 → UI 패턴 → 문법 → 원칙 순서로 우선순위를 두는 방식이다. 공부한 내용 기준으로는, 이게 가이드라인 문서의 구조를 그대로 반영한 것 같았다.

2️⃣ 내가 든 생각

읽으면서 제일 먼저 떠오른 건 “왜 웹이 아니라 플러그인이었나”라는 질문이었다. 범용성을 생각하면 웹이 낫지 않냐는 생각이었는데, 글을 따라가다 보니 그 판단 배경이 나왔다.

실무자의 하루를 먼저 들여다봤더니, UX 라이팅 검토가 필요한 순간이 항상 Figma 안에서 생긴다는 걸 알게 됐다는 거다. 문제가 있는 곳에 도구를 갖다 놓은 것이다. 제품 기획 전에 UX리서치를 먼저 한 셈인데, 그 방식이 인상적이었다.

👉🏻 또 하나 눈에 들어온 건 AI가 제안할 때 근거를 함께 보여준다는 점이었다. 왜 이 문구가 맞지 않는지, 어떤 규칙에서 나온 건지를 설명한다. 디자이너가 무비판적으로 따르지 않도록 의도한 거다. “이게 답이다”가 아니라 “이런 이유로 이 방향을 제안한다”는 방식이었다.

💡 여기서 드는 질문? AI가 제안의 이유를 설명할 때와 결과만 보여줄 때, 사용자가 그 제안을 받아들이는 방식이 실제로 달라질까.

⭐️ 마지막으로, 도구의 위치에 대해

정리해보니 이 글에서 남은 건 기능 목록보다 “도구가 어디에 있어야 하는가”라는 물음이었다. 아무리 정교한 AI도 실무 흐름 밖에 놓이면 안 쓰인다. 반대로 조금 덜 정교해도 흐름 안에 있으면 자연스럽게 자리를 잡는다. Writone이 웹에서 Figma 플러그인으로 옮긴 게 결국 그 판단의 결과인 것 같다.

공부 끝에 남은 건 “도구는 기능보다 위치로 결정된다”는 한 줄이었다.

---

참고 원문: AI 라이팅 어시스턴트, Writone 개선기