채팅창, 정말 이대로 괜찮을까요?
요즘 AI 에이전트 이야기가 정말 많죠. 코드를 대신 짜주고, 웹을 돌아다니며 조사를 해주고, 여러 작업을 동시에 처리해주는 에이전트들이 쏟아져 나오고 있는데요. 그런데 재미있는 건, 이 모든 에이전트를 다루는 인터페이스가 거의 다 똑같다는 거예요. 바로 채팅창이요. ChatGPT가 성공한 이후로 "AI = 채팅창"이라는 공식이 굳어져 버렸거든요.
그런데 최근 MarbleOS라는 데모가 이 공식에 정면으로 질문을 던졌어요. "AI 에이전트를 위한 GUI는 어떤 모습이어야 할까?"라는 질문인데요. 이름에서 짐작할 수 있듯, 에이전트를 다루는 경험을 채팅이 아니라 하나의 운영체제(OS)처럼 만들어보면 어떨까 하는 실험이에요.
채팅 인터페이스의 한계, 뭐가 문제냐면요
채팅은 기본적으로 '선형'이에요. 위에서 아래로, 한 줄씩 대화가 쌓이는 구조죠. 질문 하나 하고 답 하나 받는 용도로는 완벽한데, 에이전트 시대에는 상황이 달라져요. 에이전트는 한 번 지시를 받으면 몇 분, 길게는 몇 시간씩 혼자 일하거든요. 그것도 여러 개가 동시에요.
이런 상황에서 채팅창으로는 답하기 어려운 질문들이 생겨요. "지금 에이전트가 뭘 하고 있지?" "세 개를 동시에 돌렸는데 각각 어디까지 진행됐지?" "이 녀석이 파일을 지우려고 하는데 승인해줘야 하나?" 같은 것들이요. 긴 텍스트 로그를 스크롤하면서 이걸 파악하는 건 고문에 가깝죠. 마치 여러 프로그램을 띄워놓고 쓰는데 창 없이 터미널 로그 하나로만 모든 걸 확인해야 하는 상황이랑 비슷해요.
그래서 어떤 요소들이 필요할까요
에이전트 GUI 논의에서 공통적으로 나오는 요소들이 있어요. 첫째는 상태 가시성이에요. 에이전트가 지금 뭘 하고 있는지, 어떤 도구를 쓰고 있는지 한눈에 보여야 해요. 둘째는 개입 지점이에요. 위험한 작업 전에 사람의 승인을 받거나, 잘못된 방향으로 가면 중간에 멈추고 방향을 수정할 수 있어야 하죠. 셋째는 병렬 작업 관리예요. 에이전트 여러 개를 마치 OS의 프로세스처럼 띄워놓고, 창을 전환하듯 오가며 관리하는 개념이요. 마지막으로 결과물 중심 뷰도 중요해요. 대화 기록이 아니라 에이전트가 만들어낸 문서, 코드, 화면 자체가 인터페이스의 중심이 되는 거죠.
업계도 같은 고민을 하고 있어요
사실 이 고민은 업계 전반에서 진행 중이에요. Anthropic의 Claude는 Artifacts로 대화와 결과물을 분리했고, 코딩 에이전트들은 아예 터미널과 IDE 속으로 들어갔어요. Devin 같은 제품은 에이전트가 쓰는 브라우저, 터미널, 에디터를 나란히 보여주는 워크스페이스 뷰를 선보였고요. Vercel의 AI SDK가 밀고 있는 '생성형 UI(Generative UI)'는 AI가 텍스트 답변 대신 버튼, 폼, 차트 같은 UI 컴포넌트 자체를 생성하는 접근이에요. 다들 "채팅 다음"을 찾고 있는 거죠.
역사를 돌아보면 이런 순간이 몇 번 있었어요. 명령줄(CLI)에서 그래픽 인터페이스(GUI)로 넘어갈 때 제록스 파크와 매킨토시가 '데스크톱 은유'를 만들었고, 스마트폰이 나올 때 터치 제스처라는 새 문법이 생겼잖아요. 에이전트 시대의 데스크톱 은유는 아직 없어요. 그 자리를 누가 차지할지가 지금 완전히 열려 있는 거예요.
한국 개발자에게는 어떤 의미일까요
프론트엔드 개발자에게는 꽤 큰 기회일 수 있어요. 지금까지 AI 제품 경쟁이 모델 성능 싸움이었다면, 모델이 상향평준화된 지금은 "누가 더 좋은 에이전트 경험을 만드느냐"가 차별화 포인트가 되고 있거든요. 에이전트 상태를 시각화하는 컴포넌트, 승인 플로우 UX, 멀티 에이전트 대시보드 같은 건 아직 정답이 없는 영역이라 지금 뛰어들면 선구자가 될 수 있어요. 사내 서비스에 AI 기능을 붙이는 중이라면, 무조건 채팅창부터 만들 게 아니라 "우리 사용자에게 정말 필요한 인터페이스가 뭘까"를 먼저 고민해보는 게 좋겠죠.
한줄 정리: AI 에이전트 시대의 인터페이스는 아직 미개척지이고, 채팅창은 정답이 아닐 수 있다. 여러분은 에이전트를 쓸 때 어떤 순간이 가장 답답하셨나요? 채팅 다음의 인터페이스, 어떤 모습이어야 한다고 생각하세요?
🔗 출처: Hacker News