답답해서 바이브코딩으로 ‘UX 라이팅 툴’ 만든 썰
AI 시대, UX 라이터 생존기 ③ 피그마 플러그인 개발기
구글 검색 선호 매체로 추가※ 본 [AI 시대, UX 라이터 생존기] 시리즈는 현직 UX 라이터인 글쓰는개미핥기님과의 협업으로 작성된 콘텐츠입니다. 원문은 하단 브런치스토리 링크에서 확인하실 수 있습니다.
얼어붙은 UX 라이팅 시장, 진화의 과도기 왔다
AI 시대, UX 라이터 생존기 ① UX 라이팅과 채용 시장
AI 시대 UX 라이터, ‘작성자’에서 ‘조율자’로 전환해야
AI 시대, UX 라이터 생존기 ② UX 라이터의 역할 전환
그동안 UX 라이터로서 가장 답답했던 순간은 ‘내 도구’가 없다는 것이었어요. 아무리 좋은 문구 아이디어가 있어도, 개발자가 구현해 준 화면과 디자이너가 그려준 와이어프레임 안에서만 상상해야 했으니까요. 저에게 ‘구현’이란 늘 기획서를 받아보고 빈칸을 채우는, 철저히 수동적인 영역이었죠.
불과 1년 전만 해도 UX 라이터인 저의 하루는 ‘단어와의 싸움’이었어요. 사용자의 이탈을 막기 위해 조사를 고치고, 브랜드 톤을 맞추기 위해 수십 개의 레퍼런스를 뒤지는 장인 정신이 곧 경쟁력이었죠. 당시 저에게 ‘시스템’이란 개발자가 만들어둔 틀 안에서 텍스트를 채워 넣는 공간에 불과했습니다.
하지만 생성형 AI의 파도가 덮친 지금, 저는 더 이상 ‘문구만 고민하기’에 머무를 수 없음을 직감했어요. “이 문구는 AI가 3초면 쓰는데, 당신의 역할은 무엇인가요?”라는 무언의 압박을 받았죠. 이에 저는 쓴다는 생각을 내려놓고 ‘바이브코딩(Vibe Coding)’이라는 새로운 도구를 집어 들었죠. 글을 직접 쓰는 대신, 우리 회사의 문법을 이해하는 ‘AI 동료’를 직접 설계하기로 결심한 거예요.
데이터 보안이란 현실적인 비즈니스 문제
그렇게 나만의 AI 동료가 될 피그마 플러그인 개발을 시작하자마자 마주한 첫 번째 장벽은 코딩 난이도가 아닌, 바로 ‘데이터 보안’이라는 현실적인 비즈니스 문제였어요. 아무리 뛰어난 AI 툴이라도, 사용자의 입력 데이터가 외부 서버로 전송되는 구조라면 금융권이나 대기업에서는 도입 자체가 불가능하다는 것을 깨달았거든요. 어떻게 보면 B2B 시장에서 UX 라이팅 툴의 본질은 ‘글솜씨’가 아니라 ‘안전함’에 있었던 거죠.
보통의 개발자라면 “그럼 보안이 되는 로컬 모델만 쓰자”고 했을지도 몰라요. 하지만 저는 UX 라이터의 관점에서 다시 질문을 던졌습니다. “스타트업은 속도가 중요하고, 대기업은 보안이 중요한데, 왜 하나의 툴에서 두 가지 경험을 다 줄 순 없을까?” 이 질문은 저를 단순한 기능 구현이 아닌 ‘아키텍처 설계’의 영역으로 이끌었습니다.
그리고 이런 UX 라이터 관점에서의 아키텍처 설계 영역에서 고안해 낸 해결책은 바로 ‘하이브리드 엔진(Hybrid Engine)’ 구조였습니다. 사용자가 자신의 환경에 맞춰 ‘퍼블릭 AI(클라우드)’와 ‘사내 서버(Local Host)’ 중 공급자를 선택할 수 있는 스위치를 만든 거죠. 마치 하이브리드 자동차처럼, 상황에 따라 외부 엔진과 내부 엔진을 자유롭게 오가는 유연함을 제품의 핵심 UX로 정의했어요.
글쓰기와 닿아 있는 AI 협업
이후에도 물론 코딩을 배워서 한 줄씩 짠 게 아니에요. 앞서 언급한 보안 아키텍처나 규칙 데이터 내장 같은 ‘제품의 작동 논리’만 설계하고, 실제 코딩은 AI에게 맡기는 방식을 택했죠.
그런데 흥미로운 점은 이렇게 문제를 마주하고 AI와 해결책을 마련하는 과정은 글쓰기와 닮아 있었다는 점이에요. 결국 ‘데이터가 흐르는 길’을 문맥(Context)에 맞게 정리해 주는 일이었죠. 전 보안이 필요 없는 개인 사용자는 자신의 API Key로 즉시 기능을 쓰고, 보안이 생명인 기업 사용자는 인터넷을 끊고도 내부망(Ollama 등)을 통해 안전하게 AI를 굴리는 구조를 만들었습니다.
또한 이렇게 만들어진 AI 동료와의 협업 역시 마치 옆자리 동료에게 내 생각을 설명하는 것과도 비슷했어요. 테스트를 할 때는 “사용자가 버튼을 선택하면, 아까 심어둔 KRDS를 참고해서 3가지 대안을 보여줘”라고 요청하면, AI는 그 의도를 파악해 실행 가능한 코드로 변환해 주거든요. 저는 코드를 타이핑하는 대신, 화면에 구현된 결과물이 내 생각대로 작동하는지 ‘검증’하는 데 집중할 수 있었습니다.
그 결과 저는 기획서의 빈칸만 채우던 입장에서, ‘나만의 프로덕트’를 소유한 메이커로 나아갈 수 있었어요. 요즘은 문서 속에만 박제되어 있던 상상력이, 이제는 제 화면 위에서 실제로 작동하고 반응하는 날이 머지않았음을 느껴요. 복잡한 문법 공부 없이 오직 ‘논리’ 하나로 제품을 만드는 실험인 거죠.
저는 지금도 코딩을 완벽하게 하지는 못해요. 하지만 ‘어떤 구조가 사용자에게 필요한가’를 정의하고, AI와 협업해 그것을 ‘작동하는 현실’로 만들어가고 있어요. 어쩌면 미래의 UX 라이팅은 단어를 고르는 것이 아니라, AI가 뛰어놀 수 있는 가장 안전하고 효율적인 운동장을 설계하는 일일지도 모르겠네요.
UX 라이터와 바이브코딩
그렇지만 제가 만들 툴이 전문적인 상용 소프트웨어처럼 완벽하진 않을 거예요. 그래도 저는 이런 툴과 능력이 최소한 우리 팀에게 필요했던 UX 라이팅의 허점을 없애주고, 업무 속도를 몇 배 높여주는 ‘나만의 무기’가 되어줄 거라 믿어 의심치 않아요. 완벽한 코드를 기대하지 않아요. 그저 조금이나마 ‘작동하는 MVP’를 손에 쥐는 것, 이것이 제가 바이브코딩을 통해 도달하고 싶은 진짜 목표니까요.
결국 AI 시대의 직무 확장은 새로운 기술을 배우는 것보다, ‘내가 가진 아이디어를 구현하는 것’에 있다고 봐요. 코드를 몰라도 논리만 있다면 누구나 자신만의 도구를 만들 수 있는 시대, 저는 지금 제 커리어에서 가장 빠르고 자유로운 실험을 즐기고 있다고 할까요?
바이브 코딩, 진짜 생각 이상으로 재미있어요. 내가 생각한 결과물이 곧바로 나오기 때문에 더욱 그렇고, ‘구현이 어려워’라고 하는 틀을 깨버리기 때문에, 내가 시간을 많이 들일수록 좋은 결과물이 나와요.
전 집안일과 육아를 제외하면 회사 안팎에서 열심히 UX 라이팅을 연구하고 있는데요. 제가 잡은 다음 목표는 UX 라이터로서, 어떻게 해야 UX 라이팅의 표준을 만들어 낼 수 있을지, 나아가 누구나 참고할 수 있는 대안은 무엇일지 등을 직접 구현해 보는 것을 목표로 삼고 있어요.
확장되는 UX 라이터의 영역
이 과정에서 제가 배운 건, 이제 UX 라이터의 영역이 화면 위 텍스트를 넘어 ‘제품의 논리적 구조’까지 확장되어야 한다는 사실이에요. ‘보안’을 기술적 제약이 아니라 ‘사용자가 겪을 경험의 분기점’으로 해석하고 해결책을 제시했을 때, 비로소 이 제품은 단순한 툴이 아니라 현업에서 쓸 수 있는 솔루션이 된다고 파악했거든요.
또 저는 이런 경험이 쌓이면, UX 라이터가 가진 ‘구조적 사고력’이 툴을 만드는 데 엄청난 무기가 될 거라 확신해요. 사용자의 흐름을 읽고 정보 위계를 파악하던 습관은, 그대로 프로그램이 작동하는 알고리즘을 짜는 핵심 역량이 될 테니까요. 이러다 보니 결국 툴을 만드는 건 ‘코딩 기술’이 아니라 ‘문제를 해결하는 논리’로부터 시작할 수 있다는 것을 알게 됐죠.
전 앞으로 “개발 리소스가 없어서 안 돼요”라는 핑계를 대지 않기 위해서, 필요한 도구가 있다면 바이브코딩으로 만든 MVP를 팀원들에게 건네보며, “이건 어때요?”라고 물어보고자 해요. 어쩌면 화면만 바라보던 라이터에서, 문제를 기술적으로 해결하는 ‘프로덕트 메이커(Product Maker)’로 진화하는 과정인 셈이죠.
물론, 제가 ‘A to Z’로 제품의 전체를 설계할 수는 없어요. 다만, 가지고 있는 자원을 활용해, ‘A to Z’라는 도로로 안전하게 이끄는 것, 이것이 저의 중요한 역할이 되는 거죠.
👉 원문 보러 가기: 1) AI와 함께 ‘피그마 플러그인’을 직접 만들다. 2) UX 라이터가 ‘보안 아키텍처’를 고민하는 이유
가이드라인부터 업무 영역까지… 변화 중인 UX 라이팅 시장
와이어링크가 현장에서 목격한 3가지 흐름
뉴스콘텐츠는 저작권법 제7조 규정된 단서조항을 제외한 저작물로서 저작권법의 보호대상입니다. 본 기사를 개인블로그 및 홈페이지, 카페 등에 게재(링크)를 원하시는 분은 반드시 기사의 출처(로고)를 붙여주시기 바랍니다. 영리를 목적으로 하지 않더라도 출처 없이 본 기사를 재편집해 올린 해당 미디어에 대해서는 합법적인 절차(지적재산권법)에 따라 그 책임을 묻게 되며, 이에 따른 불이익은 책임지지 않습니다.
- 에디터김동욱 (jkkims@ditoday.com)
