봇 품질 올리는 방법
안녕하세요, 시오입니다.
오늘은 지금 다니고 있는 회사에서 약 1년여간 저를 끊임없이 괴롭혔던 UX라이팅과의 동고동락했던 기억에 대해 다뤄보려고 해요. 서비스 전반의 사용자경험을 챙기는 저희 조직이 생기면서 받은 첫 업무는 "서비스 전체 문구 검수"였습니다.
UX 라이팅이 무엇인지, 어떤 라이팅이 트렌디하고 좋은 것인지에 대해서 감각적으로 알고 있었지만 그걸 조직의 결과물 안에 체계적으로 녹이는 것은 또 다른 차원의 일이었어요. 그래서 일단은 몸으로 부딪히기 시작했습니다.
초기에는 요청 건별로 Before/After를 작성하고, 수정 근거를 달아서 전달하는 방식으로 대응했습니다. 이렇게 몇 개월간 좌충우돌하면서 느낀 문제는, 바로 판단 기준의 없다는 것이었어요. 어미 선택, 서비스명 표기 방법, 컴포넌트별 문구 구조 등은 개인의 경험에 의존하고 있었고, 조직 차원에서 합의된 원칙은 없었던 거죠. 그리고 원칙을 잡더라도 전파하는 과정이 쉽지 않았습니다 😂
그래서 AI를 활용해 UX라이팅을 효율화하는 방법을 고민했고, 클로드 코드를 CLI 환경에서 사용하면서 해결의 실마리를 찾게 되었어요. 저희 팀에서 AI를 활용해 UX 라이팅봇을 키워온 과정을 소개해 볼게요.
첫번째 할 일: 라이팅 원칙부터 만들자
AI로 라이팅봇을 만들기에 앞서, 지난 몇 개월간 실제 우리 서비스에서 문구가 어떤 상황에 어떻게 쓰이고 있는지 직접 부딪히면서 모은 사례들을 기반으로 정리하는 과정이 있었어요.
케이스가 어느 정도 모이니 반복 판단을 줄이기 위해 먼저 원칙을 문서화할 수 있겠더라고요. 그동안 검토하면서 쌓은 '감'을 토대로, 어느 정도 가시화해나갈 수 있었어요. 외부 자료도 많이 참고하면서 원칙을 잡아나갔습니다. 이 때 참고했던 좋은 자료로는 <그렇게 쓰면 아무도 안 읽습니다>, Config 2025의 <Writing is designing> 등을 추천드려요. 그리고 타사 라이팅 시스템을 참고하는 것도 많은 도움이 됐어요.
먼저 가장 기본 중의 기본! 보이스 앤 톤을 정의했어요.
보이스 앤 톤 - 격식체/해요체, 능동태/수동태 등 서비스 전반의 어조 규칙
보이스 앤 톤을 정의할 때, "우리 서비스는 친절합니다" 같은 한 줄짜리 선언으로는 실무에서 쓸 수 없었습니다. 상황마다 적절한 톤이 다르기 때문인데요. 온보딩에서 쓰는 어조와 출금 실패 에러에서 쓰는 어조가 같을 수는 없으니까요. 그래서 저희는 어도비 사례를 참고해서 스펙트럼으로 톤을 다각화했어요.
| 1단계 - 환영·격려 | 온보딩, 첫 거래 완료, 신규 기능 안내 |
| 2단계 - 친절·상세 | 기능 설명, 도움말, 단계별 가이드 |
| 3단계 - 중립·명확 | 일반 UI 레이블, 설정 화면, 상태 표시 |
| 4단계 - 간결·사실 중심 | 거래 확인, 수수료 안내, 잔액 변동 |
| 5단계 - 절제·경고 | 리스크 고지, 출금 제한 안내, 법적 공지 |
이 스펙트럼이 있으면 AI 라이팅봇에 "이 문구는 4단계로 교정해줘"라고 지시할 수 있게 돼요. "친절하게 써줘" 같은 모호한 지시보다 출력이 안정적이라고 느꼈습니다.
그리고 AI 봇을 운영하면서 알게된 점은, 용어집(glossary)이 라이팅 봇 교정 품질에 미치는 영향이 정말로 크다는 것이에요.
용어집 - 금지어/권장어 매핑, 서비스 고유명사 표기법 등
체감으로는 전체 품질의 70% 정도라고 볼 수 있을 것 같아요. 서비스 명으로 쓰일 때, 문장 안에 쓰일 때, 그리고 비슷한 다른 사례에서 어떻게 쓰였는지 - 거의 컴포넌트 가이드 단위로도 문구를 검토할 수 있었어요. 자세한 내용은 아래에서 더 설명해 볼게요!
두번째 할 일: 클로드 코드(CLI) 세팅하기
제미나이, 챗GPT를 떠나 클로드 코드로 전환한 핵심 이유는 파일 시스템 직접 접근이 가능하다는 점 때문이에요. 챗GPT나 제미나이에서는 라이팅 원칙을 프롬프트 안에 직접 작성해야 했습니다. 반면에 클로드 코드를 CLI 환경에서 사용하게 되면, 원칙을 마크다운 파일로 구조화해두면 봇이 필요할 때 읽어올 수 있어요. 규칙 변경 시 관련 마크다운 파일만 업데이트하면 되는 거죠.
아직 이 방식이 낯선 분들이 계실 텐데요. 클로드코드를 CLI 환경에서 사용하는 방법이 궁금하시다면, 유튜브 채널 <실밸개발자> 의 이 영상을 추천합니다. (생각보다 많이 어렵지 않아요!)
세번째 할 일: UX 라이터의 사고회로를 카피하자
전문적인 UX 라이터의 머릿속은 단순히 '글솜씨' 하나로 채워져 있지 않습니다. 상황에 따른 판단 기준, 브랜드의 말투, 수많은 성공과 실패의 경험이 복합적으로 얽혀 있죠. 이걸 하나의 파일에 다 넣는 것은 라이터의 뇌 전체를 통째로 복제하려는 무모한 시도와 같아요. 그래서 그래서 저희는 이 복잡한 지식을 5가지의 독립된 '사고 영역'으로 분해했어요.
- 페르소나 영역 - 역할 정의
- "나는 누구인가, 어떤 태도로 유저를 대하는가"라는 가장 밑단의 정체성이에요. 봇이 흔들리지 않는 중심을 잡는 곳이죠.
- 원칙 문서 - Docs
- 논리적 판단을 담당하는 '규칙'의 영역입니다. 보이스 앤 톤, 컴포넌트별 공식 같은 공식화된 지식을 저장합니다. "이럴 땐 이렇게 한다"는 명확한 가이드라인이 여기에 해당해요.
- 교정 사례 - Cases
- 실제로 겪었던 '경험'의 데이터베이스입니다. 단순한 규칙만으로는 설명할 수 없는 미묘한 맥락들, 즉 "예전에 이런 상황에서 이렇게 고쳤더니 반응이 좋았지" 하는 실제 판례들을 따로 모아 학습 효율을 높입니다.
- 일별 요약 - Sessions
- 오늘 하루 동안 고민했던 '작업 기억'입니다. 지금 당장 집중하고 있는 문제들을 따로 관리하여 봇이 불필요한 과거 정보에 매몰되지 않고 현재의 맥락에만 집중하게 만듭니다.
- 팀원용 설명서 - Guide
- 외부와 소통하는 '언어'의 영역입니다. 봇이 내부적으로 처리하는 복잡한 로직과 별개로, 동료들이 이 지식 체계에 어떻게 접근하고 활용할지를 정의하는 인터페이스 역할을 합니다.
그래서 UX-writing-Bot이라는 하나의 프로젝트 폴더 하위에는 크게 5개의 서브 폴더가 존재하게 돼요.
위에서 정의했던 보이스 앤 톤, 용어집은 모두 원칙(docs) 문서에 md파일로 들어가 있어요. 그리고 새로운 케이스가 등장할 때마다 cases 폴더에 새로운 md파일을 만들어 사례를 쌓아 나가는 구조입니다. 문제는 케이스가 쌓일 수록 비용이 많이 들어간다는 것이죠! (토큰 사용은 곧 돈...💰)
이를 해결하기 위해서 cases 폴더 안에 index.md 파일을 따로 만들었어요. 새로운 케이스를 쌓을 때마다, 각 요소별로 최소 3개의 태그를 부여하는 구조로 자동화했고요.
그러면 인덱스에는 새로 추가된 케이스의 ID, 태그, 한 줄 요약이 기록돼요.
봇은 인덱스를 먼저 읽은 후 현재 요청받은 맥락과 태그가 매칭되는 케이스만 추가로 찾아서 읽기 때문에 토큰 낭비를 줄일 수 있게 됩니다! 시간도 상대적으로 절약할 수 있고요.
네번째 할 일: 외부와의 연결 - 피그마 MCP, 깃허브 활용
클로드코드 UX라이팅 봇을 협업할 때 사용하려면, 피그마 MCP와 깃허브가 찰떡궁합이에요. 특히 디자인 조직에서 활용한다면 강력하게 추천드려요!
피그마 MCP
UX 라이팅은 보통 디자인 시안이 나온 상태에서 작업하게 되는데요. 피그마 MCP를 클로드코드와 연결하면 이러한 문구 워싱 과정이 한결 편해져요.
- 피그마에서 작업 중이던 파일이나 섹션 링크를 입력하고, 어떤 부분에 대한 UX라이팅을 검토해야 하는지 클로드에게 설명합니다.
- 정의된 규칙 프로세스에 따라, 피그마 파일 내에서 클로드가 원본을 복제 → 원본 옆에 배치 → 이름에 "TOBE" 붙이고 → TOBE에서만 수정 → 바뀐 텍스트는 #FF199B(핑크)로 색을 바꿔서 표시해요.
이렇게 하면 디자이너가 파일을 봤을 때 "아, 봇이 여기를 고쳤구나" 하고 바로 알 수 있어요. 물론 이렇게 봇으로 고친 버전도 사람이 아직은 눈으로 검수를 하는 게 좋아요. 은근히 놓치는 내용들이 많이 있거든요.
깃허브
클로드코드로 동료들과 협업을 하려면 깃헙의 조직 워크스페이스를 연결해 보세요. 보통 개발조직에서 코드/배포 관리를 위해 활용하는 도구인데요. 처음엔 생소하지만 금방 적응할 수 있어요! 특히 조직에서 AI를 같이 활용한다면 꼭 한 번 활용해 보시길 추천드려요. (비개발자를 위한 깃허브 설명 영상)
저희 팀은 공용 워크스페이스에서 다른 조직원들도 이 라이팅봇을 이용할 수 있도록 /skill로 배포했어요.
에이전트보다 스킬이 더 좋았던 이유는 다음과 같아요.
| 스킬 (슬래시 커맨드) | 서브 에이전트 |
| 내 옆에서 바로바로 도와주는 조수 | 옆방에 따로 있는 전문가 |
| 나와 대화하던 맥락을 다 알고 있음 | 작업 결과만 전달해 줌 |
| ✅ "이 말투 어때요?" 주고받기 편함 | ❌ "다 됐습니다" 하고 결과만 툭 던짐 |
- 대화가 끊기지 않아요 라이팅은 한 번에 정답이 나오기 어렵습니다. "이 단어는 좀 딱딱한데?"라고 하면 스킬은 우리가 나누던 대화의 맥락을 그대로 유지하며 바로 수정해 줍니다. 반면 에이전트는 매번 상황을 다시 설명해야 하는 번거로움이 있어요.
- "이거 저장할까요?"라고 물어보는 피드백 루프 작업이 끝날 때 봇이 "오늘 결정된 이 원칙, 우리 가이드북(Case)에 넣을까요?"라고 물어봅니다. 반면에 에이전트는 독립된 방에서 혼자 일하기 때문에 이런 깨알 같은 확인 루프를 만들기가 까다롭습니다.
- 가볍고 빠릅니다 피그마 mcp나 프롬프트 엔지니어링 등을 통해 맥락을 더 쉽고 빠르게 주입할 수 있었어요.
즉, 결과물만 받는 것보다, 대화하면서 같이 고치고 그 과정을 기록하는 게 중요했기 때문에 맥락을 공유하는 스킬 방식을 선택하게 됐어요. 이제는 라이팅봇을 사용하는 팀원들이 다양한 케이스를 주입하면서 훨씬 풍부한 사례를 확보하고 있어요. (협업의 맛!)
물론, 권한 관리를 통해서 봇에 반영할 케이스나 원칙을 정리하는 것도 굉장히 중요해요.
처음엔 팀원 누구나 "이거 기록해줘" 하면 바로 케이스에 넣었어요. 그랬더니 검증 안 된 교정이 판례 풀에 섞이면서 봇 출력이 흔들리기 시작하더라고요. 잘못된 판례를 참고하니 잘못된 교정을 하는 식이었어요. 그래서 여기에도 일종의 하네스(목줄)를 적용했어요. 권한에 따라서 다르게 처리되도록 만든거죠.
- 다른 조직 작업자가 "케이스 기록해줘" 하면 → Pending Cases 테이블에 임시 저장
- 우리 팀 작업자가 기록된 케이스를 확인한 뒤 → 정식 케이스로 생성 + 인덱스 반영 + 세션 요약
이렇게 저희 팀에서 주기적으로 Pending 테이블을 검토해서 승격/삭제 케이스를 관리하고 있어요. 봇의 품질 관리에 있어 중요한 부분이라, 정기적으로 논의해서 결정하고 있답니다.
결론: 리소스 50%가 어디서 줄었냐면
그래서, 이 라이팅봇을 통해 구체적으로 어떤 시간/리소스가 줄었는지 정리해 볼게요.
- 원칙 확인 - 예전엔 "이 문장에서 어미 뭘로 하지?" 하고 가이드 뒤지거나 기억에 의존했는데, 이제 봇이 관련 원칙을 자동으로 불러와서 적용해요.
- 유사 사례 검색 "비슷한 팝업 고친 적 있지 않았나?" 같은 기억 더듬기가 인덱스 매칭으로 바뀌었어요.
- 피그마 반영 피그마 섹션 복사해서 붙여넣고, 고친 사례 다시 피그마에 업데이트 하는 과정이 사라졌어요. 프레임 복제, 텍스트 교체, 색상 마킹까지 한 번에 진행할 수 있답니다.
- 교정 근거 작성 매번 직접 쓰던 걸 봇이 원칙 문서 기반으로 자동 생성해줘요.
물론 여전히 줄어들지 않은 부분도 있어요. 최종 검토와 판단은 여전히 사람 몫이에요. 봇이 제안한 문구가 맥락에 맞는지, 사용자 입장에서 자연스러운지는 꼭 직접 확인해야 해요. 그럼에도, 이렇게 판단하는 과정에만 집중할 수 있는 환경이 된 것 자체가 너무나 중요하고 큰 변화라고 느끼고 있어요.
만약 직접 해보고 싶다면
클로드코드 CLI 환경을 세팅하는 것과 별개로, 알맹이를 먼저 만들어 보는 것을 추천드려요. 결국 AI는 생산성 도구이니까요. 그 안을 어떻게 채울지를 고민하는 것이 더 중요하다고 생각합니다.
제일 먼저 할 건 용어집 만들기예요. 금지어 10개, 권장어 10개, 고정 표기법...이것만 있어도 봇 품질이 확 달라집니다. 용어집이 봇의 70%란 말이 과장이 아니에요.
그 다음은 케이스 5~10개를 손으로 직접 만들기. 봇이 참고할 수 있는 시드가 있어야 초기 출력이 나와요. 원칙만 달랑 주면 맥락 없이 기계적으로 적용해서 결과가 어색할 수 있습니다.
그리고 프롬프트와 지식을 분리하세요. 규칙은 외부 마크다운 파일로 빼고, 프롬프트엔 "어떻게 행동할지"만 추가하세요. 유지보수를 위해 정말 중요한 포인트랍니다.
✅ 내일 바로 해볼 것
- 용어집부터 만들어보세요. 금지어 10개, 권장어 10개. 서비스명 표기, 어미 통일, 자주 틀리는 단어 위주로.
- 교정 사례 3개를 Before/After로 기록해보세요. 바꾼 이유 한 줄씩만 달아도, 그게 나중에 봇 학습 데이터가 됩니다.
- 클로드 코드 설치하고 /커맨드 하나 만들어보세요. 원칙 파일 1개 + 사례 3개 정도면 첫 버전은 돌아갈 거예요!
📮 다음 호 예고
[12호] AI가 디자인을 대신하는 시대, 왜 디자인 시스템이 더 중요해질까?
생성과 변형의 시대, 디자인 시스템이 기준이 되는 이유에 대해 이야기해 볼게요.
✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요. 🙂
의견을 남겨주세요