깃허브 코파일럿 앱, 채팅 한계 넘는 양방향 맞춤형 풀스택 UI '캔버스' 제시

2026년 9월 24일, 깃허브에서 AI 기반 개발 기술을 담당하는 버크 홀랜드(Burke Holland)는 깃허브 코파일럿 앱(GitHub Copilot app) 내에서 작동하는 맞춤형 인터페이스 개념인 '캔버스(canvas)'를 공개하며, 기존 채팅 중심의 AI 사용자 인터페이스(UI)를 대체할 새로운 접근 방식을 제시했다. 캔버스는 코파일럿 앱 내부에서 브라우저 크롬(창 틀 및 제어 요소) 없이 구동되는 일종의 소형 풀스택 애플리케이션이다. 사용자는 자연어 지시를 통해 필요한 도구나 인터페이스를 즉석에서 생성할 수 있으며, 이 작업 표면은 일반 소프트웨어 프로그램처럼 독립적으로 동작하는 동시에 깃허브 코파일럿 에이전트와 실시간으로 양방향 통신(bi-directional communication)을 수행할 수 있도록 설계되었다.

이번 제안의 배경에는 대규모 언어 모델(LLM)이 본격적으로 보급된 지 3년이 지났음에도 여전히 주된 상호작용 방식이 텍스트 입력창(textarea) 기반의 채팅에 머물러 있다는 문제의식이 자리 잡고 있다. 채팅 인터페이스는 사용자가 AI로 무엇을 수행할지 알 수 없는 초기 단계에서는 유연한 범용 솔루션으로 기능했지만, 사용자가 해결하려는 과업의 목표가 명확해질수록 비효율적인 도구가 된다. 학자 스티븐 핑커(Steven Pinker)는 대규모 AI 구현의 첫 형태가 1인칭 챗봇이라는 일종의 눈속임에 그쳤던 점은 아쉽지만, AI가 과업 지향적(task-oriented)으로 발전할 때 막대한 잠재력을 발휘할 수 있다고 지적한 바 있다. 즉, 목적이 분명한 작업에서는 단일 텍스트 상자 대신 상황에 맞춘 인터페이스를 제공하는 것이 필수적이라는 분석이다.

기술적 관점에서 캔버스는 단순한 정적 웹페이지가 아니라 서버 로직을 포함하는 풀스택 애플리케이션 구조를 갖춘다. 코파일럿 앱 내부에서 실행되는 캔버스의 서버 파트는 코파일럿 에이전트와 직접 데이터를 주고받을 수 있으며, 외부 서드파티 API(third-party API)를 호출하는 것은 물론 사용자의 로컬 머신에서 직접 코드를 실행(execute code locally)할 수 있는 실행 권한을 가진다. 캔버스를 구축하는 과정 또한 에이전트와의 대화를 통해 단순화되어 있다. 코파일럿 앱 자체에 캔버스 개념이 내장되어 있으므로, 사용자가 캔버스의 목적과 상호작용 방식을 프롬프트로 지정하면 에이전트가 요구사항에 맞는 풀스택 구조를 스스로 구성해 화면에 띄운다.

원문 분석에 따르면 캔버스는 인터랙티브 엔터테인먼트부터 시스템 유틸리티까지 다양하게 활용된다. 프롬프트 요청을 통해 에이전트와 사용자가 대결하는 '커넥트 4(Connect 4)' 게임 캔버스를 즉시 구성해 GPT-5.6 Sol(고추론 모델) 및 GPT-5.6 Luna(비추론 모델)와 상호작용할 수 있다. 나아가 윈도우 패키지 관리자인 윙젯(Winget) 전용 UI 캔버스를 구축해 레지스트리 검색과 로컬 패키지 설치·제거를 직접 제어하는 사례도 제시되었다. 윙젯 UI처럼 인터페이스가 완성된 후에는 상호작용 과정에 AI가 전혀 개입하지 않는다. 이는 매번 에이전트에게 깃(Git) 스테이징이나 커밋 같은 단순 명령을 내려 토큰을 소모하는 대신, 에이전트로 하여금 한 번 도구를 만들게 하고 이후 작업은 토큰 비용 없이 수행하도록 만들어 토큰 낭비를 원천적으로 차단한다. 또한 SQLite 데이터베이스 전용 캔버스를 띄워 인텔리센스(IntelliSense)를 활용한 직접 쿼리 작성을 지원하거나, 지킬(Jekyll) 블로그 작성을 위해 과거 윈도우 라이브 라이터(Windows Live Writer) 스타일의 편집 UI를 복원하는 등 독립적인 생산성 도구로도 활용 가능하다.

캔버스의 가치는 복잡한 소프트웨어 개발 워크플로를 자동화할 때 더욱 극대화된다. 일반적인 개발 과정은 조사(Research), 프로토타입 제작(Prototype), 계획(Plan), 구현(Implement), 반복 개선(Iterate), 최종 마무리(Finalize)의 6단계 순서로 진행되는데, 기존 채팅 환경에서는 개발자가 모든 단계마다 화면 앞에 머물며 지시와 검토를 수동으로 반복해야 했다. 그러나 캔버스를 활용하면 에이전트가 자체적으로 조사와 프로토타입 생성을 진행하고, 사용자의 검토가 필요한 시점에만 알림을 보내도록 설계할 수 있다. 이를 통해 개발자는 필요에 따라 작업 루프(loop)에서 벗어나 비동기적으로 작업을 위임받을 수 있으며, 에이전트와 개발자 간의 불필요한 대기 시간을 줄이고 개발 흐름 전반을 시스템화할 수 있다.

원문이 검토한 바에 따르면 캔버스를 도입할 때 모든 도구의 제작 난이도가 동일한 것은 아니며 뚜렷한 공수 차이가 존재한다. 단일 데이터베이스를 조회하는 SQLite 캔버스와 같은 비교적 단순한 유틸리티는 단 한 번의 프롬프트 요청(one-shot)으로 즉시 생성할 수 있다. 반면 다단계 프로세스와 정교한 규칙이 결합된 개발 워크플로 자동화 캔버스의 경우, 시각적 디자인과 자동화 파이프라인을 완벽히 정립하기까지 하루의 대부분에 달하는 시간(the better part of a day)이 소요되었다. 또한 캔버스 워크플로는 모든 작업 환경에 일률적으로 적용되는 만능 표준이 아니며, 각 프로젝트와 개인의 작업 방식에 맞게 설계와 최적화를 거쳐야 한다는 점이 현실적 한계이자 적용 조건으로 지적되었다.