안녕하세요. 서초동에 서식 중인 시오입니다. 11호에서 클로드코드로 UX라이팅봇 스킬을 만들었던 이야기를 드렸지요. 그 이후로도 라이팅봇을 계속 운영하며 이런저런 테스트 경험을 쌓아갔어요. 그동안 쌓은 케이스들을 분석해 원칙 문서를 업데이트하고, 스킬 구조 문서도 개선해 나갔답니다.
그런데, 시간이 지나면서 조금 묘한 패턴이 보였습니다.
1. AI UX라이터: 모르겠고 내 맘대로 할게
어떤 문제였냐면, 라우팅은 정확한데 어딘가 의도를 빗겨나간 결과물들이 나온다는 느낌이 들었어요.
예를 들어 인증모듈에서 발생한 에러 팝업 문구를 요청하면 index.md를 타고 팝업 규칙 문서를 찾아 들어갑니다. 그런데 결과물에는 그 문서의 원칙이 절반쯤만 반영돼 있는 거죠.
그리고 스킬 정의 가장 앞에 "반드시 보이스 & 톤 배리에이션 가이드를 반드시 읽어라"고 명시했는데요. 분명 해당 문서를 읽긴 한 것 같은데, 결과물을 보면 제대로 적용을 안 한 것 같은 느낌이 들더라고요.
그래서 가만히 라이팅봇이 뱉어낸 결과물들을 살펴 봤고, 제가 찾은 발견점은 다음과 같았습니다.
- 용어사전, 맞춤법, 띄어쓰기 규칙은 거의 완벽하게 지킨다.
- 반면 '고객 친화적인' 접근이 필요한 문구는 캐치를 잘 못 한다.
처음엔 모델 또는 스킬의 구조가 원인인가 생각했는데, 결국 제가 내린 결론은 AI가 참고하는 라이팅 가이드 문서가 문제라는 것이었어요. 라이팅봇 스킬의 성능을 올리기 위해 전면적인 개편이 필요하다는 생각을 했고, 방향을 잡기 위해 AI가 문서를 어떻게 "읽는지"부터 찾아봤습니다.
2. AI는 어떻게 문서를 읽을까?
이런 저런 꿀팁들을 찾아 헤매면서 앤트로픽 공식 블로그의 글들을 많이 찾아봤어요. 결론부터 말하면, 저희 팀은 라이팅봇을 '신입사원'처럼 다뤘지만, 사실 AI는 옆자리 동료보다는 시간에 쫓기는 오픈북 시험 수험생에 가깝다고 해요. 책을 이해하며 읽는 게 아니라 답을 찾으러 펼쳐서 훑는 것이죠.
목차에서 관련 항목을 못 찾으면 넘어가고, 펼친 페이지에 적힌 것만 보고, 적힌 그대로만 답안지에 옮기는 식으로요. 자연스러운 흐름, 완곡한 표현, 친절한 배경 설명같은 '사람이 읽기 좋은 문서'의 하나하나가 AI 독자에게는 되려 감점 요인이 되는 거예요. 조금 더 자세히 살펴볼게요.
첫째, AI는 문서에 적힌 내용을 기억하지 않아요.
신입사원은 온보딩 문서를 한 번 읽으면 취지를 내면화하고, 다음부터는 문서 없이도 응용해서 현실에 적용합니다. 이와 달리 AI는 부를 때마다 매번 첫 출근하는 것에 가까워요. 어제 백 번 참조한 문서도 오늘 요청에서는 처음 보는 것처럼요. Anthropic이 에이전트용 도구 문서를 쓰는 가이드에서 권하는 기준을 보면 이러한 점이 잘 설명되어 있어요.
"how you would describe your tool to a new hire on your team".
새로 합류한 팀원에게 설명하듯 쓰라는 것인데요. 매번 그 자리에서 지침들을 새롭게 보고, 즉시 써먹을 수 있어야 합니다. 그래서 더더욱 인덱스가 중요한 것 같아요. 뭐가 필요할 땐 어디를 찾아가세요- 하는 식으로 설명해야 길을 잃거나 자기 멋대로 일하지 않을테니까요.
둘째, AI는 문서를 통째로 소화하지 못해요.
AI가 한 번에 처리할 수 있는 정보량, 그리고 그 안에서 발휘되는 주의력에는 한계가 있다고 해요. 문서가 길어질수록 개별 문장에 쏟는 주의력은 얕아지고, 특히 긴 문서의 중간 내용은 앞뒤에 비해 흐릿하게 처리되는 경향이 확인돼 있어요(Lost in the Middle이라는 이름이 붙은 현상).
그래서 Anthropic의 컨텍스트 엔지니어링 가이드는 AI에게 좋은 입력의 조건을 이렇게 정의합니다.
"the smallest possible set of high-signal tokens"
여기서 말하는 최소 집합이 곧 짧은 문서를 뜻하지는 않아요. 핵심은 결과에 영향 없는 문장(배경 설명, 분위기용 서술)입니다. 그러니까 "짧은 문서"가 아니라 "군더더기 없는 문서"를 목표로 하라는 뜻에 가까워요.
하지만 인간의 입장에서 처음부터 군더더기가 없는, 명료한 조건을 제시하는 일은 정말 어려운 일이에요. 그래서 앤트로픽에서는 처음부터 완벽한 문서를 쓰려 하지 말고, 일단 최소 버전으로 돌려보고 → 봇이 틀리는 지점을 발견하면 → 그 실패를 막는 규칙과 예시를 그때 추가하는 식으로 키워가라고 제안합니다. 규칙을 상상해서 미리 쓰는 게 아니라 실제 성공/실패 경험을 기반으로 뽑아내라는 것이죠.
셋째, AI는 행간을 맥락으로 채우지 못하고, 지시가 많아지면 오히려 놓칠 수 있습니다.
사람 동료는 "사용자를 배려하는 어조로"라는 문장을 읽으면 조직 생활의 맥락으로 그 뜻을 채워 넣습니다. 그리고 경험이 계속 누적되니 갈수록 쉬워질 거예요.
반면 AI한테는 그 맥락이 없어서, "적절히", "자연스럽게", "지나치지 않게"를 읽으면 평균에 가까운, 무난한 기본값으로 빈칸을 채웁니다. 우리가 의도했던 섬세한 맥락을 고려하지 않는 거죠.
구글에서 크롬과 AI 개발자 경험을 이끌어온 Addy Osmani가 AI 에이전트를 위한 스펙 작성 가이드에 보면 이런 말이 나와요.
"Vague prompts mean wrong results"
모호한 지시는 잘못된 결과를 뜻한다는 뜻인데요. 그렇다고 해서 지시를 수십 개 쌓아 올리면 AI가 앞의 몇 개만 따르고 나머지를 흘리기 시작한대요. 스타일을 보여주는 실제 예시 한 조각이 그걸 설명하는 세 문단보다 낫다고 합니다.
여기까지 내용을 토대로 정리해 보면 - 사람은 문서를 읽지만, AI는 문서를 청크 단위로 소비 또는 참조한다는 결론이 나와요. 우리가 다루는 것은 감성, 문장력, 메시지의 영역이지만 AI에게 이 작업을 시키려면 오히려 스펙이나 로직에 가깝게 정의해야 하는 것이죠.
3. 그래서 사람이 한 일은
그래서 이렇게 공부한 내용을 토대로, 제가 정리한 내용을 말씀드려 볼게요.
1) "언제 읽어라"를 rules 폴더로 분리하기
예전엔 각 문서가 스스로 용도를 설명하는 구조였어요.그 판단을 하려면 봇이 매번 문서를 다 열어야 하죠. 그래서 로딩 규칙만 담는 매니페스트를 만들었어요. 구조로 치면 아래와 같아요.

2) 문서 첫 줄을 한 줄 명사구로 통일하기
docs 10개의 인트로를 고정 포맷 명사구로 통일했어요.
| AS-IS | "…의 정의. 검수 시 어떤 톤을 적용할지 결정할 때 참조" (내용 + 용도) |
| TO-BE | "브랜드보이스(key voice 3원칙)와 상황별 톤 스펙트럼" (내용 색인만) |
용도 설명을 뺀 게 핵심인데요. "언제"는 이제 manifest 담당이라, 인트로에 남으면 같은 정보를 두 곳이 다르게 말하는 요인이 될 수 있어요. 그래서 원칙 md파일의 첫 줄은 "이 안에 무엇이 들어있는지 알려주는 AI용 색인 카드" 역할만 수행합니다. 포맷이 균일해지니 매칭 정확도가 상대적으로 올라가더라고요.
3) vibe를 명확한 조건문으로 변경하기
느낌적인 느낌을 아주 구체적인 조건으로 해석해주는 접근이 필요해요.
- "~가 중요합니다"로 끝나는 문장은 봇한테 지시가 아니라 감상에 가까워요. 오히려 "[목적]하려면 [선행 행동]해 주세요" 같이 조건으로 바꿔주는 것이 AI 입장에서는 더 명확해 진다고 합니다.
- '간결하게' 보다는 '40자 이내', '친절하게' 보다는 '어미를 "해요"체로 통일' 하는 식으로 지침을 구체적으로 만들어주는 것이 좋아요.
- 숫자로 정의하기 어려운 규칙에는 O/X 예시 한 쌍을 붙였습니다. 예시 쌍이 채점 기준표가 돼줍니다.
4) 예외가 있는 규칙은 판단 트리로 만들기
이번에 실제로 좀 더 고도화한 사례인데요. 서비스 레이블을 잡다 보면, 여기서 띄어 쓰는 것이 맞을지 고민되는 순간들이 자주 있어요.
저희 docs 안에는 "서비스 레이블은 붙여 쓴다"는 규칙이 있었어요. 그랬더니 결과는 눈에 보이는 모든 레이블을 다 붙여 쓰는 참사가 발생했습니다. 이 부분을 해결하기 위해, 내 느낌에 띄어쓰는 것이 맞는 것 같은 케이스와 붙여쓰는 게 좋아 보이는 사례들을 모아서 역으로 원칙을 뽑아봤어요. 그랬더니 다음과 같은 판정 트리가 나왔습니다.
예를 들어, "주식모으기"라는 서비스의 레이블을 정리한다고 해볼게요. 이미 앱 내에서 사용하고 있는 용어인 "보유자산", 그리고 새로 추가되는 "모으기 비율"이라는 용어가 있어요.
| 단계 | 판단 | 적용 사례 |
|---|---|---|
| 1단계. 용어집에 등록된 확정 용어인가? | 그 표기 그대로 | - 보유자산은 붙여쓰기 - 모으기 비율은 용어집에 등록되어 있지 않으므로 2번으로 이동 |
| 2단계. 앞말이 ~ㄹ/~ㄴ/~는 관형사구인가? | 띄운다 | - 앞말이 관형사구가 아니므로 3번으로 이동 |
| 3단계. 명사+명사, 4글자 이하인가? | 붙인다 | - 명사 + 명사지만 4글자 초과이므로 4번으로 이동 |
| 4단계. 그 외 | 띄운다 | - 모으기 비율은 띄어쓰기 |
이렇게 해보니, AI용 지침은 단순히 "무엇을 하라"가 아니라 "무엇을 먼저 확인하라"가 있을 때 훨씬 의도한 결과에 가깝게 나온다는 것을 알 수 있었어요.
4. 진짜 나아졌는지 알기 위해 필요한 것, eval
자, 이렇게 고치고 나서 과연 라이팅봇은 성장했을까요?
나아진 부분도 있지만, 솔직히 저는 '보이스&톤'을 잘 지키며 괜찮은 문구를 만들어 내고 있냐는 질문에는 아직 아쉬움이 많다고 대답하고 싶어요. UX나 디자인처럼 감각, 취향이 중요한 영역은 아직 AI가 추상화된 영역을 명확하게 이해해서 수행하기는 어려운 것 같습니다.
그래서 꾸준하게 eval을 진행하는 것이 중요하다고 생각해요. eval은 evaluation의 줄임말인데요. 개념을 제대로 잡고 싶다면 이 영상 을 보시길 추천드려요. 저희는 라이팅봇이 만든 결과물을 아래와 같은 구조로 평가하고 있어요.
- 그동안 모아온 검토 케이스들에서 봇이 내놓은 대답과, 사람이 최종 승인한 문구의 쌍 샘플들
- 왜 봇이 내놓은 대답이 문제인지에 대한 메모 (인간의 관점) + 기존 원칙 ID를 명시
- 반복적으로 등장하는 내용들을 표준화해서 스킬/docs/rules에 반영
기존 원칙 ID를 함께 명시하면, 원래 있는 규칙이 안 지켜진 것이기 때문에 기존 문서를 개선할 것이고, ID가 없으면 새 규칙을 신설할 수 있을 거예요. 다만 모든 것을 규칙화하면 안 돼요. 반복적으로 등장한 패턴만 규칙으로 승격해야 일회성 이벤트가 전체에 영향을 주는 상황을 방지할 수 있어요.
UX라이팅봇을 만든 이후 검수에 들어가는 리소스는 상대적으로 확실히 감소했어요. 대신 이 스킬을 이용할 수록 높아지는 기대치, 쌓이는 경험치에 따라 유지보수하고 개선하는 데에 노력이 보다 필요하다는 것을 느꼈습니다. (세상에 공짜로 얻는 것은 없다는 교훈)
AI가 내 마음대로 움직이지 않는 것 같을 때엔, 2번에서 이야기한 것처럼 공식 문서들을 참고해서 해결 Tip을 얻어보면 좋을 것 같아요. 그리고 그 문서를 읽고 끝내는 것이 아니라, 원리를 응용해 아이디어화해서 내 환경에 반영해보는 경험을 쌓는다면 - 대 AI 시대에 나만의 노하우와 경험을 쌓을 수 있는 좋은 방법이 되지 않을까-하는 생각을 해봅니다 :)
📮 다음 호 예고
[22호] AI 시대, 기획과 디자인의 새로운 문법, Skill
좋은 PM과 디자이너는 왜 늘 비슷한 질문을 하고, 비슷한 순서로 문제를 풀어갈까요?
우리는 그것을 경험이나 감각이라고 불러왔지만, AI 시대에는 그 노하우를 구조화하고 공유하는 일이 점점 더 중요해지고 있습니다.
다음 호에서는 Anthropic의 공식 Skill 가이드와 직접 만들어본 Skill 사례를 통해, Skill이 왜 단순한 프롬프트가 아니라 새로운 업무 자산이자 일하는 방식의 문법이 될 수 있는지 이야기해보겠습니다.
✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.

의견을 남겨주세요