업무 환경에서 AI의 중요한 변화는 모델이 더 나은 문단을 쓸 수 있다는 데 있지 않다. 시스템이 점점 더 여러 단계를 거쳐 목표를 추구할 수 있게 된다는 데 있다. 파일을 검사하고, 연결된 서비스를 검색하고, 결과물을 만들고, 기록을 업데이트하고, 메시지를 보내는 식이다.
이로 인해 업무상의 질문은 “이 답변이 정확한가?”에서 “이 시스템은 나에게 묻기 전에 어디까지 할 수 있도록 허용되어 있는가?”로 바뀐다.
Zapier는 ChatGPT Work를 파일 및 연결된 애플리케이션과 장시간 작업할 수 있는 에이전트형 모드로 설명하며, Plan 모드는 실행 전에 승인을 받을 전략을 제안한다. Microsoft 역시 Copilot, 조직 지식, 거버넌스를 운영형 AI 스택의 상호 보완적인 요소로 제시한다. 이러한 사례는 실용적인 구분을 보여 준다. AI가 대화 상대에서 위임받은 작업자로 이동하고 있다는 것이다.
위임은 시간을 절약할 수 있지만 책임의 형태도 바꾼다. 챗봇은 대개 사람이 검토할 결과물을 생성한다. 에이전트는 여러 중간 작업을 수행할 수 있으며, 그중 일부는 사후에 알아차리기 어렵다. 따라서 가장 안전한 도입 전략은 최대한의 자율성이 아니다. 명시적이고 단계적인 권한 부여다.
프롬프트가 아니라 작업을 기준으로 생각하라
유용한 첫 단계는 업무 흐름에서 AI 시스템이 수행할 수 있는 작업을 나열하는 것이다. “고객 온보딩 처리”는 관리하기에 너무 광범위하다. 보다 유용한 목록에는 다음과 같은 항목이 포함될 수 있다.
- 내부 정책을 읽고 요구 사항을 추출한다;
- 승인된 지식 기반을 검색한다;
- 이메일이나 계약 요약 초안을 작성한다;
- 티켓이나 스프레드시트 행을 만든다;
- 고객 기록이나 재무 기록을 변경한다;
- 사용자를 초대하거나, 문서를 게시하거나, 외부 메시지를 보낸다;
- 결제를 승인하거나, 데이터를 삭제하거나, 조직을 대신해 약속을 한다.
각 작업은 되돌릴 수 있는 정도, 민감도, 외부 영향, 비용이 서로 다르게 결합되어 있다. 이들을 모두 “AI 지원”으로 취급하면 실제 결정이 무엇인지 가려진다.
사람이 모든 것을 감독할 것이라는 모호한 약속보다 단순한 분류가 더 실용적이다.
- 해도 됨: 명확히 제한된 작업 공간 안에서 수행하는 위험이 낮고 되돌릴 수 있는 작업.
- 제안해야 함: 공유 업무를 변경하거나, 외부와 소통하거나, 의미 있는 약속을 만들어 내는 작업.
- 혼자 해서는 절대 안 됨: 규제 대상 의사 결정, 되돌릴 수 없는 삭제, 고액 이체, 접근 제어 변경 또는 민감한 인사 문제와 관련된 작업.
UAE의 정부 에이전트형 AI 프로그램은 관련 정책 사례를 제공한다. 이 프로그램에는 에이전트가 완료해도 되는 작업과 권고만 할 수 있는 작업을 결정하기 위한 규칙이 포함되어 있다. 그 근본적인 발상은 개별 팀에도 잘 적용된다. 권한은 시스템이 유능해 보인다는 이유만으로 부여할 것이 아니라 작업에 연결해야 한다.
결과가 달라지는 지점에 승인 관문을 사용하라
모든 단계에 확인 대화 상자가 필요한 것은 아니다. 시스템이 파일을 읽을 때마다 승인을 요청하면 사람들은 기계적으로 승인하거나 통제를 꺼 버릴 것이다. 관문은 중대한 전환이 일어나기 직전에 배치하라.
예를 들어 에이전트는 중단 없이 정보를 수집하고, 선택지를 비교하고, 초안을 준비하도록 허용할 수 있다. 하지만 다음 작업을 하기 전에는 멈춰야 한다.
- 조직 외부로 무엇인가를 보낼 때;
- 새로운 대상에게 문서를 게시하거나 공유할 때;
- 사실의 기준이 되는 기록을 변경할 때;
- 돈을 지출하거나 할인을 적용하는 경우;
- 권한을 변경하거나 자격 증명을 생성하는 경우;
- 데이터를 삭제, 덮어쓰기 또는 내보내기하는 경우;
- 고용, 자격 요건, 신용, 안전 또는 법적 권리에 영향을 미치는 결정을 내리는 경우.
승인 요청에는 제안된 작업, 정확한 대상, 주요 입력값 및 예상되는 결과가 표시되어야 합니다. “계속하시겠습니까?”는 취약한 통제입니다. “첨부된 목록을 사용해 예상 캠페인 비용 $X로 2,400명의 고객에게 이 메시지를 보내려 합니다”라고 하면 사람이 의미 있는 검토를 할 수 있습니다.
영향이 큰 작업에는 우연히 화면을 보고 있는 사람이 아니라 지정된 승인자를 요구하십시오. 위험 수준상 필요하다면 워크플로를 설계한 사람과 가장 중대한 결과를 승인하는 사람을 분리하십시오.
에이전트의 운영 범위를 정의하십시오
전문가가 유용한 경계를 설정하기 위해 모든 모델 세부 사항을 이해할 필요는 없습니다. 다만 시스템의 운영 범위를 구체적으로 지정해야 합니다:
- 범위: 어떤 프로젝트, 폴더, 계정 및 데이터 소스를 사용할 수 있는가?
- 도구: 시스템이 읽기, 쓰기, 전송, 구매, 코드 실행 또는 권한 변경을 할 수 있는가?
- 한도: 어떤 지출액, 수량, 빈도 또는 시간 한도가 적용되는가?
- 출처: 어떤 도메인, 저장소 또는 데이터베이스를 권위 있는 출처로 간주하는가?
- 에스컬레이션: 어떤 불확실성, 충돌 또는 정보 부족이 사람의 개입을 요구하는가?
- 중지 조건: 시스템이 임의로 판단하는 대신 언제 중지해야 하는가?
가능한 경우 도구 접근 권한은 사용자의 일반적인 계정 접근 권한보다 더 좁아야 합니다. 공유 드라이브를 읽을 수 있는 에이전트라고 해서 모든 연락처에 이메일을 보낼 권한까지 자동으로 필요한 것은 아닙니다. 코드를 작성할 수 있는 에이전트라고 해서 운영 환경 자격 증명까지 자동으로 필요한 것도 아닙니다. 별도의 서비스 계정, 제한된 작업 공간 또는 읽기 전용 연결을 사용하면 오류로 인한 비용을 줄일 수 있습니다.
경계를 운영 언어로 작성하십시오. “판단을 활용하라”는 통제가 아닙니다. “승인 없이 외부 이메일을 보내지 말 것; 고객 데이터베이스를 수정하지 말 것; [date]에 작성된 승인된 가격표만 사용할 것; 두 출처가 충돌하면 중지할 것”은 테스트할 수 있는 지침입니다.
실행 전에 계획을 검사할 수 있게 하십시오
계획 수립은 위임형 AI의 유용한 기능 중 하나지만, 계획이 있다는 것은 그 계획이 타당하다는 증거가 아닙니다. 계획을 제안된 작업 순서로 검토하십시오.
다음 네 가지 질문을 하십시오:
- 시스템은 어떤 결과를 추구하는가?
- 시스템은 어떤 가정을 하고 있는가?
- 어떤 도구를 어떤 권한으로 호출할 것인가?
- 어느 단계에서 실수가 큰 비용을 초래하거나 되돌리기 어려워질 수 있는가?
좋은 승인 화면은 최종 문구만이 아니라 계획의 경계를 보여줘야 합니다. 시스템이 계정을 “정리”하겠다고 말한다면, 검토자는 그것이 레코드에 태그를 지정하는 것인지, 중복 항목을 병합하는 것인지, 메시지를 보관하는 것인지, 데이터를 삭제하는 것인지 확인할 수 있어야 합니다.
반복 작업의 경우, 정책이 충분히 좁아서 테스트할 수 있을 때만 각 사례가 아니라 정책 자체를 승인하십시오. “이 공급업체들이 보내고 금액이 이 기준 미만인 청구서를 원본을 삭제하지 않고 자동으로 이 위치에 보관할 것”은 후보가 될 수 있습니다. “청구서를 관리할 것”은 그렇지 않습니다.
맥락이 실패할 수 있음을 전제로 하라
다단계 시스템은 이전 지시를 놓치거나, 검색된 정보를 잘못 읽거나, 잘못된 가정을 이어 갈 수 있다. 이 다이제스트의 연구 및 엔지니어링 지침은 맥락 손실, 프롬프트 인젝션, 비종료, 구조화된 출력 오류, 상태 복원 문제를 비롯한 실패 양상을 강조한다. Berkeley의 ABBEL 연구는 상호작용 기록 전체를 반복해서 유지하기보다 이를 믿음 상태로 압축하는 편이 나을 수 있다고도 주장하지만, 맥락 관리는 여전히 성능과 신뢰성의 문제로 남아 있다.
이는 업무에 직접적인 함의를 갖는다. 긴 실행 과정의 2단계에서 나온 제약을 에이전트가 기억하는 데 중요한 승인이 좌우되도록 하지 말라. 중요한 제약은 도구 호출이나 승인 관문 가까이에 배치하라. 수신자, 금액, 출처, 근거, 만료 시점 등 민감한 작업에는 구조화된 필드를 요구하라. 작업이 오랫동안 실행된다면 현재 목표, 완료된 단계, 보류 중인 작업, 해결되지 않은 불확실성을 다시 명시하는 체크포인트를 요구하라.
에이전트가 신뢰할 수 없는 자료를 읽을 때는 특히 주의하라. 웹 페이지, 이메일, 문서 또는 코드 주석에는 작업 완료를 돕기보다 시스템을 조작하려는 지시가 들어 있을 수 있다. 검색된 텍스트는 워크플로에서 명시적으로 권한 있는 지시로 식별하지 않는 한 데이터로 취급해야 한다.
중단과 복구를 고려해 설계하라
위임된 작업에는 눈에 보이는 중단 장치와 복구 계획이 필요하다. 반복될 수 있는 작업에는 최대 반복 횟수, 도구 호출 횟수 또는 실행 시간을 설정하라. 재시도를 안전하게 만들어라. 동일한 티켓을 두 번 생성하거나 동일한 이메일을 두 번 보내는 것은 무해한 실패가 아니다. 지원되는 경우 멱등성 작업을 사용하거나, 작업을 반복하기 전에 해당 작업이 이미 수행되었는지 시스템이 확인하도록 하라.
사람이 읽을 수 있는 활동 기록을 남겨라. 요청, 계획, 사용한 도구, 조회한 데이터 출처, 부여된 승인, 변경 사항, 최종 결과를 기록해야 한다. 이는 사후 분석만을 위한 것이 아니다. 원래 담당자가 자리를 비웠을 때 동료가 이어받을 수 있게 하고, 보이지 않는 전체 과정을 처음부터 재구성하지 않고도 결과에 이의를 제기할 수 있게 한다.
중요한 워크플로에서는 자율성을 부여하기 전에 의도적으로 나쁜 사례를 테스트하라. 데이터 누락, 정책 충돌, 만료된 출처, 문서에 포함된 악의적인 지시, 중복 요청, 철회된 권한, 오류를 반환하는 도구를 시도하라. 목표는 에이전트가 절대 실패하지 않음을 증명하는 것이 아니다. 실패가 일시 중지, 명확한 에스컬레이션 또는 안전한 롤백으로 이어지는지 확인하는 것이다.
실용적인 위임 단계
에이전트를 단계적으로 도입할 수 있다.
- 관찰: 시스템이 승인된 정보를 읽고 자신이 무엇을 할지 설명한다.
- 초안 작성: 시스템이 결과물을 준비하지만, 모든 외부 작업은 사람이 실행한다.
- 샌드박스에서 실행: 시스템이 격리된 작업 공간에서 테스트 기록, 브랜치 또는 파일을 생성한다.
- 제한된 권한으로 실행: 시스템이 작업량 및 시간 제한 아래에서 되돌릴 수 있는 저위험 작업을 수행한다.
- 정책에 따라 실행: 시스템이 충분히 테스트된 작업 유형을 처리하고, 정해진 승인 관문에서 일시 중지한다.
하위 단계에서 워크플로가 허용 가능한 방식으로 작동한다는 증거가 나온 경우에만 다음 단계로 올라가라. 작업이 바뀌거나, 도구가 바뀌거나, 데이터가 더 민감해지면 단계 사다리를 다시 내려가라.
이것이 당신의 경력에 의미하는 것
가치 있는 기술은 단순히 AI에게 결과를 요청하는 방법을 아는 것이 아니다. 모호한 위임을 범위가 정해진 운영 절차로 바꾸는 방법을 아는 것이다. 여기에는 작업을 행동 단위로 분해하고, 되돌릴 수 없는 전환을 식별하고, 에스컬레이션 규칙을 작성하고, 승인 요청을 설계하고, 에이전트가 언제 멈춰야 하는지 알아보는 일이 포함된다.
면접이나 성과 평가에서는 자신이 시작한 자동화만이 아니라 자신이 설계한 경계를 설명하라. “시스템은 조사하고 초안을 작성하며, 외부 커뮤니케이션은 지정된 검토자가 승인하고, 데이터베이스 쓰기는 이 필드들로 제한되며, 중복 작업은 확인하고, 해결되지 않은 충돌이 발생하면 실행을 중단합니다.” 이러한 표현은 운영상의 판단력을 보여 준다.
에이전트 기반 업무가 전문가로서의 책임을 질 필요를 없애지는 않을 것이다. 오히려 책임을 더 구체적으로 만든다. 작업을 넘기기 전에 시스템이 무엇을 할 수 있는지, 무엇을 먼저 보여 줘야 하는지, 무엇을 절대로 혼자 해서는 안 되는지 결정하라. 그런 다음 그 결정을 워크플로 자체에 드러나게 하라.
Maya Chen은 AI 시대에 일하기 위한 기술, 역할, 현명한 선택을 다루는 AI Career Brief의 책임 있는 인간 편집자입니다.
