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

작업 계약을 실행 가능한 문장으로 바꾸기

여섯 항목은 제목만 채우면 계약이 되지 않는다. “안전하게 고쳐라”, “관련 파일만 수정하라”, “잘 확인하라”처럼 사람마다 해석이 달라지는 말이 남아 있으면 실행자는 다시 빈칸을 추측한다. 로컬 코드의 버그 하나를 고치는 2단계 작업이라면 아래처럼 경로와 증거가 보이는 문장으로 바꿀 수 있다.

목표: 제공된 재현 절차에서 발생하는 오류를 최소 변경으로 고친다.
문맥: 이슈 설명, 실패 로그, 현재 저장소 코드를 기준 자료로 삼는다.
범위: 지정한 파일은 읽고 수정할 수 있다. 제외 경로는 수정하지 않는다.
제약: 비밀정보를 출력하지 않고, 배포·결제·권한 변경·파괴적 명령을 실행하지 않는다.
검증: 재현 테스트와 관련 테스트를 실행하고, 변경 파일 목록을 범위와 대조한다.
산출·인계: 바꾼 이유, 실행한 명령, 실제 결과, 확인하지 못한 부분을 남긴다.

여기서 중요한 것은 길이가 아니라 판정 가능성이다. “최소 변경”만 적으면 사람마다 뜻이 다르므로 수정 허용 파일과 제외 경로가 뒤따라야 한다. “테스트한다”만 적으면 어떤 실패가 고쳐졌는지 알 수 없으므로 재현 테스트와 관련 테스트를 나눈다. “결과를 알려 달라”만 적으면 성공한 출력만 남기기 쉬우므로 확인하지 못한 부분까지 인계 항목에 넣는다.

실행 전에는 계약을 위에서 아래로 한 번 읽으며 각 문장이 실제 행동을 막거나 증명하는지 확인한다. 목표에 산출물이 없으면 끝을 판정할 수 없다. 문맥에 기준 자료가 없으면 서로 충돌하는 설명 중 무엇을 믿을지 정할 수 없다. 범위에 제외 대상이 없으면 읽어도 되는 곳과 고쳐도 되는 곳을 혼동하기 쉽다. 제약에 외부 상태 변경이 빠지면 로컬 편집 요청이 배포로 번질 수 있다. 검증 명령이 없으면 “코드가 그럴듯해 보인다”가 완료 증거를 대신한다.

확인 시점	묻는 질문	남길 증거
시작 전	이번 일은 1~4단계 중 어디까지인가?	허용 행동과 사람 승인선
첫 수정 전	기준 자료와 실제 상태가 충돌하지 않는가?	읽은 경로와 재현한 실패
수정 뒤	허용 범위 밖 파일이 바뀌지 않았는가?	git diff --name-only 같은 변경 파일 목록
완료 전	정한 검증이 실제로 통과했는가?	실행한 명령과 성공·실패 출력
인계 때	다음 사람이 다시 추측해야 할 빈칸이 남았는가?	남은 위험과 재개 위치

3단계 작업은 같은 틀에 승인선과 롤백을 더한다. 예를 들어 “배포한다”는 목표가 있더라도 배포 직전까지 자동으로 진행할지, 사람이 결과를 보고 승인한 뒤 실제 운영 상태를 바꿀지를 구분한다. 승인 전 산출물과 승인 후 외부 변경을 한 문장에 섞지 않는 것이 핵심이다. 반대로 1단계 질문 답변에 배포용 계약 전체를 붙이면 필요한 설명보다 절차가 커진다. 위임 수준에 맞춰 항목의 깊이를 조절하되, 목표·범위·증거 세 줄은 어느 단계에서도 남긴다.

작업 뒤에는 계약과 실제 행동을 대조한다. 테스트가 실패했는데 이유만 설명하고 끝냈다면 검증 조건을 충족하지 못한 것이다. 허용 경로 밖 변경이 보인다면 내용이 좋아도 범위를 어긴 것이다. 확인하지 못한 항목을 인계에 적었다면 실패를 숨긴 것이 아니라 계약대로 불확실성을 넘긴 것이다. 이 대조가 있어야 다음 세션에서 프롬프트를 다시 꾸미는 대신, 빠졌던 계약 문장 하나를 고칠 수 있다.

자주 묻는 질문

프롬프트를 자세히 쓰면 별도의 작업 계약은 필요 없는가?

자세한 요청만으로는 AI가 빈칸을 자기 판단으로 채우는 일을 막기 어렵다. 목표·기준 자료·수정 범위·금지선·검증 방법·인계 형식을 정해 무엇을 어디까지 하고 어떤 증거로 끝낼지 먼저 고정해야 한다.

로컬 파일을 직접 고치게 할 때 꼭 정해야 할 것은 무엇인가?

로컬 편집은 위임 2단계에 해당한다. 어느 파일까지 건드려도 되는지 범위를 정하고, 테스트 결과나 변경 내역처럼 완료를 확인할 검증 방법을 미리 정해야 작업 결과가 곧 증거가 된다.

배포나 결제를 지시했다면 에이전트가 바로 실행해도 되는가?

배포·결제·권한 변경은 되돌리기 어렵거나 번거로운 위임 3단계다. 작업 시작 전에 사람이 승인할 지점과 문제가 생겼을 때의 롤백 방법을 정하고, 에이전트 혼자 판단해 승인선을 넘지 못하게 해야 한다.

같은 종류의 일을 세 번째 맡길 때도 계약을 다시 설명해야 하는가?

세 번째 반복이라면 이미 반복 운영 단계로 보고 계약을 프로젝트 규칙이나 별도 문서로 승격하는 편이 낫다. 목표·허용 범위·완료 증거를 고정해 두면 다음 작업부터 그 문서를 기준으로 삼을 수 있다.