에이전트로 업무 효율 높이기 ① 맡길 일을 고르고 목표·데이터·스킬 준비하기
저는 담당자가 없는 고객에게 새 담당자를 정하는 일을 자동화했습니다. 엑셀 함수식에서 VBA로, 다시 파이썬 분배기로 옮겼고 지금은 결과 파일만 확인합니다.
도구가 바뀌는 동안 그대로 쓴 것은 일을 고른 기준이었습니다. 반대로 "AI로 뭔가 자동화해 보자"로 시작한 일은 결과물만 그럴듯했습니다. 업무 시간은 줄지 않았습니다.
먼저 결론
- 에이전트를 잘 쓰는 사람과 그렇지 못한 사람의 차이는 도구보다 준비에서 납니다.
- 준비할 것은 목표(왜 만드는지, 어떤 문제를 푸는지), 데이터(에이전트가 읽을 내 업무 기록), 스킬(반복하는 일을 정리한 매뉴얼) 세 가지입니다.
- AI 모델은 계속 좋아집니다.
- 모델이 바뀌어도 남는 자산은 내 데이터와 내 업무 방식(스킬)입니다.
연재 순서: ① 맡길 일을 고르고 목표·데이터·스킬 준비하기 · ② 총괄 하나와 역할별 담당으로 팀 나누기 · ③ 예약 실행으로 매일 돌리고 마지막 확인은 사람이
효율은 같은 설명을 반복하지 않는 데서 났다
대부분 AI를 채팅창에서 처음 씁니다. 질문하고, 답을 복사해 엑셀이나 문서에 붙이는 방식입니다.
이 방식에는 한계가 세 가지 있습니다. 일할 때마다 지시(프롬프트)를 처음부터 다시 자세히 써야 합니다. 대화 기록이 흩어져서 지난 결과를 다시 찾기 어렵습니다. 지난번에 생긴 문제를 다음 작업에 반영하기도 어렵습니다.
에이전트는 이 세 가지를 바꿉니다. 한 번 설정해 두면 반복 실행되고, 결과는 정해진 곳에 쌓입니다. 작업 중 생긴 문제를 지침에 적어 두면 다음 작업에 반영됩니다.
업무 효율이 오르는 지점은 "AI가 똑똑해서"보다 같은 일을 다시 설명하지 않아도 되는 것에 있습니다.
1. 질문을 바꾼 뒤에야 방향이 잡혔다
에이전트를 만드는 과정은 11단계로 나눌 수 있습니다. 단계마다 할 일과, 넘어가기 전에 확인할 질문을 붙였습니다.
| 단계 | 할 일 | 넘어가기 전 확인 |
|---|---|---|
| 1. 목표 정의 | 어떤 문제를 왜 푸는지, 성공하면 무엇이 달라지는지 적는다 | 결과를 숫자나 한 문장으로 확인할 수 있는가 |
| 2. 구조 설계 | 가장 단순한 방식부터 고른다. 순서가 정해진 일은 정해진 절차로, 판단이 필요한 일만 에이전트에게 맡긴다 | 에이전트 하나로 충분한가, 정말 여러 개가 필요한가 |
| 3. 도구 연결 | 메일·파일·DB 등 에이전트가 쓸 도구를 연결하고, 도구마다 언제·어떻게 쓰는지 신입 직원에게 설명하듯 적는다 | 도구 설명만 읽고 사람이 써도 헷갈리지 않는가 |
| 4. 데이터 준비 | 에이전트가 읽을 기록을 한곳에 모으고 형식을 맞춘다 | 개인정보·회사 자료를 써도 되는 범위인가 |
| 5. 사용 방식(UX) 설계 | 어디서 지시하고 어디로 결과를 받을지 정한다 (채팅, 메신저, 보고서 파일 등) | 결과를 받는 사람이 따로 정리하지 않아도 되는가 |
| 6. 보안 | 담당마다 필요한 권한만 주고, 되돌릴 수 없는 동작(발송·삭제·공개)은 사람 확인을 거치게 한다 | API 키가 코드나 문서에 적혀 있지 않은가 |
| 7. 테스트 | 실제 업무에 붙이기 전에 시험용 자료로 돌려 본다. 틀리기 쉬운 경우(빈칸, 중복, 예외)를 일부러 넣는다 | 결과를 원본과 맞춰 봤는가 |
| 8. 운영 | 실행 기록을 남기고, 몇 번 넘게 실패하면 멈추고 알리게 한다 | 실패했을 때 누가 어떻게 알게 되는가 |
| 9. 피드백 반영 | 틀린 결과가 나오면 지침(스킬)에 한 줄씩 추가한다 | 같은 실수가 다시 나오지 않는가 |
| 10. 확장 | 잘 되는 일을 다른 업무로 넓히거나 역할별 에이전트로 나눈다 | 하나로 감당이 안 될 때만 나누고 있는가 |
| 11. 비용 관리 | 일에 맞는 모델을 고르고, 실행 횟수와 대화 길이를 관리한다 | 줄어든 업무 시간이 드는 비용보다 큰가 |
이 중 가장 중요한 것은 첫 단계입니다. 에이전트를 왜 만드는지에 대한 문제 분석입니다.
처음부터 11단계를 다 갖출 필요는 없습니다. 에이전트 하나로 작게 시작해 테스트와 피드백(7·9단계)을 몇 번 돌린 뒤 확장하는 편이 실패가 적습니다.
현업에서 써 보면 실제로 그렇습니다. 저도 처음에는 "AI로 뭔가 자동화해 보자"로 시작했습니다. 결과물은 그럴듯한데 실제 업무 시간은 줄지 않았습니다.
방향이 잡힌 것은 질문을 바꾼 뒤였습니다. 매주, 매달 손으로 반복하는 일은 무엇인가. 그 일의 입력은 어떻게 생겼고, 결과는 어떤 모양이어야 하는가. 무엇이 틀리면 안 되는가(금액, 건수, 개인정보).
예를 들어 "실적표를 본부별로 나눠 보내는 일"은 세 가지가 분명합니다. 입력은 전사 실적표, 결과는 본부별 파일, 틀리면 안 되는 것은 행 수 합계입니다. 이런 일이 첫 에이전트로 좋습니다.
제가 처음 자동화한 일도 이런 일이었습니다. 담당자가 없는 고객에게 새 담당자를 정하는 일입니다. 처음에는 엑셀에서 손으로 고치고, 지역·상품 등 100여 개 조건을 함수식으로 관리했습니다.
사람 손과 시간이 너무 많이 들어 VBA로 옮겼습니다. 이후 파이썬으로 분배기를 다시 만들어 지금은 결과 파일만 확인합니다. 결과를 보기 편하게 화면(Streamlit)도 붙였습니다.
처음부터 AI 에이전트였던 것은 아닙니다. 다만 반복되고 입력과 결과가 분명한 일을 먼저 골랐습니다. 그 덕분에 도구를 바꿀 때마다 같은 기준을 그대로 쓸 수 있었습니다.
2. 모델은 바뀌어도 내 기록은 남는다
준비할 것을 한 문장으로 줄이면 이렇습니다. AI 모델은 계속 좋아지니, 좋아지는 모델이 학습할 나만의 데이터를 준비해야 합니다.
지금 최고라고 부르는 모델도 1년 뒤에는 평범해 보일 수 있습니다. 내 업무 기록은 모델이 바뀌어도 그대로 쓸 수 있습니다.
회사에서 쓰는 데이터는 대부분 다섯 가지 안에 들어갑니다. 주고받은 이메일, 통화 기록, 회의 기록, 엑셀·PPT 같은 업무 파일, 홈페이지·유튜브 같은 공개 자료입니다.
통화와 이메일은 자동으로 기록되게 해 둡니다. 회의는 녹음해 글로 옮긴 뒤 요약까지 AI에게 맡기면 됩니다. 쌓는 것은 자동, 정리는 AI가 합니다.
제 경우 다섯 가지 중 가장 먼저 효과를 본 것은 흩어진 메모를 한곳으로 모으는 일이었습니다. 메신저에 적은 메모, 회의에서 나온 할일, 그날 끝낸 일을 한곳에 쌓았습니다.
그러자 업무일지가 자동으로 채워졌습니다. 에이전트에게 "이번 주에 한 일"을 물어볼 수도 있게 됐습니다. 데이터가 흩어져 있으면 에이전트도 매번 처음부터 시작합니다.
회의 기록은 처음 계획과 다르게 모았습니다. 처음에는 녹음 파일을 올리면 자동으로 글로 옮기고 요약하는 기능을 붙이려 했습니다.
그러다 각자 쓰는 AI(클로바노트, ChatGPT 등)에 녹음을 올리면 요약을 바로 받을 수 있다는 점을 보고 방향을 바꿨습니다. 저는 그 요약을 받는 입구만 만들었습니다. 요약을 붙여 넣으면 목록 줄이 액션아이템 후보로 뜨고, 골라서 할일로 등록합니다.
음성 인식 기능을 따로 만들지 않아 개발이 짧아졌습니다. 회의 결과는 여전히 할일과 같은 곳에 모입니다. 데이터를 모으는 방법은 꼭 새로 만들 필요가 없습니다.
주의할 점도 있습니다. 회사 자료를 외부 AI 서비스에 올리기 전에는 회사 정책을 먼저 확인해야 합니다. 저는 사내 파일을 다루는 도구는 처음부터 "파일이 밖으로 나가지 않는다"를 조건으로 두고 만들었습니다. 통화 녹음도 기록하기 전에 상대에게 알리는 것이 좋습니다.
3. 잘 된 작업을 거꾸로 매뉴얼로 만들었다
에이전트를 쓸 때 가장 중요한 것이 스킬입니다. 스킬은 자주 하는 일을 어떻게 하는지 적어 둔 업무 매뉴얼입니다. 신입 직원에게 주는 인수인계서라고 생각하면 됩니다.
예를 들어 매주 하는 회의를 회사 양식에 맞춘 회의록으로 정리하는 방법을 스킬로 저장합니다. "스킬 만드는 스킬"에 업종을 말하면 맞춤 스킬 초안을 만들어 줍니다.
한 번 잘 된 작업을 지침 파일로 남기는 방법도 있습니다. "이번 작업에서 생긴 문제는 다음에 반복되지 않도록 지침을 보완해 줘" 한 문장으로 계속 다듬습니다.
스킬을 만들 때 제가 효과를 본 방법은 세 가지입니다.
첫째, 잘 된 결과에서 거꾸로 만듭니다. 처음부터 매뉴얼을 쓰기보다 한 번 잘 된 작업을 두고 묻습니다. "이걸 다음에도 똑같이 하려면 무엇을 적어 둬야 해?"
둘째, 금지 사항을 적습니다. "회사명·실명은 넣지 않는다", "자료에 없는 숫자는 쓰지 않는다" 같은 한 줄이 결과 품질을 가장 크게 바꿨습니다.
셋째, 틀린 것이 보일 때마다 한 줄씩 추가합니다. 처음부터 완벽한 스킬은 없습니다. 고친 횟수만큼 손이 덜 갑니다.
이 블로그 글도 스킬로 씁니다. 글 쓰는 에이전트의 스킬에는 세 줄이 들어 있습니다. "회사명·실명·내부 수치는 넣지 않는다", "자료에 없는 사실은 쓰지 않는다", "확인 못 한 것은 확인 못 했다고 적는다"입니다.
집과 회사 PC에서 일하는 방식이 달라지지 않게 하는 것도 스킬로 풀었습니다. 보고 방식·작업 순서·보안 규칙을 적은 공통 지침 파일 하나를 저장소에 두고, 두 PC의 에이전트가 같이 읽게 했습니다. 어느 PC에서 시작해도 같은 기준으로 일합니다.
첫 에이전트는 다섯 가지 질문으로 고른다
- 매주 또는 매달 반복되는 일인가
- 입력과 결과의 모양을 한 문장씩으로 설명할 수 있는가
- 틀리면 안 되는 것을 숫자로 확인할 수 있는가
- 필요한 데이터가 한곳에 모여 있는가 (아니면 모으는 일부터)
- 회사 자료를 써도 되는 범위인가
도구가 바뀌어도 그대로 옮겨 간 것은 일을 고른 기준과 쌓아 둔 기록이었습니다.
다음 편에서는 에이전트 하나가 모든 일을 하는 대신, 역할을 나눈 에이전트 팀으로 일을 나누는 방법을 정리합니다.