AI에게 일을 잘 맡기는 법: 좋은 프롬프트보다 좋은 작업 티켓이 먼저다

1. 개요: 모델만 바꾼다고 업무가 좋아지지 않는다

애매한 요청은 애매한 결과를 만듭니다. "제안서 써줘"라고만 하면 AI는 고객, 톤, 가격 논리, 법적 경계, 문서 형식을 추측합니다. 그 다음 사람은 AI가 잘못 추측한 부분을 다시 고칩니다. 이때 문제는 모델 성능이 아닐 수 있습니다. 처음부터 일이 충분히 정의되지 않은 것입니다.

OpenAI와 Anthropic의 프롬프트 가이드는 반복해서 같은 방향을 말합니다. 명확하게 지시하고, 필요한 맥락을 주고, 예시를 제공하고, 원하는 출력 형식을 지정하라는 것입니다. OpenAI의 Structured Outputs는 한 걸음 더 나아가 "어떤 모양의 결과가 허용되는가"를 구조로 정하게 합니다. 운영자의 언어로 번역하면 이렇습니다. 문장 하나를 더 예쁘게 쓰지 말고, 일을 포장해서 넘기십시오.

이번 조사에서 로컬 X 인박스도 같은 현장 신호를 보여줬습니다. 매번 채팅에서 톤과 금지사항을 다시 쓰는 대신 재사용 가능한 AI 셋업을 만들자는 이야기, 브라우저 화면에 직접 댓글을 달아 UI 문제를 정확히 가리키는 흐름, 초기 PRD와 실제 소스코드를 대조해 괴리를 찾는 방식, 공개 전 보안·개인정보 체크리스트가 반복해서 보였습니다. X 글은 최종 사실 근거가 아니라 현장의 마찰 신호로만 사용했습니다.

2. 쉬운 용어 정리: 프롬프트, 작업 티켓, SOP, MCP, 완료 기준

프롬프트는 AI에게 보내는 질문이나 지시입니다. 작업 티켓은 그 지시를 둘러싼 업무 주문서입니다. 무엇을 달성해야 하는지, 어떤 출처를 봐야 하는지, 무엇을 하면 안 되는지, 어떤 형식으로 내야 하는지, 어떻게 검증할지가 들어갑니다.

SOP는 Standard Operating Procedure의 약자입니다. 쉽게 말하면 회사에서 반복 업무를 처리하는 레시피입니다. CLAUDE.md나 AGENTS.md 같은 파일은 AI용 업무 브리핑입니다. 프로젝트의 안정적인 규칙, 실행 명령어, 말투, 위험한 행동, 중요한 파일 위치를 AI에게 미리 알려주는 역할을 합니다.

MCP는 Model Context Protocol의 약자입니다. AI가 외부 도구나 데이터 소스와 연결되는 표준화된 통로라고 보면 됩니다. 다만 MCP가 있다고 해서 일이 자동으로 잘 정의되지는 않습니다. 도구를 연결해도 무엇을 해야 하는지, 어디까지 해도 되는지, 무엇을 근거로 완료라고 할지는 작업 티켓이 정해야 합니다. 통과 조건은 결과물이 만족해야 할 체크 항목이고, 완료 기준은 일을 끝났다고 부르기 위해 필요한 증거입니다.

• 프롬프트: 지금 AI에게 보내는 즉시 지시.
• 작업 티켓: 지시를 포함한 전체 업무 주문서.
• SOP: 반복 업무를 처리하는 회사의 레시피.
• AI 브리핑 파일: AI가 계속 기억해야 하는 프로젝트 규칙.
• MCP: AI가 외부 도구와 데이터에 연결되는 통로.
• 통과 조건: 결과물이 만족해야 하는 체크 항목.
• 완료 기준: 일을 끝났다고 말하기 전에 필요한 증거.

3. 왜 애매한 프롬프트는 비용을 만든다

첫 번째 비용은 추측을 고치는 비용입니다. 사람이 "영업 메일 써줘"라고 하면 AI는 대상 고객, 가격 조건, 금지 표현, 톤, 길이를 모두 추측합니다. 결과는 그럴싸해도 실제 업무에는 맞지 않을 수 있습니다. 그 다음 사람은 "이건 빼고, 이 톤으로, 이 조건은 넣고"를 반복합니다.

두 번째 비용은 맥락 손실입니다. 중요한 출처가 Notion, 저장소 파일, 정책 PDF, 이전 결정 기록에 있는데 모델이 보지 못하면, 답변은 자신감 있어 보이지만 회사의 실제 판단 기준과 어긋날 수 있습니다. Anthropic이 에이전트의 context engineering을 강조하는 이유도 여기에 있습니다. 긴 대화보다 중요한 것은 필요한 정보를 필요한 순간에 제대로 넣는 것입니다.

세 번째 비용은 완료가 보이지 않는 것입니다. "괜찮아 보인다"는 완료 기준이 아닙니다. 코드라면 lint, build, 라우트 확인, 커밋 증거가 필요할 수 있습니다. 블로그라면 출처, 이미지, 다국어 라우트, sitemap, 라이브 URL 확인이 필요합니다. 고객 응대라면 정책 준수와 사람 승인 경계가 필요합니다.

4. 7칸짜리 AI 작업 티켓

좋은 작업 티켓은 한 화면에 들어갈 수 있습니다. 관료주의를 만들자는 뜻이 아닙니다. AI가 시작하기 전에 숨어 있던 판단 기준을 보이게 하자는 뜻입니다. 같은 요청이 두 번 이상 반복되면 티켓을 템플릿으로 만들 가치가 있습니다.

첫 번째 칸은 목표입니다. 어떤 사용자 결과나 사업 결과가 바뀌어야 하는지 적습니다. 두 번째 칸은 배경 맥락입니다. AI가 행동하기 전에 알아야 할 상황입니다. 세 번째 칸은 출처 묶음입니다. 링크, 파일, 노트, 예시, 스크린샷, 로그처럼 답변을 제한해야 하는 근거입니다.

네 번째 칸은 제약 조건과 금지사항입니다. 근거 없는 주장 금지, 법적 약속 금지, 가격 변경 금지, 특정 폴더 밖 수정 금지, 승인 없는 라이브 서비스 호출 금지처럼 하면 안 되는 일을 적습니다. 다섯 번째는 출력 형식입니다. 여섯 번째는 검증 방법입니다. 일곱 번째는 완료 증거와 에스컬레이션 조건입니다. 어떤 증거를 보고해야 하는지, 언제 멈추고 사람에게 물어야 하는지 정합니다.

• 목표: 어떤 결과가 바뀌어야 하는가?
• 배경: 일을 이해하기 위한 맥락은 무엇인가?
• 출처 묶음: AI가 읽거나 인용해야 할 근거는 무엇인가?
• 제약 조건: 절대 하면 안 되는 일은 무엇인가?
• 출력 형식: 어떤 모양으로 결과를 내야 하는가?
• 검증 방법: 무엇으로 결과를 확인할 것인가?
• 완료 증거: 무엇을 보여주면 끝이고, 언제 사람에게 넘겨야 하는가?

5. 운영자가 바로 쓸 수 있는 네 가지 예시

블로그 글이라면 티켓에 주제, 독자, 필요한 출처 종류, 반드시 인용해야 할 주장, 이미지 요구사항, 다국어 반영, SEO 확인, 라이브 확인이 들어가야 합니다. 그러면 "글 써줘"가 실제 발행 가능한 업무가 됩니다.

고객 답변이라면 고객 히스토리, 정책 출처, 말투 경계, 환불·계약 규칙, 절대 약속하면 안 되는 내용, 발송 전 사람 승인 여부가 들어가야 합니다. 그래야 따뜻하지만 위험한 문장을 줄일 수 있습니다.

코드 수정이라면 파일 범위, 기대 동작, 통과 조건, 실행할 검증 명령어, 라우트나 스크린샷 증거, 커밋 정책, 롤백 메모가 들어가야 합니다. Codex 같은 코딩 에이전트는 파일을 고치고, 검증을 돌리고, 증거를 남길 때 가장 강해집니다.

• 조사 요약: 출처 우선, 충돌 기록, 신뢰도 라벨, 검증 안 된 주장 제거.
• 블로그 글: 근거 로그, 이미지, 다국어 라우트, SEO, sitemap, 라이브 확인.
• 고객 답변: 정책 출처, 말투, 금지 약속, 승인 경계.
• 코드 수정: 파일 범위, 테스트, build, diff, 커밋, 배포 증거.

6. 습관이 아니라 일의 종류로 도구를 고른다

작업 티켓은 어떤 도구가 일을 맡아야 하는지도 정리해 줍니다. 출처 기반 질문은 검색이나 RAG부터 시작하는 것이 좋습니다. 전략, 판단, 내러티브처럼 모호한 일은 프리미엄 추론 모델이 잘 맞습니다. 파일 수정, 테스트, 라우트 확인은 Codex 같은 코딩 에이전트가 맡기 좋습니다. 되돌리기 어려운 결정은 여전히 사람이 승인해야 합니다.

이 구분이 중요한 이유는 팀이 돈과 주의력을 동시에 낭비할 수 있기 때문입니다. 강한 모델은 약한 맥락에서도 멋진 답을 쓸 수 있습니다. 하지만 멋진 답이 업무적으로 안전하다는 뜻은 아닙니다. 작은 모델은 서식 변환을 빠르게 할 수 있지만 계약 리스크를 승인하면 안 됩니다. 작업 티켓은 이 배치를 눈에 보이게 만듭니다.

GUILDEX식 운영 규칙으로 말하면 간단합니다. 출처 묶음이 먼저, 작업 티켓이 둘째, 모델 선택이 셋째, 검증이 마지막입니다. 앞의 두 단계를 건너뛰면 팀은 위임 문제를 모델 문제로 착각하게 됩니다.

7. 사람도 함께 발전해야 하는 이유: 위임 문해력

AI는 계속 강해질 것입니다. 그렇다고 사람이 발전하지 않아도 되는 것은 아닙니다. 필요한 능력의 위치가 바뀝니다. 앞으로 가치 있는 사람은 직접 글을 쓰고, 검색하고, 코딩하고, 요약하는 사람만이 아닙니다. 일을 정의하고, 진짜 출처를 고르고, 경계를 정하고, 도구를 배치하고, 결과를 평가하고, 다음 실행을 위한 템플릿으로 고치는 사람입니다.

그래서 작업 티켓은 문서 작업이 아닙니다. 위임 문해력입니다. 암묵적인 판단을 명시적으로 만들고, 반복 설명을 줄이고, 개인의 프롬프트 감각을 팀의 운영 자산으로 바꿉니다.

이번 주에 할 수 있는 첫 행동은 단순합니다. 자주 하는 AI 요청 하나를 골라 7칸짜리 티켓으로 다시 쓰십시오. 그리고 결과, 검증 증거, 수정 사항을 남기십시오. 두 번째 실행은 더 싸져야 합니다. 세 번째 실행은 템플릿이 되어야 합니다.