AI Agent가 지금 안정적으로 수행할 수 있는 수익 관련 업무와 아직 자동화하기 어려운 업무, 그리고 반드시 사람이 확인해야 할 지점을 정리합니다.
AI Agent와 대화형 AI의 가장 큰 차이는 실제로 행동할 수 있다는 점입니다. 브라우저를 열고, 폼을 작성하고, 스프레드시트를 읽고 쓰며, 사람이 매번 복사해 붙이지 않아도 정해진 워크플로를 따라 다음 단계로 진행할 수 있습니다.
이 차이에서 오는 능력 향상은 분명하지만, 가능한 일과 어려운 일의 경계도 금방 드러납니다. 몇 차례 실행해 보면 막히는 지점은 기술 자체보다 현실적인 제약에 있는 경우가 훨씬 많다는 것을 알 수 있습니다.
지금 실제로 안정적으로 돌아가는 업무
현재 안정적으로 활용되는 사례에는 공통점이 있습니다. 결과를 사람이 빠르게 확인할 수 있고, 잘못되더라도 되돌릴 수 없는 결과를 만들지 않는다는 점입니다.
가장 부담이 적은 영역은 데이터 정리와 모니터링입니다. 여러 소스에 흩어진 데이터를 주기적으로 수집하고, 필드를 맞추고, 중복을 제거한 뒤 일간 또는 주간 변화 보고서를 만드는 작업은 Agent가 빠르고 지치지 않게 처리할 수 있습니다. 가격 변동, 재고 상태, 순위 변화, 공개 데이터 업데이트도 같은 방식으로 다룰 수 있습니다. 읽기만 하고 쓰지 않는 워크플로라면 오류 비용은 사실상 매우 낮습니다.
콘텐츠 초안의 대량 생성과 재작성도 이미 실용적입니다. 주제를 정해 주면 Agent가 공개 정보를 수집하고 구조화된 메모로 정리한 뒤 첫 초안의 뼈대를 만들 수 있어 자료 조사 시간을 크게 줄여 줍니다. 재작성도 비슷합니다. 긴 콘텐츠를 채널별 길이와 톤에 맞게 나누고 다듬는 작업은 상당히 높은 완성도까지 가능합니다. 다만 결과물은 여전히 초안입니다. 경험에 기반한 판단이나 관점이 필요한 부분은 사람이 채워야 하며, 그렇지 않으면 내용이 빈약해집니다.
고객지원과 이메일의 1차 응대도 많은 업무를 흡수할 수 있습니다. 자주 묻는 질문, 배송 상태 확인, 반품·교환 절차 안내, 예약 확인처럼 표준 답변이 있는 대화는 Agent가 먼저 처리하고, 범위를 벗어난 대화만 표시해 사람에게 넘기면 응답 속도가 눈에 띄게 좋아집니다.
가격 비교와 정보 취합도 안정적인 영역입니다. 같은 상품의 채널별 가격, 사양 차이, 후기에서 반복되는 불만을 하나의 표로 정리하는 일은 사람이 수동으로 찾아보는 것보다 일관되게 처리하기 쉽습니다. 비교 기준을 명확하게 주면 결과를 바로 사용할 수 있는 경우가 많습니다.
이 네 가지 사례에는 또 하나의 숨은 전제가 있습니다. 업무의 경계가 명확해야 한다는 점입니다. “무엇을 입력하고, 무엇을 출력하며, 어떤 조건에서 멈출지”를 구체적으로 정할수록 더 안정적으로 돌아갑니다.
아직 제대로 돌아가기 어려운 업무
반대쪽 영역도 분명합니다. 모델의 능력이 부족해서라기보다 현실의 제약 때문에 막히는 경우입니다.
계정의 신원성을 필요로 하는 작업이 대표적입니다. 로그인 상태, 실명 인증 정보, 누적된 신뢰도는 플랫폼이 특정 주체에게 부여한 권한과 연결됩니다. Agent가 기술적인 방법만으로 그 권한을 얻을 수는 없습니다. Agent에게 “계정을 운영하게 하는 것”과 “데이터셋을 처리하게 하는 것”은 성격이 완전히 다릅니다.
결제와 관련된 작업도 완전 자동화에 맡기지 않는 편이 좋습니다. 주문, 결제, 송금, 자산 환매처럼 실제 돈이 움직이는 행동에는 사람이 마지막 확인을 하는 단계를 남겨 둘 가치가 있습니다. 단순히 실수를 막기 위해서만이 아니라, 금전 관련 작업은 되돌릴 수 없는 경우가 많기 때문입니다.
플랫폼의 승인이 반드시 필요한 행동도 있습니다. 평가 통과, 자격 심사, 행사 신청, 콘텐츠 승인 등은 결과를 플랫폼이 판단합니다. 이런 판정을 기술적으로 우회할 수 있는 통로는 없습니다. 도구를 쓰면 이런 승인을 대신 확실하게 받아 줄 수 있다는 주장은 대체로 성립하기 어렵습니다.
대량 계정 등록이나 자동으로 과제를 반복해 보상을 얻는 방식도 정상적인 워크플로 범위에 넣기 어렵습니다. 이런 방식은 플랫폼 규정에서 가장 명확하게 제한하는 항목과 충돌하며, 판정 기준도 단일 행동만 보지 않습니다. 작업 간격, 행동 경로, 환경의 일관성 등이 모두 고려될 수 있습니다. 기술적으로 작동하더라도 계정이 얼마나 유지될지는 플랫폼의 허용 범위에 달려 있고, 그 전제는 언제든 바뀔 수 있습니다.
사람이 직접 확인해야 할 관문
Agent는 실행 계층으로 사용할 때 가장 잘 맞습니다. 다음 단계들은 고정적으로 사람의 통제 아래 두는 것이 좋습니다.
목표와 우선순위를 정하는 일입니다. 무엇을 할지, 어떤 기준으로 판단할지, 언제 멈출지는 실행 속도보다 훨씬 중요한 결정입니다. 잘못된 방향을 선택했을 때의 결과를 Agent가 대신 책임지지는 않습니다.
외부로 나가는 콘텐츠를 검토하는 일입니다. 본인의 이름으로 읽히게 될 이메일, 답변, 게시물, 보고서는 보내기 전에 한 번 확인해야 합니다. 이유는 현실적입니다. 잘못됐을 때 책임지는 사람은 본인이기 때문입니다.
자금과 권한 관련 작업을 확인하는 일입니다. 읽기 권한은 넓게 열어 Agent가 언제든 데이터를 보고 보고서를 만들게 할 수 있습니다. 파라미터를 바꾸거나 효율이 낮은 작업을 중지하는 정도의 일반적인 조정도 맡길 수 있습니다. 하지만 큰 규모의 변경과 일괄 작업은 사람이 한 번 더 확인하도록 해야 합니다. 그래야 효율과 통제력을 함께 유지할 수 있습니다.
실행 기록을 남기는 일입니다. Agent가 무엇을 했고 어떤 규칙에 따라 움직였는지 기록해야 합니다. 문제가 생기면 이 기록이 원인 분석의 근거가 되고, 평소에는 워크플로를 개선하는 입력 자료가 됩니다.
더 많은 계정을 병렬로 돌리고 싶을 때
하나의 워크플로가 안정적으로 돌아가면 자연스럽게 같은 방식을 더 많은 계정에 적용할 수 있는지 생각하게 됩니다.
이때 병목은 보통 Agent보다 계정 환경에 있습니다. 여러 계정이 같은 브라우저 환경과 같은 네트워크 출구를 사용하면 플랫폼이 이들을 하나의 묶음으로 판단하고 함께 처리하기 쉬워집니다. 현실적인 방법은 계정과 환경을 1대1로 대응시키는 것입니다. 계정마다 독립된 브라우저 환경과 고정된 네트워크 출구를 두고, 작업을 실행할 때 해당 계정의 환경을 불러옵니다. PurpleMark 같은 도구는 이런 다중 환경 관리 기능을 제공하며, 계정별로 환경을 전환하는 스크립트와 함께 사용할 수 있습니다.
하지만 순서를 거꾸로 해서는 안 됩니다. 환경 분리는 계정이 “서로 독립된 사용자처럼 보이는가”라는 문제만 다룹니다. 그 행동을 해도 되는지까지 답해 주지는 않습니다. 계정에서 이루어지는 행동 자체가 규정을 준수해야 환경 분리도 의미가 있습니다.
실패 가능성을 낮추는 도입 순서
처음부터 전체 과정을 자동화하려 하지 말고 작고 구체적인 하나의 상황부터 시작합니다. 결과물이 바로 쓸 수 있는지 확인하고, 쓸 수 있다면 다음 단계를 추가합니다. 이 시점에 권한 경계도 정해야 하며, 특히 쓰기 권한과 자금 관련 작업은 더 엄격하게 다뤄야 합니다. 하나의 워크플로를 일정 기간 안정적으로 운영한 뒤 더 많은 계정으로 확장하고, 확장하기 전 환경 분리를 준비합니다.
이 순서는 조금 느리지만 각 단계에서 실패 비용이 낮고, 각 단계에서 얻은 결론을 다음 단계에도 재사용할 수 있습니다.
