AI 에이전트에게 일 맡기기 전 정해야 할 6가지

새로 온 아르바이트생에게 "가게 좀 봐줘"라고만 하고 나가면 무슨 일이 생길까. 계산은 어디까지 해도 되는지, 손님이 환불을 요구하면 얼마까지 승인 가능한지, 마감은 몇 시인지 아무것도 안 정해졌다. 대부분은 어떻게든 그럭저럭 해내겠지만, 손대면 안 되는 금고를 열거나 오늘 마감 매출을 실수로 지워버릴 수도 있다. AI 에이전트(사람 대신 작업을 진행하는 AI 프로그램)에게 일을 맡길 때도 똑같은 일이 벌어진다. 문제는 대부분 프롬프트 문장을 더 정교하게 다듬는 데만 시간을 쓴다는 점이다.

정작 먼저 정해야 하는 건 문장이 아니라 구조다. 무엇이 끝났다는 증거인지, 어디까지 건드려도 되는지, 사고가 나면 누가 책임을 되찾아오는지. 이 구조를 나는 "작업 계약"이라 부른다. 코딩 에이전트든 범용 비서형 AI든 마찬가지다.

왜 프롬프트보다 계약이 먼저인가

프롬프트는 요청서고 계약은 약속이다. "이 버그 고쳐줘"는 요청에 그친다. 반면 "이 파일들 안에서만 고치고, 테스트가 통과해야 끝난 거고, 커밋은 하지 말고 diff만 보여줘"는 약속이다. 요청만 던지면 AI는 빈칸을 자기 판단으로 채운다. 그 판단이 항상 내 생각과 같지는 않다.

실제로 벌어지는 일은 이렇다. "정리해줘"라는 말만 믿고 맡겼더니 지우면 안 될 파일까지 지웠다는 이야기, 배포까지 알아서 해버렸다는 이야기가 낯설지 않다. AI가 나빠서가 아니다. 계약이 없으니 AI가 스스로 계약을 상상해서 채운 것뿐이다. 상상은 늘 사람의 기대와 어긋날 여지가 있다.

계약을 먼저 정하면 역할이 명확해진다. 사람은 무엇을, 어디까지, 무엇으로 증명할지를 정하는 설계자 역할을 하고, AI는 그 틀 안에서 실행하는 역할을 한다. 틀이 없으면 설계자 역할까지 AI에게 떠넘긴 셈이 되고, 그건 위임이 아니라 방치에 가깝다.

정해야 할 6가지

계약이라고 하면 거창해 보이지만 실제로는 질문 6개에 답만 하면 된다. 아래 표는 각 항목이 무슨 질문에 답하는지, 그리고 답을 어떤 형태로 적어야 실제로 쓸모가 있는지 정리한 것이다.

항목	질문	구체적인 형태
목표	끝났을 때 무엇이 달라지는가?	파일, PR, 보고서처럼 눈으로 확인 가능한 산출물
문맥(자료의 출처)	무엇이 진짜 기준 자료인가?	저장소 경로, 원본 자료, 이슈 번호, 로그, 최신 지시사항
범위	읽고 고칠 수 있는 곳은 어디인가?	포함할 경로와 제외할 경로를 같이 적는다
제약	절대 하면 안 되는 것은?	비밀번호·운영 배포·되돌릴 수 없는 명령·외부 결제·권한 상승
검증	무엇으로 끝났다고 증명하는가?	테스트 실행 결과, 변경 내역(diff) 확인, 화면 캡처, 로그, 수동 점검표
산출·인계	다음 사람은 무엇을 알아야 하는가?	변경 요약, 증거, 확인 못 한 부분, 재개할 위치

여섯 항목 중 가장 자주 빠지는 건 '문맥'과 '인계'다. 목표와 제약은 다들 신경 쓰지만, "이 판단의 근거 자료가 어디냐"와 "다음 사람(또는 다음 세션의 나 자신)이 뭘 알아야 하냐"는 잊기 쉽다. AI 에이전트는 대화가 끝나면 그 순간의 기억을 통째로 잃는다. 다음에 다시 부를 때는 완전히 새로운 사람을 처음 채용하는 것과 같다. 인계 문서가 없으면 매번 처음부터 설명해야 하고, 설명이 빠지면 그 빈틈을 또 AI가 자기 판단으로 채운다.

위임 수준부터 정한다

계약 항목을 채우기 전에 먼저 정할 게 하나 더 있다. 이번 작업이 어느 수준의 위임(맡기는 일의 무게)인지다. 같은 "코드 좀 봐줘"라도 그냥 설명만 듣고 싶은 건지, 파일을 직접 고쳐도 되는 건지는 완전히 다른 계약이 필요하다. 아래 4단계로 나눠보면 헷갈리지 않는다.

• 1단계, 질문 답변: 아무것도 고치지 않고 설명만 한다. 예를 들어 "이 함수가 왜 느린지 원인만 알려줘"다. 필요한 건 딱 하나, 기준 자료가 어디인지와 AI가 확신하지 못하는 부분을 솔직히 구분해서 말해주는 것뿐이다.
• 2단계, 로컬 편집: 내 컴퓨터나 저장소 안에서 파일을 실제로 고친다. 이때부터는 범위(어느 파일까지 건드려도 되는지)와 검증 방법(테스트를 돌려서 확인할지, 눈으로 diff를 볼지)을 반드시 정해야 한다. 작업이 끝나면 그 변경 내역과 테스트 결과가 곧 증거다.
• 3단계, 외부 상태 변경: 실제 서비스에 배포하거나, 결제를 진행하거나, 계정 권한을 바꾸는 일이다. 되돌릴 수 없거나 되돌리기 매우 번거로운 영역이라 사람이 미리 승인하는 지점(승인선)과 문제 생겼을 때 되돌리는 방법(롤백)을 작업 시작 전에 정해둬야 한다. 이 단계는 AI 혼자 판단해서 넘어가게 두면 안 된다.
• 4단계, 반복 운영: 같은 일을 계속 시킬 거라면, 그때마다 계약을 새로 설명하지 말고 문서로 승격한다. 프로젝트 규칙 파일, 매뉴얼, 정해진 절차, 자동 점검 스크립트 같은 형태다. 한 번 잘 정리해두면 다음부터는 그 문서를 가리키기만 하면 된다.

단계가 올라갈수록 사고 났을 때 되돌리는 비용이 커진다. 그래서 1단계면 대충 시작해도 괜찮지만 3단계라면 계약서를 문장으로 미리 적어두는 편이 안전하다. 어느 단계인지도 안 정하고 일단 맡기면, AI가 지금 이게 몇 단계 작업인지조차 스스로 추측해야 한다.

먼저 닫아야 할 금지선

계약을 다 정해도, 실수로 넘으면 되돌리기 힘든 영역은 애초에 문 앞에 선을 그어야 한다. 다음은 특히 비용이 큰 영역이다.

• 비밀번호, 토큰, 개인키, 로그인된 브라우저 세션
• 운영 서비스 배포, 데이터베이스 구조 변경(마이그레이션), 결제, 도메인·DNS 설정
• 되돌릴 수 없는 파일 삭제나 초기화 같은 명령
• 동작 검증 장치 없이 진행하는 대규모 코드 재구성
• 원문을 통째로 복사하는 등 저작권 경계가 있는 작업

이 다섯 가지는 프롬프트에 "조심해줘"라고 적는 것만으로는 안 막힌다. AI는 지시를 잊거나, 지금은 예외라고 스스로 판단하거나, 다르게 해석할 수 있다. 부탁은 지켜질 때만 지켜진다. 진짜로 막으려면 애초에 이 영역은 이번 계약의 범위 밖이라고 못 박거나, 시스템 차원에서 실행 자체를 가로막는 장치를 둬야 한다. 계약 문서에 "이 다섯 가지는 이번 작업 범위 밖"이라고 명시하는 것부터가 첫걸음이다.

시작 전 체크리스트

일을 맡기기 직전, 아래 항목에 전부 답할 수 있는지 확인한다. 하나라도 빈칸이면 AI가 그 빈칸을 자기 방식대로 채운다는 뜻이다.

• ☐ 끝났을 때 무엇이 달라져 있어야 하는지 한 문장으로 말할 수 있다
• ☐ 기준 자료(문맥)가 어디에 있는지 경로나 링크로 짚을 수 있다
• ☐ 건드려도 되는 범위와 건드리면 안 되는 범위를 둘 다 적었다
• ☐ 절대 하면 안 되는 것(제약)을 구체적으로 나열했다
• ☐ 완료를 증명할 검증 방법(테스트, diff, 화면 확인 등)을 정했다
• ☐ 이번 작업이 위임 4단계 중 몇 단계인지 정했다
• ☐ 3단계 이상이면 사람이 승인할 지점과 되돌리는 방법을 미리 정했다
• ☐ 다음 사람(또는 다음 세션)에게 넘길 인계 내용의 형식을 정했다

이 체크리스트를 매번 처음부터 채우기 번거롭다면, 자주 하는 작업 유형별로 미리 템플릿을 만들어두는 것도 방법이다. 계획을 다른 검증자에게 확인받는 절차를 계약에 포함시키는 방식은 한 모델만 믿지 말고 AI 코드 교차 검증하는 법에서 더 자세히 다뤘다.

반복되는 일은 계약을 문서로 승격한다

같은 종류의 작업을 세 번째 맡기고 있다면, 그건 이미 반복 운영 단계에 들어선 것이다. 매번 같은 설명을 다시 타이핑하고 있다면 신호다. 이럴 때는 계약 내용을 대화창이 아니라 프로젝트 규칙 파일이나 별도 문서로 옮긴다.

내가 관리하는 지식 저장소에서도 같은 원칙을 쓴다. 원본 자료는 원문 그대로 보존하는 창고에 두고, 반복해서 참고할 결론만 별도 문서로 정리해 승격한다. 매번 새로 판단하지 않고 이미 정리된 결론을 가리키기만 하면 되니 속도도 빨라지고 판단도 흔들리지 않는다. 이 승격 작업의 구체적인 흐름은 LLM 활용 카테고리의 다른 글에서 더 볼 수 있다.

문서로 옮겨둔 계약은 다음 세 가지를 항상 포함해야 쓸모가 있다. 무엇을 끝내야 하는지, 어디까지 건드려도 되는지, 무엇으로 증명하는지. 이 세 줄만 프로젝트 맨 앞에 고정해둬도 매번 처음부터 설명하는 수고가 크게 줄어든다.

결국 AI에게 일을 잘 맡기는 기술은 프롬프트를 화려하게 쓰는 기술이 아니다. 무엇을, 어디까지, 무엇으로 증명할지를 일하기 전에 정하는 습관이다. 이 습관 하나만 들여도 "알아서 해줘"라고 던져놓고 불안해하는 일이 줄어든다. 남은 숙제는 이 계약을 팀 단위로 공유할 때 버전을 어떻게 관리할지다. 한 사람의 머릿속에만 있는 규칙은 그 사람이 자리를 비우는 순간 사라진다.