업무를 맡겼는데, 설명과 확인은 왜 그대로일까요?
매주 반복하는 업무를 AI에 맡겨도 담당자가 계속 맥락을 설명하고 결과를 다시 확인한다면, 작업자는 바뀌었지만 운영 방식은 달라지지 않은 셈이에요. 프롬프트가 길어지고 자동화가 늘어날수록 예외가 어디서 생겼는지 찾기도 어려워집니다.
Basis·Clay·Exa의 사례는 이 문제를 서로 다른 방식으로 풀었습니다. 순서가 안정된 업무는 재사용 가능한 스킬로 만들고, 계속 달라지는 맥락은 계정별 작업공간에 남기고, 외부 결과를 만드는 실행에는 테스트와 사람 검토를 붙였어요. 세 회사가 공통으로 운영 자산으로 만든 것은 대화문이 아니라 업무의 상태와 완료 증거였습니다.
Basis는 온보딩 설명을 ‘완료 가능한 절차’로 바꿨어요
Basis가 줄인 것은 신입에게 정보를 전달하는 시간만이 아닙니다. 사람이 한 번 시연한 과정을 트리거, 실행 단계, 필요한 도구, 완료 조건이 있는 회사 전용 스킬로 바꿨어요. 신입은 첫날 Codex와 온보딩 스킬을 받고, 에이전트가 회사의 주요 개념을 설명하는 동안 컴퓨터 통합 설정도 진행합니다. OpenAI가 2026년 9월 공개한 사례에서 Basis는 첫날 온보딩 시간이 2시간에서 30분으로 줄었다고 밝혔습니다.
다만 이 수치는 Basis가 보고한 단일 사례입니다. 표본 수와 측정 기간, 설정 오류율, HR의 검토시간은 공개되지 않았으므로 모든 회사가 75%를 절약할 수 있다는 뜻은 아니에요. 가져올 만한 부분은 숫자보다 설명을 실제 상태 변화와 연결한 설계입니다.
문서와 실행 절차는 끝나는 지점이 다릅니다.
“필수 협업 도구를 설정한다”는 문서는 읽고 이해하면 끝납니다. 실행 절차라면 “승인된 서비스 목록 확인 → 회사 이메일로 로그인 → 필수 채널 참여 상태 기록 → 계정 충돌이나 추가 권한 요청이 생기면 중단”처럼 완료 증거와 예외 처리까지 있어야 해요.
예외가 사라지는 것도 아닙니다. Basis 사례에서는 반복 질문과 새로운 예외가 나오면 HR이 스킬을 갱신하고, 복잡한 질문에는 사람이 개입합니다. Basis가 자사 회계 에이전트에서도 핵심 결정 지점에 회계사가 참여하고 완성 결과를 검토한다고 설명하는 것을 보면, 이 회사의 운영 원리는 무인화보다 반복 실행과 전문가 판단의 분리에 가깝습니다.
Clay는 요약문이 아니라 다음 날에도 남는 상태를 만들었어요
거래 정보처럼 매일 변하는 업무에는 고정된 절차만으로 부족합니다. Clay는 CRM, 이메일, Slack, 통화, 발표 자료 등에 흩어진 거래 맥락을 계정별 작업공간에 모았어요. 전담 서브에이전트가 밤마다 원자료를 검토해 계정 폴더를 갱신하고, 조정 에이전트가 아침에 고객 질문 답변이나 구매위원회 빈자리 확인 같은 우선 행동을 추립니다. Clay가 밝힌 절감 시간은 매일 밤 받은편지함을 분류하던 약 1시간입니다.
핵심은 어제의 결론이 오늘의 입력으로 이어진다는 점이에요. Clay의 Account Agents 제품 페이지도 이전 접촉, 거래, 통화와 결론을 바탕으로 허용된 행동 중 다음 단계를 고르고, 결론과 추론을 다시 계정에 기록하는 구조를 설명합니다. CRM·데이터웨어하우스 기록은 사람 승인을 거치는 구조로 제시됩니다. 다만 이 상용 제품과 OpenAI 사례에 나온 Clay 내부 시스템이 완전히 같은 구현인지는 공개 자료만으로 확인되지 않습니다.
Exa는 발견에서 멈추지 않고 테스트된 PR까지 연결했어요
코드와 외부 파트너에 영향을 주는 업무라면 산출물을 만드는 것만큼 검증 경로가 중요합니다. Exa의 Codex 워크플로는 개발 생태계에서 통합 기회를 감시하고 관련 맥락을 모은 뒤 PR을 만들고 테스트를 실행합니다. 주간 업데이트와 필요한 경우 초기 공지 초안도 준비하지만, 실제 배포 전에는 사람이 검토해요. 어떤 기회에 투자할지, 외부 파트너에게 무엇을 약속할지도 팀이 결정합니다.
Exa는 별도로 GitHub 저장소와 문서, Stack Overflow를 색인해 자연어 질의를 실제 코드 예시와 연결하는 Code Search도 제공하고 있습니다. 다만 공개된 사례는 이 제품이 사내 통합 워크플로에 직접 사용됐다고 밝히지 않아요. 따라서 Code Search를 Exa 사례의 기술적 기반이라고 단정하기보다, 회사가 코드 탐색 문제를 다루는 별도 제품으로 구분해서 보는 편이 정확합니다.
| 업무의 성격 | 가까운 사례 | 남겨야 할 운영 자산 | 사람이 결정할 지점 |
|---|---|---|---|
| 순서와 정상 종료가 안정적 | Basis | 트리거·단계·도구·완료 조건이 있는 스킬 | 새로운 예외와 복잡한 질문 |
| 고객·계정별 맥락이 계속 변함 | Clay | 원자료와 결론이 누적되는 영속 작업공간 | 근거 확인 후 고객에게 취할 행동 |
| PR·발송·배포처럼 외부 결과를 만듦 | Exa | 테스트 결과와 검토 가능한 산출물 | 우선순위·대외 약속·배포 승인 |
실행 전에 끝내는 첫 파일럿 설계 체크리스트
공개 자료에는 Basis의 회사 전용 온보딩 스킬을 설치하거나 실행하는 경로가 나와 있지 않습니다. 따라서 아래 절차는 특정 제품의 사용법이 아니라, 담당자와 함께 파일럿을 실행할 준비가 됐는지 확인하는 설계 체크리스트예요. OpenAI가 제안하는 출발점도 담당자와 기준선, KPI, 가드레일을 정한 뒤 트리거와 권한, 완료 증거, 사람에게 넘길 중단점을 명시하는 것입니다.
- 현재 수행 기록이 있는 업무 하나를 고릅니다. 정상 종료 상태를 한 문장으로 말할 수 있어야 해요. 현재 처리시간, 예외, 사람 개입 횟수와 검토시간도 기준선으로 적습니다.
- 업무 상태에 맞는 구조를 선택합니다. 순서가 안정됐으면 재사용 스킬, 정보가 계속 변하면 영속 작업공간, 외부 결과를 만들면 테스트와 검토가 있는 제한 실행으로 분류하세요.
- 트리거와 허용 범위를 구체적인 문장으로 씁니다. 예를 들어 “입사일과 회사 이메일이 확정되면 시작한다. 승인된 계정 목록만 읽고 설정 상태를 확인한다. 권한 부여 요청, 계정 충돌, 목록 밖 서비스가 발견되면 중단한다”처럼 작성합니다.
- 완료 증거와 사람의 중단점을 먼저 정합니다. 신입 계정 설정이라면 각 필수 서비스의 로그인 확인 기록, 코드 변경이라면 테스트 결과와 변경 내역처럼 담당자가 원자료로 확인할 수 있어야 합니다. 외부 발송, 데이터 수정, 배포, 권한 부여는 승인 대상으로 분리하세요.
- 실행 전 담당자와 사용할 환경을 확정합니다. 제품 이름과 지원 플랜, 설치 또는 접속 경로, 로그인·인증 담당자, 연결할 시스템, 부여할 최소 권한, 업무 입력 위치, 결과와 감사 기록을 확인할 위치를 한 표에 적으세요. 이 항목 중 하나라도 정해지지 않았다면 아직 실행 단계가 아닙니다. GitHub의 codex-action을 선택했다면 PR 본문, 커밋 메시지, 저장소 지시 파일과 이미지도 신뢰할 수 없는 입력으로 보고 가장 좁은 파일·네트워크 권한을 골라야 합니다.
- 예외를 다음 버전에 돌려보내는 규칙을 정합니다. 파일럿에서 발생할 실패를 빠진 조건, 부족한 맥락, 잘못된 권한, 검토 규칙 중 하나로 기록하고, 누가 스킬·작업공간·테스트를 수정하며 재검토할지 정하세요.
파일럿 실행 준비 완료 기준
업무 담당자, 현재 기준선, 사용할 제품과 접속 경로, 인증·연결 담당자, 입력 위치, 최소 권한, 완료 증거의 확인 위치, 승인 주체가 모두 정해져 있어야 합니다. 하나라도 비어 있다면 실행 명령을 추측하지 말고 해당 제품의 공식 설치·인증 문서를 확인한 뒤 별도의 실행 절차를 작성하세요.
성공 기준은 출력량이 아닙니다.
2026년 6월 기업 고객의 Codex·ChatGPT 합산 출력 토큰 중 Codex 비중은 64%였고, 월별 AI 사용 상위 10% 기업은 활성 사용자당 출력 토큰이 중간 구간 기업보다 8.3배 많았습니다. 하지만 OpenAI도 토큰 양은 사업 가치의 불완전한 대리 지표라고 명시합니다. 실제 파일럿을 시작한 뒤에는 완료 작업, 주기시간, 품질, 예외, 검토 부하, 비용과 위험 중 해당 업무에 맞는 지표를 사전에 기록한 기준선과 비교해야 해요.
스킬을 공유하거나 관리하는 방식도 제품마다 확인해야 합니다. ChatGPT의 스킬은 지시·예제·코드를 담아 재사용하고 공유할 수 있으며, Enterprise와 Edu 관리자는 관련 권한을 역할별로 관리할 수 있습니다. 그러나 공식 도움말도 다른 제품에서는 가용성과 설치·동기화·거버넌스 방식이 다를 수 있다고 안내합니다. 이 관리 화면과 권한을 Codex에도 그대로 적용된다고 가정하면 안 됩니다.
세 사례에서 복사할 것은 숫자가 아니라 경계입니다
Basis의 30분과 Clay의 하루 1시간은 가능성을 보여주지만, 표본과 비교 방식이 공개된 통제 실험 결과는 아닙니다. 우리 팀에서 먼저 확인할 것은 “얼마나 빨라졌나” 하나가 아니라 어디까지 에이전트가 실행하고, 무엇을 상태로 남기며, 어느 지점에서 사람이 책임질 것인가예요.
안정된 절차에는 완료 조건을, 변하는 업무에는 지속되는 맥락을, 외부 영향을 만드는 실행에는 테스트와 승인 게이트를 붙이세요. 여기에 사용할 제품과 접속 경로, 권한, 입력·결과 위치까지 확정돼야 실제 파일럿으로 넘어갈 수 있습니다. 이 경계가 보이면 AI 자동화는 개인의 긴 프롬프트에서 벗어나 다음 사람도 반복하고 개선할 수 있는 운영 워크플로가 됩니다.
