AI에게 일을 맡길 때, 프롬프트보다 먼저 정할 6가지

완료라고 했는데 왜 안 끝났을까

나는 2026년 8월, 그동안 AI에게 보낸 프롬프트 32,522개를 다시 봤다. 구현을 요청한 입력 178개 중 검증 조건이 들어간 건 25개뿐이었다. 반면 결과가 맞는지 다시 따진 기록은 1,001번이었다.

검증을 안 한 게 아니었다. 순서가 뒤집혀 있었다. 일을 맡길 때는 완료 기준을 빼놓고, 일이 틀어진 뒤에야 “진짜 되는 거 맞아?”라고 물었다. AI가 추측한 완료와 내가 기대한 완료가 다르니 재작업이 생겼다.

내가 쓰는 6줄 계약

1. 목표

   이번 작업으로 바뀌어야 하는 상태를 한 문장으로 적는다.

2. 비목표

   건드리지 않을 범위를 적는다. 범위가 넓어지는 걸 막는 가장 싼 장치다.

3. 대상 환경

   어느 저장소, 화면, 계정, 배포 대상을 다루는지 고정한다.

4. SOT

   무엇을 정답의 원천으로 볼지 정한다. 최신 문서와 실제 운영 데이터를 구분한다.

5. 완료 증거

   테스트, 실제 화면, 운영 데이터처럼 ‘끝났다’를 증명할 관측값을 적는다.

6. 부작용 허용 범위

   비용, 외부 발송, 운영 데이터, 삭제처럼 멈춰서 확인받을 경계를 정한다.

질문은 부작용 경계에서만

계약이 길어지면 AI는 자꾸 멈춘다. 그래서 모든 분기에서 허락을 받게 하지 않는다. 되돌릴 수 있는 탐색과 로컬 수정은 맡기고, 돈이 나가거나 밖으로 발송되거나 운영 데이터를 바꾸는 지점에서만 멈추게 한다.

자율성을 줄이는 게 목적이 아니다. 안전하게 맡길 수 있는 범위를 넓히는 게 목적이다. 마지막 버튼만 사람이 누르면, AI는 그 전까지 훨씬 멀리 갈 수 있다.

검증을 뒤에서 앞으로 옮긴다

프롬프트를 더 길게 쓰는 것보다 완료 증거를 먼저 정하는 편이 효과가 컸다. “다 해줘” 대신 “이 테스트와 실제 화면으로 완료를 증명해줘”라고 맡긴다. AI의 말이 아니라 관측 가능한 결과로 끝내는 것이다.

AI에게 일을 잘 맡기는 사람은 답을 잘 받는 사람이 아니라, 완료를 증명하게 만드는 사람이다.