!원문 캡처 · lexifina.com

명령줄이나 사이드바에서 에이전트와 대화하면 사용자는 요청과 답변, 도구 호출 기록을 보지만 에이전트가 실제로 일하는 과정은 대개 볼 수 없다. 작업이 길어질수록 에이전트가 한 일과 사용자가 이해한 내용 사이의 간격이 커진다. 이 글은 에이전트를 문서 안에서 작업하게 하고, 사람이 진행 중인 작업을 조정할 수 있는 시각적 인터페이스를 제안한다.

시각적 표현이 단순한 볼거리에 그치지 않고 작업을 이해하는 데 도움이 되려면, 사용자가 작업을 확인하고 개입하는 정도와 에이전트가 일을 수행하는 정도 사이에서 균형을 찾아야 한다. 화면 밖에서 일하면 더 많은 작업을 처리할 수 있고, 화면 안에서 일하면 사용자가 진행 상황을 파악하고 작업을 배우기 쉽다.

문서에서 보이고 조정할 수 있는 에이전트

문서에서 일하는 에이전트는 동료처럼 이름과 커서를 갖고, 작업 중인 문단으로 이동하며, 편집 내용을 변경 내용 추적 형태로 보여줄 수 있다. 다른 사람이 맡았거나 잠근 부분은 건드리지 않는 방식도 제시한다. 사이드바에서 나중에 작업 보고서를 읽는 대신, 해당 위치에서 변경이 이뤄지는 모습을 보며 작업을 중단하거나 지시를 바꿀 수 있다는 구상이다.

변경 사항을 승인된 수정(diff)으로 제시하고 사용자가 수락하거나 거부하게 하면 과정에 마찰이 더해진다. 대신 선택 기록을 버전 관리에 남겨 이후 에이전트가 사용자의 선호를 반영하는 데 활용할 수 있다. Cursor도 이 접근법을 설명했다.

문서 안에서 작업하면 사용자가 위치를 지정하기도 쉬워진다. 화면에 큰 화살표나 상자, 문구를 그려 코딩 에이전트를 안내하는 big-arrow-on-the-screen 사례처럼, 시각적 표시는 소프트웨어 사용법을 안내하는 데 쓸 수 있다. 사람끼리 표시를 하거나 특정 부분을 강조해 소통하듯, 에이전트에도 그런 지시 방식을 적용할 수 있다는 생각이다.

한 번에 세 개의 커서를 표시하는 실험은 대부분의 사용자에게 실시간으로 보기엔 정보가 지나치게 많다는 점을 보여준다. 글은 에이전트의 행동을 영상 결과물 등으로 다시 볼 수 있게 하고, 커서의 이동 경로를 각각 분리해 확인하며, 버전 관리로 되돌릴 수 있게 하면 문제를 줄일 수 있다고 본다. 에이전트의 커서는 기본 사이드바를 대체하지 않고 사용자가 선택해 켜는 보조 기능일 수도 있다. 이 경우 작업 방식은 그대로 두고 사용자가 주의를 기울이고 의견을 전달하는 위치만 바꾼다.

사람과 에이전트가 함께 쓰는 작업 공간

실제 업무는 여러 사람이 공유하지만 에이전트와의 대화는 대개 한 사용자에게만 보인다. 글은 협업 공간을 조직, 프로젝트, 공유 대화, 실시간 협업으로 나눈다. 회사는 기존 권한 관리 방식으로 문서를 공유하고, 프로젝트 구성원과 에이전트는 같은 문서와 사실, 결정을 참고한다. 관련 정보가 커밋 등으로 꾸준히 기록되지 않는다면 에이전트 대화 자체도 검색 가능한 업무 기록이 될 수 있다.

실시간 협업에서는 동료가 문서에서 서로를 확인하고, 각자 맡을 부분을 지정하거나 AI가 수정하지 못하도록 잠글 수 있다. 사람과 에이전트가 작성한 모든 수정 사항을 발생 순서대로 재생해 초안이 만들어진 과정을 살펴보는 방식도 포함된다.

텍스트에 고정되는 댓글은 사람과 에이전트 사이의 지시를 해당 문장에 연결한다. 사용자가 댓글에서 에이전트를 언급하면 에이전트가 댓글 대화를 읽고 질문이 나온 위치에 답할 수 있다. 하나의 긴 답변 대신 관련 문단마다 별도 댓글을 남기는 방식도 가능하다. 댓글에는 문서의 수치로 만든 차트나 일정표, 흐름도 같은 시각 자료를 실시간 결과물로 담을 수도 있다. 다만 댓글을 이용하는 방식은 사이드바에 입력하는 것보다 클릭이 늘어나는 등 추가적인 마찰을 만든다.

댓글과 공유 대화는 작성 주체와 위치를 드러내며, 사람들이 이미 익숙하게 쓰는 방식이라는 장점이 있다. 글은 Claude Tags 같은 조직용 워크플로 도구의 등장을 이런 흐름과 연결한다. 남은 과제는 서로 다른 화면에서도 같은 에이전트 실행 체계와 버전 관리 시스템을 사용해 동일한 수준으로 기능을 지원하는 일이다.

여러 에이전트 사이의 소통

에이전트 간 협업 방식으로는 상위 조정자가 일을 나눠 전문가 에이전트가 수행하고 마지막에 결과를 확인하는 하향식 방식, 그리고 작업 중 발견 사항이나 수정, 변경된 지시를 서로 전달하는 방식이 제시된다. 전달 메시지는 순서와 기록이 남아야 한다. 받는 에이전트는 메시지가 다른 세션에서 왔음을 알아야 하며, 동료 에이전트가 사용자 대신 권한 요청을 승인해서도 안 된다. Anthropic의 문서도 이 제한을 설명한다.

사람이 읽어야 할 것은 에이전트끼리 주고받은 대화 전체가 아니라 공유된 결과물이라는 것이 글의 주장이다. 자유로운 에이전트 간 대화는 정보가 새거나 맥락이 흐려질 수 있고, 원시 도구 호출 기록을 읽는 것만큼 지루해질 수 있다. 대신 섹션별 제안과 의견이 엇갈린 문단, 각 변경에 대한 이유를 한눈에 볼 수 있는 작업 기록을 보여줄 수 있다. 충돌은 사용자에게 선택지를 제시해 해결하거나, 사용자가 선호를 밝히지 않으면 에이전트가 해결안을 선택하는 방법도 거론한다.

에이전트 네트워크는 대부분 주의를 분산시키므로, 작업 그래프 등을 사용해 에이전트 사이의 마찰을 줄여야 한다는 견해도 소개한다. 여러 에이전트가 병렬로 읽고 정보를 보태되 쓰기는 한 번에 하나씩 수행하는 방식이 유용하다는 설명이다. Anthropic은 대부분의 작업에 팀원 세 명에서 다섯 명을 권하고, 두 팀원이 같은 파일을 편집하면 덮어쓰기가 생긴다고 경고한다. 관련 문서와 다중 에이전트 작업에 대한 논의를 함께 언급하며, 문서 작업에서도 읽기는 병렬로 할 수 있지만 쓰기는 동기화해야 한다는 결론을 제시한다. 문서 작업에 관한 앞선 글도 참조한다.

지식 그래프는 독자보다 에이전트에 더 유용할 수 있다

글은 3차원 지식 그래프를 문서를 읽는 인터페이스로는 가장 유용하지 않았다고 평가한다. 에이전트의 추론을 모두 그래프에 표시하면 짧은 보고서도 100개가 넘는 노드로 불어날 수 있다. 깊이 표현은 노드와 라벨이 서로 가리는 문제를 만들고, 힘 기반 배치에서 노드가 놓인 위치에는 의미가 없어 사용자가 구조를 익히기도 어렵다. 의미상 가까운 노드의 묶음이 더 중요한 구조를 가릴 수도 있다.

답이 대개 목록이라면 질문에 맞춰 그래프를 재배치해, 관련 항목과 의존 관계, 파급 효과를 왼쪽에서 오른쪽으로 읽게 하는 편이 낫다는 제안이다. 지식 그래프는 에이전트가 작업 데이터를 살피는 데는 유용하지만, 독자에게 그대로 보여주기엔 적합하지 않다는 판단이다. 에이전트는 한 부분을 고치기 전에 어떤 항목이 그 부분에 의존하는지 그래프에서 확인할 수 있다. 반면 사람에게는 질문에 답하는 부분만 의미 있는 위치 관계로 정리하고, 관련 텍스트를 함께 보여주는 것이 필요하다.

제안의 핵심

글은 에이전트가 알고 있는 모든 것을 그리기보다 사람이 확인해야 하는 것을 보여줘야 한다고 주장한다. 작업은 사람들이 이미 의견을 나누는 공유 대화, 텍스트에 고정된 댓글, 검토 화면에 놓고, 워크플로와 지식 기반은 지속적으로 남겨 나중에 참조할 수 있어야 한다. 재현성이 더 필요한 작업에는 명세에 맞춘 결정적 프로그램과 회귀 테스트를 활용하는 방안도 제시한다.

“안내와 실행을 분리하세요. ‘이걸 하는 법을 알려주는’ 안내 에이전트가 아니라 ‘안내하는 에이전트’를요.”

“에이전트의 실수를 고치려고 메시지를 더 보내는 건 번거롭다. 변경 내용 추적이라면 한 번의 클릭으로 거부할 수 있다.”

“우리도 종이에 표시할 수 있다. 무언가를 가리키거나 형광펜으로 강조할 수 있다. LLM에도 이런 능력을 주면 안 될 이유가 있을까?”

참고 자료