생성형 AI를 써도 일이 안 줄어드는 원인은 모델이 아니라 모호한 요청과 없는 팀 기준이다. 문서 품질 차이는 대상·결과물 형태·검수 기준 세 가지에서 가장 많이 난다. 팀에 공통 요청 템플릿과 결과물 품질 체크리스트가 있는지부터 확인하면 된다.
"AI 한번 써보자"는 말이 조직 안에서 흔해진 지 오래다. 원문 2026년 1월 6일에 우리가 적어 둔 대로, 도입 뒤 현장에서 더 자주 듣는 말은 따로 있다. "써보긴 했는데 결과물이 들쭉날쭉해요"가 첫째다. 초안은 나오는데 조직 스타일이 아니라는 말, 잘 쓰는 사람만 잘 쓰고 나머지는 금방 포기한다는 말이 뒤따른다. 마지막 반응은 도입 취지와 정반대다. "팀 표준이 없어서 오히려 재작업이 늘어난 느낌이에요."
우리는 이 반응의 원인을 도구가 아니라 시작 조건에서 찾는다. 요청 방식과 팀 기준이 정리되지 않은 채 도입부터 했기 때문이다. 1분 자가진단 일곱 항목은 보고·기획·메일·회의록 같은 반복 문서 업무가 많은지, AI 결과물 품질이 사람마다 다른지, 어떻게 시켜야 할지 애매해 재작업이 잦은지, 팀장·임원 보고가 많아 톤과 구조 표준화가 필요한지, 평가·채용·교육 시즌에 문서량이 폭증하는지, 보안·규정 때문에 안전한 사용 기준이 필요한지, 도입은 했는데 정착이 안 됐는지다. 세 개 이상이면 교육이 효과를 내기 쉬운 팀이다.
이 일곱 항목 중 모델 성능에 관한 것은 하나도 없다. 전부 요청과 기준에 관한 항목이다.
요청이 모호하면 결과도 모호해진다
우리가 현장에서 원인을 설명할 때 쓰는 한 줄은 "요청이 모호하면, 결과도 모호해집니다"이다. AI가 틀린 것이 아니라 기준을 충분히 주지 못한 경우가 대부분이라는 뜻이다. 흔한 요청과 기준을 붙인 요청을 나란히 놓으면 차이가 보인다.
| 요청 | 모델이 추측으로 채워야 하는 빈칸 |
|---|---|
| "보고서 정리해줘" | 누구 기준인지, 분량, 대상, 결론, 액션 |
| 이번 주 KPI를 임원 보고용 1페이지로. 요약 5줄 → 리스크 3개 → 대응·다음 액션 5개 구조. 숫자는 표, 톤은 딱딱하게 | 없음 |
두 번째 요청에 프롬프트 기법이라 부를 만한 것은 없다. 대상(임원), 형태(1페이지), 구조(5-3-5), 표현 규칙(표·톤)을 적었을 뿐이다. 그런데 같은 도구를 쓰고도 일이 줄어드는 팀과 재작업이 늘어나는 팀은 이 네 줄에서 갈린다. 조건이 빠진 요청을 받은 모델은 빈칸을 추측으로 메우고, 사람은 그 추측을 되돌리는 데 시간을 쓴다. 되돌린 시간의 합이 팀이 체감하는 재작업이다.
성과가 나는 팀은 개인의 센스 대신 팀 표준을 운영한다
갈림길은 개인이 잘 쓰느냐가 아니라 팀이 공통으로 쓰는 틀이 있느냐다. 우리가 팀 표준의 예로 드는 틀은 네 가지다. 팀 공통 요청 템플릿, 대상·목적·톤·구조·분량을 보는 결과물 품질 체크리스트, 팀 문서의 정답 예시를 모은 샘플 라이브러리, 민감정보와 보안 이슈를 피하는 사용 규칙이다.
네 가지 모두 프롬프트 문장이 아니라 문서에 관한 것이다. 문서 품질 차이가 가장 크게 벌어지는 지점으로 우리가 꼽는 세 가지도 같은 성격이다. 읽는 사람이 임원인지 팀장인지 전사 공지인지 외부 고객인지, 결과물이 1페이지인지 메일인지 공지문인지 회의록인지 제도 문서인지, 검수에서 금지 표현·톤·분량·핵심 메시지를 무엇으로 볼지다. 우리 교육이 좋은 프롬프트 쓰는 법보다 팀 문서 기준 정리를 앞에 두는 이유가 여기 있다. 템플릿은 그 기준이 선 뒤에 맞춘다. 툴 사용법 교육이 한 달 뒤 업무 방식을 바꾸지 못하는 관찰은 AX 전환 교육, 어디서부터 시작해야 할까에서 다뤘는데, 그 글의 "확산 기준"이 여기서는 세 줄짜리 문서 기준으로 구체화된다.
에이전트는 팀 문서 기준 위에 세운다
2026년 1월 기준으로 우리가 보는 작업 방식의 변화는 세 단계다. 프롬프트를 잘 써서 실행하는 단계, 프롬프트를 잘 쓰도록 시킨 뒤 그 프롬프트를 실행하는 단계, 그리고 프롬프트를 여러 버전으로 써서 에이전트 봇을 만들고 검수·재작성을 맡는 서브 에이전트나 커스텀 봇까지 붙여 함께 돌리는 단계다.
여기서 순서가 중요하다. 팀 문서를 먼저 정립하고 에이전트는 그 다음에 세운다. 검수 에이전트가 검수하려면 검수 기준이 문서로 있어야 하고, 재작성 에이전트가 고치려면 정답 예시가 있어야 한다. 기준 없이 에이전트부터 만들면 "보고서 정리해줘"를 자동으로 반복하는 장치가 된다. 우리 교육이 끝난 뒤 조직에 남기는 산출물이 업무 템플릿 세트, 보고·기획·메일 공통 구조, 요청을 명확하게 만드는 질문 리스트, 실제 문서의 Before/After 예시인 것도 같은 맥락이다. 이 산출물이 에이전트의 입력이 된다.
가져갈 것
팀에서 가장 자주 나가는 문서 하나를 골라 아래 빈칸을 채우고, 팀 공통 요청 템플릿의 첫 항목으로 올린다. 위 세 갈림길과 KPI 보고 예시에서 뽑았다.
읽는 사람 ______ (임원 보고인지, 팀장 보고인지, 전사에 붙는 공지인지, 외부 고객에게 나가는 글인지 하나만)
나가는 형태 ______ (한 장짜리 보고서·메일·공지문·회의록·제도 문서 가운데 하나)
뼈대 요약 __줄 → 리스크 __개 → 대응·다음 액션 __개 (문서마다 숫자를 바꾼다)
검수에서 볼 것 쓰지 않을 표현 ______ / 톤은 딱딱하게·친근하게 중 ______ / 분량 ______ / 빠지면 안 되는 메시지 ______
채운 예 이번 주 KPI, 임원 보고용 한 장. 요약 5줄, 리스크 3개, 대응 5개. 숫자는 표, 톤은 딱딱하게.
안 되는 경우
- 이 방식이 잘 맞는 팀은 HR·기획/운영·마케팅/영업지원·백오피스처럼 문서 생산이 많은 팀이다. 자가진단 일곱 항목 중 세 개 미만인 팀, 즉 반복 문서 업무 자체가 적은 팀은 원문이 다루지 않는다.
- 팀 표준을 세운 뒤 재작업이 얼마나 줄었는지 시간·건수 수치는 원문에 없다. 사례 조직명도 없다. 위 논지는 관찰과 진단이지 측정 결과가 아니다.
- 보안·민감정보 규칙은 조직 정책에 맞춰 조정한다고만 되어 있고 규칙의 내용은 밝히지 않는다. 외부 SaaS 접속이 막힌 조직은 팀 표준 이전에 어떤 도구를 쓸 수 있는지부터 정해야 한다.
- 에이전트·서브 에이전트 단계는 어떤 플랫폼으로 어떤 비용에 만드는지 원문이 다루지 않는다. 팀 문서 기준이 없는 조직이 이 단계로 바로 가는 것은 위에서 말한 순서와 반대다.
이번 주에 바꿀 것은 프롬프트 교육 일정이 아니라 문서 한 건이다. 가장 자주 나가는 보고서나 메일 하나를 골라 대상·형태·검수 기준 세 줄을 적고, 그 세 줄이 붙은 요청과 붙지 않은 요청의 결과물을 팀이 나란히 본다. 개인의 요령을 팀의 기준으로 옮기는 그 작업을 교육으로 시작하려면, 조녁컴퍼니의 AX 전환 교육 범위를 먼저 확인해 보라. 사업영역 →