팀 공용 요청문, 사람마다 다른 요청문을 역할별 한 장으로 모아 두세요
AI를 팀이 같이 쓰기 시작하면 같은 일을 맡기는데도 사람마다 요청문이 다르죠. 누구는 금지 조건을 길게 적고, 누구는 결과 모양을 정하지 않아서 받을 때마다 다른 표가 돌아오고요. 이 글은 팀 공용 요청문을 역할별 지침 한 장으로 모으고, 일을 맡길 때는 그 장을 가리키기만 하는 방법을 다룹니다.
견본은 이 블로그를 만드는 저장소에서 팀 공용 요청문으로 쓰는 실제 지침 파일이에요. 글 작성 담당과 사실 검증 담당이 한 장씩 갖고 있고, 보고 규칙은 따로 떼어 한 장으로 두었어요. 글에 실은 카드는 그 파일들을 옮겨 그린 것이고, 경로와 내부 이름은 가리거나 풀어 썼습니다.
결론부터, 요청문은 한 장에 두고 대화에서는 그 장을 가리키세요
팀 공용 요청문을 대화창에 매번 붙여 넣으면, 붙여 넣는 사람마다 문장이 조금씩 달라져요. 이 저장소의 작업 규칙(CLAUDE.md)에는 같은 지침을 대화에 되풀이해 쓰지 말고 지침 파일을 가리키라는 줄이 있습니다. 글쓰기 절차 문서는 더 구체적이에요. 원고를 맡길 때 지침을 매번 새로 쓰지 않고 글 작성 담당 지침 한 장을 읽게 한 뒤, 그 글에만 해당하는 것(슬러그, 제목 형식, 주제, 출발 주소, 조심할 것)만 10~20줄로 적어 준다고 적혀 있어요.
Claude Code 공식 문서도 같은 기준을 둡니다. 스킬(Skill) 문서는 “keep pasting the same instructions, checklist, or multi-step procedure into chat”, 같은 지시나 점검표, 여러 단계 절차를 대화창에 계속 붙여 넣고 있다면 스킬을 만들 때라고 해요. 팀 공용 요청문이 딱 이 경우죠. 메모리 문서는 CLAUDE.md를 “what you’d otherwise re-explain”, 적어 두지 않으면 또 설명하게 될 것을 적는 곳이라고 부르고요.
보조 AI에게 맡길 때는 이 차이가 더 커요. 보조 에이전트(Subagent) 문서에는 “Each subagent starts with a fresh, isolated context window. It doesn’t see your conversation history”라는 줄이 있습니다. 새로 띄운 보조 AI는 앞선 대화를 보지 못한다는 뜻이에요. 맡기는 쪽이 요약해 넘긴 내용만 들고 시작하니, 팀 공용 요청문은 파일로 남겨야 이어집니다.
대화창에 매번 붙여 넣기
- 붙여 넣는 사람마다 문장이 조금씩 다름
- 지난번에 고친 줄이 빠진 판이 돌 수 있음
- 새로 띄운 보조 AI는 앞 대화를 못 봄
역할 한 장을 가리키기
- 모두 같은 파일을 읽음
- 고칠 곳은 그 장 한 곳
- 대화에는 이번 일에 해당하는 것만 덧붙임
팀 공용 요청문 한 장에는 이 다섯 칸을 넣어 보세요
팀 공용 요청문의 견본으로 삼은 글 작성 담당 지침은 2026년 10월 19일 기준 46줄짜리 파일 한 장이에요. 파일의 절 이름은 “먼저 읽을 것”, “절대 규칙”, “원고 요건”, “하지 말 것”, “보고”이고, 맨 위에 맡은 일을 적은 줄이 있습니다. 이걸 다섯 칸으로 다시 나눠 보면 아래 카드처럼 돼요. 칸 이름은 이 글에서 붙인 것입니다.
| 칸 | 지침 한 장에 적힌 것 | 적는 요령 |
|---|---|---|
| 맡은 일 | 조사, 원고, 도식·대표 이미지 원고, 기계 검사까지. 사실 검증과 업로드, 점수 확인은 맡긴 쪽이 한다 | 맡기지 않는 일도 같은 줄에 |
| 먼저 읽을 것 | 보고 규칙, 문체 기준 문서, 본보기 글, 그림 원고 형식 | 파일 이름으로, 읽을 순서대로 |
| 절대 규칙 | 절대 규칙 9줄과 하지 말 것 2줄 | 맞게 했는지 확인할 수 있는 문장으로 |
| 결과 형식 | 소제목 5~7개, 낱말 1,100~1,500개, 끝 문장, 오류 0까지 고치는 검사 | 개수와 범위는 숫자로 |
| 보고 규칙 | 보고서 파일에 6가지, 마지막 메시지에는 그중 일부 | 보고 규칙 한 장을 가리키기 |
팀 공용 요청문의 절대 규칙 칸은 공식 메모리 문서의 기준과 맞춰 볼 만해요. 문서는 지시를 “concrete enough to verify”, 맞게 했는지 확인할 수 있을 만큼 구체적으로 쓰라고 하면서 “Format code properly” 대신 “Use 2-space indentation”을 예로 듭니다. 이 블로그의 지침에도 “돈 얘기 조심” 같은 줄은 없어요. “수익·매출 금액 금지. 제품 가격은 꼭 필요할 때만 원문 표기(달러) 그대로 한 번, 원화 환산 금지.”처럼 적혀 있죠.
팀 공용 요청문을 역할마다 따로 두면 다른 역할의 한 장도 같은 모양이 돼요. 사실 검증 담당 한 장이 그래요. 맨 앞 문단에 “글을 고치지 않는다. 틀린 곳을 찾아 보고만 한다.”가 있고, 그 아래 입력, 확인할 것, 보고 형식 절이 이어집니다. 글 발행·영상·SNS 게시처럼 작업 창을 따로 여는 역할은 첫 지시문도 한 문단이에요. 역할표를 읽게 하고, 먼저 볼 파일을 이름으로 대고, “멈춘 작업은 이어서 하지 말고” 준비됐다는 말과 마지막 상태 3줄을 보낸 뒤 기다리라는 내용입니다.
에이전트 스킬 – 반복 작업을 절차로 묶는 방법검수에서 고친 점은 그날 그 장에 적어 두세요
팀 공용 요청문 한 장이 쓸모 있으려면 검수에서 나온 지적이나 새로 정한 규칙이 그 장에 쌓여야 해요. 이 저장소에서는 2026년 10월 19일 글 끝 상담 안내 규칙을 정한 날, 글 작성 담당 지침에 한 줄이 들어갔어요. 본문 마지막 문단은 정해진 상담 안내 한 문장으로 쓰고, 말을 거는 문장은 쓰지 않는다는 줄입니다. 이 글의 마지막 문장도 그 줄대로 썼어요.
글쓰기 기준 문서에는 “검수에서 배운 것”이라는 절이 따로 있어요. 첫 줄이 “글을 쓰고 검수받으며 나온 것을 여기에 쌓는다. 새 글을 쓰기 전에 읽고, 새로 배운 것이 생기면 추가한다.”이고, 2026년 10월 19일 기준 항목이 49개입니다. 대부분의 줄 끝에는 그 줄이 나온 글이 “(2편)”처럼 괄호로 붙어 있고요. 그중 “개수를 말하면 세어 본다”와 “전문 용어는 한글 뒤에 영어 원어를 괄호로”는 글 작성 담당 지침의 절대 규칙에도 같은 말로 들어 있어요.
공식 메모리 문서가 지침 파일에 줄을 더할 때로 꼽는 것도 이런 순간이에요. 팀 공용 요청문에 그대로 옮겨 쓸 수 있는 기준이고요. “Claude makes the same mistake a second time”, 같은 실수가 두 번째 나올 때. “A code review catches something Claude should have known”, 검토에서 알았어야 할 것이 걸렸을 때. “You type the same correction or clarification into chat that you typed last session”, 지난번에 한 정정을 대화창에 또 쓰고 있을 때.
바뀐 규칙은 덧붙이지 말고 그 줄을 고쳐 쓰세요
공식 문서는 두 지시가 서로 어긋나면 “Claude may pick one arbitrarily”, 둘 중 하나를 임의로 고를 수 있다고 적어요. 이 저장소에서 2026년 10월 15일 지침을 고칠 때는 “도식·영상 원고”를 “도식·대표 이미지 원고”로 바꿔 쓰고, 같은 칸에 “영상은 … 몫이라 만들지 않는다”를 붙였습니다. 예전 줄을 남긴 채 새 줄만 더하지 않았어요. 팀 공용 요청문 한 장 안에서 같은 일을 두고 두 말이 남지 않게 하는 거예요.
보고 규칙은 따로 한 장으로 떼어 두세요
보고 규칙은 팀 공용 요청문의 역할 한 장 안에 두지 않고 “담당 에이전트 공통” 한 장으로 떼어 두었어요. 글 작성 담당 지침도 맨 앞에서 이 장을 먼저 읽으라고 가리킵니다. 이 장의 첫 문단이 이유를 적고 있어요. 일을 맡긴 쪽의 컨텍스트(Context)는 한정돼 있어서, 담당이 돌려주는 보고가 길면 그만큼 맡긴 쪽이 쓸 수 있는 양이 줄어든다는 내용입니다.
규칙은 7줄이에요. 마지막 메시지는 40줄 이내로 쓰고, 자세한 것은 역할 이름을 붙인 보고서 파일로 넘깁니다. 맞는 것은 “수치 N개 중 일치 M개”처럼 개수로만 적고, 받은 지시문이나 명령 출력은 보고에 다시 옮기지 않아요. 공식 보조 에이전트 문서도 같은 쓰임을 적고 있어요. 검색 결과나 로그처럼 다시 볼 일 없는 내용이 대화를 채울 때 보조 에이전트에 맡기면, 그 일은 보조 에이전트의 컨텍스트에서 하고 “returns only the summary”, 요약만 돌려준다고요.
글 작성 담당은 이 공통 규칙 위에, 팀 공용 요청문의 보고 칸을 하나 더 둬요. 보고서 파일에 여섯 가지를 쓰는데, 그중 하나가 “확신이 약한 문장 5~15개”입니다. 글쓰기 기준 문서에는 이 칸을 두면 검증이 빨라진다고 적혀 있어요. 이 칸에는 원문과 다르게 줄였거나 스스로 묶은 문장을 적어요.
팀 공용 요청문을 팀에 들일 때는 이 순서로 시작해 보세요
팀 공용 요청문을 처음 만드는 팀이라면 이 순서로 시작해 볼 만해요. 이 블로그 저장소의 지침 파일과 공식 문서를 바탕으로 정리한 순서예요. 공식 문서에 적힌 절차는 아니고, 이 글에서 권하는 방법입니다.
- 두 번 이상 붙여 넣은 요청문부터 고르기: 지난주에도 이번 주에도 대화창에 붙여 넣은 요청문이 첫 후보예요. 공식 스킬 문서가 스킬을 만들 때로 꼽는 것도 이 경우입니다.
- 역할 이름을 정하고 다섯 칸을 채우기: 맡은 일 칸에는 맡기지 않는 일도 함께 적고, 절대 규칙은 맞게 했는지 확인할 수 있는 문장으로 써요.
- 보고 규칙 한 장을 따로 두기: 역할 한 장마다 “보고 규칙을 먼저 읽는다”는 줄 하나만 넣으면 돼요.
- 맡길 때는 그 장을 가리키고 이번 일만 덧붙이기: 이 블로그는 이번 글에만 해당하는 것을 10~20줄로 적어요.
- 검수에서 고친 점은 그날 그 장에: 줄 끝에 어느 일에서 나온 줄인지 괄호로 적어 두면 나중에 정리할 때 찾기 쉬워요.
- 가끔 겹치거나 어긋난 줄을 정리하기: 공식 문서는 CLAUDE.md 한 파일을 200줄 아래로 두라고 권하고, 길어지면 지시를 덜 따른다고 적어요.
빈 양식의 “먼저 읽을 것” 1번 자리에는 보고 규칙 한 장을 미리 적어 두었어요. 나머지 칸은 역할마다 다르게 채우면 됩니다. 팀 공용 요청문이 처음부터 길 필요는 없고, 검수에서 고친 줄이 쌓이며 채워져요. 팀 공용 요청문에서 금지 칸과 결과 형식 칸을 어떻게 적는지는 AI 요청문 작성법에 더 자세히 있어요.
이 글의 근거와 참고한 공식 문서
카드와 본문에 옮긴 지침은 이 블로그 저장소의 글 작성 담당 지침, 담당 공통 보고 규칙, 사실 검증 담당 정의 파일, 글쓰기 기준 문서와 절차 문서, 작업 규칙, 역할표와 역할별 첫 지시문에서 가져왔어요. 줄 수와 항목 수, 바뀐 날짜는 2026년 10월 19일에 파일과 저장소 변경 기록(git log)으로 확인한 값입니다.
공식 근거는 Claude Code 문서 How Claude remembers your project, Extend Claude with skills, Create custom subagents를 참고했어요. 문서는 바뀔 수 있으니 원문을 확인해 주세요.
AI가 먼저 묻게 하는 요청문은 업무 매뉴얼 만들기 글에, 역할 한 장을 AI가 필요할 때 꺼내 쓰는 절차로 묶는 방법은 에이전트 스킬 글에 있어요.
업종과 업무에 맞춘 AX 설계 상담은 무료 AX 상담 신청에서 받습니다.
팀 공용 요청문 자주 묻는 질문
팀 공용 요청문을 한 장에 모아 두면 대화창에는 무엇을 쓰나요?
그 장을 읽으라고 가리키고, 이번 일에만 해당하는 것만 덧붙여요. 이 블로그는 원고를 맡길 때 글 작성 담당 지침 한 장을 읽게 하고, 그 글의 슬러그·제목 형식·주제·출발 주소·조심할 것만 10~20줄로 적어 줍니다.
역할 한 장에는 어떤 칸을 두면 되나요?
맡은 일, 먼저 읽을 것, 절대 규칙(금지), 결과 형식, 보고 규칙 다섯 칸으로 시작해 보세요. 이 블로그의 글 작성 담당 지침은 46줄 한 장에 이 다섯 가지가 다 들어 있고, 맡은 일 줄에는 맡기지 않는 일(사실 검증, 업로드, 점수 확인)까지 적혀 있어요.
검수에서 지적받은 내용은 어디에 남기나요?
대화에서 말로 끝내지 말고 그날 그 역할의 한 장에 한 줄로 넣어요. Claude Code 공식 문서도 같은 실수가 두 번째 나올 때, 지난번에 한 정정을 대화창에 또 쓰고 있을 때 지침 파일에 적으라고 해요. 바뀐 규칙은 덧붙이지 말고 그 줄을 고쳐 써야 서로 어긋나는 줄이 남지 않습니다.
글에 나온 역할별 AI 작업 창은 Claude Code로 띄운 것이고, 공식 안내는 Claude Code 공식 문서에 있습니다.
이 글은 직접 만들고 운영하며 남긴 기록입니다. 적힌 수치는 작성 시점의 운영 계정 기준이며, 같은 결과나 수익을 보장하지 않습니다.
