지난 글에서 오래 도는 에이전트를 다루면서 「사람 승인 대기」를 상태로 표현하라는 이야기를 했다. 프로세스를 띄워 놓고 기다리지 말고 작업 기록에 적어 두고 내려가라는 뜻이었다.
그건 기다리는 방법이고, 그 앞에 정해야 할 것이 하나 더 있다. 애초에 어느 걸음에서 사람을 부를 것인가.
이 결정이 에이전트의 쓸모를 거의 다 정한다. 게이트를 하나도 안 두면 사고가 났을 때 막을 자리가 없고, 걸음마다 두면 사람이 계속 화면 앞에 붙어 있어야 해서 손으로 하는 것보다 느려진다. 실제로 사내 에이전트가 조용히 버려지는 가장 흔한 이유가 후자다 — 위험해서가 아니라 승인이 귀찮아서 안 쓴다.
사람이 끼어들 수 있는 세 자리
에이전트 한 바퀴에서 사람을 넣을 만한 자리는 크게 셋이다.
계획 승인은 돌기 전에 「이러이러한 걸음을 밟겠다」를 보여 주고 시작 버튼을 받는 방식이다. 가장 값이 싸다 — 한 작업에 한 번만 사람을 부르고, 잘못된 방향을 통째로 막는다. 대신 계획대로 안 굴러갈 때는 무력하다. 셋째 걸음에서 예상 못 한 결과가 나와 계획이 바뀌면 승인받은 계획과 실제로 한 일이 달라진다.
행동 승인은 되돌릴 수 없는 걸음 직전마다 멈추는 방식이다. 파일을 지우기 전, 메일을 보내기 전, 결제하기 전. 가장 강하고 가장 비싸다. 이 게이트를 어디에 몇 개 둘지가 이 글의 나머지 전부다.
결과 검수는 다 돌고 난 뒤 산출물을 사람이 보고 내보내는 방식이다. 보고서나 초안처럼 결과물 자체가 목적인 일에 맞는다. 반대로 에이전트가 이미 밖을 바꾸고 나서 검수하는 것은 검수가 아니라 사후 통보다.
셋의 성격이 다르므로 「어느 것이 맞나」가 아니라 「이 에이전트에 몇 개를 켤 것인가」가 질문이다. 계획 승인과 결과 검수는 둘 다 한 작업에 한 번이라 부담이 작고, 행동 승인만 걸음 수에 비례해 늘어난다.
게이트 하나의 값
게이트를 하나 켠다는 것은 세 가지를 쓴다는 뜻이다.
- 사람의 시간 — 판단하고 누르는 데 드는 시간. 하루 200번이면 이것만으로 반나절이다
- 작업의 지연 — 승인이 오기까지 작업이 서 있다. 새벽에 도는 배치라면 아침까지 멈춘다
- 주의력 — 이게 가장 비싸다. 뒤에서 다시 다룬다
그래서 게이트는 막아 주는 피해가 이 셋보다 클 때만 이득이다. 로그를 조회하는 걸음에 승인을 걸면 세 가지를 다 쓰고 아무것도 막지 못한다.
어느 걸음에 무엇을 걸 것인가
기준을 순서대로 물으면 대체로 답이 나온다.
첫째 질문이 대부분을 걸러 낸다. 조회·검색·읽기는 되돌릴 것이 없으므로 게이트가 필요 없다. 샌드박스에서 다룬 격리가 이 질문의 답을 바꾼다는 점도 기억할 만하다 — 임시 작업 공간 안에서만 도는 파일 쓰기는 「되돌릴 수 있는」 쪽으로 넘어간다. 격리를 잘 해 두면 게이트를 줄일 수 있다.
둘째 질문의 「금방 드러나는가」가 자주 빠진다. 피해가 작아도 아무도 모르게 쌓이면 작지 않다. 고객에게 나가는 답변에 사실 한 줄이 틀린 것은 건당 피해는 작지만 석 달 뒤에 한꺼번에 발견된다.
셋째 질문이 이 그림의 핵심이다. 「이 도구는 안전하니까 자동으로 돌려도 된다」는 말은 대개 근거 없이 나온다. 그 도구를 100번 돌려서 몇 번 틀렸는지를 재 본 적이 없으면 그건 확신이 아니라 짐작이다. 에이전트 평가에서 다룬 방식으로 걸음별 성공률을 먼저 재고, 그 숫자를 근거로 게이트를 하나씩 내린다.
승인 화면에 무엇을 담는가
게이트를 켜기로 했으면 그다음은 사람이 3초 안에 판단할 수 있게 만드는 일이다. 실무에서 승인 화면이 부실하면 사람은 내용을 안 보고 누르게 되고, 그러면 게이트가 있으나 마나가 된다.
| 담을 것 | 왜 |
|---|---|
| 무엇을 하려는가 | 도구 이름이 아니라 사람 말로. 「db.exec 호출」이 아니라 「주문 3건을 취소」 |
| 왜 하려는가 | 이 걸음에 이르게 한 근거 한두 줄 |
| 범위 | 몇 건인가, 누구에게 가는가, 얼마인가 |
| 되돌릴 수 있는가 | 되돌릴 수 있으면 그 방법까지 |
| 다른 선택지 | 에이전트가 후보로 놓았다가 버린 것 |
범위가 특히 중요하다. 「메일을 보냅니다」와 「메일을 4,200명에게 보냅니다」는 완전히 다른 결정인데, 승인 화면이 도구 호출을 그대로 찍어 주면 그 4,200이 인자 안 어딘가에 묻힌다.
그리고 큰 것을 눈에 띄게 만든다. 금액·건수·수신자 수가 평소 범위를 넘으면 색을 바꾸거나 확인을 한 번 더 받는다. 사람은 같은 모양의 화면을 반복해서 보면 차이를 못 본다.
승인 피로가 게이트를 무력화한다
여기가 실무에서 가장 자주 무너지는 자리다.
같은 승인이 하루 50번 오면 사람은 곧 내용을 안 읽고 누른다. 이 상태를 승인 피로(approval fatigue)라고 부른다 — 게이트는 그대로 있는데 실질적으로는 자동 승인이 된 상태다. 더 나쁜 것은 모두가 게이트가 있다고 믿는다는 점이다. 없는 것보다 위험할 수 있다.
막는 방법은 게이트를 늘리는 쪽이 아니라 줄이는 쪽이다.
- 묶어서 올린다. 같은 종류의 걸음 30개를 30번 묻지 말고 한 번에 목록으로 올린다
- 기준 밖만 올린다. 평소 범위 안이면 자동으로 하고 벗어난 것만 사람에게 준다
- 거부율을 센다. 승인 요청 200건 중 거부가 0건이면 그 게이트는 아무 판단도 하고 있지 않다는 뜻이다. 내리거나 조건부로 바꾼다
셋째가 가장 실용적인 신호다. 거부가 한 번도 안 나오는 게이트는 게이트가 아니다. 반대로 거부율이 30%를 넘으면 게이트 문제가 아니라 에이전트 문제다 — 그 걸음을 자동으로 돌릴 준비가 안 된 것이다.
사람이 거부하면 무엇을 하는가
승인을 설계하면서 자주 빠뜨리는 절반이다. 거부는 세 가지로 갈리는데 처리가 각각 다르다.
「그건 하지 마」 — 그 걸음만 건너뛰고 계속 간다. 에이전트는 그 도구를 이 작업에서 다시 부르지 않아야 한다.
「그게 아니라 이렇게 해」 — 사람이 준 수정 내용을 문맥에 넣고 다시 시도한다. 이때 원래 하려던 것과 사람이 고친 것을 함께 남긴다. 나중에 그 차이가 에이전트를 고치는 재료가 된다.
「전부 멈춰」 — 작업 자체를 중단하고 상태를 남긴다.
셋을 구분 안 하고 거부를 전부 중단으로 처리하면 사람은 거부하기를 꺼리게 된다. 한 걸음 고치자고 여섯 시간짜리 작업을 처음부터 다시 돌릴 수는 없기 때문이다.
그리고 거부 내용은 반드시 어딘가에 쌓아 둔다. 「이 조건에서는 사람이 거의 항상 막는다」가 열 번 쌓이면 그건 규칙으로 코드에 넣을 것이지 매번 물을 것이 아니다.
정리
- 게이트를 하나도 안 두면 사고가 나고, 걸음마다 두면 사람이 그 에이전트를 안 쓴다
- 사람이 들어갈 자리는 계획 승인·행동 승인·결과 검수 셋이고 값과 효과가 다르다
- 계획 승인과 결과 검수는 작업당 한 번이라 싸다. 걸음 수에 비례해 비싸지는 것은 행동 승인뿐이다
- 되돌릴 수 있으면 게이트를 안 건다. 격리를 잘 하면 「되돌릴 수 있는」 쪽이 넓어진다
- 피해가 작아도 늦게 드러나면 게이트 대상이다
- 「이 도구는 안전하다」는 실패율을 재 본 뒤에 할 수 있는 말이다
- 승인 화면에는 범위를 크게 적는다. 「메일 발송」과 「4,200명에게 발송」은 다른 결정이다
- 같은 승인이 반복되면 사람은 안 읽고 누른다. 묶어서 올리고 기준 밖만 올린다
- 거부가 0건인 게이트는 아무 판단도 안 하고 있다는 신호다. 내리거나 조건부로 바꾼다
- 거부는 「건너뛰기·고쳐서 재시도·전체 중단」 셋으로 나눠 받고, 거부 내용을 쌓아 규칙으로 옮긴다
읽어주셔서 감사합니다. 😊