디자이너가 AI로 워크플로 하나를 설계하는 데 프롬프트를 30~50번 던집니다. 구조와 인터랙션, 컬러 토큰을 다 맞춘 마지막 단계에 가서야 “그런데 이 카드에 뭐라고 쓰지?”가 나오죠.

인튜이트의 콘텐츠 시스템 팀이 사내 AI 디자인 워크플로를 조사하다 발견한 숫자입니다. 이 팀은 잘 만들어둔 콘텐츠 디자인 시스템이 정작 문구가 만들어지는 순간에는 아무 역할도 못 한다는 결론에 도달했죠. 그래서 기준 자체를 Claude 스킬로, 다시 플러그인으로 옮긴 과정을 공개했습니다.

출처: Claude Skills for content design: inside Intuit’s AI build – UX Content Collective

문서로 있는 기준은 적용되지 않는다

문제는 두 방향에서 왔습니다. 업계 전반에서 전담 콘텐츠 디자이너 수가 줄어 대부분의 프로덕트 디자이너에게는 짝이 될 콘텐츠 파트너가 없죠. 동시에 Claude나 Cursor 같은 도구가 디자인 일정을 압축하면서, 엔지니어가 배포 직전에 엣지 케이스 문구를 직접 쓰는 일까지 생겼습니다.

인튜이트에는 이미 잘 정리된 콘텐츠 디자인 시스템이 있었습니다. 그런데 적용이 안 됐어요. 사람들이 “좋은 문구가 무엇인지” 판단하는 법을 몰랐기 때문이죠.

팀이 스스로에게 던진 질문이 이 글의 출발점입니다. 콘텐츠가 실제로 생성되는 층위에 기준이 적용되지 않는다면, 그 기준을 여전히 시스템의 일부라고 부를 수 있을까요.

스킬 여러 개가 아니라 허브 하나

처음엔 스킬마다 각자의 레퍼런스 폴더를 두고 콘텐츠 시스템 문서를 담았습니다. 진실 공급원이 여러 개로 갈라진 셈이죠. 기준이 바뀔 때마다 중복된 파일을 전부 손봐야 한다는 뜻인데, 그건 이 팀이 없애려고 존재하는 종류의 혼란이었습니다.

그래서 구조부터 다시 짰습니다. 공유 레퍼런스를 가진 “허브” 하나를 두고, 거기서 전문 스킬로 자동 라우팅하는 방식이죠. 무엇이 좋은 문구인지에 대한 정의가 한 곳에만 살고 나머지는 그걸 상속받죠. 검색 정확도와 토큰 사용량, 관리 부담이 한꺼번에 정리됐습니다.

여기서 눈여겨볼 대목이 있죠. 팀은 Claude에게 어떤 구조가 좋을지 물어보긴 했지만, 그 추천을 그대로 받아들이지는 않았습니다. 플러그인이 내부에서 어떻게 작동하는지 이해하지 못한 채 고르는 게 불편했거든요. 문서를 읽고 사내 AI 담당자들과 이야기한 다음에야 결정을 내렸죠.

트리거 문구는 디자이너가 쓰는 말로

구조를 정한 뒤에는 기존 스킬들을 사람이 직접 감사했습니다. 겹치는 부분, 어긋나는 부분, 같은 조건을 두고 서로 경쟁하는 스킬을 찾아냈죠.

스킬 설명 문구도 다시 썼습니다. 트리거가 되는 표현이 콘텐츠 디자이너가 자기 일을 설명하는 방식이 아니라, 디자이너가 실제로 쓰는 말과 맞아야 했으니까요. 이 차이를 놓치면 스킬이 있어도 호출되지 않습니다.

가장 지저분했던 건 마지막 패키징이었습니다. 사내 플러그인 제작 가이드가 개발자 독자를 상정하고 쓰여 있어서 읽기가 어려웠고, 개발자가 아닌 팀에게 기술 설정은 그 자체로 위협적이었죠. Claude Code가 과정을 번역해주긴 했지만 전부 대신해주지는 못했습니다.

결국 며칠간의 시행착오와 179번의 커밋, 그리고 개발자 동료들에게 보낸 수많은 슬랙 메시지 끝에 플러그인이 나왔죠. 24시간 만에 사내 AI 마켓플레이스에서 두 번째로 많이 설치된 플러그인이 됐습니다.

플러그인이 없을 때 모델은 통과라고 답했다

효과는 같은 토스트 메시지를 두 조건에서 평가시켜 보면 드러나죠. 플러그인이 꺼진 상태에서 모델은 그 메시지가 모든 콘텐츠 기준을 통과했고 고칠 게 없다고 답했습니다. 틀린 판정이었죠. 플러그인을 켜자 토스트 담당 스킬이 작동하면서 알맞은 레퍼런스를 불러오고, 문제를 짚고, 확인 메시지 가이드라인에 맞는 패턴을 제안했습니다.

팀이 스스로 붙인 단서도 솔직합니다. 이 플러그인이 시스템을 확장해주긴 해도 장인정신까지 확장해주지는 않는다는 것. 그건 여전히 사람 몫이라고 못 박았죠.

같은 교정을 반복하고 있다면

이 사례에서 개인이 가져갈 지점은 조직 규모와 무관하죠. 어떤 판단 기준이 도구 안에 들어가 있지 않으면, 그 자리는 AI의 기본값이 대신 채웁니다. 앞의 토스트 메시지 실험이 정확히 그 장면이었죠.

그러니 같은 종류의 교정을 반복해서 손으로 하고 있다면, 그게 스킬로 굳힐 신호입니다. 기준을 문서에 적어두고 필요할 때 찾아보는 방식은 “내가 항상 그 방에 있다”는 전제 위에 서 있는데, 지금은 아무도 모든 방에 동시에 있을 수 없으니까요.

써보려면

필요한 것: Claude 등 스킬·플러그인을 지원하는 AI 도구. 여러 스킬을 묶어 배포하려면 팀이나 조직 단위의 레지스트리가 있어야 자동 업데이트가 됩니다.

시작 지점: 이미 쓰고 있는 프롬프트 중 반복되는 것을 골라 스킬 하나로 만듭니다. 여러 개가 되면 레퍼런스를 허브 하나로 모으고 거기서 라우팅하는 구조로 바꿉니다.

잘 맞는 상황 / 안 맞는 상황: 판단 기준이 이미 문서로 정리돼 있고 그걸 여러 사람이 일관되게 적용해야 할 때 잘 맞습니다. 반대로 기준 자체가 아직 흔들리는 단계이거나, 품질이 사례별 감각에 크게 기대는 작업이라면 스킬화가 이르죠. 스킬 설명의 트리거 문구를 실제 사용자의 말투에 맞추지 않으면 만들어두고도 호출되지 않는다는 점도 감안해야 합니다.

참고자료:

• Intuit Content Design System – Intuit