에이전트로 업무 효율 높이기 ③ 예약 실행으로 매일 돌리고 마지막 확인은 사람이

먼저 결론

• 에이전트의 효율이 가장 크게 오르는 순간은 내가 말하지 않아도 일할 때이니, 정해진 시각에 실행되도록 예약합니다.
• 결과는 한곳에 모읍니다. 여러 에이전트가 일해도 결과가 같은 데이터베이스에 쌓이면 확인이 쉽습니다.
• 결과물의 "AI가 만든 느낌"은 디자인 지침이나 스킬로 줄이고, 비용은 모델 선택과 대화 정리로 관리합니다.
• 보안(API 키), 출처 표시, 사람 확인은 자동화할수록 더 챙겨야 합니다.

연재 순서: ① 맡길 일을 고르고 목표·데이터·스킬 준비하기 · ② 총괄 하나와 역할별 담당으로 팀 나누기 · ③ 예약 실행으로 매일 돌리고 마지막 확인은 사람이

1. 말하지 않아도 일하게 예약해 둔다

반복 업무인데 매번 내가 시킨다면, AI를 쓰고는 있어도 비효율적입니다. 그래서 아침마다 말하지 않아도 일하는 AI 직원을 만듭니다.

만드는 순서는 이렇습니다.

1. 에이전트 세 개에게 각각 담당 회사를 하나씩 맡긴다.
2. 결과를 쓸 곳으로 같은 노션 데이터베이스 하나를 지정한다. 보고서가 여기저기 흩어지면 확인하기 어렵기 때문이다.
3. 매일 아침 7시에 실행되도록 예약하고, 결과 페이지에는 회사명과 작업 날짜·시각을 적게 한다.
4. 30초 뒤 실행으로 먼저 시험하고, 에이전트 창을 모두 닫아도 결과가 쌓이는지 확인한다.
5. 마지막으로 구조를 다이어그램으로 그린다. 매일 7시에 세 에이전트가 동시에 일하고, 결과는 같은 데이터베이스로 간다는 것이 한눈에 보인다.

여기서 배울 점은 두 가지입니다. 먼저 시험 실행부터 합니다. 다음 날 아침까지 기다리지 말고, 몇십 초 뒤 실행으로 설정이 맞는지 먼저 확인합니다.

다음은 창을 닫아도 도는지 확인하는 것입니다. 예약이 내 컴퓨터에 묶여 있는지, 클라우드에서 도는지에 따라 운영 방법이 달라집니다.

제 경우에는 평일 아침 7시에 브리핑을 받습니다. 그날 마감인 일, 새 글, 팀 일정을 모아 보내는 기능입니다. 출근해서 무엇부터 할지 찾는 시간이 사라진 것이 가장 체감되는 변화였습니다.

이 블로그의 뉴스 스크랩도 같은 방식으로 돕니다. 매일 아침 PC의 작업 스케줄러가 스크랩 도구를 실행해, 정해 둔 검색어로 기사를 고릅니다. 기사 본문은 옮기지 않고 제목·출처·링크와 직접 쓴 요약만 올립니다. 실패하면 텔레그램 알림봇이 알려 줍니다.

다만 예약이 내 PC에 묶여 있으니 PC가 꺼져 있으면 돌지 않습니다. 예약을 만들 때 "어디서 도는가"를 먼저 정해야 하는 이유입니다.

2. 결과는 한곳에 모으고 형식은 스킬에 적는다

자동으로 만들어지는 결과물이 늘어나면 두 가지 문제가 생깁니다. 어디 있는지 모르는 것, 그리고 다 비슷해 보이는 것입니다.

첫 번째 문제는 저장소를 하나로 정해 풉니다. 노션 데이터베이스 하나를 결과 저장소로 정합니다. 젠스파크라면 드라이브에 폴더를 만들어 지금까지 만든 자료를 저장하게 하고, 다른 작업에서도 그 폴더를 불러 씁니다. 파일을 내려받아 다시 올리는 반복이 없어집니다.

두 번째는 AI 느낌입니다. 그냥 "보고서 만들어 줘"라고 하면 흔히 말하는 AI가 만든 느낌이 나기 쉽습니다.

이럴 때 유명 서비스들의 디자인 지침을 모아 둔 사이트에서 원하는 지침을 고릅니다. 그대로 붙여 넣고 "이 지침으로 다시 만들어 줘"라고 합니다.

젠스파크에서 슬라이드를 만들 때는 모드를 바꿉니다. 기본 모드 대신 이미지 생성 모델을 함께 쓰는 "크리에이티브" 모드와 가이드 모드로 사람이 만든 느낌을 냅니다.

저는 결과물 형식도 스킬에 적어 둡니다. 보고서라면 "그래프는 맨 위", "결론을 먼저", "표는 5줄 이내" 같은 규칙입니다. "그래프를 보고서 상단에" 같은 규칙을 지침에 넣어 두면 에이전트 팀이 다음 실행에서도 그대로 지킵니다.

3. 가장 큰 비용은 같은 설명을 반복하는 데 들었다

에이전트는 오래, 자주 돌수록 비용이 듭니다. 비용을 줄이는 방법은 세 가지입니다.

모델을 일에 맞게 고릅니다. 평소 업무에는 최상위 모델보다 한 단계 아래 모델(Sonnet)이면 충분합니다.

긴 대화는 정리합니다. AI는 답할 때마다 앞의 대화를 다시 읽기 때문에 대화가 길수록 비용이 늘어납니다. "대화 압축" 기능으로 대화를 줄이면서 계속 작업할 수 있습니다.

무료 한도와 유료 사용을 구분해 씁니다. 기획 단계는 무료 한도 안에서, 최종 결과물만 유료로 만드는 방식입니다. 요금 정책은 자주 바뀌니 쓰기 전에 확인이 필요합니다.

제가 덧붙이자면, 같은 일을 여러 번 다시 설명하는 비용이 생각보다 큽니다. 1편에서 말한 스킬과 지침 파일이 비용을 줄이는 가장 확실한 방법이었습니다.

4. 자동 배포는 닷새 동안 실패하고 있었다

자동화가 잘 될수록 사람이 결과를 덜 보게 됩니다. 그래서 안전장치는 처음에 넣어 두어야 합니다.

저는 이 말을 직접 겪었습니다. 이 사이트는 저장소에 올리면 자동으로 배포되도록 설정해 두었습니다. 그런데 설정한 날부터 닷새 동안 자동 배포가 네 번 모두 실패하고 있었습니다.

그 사이 사이트가 바뀐 것은 제 PC에서 따로 올렸기 때문이었습니다. 자동 배포는 실패한 줄 모른 채 지나갔습니다. 블로그를 개편하면서 배포 결과를 실제 주소로 확인하다가 알게 됐습니다.

원인은 네 가지였습니다. 패키지 목록 불일치, 실행 환경 버전, 배포 도구 버전, 등록되지 않은 배포 키입니다. 그 뒤로 저는 "실제 주소에서 바뀐 내용이 보인다"를 작업의 끝으로 봅니다.

보안에서는 특히 API 키 노출을 조심해야 합니다. 키가 새면 큰 비용이 청구될 수 있습니다. 키는 코드나 문서에 적지 말고 별도 설정에만 둡니다.

회사 자료를 어느 서비스에 연결하는지도 확인합니다. 메일, 드라이브, 메신저를 연결하면 편하지만, 그만큼 에이전트가 볼 수 있는 범위가 넓어집니다.

출처도 챙깁니다. 자동으로 만들어지는 보고서는 저작권 문제가 생길 수 있으니 출처를 적게 합니다. 투자처럼 판단이 중요한 내용은 AI 결과를 그대로 믿지 않습니다.

제가 가장 중요하게 보는 것은 사람 확인입니다. 저는 에이전트가 쓴 블로그 글을 이렇게 운영합니다.

1. 에이전트가 쓴 글은 공개되지 않은 검토 대기로 올라온다.
2. 휴대폰으로 알림이 오면 내용을 확인한다.
3. 발행 버튼은 사람이 누른다. 승인 링크는 그 글 하나에만, 정해진 기간 동안만 쓸 수 있다.

이 구조 덕분에 에이전트에게 글쓰기를 마음 놓고 맡깁니다. 업무 도구도 같습니다. 숫자는 원본 건수와 맞춰 보는 장치를 넣습니다.

고객에게 나가는 메일이나 외부 공개는 처음 몇 주 동안 사람이 한 번 봅니다. 오류가 안 보이면 그때 확인 단계를 줄입니다.

위험한 동작은 에이전트가 멈추게 해 두는 것도 방법입니다. 업무 도구를 고칠 때, 운영 데이터베이스를 바꾸는 명령은 에이전트가 바로 실행하지 못하게 되어 있었습니다.

에이전트는 멈춰서 순서를 물었습니다. "이 명령을 먼저 실행하지 않고 배포하면 로그인이 전부 실패한다"는 설명과 함께였습니다. 데이터베이스 변경 → 배포 → 로그인 확인 순서로 사고 없이 마쳤습니다.

세 편을 한 줄씩 줄이면

1. 무엇을 맡길지 정하고, 데이터와 스킬을 준비한다.
2. 일이 많아지면 총괄과 담당으로 나누고, 권한은 필요한 만큼만 준다.
3. 정해진 시각에 돌게 하고, 결과는 한곳에 모으고, 마지막 확인은 사람이 한다.

도구는 계속 바뀝니다. 젠스파크, 제미나이, Claude처럼 도구가 달라도 순서는 같습니다.

내 일에서 반복되는 것을 찾고, 기록을 모으고, 잘 된 방법을 매뉴얼로 남깁니다. 여기서 시작하면 어떤 도구로 옮겨 가도 그대로 쓸 수 있습니다. 처음 읽는다면 ① 맡길 일을 고르고 목표·데이터·스킬 준비하기부터 보면 됩니다.