장시간 AI 작업의 첫 비용 상한과 중지 조건

먼저 구분하자: 장시간 AI는 하나의 스위치가 아니다

많은 팀은 새 모델을 시험할 때 질문을 이렇게 던진다. “이 모델을 모두에게 열어줄까?”

이 질문은 너무 거칠다. 더 좋은 질문은 이것이다. “어떤 종류의 작업은 끝까지 자동 실행해도 되는가? 어떤 작업은 초안까지만 맡겨야 하는가? 어떤 작업은 매 단계마다 사람이 확인해야 하는가?”

예를 들어, 같은 AI 에이전트라도 다음은 서로 다른 작업이다.

• 공개 자료 20개를 정리해 연구 요약을 만드는 작업.
• 코드 저장소 안의 코드를 수정하고 pull request를 여는 작업(리뷰 후 반영되는 코드 변경 제안).
• 고객 데이터를 읽고 답변을 보내며 CRM(고객 관계 관리 시스템)을 업데이트하는 작업.

AI 에이전트에게 코드를 쓰게 하려는 중이라면 이 글도 함께 보면 좋다. AI 에이전트에게 코드를 맡기기 전, 작업 안에 체크포인트를 넣자. 그 글은 “작업 중 어디에 멈춤 지점을 넣을 것인가”를 다루고, 이 글은 “각 멈춤 지점 전에 토큰을 얼마나 쓰고, 비용을 얼마나 쓰며, 몇 번까지 재시도할 수 있는가”를 보완한다.

작은 팀의 작업 흐름에 연결하는 5단계

상한표가 생겼다고 바로 전사에 열어줄 필요는 없다. 다음 단계는 작은 경로 하나로 시험 실행하는 것이다. 아래 절차는 3명에서 20명 규모의 작은 팀, 특히 전담 AI 플랫폼 팀이 아직 없는 상황에 적합하다.

1. 먼저 “출력을 검수할 수 있는” 장시간 작업 하나를 고른다

첫 작업으로 “나를 좀 더 똑똑하게 만들어줘”처럼 결과가 모호한 요구를 고르지 말자. 출력물을 확인할 수 있고, 실패해도 회수할 수 있는 작업을 고른다. 예를 들면 다음과 같다.

• 공개 문서 15개를 한 페이지 요약으로 정리한다.
• 고객 메시지 30개를 5개 유형으로 나누고, 각 유형별 대표 사례 3개를 제시한다.
• 작은 pull request를 읽고 사람이 봐야 할 가능성이 있는 파일을 나열한다.
• 내부 SOP를 신입용 버전으로 다시 쓰되, 바로 게시하지 않는다.

판단 기준은 단순하다. 출력이 틀렸을 때 10분 안에 알아볼 수 있는가? 아니라면 첫 번째 파일럿 작업으로는 적합하지 않다.

2. 작업이 “최대로 읽을 수 있는 것”을 명시한다

장시간 작업은 문맥을 쉽게 가득 채운다. 문맥은 AI가 현재 읽고, 기억하고, 추론에 사용할 수 있는 자료라고 이해하면 된다. 많이 읽는다고 꼭 더 정확해지는 것은 아니다. 자료 범위가 불명확하면 오히려 오래된 정보나 무관한 내용이 섞일 가능성이 커진다.

작업 명세에 다음처럼 적을 수 있다.

• 지정한 폴더나 지정한 URL만 읽을 수 있다.
• 한 번에 최대 10개 파일까지만 읽을 수 있다.
• 책임자가 승인하지 않는 한 각 파일은 제목, 요약, 최근 30줄의 변경 내용만 읽는다.
• 고객 개인정보, 결제 자료, 비밀키, 내부 급여, 계약서 원문은 읽을 수 없다.

이런 제한은 “조심해서 처리해줘”보다 유용하다. 에이전트를 프로그램 수준에서 막을 수 있기 때문이다.

3. 시험 실행과 실제 실행의 차이를 정한다

dry-run(데이터 변경이나 게시를 실제로 하지 않고 먼저 시도해보는 실행)은 먼저 데이터를 바꾸거나 게시하지 않는 방식이다. 장시간 작업 에이전트가 처음 작업 흐름에 들어올 때 기본값은 dry-run이어야 한다.

예를 들어 코딩 에이전트는 다음을 할 수 있다.

• issue(요청 티켓)를 읽는다.
• 관련 파일을 찾는다.
• 수정 계획을 제안한다.
• patch(제안된 변경 diff)를 생성한다.
• 테스트 제안을 작성한다.

하지만 바로 다음을 해서는 안 된다.

• main branch에 push한다.
• pull request를 merge한다.
• production config(실서비스 설정)를 변경한다.
• package를 배포한다.

문서 에이전트도 마찬가지다. 초안과 차이 요약은 만들 수 있지만, 공식 문서를 바로 덮어쓰면 안 된다. 시험 실행 결과를 5~10번 살펴보고 실패 양상이 예측 가능해진 뒤에야 다음 단계를 열지 검토한다.

4. “중지 조건”을 if–then으로 쓴다

중지 조건은 추상적인 주의 문구로 쓰지 말자. if–then으로 적어야 한다.

• 작업이 해당 등급에서 승인된 토큰 또는 비용 상한을 넘길 것으로 예상되면 먼저 계획만 출력하고 전체 실행에 들어가지 않는다. 예를 들어 L2 상한이 60,000 토큰이라면 그 값에 도달하기 전에 멈추고, 책임자가 범위를 줄일지 여부를 결정하게 한다.
• 작업이 해당 단계에 승인된 재시도 상한에 도달한 뒤에도 완료되지 않으면 즉시 멈추고 마지막 오류를 기록한다. 책임자는 범위를 줄일지, 다른 방법을 쓸지, 작업을 끝낼지 결정한다. L1과 L3은 한 번 재시도한 뒤에도 실패하면 멈추고, L2는 최대 두 번까지 허용하며, L4는 자동 재시도를 허용하지 않는다.
• 승인 목록에 없는 데이터 출처가 필요하면 실행을 멈추고 이유를 나열한다.
• 출력물이 외부 사용자에게 보이는 내용을 바꾸게 된다면, 초안 상태에서 멈춘다.
• 작업 중 결제, 삭제, 권한 승격, 공식 약속이 등장하면, 실행하지 말고 제안만 만든다.

이 문장들은 에이전트의 system prompt(에이전트가 시작할 때 읽는 시스템 지침)에 넣어 모델이 스스로 멈춰야 할 때를 알리는 데 쓸 수 있다. 그러나 prompt는 강제 비용 계량기, 권한 시스템, 신뢰할 수 있는 중지 스위치가 아니다. 실제 토큰·비용·재시도 상한은 모델 밖의 작업 흐름 제어기가 강제로 적용해야 한다. 제어기는 각 호출에서 보고된 입력·출력 토큰, 도구 비용, 재시도 횟수를 누적하고 다음 호출 전에 남은 예산을 확인한다. 남은 예산으로 다음 호출을 감당할 수 없으면 요청을 보내지 않고 현재 결과와 사람의 판단을 기다리는 항목만 반환한다. 삭제, 결제, 공식 발송, 게시, 권한 승격은 실행 자격 증명을 처음부터 주지 않아야 하며, prompt에 “하지 말라”고 쓰는 것으로 대신해서는 안 된다.

5. 매주 하나의 손잡이만 조정한다

시험 실행 뒤에는 몇 가지 흔한 결과가 보일 것이다.

• 작업이 끝나기 전에 토큰 상한에 자주 부딪힌다.
• 비용은 낮지만 사람의 검수 시간이 너무 오래 걸린다.
• 재시도 횟수가 많아 총비용을 예측하기 어려워진다.
• 저위험 작업은 너무 많이 막히고, 고위험 작업은 오히려 너무 쉽게 다음 단계로 넘어간다.

한 번에 전부 조정하지 말자. 매주 하나의 손잡이만 바꾼다. 예를 들면 다음과 같다.

• L1 토큰 상한을 20,000에서 30,000으로 올린다.
• L2 재시도 상한을 2회에서 1회로 낮춘다.
• L3를 “수정안 생성 가능”에서 “수정 계획만 생성 가능”으로 바꾼다.
• 외부 게시 전 책임자 확인 필드를 하나 추가한다.

작은 팀의 가장 큰 장점은 거버넌스 문서가 많다는 것이 아니다. 어떤 상한이 너무 빡빡하고, 어떤 멈춤 지점이 너무 느슨한지 빠르게 볼 수 있다는 점이다. 한 번에 하나만 바꿔야 어떤 변경이 효과가 있었는지 알 수 있다.

작은 팀의 첫 번째 실행 가능한 버전

오늘 한 가지만 할 수 있다면 “장시간 AI 작업 신청 카드”를 만들자. 새 도구를 살 필요는 없다. Notion, Google Sheet, Linear, GitHub issue template이면 충분하다.

권장 필드는 다음과 같다.

1. 작업 이름: 예를 들어 “경쟁사 공지 15개 정리”.
2. 작업 단계: L1, L2, L3 또는 L4.
3. 읽을 수 있는 자료: 폴더, URL, 문서 이름을 나열한다.
4. 읽을 수 없는 자료: 고객 개인정보, 결제 정보, 비밀키, 계약서 원문 등.
5. 문맥 상한: 예를 들어 1회 실행에서 최대 10개 파일, 파일별 최근 30줄 변경분, 총 40,000개 입력 토큰까지만 읽는다. 이를 넘으면 먼저 요약하고 책임자에게 계속 진행 여부를 물어본다.
6. 토큰 상한: 표의 시작값을 넣는다.
7. 1회 비용 상한: 표의 시작값을 넣는다.
8. 재시도 상한: 0, 1 또는 2회.
9. 중지 조건: 최소 3개의 if–then을 쓴다.
10. 책임자: 누가 검수하고 다음 단계를 승인할지 정한다.
11. 출력 상태: 초안, 제안, 수정안, 실제 실행 중 하나만 가능하게 한다.

이 카드의 목적은 행정 절차를 늘리는 것이 아니다. 모두가 알 수 있게 하는 것이다. AI가 어디까지 갈 수 있는지, 어디서 멈춰야 하는지, 누가 봐야 하는지, 비용이 얼마를 넘으면 더 진행할 수 없는지를 명확히 만드는 것이다.

생활 4컷 만화

1. 이사를 앞둔 세 친구는 방에 놓인 상자 세 개를 보고 오늘 무리 없이 정리할 수 있겠다고 생각한다.
2. 하지만 옷장과 선반을 열자 예상보다 훨씬 많은 물건이 나온다.
3. 세 사람은 잠시 멈추고 오늘 할 일을 간단한 세 항목 체크리스트로 줄여, 함께 합의한 범위만 처리하기로 한다.
4. 합의한 상자만 봉하고, 남은 물건은 다음에 이어서 정리할 수 있도록 가지런히 남겨 둔다.