에이전트를 만들 때 우리는 대개 할 수 있는 일을 늘리는 데 집중합니다. 도구를 붙이고, 권한을 주고, 접근 범위를 넓힙니다.
그런데 실제로 운영해보면 사고는 반대쪽에서 납니다. 하지 말았어야 할 일을 성실하게 해낸 경우입니다.
성실함이 위험이 되는 순간
사람 조수에게 "이 목록의 고객들에게 안내 메일 보내줘"라고 시켰다고 해봅시다. 목록에 이미 해지한 고객이 섞여 있으면, 조수는 대개 손을 멈추고 물어봅니다. "이분들은 작년에 해지하셨는데 맞나요?"
이 되묻기가 가치입니다. 지시의 빈틈을 메우는 판단입니다.
에이전트는 대체로 되묻지 않습니다. 목록을 받았으니 보냅니다. 300통이 나가고, 그중 40통이 이미 떠난 고객에게 갑니다. 지시는 정확히 수행됐습니다.
문제는 능력이 아니라 거절할 근거가 설계에 없다는 것입니다.
거절은 세 가지 형태로 나온다
에이전트가 "안 한다"고 말할 수 있는 방식은 층위가 다릅니다.
멈춤. 조건이 예상 범위를 벗어나면 실행하지 않고 사람에게 넘깁니다. 가장 기본이고 가장 안전합니다.
되묻기. 지시가 모호하면 실행 전에 확인합니다. 이게 있으면 사고가 크게 줄지만, 너무 자주 물으면 아무도 안 씁니다. 빈도 조절이 설계의 핵심입니다.
부분 수행. 할 수 있는 데까지 하고 나머지를 보고합니다. "300건 중 260건 발송, 40건은 상태 불일치로 보류했습니다." 실무에서 가장 유용한 형태입니다.
세 번째가 특히 중요합니다. 전부 하거나 전부 멈추는 이분법은 현실의 업무와 안 맞습니다.
무엇을 거절하게 할 것인가
"이상하면 멈춰"는 지시가 아닙니다. 판정 가능한 조건이어야 합니다. 실무에서 잘 작동하는 유형들입니다.
규모 이탈. 평소 30건인데 3천 건이면 멈춥니다. 대량 사고 대부분이 여기서 걸립니다.
대상 불일치. 지시한 조건과 실제 데이터가 어긋날 때. 위 사례의 해지 고객이 여기 해당합니다.
되돌릴 수 없는 동작. 발송, 결제, 삭제, 게시. 예외 없이 사람 승인을 거칩니다.
첫 경험. 처음 보는 유형, 처음 접근하는 시스템, 처음 만나는 에러. 익숙하지 않은 상황에서 자신 있게 진행하는 것이 가장 위험합니다.
모순. 지시끼리 충돌할 때. "빠르게" 와 "전부 확인하고" 가 같이 오면 어느 쪽을 버릴지 스스로 정하게 두면 안 됩니다.
거절의 품질이 더 중요하다
멈추기만 하면 반쪽입니다. 어떻게 멈추는가가 실제 유용성을 결정합니다.
나쁜 거절: "실행할 수 없습니다."
좋은 거절: "300건 중 40건이 해지 상태입니다. 260건만 발송할까요, 아니면 목록을 다시 확인하시겠습니까? 해지 40건 목록은 여기 있습니다."
차이는 다음 행동이 명확한가입니다. 사람이 다시 조사해야 하는 거절은 일을 늘립니다. 판단만 하면 되는 거절은 일을 줄입니다.
자율성을 늘리는 순서
거절 권한이 갖춰지면 오히려 자율성을 더 줄 수 있습니다. 순서가 반대입니다.
- 거절 조건을 먼저 정합니다. 무엇을 만나면 멈추는지.
- 거절할 때 무엇을 함께 보고할지 정합니다.
- 그다음에 권한을 넓힙니다.
이 순서를 지키면 권한이 늘어도 위험이 비례해서 늘지 않습니다. 반대로 하면 권한만 늘고 안전장치는 사고 후에 붙습니다.
남는 문제
거절 권한을 주면 새로운 질문이 생깁니다. 에이전트가 잘못 거절했을 때는 어떻게 되는가.
너무 자주 멈추는 에이전트는 안 쓰이고, 안 쓰이는 에이전트는 없는 것과 같습니다. 그래서 거절 기록도 성공 기록만큼 봐야 합니다. 거절 건수가 줄지 않는다면 조건이 과한 것이고, 거절이 한 번도 없다면 조건이 작동하지 않는 것입니다.
결국 이건 사람에게 일을 맡길 때와 같은 문제입니다. 시키면 무조건 하는 사람과, 필요할 때 "이거 확인해보셨어요?"라고 묻는 사람 중 누구와 오래 일하고 싶은지.
자율성의 크기는 할 수 있는 일의 목록이 아니라, 하지 않기로 한 일의 목록에서 드러납니다.
