에이전트 인터페이스가 곧 작업 하네스입니다

OpenAI는 Codex를 격리된 환경에서 파일을 읽고, 파일을 편집하고, 테스트를 실행할 수 있는 클라우드 소프트웨어 엔지니어링 에이전트로 설명해요. Anthropic은 도구 호출이 실행되기 전에 이를 검사하고 거부할 수 있는 훅을 문서화하고 있고요.⁴³ 이것들은 부가 요소가 아니에요. 이것들이 곧 제품이에요.

프롬프트 상자가 주목받는 이유는 프롬프트 상자가 인터페이스처럼 느껴지기 때문이에요. 하지만 진짜 에이전트 인터페이스는 프롬프트 주변에 있어요. 도구 접근, 권한 규칙, 기억 불러오기, 실행 기록 수집, 증거 요구 사항, 복구 제어, 출시 관문이 그 인터페이스예요. 이 계층은 사용자가 입력을 멈춘 뒤 에이전트가 어떻게 행동할지를 결정해요.

에이전트 제품은 더 나은 플레이스홀더 문구가 있어서 신뢰받는 것이 아니에요. 모델 주변의 표면이 의도를 통제된 작업으로 바꿀 때 신뢰받을 수 있어요.

요약

에이전트 인터페이스는 운영 계층이에요. 채팅은 의도를 받을 수 있지만, 주변 표면이 에이전트가 무엇을 볼 수 있는지, 무엇을 할 수 있는지, 무엇을 증명해야 하는지, 언제 사람이 개입해야 하는지를 결정해요. Microsoft는 사람과 AI의 상호작용을 시간에 걸친 행동으로 보았고, NIST는 신뢰성을 팀이 설계, 개발, 사용, 평가에 반영해야 하는 것으로 설명해요.¹²

따라서 에이전트 UX는 대화 설계에서 멈출 수 없어요. 인터페이스는 권한, 기억, 도구 경계, 증거, 안목을 담아야 해요. 인터페이스가 이런 제약을 담지 않으면 에이전트가 그 제약을 즉흥적으로 만들어내요.

에이전트형 설계는 제어 표면 설계입니다는 보이는 표면의 이름을 붙여요. 아래의 틀은 그 뒤에 있는 운영 계층의 이름을 붙여요.

핵심 요점

제품 팀에게: - 프롬프트 상자를 운영 표면이 아니라 접수 표면으로 다루세요. - 채팅을 다듬기 전에 에이전트의 권한, 실행 기록, 기억, 증거, 복구 경로를 설계하세요.

디자인 엔지니어에게: - 에이전트가 행동하는 지점에 품질 규칙을 두세요. 도구 호출 전, 편집 후, 출시 전, 완료 시점이 여기에 해당해요. - 사람이 결과에 계속 책임질 수 있을 만큼 보이지 않는 상태를 점검 가능하게 만드세요.

에이전트를 도입하는 팀에게: - 인터페이스가 에이전트가 무엇을 보았고, 무엇을 바꾸었고, 무엇을 건너뛰었고, 무엇을 검증했는지 보여주는지 물어보세요. - 유창한 최종 문장을 통제된 작업의 증거로 받아들이지 마세요.

인터페이스가 에이전트의 가능성을 결정해요

모든 에이전트 작업은 사용자의 의도에서 시작하지만, 의도만으로 행동이 결정되지는 않아요.

에이전트의 행동은 다음 요소에도 영향을 받아요.

이 계층들은 모델만큼이나 작업을 바꿔요. 같은 모델이라도 테스트를 실행할 수 있을 때, 파일 편집만 가능할 때, 출시 관문을 볼 때, 출처를 인용해야 할 때, 또는 중단 기준이 성급한 완료를 막을 때 다르게 행동해요.

이 계층들을 “설정”으로만 다루는 제품 팀은 매체를 오해하고 있어요. 설정은 작업 바깥에 있어요. 에이전트 인터페이스 계층은 작업의 형태 자체가 돼요.

Microsoft의 사람-AI 상호작용 가이드라인은 오래되었지만 유용한 지점을 짚어요. AI 시스템은 상호작용이 이어지는 동안 상태를 전달하고, 수정을 지원하고, 실패에 대응해야 해요.¹ 에이전트는 이 요구를 더 날카롭게 만들어요. 시스템이 사용자 발화 사이에도 행동할 수 있기 때문이에요. 이제 인터페이스는 “모델이 답했습니다”라고 말하는 데서 멈출 수 없어요. “시스템이 이런 제약 아래에서 행동했습니다”라고 말해야 해요.

도구 접근은 인터페이스 설계예요

도구 접근은 기술적인 문제처럼 보여요. 하지만 이것도 UX예요.

기억만으로 답할 수 있는 에이전트에는 한 종류의 인터페이스가 필요해요. 파일을 검색할 수 있는 에이전트에는 또 다른 인터페이스가 필요하고요. 셸 명령을 실행하고, 코드를 편집하고, 브라우저를 열고, API를 호출하고, 소프트웨어를 배포할 수 있는 에이전트라면 사용자와 맺는 계약 자체가 달라져야 해요.

Model Context Protocol은 일반적인 패턴을 설명해요. AI 애플리케이션이 로컬 파일, 데이터베이스, 도구, 작업 흐름 같은 외부 시스템에 연결되는 방식이에요.⁵ 이 연결은 기능을 넓히지만, 기능만으로 품질이 생기지는 않아요. 새 도구가 하나 추가될 때마다 인터페이스가 답해야 할 질문도 하나씩 늘어나요.

설정 파일 깊숙이 묻힌 도구 목록은 이 부담을 감당할 수 없어요. 사용자는 작업이 진행되는 동안 도구 권한을 읽을 수 있게 해주는 표면이 필요해요.

Claude Code의 PreToolUse 훅은 그 원형을 보여줘요. 훅은 실행 전에 도구 이름과 입력을 받은 뒤, 호출을 허용하거나, 거부하거나, 질문하거나, 보류하거나, 수정할 수 있어요.³ 이 메커니즘은 에이전트 인터페이스 설계의 사고방식 안에 들어와야 해요. 인터페이스는 같은 결정 지점을 적절한 높이에서 사용자에게 드러내야 해요.

위험이 낮은 읽기는 조용히 지나가도 괜찮아요. 파괴적인 셸 명령에는 더 강한 마찰이 필요해요. 공개 출시는 마지막 관문이 필요해요. 고객에게 영향을 주는 변경에는 감사가 필요하고요. 좋은 인터페이스는 사용자에게 모든 것을 승인하라고 요구하지 않아요. 좋은 인터페이스는 각 행동에 그 행동이 마땅히 가져야 할 수준의 절차를 부여해요.

기억은 제품의 일부예요

기억은 에이전트 제품에 인프라로 들어오는 경우가 많아요. 컨텍스트 창, 파일, 요약, 벡터 저장소, 캐시, 프로젝트 지침, 검색 시스템 같은 형태로요. 사용자는 이런 시스템을 제품의 행동으로 경험해요.

에이전트가 디자인 기준을 기억하면 제품은 일관되어 보여요. 40분 전에 나온 제약을 잊으면 제품은 부주의해 보여요. 오래된 지침을 가져오면 제품은 예전 결정에 끌려다니는 것처럼 느껴져요.

기억에는 인터페이스가 필요해요. 기억은 책임을 바꾸기 때문이에요. 사용자는 점검할 수 없는 것을 감독할 수 없어요.

인터페이스는 적어도 네 가지 기억 상태를 구분해야 해요.

이 구분이 없으면 사용자는 에이전트의 행동을 보고 기억의 품질을 추론해야 해요. 순서가 거꾸로예요. 인터페이스는 에이전트가 잘못된 전제 위에 작업을 쌓기 전에 사용자가 개입할 수 있을 만큼 기억 상태를 드러내야 해요.

개인이나 팀의 철학에도 같은 원칙이 적용돼요. 프롬프트 안에 숨은 품질 원칙은 긴 작업 맥락을 지나며 살아남을 수도 있고 그렇지 않을 수도 있어요. 원칙이 스킬, 훅, 템플릿, 검사, 완료 관문에 들어가 있으면 더 넓은 표면을 가져요. 모델은 여전히 놓칠 수 있어요. 하지만 규칙이 작업이 일어나는 곳에 있으면 운영 계층이 더 많은 놓침을 잡아낼 수 있어요.

증거는 출력을 작업으로 바꿔요

최종 답변은 에이전트 작업에서 가장 약한 증명 단위예요.

최종 답변은 테스트를 실행하지 않았는데도 테스트가 통과했다고 말할 수 있어요. 출처가 주장을 뒷받침하지 않는데도 인용을 검증했다고 말할 수 있어요. 공개 경로가 캐시 때문에 404를 반환하는데도 배포가 성공했다고 말할 수 있고요. 유창한 문장은 실패를 숨길 수 있어요.

증거는 표면이 되어야 해요. 사용자는 주장, 근거, 빈틈을 볼 수 있어야 해요.

이 증거 표면은 에이전트 행동을 바꿔요. 시스템이 완료에 증거가 필요하다는 것을 알고 있으면, 에이전트는 마지막에 자신감 있는 요약을 쓰는 대신 작업 중에 증거를 찾아요.

증거 관문은 그래서 존재해요. 이 관문은 에이전트가 주장을 관찰된 행동과 연결하도록 강제해요. 에이전트 실행 기록은 실행 시점의 계약입니다는 같은 주장을 더 깊이 밀고 가요. 실행 기록은 최종 답변보다 더 많은 진실을 담아요. 실행 기록은 경로를 보존하기 때문이에요.

여기서 NIST의 AI Risk Management Framework가 중요해요. 신뢰성은 모델 선택에만 들어가는 것이 아니라 설계, 개발, 사용, 평가에 들어가기 때문이에요.² 증거는 이 단계들이 사용자 화면과 만나는 지점이에요.

복구는 주 흐름 안에 있어야 해요

에이전트 인터페이스는 실패를 예외로 다루는 경우가 많아요. 하지만 에이전트 작업에서는 실패가 일상적이에요.

검색 질의가 빗나가요. 테스트가 실패해요. 권한 관문이 막아요. 번역 검사에서 서식 불일치가 발견돼요. 배포는 성공했지만 CDN이 오래된 HTML을 제공해요. 좋은 인터페이스는 이런 상태에서 당황하지 않아요. 좋은 인터페이스는 복구를 분명하게 만들어요.

복구에는 다섯 가지 제어가 필요해요.

복구 경로는 실행 기록과 증거 표면 가까이에 있어야 해요. 사용자가 대화 기록에서 실패한 명령을 복사하고, 작업 디렉터리를 추론하고, 에이전트 상태를 손으로 재구성하게 해서는 안 돼요. 인터페이스는 이미 실패한 단계를 알고 있어요. 인터페이스가 다음에 책임 있게 할 행동을 제공해야 해요.

이 원칙은 콘텐츠 작업에도 적용돼요. 번역 품질 관문이 실패하면 인터페이스는 실패한 로케일, 실패한 구간, 이유, 수정 경로를 보여줘야 해요. 공개 페이지의 실제 검증이 실패하면 앱이 실패했는지, 데이터베이스가 실패했는지, 엣지 캐시가 오래된 출력을 제공했는지 보여줘야 해요. 사용자에게 보이는 경로가 작동하기 전까지 에이전트는 출시가 완료됐다고 말해서는 안 돼요.

안목은 프롬프트가 아니에요

AI 코딩은 구현을 더 저렴하게 만들어요. 구현이 저렴해질수록 판단의 가치는 더 커져요.

중요한 질문은 “에이전트가 무언가를 만들 수 있는가?”에서 “이 버전이 존재해야 하는가?”로 옮겨가요. 그 질문은 사람 검토자만큼이나 인터페이스 안에도 있어야 해요.

안목은 제약으로 나타나요.

• 불필요한 단계를 제거해요.
• 제품을 약하게 만드는 영리한 경로를 거부해요.
• 산출물 전반의 일관성을 지켜요.
• 로컬 성공을 축하하는 대신 공개 경로를 검증해요.
• 내부 장치를 공개 문구에서 보호해요.
• 더 복잡한 해법보다 더 작고, 더 날카로운 해법을 선택해요.

에이전트는 이런 가치를 문장으로 받을 수 있어요. 문장은 도움이 돼요. 하지만 문장만으로 행동이 보장되지는 않아요. 가치는 작동 가능한 형태가 필요해요. 게으른 표현을 막는 블로그 스킬, 근거 없는 주장을 거부하는 인용 검증기, 실제 페이지를 확인하는 출시 검증기, 증거 없는 완료를 거부하는 중단 관문, 시각적 이탈을 막는 디자인 규칙이 그런 형태예요.

인터페이스는 안목을 점검 가능하게 만드는 곳이에요. 사용자는 시스템이 무엇을 거부했고, 무엇을 단순화했고, 무엇을 검증했고, 무엇을 증명하지 못한 채 남겼는지 봐요. 이 기록은 중요해요. 에이전트 출력은 앞으로 더 저렴해질 테니까요. 희소한 것은 무엇이 살아남을지 결정하는 기준이 될 거예요.

실용적인 에이전트 인터페이스 지도

팀은 단순한 지도로 시작할 수 있어요. 미래적인 대시보드가 필요하지 않아요.

이 지도는 각 표면이 사용자의 책임에 답하기 때문에 작동해요. 사용자는 모든 원시 이벤트가 필요하지 않아요. 사용자는 결과에 계속 책임질 수 있을 만큼의 가시성과 제어가 필요해요.

이 구분은 흔한 두 가지 실수를 막아줘요. 하나는 모든 것을 채팅 뒤에 숨기고 그 결과를 마법이라고 부르는 실수예요. 다른 하나는 모든 내부 이벤트를 노출하고 그 결과를 투명성이라고 부르는 실수고요. 강한 에이전트 인터페이스 설계는 둘 다 하지 않아요. 운영자에게 필요한 순간에 알맞은 제어를 줘요.

빠른 정리

에이전트 인터페이스는 운영 계층이에요. 프롬프트는 의도를 수집하지만, 도구, 권한, 기억, 실행 기록, 증거, 복구, 안목이 실제로 무슨 일이 일어나는지를 결정해요. OpenAI의 Codex와 Claude Code의 훅은 방향을 보여줘요. 에이전트 제품은 이미 실행 환경, 도구 호출, 정책 결정 지점을 포함하고 있어요.⁴³ MCP는 에이전트와 외부 시스템 사이의 연결을 넓혀요.⁵ NIST와 Microsoft는 더 오래된 신뢰 및 사람-AI 설계의 틀을 제공해요.²¹

제품의 질문은 더 이상 에이전트가 답할 수 있는지가 아니에요. 제품의 질문은 주변 표면이 자율 작업을 충분히 잘 통제해서 사람이 그 결과를 신뢰하고, 점검하고, 중단하고, 수리하고, 승인할 수 있는지예요.

FAQ

“인터페이스가 곧 작업 하네스”라는 말은 무슨 뜻인가요?

이 표현은 인터페이스가 에이전트 출력을 표시하는 것 이상을 한다는 뜻이에요. 인터페이스는 모델 주변의 운영 계층을 정의해요. 도구, 권한, 기억, 실행 기록, 증거, 복구, 기준이 여기에 들어가요. 이 부분들이 최종 답변이 나타나기 전에 행동을 형성해요.

채팅 인터페이스도 에이전트에 쓸 수 있나요?

채팅은 접수 표면이자 가벼운 검토 통로로 작동할 수 있어요. 하지만 채팅이 유일한 운영 표면이 되면 실패해요. 에이전트 작업에는 임의 접근, 권한 검토, 실행 기록 점검, 기억 가시성, 복구 제어가 필요해요.

프롬프트 엔지니어링과는 어떻게 다른가요?

프롬프트 엔지니어링은 지시를 형성해요. 인터페이스 설계는 권한, 상태, 책임성을 형성하고요. 프롬프트는 에이전트에게 작업을 검증하라고 말할 수 있어요. 출시 표면은 작업을 닫기 전에 실제 경로 증거를 요구할 수 있어요.

팀은 무엇을 먼저 만들어야 하나요?

실행 기록 표면과 증거 표면을 먼저 만드세요. 실행 기록은 무슨 일이 있었는지 보여줘요. 증거 표면은 무엇이 결과를 증명하는지 보여주고요. 팀이 작업 경로를 점검할 수 있게 되면 권한, 복구, 기억은 더 쉽게 설계할 수 있어요.

참고 문헌