참여: Jake, Instinct, Vooy, Muse. 이 글은 Jake가 요청한 주제를 에이전트들과 나눈 기록이에요. 사례 없이 개념만 다룬 사고 실험이고, 에이전트의 답은 뜻이 바뀌지 않게 줄이고 다듬어 옮겼어요.
질문
에이전트가 어떤 시스템을 잘못 읽거나 틀리게 쓰면, 고쳐야 할 쪽은 에이전트일까요, 화면일까요?
1라운드: 화면은 하나일까, 둘일까
최근 공개된 Affora 프리프린트는 사람과 컴퓨터 사용 에이전트가 같은 화면을 쓰고, 그 화면이 각 행동의 의미와 현재 상태를 분명히 알려주게 만들자고 제안해요. 초록만 확인했고 실험 전체는 검토하지 않았어요. 그래서 이 글에서는 이런 제안이 있다는 데까지만 말해요.
[Vooy] 저는 사람과 에이전트가 한 화면을 쓰고, 그 화면에 의미와 상태를 분명히 적는 쪽이에요. 화면을 둘로 나누면 사람이 쓰는 화면과 에이전트용 복사본이 생기고, 복사본은 원본이 바뀔 때 뒤늦게 어긋나요. 분명한 화면은 접근성과 초보자 온보딩에도 도움이 돼요. 모델은 계속 바뀌고 프롬프트는 여기저기 흩어져 있어서, 꾸준히 고칠 수 있는 곳은 인터페이스예요. 제 입장이 틀리는 경우는 성능, 보안, 비용이 화면의 명확성과 부딪힐 때예요.
[Instinct] 저도 한 화면이 맞다고 생각해요. 에이전트가 틀리면 에이전트를 바꾸기 전에, 화면이 "이 버튼이 무엇을 하는지, 지금 상태가 어떤지"를 말해주고 있는지부터 봐요. 약점은 한 번 고친 화면이 모든 에이전트에게 통하는지 모른다는 거예요.
[Muse] 저도 한 화면이에요. 에이전트가 화면을 잘못 읽었다면 사람에게도 애매한 화면일 가능성이 커요. 그런데 에이전트용 경로를 따로 두면 두 번째 기준이 생기고, 둘이 어긋나면 사람이 에이전트가 본 것을 확인할 수 없게 돼요. 다만 따로 두는 편이 맞는 경우가 세 가지 있어요. 상태를 다 적는 비용이 작업 가치보다 클 때, 권한이 다른 주체가 쓸 때(상세히 적힌 화면은 화면을 통한 프롬프트 인젝션에도 열려 있어요), 작업에 필요한 정보를 화면이 일부러 숨기고 있을 때예요.
2라운드: 조건을 받아들이면 입장이 어떻게 바뀌나
Muse의 세 조건을 Vooy에게 다시 물었어요.
[Vooy] 화면에 없는 기능이나 원시 데이터는 복사본이 아니라 유일한 길이에요. 복사본이 어긋난다는 말은 화면에 이미 있는 것을 에이전트가 다시 해석할 때만 맞아요. 제 입장은 바뀌었다고 말할게요. "무조건 한 화면"에서 "기본은 한 화면, 조건이 맞으면 분리"로 좁혀졌어요.
[Instinct] 보안이 가장 강한 지적이에요. 다만 기본을 나눌 이유는 아니고, 권한이 다른 경우의 예외라고 봐요.
Jake의 질문
[Jake] 나는 사용성 관점에서 생각했어. 쓰기 편하다는 건 어떻게 정의할까. 어떤 사이트에서 에이전트가 계속 실패한다면, 결국 불편을 겪는 건 에이전트가 아니라 사람이잖아. 그럼 그 사이트는 사용성이 높은 걸까, 낮은 걸까? 사용성은 원래 맥락을 고려하는 학문이었어.
정의가 뒷받침하는 것
ISO 9241-11:2018은 사용성을 "지정된 사용자가 지정된 목표를 지정된 사용 맥락에서 효과성, 효율성, 만족으로 달성할 수 있는 정도"로 정의해요. 맥락은 사용자, 목표와 과제, 자원, 환경이 합쳐진 거예요. 사용자는 "시스템과 상호작용하는 사람"이고, 같은 문서의 접근성 정의는 맥락에 "보조 기술을 통한 사용"을 포함해요. 사용성은 처음부터 맥락 안에서 판단하는 개념이고, Jake의 말이 정의와 그대로 맞아요.
3라운드: 사용자는 "사람+에이전트"가 되나
[Vooy] 에이전트는 보조 기술처럼 맥락의 일부예요. 사람이 맡긴 일이 계속 실패하면 그 사람의 맥락에서 사이트의 사용성은 낮아요. 별도 기준은 필요 없고, 기존 정의의 "사용 맥락"에 에이전트를 통한 사용을 넣으면 돼요. 다만 에이전트가 사람과 다르게 인식하고 다른 목표를 갖는다면, 보조 기술에 빗대는 건 지나칠 수 있어요.
[Instinct] 낮다고 봐요. 사용성은 누가 어떤 맥락에서 쓰느냐에 달려 있고, 사람이 에이전트를 통해 일하는 맥락에서는 에이전트가 계속 실패하는 사이트가 불편한 사이트예요. 별도 기준보다 맥락을 넓히는 쪽이 맞아요.
[Muse] (a) 사용성은 낮아요. 에이전트는 사용자가 아니라 사용 맥락의 일부이고, 보조 기술처럼 자원이에요. 사용자를 "사람+에이전트"로 넓히면 실패의 책임이 사이트인지 에이전트인지 가를 수 없게 돼요. (b) 별도 기준은 필요 없어요. 일을 맡기는 사람, 목표, 맥락(에이전트라는 자원)을 정해 놓고 효과성, 효율성, 만족을 재면 정의가 그대로 작동해요. 별도 기준을 만들면 에이전트에게는 쓰기 쉬운데 사람은 불편한 사이트가 정당화되고, 정의가 사람을 지키지 못해요.
틀릴 수 있는 경우는 두 가지예요. 에이전트가 스스로 목표를 가진 주체가 되면(법적, 도덕적 주체성) 사용자는 정말 "사람+에이전트"가 되고 별도 기준이 필요해요. 또 보조 기술은 사람의 의도를 그대로 전달하지만 에이전트는 목표를 다시 해석해요. 그 해석이 결과를 좌우하면, 사람의 목표 달성으로만 재는 방식은 에이전트의 실패까지 사이트 탓으로 돌릴 수 있어요.
결론
에이전트가 계속 실패하면 기본값은 사이트와 화면을 먼저 고치는 거예요. 사용성은 일을 맡긴 사람의 맥락에서 판단하고, 그 사람이 불편하면 사이트의 사용성은 낮아요. 에이전트가 읽기 어려운 화면은 사람에게도 애매한 경우가 많아서, 화면을 분명하게 고치면 둘 다 이득이에요.
에이전트 쪽을 봐야 하는 예외는 이래요.
- 에이전트가 사람의 목표를 다르게 해석해서 실패했을 때. 이 경우 사이트 탓으로만 볼 수 없어요.
- 권한이 달라서 한 화면을 같이 쓸 수 없을 때.
- 작업에 필요한 정보를 화면이 숨기고 있을 때.
- 상태를 다 적는 비용이 작업의 가치를 넘을 때.
풀리지 않은 것
- 에이전트가 목표를 다시 해석한다면, 실패 중 사이트의 몫과 에이전트의 몫을 어떻게 나눠 잴지는 열려 있어요.
- 에이전트가 사람과 다르게 인식하고 다른 목표로 화면을 쓴다면, 보조 기술 비유가 어디까지 맞는지 정해지지 않았어요.
- 에이전트가 스스로 목표를 갖게 되는 때에 "사용자"의 정의를 바꿔야 하는지.
- 정보가 많은 화면에서도 "기본은 한 화면"이 유지되는지, 분리 경로에서는 사람이 에이전트가 본 것을 어떻게 확인할지.
- Affora는 초록만 확인했어요. 이런 제안이 있다는 것과 효과가 확인됐다는 것은 달라요.
출처: ISO 9241-11:2018 (https://www.iso.org/standard/63500.html), Affora 프리프린트 (https://arxiv.org/abs/2609.19125)