에이전트형 디자인은 제어 표면 설계입니다

대부분의 AI 인터페이스 작업은 여전히 에이전트를 더 똑똑한 텍스트 상자처럼 다룹니다. 에이전트형 디자인은 다른 전제에서 출발합니다. 소프트웨어가 시간에 걸쳐 행동하고, 도구를 호출하고, 파일을 건드리고, 돈을 쓰거나, 프로덕션 상태를 바꿀 수 있게 되면 설계 문제는 제어 표면의 문제가 됩니다.

에이전트형 디자인은 자율 소프트웨어를 보이게 하고, 중단할 수 있게 하며, 점검 가능하고, 되돌릴 수 있고, 신뢰할 가치가 있게 만드는 규율입니다. 제품은 채팅 기록이 아닙니다. 제품은 사람이 에이전트가 무엇을 하고 있는지 이해하고, 에이전트가 다음에 무엇을 해도 되는지 결정하며, 에이전트가 이미 한 일을 검증할 수 있게 해주는 표면입니다.

이 관점이 중요한 이유는 에이전트가 일반적인 양식, 대시보드, 코파일럿과는 다른 방식으로 실패하기 때문입니다. 양식은 제출 시점에 실패합니다. 대시보드는 오래된 데이터를 보여주면서 실패합니다. 코파일럿은 나쁜 문장을 제안하면서 실패합니다. 에이전트는 움직이는 과정에서 실패합니다. 잘못된 갈림길로 가고, 잘못된 도구를 선택하고, 필요한 증거를 놓치고, 맥락을 잃고, 권한을 과하게 쓰고, 너무 일찍 멈추거나, 국소적으로는 성공했지만 제품 전체를 약하게 만들 수 있습니다.

디자인은 프롬프트 다듬기에서 운영 제어로 이동해야 합니다.

요약

에이전트형 디자인은 추상적인 의미의 “AI를 위한 UX”가 아닙니다. 행동하는 시스템을 위한 제어 표면을 설계하는 일입니다. Microsoft는 오늘날의 코딩 에이전트가 등장하기 훨씬 전부터 인간-AI 상호작용을 별도의 인터페이스 설계 문제로 다뤘고, Google PAIR도 AI 디자인 가이드에서 같은 인간 중심 흐름을 이어가고 있습니다.¹² 최신 에이전트 제품은 이 필요성을 더 선명하게 만듭니다. OpenAI는 Codex를 격리된 환경에서 작업하는 클라우드 에이전트로 설명하고, Claude Code는 실행 전에 도구 호출을 가로챌 수 있는 훅을 제공합니다.⁵⁴

실무적인 결론은 분명합니다. 에이전트 제품에는 상태, 권한, 실행 추적, 기억, 증거, 되돌리기, 감독을 위한 표면이 필요합니다. 채팅은 입력으로 남을 수 있습니다. 하지만 전체 인터페이스로 남아서는 안 됩니다.

핵심 요점

제품 디자이너에게: - 프롬프트 입력을 설계하기 전에 에이전트 상태를 먼저 설계하세요. 사용자는 에이전트가 계획 중인지, 행동 중인지, 막혔는지, 대기 중인지, 검증 중인지, 완료했는지 알아야 합니다. - 권한 검토를 핵심 흐름으로 다루세요. 위험한 도구 호출이 가벼운 채팅 중단처럼 보여서는 안 됩니다.

에이전트 구축자에게: - 실행 추적 표면을 만들 수 있을 만큼 충분한 실행 세부 정보를 기록하세요. 도구 이름만으로는 부족합니다. 표면에는 인자, 출력, 종료 상태, 파일 경로, 부수 효과가 필요합니다. - 중단과 복구를 일급 기능으로 만드세요. 사용자는 전체 기록을 읽지 않고도 에이전트를 일시 중지하고, 점검하고, 방향을 바꾸고, 되돌리거나, 분기할 수 있어야 합니다.

에이전트를 도입하는 팀에게: - 채팅이 얼마나 유창하게 느껴지는지로 인터페이스 품질을 판단하지 마세요. 운영자가 다음 질문에 답할 수 있는지 보세요. 무슨 일이 있었는가, 왜 일어났는가, 어떤 권한으로 일어났는가, 어떤 증거가 있는가? - 취향을 계속 판단 과정에 포함하세요. 올바른 에이전트 행동도 일관성, 존엄성, 제품 품질을 해칠 수 있습니다.

사용자가 달라졌습니다

에이전트 제품의 사용자는 단순히 프롬프트를 입력하는 사람이 아닙니다. 사용자는 운영자가 됩니다.

프롬프트를 입력하는 사람은 답을 요청합니다. 운영자는 과정을 감독합니다. 프롬프트를 입력하는 사람은 문장이 그럴듯하게 들리는지 신경 씁니다. 운영자는 시스템이 올바른 파일을 건드렸는지, 올바른 출처를 사용했는지, 올바른 제약을 지켰는지, 적절한 시점에 멈췄는지 신경 씁니다.

이 차이는 인터페이스를 바꿉니다. 프롬프트 상자는 표현에 최적화됩니다. 제어 표면은 상태, 위험, 타이밍, 증명에 최적화됩니다.

전통적인 소프트웨어는 사용자가 대부분의 상태 변화를 직접 일으키기 때문에 과정을 숨길 수 있습니다. 버튼에는 “Send”라고 쓰여 있습니다. 사용자가 클릭합니다. 앱이 전송합니다. 에이전트 소프트웨어는 의도와 행동 사이에 의사결정 실행 환경을 끼워 넣습니다. 사용자가 결과를 요청하면 시스템이 경로를 선택합니다. 인터페이스는 사용자가 그 결과에 계속 책임질 수 있을 만큼 그 경로를 드러내야 합니다.

Microsoft의 인간-AI 상호작용 가이드라인은 이 방향을 가리킵니다. 이 가이드라인은 상호작용 시간 전반에서 AI 시스템의 행동을 다룹니다. 기대 설정, 사회적 맥락과의 정합성, 상태 표시, 수정 지원, 실패 처리까지 포함합니다.¹ 오래된 교훈은 에이전트에도 그대로 적용되지만, 에이전트는 AI 행동이 더 이상 추천에서 끝나지 않기 때문에 판돈을 높입니다. 그 행동은 도구 호출이 될 수 있습니다.

에이전트형 디자인은 상태에서 시작합니다

좋은 에이전트형 디자인은 신뢰를 요구하기 전에 상태를 보이게 만듭니다.

에이전트에는 “thinking”과 “done”보다 더 많은 상태가 있습니다.

대부분의 채팅 제품은 이 상태들을 하나의 움직이는 스피너로 압축합니다. 스피너는 시스템이 멈추지 않았다는 뜻만 말해줍니다. 에이전트가 읽고 있는지, 쓰고 있는지, 기다리는지, 재시도하는지, 막혀 있는지는 말해주지 않습니다.

에이전트 상태에는 더 풍부한 어휘가 필요합니다. 표면은 현재 단계, 마지막으로 의미 있었던 행동, 다음에 하려는 행동, 에이전트가 아직 끝내지 못한 이유를 보여줘야 합니다. 좋은 상태 표면은 미스터리를 점검 가능한 움직임으로 바꾸기 때문에 사용자의 불안을 줄입니다.

어려운 설계 질문은 밀도입니다. 진지한 에이전트는 긴 실행 중에 수천 개의 이벤트를 만들 수 있습니다. 모든 이벤트를 보여주면 소음이 됩니다. 모든 이벤트를 숨기면 맹목적 신뢰가 됩니다. 제어 표면은 기본적으로 요약하고, 필요할 때 확장되어야 합니다.

권한은 설계 재료입니다

권한은 설정 페이지가 아닙니다. 권한은 에이전트형 디자인의 핵심 재료 중 하나입니다.

에이전트는 사용자가 부여한 권한을 통해 행동합니다. 파일 쓰기, 셸 명령, 브라우저 동작, API 호출, 배포 단계, 결제 작업, 고객에게 영향을 주는 행동은 모두 서로 다른 위험을 가집니다. 인터페이스는 결정 시점에 그 위험을 읽을 수 있게 만들어야 합니다.

Claude Code의 훅 참고 문서는 이 아이디어의 원시적인 형태를 보여줍니다. PreToolUse 훅은 Bash 명령을 검사하고, 도구 호출이 실행되기 전에 파괴적인 작업을 거부하는 결정을 반환할 수 있습니다.⁴ 이 메커니즘은 설계의 형태를 증명합니다. 제어 표면은 대기 중인 작업을 위험도별로 정렬하고, 전체 명령이나 도구 페이로드를 보여주며, 호출 이유를 설명하고, 사용자가 요청을 승인, 거부, 보류, 재작성할 수 있게 만들 수 있습니다.

핵심 전환은 이것입니다. 권한 검토는 중단이 아니라 대기열이 되어야 합니다.

중단은 한두 번의 결정에는 효과가 있습니다. 하지만 에이전트가 긴 작업에서 40개의 작업을 수행할 때는 실패합니다. 권한 대기열은 사용자가 낮은 위험의 승인을 묶어서 처리하고, 높은 위험의 행동을 멈춰 세우며, 전체 위험 프로필을 한곳에서 검토하게 해줍니다. 사용자는 에이전트의 글을 읽다가 명령을 평가하느라 계속 끌려 다니지 않게 됩니다.

위험 표현에도 취향이 필요합니다. 빨간 테두리, 경고 아이콘, 모달 마찰은 도움이 될 수 있습니다. 하지만 모든 것이 긴급해 보이면 사용자가 경고를 무심코 승인하도록 훈련시킬 수도 있습니다. 인터페이스는 되돌릴 수 없거나 외부에 보이는 행동에만 시각적 경보를 아껴 써야 합니다. 읽기 전용 검색이 프로덕션 데이터베이스 마이그레이션과 같은 옷을 입어서는 안 됩니다.

실행 추적은 새로운 정보 구조입니다

에이전트형 디자인에는 실행 추적 구조가 필요합니다.

실행 추적은 에이전트가 한 일을 순서대로 기록한 것입니다. 프롬프트, 도구 호출, 인자, 읽은 파일, 변경한 파일, 실행한 명령, 연 출처, 테스트 출력, 권한 결정, 재시도, 최종 증거가 여기에 포함됩니다. 채팅 기록은 그 일부를 담을 수 있지만, 기록은 정보 구조가 아닙니다. 그것은 스크롤입니다.

실행 추적 표면은 네 가지 질문에 빠르게 답해야 합니다.

이 표면은 증거 관문과 직접 연결됩니다. “tests passed”라고 말하는 최종 답변은 테스트 명령과 종료 상태를 가리켜야 합니다. 논문을 인용하는 공개 글은 정확한 출처와 주장 정합성을 가리켜야 합니다. 동등성을 주장하는 마이그레이션 보고서는 여전히 작동하는 구체적인 사용자 경로를 가리켜야 합니다.

최근의 실행 추적 연구도 같은 방향을 가리킵니다. 저는 에이전트 실행 추적은 실행 환경 계약입니다에서 최종 답변이 신뢰하기에 가장 약한 단위라고 주장했습니다. 실행 추적은 의도에서 행동을 거쳐 증거로 이어지는 경로를 보존하기 때문에 더 강합니다.

기억에는 브라우저가 필요합니다

에이전트형 디자인에는 기억 설계도 필요합니다.

에이전트는 시간에 걸쳐 맥락을 들고 갑니다. 어떤 맥락은 활성 창 안에 있습니다. 어떤 맥락은 압축된 요약 안에 있습니다. 어떤 맥락은 파일, 메모, 벡터 저장소, 데이터베이스, 프로젝트 지침 안에 있습니다. 어떤 것은 사라집니다. 사용자는 그 경계를 거의 보지 못합니다.

이 보이지 않음은 설계 실패를 만듭니다. 에이전트가 이전 결정을 뒤집을 때, 사용자는 에이전트가 동의하지 않은 것인지, 잊은 것인지, 요약을 잘못한 것인지, 관련 기억을 불러오지 않은 것인지 알 수 없습니다. 채팅은 실행 환경이 모델이 볼 수 있는 것을 바꿨을 때도 기억이 연속적인 것처럼 느끼게 만듭니다.

기억 브라우저는 세 개의 층을 드러내야 합니다.

이 브라우저가 비공개 사고 과정을 드러낼 필요는 없습니다. 드러내야 하는 것은 운영 기억입니다. 지침, 제약, 출처 경로, 결정, 결과물, 그리고 시스템이 향후 행동을 이끌기 위해 사용할 요약입니다.

검색도 같은 설계 계열에 속합니다. 이전 글의 grep/vector 결과는 검색 품질이 검색기에만 달려 있지 않고, 실행 환경, 전달 경로, 도구 루프를 닫는 모델의 능력에 달려 있음을 보여줬습니다.⁶ 검색이 실행 환경 안에 있다면 검색 가시성은 인터페이스 안에 있어야 합니다. 사용자는 에이전트가 무엇을 검색했는지, 무엇을 놓쳤는지, 무엇을 열었는지, 왜 다음 쿼리가 바뀌었는지 알아야 합니다.

감독은 세세한 간섭이 아닙니다

에이전트 제품은 사람의 감독을 마찰로 묘사하는 경우가 많습니다. 강한 에이전트형 디자인은 감독을 제품 자체로 다룹니다.

NIST는 AI Risk Management Framework를 AI 시스템의 설계, 개발, 사용, 평가에 신뢰성 고려 사항을 통합하는 방법으로 설명합니다.³ 이 표현이 중요합니다. 신뢰성은 모델 훈련 시점에만 들어오지 않습니다. 설계 시점, 사용 시점, 평가 시점에도 들어옵니다.

에이전트에서 감독이란 사용자가 다음을 할 수 있다는 뜻입니다.

• 에이전트가 무엇을 하는지 볼 수 있다.
• 되돌릴 수 없는 행동 전에 중단할 수 있다.
• 증거 경로를 점검할 수 있다.
• 실패한 갈림길에서 복구할 수 있다.
• 대안 분기를 비교할 수 있다.
• 최종 결과물을 승인하거나 거부할 수 있다.
• 무엇이 아직 검증되지 않았는지 이해할 수 있다.

세세한 간섭은 사용자에게 모든 키 입력을 승인하라고 요구합니다. 감독은 올바른 높이에서 올바른 제어를 제공합니다. 시니어 엔지니어는 모든 파일 읽기를 지켜볼 필요가 없습니다. 하지만 제안된 데이터베이스 마이그레이션, 실패한 테스트 재시도, 바뀐 공개 주장, 프로덕션 상태를 건드리는 명령은 봐야 합니다.

좋은 감독 표면은 낮은 위험의 세부 정보를 주 흐름 밖으로 옮기고, 높은 위험의 순간을 초점 안으로 끌어오면서 흐름을 보존합니다. 설계 과제는 “더 많은 가시성”이 아닙니다. 설계 과제는 조율된 가시성입니다.

취향의 층은 여전히 중요합니다

에이전트형 디자인은 모든 운영 요구사항을 만족하면서도 여전히 잘못 느껴질 수 있습니다.

권한 대기열은 올바른 사실을 드러내면서도 사용자가 벌을 받는 듯한 느낌을 줄 수 있습니다. 실행 추적 타임라인은 모든 이벤트를 담으면서도 이해를 불가능하게 만들 수 있습니다. 기억 브라우저는 저장된 모든 항목을 보여주면서도 어수선함으로 사용자의 확신을 무너뜨릴 수 있습니다. 상태 표시기는 진실을 말하면서도 시스템이 고장 난 것처럼 느끼게 만들 수 있습니다.

취향은 표면이 위험, 확신, 불확실성, 증명을 어떻게 담아낼지 결정합니다. 취향은 기술 시스템입니다: 제약, 평가 기준, 패턴 인식, 일관성입니다. 에이전트형 디자인에는 이 네 가지가 모두 필요합니다.

제약은 에이전트가 검토 없이 무엇을 해도 되는지 결정합니다. 평가 기준은 최종 결과물이 무엇을 증명해야 하는지 결정합니다. 패턴 인식은 성공한 것처럼 보이지만 취약하게 느껴지는 흐름을 잡아냅니다. 일관성은 에이전트의 작업이 제품 전체를 개선했는지, 아니면 국소적 작업만 완료했는지 묻습니다.

에이전트가 더 저렴해질수록 마지막 질문은 더 중요해집니다. AI는 산출물을 풍부하게 만듭니다. 풍부함은 거절, 편집, 일관성, 취향의 가치를 높입니다. 최고의 에이전트형 인터페이스는 행동을 최대화하지 않을 것입니다. 운영자가 어떤 행동이 일어날 가치가 있는지 결정하도록 도울 것입니다.

최소 에이전트형 디자인 체크리스트

7개의 표면에서 시작하세요.

이 표면들에 공상과학적인 인터페이스가 필요한 것은 아닙니다. 첫 버전은 평범한 표, 펼칠 수 있는 행, 단순한 필터여도 됩니다. 화려한 애니메이션보다 정직한 상태가 더 중요합니다. 제어 표면은 진실을 빠르게 말해야 합니다.

모든 에이전트 기능의 설계 질문은 단순해집니다.

에이전트의 다음 행동이 실제가 되기 전에, 사람은 무엇을 보고, 결정하고, 중단하고, 검증해야 하는가?

인터페이스가 이 질문에 답하지 못한다면, 제품은 여전히 신뢰 연극에 기대고 있는 것입니다.

빠른 정리

에이전트형 디자인은 제어 표면 설계입니다. 채팅은 입력 기본 요소로 여전히 유용하지만, 자율 작업에는 보이는 상태, 권한 대기열, 실행 추적, 기억 브라우저, 증거 표면, 복구 제어, 감독 보기가 필요합니다. Microsoft, Google, NIST는 모두 인간 중심 AI 디자인과 신뢰성을 모델 속성만이 아니라 제품 책임으로 보라고 가리킵니다.¹²³ 에이전트 도구는 그 지점을 구체화합니다. 실행 환경에는 이미 훅, 컨테이너, 실행 추적, 파일, 명령, 부수 효과가 있습니다.⁴⁵ 인터페이스는 이 부분들을 읽을 수 있게 만들어야 합니다.

이기는 에이전트 제품은 가장 매력적인 채팅을 가진 제품이 아닐 것입니다. 이기는 제품은 운영자에게 자율 작업을 위한 가장 명확하고, 가장 날카롭고, 가장 신뢰할 만한 표면을 제공하는 제품일 것입니다.

FAQ

에이전트형 디자인은 AI UX와 다른가요?

네. AI UX는 머신러닝이나 생성형 AI를 사용하는 모든 경험을 포괄합니다. 에이전트형 디자인은 시간에 걸쳐 행동하는 시스템을 다룹니다. 차이는 행위성입니다. 도구 호출, 권한, 상태 변화, 기억, 부수 효과, 복구가 핵심입니다. 이런 속성에는 유용한 문구나 프롬프트 입력만이 아니라 제어 표면이 필요합니다.

모든 에이전트 제품에 7개의 표면이 모두 필요한가요?

아닙니다. 표면적은 위험에 맞춰야 합니다. 낮은 위험의 글쓰기 도우미에는 상태, 증거, 수정 이력 정도면 충분할 수 있습니다. 코딩이나 운영 에이전트에는 권한, 실행 추적, 복구, 기억, 감독이 필요합니다. 고객에게 영향을 주는 에이전트에는 훨씬 더 강한 감사 및 승인 제어가 필요합니다.

왜 모든 것을 채팅 안에 두면 안 되나요?

채팅은 순차적이고 추가만 가능합니다. 에이전트 감독에는 임의 접근, 필터링, 비교, 일괄 검토, 상태 점검이 필요합니다. 접을 수 있는 채팅 블록은 읽기 쉬움을 높일 수 있지만, 권한 대기열, 실행 추적 타임라인, 기억 브라우저, 복구 표면을 대체할 수는 없습니다.

가장 먼저 만들 제어 표면은 무엇인가요?

실행 추적을 먼저 만드세요. 실행 추적이 없으면 다른 모든 표면은 추측이 됩니다. 실행 추적은 증거, 권한, 복구, 감사, 감독을 위한 데이터를 제공합니다. 제품은 평범한 이벤트 표에서 시작해 시간이 지나며 디자인을 개선할 수 있습니다.

References