• AI 에이전트의 실행 범위가 넓어질수록, 사용자 측의 '확인 왕복'이 병목 현상이 된다
• 의뢰 서두에 '권한 레벨(L1/L2/L3)'을 3줄로 선언하는 것만으로, 자동 실행/정지 라인이 명확해진다
• 체감상 밤 시간의 확인 건수가 약 30%까지 줄어들었으며, 확보된 시간은 '다음에 무엇을 맡길 것인가에 대한 설계'에 투입할 수 있게 되었다

:::

배경: 에이전트 시대의 새로운 마찰

2026년에 들어서며, AI 에이전트는 '초안을 작성하는 것'에서 '실제로 조작하는' 단계로 진입했습니다. 파일 편집, 메일 초안 작성, 외부 API 호출, 결제 플로우 시작까지, 사용자를 대신하여 직접 움직일 수 있습니다.

편리해진 한편으로, 부업 워커(Side-hustle worker)의 체감 시간은 생각만큼 단축되지 않고 있습니다. 원인은 '자동 실행된 것을 다시 확인하는 비용'이 설계 시점에 간과되었기 때문입니다.

설계: 권한을 3단계로 선언하기

의뢰 서두에 다음 테이블에 대응하는 한 줄을 붙여넣습니다.

선언 예시:

이 태스크는 L2로 진행해 주세요. 전송·공개·결제에 닿기 전에는 반드시 정지하여 확인을 요청할 것.

제약 사항에 이유를 병기하는 이유는, 에이전트가 경계 판단에 망설일 때의 우선순위를 심어주기 위해서입니다 (모호한 조작은 '가역성 (Reversibility)'을 기준으로 판단하도록 유도함).

구현: 프롬프트 템플릿

의뢰 서두에 두는 템플릿입니다. 긴 의뢰라도 이 3줄만 있다면 에이전트의 초동 대응이 크게 달라집니다.

【권한 레벨】 L2

【가역적인 조작】 실행 가능. 완료 보고만 하면 됨

【불가역적인 조작】 전송/공개/결제/외부 쓰기는 실행 전에 반드시 정지하여 확인을 요청할 것

포인트는 '불가역적인가'를 판단 축으로 삼는 것입니다. 툴 이름이나 구체적인 API 명칭으로 금지 리스트를 작성하는 것보다, 장기적으로 운용이 망가지지 않는다는 경험칙입니다.

결과: 확인 왕복의 실측 변화

도입 전후로 1주일씩 측정한 대략적인 변화입니다.

숫자를 취하는 방식이 엄밀하지는 않지만, '밤의 확인 왕복이 사라졌다'는 체감은 강력하게 일관되고 있습니다.

함정: L3를 처음부터 사용하지 말 것

도입 직후에 빠지기 쉬운 것이, 편리함에 고무되어 L3(완전 위임)를 남용하는 것입니다. L3는 '실패의 감지가 늦어진다'는 전제하에 운용해야 하며, 상시 태스크화된 것 이외에는 적합하지 않습니다.

신규 태스크는 반드시 L1 또는 L2로 1~2회 사이클을 돌립니다. 안정적으로 동일한 결과를 반환하게 된 후에야 비로소 L3로 승격시킵니다. 이 순서를 지키지 않으면 결국 확인의 왕복 상태로 돌아가게 됩니다.

요약: 전달 방식은 처음 3줄로 결정된다

에이전트의 똑똑함보다, 우리의 전달 방식을 정돈하는 것이 먼저 효과가 있었습니다. 3줄의 라벨링을 서두에 두는 것만으로도, 확인의 양과 타이밍은 자신의 손으로 돌아옵니다.

부업처럼 시간이 한정된 운용일수록, 이 '권한을 선언한 뒤 의뢰하는' 습관이 생각 이상으로 효과적입니다.

Discussion