
제품이 상황을 알아채고 다음 행동을 먼저 제안하면 편리합니다. 하지만 필요한 메뉴를 앞으로 가져오는 것과, 내 대신 서비스를 신청하는 것은 전혀 다른 일입니다.
이번 주 글에서는 이 경계가 반복해서 등장했습니다. 상황에 따라 달라지는 화면, 도구를 실행하는 에이전트, 자동화 이후 사람에게 남겨야 할 역할까지. 할 수 있는 일이 많아질수록 어디까지 맡길지 구체적으로 정해야 합니다.
이번 주에는 사람이 개입할 자리가 분명한 자동화를 살펴봅니다. 모든 단계에 확인 버튼을 붙이자는 이야기는 아닙니다. 제안과 실행을 구분하고, 잘못됐을 때 멈추거나 고칠 수 있는 자리를 만드는 이야기입니다.
이번 주 아티클 핵심 포인트 3가지를 공유합니다👇

1️⃣ 상황을 이해했다고, 실행까지 허락받은 건 아닙니다
상황 중심 디자인: 정해진 흐름을 넘어 우선순위 설계하기는 지금 필요한 행동을 먼저 보여주되, 익숙한 구조와 선택권을 유지하는 접근을 제안합니다. 예를 들어 사고 신고 뒤 긴급 지원 메뉴를 강조할 수는 있지만, 출동 서비스를 신청하려면 별도의 확인이 필요합니다. 이 사례는 검증된 성과가 아니라 설계 제안입니다. 그래도 구분은 선명합니다. 시스템의 추정이 맞는지와 그 추정에 따라 행동해도 되는지는 다른 질문입니다. 무엇을 근거로 화면을 바꿨는지, 사용자가 거절하면 어떻게 돌아가는지까지 함께 설계해야 합니다.

2️⃣ 답변이 끝난 것과 작업이 끝난 것은 다릅니다
AI 에이전트 직접 만들기: 50줄의 Python에서 MCP까지는 에이전트를 판단, 도구 실행, 결과 관찰의 반복으로 풀어냅니다. 이 구조를 보면 화면에 보여줄 상태도 달라집니다. 모델이 무엇을 하겠다고 말한 상태, 프로그램이 실제로 실행한 상태, 결과를 확인한 상태는 구분되어야 합니다. 자연스러운 마지막 답변만으로 작업 완료를 판단하면 실패나 미실행을 놓칠 수 있습니다. 사용자가 맡긴 일이 지금 어디까지 진행됐는지, 승인을 기다리는지, 다시 시도해야 하는지를 알 수 있어야 안심하고 다음 행동을 정할 수 있습니다.

3️⃣ 사람을 남기는 것보다, 어떤 권한을 남길지가 중요합니다
UX 디자인은 인간의 일로 남아야 할까?는 직업 전체를 자동화에서 보호하는 대신, 의미 있는 인간 참여의 최소선을 정하자는 관점을 소개합니다. 사람이 관계에 직접 참여해야 하는지, 최종 책임을 맡아야 하는지, 일을 배우며 성장할 기회를 남겨야 하는지 나눠보는 겁니다. 검토자가 있다는 사실만으로 충분하지는 않습니다. 결과를 바꾸거나 중단할 권한 없이 확인만 하는 자리라면 참여의 의미가 약해집니다. 자동화할 업무를 정할 때 남겨둘 책임과 선택권도 함께 적어야 한다는 이야기로 읽힙니다.
그 주에 등록된 도구와 아티클에서 뽑은 시그널을 정리해서 보내드려요.