이벤트가 실행하는 AI 에이전트와 비즈니스 워크플로 설계

프롬프트를 기다리지 않는 업무 실행

Writer가 공개한 이벤트 기반 에이전트 플랫폼에서는 사람이 매번 지시를 입력하지 않는다. Gmail·Google Calendar·Slack·Gong에서 발생한 업무 이벤트가 에이전트를 깨우고, 사건의 의미에 맞는 멀티스텝 워크플로를 실행한다. AI 에이전트를 요청에 응답하는 보조 도구가 아니라 비즈니스 프로세스 안에서 움직이는 실행 주체로 배치하는 구조다.

이 방식이 성립하려면 외부 서비스의 신호를 안정적으로 받아들이는 계층, 실행할 업무를 가려내는 판단 과정, 여러 단계를 순서대로 처리하는 엔진이 함께 필요하다. 자율 실행이 외부 발송이나 계약 같은 고영향 액션으로 이어질 수 있으므로 승인과 감사 체계도 처음부터 아키텍처에 포함해야 한다.

외부 이벤트를 업무 시그널로 바꾸는 과정

가장 앞단에는 비즈니스 도구별 이벤트 소스 커넥터가 놓인다. 각 커넥터는 서비스가 지원하는 Webhook·폴링·SSE(Server-Sent Events)를 이용해 이벤트를 수신한다.

서비스마다 페이로드 구조가 다르기 때문에 원시 이벤트를 곧바로 워크플로에 넘기지는 않는다. 먼저 통합 스키마로 정규화한 뒤 시그널 분류기(Signal Classifier)를 통과시킨다. Gmail의 이메일 수신 이벤트라면 계약 요청 수신·지원 티켓 접수·미팅 요청·일반 통신처럼 업무에서 사용할 수 있는 시그널로 해석하는 식이다.

⤢✕

분류는 키워드 일치만으로 끝나지 않는다. LLM은 이메일 본문뿐 아니라 발신자, 첨부 파일 유무, 앞선 스레드의 맥락을 함께 읽고 비즈니스 인텐트를 추론한다. 분류 신뢰도가 임계값을 넘지 못한 이벤트는 자동 실행 경로에서 제외하고 인간 검토 큐로 보낸다.

조건을 통과한 이벤트만 워크플로를 연다

시그널의 의미를 판별한 뒤에는 워크플로별 실행 조건을 평가한다. 발신자 도메인처럼 단순한 속성을 비교할 수도 있고, 고객 계정의 ARR이 일정 금액 이상이면서 오픈 딜이 존재하는지처럼 여러 컨텍스트를 결합할 수도 있다. 조건을 충족한 이벤트만 실제 실행으로 이어진다.

실행 엔진은 워크플로를 DAG(Directed Acyclic Graph)로 표현한다. 각 작업은 노드가 되고 선후 관계는 엣지가 된다. 선행 작업이 없는 노드는 병렬로 실행할 수 있으며, 각 노드에서는 LLM 호출·도구 실행·외부 API 호출 같은 에이전트 액션을 수행한다.

⤢✕

계약 요청 처리에서는 첨부 파일을 확보한 뒤 계약 조항 분석과 CRM 조회를 병렬로 진행할 수 있다. 두 작업의 결과가 모두 필요한 리스크 평가는 그다음 노드에 둔다. 내부 법무팀 알림과 고객 접수 확인 메일도 앞선 검토 순서를 지키도록 연결한다.

결과 전달과 감사 기록은 실행의 일부다

워크플로의 결과는 사전에 지정한 채널로 전달된다. 이메일 초안은 Gmail 임시보관함에 저장하고, Slack 메시지는 정해진 채널에 보내며, CRM 변경 사항은 해당 레코드에 반영한다. 계약서 서명이나 외부 발송처럼 영향이 큰 액션은 에이전트가 바로 완료하지 않고 인간 승인 게이트를 거치게 한다.

실행 과정 전체는 불변 감사 로그에 남는다. 로그에는 최초 이벤트 원문, 실행된 작업, 각 작업의 입출력, 실행 시간과 최종 결과가 포함된다. 규정 준수 감사뿐 아니라 실패 지점을 추적할 때도 이 기록을 사용한다.

서비스별 API를 의미적 액션 뒤에 감춘다

Writer의 업무 도구 연동은 OAuth 2.0 위임 접근 모델을 따른다. 사용자가 초기 설정에서 서비스 접근 권한을 부여하면 플랫폼은 리프레시 토큰을 안전하게 보관하고, 필요한 시점에 액세스 토큰을 발급해 API를 호출한다.

서비스별 브릿지는 서로 다른 데이터 모델을 워크플로가 직접 다루지 않도록 추상화한다. Gmail 브릿지는 이메일 스레드·레이블·첨부 파일을 처리하고, Calendar 브릿지는 이벤트·참석자·가용 시간을 조회한다. Slack 브릿지는 채널 메시지·DM·파일 공유를 맡는다. Gong 브릿지는 영업 콜 녹취록과 키워드 분석, 후속 조치 항목 추출을 지원한다.

이 분리 덕분에 워크플로 정의에는 서비스 API의 세부 요청 형식 대신 고객에게 이메일 발송·미팅 예약·채널에 알림 같은 업무 의미를 기록할 수 있다. 실제 API 호출 방식은 각 브릿지가 책임진다.

목표 상태에서 실행 순서를 역산한다

복합적인 이벤트만 보고 어떤 워크플로를 실행할지 결정하려면 이벤트의 내용과 메타데이터를 함께 해석해야 한다. 인텐트 추론 엔진은 에이전트가 도달해야 할 최종 업무 상태를 찾아내고, 조직 구조·고객 세그먼트·내부 프로세스 문서를 RAG 방식으로 참조해 회사별 맥락을 반영한다.

실행 순서는 업무 규칙과 기술 제약을 모두 따라야 한다. 고객 응답 전에 내부 법무 검토가 끝나야 한다면, 그 규칙을 단순 지침으로 남기는 대신 DAG의 선행 엣지로 표현한다. 에이전트가 판단할 수 있는 영역과 반드시 지켜야 하는 순서를 구조적으로 분리하는 방식이다.

실패한 단계에서 멈추지 않게 만드는 복구 경로

멀티스텝 워크플로에서는 한 작업의 실패가 뒤따르는 모든 작업을 막을 수 있다. Writer 플랫폼은 작업별 재시도 정책과 폴백 경로를 정의한다. API 호출에 실패하면 지수 백오프(exponential backoff)를 적용해 최대 3회 다시 시도하고, 이후에도 실패하면 대체 경로로 전환하거나 인간 개입을 요청한다.

완료 알림도 성공 여부에 따라 달라진다. 정상적으로 끝난 워크플로는 실행 요약을 Slack으로 전달한다. 오류가 발생했다면 실패 원인과 사람이 이어서 처리해야 할 조치를 알림에 포함한다.

자율 실행 범위는 액션의 영향도로 나눈다

프롬프트리스 실행은 사용자가 인터페이스를 열고 지시해야만 작동하던 에이전트의 제약을 없앤다. 업무 사건에 즉시 반응할 수 있어 에이전트를 실제 프로세스 안에 배치하기 쉬워진다.

그만큼 실행 경계는 더 명확해야 한다. 잘못된 이메일 발송, 불필요한 API 호출에 따른 요금 낭비, 권한을 벗어난 액션을 막을 장치가 필요하다. 모든 작업에 같은 자율성을 부여하지 않고 영향도에 맞춰 실행 권한을 나누는 이유다.

⤢✕

읽기와 내부 알림은 즉시 실행하고, 내부 문서 생성이나 CRM 갱신은 실행 후 보고할 수 있다. 외부 발송·API 호출·결제에는 인간 승인을 두며, 계약 체결처럼 법적 효력이 생기는 일은 사람이 직접 실행하고 에이전트는 보조 역할을 맡는다. 어느 경로를 택하든 감사 로그는 남긴다.

Writer·Notion·Microsoft가 선택한 통합 범위

이벤트를 에이전트의 입력으로 삼는 구조는 Writer만의 패턴은 아니다. Notion은 데이터베이스 변경 이벤트를 기준으로 에이전트 액션을 실행하는 자동화 시스템을 개발자 플랫폼에 추가했다. Microsoft Copilot Wave 3는 Microsoft 365의 이메일·캘린더·Teams 이벤트를 바탕으로 에이전트 액션을 지원한다.

세 플랫폼은 기존 생산성 도구에서 흐르는 이벤트를 에이전트 입력으로 사용한다는 공통점이 있다. 다만 통합 범위와 자율성의 방향은 다르다. Microsoft Copilot은 Microsoft 생태계 안의 연동과 인간 검토 중심 설계에 무게를 둔다. Writer는 폭넓은 서드파티 연동과 높은 자율 실행 비율을 지향한다. Notion은 워크스페이스 데이터의 변화를 중심으로 트리거를 구성한다.

생산성 효과만큼 통제 실패의 파급력도 커진다

Writer의 고객사 사례 연구에서는 계약 검토 워크플로 자동화 후 평균 응답 시간이 48시간에서 2시간으로 줄었다. 영업 콜 후속 조치 자동화는 영업 담당자 1인당 주 4시간의 반복 업무를 없앴다.

하지만 더 많은 프로세스에 에이전트를 연결할수록 한 번의 오작동이 미치는 범위도 넓어진다. 이벤트 수집과 DAG 실행만으로는 엔터프라이즈 자동화가 완성되지 않는다. 영향도에 따른 권한 계층, 변경할 수 없는 감사 로그, 비상 중단 메커니즘을 함께 설계해야 자율 실행을 실제 업무에 맡길 수 있다.