AI 직원 4명을 만들었는데 사용량 한도에 걸렸다

AI 직원 네 명은 업무 역할을 나눈 에이전트였다

모임 전에 안내를 보내고, 고객 문의에 답하고, 매일 커뮤니티에 뉴스를 전달하는 일은 하나씩 보면 작다. 혼자 운영하면 각각의 발송 시점과 대상을 계속 기억해야 한다. AI 자동화가 유용한 지점은 여기다. 하지만 일정이 생기면 사용량도 반복해서 발생하고, 그 한도가 찼을 때 처리할 일을 사람이 다시 맡아야 한다.

지피터스의 한이룸은 1인 운영자로서 OpenClaw에 총괄·리서치·기획·글쓰기 역할을 만들고 모임 안내, 카카오 비즈톡 답변, 하루 두 번의 뉴스 전달, 이메일과 뉴스레터 초안을 연결했다고 밝혔다. 이메일은 사전 승인 뒤 발송했고 뉴스레터 초안도 직접 검토했다고 설명했다. 직원 네 명을 해고한 사례가 아니라 네 에이전트의 역할을 정한 경험이다. 지피터스 AI 직원 사례

같은 글에는 비용과 중단 경험도 있다. 초기 스케줄 실험 후 10만원 결제를 경험했다고 밝혔고, 이후 사용량 한도를 채우면 총괄 에이전트가 텔레그램에서 더 답하지 못했다고 설명했다. 10만원은 당시 개인 실험의 결과이며 현재 서비스의 표준 운영 요금이 아니다. 반복 전달은 편해졌지만 사용량과 다듬는 작업은 남았다.

OpenClaw 공식 문서는 에이전트별 작업 공간과 상태, 대화 기록을 구분한다. 역할을 나누면 문맥과 맡을 일을 구분할 수 있지만 공급자의 사용량 한도까지 독립적으로 늘어난다는 뜻은 아니다. 도입팀은 네 역할이 어느 모델과 계정을 사용하는지부터 확인해야 한다. OpenClaw 다중 에이전트 구성

자동화를 준비할 때는 자동화가 편리했던 업무뿐 아니라 사람이 맡은 검토도 함께 봐야 한다. 정해진 모임 안내를 보내는 일과 개별 고객에게 답하면서 새로운 약속을 만드는 일은 다른 기준을 요구한다. 에이전트 이름을 만드는 것보다 업무마다 입력·완료 조건·승인자를 적는 일이 먼저다.

한 번의 업무에도 여러 번의 AI 호출이 들어간다

자동화 운영을 설계할 때는 사람에게 보이는 실행 횟수와 모델 호출 횟수를 나눠 세야 한다. 뉴스를 한 번 보내더라도 자료 검색, 후보 선별, 요약, 문장 수정, 최종 확인에 각각 모델을 쓸 수 있다. 총괄이 다른 에이전트에게 설명을 넘기고 결과를 다시 읽는 과정도 추가 입력과 출력을 만든다.

예를 들어 하루 두 번 실행하고 매번 세 단계에서 모델을 호출한다는 가정이라면, 기본 호출은 하루 여섯 번이다. 검색 결과가 부족해 다시 찾거나 생성 문장을 고치면 실제 호출은 늘어난다. 이 숫자는 사례의 실제 사용량이 아니라 운영자가 호출 구조를 셀 때 쓰는 계산 예시다.

호출 수만 기록해도 비용의 전부는 보이지 않는다. 같은 한 번이라도 짧은 안내문만 읽는 작업과 긴 자료 전체를 반복해 읽는 작업은 입력량이 다르다. 이전 대화가 길어지고 첨부 자료가 많아질수록 직원 한 명에게 부탁하듯 보낸 짧은 요청에도 많은 문맥이 함께 들어갈 수 있다.

Claude 공식 도움말은 메시지 길이, 첨부 파일 크기, 현재 대화 길이, 도구 사용, 모델 선택, 작업 단계 등이 사용량 한도에 영향을 준다고 설명한다. 사용량 화면에서는 해당 요금제의 세션·주간 사용 상태를 볼 수 있다. 남은 메시지 개수만으로 운영 여유를 판단하기보다 실제 계정에서 현재 사용량을 확인해야 한다. Claude 사용량 안내

도입팀은 자동화마다 정상 실행의 단계와 추가 호출의 원인을 기록한다. 결과가 빈 값이라 재실행한 것인지, 정해진 형식에서 벗어나 다시 생성한 것인지, 사람이 문구를 수정하려고 요청한 것인지 구분한다. 원인이 다른 호출을 모두 재시도라고 묶으면 줄일 방법도 모호해진다.

이 표는 운영 설계를 위한 기록안이다. 결과 파일이나 발송 기록이 이미 있으면 다음 단계에서 그것을 재사용하도록 연결한다. 에이전트가 일을 넘길 때도 모든 대화 대신 목표, 필요한 자료, 완료된 결과, 남은 쟁점을 전달하면 담당 에이전트가 다시 처음부터 조사하는 일을 줄일 수 있다.

구축 때 쓴 비용과 매달 반복되는 비용을 나눈다

처음 만들 때는 시행착오가 많아도 실제 운영에서는 줄어들 수 있다. 반대로 시연 한 번은 저렴했는데 매일 실행하면서 비용이 커질 수 있다. 도입팀은 코드 생성과 테스트에 쓴 비용, 정기 실행 비용, 장애를 고치느라 추가로 쓴 비용을 따로 봐야 한다.

정기 비용에는 모델 사용만 들어가지 않는다. 서버가 실행되는 비용, 워크플로우 도구, 이메일·문자 발송, 외부 데이터 서비스가 붙을 수 있다. 구독을 이미 내고 있다는 이유로 자동화 전체 비용을 0으로 잡으면 신규 실행에 필요한 여유와 외부 서비스 비용을 놓친다.

자동화별 비용표에는 실행 빈도와 사용하는 서비스를 먼저 적는다. 정해진 시간마다 보내는 뉴스와 고객이 문의할 때만 생성하는 답변은 비용을 예측하는 기준이 다르다. 문의가 늘었을 때 어느 단계가 함께 늘어나는지, 승인 대기 중인 결과를 다시 만들고 있지는 않은지 확인한다.

운영자가 정할 예산도 하나로 묶지 않는 편이 좋다. 새 기능 시험에 쓸 한도와 기존 고객 업무에 남겨둘 여유를 구분한다. 실험 도중 기본 안내까지 응답하지 못하면 시험 비용이 업무 장애로 이어진다. 공급자의 한도와 별개로 자동화 실행 빈도와 추가 시도를 제한하는 규칙을 둘 수 있다.

한도 소진, 호출 속도 제한, 결제 오류는 같은 상태가 아니다. 잠시 뒤 처리할 수 있는 호출 제한과 예산을 다 쓴 상태를 같은 재시도로 연결하면 불필요한 실행이 쌓인다. 실패 원인을 구분해 대기, 실행 중지, 담당자 확인으로 나눠야 한다.

n8n 공식 문서는 호출 빈도 제한에 재시도 사이의 대기와 배치를 적용하는 방식을 설명한다. 이 기능은 요청 속도를 조절하는 데 쓰이며, 이미 소진한 예산을 늘려주는 기능이 아니다. 운영자는 서비스가 반환한 오류와 사용량 상태를 보고 해당 처리를 선택해야 한다. n8n 호출 제한 문서

정해진 안내문을 매번 새로 쓰게 할 필요는 없다

사용량을 줄이는 첫 방법은 모든 단계에 생성 모델이 필요한지 보는 것이다. 정해진 대상 목록을 읽고 발송 시간을 계산하는 일, 승인한 안내문에서 날짜·장소를 바꾸는 일은 고정 규칙과 템플릿으로 처리할 수 있다. 새로운 내용에 맞는 문장을 만드는 부분에 모델을 쓰면 운영 구조가 더 분명해진다.

도입팀은 실제 업무 입력 몇 개로 모델 선택을 시험해야 한다. 답변 길이가 짧다는 이유만으로 쉬운 작업이라고 단정하지 않고, 필요한 근거와 잘못된 답의 영향을 본다. 신청 위치를 안내하는 문구와 계약 조건을 새로 제안하는 답변은 문장 길이가 비슷해도 확인할 내용이 다르다.

시험 결과에는 답변 품질과 함께 수정에 걸린 시간을 기록한다. 호출 비용은 줄었지만 사람이 매번 크게 고쳐야 한다면 전체 업무가 줄지 않을 수 있다. 반대로 승인된 형식을 잘 지키는 작업에 높은 추론 수준을 계속 쓰면 결과 차이 없이 사용량만 커질 수 있다.

실행 빈도도 업무 목적에서 정한다. 자료가 하루 한 번 바뀌는데 몇 분마다 전체를 검색할 필요는 없다. 고객 문의처럼 사건이 생길 때 처리할 일과 정해진 시점에 보낼 일, 사람이 요청할 때만 만들 일을 나눈다. 상태 확인 자체가 매번 긴 모델 대화를 시작하지 않도록 구현한다.

OpenClaw 공식 문서는 스케줄 실행, 결과 전달, 실패 알림과 실행 기록을 구분해 제공한다. 이 기능을 도입할 때는 일정 등록이 됐는지뿐 아니라 어떤 결과를 어디에 전달해야 완료인지도 정해야 한다. 작업이 실행됐지만 대상 채널에 전달되지 않은 상태를 놓치지 않아야 한다. OpenClaw 일정 자동화

사용량 확인 기능과 공급자 계정의 사용량 화면도 함께 본다. 도구에 표시된 실행 횟수, 입력·출력량, 계정의 남은 한도는 서로 다른 지표다. OpenClaw는 사용량 추적 기능을 제공하지만 운영자는 현재 연결 방식에서 어떤 정보를 표시하는지 확인하고, 이를 실제 계정 사용량과 대조해야 한다. OpenClaw 사용량 추적

총괄이 답하지 못해도 어느 업무가 밀렸는지 알아야 한다

총괄 에이전트가 메신저에서 응답하지 못하는 것과 모든 스케줄 작업이 멈추는 것은 다른 상태다. 업무가 서로 다른 연결과 실행 경로를 사용하면 일부는 계속될 수 있다. 장애 알림도 전체 중단이라고 뭉뚱그리기보다 실제로 실패하거나 확인을 기다리는 업무를 알려야 한다.

Threads의 system_flow_official은 연결이 며칠 끊겼지만 자동 발행은 유지됐고, 사람의 확인이 필요한 답글만 밀렸다고 설명했다. 이 경험을 완전한 시스템 중단으로 읽으면 운영자가 찾아야 할 지점을 놓친다. 자동 발행, 승인 대기, 문의 응답의 상태를 따로 봐야 한다. 연결 장애와 일부 업무 지연 경험

도입 설계에서는 업무별 마지막 성공과 다음 예정 시점, 대기 이유를 기록한다. 알림에는 실패 업무, 영향을 받은 대상, 이미 처리한 부분, 사람이 이어서 할 일을 넣는다. 단순히 오류라고만 보내면 운영자가 다시 여러 화면을 열어 상태를 복원해야 한다.

이 표는 업무를 이어가기 위한 적용안이다. 수동 처리를 할 때도 같은 발송 기록을 사용해야 한다. 사람이 대신 보낸 뒤 자동화가 재개돼 또 보내는 일을 막으려면 대상과 발송 상태를 갱신한다. 생성이 끝난 초안과 실제 전달된 메시지를 같은 완료로 취급해서는 안 된다.

반복 알림이 많아지면 운영자는 중요한 장애까지 무시할 수 있다. 같은 원인으로 대기 중인 작업은 묶고, 처리 대상이나 마감 영향이 바뀔 때 알림을 갱신한다. 이미 사람이 맡은 업무를 계속 생성하지 않도록 수동 처리 중이라는 상태도 둔다.

줄어든 수작업 시간에서 확인·수정·복구 시간을 뺀다

운영 성과를 계산하려면 자동화 전후의 같은 업무를 비교해야 한다. 모임 안내 문구 작성과 발송에 쓰던 시간에서 자동화 후 초안 확인, 대상 수정, 오류 복구에 쓰는 시간을 뺀다. 사람이 직접 처리하던 부분이 자동화 뒤 다른 확인 업무로 바뀌었을 수 있다.

Reddit의 한 자동화 운영 토론은 재시도로 인한 중복, API 변경, 예상하지 못한 예외, 모니터링·디버깅이 새로운 관리 일이 되는 문제를 제기했다. 댓글에서는 결과가 사라졌는지 쉽게 알아볼 수 있는 구조와 안정된 업무부터 자동화하는 경험이 이어졌다. 모든 자동화가 실패한다는 결론보다, 운영 뒤에 생긴 일도 비용에 넣어야 한다는 논점이다. 자동화 유지보수 토론

도입팀은 처음 구축한 시간을 일회성으로 기록하고 정기 확인과 장애 대응은 반복 운영 시간으로 둔다. 기능을 추가할 때마다 같은 오류를 고치는지, 입력 양식이 자주 바뀌어 매주 코드를 수정하는지 살펴본다. 아직 업무 절차가 안정되지 않았다면 전부 자동으로 연결하기보다 초안과 승인 단계까지 범위를 좁힐 수 있다.

결과 검토를 무조건 없애는 것도 운영 효과의 조건은 아니다. 고객에게 나가는 내용의 승인과 뉴스레터 초안의 편집은 남겨둘 가치가 있다. 그 앞의 자료 수집과 초안 생성이 줄어들면 사람이 중요한 검토에 집중할 수 있다. 어떤 확인은 남기고 어떤 반복은 줄였는지 구체적으로 기록해야 한다.

처리량만 늘리고 완료 결과를 확인하지 않으면 바쁘게 돌아가는 자동화가 성과처럼 보인다. 생성한 안내문, 실제 보낸 메시지, 승인 대기, 실패 후 수동 처리 건을 나누어 봐야 한다. 시간 절감과 비용도 이 결과 단위에 맞춰 계산한다.

AI 직원 네 역할을 만든 뒤에도 운영자는 실행 범위와 승인, 사용량, 실패 대응을 맡는다. 도입을 계속할지 판단하는 기준은 에이전트가 몇 명인지가 아니다. 필요한 연락과 결과물이 제때 나가고, 확인과 복구까지 포함한 업무가 줄었는지다. 한도에 닿아도 다음 행동을 알 수 있는 자동화가 반복 업무를 맡을 수 있다.

자주 묻는 질문