Basis는 첫날 온보딩을 2시간에서 30분으로 줄였고, Clay는 매일 약 1시간의 받은편지함 정리를 덜어냈어요. 하지만 세 회사가 실제로 재사용한 것은 프롬프트가 아니라 업무의 순서·상태·완료 조건이었습니다.
30분의 비밀은 대화가 아니라 작업 명세예요
Basis 사례의 핵심은 온보딩 안내를 챗봇에게 맡긴 게 아니라, 사람이 한 번 시범 보인 절차를 시작 조건, 순서, 필요한 도구, 완료 조건이 있는 스킬로 바꾼 데 있어요. 신입 직원은 첫날 Codex와 회사 전용 온보딩 스킬을 받고, 에이전트는 회사의 주요 개념을 설명하면서 컴퓨터 통합 설정을 백그라운드에서 처리합니다. OpenAI가 공개한 회사 사례에 따르면 이 과정으로 첫날 온보딩 시간이 2시간에서 30분으로 줄었어요.
여기서 스킬은 멋진 프롬프트 모음이 아니에요. OpenAI의 제품 문서도 스킬을 재사용 가능한 지시로 설명하며, 조직 관리자가 생성·사용·공유·설치 권한을 역할별로 관리할 수 있다고 안내합니다. 즉, 스킬이 운영 자산이 되려면 적어도 누가 소유하고, 누가 실행하며, 어떤 변경을 다음 입사자부터 적용할지 정해져야 해요.
Basis가 예외를 없앤 것도 아닙니다. 반복 질문이나 새로운 예외가 나오면 HR이 스킬을 갱신하고, 복잡한 질문에는 사람이 개입해요. Basis가 본업인 회계 에이전트에서도 자율 작업 뒤 핵심 판단 지점에 회계사가 참여하고 결과물을 검토한다고 밝히는 점을 보면, 이 회사의 패턴은 ‘무인 자동화’보다 반복 구간을 기계가 실행하고 판단 구간을 사람이 맡는 구조에 가깝습니다.
온보딩 문서를 그대로 넣으면 부족한 이유
문서는 무엇을 알아야 하는지 설명하지만, 워크플로는 어느 화면에서 무엇을 확인하고 어떤 상태가 되면 끝나는지까지 정합니다. “슬랙을 설정하세요”보다 “회사 이메일로 로그인 → 필수 채널 5개 참여 확인 → 알림 설정 확인 → 실패 시 IT 담당자에게 중단 사유 전달”처럼 써야 실행과 검수가 가능해져요.
세 회사는 서로 다른 ‘업무 상태’를 에이전트에게 넘겼어요
세 사례의 차이는 자동화한 부서가 아니라, 에이전트가 기억하고 전진시켜야 할 상태의 종류예요.
| 회사 | 넘긴 업무 상태 | 에이전트의 산출물 | 사람이 남긴 결정 |
|---|---|---|---|
| Basis | 순서가 안정된 온보딩 절차 | 설명과 통합 설정 완료 | 예외 처리, 문화와 지원 |
| Clay | 계속 변하는 계정별 맥락 | 매일 갱신된 폴더와 우선 행동 | 근거 확인 후 고객에게 행동 |
| Exa | 발견된 통합 기회의 진행 상태 | 테스트를 거친 PR과 공지 초안 | 우선순위, 약속, 배포 승인 |
Clay는 CRM, 이메일, Slack, 통화, 발표 자료 등에 흩어진 거래 맥락을 계정별 작업공간과 전담 서브에이전트에 모았어요. 서브에이전트가 밤마다 1차 자료를 검토해 계정 폴더를 갱신하고, 조정 에이전트가 아침마다 고객 질문에 답하기, 구매위원회 빈자리 찾기 같은 우선 행동을 추립니다. Clay가 OpenAI에 밝힌 절감 시간은 매일 밤 약 1시간이에요.
이 구조에서 중요한 건 ‘요약’보다 다음 실행에도 남는 상태예요. Clay의 Account Agents 공식 페이지도 이전 접촉, 거래, 통화와 결론을 바탕으로 다음 행동을 고르고, 그 결론과 추론을 다시 계정에 기록한다고 설명합니다. 실행 가능한 행동 역시 관리자가 허용한 범위에서 선택하며, CRM 기록이나 담당자 알림 같은 작업은 사람 승인 구조로 설정할 수 있어요.
Exa는 한 단계 더 나아갑니다. 저장소와 개발 생태계에서 통합 기회를 찾은 뒤 관련 맥락을 모으고, PR을 만들고, 테스트를 실행하고, 주간 업데이트와 초기 공지까지 준비해요. 다만 실제 배포 전에는 사람이 검토하고, 어떤 기회에 투자할지와 외부 파트너에게 무엇을 약속할지는 팀이 결정합니다. Exa의 코드 검색 자체도 GitHub 저장소, 문서, Stack Overflow의 실제 코드 예시를 의미 기반으로 찾도록 설계돼 있어 이 탐색 단계의 기반이 됩니다.
성과 수치는 구매 근거가 아니라 자체 실험의 기준선이에요
2시간에서 30분, 하루 약 1시간 절감은 흥미로운 출발점이지만 그대로 우리 회사의 ROI로 옮기면 안 돼요. 두 수치는 각 회사가 OpenAI 사례를 통해 공개한 결과이며 표본 수, 비교 기간, 오류율 같은 실험 세부 정보는 해당 글에 제시되지 않았습니다. 따라서 제품 성능의 보편적 증명보다 “우리도 이 지표를 측정해 보자”는 가설로 보는 편이 안전해요.
토큰 사용량도 마찬가지예요. OpenAI의 Enterprise Signals에 따르면 AI 사용 상위 10% 기업은 일반 기업보다 활성 사용자당 출력 토큰을 8.3배 생성했고, 2026년 6월에는 기업 고객의 Codex와 ChatGPT 합산 출력 토큰 중 Codex가 64%를 차지했습니다. 그러나 OpenAI도 토큰을 사업 가치의 불완전한 대리 지표라고 명시해요. 출력이 길어졌다는 사실만으로 처리 시간, 품질, 매출이 좋아졌다고 볼 수는 없습니다.
연결 범위가 커질수록 권한 설계가 먼저예요
이메일, CRM, Slack, 저장소를 읽는 에이전트는 더 유용하지만 공격 표면도 넓어집니다. OpenAI의 Codex Action 보안 문서는 PR 본문, 커밋 메시지, 저장소 지시 파일과 이미지까지 신뢰할 수 없는 입력으로 취급하고, 작업에 필요한 가장 좁은 파일·네트워크 권한을 선택하라고 권고합니다.
첫 실험에서는 속도 하나만 보지 마세요. 처리시간, 무개입 완료율, 예외율, 사람 검토시간, 되돌림 건수를 함께 기록해야 합니다. 처리시간이 줄었는데 검토시간과 오류 복구가 늘었다면, 업무가 사라진 게 아니라 사람의 뒤쪽 대기열로 이동한 것뿐이에요.
이번 주에 운영 워크플로 하나를 만드는 법
신입 계정 설정, 주간 고객 현황 정리, 문서 링크 검사처럼 월 4회 이상 반복되고 정상 종료 상태를 한 문장으로 말할 수 있는 일을 택합니다. 채용 결정이나 계약 승인처럼 책임이 큰 판단은 첫 대상으로 잡지 마세요.
각 단계의 입력, 사용하는 메뉴와 도구, 출력, 실패 조건을 적습니다. 화면 녹화만 남기지 말고 “Google Workspace 관리자에서 사용자 생성 → 회사 이메일 로그인 확인”처럼 텍스트 체크리스트로 변환하세요.
트리거, 필요한 자료, 허용 도구, 완료 조건, 반드시 제시할 증거, 사람이 승인할 지점을 한 페이지에 담습니다. 외부 메시지 발송, 결제, 배포, 권한 부여는 기본적으로 승인 전 중단하도록 정하세요.
기존 방식과 에이전트 방식을 각각 수행해 시작·종료 시각, 성공 여부, 개입 횟수, 검토시간을 기록합니다. 평균만 보지 말고 가장 오래 걸린 사례와 실패 이유도 남겨야 다음 버전을 고칠 수 있어요.
실패를 개인의 프롬프트 요령으로 해결하지 말고 ‘어떤 조건을 빠뜨렸는가’로 분류합니다. 소유자와 버전을 붙여 수정하고, 변경 전 실패 사례를 회귀 테스트로 다시 실행한 뒤 다음 팀에 배포하세요.
