에이전트는 작업 과정을 문서 안에서 보여줘야 한다

에이전트 커서 세 개를 동시에 문서에 띄우면 각자의 표시만으로는 괜찮아도 서로 같은 화면을 놓고 경쟁한다. 여러 에이전트의 작업을 실시간으로 보여주는 방식은 사용자가 진행 상황을 파악하게 하지만, 한꺼번에 보이는 정보가 너무 많아질 수도 있다.

이 글은 에이전트의 작업 과정을 사용자가 문서 안에서 확인하고 조정할 수 있는 인터페이스를 제안한다. 명령줄이나 사이드바에 대화와 도구 호출을 기록하는 대신, 에이전트가 문서에서 편집하고 댓글을 주고받으며 결과를 공유하는 방식이다. 글의 주장은 에이전트의 작업을 더 잘 이해하고 조정하려는 사람에게 시각적 인터페이스가 유용할 수 있지만, 작업을 보여주는 데서 그치지 않고 적절한 마찰과 검토 절차를 설계해야 한다는 것이다.

에이전트의 작업을 왜 문서 안에서 봐야 하나

명령줄이나 사이드바는 대체로 사용자가 쓰고 에이전트가 답하며, 도구 호출이 쌓이는 기록이다. 에이전트는 보이지 않는 곳에서 작업하고 사람은 나중에 결과를 검토한다. 왕복이 거듭될수록 에이전트가 한 일과 사용자가 이해한 일 사이의 간격이 커진다. 작업이 길어지면 그 간격이 한계가 된다. 사용자는 결과를 믿거나 작업 과정을 되짚어야 한다.

대안은 에이전트가 사용자의 문서 옆에서 함께 작업하는 시각적 방식이다. 작업 중에도 방향을 조정할 수 있다. 작업을 감추면 더 많은 일을 처리할 수 있는 반면, 작업을 보여주면 사용자가 진행 상황을 파악하고 과정에서 배울 수 있다. 목표는 사용자의 의도와 작업량 사이에서 알맞은 균형을 이루는 ‘적정한 마찰’이다. 너무 많은 확인 절차는 작업을 방해하지만, 마찰이 전혀 없으면 사용자가 개입하고 조정하기 어렵다.

문서에서 일하는 타이핑 에이전트는 동료처럼 동작한다. 커서와 이름이 있고, 작업할 문단으로 이동하며, 편집 내용은 변경 내용 추적 표시로 나타난다. 다른 사람이 맡거나 잠근 구역은 건드리지 않는다. 사이드바에서는 에이전트의 작업이 나중에 읽는 보고서지만, 문서 안에서는 해당 위치에 작업 결과가 나타난다. 사용자는 이를 보며 더 직관적으로 개입하거나 지시를 수정할 수 있다.

사용자가 승인하는 변경 사항 비교표도 이런 방식에 들어맞는다. 사용자는 변경을 받아들이거나 거부할 수 있고, 각 결정은 버전 관리에 기록된다. 나중에 그 기록을 에이전트에 다시 제공하면 사용자가 원하는 방향에 더 가깝게 작업하도록 할 수 있다. 이 접근법에 관해 Cursor가 쓴 글이 있다.[[1]](https://lexifina.com/blog/agent-guis#ref-1)

문서에서 작업하면 위치를 더 정확히 지정할 수 있다. 최근 해커뉴스(HN)에 올라온 big-arrow-on-the-screen은 코딩 에이전트가 화면에 큰 화살표나 상자, 글줄을 그리게 한다.[[2]](https://lexifina.com/blog/agent-guis#ref-2) 이런 시각적 안내로 사용자가 소프트웨어를 다루는 방법을 보여줄 수 있다. 여러 에이전트의 협업이 사람의 공동 작업 방식을 참고하듯, 사람은 표시를 그어 특정 부분을 가리킬 수 있다. 에이전트에도 같은 능력을 주지 못할 이유가 없다는 제안이다.

글쓴이 측은 커서 세 개를 동시에 띄우는 방식도 실험했다. 대부분의 사용자가 실시간으로 확인하기에는 정보가 너무 많았다. 에이전트의 작업을 영상 같은 결과물로 다시 볼 수 있게 하고, 커서 움직임을 하나씩 따로 확인할 수 있게 하며, 버전 관리로 되돌릴 수 있게 하면 문제를 대부분 해결할 수 있다는 구상이다. 요약은 사용자가 행동으로 옮길 수 있을 때 읽기 쉬워진다는 설명이다.

커서는 사용자가 선택해 켜는 사이드바 보조 기능으로 제공할 수도 있다. 에이전트는 기존처럼 프롬프트와 도구 호출을 거쳐 작업을 마치고, 사용자가 원하면 따라갈 수 있도록 커서만 표시한다. 에이전트 작동 방식을 바꾸기보다 사용자가 주의를 기울이고 의견을 보내는 위치를 옮기는 방식이다.

여러 사람이 함께 일하려면 무엇을 공유해야 하나

실제 업무 대부분은 여럿이 함께하지만, 에이전트 대화는 대개 한 사람에게만 보인다. 글은 다수가 같은 코드베이스를 편집하되 대화는 각자 비공개로 유지하는 것이 효과적인 협업인지 묻고, 이를 몇 가지 요소로 나눈다.

조직은 기존처럼 문서를 회사 전체와 공유한다. 구성원에게 편집자나 보기 전용 권한을 주는 식의 역할 기반 접근 제어(RBAC)를 적용할 수 있다. 프로젝트에서는 문서와 사실, 결정 사항을 프로젝트에 모으고, 사람과 에이전트가 같은 자료를 읽는다. 사람이 관련 정보를 항상 기록에 남긴다고 기대할 수 없다면, 검색할 수 있는 에이전트 대화도 작업 결과물로 취급한다.

실시간 협업에서는 동료가 문서 안에 있는 것을 서로 볼 수 있다. 각자 맡은 구역을 지정하고, 인공지능이 그 부분을 수정하지 못하도록 잠글 수 있다. 초안이 만들어진 과정을 재생해 모든 사람과 에이전트의 편집을 발생한 순서대로 확인할 수도 있다.

텍스트에 고정되는 댓글은 양방향으로 위치를 지정하는 문제를 해결한다. 댓글은 관련 문구에 붙어 있으므로 사용자가 ‘이 부분’을 물으면 에이전트도 무엇을 가리키는지 알 수 있다. 댓글에서 에이전트를 호출하면 에이전트가 대화 내용을 읽고 질문이 나온 자리에 답을 달 수 있다. 한 번에 긴 답변을 쓰는 대신, 관련 문단마다 별도의 댓글을 여러 개 남길 수도 있다. 에이전트가 읽을 수 있도록 화면에 댓글을 남기는 방식은 사이드바에 입력하는 것보다 자연스럽게 느껴질 수 있다. 다만 클릭이 늘어나는 등 추가적인 마찰도 생긴다.

댓글에는 그래프나 연대표, 흐름도도 넣을 수 있다. 문서에서 이미 논의가 이뤄지는 자리에 에이전트도 참여하도록 하는 확장이다. 시각 자료는 이미지로 붙여 넣는 대신 문서 자체의 수치에서 생성해 갱신되는 결과물로 만들 수 있다.

댓글과 공유 대화는 작성자와 위치를 파악하는 문제를 해결한다. 사람들이 이미 사용법을 알고 있다는 장점도 있다. 글은 Claude Tags 같은 조직 업무 도구가 등장한 것도 이런 흐름과 관련이 있다고 본다. 남은 문제는 다양한 화면 표현이 같은 에이전트 실행 환경과 버전 관리 시스템을 사용하도록 해 모든 표현이 같은 수준의 지원을 받게 하는 것이다.

에이전트끼리 주고받을 내용은 무엇인가

글은 에이전트 간 소통 방식으로 두 가지를 제시한다. 하향식 방식에서는 조정자가 일을 나누고 전문 에이전트들이 작업한 뒤, 마지막에 한 번 검토한다. 전달 방식에서는 에이전트가 작업 중 발견한 사실이나 수정 사항, 바뀐 지시를 서로 보낸다. 이 메시지는 지속해서 보관되고 순서가 기록돼야 한다. 메시지를 받는 에이전트는 다른 세션에서 온 것임을 알아야 하며, 팀원이 사용자 대신 권한 요청을 승인할 수는 없어야 한다.[[3]](https://lexifina.com/blog/agent-guis#ref-3)

사람이 읽을 것은 에이전트끼리 주고받은 대화가 아니라 함께 만든 기록이다. 에이전트 간 자유로운 대화는 정보가 새거나 논의가 어긋날 수 있고, 원시 도구 호출을 읽는 것만큼 지루할 수 있다. 대신 구역별 제안이 정리된 작업판을 보여주고, 의미 차이 때문에 에이전트 둘이 동의하지 않는 문단에는 ‘의견 충돌’ 표시를 붙일 수 있다. 충돌은 자동으로 해결할 수도 있다. 코딩 에이전트 실행 환경에서 흔히 쓰는 방식은 쟁점을 보여주고 사용자에게 A·B·C 중 무엇을 선호하는지 묻는 것이다. 사용자가 선호를 설명하지 않으면 에이전트가 해결안을 선택한다. 여기에도 사용자가 선택해 개입하는 마찰이 들어간다.

에이전트가 서로 연결돼 상호작용하는 네트워크는 “대체로 주의를 분산시킨다”는 것이 글의 평가다. 그래서 방향성 비순환 그래프(DAG) 등으로 에이전트끼리 부딪칠 가능성을 줄이는 방식으로 작업을 구성한다. 여러 에이전트가 읽기 작업을 병렬로 처리하되, 쓰기는 한 번에 하나씩 하는 방식은 유용할 수 있다.[[4]](https://lexifina.com/blog/agent-guis#ref-4)

앤스로픽은 대부분의 작업에 팀원 세 명에서 다섯 명을 권하고, 팀원 둘이 같은 파일을 편집하면 서로의 작업을 덮어쓸 수 있다고 경고한다.[[3]](https://lexifina.com/blog/agent-guis#ref-3) 글쓴이 측도 6월에 문서 작업에서 같은 결론에 도달했다. 읽기는 병렬로 할 수 있지만 쓰기는 동기식으로 해야 한다는 것이다.[[5]](https://lexifina.com/blog/agent-guis#ref-5)

지식 그래프는 누구에게 유용한 화면인가

데이터를 3차원으로 시각화하는 것은 매력적으로 보일 수 있고, 의미 벡터도 개념적으로 흥미롭다. 그러나 글쓴이 측이 만든 문서 읽기 인터페이스 가운데 지식 그래프는 가장 쓸모가 적었다고 평가한다. 이유는 네 가지다.

첫째, 모든 것을 한꺼번에 보여주면 답을 주지 못한다. 에이전트의 추론은 복잡해 경로 하나로 보기 어렵다. 짧은 보고서도 노드가 100개를 넘을 수 있다. 예시 화면에서는 3차원 그래프 속 답을 보여주지만, 가장 읽기 쉬운 부분은 그래프 옆의 목록이다.

둘째, 깊이가 주는 이점보다 비용이 크다. 3차원은 공간을 늘리는 대신 노드가 다른 노드를 가리고 글자끼리 부딪치게 한다. 힘 기반 배치에서 노드가 놓인 위치에는 의미가 없으므로 사용자는 항목이 어디 있는지 익힐 수 없다. 의미상 비슷한 항목끼리 묶으면 더 중요한 구조가 가려지기도 한다.

셋째, 답은 보통 목록 형태다. 더 나은 그래프는 질문에 맞춰 배열을 바꾼다. 답을 열로 나누면 왼쪽에서 오른쪽으로 결과의 연결 관계를 읽을 수 있다. 예시에서는 같은 답을 질문에 맞게 재배치한다. 위치가 의미를 갖게 돼 무엇이 질문에 부합하는지, 무엇에 의존하는지, 무엇으로 이어지는지 알 수 있다.

지식 그래프는 에이전트가 작업할 때 쓰는 데이터로는 훌륭하지만, 사람이 읽는 화면으로는 적합하지 않다는 것이 글의 결론이다. 에이전트는 문서를 바꾸기 전에 특정 구역에 의존하는 내용이 무엇인지 그래프의 연결을 이용해 확인할 수 있다. 사람에게는 질문에 답하는 그래프의 일부만 보여줘야 한다. 그 정보는 위치가 의미를 갖도록 배치하고, 관련 텍스트도 바로 아래에 제공해야 한다. 글은 이를 오컴의 면도날에 빗댄다.

결론은 무엇인가

글에 실린 익명 이용자들의 의견은 시각적 안내가 작업을 대신하는 에이전트뿐 아니라 사용법을 가르치는 에이전트에도 도움이 될 수 있다는 것이다. 한 이용자는 이런 접근이 데스크톱 컴퓨터를 처음 쓰는 사람을 돕는 데 유용할 것이라고 했고, 다른 이용자는 몇 년 전 블렌더에서 메시의 모든 정점 법선을 표시하는 방법을 배우던 때 필요했을 것이라고 말했다. 또 다른 이용자는 종이에서 하듯 무언가를 가리키거나 표시하는 능력을 대규모 언어 모델에도 줄 수 있지 않겠느냐고 물었다. 에이전트가 저지른 실수를 메시지를 더 보내서 되돌리는 것보다 변경 사항 추적에서 한 번 클릭해 거부하는 편이 간단하다는 의견도 있었다.

글의 제안은 에이전트가 아는 모든 것을 그리기보다 사람이 확인해야 할 것을 보여주라는 것이다. 지식 그래프는 에이전트의 데이터다. 사용자는 질문에 답하는 부분을 이해하기 쉬운 위치에 배치하고, 근거가 된 문장도 한 번의 클릭으로 확인할 수 있어야 한다.

에이전트의 작업은 사람들이 이미 대화하는 곳에 놓을 수 있다. 공유 대화와 텍스트에 고정되는 댓글, 변경 사항 검토가 그 예다. 글은 ‘워크플로’라는 말이 어색하더라도 작업 과정은 지속적으로 보관하고 참조할 수 있어야 한다고 주장한다. 암묵적인 사례로는 언어적 설명을 담은 마크다운 파일의 연속을 든다. 언어가 대규모 언어 모델이 다루는 궁극적인 교환 수단이라는 설명이다. 작업을 더 재현 가능하게 하려면 명세에 맞게 수정한 결정적 프로그램을 사용하고 회귀 검사 관문으로 시험하는 방법도 제시한다.

시각적 에이전트 인터페이스를 검토한다면 작업 표시가 사용자의 확인과 조정을 돕는지, 여러 에이전트의 동시 작업이 화면을 복잡하게 만들지, 편집을 검토하고 되돌릴 수 있는지 살펴볼 만하다. 원문은 제안한 인터페이스의 독립적인 검증 결과나 실제 사용 환경에서의 성능, 구현·이용 조건은 밝히지 않는다.