Brainless, 에이전트 UI를 컴포넌트화하다

터미널 에이전트 UI가 디자인 시스템으로 온다

Brainless는 Claude Code, Codex, Grok 스타일의 에이전트 인터페이스를 shadcn/ui 방식 컴포넌트로 제공하는 작은 프로젝트다. 사이트는 헤더, 메시지 턴, 사고 표시, 도구 호출, 인라인 diff, 권한 프롬프트, slash command 메뉴, composer 같은 패턴을 terminal-like UI로 보여준다. 표면적으로는 재미있는 모사처럼 보이지만, 실제 신호는 더 크다. 에이전트 제품의 UI 문법이 반복 가능한 구성요소로 굳어지고 있다는 뜻이다.

AI 제품은 그동안 채팅창을 기본 UI로 삼았다. 그러나 코딩 에이전트와 업무 에이전트는 단순 대화보다 많은 상태를 보여줘야 한다. 무엇을 읽었는지, 어떤 명령을 실행하려는지, 권한이 필요한지, 파일이 어떻게 바뀌었는지, 중단과 재개가 가능한지 사용자가 계속 판단해야 한다. Brainless가 흉내 내는 인터페이스들은 바로 이 상태 표시의 집합이다.

GitHub 저장소와 사이트의 문구를 보면 목표는 단순한 ASCII 장식이 아니라, 실제 HTML 컴포넌트와 접근성 의미를 유지하는 것이다. ARIA live region, listbox, radiogroup 같은 의미가 들어간다면 사용자는 스크린리더와 키보드로 에이전트 상태를 더 잘 다룰 수 있다. WAI-ARIA Authoring Practices Guide가 강조하는 상호작용 의미론이 에이전트 UI에서도 중요해진다.

왜 shadcn 방식인가

shadcn의 장점은 패키지로 숨은 컴포넌트를 쓰는 것이 아니라, 소스 코드를 프로젝트 안으로 가져와 수정한다는 데 있다. 에이전트 UI는 제품마다 권한 모델, 로그 보존 정책, diff 표현, 도구 이름이 다르다. 따라서 완전한 블랙박스 UI 키트보다 가져와서 고치는 registry 방식이 잘 맞는다. Brainless가 shadcn registry를 택한 것은 에이전트 UI가 팀별로 변형될 수밖에 없다는 현실과 맞닿아 있다.

Claude Code, OpenAI Codex, xAI Grok 계열 도구가 경쟁하면서 사용자들은 이미 특정 UI 관습에 익숙해졌다. 진행 중 사고 표시, 승인 요청, 터미널 로그, 파일 diff, 세션 요약은 이제 코딩 에이전트의 기본 어휘다. Brainless는 이 어휘를 서비스 개발자가 복사해 제품 안으로 넣을 수 있게 만든다.

국내 제품팀이 배울 점

한국 SaaS와 내부 업무 도구에서도 에이전트 UI가 늘고 있다. 문제는 많은 팀이 채팅창 위에 로그를 얹는 수준에서 멈춘다는 것이다. 그러나 업무 에이전트는 사용자가 반복적으로 검토하고 승인해야 하는 운영 도구다. OfficeCLI 문서 에이전트나 GPT-Live 음성 에이전트 인터페이스가 보여주듯, 인터페이스는 모델 성능 못지않게 신뢰를 좌우한다.

Brainless가 주는 교훈은 "예쁜 터미널"이 아니라 정보 구조다. 에이전트가 계획, 실행, 관찰, 수정, 완료를 오가면 UI도 그 상태를 분리해야 한다. 실패했을 때 사용자가 어디서 되돌릴 수 있는지, 어떤 도구 호출이 외부 시스템에 영향을 줬는지, 어떤 파일 변경이 아직 적용 전인지 명확해야 한다. Codex 토큰 클러스터링처럼 에이전트 신뢰를 계량하려는 시도도 결국 UI에 드러나야 사용자가 행동할 수 있다.

접근성과 감사 가능성이 경쟁력이다

AI 에이전트 UI는 멋진 애니메이션보다 감사 가능성이 먼저다. 사용자가 나중에 "왜 이 변경이 들어갔는가"를 물었을 때 세션 로그, 권한 응답, diff, 실행 결과가 연결되어야 한다. 또한 키보드 조작과 스크린리더 지원을 포기하면 내부 도구라 해도 접근성 리스크가 쌓인다. shadcn/ui GitHub가 오픈 코드와 컴포넌트 배포 플랫폼을 내세우는 것도 이런 커스터마이즈 요구와 맞는다.

개발팀은 Brainless를 그대로 쓰지 않더라도 패턴을 가져올 수 있다. 승인 버튼은 위험도별로 나누고, 장기 실행 작업은 중단과 재개 상태를 표시하며, 도구 호출은 성공과 실패 원인을 같은 형식으로 남긴다. 파일 diff는 요약과 전체 보기를 분리하고, 모델의 계획과 실제 실행 로그를 섞지 않는다. Fable 안전분류기 연구 생산성이 보여준 것처럼 안전장치가 연구와 개발 속도를 막지 않으려면 UI가 정확해야 한다.

자주 묻는 질문

Q1: Brainless는 완성된 앱인가요?

A: 아니다. Claude Code, Codex, Grok형 인터페이스를 재사용 가능한 shadcn 컴포넌트와 블록으로 제공하는 프로젝트에 가깝다.

Q2: 왜 에이전트 UI에 접근성이 중요한가요?

A: 권한 승인, 도구 호출, diff 확인은 중요한 작업이다. 키보드와 스크린리더에서 의미가 깨지면 사용자가 위험한 결정을 놓칠 수 있다.

Q3: 한국 SaaS가 바로 쓸 수 있나요?

A: 일부 패턴은 바로 참고할 수 있다. 다만 권한 모델, 감사 로그, 데이터 보존 정책은 각 제품의 보안 요구에 맞게 바꿔야 한다.

Q4: 채팅 UI와 무엇이 다른가요?

A: 채팅 UI는 발화 중심이고, 에이전트 UI는 실행 상태 중심이다. 읽기, 쓰기, 명령 실행, 승인, 롤백 같은 상태가 핵심이다.

Q5: 디자인 시스템 팀의 역할은 무엇인가요?

A: 에이전트 상태를 공통 컴포넌트로 정의해야 한다. 그래야 제품마다 승인 UX와 로그 표현이 달라져 생기는 신뢰 문제를 줄일 수 있다.