AI에 일을 어디까지 맡겨도 될까?

AI에게 회의록을 정리해 달라고 하는 것과, 정리한 내용을 팀 전체에 보내 달라고 하는 것은 한 번의 요청 차이예요. 하지만 틀렸을 때 고쳐야 하는 범위는 크게 달라집니다. 초안은 다시 쓰면 되지만 이미 보낸 메시지는 다른 사람의 판단과 행동까지 바꿀 수 있으니까요.

처음에는 내가 확인할 수 있는 결과까지 맡기고 원본이나 다른 사람에게 영향을 주는 행동 앞에 확인 지점을 두세요. 잘됐다는 답변보다 무엇이 바뀌었고 무엇과 대조했는지가 중요해요.

업무 자동화를 설명하는 윤자동, 기업의 AI 활용 사례를 인터뷰하는 빌더 조쉬, 코드와 테스트를 다루는 맷 포콕의 콘텐츠를 함께 보면 이 질문이 세 갈래로 나뉩니다. 일을 이해시키는 방법, 실행을 제한하는 방법, 결과를 확인하는 방법이에요.

1. 자세히 시켰는데, 왜 원하지 않은 일이 생길까?

윤자동의 영상에는 “저장하지 말라”고 했는데 저장된 사례가 나와요. 이 이야기는 단순히 AI가 금지한 명령을 실행했다는 사례와는 조금 다릅니다. 영상 속 설명에 따르면 AI가 텍스트를 입력한 편집기가 iCloud와 연결되어 있었고 입력한 내용이 자동 저장됐어요. AI가 저장 명령을 내리지 않았어도 환경이 결과를 바꿨어요.

이때는 지시문의 길이와 함께 AI가 어디에 입력하는지, 그 도구에 자동 저장이나 공유가 연결되어 있는지까지 봐야 합니다. 원본을 건드리지 않는 게 조건이라면 복사본으로 작업하게 하고 복사본도 어디에 저장되는지 확인하는 편이 좋아요.

같은 영상에서 윤자동은 역할 놀이식 문구보다 실제 업무의 맥락을 강조합니다.

“

뭐가 중요하냐면 맥락이 중요합니다.

03:39 대본 발췌 ↗

내가 어떤 일을 하고 이 결과를 어디에 쓰며 언제까지 필요한지 알려주는 거예요. 매번 설명하는 조건은 규칙으로 남기고요. 영상 후반에는 원본에서 중복을 뺀 합계와 지점별 합계 시트를 대조해 표로 보여달라는 검산 요청도 소개합니다.

다음 요청에는 산출물과 경계를 같이 적어보세요

예를 들어 주간 실적표를 정리한다면 “이 파일 분석해 줘”에서 한 걸음 더 나아갈 수 있어요.

• 목적: 금요일 회의에서 지점별 실적 차이를 설명할 거예요.
• 산출물: 이번 주와 지난주의 합계, 차이가 큰 지점, 계산에 사용한 열을 표로 보여주세요.
• 작업 범위: 제공한 복사본을 읽고 결과를 별도 초안으로 만드세요. 원본 수정과 외부 전송은 하지 마세요.
• 확인 기준: 중복을 제외한 기준과 제외한 행, 원본 합계와 결과의 차이를 함께 보여주세요. 기준이 모호하면 먼저 물어보세요.

이 예시는 영상의 맥락·규칙·검산 설명을 업무에 옮겨본 요청이에요. 지시를 적었다고 해당 행동이 기술적으로 차단되는 것은 아닙니다. 입력할 자료와 저장 위치, 실제 도구 권한도 확인해야 해요.

2. 보내거나 바꾸는 일도 맡겨도 될까?

맥락을 충분히 알려줬다면 다음에는 실행 범위를 정할 차례예요. 답변 초안을 쓰는 권한과 실제 발송하는 권한, 수정안을 만드는 권한과 원본에 덮어쓰는 권한을 나눠보세요.

빌더 조쉬의 HOW I AI 인터뷰에서 임페라이의 음병찬 대표는 에이전트의 실행과 통제를 분리해야 한다고 설명합니다. “하지 말라”는 프롬프트에 의존하는 대신, 어떤 행동을 실행하려는 순간 허용할지 판단하는 장치를 두자는 이야기예요. 이어지는 Decision Ledger 설명에서는 흩어진 로그와 하나의 결정에 대한 기록을 구분합니다.

이 인터뷰는 게스트가 만드는 에이전트 통제 제품 Toren의 설명과 시연을 포함합니다. 제품의 사고 예방 효과를 독립적으로 검증한 연구는 아니에요. 여기서 가져올 것은 제품 도입 결론보다 내 업무에서 어느 행동을 따로 승인할 것인가라는 질문입니다.

“계속 진행해”의 범위를 한 번 나눠보세요

고객 문의 답변을 맡긴다고 생각해 볼게요. 조직에서 허용한 AI 도구와 제공 가능한 자료 범위 안에서, 문의의 사실을 정리하고 답변 초안을 쓰는 단계부터 시작할 수 있습니다. 자료를 넣어도 되는지 확인되지 않았다면 실제 고객 정보 대신 가상 예시로 먼저 시험해 보세요. 발송 전에는 수신자, 첨부파일, 약속한 내용, 출처를 한 화면에서 확인하도록 해보세요. 확인한 초안과 실제 보낼 내용이 같아야 승인에도 의미가 생깁니다.

원본 변경이나 외부 전송이 가능한 도구라면 그 행동에 필요한 권한을 처음부터 모두 주기보다, 이번 작업에 필요한 범위로 제한하는 방법을 확인해 보세요. 사용하는 서비스가 읽기와 쓰기 권한을 나누거나 실행 전 승인을 지원하는지는 별도로 확인해야 합니다. 그런 경계를 만들 수 없다면 우선 초안을 받아 사람이 옮기는 단계에 머물 수 있어요.

승인 버튼을 한 번 누른 사실도 결과가 맞다는 증거는 아니에요. 내가 내용을 판단할 수 없거나 바빠서 읽지 못한다면, 승인 횟수를 늘리는 것으로 해결되지 않습니다. 확인할 사람이 판단할 수 있는 단위로 일을 더 나누거나, 해당 업무를 아는 사람에게 검토를 맡겨야 해요.

3. AI가 검사도 했다면, 이제 끝난 걸까?

윤자동은 결과를 만드는 일뿐 아니라 검산도 AI에게 맡기고 사람이 검증 결과를 살펴보는 흐름을 제안해요. 반복 계산을 줄이는 데 참고할 만한 방법입니다. 그런데 그 검사가 중요한 오류를 놓치고 있다면 어떨까요?

맷 포콕의 짧은 영상은 코드 테스트를 예로 이 질문을 다룹니다. 코드에 일부러 작은 변형을 넣고 기존 테스트가 그 변화를 잡아내는지 확인하는 변이 테스트(mutation testing)예요. 영상에서는 문자열을 빈 문자열로 바꾼 예를 보여줍니다. 테스트를 다시 돌려도 통과하는 변형이 남으면, 검사에서 무엇을 놓치는지 살펴볼 수 있어요.

“

테스트를 다시 실행해 테스트가 실패하는지 확인합니다.

00:19–00:26 대본 · 한국어 번역 ↗

남은 변형이 모두 테스트의 결함을 뜻하는 것은 아니에요. Stryker 공식 문서는 코드를 바꿔도 실제 동작이 같은 ‘동등한 변형’이 있을 수 있다고 설명합니다. 숫자를 100%로 만드는 것보다, 남은 변형이 행동을 바꾸는지 먼저 살펴봐야 해요.

이 방법은 테스트가 얼마나 유용한지 한 번 더 묻는 방법이지, 모든 결함을 발견한다는 증명은 아니에요. 코드 밖의 문서 판단이나 업무 승인에 그대로 적용할 수도 없습니다. 원문에 등장하는 Stryker 역시 코드의 변이 테스트를 위한 도구예요.

검증 방법이 실패하는 경우도 확인해 보세요

주간 실적표로 돌아오면, 합계가 같다는 이유만으로 분류까지 맞다고 단정하면 안 돼요. 지점 이름을 잘못 붙여도 전체 합계는 같을 수 있으니까요. 원본과 결과의 합계 대조에 더해, 지점 분류 기준과 실제 행 몇 개를 함께 볼 수 있습니다.

작업용 복사본에 중복이나 누락을 일부러 넣고 검사가 이를 찾아내는지 시험해 보는 것도 방법이에요. 이것은 코드의 변이 테스트를 엑셀에서 재현했다는 뜻이 아니라, 검사가 놓칠 수 있는 예를 따로 준비한다는 생각을 업무에 적용한 것입니다. 표본 몇 개를 통과했다고 나머지 전체가 정확해지는 것은 아니며 틀렸을 때의 영향에 맞춰 확인 범위를 정해야 해요.

다음 업무 하나에서, 맡길 범위를 정해보세요

세 콘텐츠가 같은 해법을 말하는 것은 아니에요. 윤자동은 맥락과 반복 규칙, 검산을 설명하고 빌더 조쉬의 인터뷰는 실행 권한과 결정 기록을, 맷 포콕은 검사 자체의 빈틈을 다룹니다. 내 업무에는 이 중 어떤 부분이 비어 있는지부터 보면 좋아요.

다음에 맡길 일 하나를 골라 아래 네 문장을 채워보세요.

1. 여기까지 맡긴다: 입력 자료와 이번에 받을 결과는 무엇인가?
2. 여기서 멈춘다: 원본 변경·발송·공개 전에 사람이 확인할 행동은 무엇인가?
3. 이것과 대조한다: 결과를 확인할 원본·기준·실패 예시는 무엇인가?
4. 틀리면 이렇게 돌아온다: 바뀐 내용을 확인하고 되돌릴 방법은 무엇인가?

처음 실행은 복사본이나 초안으로 해보세요. 결과가 맞았다는 사실뿐 아니라, 정한 범위를 지켰는지와 문제가 생겼을 때 되돌릴 수 있었는지를 보고 다음 범위를 정하는 거예요. 모든 일을 계속 승인받게 하는 것도, 한 번 잘됐으니 전부 맡기는 것도 이번 업무의 답을 대신해 주지는 않습니다.

더 맡길 수 있는 기준은 “AI가 자신 있게 답했다”보다 “나는 무엇이 바뀌었고 왜 괜찮은지 확인할 수 있다”에 가까워요.