에이전트 제품을 만들 때 가장 먼저 나오는 말이 있어요. "위험한 건 사용자한테 한 번 물어보자." 승인 팝업을 하나 달면 안전장치를 넣었다는 기분이 들어요.

지금은 생각이 달라요. 승인 버튼은 감독이 아니라 감독하는 것처럼 보이게 하는 장치에 가까워요. 디자이너가 할 일은 팝업을 더 넣는 게 아니라, 사용자가 끼어들 수 있는 자리를 설계하는 거예요.

클릭 수는 감독의 양이 아니에요

Anthropic이 Claude Code 사용 기록을 분석한 글이 있어요(2026-02-18). 숫자 몇 개가 눈에 들어와요.

  • 새 사용자는 세션의 약 20%에서 전체 자동 승인을 켜요. 경험이 쌓이면 40%를 넘어요.
  • 그런데 사용자가 중간에 끼어드는 비율은 줄지 않고 늘어요. 턴 기준으로 5% 정도에서 9% 정도로 올라가요.

승인은 줄고 개입은 늘었어요. 이 두 숫자를 같이 보면 이야기가 달라져요. 처음엔 하나하나 눌러서 확인하니까 따로 끼어들 일이 적어요. 익숙해지면 다 맡겨두고, 이상하다 싶을 때만 멈춰요. Anthropic도 비슷하게 해석해요. 경험 많은 사용자가 감독을 버린 게 아니라 감독하는 방식을 바꿨다는 거예요.

저는 이 대목이 제일 중요하다고 봐요. 승인 클릭 수를 감독의 지표로 쓰면, 가장 잘 감독하는 사람이 가장 감독 안 하는 사람으로 보여요.

숫자만으로는 좋고 나쁨을 못 정해요

여기서 바로 결론을 내리면 안 돼요. 자동 승인 40%가 좋은 건지 위험한 건지는 이 숫자로 알 수 없어요. Anthropic도 에이전트가 적절한 시점에 멈추는지는 아직 단정하지 못한다고 써요. 복잡한 작업에서는 에이전트가 먼저 물어보려고 멈추는 횟수가 사람이 끼어드는 횟수의 두 배가 넘는다는 것도 같은 글에 나와요. 이게 많이 묻는 건지, 필요한 만큼 묻는 건지는 비교할 기준이 없어요.

그래서 에이전트 UX를 평가한다는 게 어려워요. 모델이 정답을 맞혔는지는 벤치마크로 재요. 하지만 사람이 맡기고, 지켜보고, 끼어들고, 되돌릴 수 있는지는 정해진 표준이 아직 없어요. 팀마다 자기 지표를 만들어서 써요.

이미 나와 있는 시도들

완성된 답은 아니지만 참고할 만한 게 있어요.

개인 블로그 Glasgow Works의 "Measuring Agentic UX"(2026-10-01)는 감독, 의존도 보정, 개입, 복구 네 축으로 점수표를 만들어요. 표준은 아니고, 글쓴이도 모든 곳에 통하는 기준값은 없다고 밝혀요. 그래도 질문을 네 개로 나눈 건 쓸모가 있어요. "사용자가 승인했나"가 아니라 "사용자가 제때 개입할 수 있었나, 잘못됐을 때 되돌릴 수 있었나"를 묻게 되니까요.

Microsoft의 Magentic-UI(arXiv 2507.22358)는 아예 개입 자리를 제품에 넣은 연구예요. 실행 전에 같이 계획을 짜고, 위험한 동작에는 가드를 걸고, 언제든 멈출 수 있게 해요. 승인을 묻는 대신 끼어들 수 있는 구조를 만든 쪽이에요. 다만 이 연구에서 쓴 시뮬레이션 사용자는 진짜 사람의 감독을 대신하지 못해요. 시뮬레이션이 잘 맞아도 실제 사람이 어떻게 놓치는지는 따로 봐야 해요.

τ-bench(arXiv 2406.12045)는 같은 과제를 여러 번 돌려서 매번 성공하는 비율(pass^k)을 봐요. 한 번 잘하는 것과 매번 믿을 만한 건 다르다는 걸 숫자로 보여줘요. 감독 설계와 직접 이어지는 건, 얼마나 믿을 만한지 알아야 사용자가 맡기는 정도를 정할 수 있다는 점이에요.

그래서 디자이너는 뭘 설계하나요

제 생각은 이래요. 승인 팝업은 에이전트가 이미 하기로 한 일에 사람이 도장을 찍는 자리예요. 그때는 맥락이 없고 시간도 없어요. 눌러야 다음으로 넘어가니까 누르게 돼요. 그러다 한 번 사고가 나면 "물어봤는데 눌렀잖아"가 되고, 책임이 사용자한테 넘어가요. 안전해진 게 아니라 책임 소재만 옮겨진 거예요.

끼어들 자리를 설계한다는 건 질문이 다르다는 뜻이에요.

  • 사용자가 지금 에이전트가 뭘 하는지 볼 수 있나요? 로그가 아니라 사람이 읽을 수 있는 형태로요.
  • 멈추는 데 비용이 얼마나 드나요? 멈추면 처음부터 다시 해야 하나요, 이어서 할 수 있나요?
  • 되돌릴 수 있나요? 되돌릴 수 없는 일은 시작하기 전에 따로 구분되어 있나요?
  • 에이전트가 모를 때 스스로 멈추나요? 그 멈춤이 사용자한테 유용한 질문으로 오나요, 그냥 "계속할까요?"로 오나요?

이 질문들엔 클릭 수가 아니라 흐름과 상태 표시, 되돌리기, 질문의 질이 답이에요. 전부 화면 설계 문제예요.

제 경험도 비슷해요. LLM 작업을 하다가 일이 제 이해를 넘어선 순간이 있었어요. 과정을 따라갈 수가 없으니까, 중간에 뭘 묻든 제가 판단할 근거가 없었어요. 그래서 일단 해보게 두고, 끝난 다음에 결과를 읽어보고 판단하기로 했어요. 그런데 그렇게 나온 결과물도 제가 봐서는 잘 모를 때가 많았어요.

나중에 문제를 발견했고, 결국 처음부터 하나하나 이해하면서 다시 했어요. 토큰은 토큰대로, 시간은 시간대로 낭비한 최악의 결과였어요. 에이전트가 너무 깊게 파고드는 경향이 있어서, 저는 작업 맥락 안에서 길을 잃었어요.

저한테는 승인 클릭도, 결과를 읽는 것도 진짜 감독이 되지 못했어요. 눌러도 뭘 승인하는지 몰랐고, 읽어도 맞는지 몰랐어요. 감독을 못 한 값은 그때 안 치르고 나중에 한 번에 왔어요. 전체를 다시 하는 걸로요.

이게 제 생각의 출발점이에요. 문제는 승인을 몇 번 받느냐가 아니라, 에이전트가 깊이 들어가는 동안에도 사용자가 작업 맥락 안에 남아 있을 수 있느냐예요. 그러려면 과정이 알맞은 단위로 읽혀야 하고, 중간중간 사용자가 판단할 수 있는 확인 지점이 있어야 해요. 틀렸을 때 어디까지 되돌릴지도 거기서 정해져요.

아직 모르는 것

솔직히 답이 없는 부분이 많아요. 자동 승인 비율이나 개입 비율이 얼마면 좋은지 정한 기준이 없어요. 에이전트가 적절한 때에 묻는지 재는 방법도 정해진 게 없어요. 시뮬레이션으로 개입 설계를 시험하는 건 가능해도, 진짜 사람이 지루해지고 놓치는 건 시뮬레이션이 못 잡아요. 그래서 저는 지금 할 수 있는 건 하나라고 생각해요. 승인 횟수를 지표로 삼지 말고, 사용자가 끼어들 수 있었는지와 되돌릴 수 있었는지를 지표로 삼는 것.

승인 버튼을 없애자는 얘기가 아니에요. 되돌릴 수 없는 일 앞에는 필요해요. 다만 그게 감독 설계의 전부가 되면 안 돼요.

출처