제품 팀을 위한 공유 AI glossary 초안 만들기(Draft a shared AI glossary for your product team)

교과서 정의보다 팀 전용 AI glossary가 낫다

AI 어휘는 급격히 늘어났고, 같은 단어가 팀마다 다른 뜻을 갖습니다. "Agent"는 어떤 팀에서는 챗봇이고, 어떤 팀에서는 tool-using LLM이며, 또 다른 팀에서는 workflow orchestrator나 완전 자율 작업 실행기를 뜻합니다. 교과서 정의는 이 혼란을 풀지 못합니다. 각 용어가 당신의 제품에서 구체적으로 무엇을 의미하는지 적은 공유 glossary만이 이를 해결합니다. 이상적인 출력은 신규 입사자가 반드시 읽고, planning conversation이 계속 참조하는 1페이지짜리 artifact입니다.

이 프롬프트의 작동 방식

이 프롬프트는 팀이 planning, spec, customer conversation에서 실제로 쓰는 20-30개 용어에만 범위를 한정합니다. 포괄적인 학술 어휘집이 아니라는 뜻입니다. 각 용어는 세 가지를 갖습니다. 짧은 정의, 우리 제품에서 운영상 어떻게 쓰는지, 그리고 가장 흔한 오용입니다. 신규 입사자가 맞는 mental model과 틀린 mental model을 동시에 익히게 하려는 구조입니다.

용어 범주는 architecture(agent, RAG, fine-tune vs. prompt), quality and evaluation(hallucination, eval, regression), cost and performance(token, latency, cost per outcome), product surface(human-in-the-loop tier, disclosure label)까지 다룹니다. 분기별 review cycle이 있어야, 새 AI surface를 ship하거나 새로운 고객 오해를 만날 때 glossary도 함께 갱신됩니다.

언제 사용할까

• 같은 단어를 두고 planning meeting이 자꾸 멈출 때
• 새 AI 기능 discovery가 시작되는데 팀에 공통 어휘가 없을 때
• 신규 입사자가 팀 전용 AI 용어를 따라잡는 데 몇 주를 쓰고 있을 때
• 마케팅, 지원, 제품 문서에서 AI 용어가 제각각 쓰일 때
• 회사가 AI surface area를 확장하며 공통 운영 언어가 필요할 때

흔한 함정

• 교과서 glossary를 복사하는 것. 교과서 정의는 팀 정의가 아닙니다. "우리가 실제로 어떻게 쓰는가" 열이 핵심입니다.
• Owner 없는 glossary. Owner가 없으면 분기 안에 바로 낡습니다. Product ops가 소유해야 합니다.
• Distribution plan이 없는 것. 아무도 안 읽는 wiki 폴더 안의 glossary는 아무 역할도 못 합니다. Onboarding과 meeting reference에 넣어야 합니다.

참고 자료

• Anthropic Research
• AI Adoption in Product Orgs — Reforge
• The Product Engineer Role — PostHog
• GitHub Developer Research