안녕하세요! AI UX라이터 제민희입니다. 무엇을 도와드릴까요?

이것은 UX라이터와 개발자가 제민희라는 사내 AI 라이팅 툴을 만든 과정에서 마주했던 대다수의 실패와 작은 성취에 대한 기록입니다.

UX라이터라는 직군이 생소한 분도 계실 텐데요. UX라이터는 디지털 프로덕트(앱, 웹사이트 등)와 사용자 간의 상호작용을 돕는 언어 전문가입니다. 단순히 문법적으로 올바른 문장을 쓰는 것을 넘어 사용자가 프로덕트를 이용하는 전 과정에서 혼선 없이 목표를 달성할 수 있도록 직관적인 텍스트를 설계하는 일을 합니다.

하지만 서비스가 고도화될수록 모든 프로덕트 문구 검수를 소수의 UX라이터들이 감당하기에 어려움이 커졌습니다. 각 담당자가 라이팅 문구를 자체적으로 검수할 수 있도록 가이드를 제작하고 전파했지만 이를 위한 교육이 또 다른 부담이 되어 돌아왔어요. 때문에 저희는 라이터의 업무 효율성을 개선하기 위한 프로젝트를 시작하게 되었습니다.

툴 제작으로 업무 효율을 향상시키고자 하는 분들이라면, 이 글을 읽고 저희의 시행착오를 발판 삼아 불필요한 과정을 줄이는 데 도움이 되실 거예요.

참, 툴 이름을 왜 ‘제민희’라고 지었는지 궁금하실 거 같아요. 시스템 프롬프트를 작성할 때 테스트를 위해 AI와 무수히 많은 대화를 주고받다 보니, 사용자들도 이 툴의 성장을 응원하며 동료로서 의지해주길 바라는 마음이 들었어요.

그래서 우아한형제들에 새로 들어온 신입 UX라이터라는 페르소나를 설정하고 가장 사람 이름에 가까운 이름을 붙여줬습니다. 툴에 활용한 모델인 Gemini(제미나이)를 한글 발음으로 읽어보면 ‘제민희’와 소리가 비슷하더라구요.

그럼 본론으로 돌아가서, 프로젝트 이야기를 해볼까요?

시작할 때만 해도 UX라이터와 개발자는 각자의 전문성에 대한 이해가 부족했습니다. 개발자는 ‘라이팅 가이드’의 존재조차도 모르고 있었고 UX라이터의 ‘개발 지식’은 참담한 수준이었죠.

UX라이터가 필요한 기능과 그 이유를 잔뜩 늘어놓으면, 개발자는 그 기능이 정확히 왜 필요한지 이해하기도 전에 기술적 제약부터 설명하기 일쑤였습니다.

여기서부터가 우리만의 솔루션을 찾아가는 고난의 시작이었어요.

➊ ‘진짜’ 문제 정의하기

"라이팅 업무 효율성을 개선할 거예요!"라는 두루뭉술한 이야기 말고요.

서로를 이해하기 위한 첫 단추는 어떤 문제를 해결할지 범위를 구체적으로 정의해보는 것이었습니다. 문제의 실체를 확인하면 기술적 가능과 불가능도 보다 정확히 가늠할 수 있을 테니까요.

실제 UX라이팅 검토 지원 요청 전체를 분석해 봤습니다. ‘가이드 원칙의 일관성 체크’와 ‘의미 전달을 명확히 하기 위한 문구 수정’ 업무 요청이 47.3%에 달하는 걸 확인할 수 있었죠.

이는 곧 전체 요청의 절반 정도는 인간의 부차적인 판단 없이도 라이팅 규칙을 패턴화하여 해결할 수 있다는 의미였습니다. 생각보다 큰 범위죠?

라이터 입장에서는 동일한 문구에 대한 반복적인 검수 비효율을 해소하고, 유관부서 입장에서는 소수 라이터에게 요청이 몰려 발생하는 일정 병목 문제를 해결하기 위해 자동화가 꼭 필요해 보였습니다.

"패턴화 가능한 문구 검수 요청에 대해 가이드에 기반하여 일관성 있는 답변을 전달하는 것"

해결할 라이팅 문제를 명확히 좁히고 나니까 기술적 판단에 있어서도 마찬가지로 ‘답변의 일관성’이라는 기준이 세워졌습니다.

GPT나 Gemini의 커스터마이징 기능을 처음부터 활용하지 않은 것도 이 기준 때문이었는데요. LLM(Large Language Model)은 문장의 뜻을 이해하고 답하는 것이 아니라, 수많은 데이터를 학습한 경험을 바탕으로 지금까지 나온 단어들 다음에 올 가장 높은 ‘확률’의 단어를 한 글자씩 골라 문장을 완성하는 방식으로 말합니다.

즉, 동일한 문장으로 질문 하더라도 매번 다른 답변을 줄 수 있다는 것이며, 이것은 검수 자동화 목적에는 맞지 않아 보였습니다.

그래서 입력값과 데이터가 1:1로 매칭되어 동일한 답변을 보여주는 ‘규칙 기반’의 툴이 문제 해결을 위한 방법으로서 합리적으로 보였어요.

➋ 기술 검증: 3주간의 삽질

규칙 기반 툴이란 듣기엔 간단해 보입니다. 규칙만 잘 정리해 넣으면 원하는 답이 나올 것 같았었기 때문이죠. 하지만 막상 부딪혀보니 라이팅 규칙은 생각보다 훨씬 다양했습니다. 문장부호부터 날짜와 시간, 금액 표기까지, 일반적인 표기 규칙만 정리해도 시트가 빼곡했어요.

규칙을 한번 잘 정리했다고 끝이 아닙니다. 서비스 환경에 맞춰 규칙은 계속 개선되거나 추가됩니다. 즉, UX라이터는 가이드를 계속 바꿔야 하고, 개발자는 그 모든 규칙을 컴퓨터가 알아듣게 옮겨야 한다는 의미입니다. 변경 시마다 어떠한 식으로든 대규모의 리소스를 필요로 하는 복잡한 작업이죠.

"기본적인 맞춤법 검증에, 배민의 정체성이 담긴 UX라이팅 규칙까지 검증하는 로직을 넣어야 했습니다. 이건 너무나 방대한 양일뿐더러, 모든 케이스를 커버할 수도 없었죠."

하지만 개발자는 단순히 코딩만 하는 사람이 아니라, 문제를 해결하려 창의성을 발휘하는 사람입니다. 이 복잡한 문제 앞에서도 포기하지 않고, ‘규칙 기반’ 툴을 구현하려고 기술 검증에 매달렸습니다.

네이버 맞춤법 검사기 같은 상용 도구를 조합하는 방법부터 찾아봤습니다. 비용 산정은 물론이고, 단순 맞춤법이 아닌 배민 고유의 UX라이팅 규칙을 분석해 문장을 수정해 줄 오픈소스 라이브러리도 둘러봤습니다.

결론부터 말하자면, 기존 상용 플랫폼과 오픈소스만으로는 구현이 어려웠습니다.

우선 네이버 맞춤법 검사기 같은 상용 도구들은 단순 맞춤법을 넘어 ‘배민 고유 명칭’이나 ‘상황별 용어’ 같은 복잡한 규칙들을 원하는 대로 적용할 수 없었고, API 연동 비용 또한 낮지 않았습니다.

설령 맞춤법을 잡는다 해도, 배민 고유의 UX라이팅 규칙을 분석해 문장을 바꾸는 건 분명 어려운 일이었습니다. 그래서 네이버 맞춤법 검사기의 맞춤법을 기본으로 하여 카카오의 오픈소스 형태소 분석기 Khaiii(Kakao Hangul Analyzer III)를 활용하여 배민의 규칙을 더하는 방식도 시도해 봤습니다.

Khaiii는 CNN(convolutional neural network) 기반 형태소 분석기입니다. 형태소란, 의미를 가진 가장 작은 말의 단위로서, 직접 문장을 형태소 단위로 나눠서 규칙으로 나열하는 방식입니다.

만들고자 했던 규칙기반 툴에서는 문장을 형태소분석한 결과 기준으로 다시 배민 맞춤법으로 교정해주게 할수만 있다면 최선의 선택이라 생각하였습니다.

CNN이란? 합성곱 신경망으로도 불리는 딥러닝의 핵심 모델 중 하나로, 특히 이미지/영상 분석에 강력한 성능을 보이는 인공 신경망입니다. Khaiii는 CNN으로 한국어 문장의 문맥적 특징을 추출해 더 정확한 문장 분석을 했다고 합니다.

이 설계만 놓고 보면, ‘배민 UX라이팅 가이드’를 네이버와 카카오라는 두 거대한 기둥 위에 얹어 꽤 근사한 결과물을 만들 것 같았습니다.

출처: AI생성 이미지, ChatGPT(DALL·E)

하지만 이 원대한 계획도 결국 삽질이 됐습니다. 개발자에게 익숙지 않은 개발 환경은 차치하더라도, 비싼 맞춤법 검사기와 방대한 학습 데이터가 필요한 문장 분석기는 개발자의 전의를 꺾기에 충분했습니다.

가장 핵심적인 이유는 khaiii를 개발한 카카오브레인이 GPT와 같은 트랜스포머 아키텍쳐가 주류가 되는 패러다임 변화를 겪으며 공식적으로 개발 및 지원을 중단했기 때문입니다. (후속 모델이었던 Pororo도 현재는 Archive 상태) 단순히 지원을 중단한것 뿐 아니라, CNN 모델을 수정하여 원하는대로 사용할 수 있도록 하는 작업 자체가 매우 어려웠기 때문입니다.

공개된 정보만 보고 오픈소스니까 좀 더 쉽게 적용할 수 있겠다는 안일한 생각과 유료 외부 라이브러리면 비용을 지불해서라도 해결하면 되겠다는 가벼운 판단과는 달리, 저희는 오랜 시도 끝에 역량의 부족함을 느꼈고 이 방법을 활용하기는 어렵다고 인정할 수 밖에 없었습니다.

➌ 방향 전환: RAG(Retrieval-Augmented Generation)와 AI를 위한 가이드 번역

규칙 기반 툴이 실패로 돌아가고, 원점에서 다시 고민이 시작됐습니다. 어떻게 하면 가이드 추가/개선 적용의 편의성과 답변의 일관성을 동시에 잡을 수 있을까?

대안을 탐색하던 중, 프롬프트 엔지니어 강수진님의 『프롬프트 엔지니어의 업무일지』라는 책을 보게 되었는데요. 테스트 규칙 중 프롬프트는 최소 열 번 이상 생성한다, 그리고 이렇게 반복적으로 생성한 결과의 일관성을 검사한다. 라는 대목을 보고 문득 100%라는 강박이 발목을 잡았다는 생각이 들었습니다. 지향점이 100%가 아닌 99.999%라면, 개선을 목적으로 노력하면 되는 것이지 일관성 때문에 AI를 배제할 이유는 없었으니까요.

일관성 ‘보장’에서 답변 ‘확률’을 높이는 방향으로 선회하니, 검색 증강 생성(RAG)이라는 방법이 눈에 들어왔습니다. AI의 자체 판단(웹 크롤링)에 기댈 때 생기는 변수 대신, 참고 자료에 제약을 두어 경우의 수를 좁히는 방법입니다.

RAG라는 이름은 뭔가 어려워 보이지만, 원리는 간단합니다. AI에게 오픈북 테스트를 보게 하는 거죠. ChatGPT 같은 AI는 교과서만 외운 학생처럼 최신 정보에 어둡거나 그럴듯한 거짓말을 할 때가 많은데, RAG는 AI가 스스로 답을 지어내기 전에 먼저 ‘검색’을 통해 가이드라인 같은 ‘참고 자료’를 찾아보게 만듭니다. 그리고 이 ‘검색된 근거 자료’를 바탕으로 답을 ‘생성’하도록 유도하죠.

이 방식은 AI가 허언 대신 실제 데이터를 기반으로 답하게 만드니, 저희의 목적에 완벽해 보였습니다. 하지만 문제가 하나 있었습니다. 참고 자료가 될 기존 라이팅 가이드가 철저히 ‘사람 중심’으로 구성되어 있다는 점이었죠. 예시 이미지와 원칙을 복합적으로 해석해야만 이해할 수 있는 구조였습니다.

이때부터 UX라이터의 역할이 중요해졌습니다. 사람 친화적 문구에서 AI 친화적 문구까지, 업무 범위가 확장되는 순간이었죠. 오직 사람의 이해를 목적으로 이미지와 혼합된 형태의 가이드를 LLM이 명확히 이해할 수 있게 ‘텍스트’ 만으로 설명하는 고된 과정이 필요했습니다. 예를 들면 이런 겁니다.

[AS-IS] 사람 중심 가이드

‘만원의 행복’이란 문구가 적용된 광고 배너 이미지 + 단, 마케팅 문구 등 관용적으로 굳어진 표현에는 1을 생략할 수 있어요.

[TO-BE] AI 중심 가이드

광고 배너, 프로모션 페이지에 적용되는 마케팅 문구 작성 시, ‘1만원’, ‘1천원’, ‘1백원’처럼 단위 앞에 숫자 ‘1’이 붙는 경우, 이를 생략하고 ‘만원’, ‘천원’, ‘백원’으로 표기할 수 있습니다.

어때요. 차이가 명확하죠?

➍ 컨텍스트 설계: AI를 위한 작업 규칙

규칙 기반으로 설계된 데이터가 완성됐다면, 이것을 활용한 사용법도 따로 알려줘야 했어요. AI가 따라야 할 명확한 ‘작업 규칙’을 설계하기로 했습니다. 나중에야 이걸 ‘컨텍스트 엔지니어링’이라 부른다는 걸 알았죠.

‘컨텍스트 엔지니어링’이란 단순 프롬프트 작성을 넘어, AI가 우리의 의도대로 생각하고 답하도록 ‘정보 환경’과 ‘사고 과정’ 전체를 설계하는 일입니다. 저희는 이 과정에서 네 가지 핵심 요소를 담은 시스템 프롬프트를 구성했습니다.

1. 작업 순서 정의

AI의 요청 처리 워크플로(Workflow)를 명확히 했습니다.

디자이너, PM, 개발자의 검토 요청을 받으면 다음 순서로 작업을 수행합니다.

요청 문구 구조 분석 → 목적에 따른 필수 정보 확인 → 작성 위치 확인 → 가이드 일관성 확인 → 간결성 고려 → 수정안 도출 → 근거 제시

2. 가이드 기반 의사결정

가이드 기반의 의사 결정 AI가 "제 생각엔 이것이 더 자연스럽습니다"와 같은 주관적 판단을 내리지 못하도록 차단했습니다. 모든 수정안은 ‘라이팅 가이드’나 ‘과거 검토 사례’에 근거해야 합니다. 또한, 답변 시 어떤 가이드를 근거로 판단했는지 ‘수정 근거’ 항목에 명시하도록 했습니다.

• 문구에 포함된 단어가 유명사, 합성어, 반복노출 단어에 해당하는지 확인합니다.
• ‘Case Studies’에서 현재 요청과 유사한 케이스가 있는지 확인하고, 있다면 수정 근거를 참고합니다.

3. 명확한 예외 처리

AI가 모르는 내용에 대해 그럴듯하게 거짓말(hallucination)하는 것을 막도록 해야합니다. 가이드에 없는 요청은 임의로 답하지 않고, "해당 내용은 가이드에 정의되지 않습니다. 담당 시니어 라이터에게 문의해 주세요."처럼 정해진 경로로 안내하도록 설계했습니다.

4. 일관된 답변 포맷

사용자가 동일한 경험을 하도록 답변 형식을 통일했습니다. AS-IS(입력 문구), TO-BE(수정 문구), 수정 근거 등 명확히 구분된 서식으로만 답을 줍니다. 이렇게 내용을 확실하게 알 수 있도록 함으로써 사용자가 답변의 신뢰도를 즉각 인지할 수 있습니다.

• 답변 생성: 검토 결과를 아래 에 맞춰 명확하게 구분하여 제공합니다.
• 예외 처리: 만약 요청 사항이 ‘Guide’에 명시적으로 언급되지 않았다면, 임의로 판단하지 않습니다. 해당 내용을 명확히 고지하고, 시니어 UX라이터 장민우님, 유다정님께 슬랙 채널로 문의하시도록 안내합니다.

이 설계를 고민하며, 어느덧 습관처럼 하던 라이팅 검토 업무를 ‘인수분해’하듯 세분화해보니, 그 과정 자체가 제민희의 컨텍스트를 설정하는 데 큰 도움이 되었습니다.

➎ 구현과 개선: 각자의 전문성

프롬프트 개선과 RAG로 AI 시스템의 뼈대를 마련한 뒤, 제민희 프로젝트는 비로소 ‘구현’과 ‘개선’ 단계로 나아갔습니다.

여기서부터는 개발자와 UX라이터가 각자의 전문성을 바탕으로 LLM 선정, 컨텍스트 설계, 모델 품질 결정에 이르기까지, ‘기술 최적화’와 ‘사용자 경험 최적화’라는 두 축을 조율하며 균형을 찾는 과정이었어요.

가장 먼저 툴에 쓸 AI 모델 선정부터 논의했습니다. 수많은 LLM 중 우리 상황에 맞는 모델을 찾아야 했죠. 사내에서 쓰던 Gemini와 사용자가 많은 ChatGPT를 최종 후보로 올렸습니다. 최종 결정을 위한 기준은 아래와 같았습니다.

1. 한국어 이해도
2. 응답 속도
3. 멀티모달 지원 여부
4. 논리적 추론 능력

멀티모달: 텍스트(글)뿐만 아니라 이미지, 음성, 영상 등 여러 종류의 정보를 동시에 이해하고 처리하는 기술

결국 저희의 선택은 Gemini로 기울었습니다. Gemini는 처음부터 추론을 기준으로 ‘설계’된 모델이며, 멀티모달 환경처럼 토큰 사용량이 많은 곳에서도 강점을 보였습니다. 이 ‘추론’이 중요한 이유는, 복잡한 작업에서 AI가 흔들리더라도 결국 원하는 결과값을 내도록 방향을 잡아주기 때문입니다. 덕분에 제민희가 명확한 ‘수정 근거’를 제시할 수 있게 되는 것이죠. 또한 커다란 컨텍스트 유지가 가능하다는 점은, 이미지를 통한 문구 제안, 피그마 연동 등 장기적인 확장성까지 고려할 때 최선의 선택이었습니다.

앞선 과정에서 시간을 많이 썼기에, 빠르고 간결한 PoC(Proof of Concept, 개념 증명)가 필요했습니다. 하지만 챗봇의 본질을 구현하기 위해 기술적, 기능적으로 챙길 것이 너무 많았죠.

PoC: 빠르게, 프로토타입을 제작하여 프로덕트가 실제로 가능함을 증명하는 과정

위의 내용에서 RAG를 언급하였는데, "RAG를 구현할 때 보통 Vector DB를 많이 사용합니다. 하지만 저희는 서버 비용 없는 빠른 PoC를 목표로 했기 때문에, Vector DB를 도입하는 대신 RAG의 핵심 개념에 집중했습니다.

즉, UX 라이터가 직접 관리하는 가이드(지식)를 시스템 프롬프트로 저장하고, 필요한 지식을 그대로 프롬프트에 ‘검색 증강’ 하는 방식으로 RAG를 구현했습니다. 이는 가장 단순하지만, 우리의 목표에는 가장 효과적인 방식이었습니다.

일반적으로 RAG 라 함은 Vector DB를 활용한 매칭을 먼저 떠올리 실 것 같습니다. 하지만 RAG의 본질은 검색’을 통해 ‘보강’하여 ‘생성’한다는 개념 그 자체이며, Vector DB는 이 ‘검색’ 단계를 효율적으로 하기 위한 수많은 ‘도구’ 중 하나일 뿐입니다.

제민희에는 위 내용처럼 자연어 텍스트를 활용한 컨텍스트 구체화를 활용하였는데, 이 부분 또한 온전히 RAG의 개념에 부합하게 됩니다. AI툴을 만들고 싶은데 RAG를 구성하는 것도 어렵다 라고 생각하며 걱정부터 하고 계시다면 저희 처럼 간단하게 먼저 시작 해보시길 권해드리고 싶습니다.

RAG가 구성 되었다면, 컨텍스트 유지’를 위해, 서버 없이도 대화 맥락을 기억하도록 브라우저 ‘미니 DB’인 ‘IndexedDB’ 기술을 제안했습니다. 브라우저 자체에 데이터를 저장하고 필요할 때 꺼내 쓰는 방식이었죠. 동시에, 컨텍스트가 무한정 늘어나는 것을 막고자 토큰 수가 일정 범위를 넘으면 내용을 축약하는 기능도 넣었습니다. 사용자의 예상 흐름을 고려해, 툴의 본래 용도에 맞게 일정 수준의 대화만 유지하도록 한 것입니다.

RAG에 이어서 토큰이 왜 중요한지 모르는 분을 위해 비유를 하자면 토큰은 게임에서 MP, 마나와 같은 역할을 합니다, AI에게 질문(Prompt)을 하거나 답변을 받는 것은 ‘마법 스킬’을 쓰는 것과 같은데, 이때 캐릭터마다 한 번에 쓸 수 있는 ‘최대 마나량’이 정해져 있듯, AI도 한 번에 기억할 수 있는 ‘최대 토큰량’이 정해져 있습니다. 이 한계를 "컨텍스트 창(Context Window)" 이라고 부릅니다.

예를 들어, 최대 토큰이 4,000인 모델에게 5,000 토큰 분량의 글을 주면, 앞의 1,000 토큰은 ‘기억하지 못하고’ 처리합니다. (마나가 모자라서 스킬이 안 나가는 것과 비슷합니다.)

출처: 메이플스토리, 2차 창작

이렇게 기술 자문을 통해, 개발자가 기술 뼈대를 세우는 동안, UX라이터는 제민희의 본질이라 할 수 있는 ‘시스템의 언어’를 고민했습니다. AI가 단순히 답하는 것을 넘어, 사용자의 의도를 파악해 제대로 된 답을 주도록 만드는 일이었죠.

이를 위해 UX라이터는 LLM UX라이팅 질문/답변 사례를 리서치해 대화 패턴을 분석했습니다. 그리고 사용자가 핵심 정보를 놓쳤을 때, AI가 역으로 질문해 정보를 얻어내도록 프롬프트를 설계했어요. 이를 위해 UX라이터는 먼저 사용자들의 LLM을 통한 UX라이팅 질문과 답변 사례들을 리서치하며 대화 패턴을 분석하는 것에서부터 시작했습니다.

1. 누락된 정보(컨텍스트)에 대한 역질문

가장 빈번한 문제는 사용자가 텍스트가 쓰일 위치(타이틀, 디스크립션 등)를 명시하지 않는 경우였습니다. 이 정보가 없으면 AI는 추측에 의존할 수밖에 없죠. 이를 막기 위해, 핵심 컨텍스트가 누락되면 AI가 준비된 스크립트로 역질문하도록 했습니다.

"해당 텍스트가 어느 UI 컴포넌트(예: 토스트, 버튼 / 타이틀, 디스크립션 등)에 노출될 예정인지 알려주실 수 있을까요? 각 영역에 맞는 라이팅 가이드를 적용하여 더 정확한 제안을 드릴 수 있습니다."

이는 ‘작성 위치’라는 핵심 맥락을 AI가 능동적으로 확보해 영역별 가이드에 맞는 정확한 답변을 유도하는 장치였습니다.

2. 입력 편의성을 위한 UX 설계

또한, 입력 편의성도 고려했습니다. 사용자가 ‘제목’이나 ‘본문’처럼 자신에게 익숙한 단어를 써도, AI가 이를 ‘타이틀’, ‘디스크립션’ 같은 시스템 용어로 자동 변환해 이해하도록 프롬프트를 구성한 것이죠.

실제로 같은 프로젝트를 진행하더라도, 각 직군별로 부르는 용어가 다른 경우가 종종 있고, 이를 전부 파악하기는 너무나 어려웠습니다. 하지만 이를 데이터화해, 사용자는 정확한 가이드 용어를 몰라도 편하게 질문할 수 있고, AI는 매칭되는 표준화된 용어를 기반으로 정확한 결과물을 제공할 수 있습니다.

더 다양한 사용 패턴이 수집될수록, 더 많은 컨텍스트를 가지고 사용자에게 다가갈 수 있기 때문에, 사용자의 언어를 시스템의 언어로 매끄럽게 잇는 UX 설계 고도화가 이뤄지리라 기대하고 있습니다.

➏ 작은 성취, 그리고 계속될 여정

수많은 삽질과 방향 전환을 거쳐, 마침내 개발자와 UX라이터의 공통 언어로 빚어진 ‘제민희’가 세상에 나오게 되었습니다. 물론 ‘신입 UX라이터’라는 페르소나처럼 아직은 배우고 개선해야 할 점이 많습니다.

이 프로젝트의 가장 큰 성과는 단순히 툴 하나를 완성했다는 것보다, 서로 다른 전문성을 가진 직군이 만나 ‘진짜 문제’를 해결하기 위해 서로의 언어를 치열하게 배웠다는 데 있습니다. 개발자는 ‘왜’ 이 기능이 필요한지 공감하게 되었고, UX라이터는 ‘어떻게’ 이 기능이 기술적으로 구현되는지 이해하게 되었습니다. 제민희는 바로 이 공통의 이해를 바탕으로 탄생한 작은 성취입니다.

앞으로 제민희는 더 많은 사용자 피드백과 데이터를 만나며 성장할 것입니다. 단순히 반복적인 검수 비효율을 해결하는 것을 넘어, 사용자의 의도를 더 깊이 파악하고 창의적인 라이팅을 돕는 든든한 ‘동료’로 자리매김하는 것이 다음 목표입니다.

AI UX라이터 제민희가 모두의 성장을 돕는 ‘시니어 라이터’가 되는 그날까지, 저희의 여정은 계속될 것입니다. 많은 응원 부탁드려요!