AI에 무엇을 맡길 것인가

1. 목록은 나왔는데 일은 끝나지 않았습니다

이 글은 챕터 0의 전제를 실제 업무에 적용합니다. 챕터 0을 읽지 않았다면 한 가지만 기억하면 됩니다. 이 글의 표와 프롬프트는 정답 양식이 아니라 원리를 관찰하기 위한 실험 도구입니다.

회의 메모를 AI에 넣고 체크리스트로 바꿔 달라고 요청해 봤습니다. 메모는 실제 회사가 아닌 합성 자료입니다.

- 신입 구성원 온보딩 안내문을 개정한다.
- 보안 정책을 반드시 포함한다. 참고 문서는 사내 드라이브의 security_policy_v3.pdf다.
- 민아가 금요일 배포를 제안했지만 확정되지는 않았다.
- 준호는 일정이 되면 검토할 수도 있다고 말했다.
- 화면 캡처 교체 담당자는 정하지 않았다.
- 팀장 승인 후에만 배포할 수 있다.
- 직원 개인정보는 외부 AI 서비스에 입력하지 않는다.

몇 초 뒤 이런 목록이 나왔습니다.

- [ ] 신입 구성원 온보딩 안내문 개정
- [ ] 사내 드라이브의 security_policy_v3.pdf를 참고하여 보안 정책 반드시 포함
- [ ] 배포 일정 확정: 민아가 제안한 금요일 배포는 미확정
- [ ] 준호의 검토 가능 여부 확인: 일정에 따른 조건부 의사로, 검토 미확정
- [ ] 화면 캡처 교체 담당자 지정 후 교체 진행
- [ ] 팀장 승인 확보 후에만 배포
- [ ] 작업 전 과정에서 직원 개인정보를 외부 AI 서비스에 입력하지 않기

잘 만든 목록입니다. 일곱 항목이 빠짐없이 들어갔고, 금요일 배포나 준호의 검토를 확정된 것처럼 바꾸지도 않았습니다. 여기서 “정리 끝”이라고 느끼기 쉽습니다.

그런데 이 목록을 들고 내일 출근하면 무엇부터 할 수 있을까요? 안내문은 누가 고칩니까? 배포는 언제입니까? AI는 security_policy_v3.pdf를 열어 보지 못했으니 보안 정책이 제대로 반영될지도 알 수 없습니다. 팀장 승인은 목록이 생겼다고 저절로 나오지 않습니다.

목록을 만드는 일은 끝났지만, 안내문을 고쳐서 배포하는 일은 하나도 끝나지 않았습니다.

그래서 먼저 물어야 할 질문은 “AI가 이 일을 할 수 있는가?”가 아닙니다.

이 업무에서 AI가 만들어도 되는 부분은 무엇이고, 사람이 확인해야 하는 부분은 무엇이며, 사람이 직접 결정해야 하는 부분은 무엇인가?

2. 이 글을 읽고 할 수 있게 될 것

자신의 업무 하나를 다음 세 칸으로 나눕니다.

• AI에게 맡길 것: AI가 후보나 초안을 만들어도 되는 부분
• 사람이 확인할 것: 원자료·기준·권한·결과를 사람이 대조할 부분
• 사람이 직접 결정할 것: 책임과 영향을 따져 사람이 결론 내릴 부분

칸 이름마다 “누가”를 붙인 데는 이유가 있습니다. 주어를 빼고 “맡길 것”이라고만 썼더니 AI가 “다른 사람에게 넘길 일”로 읽은 사례가 있었습니다. 7절에서 봅니다.

마지막에는 10~30분 안에 자신의 업무 위임표를 만듭니다. 이 표는 일반인편 챕터 8에서 개인 AI 활용 플레이북의 첫 장으로 다시 씁니다.

특정 AI 제품의 성능이나 개인정보 약관, 조직별 법적 의무는 판정하지 않습니다. 인사·의료·법률·재무처럼 중요한 판단에는 조직 정책과 해당 분야 전문가의 검토가 먼저입니다.

3. 실험: 세 칸으로 나눠 달라고 하면

같은 메모로 한 번 더 요청했습니다. 이번에는 조건 세 가지를 붙였습니다.

1. 각 항목을 맡길 것 / 확인할 것 / 직접 결정할 것으로 분류한다.
2. 원문에 없는 담당자·기한·승인 여부는 추정하지 않고 미정으로 표시한다.
3. 완료 조건은 보안 정책 반영, 화면 캡처 교체, 팀장 승인, 배포일 확정이다.

결과를 보기 전에 잠깐 직접 분류해 보세요. “화면 캡처 교체”는 세 칸 중 어디에 들어가야 할까요?

AI가 만든 표를 요약하면 다음과 같습니다.

좋아진 점이 분명합니다. 첫 번째 목록에서는 묻혀 있던 담당자·기한·승인이 모두 미정으로 드러났고, 배포일은 사람이 정할 일로 분리됐습니다.

그런데 “맡길 것” 칸을 다시 보세요. AI는 사내 드라이브의 보안 정책 문서를 열 수 없었습니다. 화면을 캡처해 교체할 수도 없습니다. 그런데 두 항목이 모두 “맡길 것”에 들어갔습니다. 이 칸이 “AI에게 맡길 일”이라면 분류가 틀린 것이고, “누군가에게 맡길 일”이라면 맞는 분류입니다. 요청에 주어를 쓰지 않았기 때문에 어느 쪽인지 알 수 없습니다.

직접 관찰한 것

• 짧은 요청도 쓸 만한 체크리스트를 만들었습니다.
• 조건을 붙인 요청은 결정되지 않은 담당자·기한·승인을 더 잘 드러냈습니다.
• 두 요청 모두 사내 원문 확인, 실제 수정, 승인, 배포를 하지 않았습니다.
• AI가 만든 분류 자체도 사람이 다시 확인해야 했습니다.

여기서 해석할 수 있는 것

완료 조건과 “추정하지 말라”는 조건은 그럴듯한 빈칸 채우기를 줄이고 다음 행동을 드러내는 데 도움이 됐습니다. 동시에, 분류를 AI에게 맡기면 그 분류도 확인 대상이 됩니다. 칸 이름처럼 사소해 보이는 표현이 결과를 바꿀 수 있습니다.

이 결과로 “이 프롬프트가 항상 더 좋다”고 말할 수는 없습니다. 조건별로 한 번만 실행했고 합성 문서 업무 하나만 썼습니다. 모델 성능 비교가 아니라, 결과를 만드는 일과 업무를 끝내는 일을 구분하기 위한 설명용 사례입니다.

4. 무엇을 맡길지 정하기 전에 정할 네 가지

4.1 목적: 이 결과로 누가 무엇을 하는가

“보고서를 만들어 주세요”는 결과물의 이름만 말합니다. 같은 보고서도 팀 내부 아이디어 모음인지, 고객에게 보낼 확정 문서인지에 따라 필요한 정확성과 승인 절차가 달라집니다. 목적은 한 문장으로 적습니다.

이 결과를 사용해 누가 어떤 다음 행동을 할 것인가?

“신입 구성원이 첫날 필요한 절차를 빠뜨리지 않도록 안내문을 개정한다”라고 쓰면, 문장을 예쁘게 다듬는 것보다 누락을 막는 것이 중요하다는 사실이 드러납니다.

미국 국립표준기술연구소(NIST)의 AI 위험관리 프레임워크도 AI의 의도한 목적과 사용 맥락, AI가 지원할 구체적인 과업을 먼저 정의하라고 권합니다. 조직을 위한 자발적 지침이라 개인의 작은 업무에 같은 절차를 요구하지는 않습니다. 다만 도구보다 목적과 맥락을 먼저 본다는 순서는 그대로 쓸 수 있습니다.

4.2 입력: AI에 무엇을 보여 줄 수 있는가

자료가 있다고 모두 넣어도 되는 것은 아닙니다. 먼저 세 종류로 나눕니다.

1. 외부 서비스에 넣어도 되는 자료
2. 이름·연락처·계정 정보처럼 지우거나 바꿔야 하는 자료
3. 조직 정책이나 계약상 외부 입력이 금지된 자료

기준은 “AI가 이해할 수 있는가”가 아니라 “이 서비스에 이 내용을 넣어도 되는가”입니다. 서비스별 데이터 보관·학습 정책은 바뀔 수 있으니 사용 전에 최신 공식 문서와 조직 정책을 확인하세요. 자료를 넣을 수 없어도 방법은 있습니다. 가짜 예시로 형식만 만들거나, 민감한 값을 [고객명] 같은 자리표시자로 바꾸거나, 조직이 승인한 환경을 쓸 수 있습니다.

4.3 제약: 해서는 안 되는 일은 무엇인가

제약에는 두 종류가 있습니다.

• 내용 제약: 확인되지 않은 수치를 쓰지 않는다, 원문에 없는 담당자를 만들지 않는다.
• 행동 제약: 파일을 고치지 않는다, 메일을 보내지 않는다, 외부에 게시하지 않는다.

둘은 막는 방법이 다릅니다. 내용 제약은 요청 문장으로 전달할 수 있습니다. 행동 제약은 문장만으로는 부족할 때가 있습니다. 6절에서 자세히 봅니다.

4.4 완료 기준: 무엇을 확인하면 끝인가

완료 기준은 결과물의 모양이 아니라 목적이 이뤄졌는지 확인하는 조건입니다. 온보딩 안내문이라면 다음과 같습니다.

• 보안 정책의 필수 항목이 원문과 일치한다.
• 오래된 화면 캡처가 교체됐다.
• 담당자가 문서를 검토했다.
• 팀장이 배포를 승인했다.
• 확정된 날짜에 승인된 경로로 배포했다.

AI가 초안을 완성해도 이 다섯 가지를 확인하지 못했다면 업무는 끝나지 않았습니다. 반대로 내부 아이디어 모음이 목적이라면 더 짧은 기준으로 끝낼 수 있습니다.

NIST의 생성형 AI 프로필은 생성형 AI가 틀린 내용을 확신 있게 내놓는 현상(confabulation, 흔히 “환각”이라고 부르는 현상)을 위험으로 설명하고, 생성된 정보의 정확성을 확인하는 절차를 두라고 권합니다. 문장이 자연스럽다는 사실만으로 업무가 끝났다고 볼 수 없는 이유입니다.

5. 업무를 다섯 단계로 나누기

업무 전체에 “AI에게 맡김”이라고 표시하면 사람이 책임질 지점이 보이지 않습니다. 목표 → 입력 → 생성 → 검증 → 결정으로 나누면 경계가 선명해집니다.

이 그림은 고정된 역할표가 아닙니다. 확인 기준이 명확하고 되돌리기 쉬운 내부 초안이라면 AI에게 더 넓게 맡길 수 있습니다. 반대로 잘못되면 사람의 권리, 큰 비용, 보안, 대외 신뢰에 영향을 주고 되돌리기 어렵다면 사람의 확인과 차단 장치를 늘려야 합니다.

6. “하지 마세요”와 “할 수 없게 만들기”는 다릅니다

AI 메일 비서에게 “메일은 보내지 마세요”라고 지시했다고 해 봅시다. AI가 지시를 지키면 문제없습니다. 그런데 AI가 요청을 잘못 이해했거나 실수했다면 어떻게 될까요? 메일 발송 기능이 연결돼 있다면 메일은 그대로 나갈 수 있습니다.

지시는 AI가 읽는 규칙입니다. 반면 발송 권한을 주지 않거나 보내기 전에 사람 승인을 거치게 하는 것은 실제 행동이 지나가는 길목에서 막는 장치입니다. 둘 다 필요할 수 있지만 서로 대신하지는 못합니다.

“지시는 소용없다”는 뜻이 아닙니다. 많은 작업은 지시만으로도 잘 제한됩니다. 다만 실수했을 때 되돌리기 어려운 행동, 예를 들어 메일 발송, 파일 삭제, 결제, 공개 게시에는 지시가 지켜지기를 기대하는 것과 실행 자체를 막는 것을 구분해야 합니다. 쓰고 있는 AI 도구에 어떤 권한이 연결돼 있는지, 실행 전에 확인을 요구하는 설정이 있는지 살펴보세요. 이 권한 구조를 시스템 관점에서 자세히 보는 내용은 개발자편(준비 중)에서 다룹니다.

7. 다른 업무에서도 통할까: 환불 문의 반례

회의 메모 정리는 틀려도 내부에서 고칠 수 있는 일입니다. 결과가 고객에게 나가고 돈이 걸린 업무에서도 같은 방식이 통할지 확인하려고 두 번째 실험을 했습니다.

[고객 문의 — 합성 자료]
3주 전에 연간 이용권을 결제했는데, 기대했던 기능이 없어서 환불받고 싶습니다.
결제일은 8월 20일입니다. 가능한 한 빨리 처리 부탁드립니다.
 
[내부 환불 정책 발췌 — 합성 자료]
- 결제 후 14일 이내: 전액 환불
- 14일 초과: 이용 기간에 해당하는 금액과 위약금 10%를 제외하고 환불
- 정책 예외 승인은 운영팀장만 할 수 있음
- 환불 확정 안내는 결제 시스템에서 환불 처리를 마친 뒤 발송

짧은 요청 — “고객에게 보낼 답장을 작성해 주세요.”

답장은 정중하고 정책도 정확히 인용했습니다. 그런데 이런 문장이 들어 있었습니다.

확인 결과, 결제일이 8월 20일로 오늘(9월 14일) 기준 결제 후 14일이 경과하여, 저희 환불 정책상 전액 환불이 아닌 이용 기간에 해당하는 금액과 위약금 10%를 제외한 금액으로 환불이 진행되는 점 양해 부탁드립니다.

정책에 따른 부분 환불: 이용 기간 차감 및 위약금 10% 제외 후 환불 (즉시 진행 가능)

아무도 결제 시스템을 열어 보지 않았는데 “확인 결과”라고 썼고, 처리 가능 여부가 확인되지 않았는데 “즉시 진행 가능”이라고 적었습니다. 운영팀장에게 예외 검토를 “받아 보겠다”는 약속도 들어 있었습니다. 이 답장을 그대로 보내면 고객에게는 회사의 확정 안내가 됩니다. 회의 메모 목록은 틀려도 다시 고치면 되지만, 보낸 메일과 약속은 되돌리기 어렵습니다.

조건을 붙인 요청 — 세 칸 분류, 추정 금지, 확정되지 않은 약속 금지

이번 답장은 금액과 승인 여부를 약속하지 않고 확인이 끝나면 안내하겠다고만 썼습니다. 그런데 함께 만든 분류표에 이런 행이 나왔습니다.

AI는 “맡길 것”을 AI에게 맡길 일이 아니라 다른 사람에게 넘길 일로 읽었습니다. 칸 이름에 주어가 없으니 틀린 해석이라고 하기도 어렵습니다. 3절의 “화면 캡처 교체”가 “맡길 것”에 들어간 것도 같은 이유였을 수 있습니다.

칸 이름에 주어를 넣고 다시 요청했습니다 — AI에게 맡길 것 / 사람이 확인할 것 / 사람이 직접 결정할 것

환불 문의에서는 결과가 달라졌습니다. “AI에게 맡길 것”에는 답장 초안 작성 하나만 남았고, 운영팀장의 예외 승인은 “사람이 직접 결정할 것”으로, 결제 처리와 안내 발송은 사람 쪽으로 옮겨 갔습니다.

같은 방식으로 온보딩 메모도 다시 분류해 봤습니다. “화면 캡처 교체”는 “사람이 확인할 것”으로 옮겨졌습니다. 하지만 AI가 열어 볼 수 없는 보안 정책 문서가 필요한 “보안 정책 반영”은 여전히 “AI에게 맡길 것”에 남았습니다.

칸 이름에 주어를 넣으면 뜻은 분명해집니다. 그래도 AI가 자기가 볼 수 없는 자료가 필요한 일까지 스스로 걸러 내지는 않았습니다. 그래서 이 글의 위임표는 칸 이름에 “AI에게”, “사람이”를 붙이고, AI가 만든 분류도 사람이 한 번 더 확인하는 것을 전제로 합니다.

무엇이 달라졌는가

두 업무를 나란히 놓으면 위임 범위를 정하는 네 가지 질문이 보입니다.

아래 칸으로 갈수록 AI에게 맡길 범위는 줄이고, 사람이 확인하고 결정할 범위는 넓혀야 합니다. 환불 답장이라면 AI에게는 초안까지만 맡기고, 결제 내역 확인과 금액 판단, 발송 결정은 사람이 하는 편이 맞습니다.

이 표도 자동 판정기는 아닙니다. 업무 맥락을 빠뜨리지 않기 위한 질문 목록입니다.

8. 실패하기 쉬운 맡김 방식과 이번 사례에서 가져갈 것

“일단 만들어 줘” 뒤에 목적을 붙이는 경우

결과를 본 뒤 목적을 정하면, 잘 만든 문장에 맞춰 성공 기준을 바꾸기 쉽습니다. 먼저 결과의 쓰임과 완료 조건을 한 줄씩 적습니다.

사람 검토를 만능 안전장치로 두는 경우

검토자가 원자료를 볼 수 없거나, 판단할 전문성이 없거나, 시간이 없다면 검토 단계는 이름만 남습니다. 누가 무엇과 대조해 어떤 오류를 찾아야 하는지 정합니다.

보낼 문장과 검토할 초안을 구분하지 않는 경우

환불 답장처럼 결과가 밖으로 나가는 업무에서 AI 출력은 “보낼 문장”이 아니라 “검토할 초안”입니다. 초안에 들어간 “확인 결과”, “즉시 가능”, “검토해 보겠습니다” 같은 약속 표현을 하나씩 사실과 대조합니다.

AI가 만든 내용을 내 경험처럼 쓰는 경우

AI가 초안이나 분류를 만들었다면 숨길 필요는 없습니다. 대신 내가 직접 정한 요구사항, 확인한 범위, 아직 확인하지 못한 부분을 구분해 둡니다.

한 번의 성공을 규칙으로 만드는 경우

이 글의 두 실험은 합성 자료로 한 번씩 실행한 관찰입니다. 다른 업무와 모델에서도 같은 차이가 나온다는 증거는 아닙니다.

이번 사례에서 가져갈 것

9. 독자 실습: 내 업무 위임표 만들기

10~30분이면 됩니다. 실제 개인정보, 고객 정보, 비밀번호, 비공개 계약 내용은 외부 AI에 넣지 마세요. 조직 정책상 허용되는지 모르면 AI 없이 종이에 표만 만들어도 됩니다.

준비물

• 이번 주에 실제로 해야 하는 작은 업무 하나
• 그 업무의 원자료가 있는 곳
• 결과를 쓸 사람과 그 사람의 다음 행동

1단계: 목적과 완료 기준 적기

• 목적: 이 결과로 누가 어떤 다음 행동을 합니까?
• 완료 기준: 무엇을 확인하면 끝났다고 말할 수 있습니까?
• 실패 영향: 틀리면 누구에게 어떤 문제가 생깁니까? 되돌릴 수 있습니까?

2단계: 단계별로 나누기

한 단계를 한 칸에만 넣을 필요는 없습니다. “보고서 작성”이라면 문장 초안은 AI에게 맡기고, 숫자 원문 대조는 사람이 확인하고, 외부 배포는 사람이 결정할 수 있습니다.

3단계: 경계 질문에 답하기

• 이 자료를 지금 쓰는 AI 서비스에 넣어도 됩니까?
• AI가 보지 못한 원자료는 무엇입니까?
• 틀린 결과를 어떤 방법으로 찾아냅니까?
• 결과가 밖으로 나가기 전에 누가 승인합니까?
• 실패하면 멈추고 되돌아갈 지점이 있습니까?

4단계(선택): AI의 분류와 비교하기

2단계 표를 먼저 직접 채운 뒤, 개인정보를 뺀 업무 설명을 AI에게 주고 같은 세 칸으로 분류해 달라고 요청해 보세요. 칸 이름에 “AI에게”, “사람이”를 넣었을 때와 뺐을 때를 비교해도 좋습니다. 내 분류와 다른 칸이 있다면, 누가 옳은지보다 왜 다르게 읽혔는지를 적어 둡니다.

완료 기준

• 업무 목적이 한 문장으로 적혀 있습니다.
• AI에게 맡길 것, 사람이 확인할 것, 사람이 직접 결정할 것이 각각 하나 이상 있습니다.
• 최종 완료를 확인할 사람과 증거가 적혀 있습니다.
• 민감한 자료와 밖으로 나가는 행동에 멈출 조건이 적혀 있습니다.

표를 다 채웠다고 모든 칸을 AI에게 맡길 필요는 없습니다. 이 실습의 결과물은 “더 많이 위임한 표”가 아니라 맡긴 범위와 책임의 경계를 설명할 수 있는 표입니다.

10. 핵심 정리와 다음 연결

AI에게 일을 맡길 때는 결과물 단위가 아니라 책임 단위로 나눕니다.

1. 도구보다 먼저 목적, 입력, 제약, 완료 기준을 정합니다.
2. 결과가 나왔다는 사실과 업무가 끝났다는 사실을 구분합니다.
3. 칸 이름에도 주어를 씁니다. AI에게 맡길 것, 사람이 확인할 것, 사람이 직접 결정할 것.
4. “하지 마세요”라는 지시와 실제로 할 수 없게 막는 장치를 같은 것으로 보지 않습니다.
5. 확인할 수 있는지, 틀렸을 때 알아챌 수 있는지, 되돌릴 수 있는지, 영향이 큰지에 따라 위임 범위를 조절합니다.

다음 일반인편 챕터 2(준비 중)에서는 AI가 무엇을 바탕으로 답하는지 살펴봅니다. AI가 학습한 지식, 지금 대화에서 준 자료, 연결된 외부 자료를 구분하면 왜 어떤 정보는 답에 반영되고 어떤 최신 정보는 따로 확인해야 하는지 이해할 수 있습니다.

모델이 만든 결과와 도구가 실제로 실행한 행동이 시스템 안에서 어떻게 나뉘는지는 개발자편 챕터 1(준비 중)에서 다룹니다. 이 글을 읽지 않아도 이해할 수 있게 따로 구성합니다.

출처와 확인 환경

실험 1 — 온보딩 회의 메모(1·3절)

• 자료: 합성 회의 메모(실제 인물·문서 아님)
• 도구: Codex CLI 0.153.4, 읽기 전용 샌드박스, 임시 디렉터리
• 모델: 실행 로그에 정확한 모델 식별자가 남지 않아 확인하지 못함
• 반복: 조건별 1회, 실행일 2026-09-12, Windows
• 표기: 1절 체크리스트는 출력 전문, 3절 표는 출력 요약

실험 2 — 환불 문의(7절)

• 자료: 합성 고객 문의와 합성 환불 정책
• 도구: Claude Code CLI 2.1.270 비대화형 모드, 도구 사용 끔, 사용자·프로젝트 설정 제외
• 모델: claude-sonnet-5, 시스템 지시 “당신은 업무를 돕는 AI 어시스턴트입니다.”
• 반복: 짧은 요청, 조건을 붙인 요청, 칸 이름에 주어를 넣은 요청을 조건별 1회 실행. 주어를 넣은 요청은 온보딩 메모에도 한 번 적용. 실행일 2026-09-14, Windows
• 한계: 실행 도구가 현재 날짜를 모델에 제공해 경과일 계산에 쓰였습니다. 주어를 넣은 온보딩 메모 분류는 실험 1과 다른 도구·모델로 실행했습니다. 본문 인용과 표는 출력에서 발췌했습니다.

검증 정보

NIST 자료의 핵심 항목은 원문에서 확인했고, 두 실험의 입력과 출력 전문을 별도 기록으로 보존했습니다.

아직 확인하지 못한 범위는 다음과 같습니다.

• 같은 차이가 반복 실행이나 다른 모델·채팅 서비스에서도 나타나는지
• 칸 이름에 주어를 넣었을 때 분류가 달라진 결과가 반복 실행에서도 유지되는지
• 특정 AI 서비스의 최신 개인정보·데이터 보관 정책