화이트보드는 개발 실무에서 여전히 가장 빠른 사고 도구다. 아키텍처를 스케치하고, 데이터 흐름을 화살표로 잇고, 붙임쪽지로 메모를 남기는 작업은 코드보다 앞서는 경우가 많다. 그런데 이 다이어그램을 실제로 그리고 고치는 일은 손이 많이 간다. 드로겐트(Drawgent)는 이 지점을 노린 오픈소스 프로젝트로, 사용자가 이미 쓰고 있는 코딩 에이전트를 Excalidraw 기반 화이트보드에 연결해 그림 자체를 에이전트가 편집하게 만든다.
무엇을 하는 도구인가
핵심 아이디어는 단순하다. Claude Code, Codex, opencode 가운데 하나를 캔버스에 붙이면, 채팅 패널에 "이런 다이어그램을 그려줘"라고 요청하거나 그림의 특정 부분 옆에 'AGENT: …' 형식으로 지시를 적어둘 수 있다. 그러면 에이전트가 캔버스를 스크린샷과 장면(scene) 데이터로 함께 들여다보고, 요소를 실시간으로 편집한 뒤 결과를 스스로 확인하고, 해당 메모를 DONE으로 표시한다. 사람이 그림 위에 남긴 자연어 지시가 곧 작업 티켓이 되고, 완료 상태까지 캔버스 안에서 관리되는 구조다.
주목할 점은 에이전트를 새로 설치하거나 별도 계정을 만들 필요가 없다는 것이다. 드로겐트는 사용자가 이미 설치하고 로그인해 둔 CLI, 그 설정과 저장소를 그대로 연결한다. 전제 조건도 그만큼 명확하다. claude, codex, opencode 중 하나가 PATH에 있고 로그인되어 있어야 하며, Claude와 Codex 브리지는 Node.js 18 이상(npm)을 요구한다. 캔버스를 그려내는 렌더러는 헤드리스 크롬이 필요한데, 기존에 설치된 Chrome이나 Chromium을 쓰거나 비대화형 옵션으로 다운로드·시스템·직접 경로 지정을 고를 수 있다.
설정이 실패를 앞당기는 방식
실무자 입장에서 반가운 대목은 설정 검증 방식이다. 드로겐트는 CLI 존재 여부, 로그인 상태(claude auth status, codex login status, opencode auth list), 캔버스 도구 연결, 크롬 렌더러까지 한 번에 점검하고, 빠진 것이 있으면 정확히 무엇을 어떻게 고쳐야 하는지 알려주며 멈춘다. 점검 결과는 ~/.config/drawgent/config.toml에 기록되고, 이후 drawgent up은 해당 에이전트의 설정이 성공적으로 끝나지 않았거나 기록해 둔 무언가가 사라졌으면 아예 기동을 거부한다. 애매하게 실행됐다가 나중에 깨지는 대신, 시작 시점에 실패를 드러내는 설계다.
에이전트별로 붙는 방식에는 차이가 있다. Codex만 'codex mcp add drawgent -- drawgent mcp'로 캔버스 도구를 한 번 등록해야 하고, Claude와 opencode는 세션에 붙는 시점(attach)에 도구를 자동으로 받는다. 실행은 현재 디렉터리를 작업 공간으로 삼으며, 장면 데이터는 .drawgent/scene.json에 저장되고 이 파일은 자동으로 git에서 제외된다. id 없이 붙이면 현재 디렉터리를 우선해 발견한 세션 목록을 보여주고 그중 하나를 고르게 한다.
도구 표면과 활용 시나리오
에이전트가 캔버스를 다루는 능력은 MCP 도구 집합으로 정의된다. 장면과 스크린샷을 읽고(get_scene, get_screenshot, element_ids로 확대), 요소를 추가하고(add_elements는 화살표를 id로 결합해 가장자리끼리 자동 연결, add_mermaid는 자동 레이아웃), 라벨과 결합된 화살표가 도형을 따라 재배치되도록 갱신하며(update_elements), 삭제·초기화하고, 지시 목록을 조회·해결하며 상태를 설정한다. 같은 기능이 REST 및 웹소켓 API로도 노출돼 헬스체크, 장면·스크린샷 조회, 요소 조작, mermaid 변환, 채팅, 브라우저 동기화까지 외부에서 다룰 수 있다. 프런트엔드는 에디터 페이지와 렌더러 페이지로 나뉘어 있다.
협업 측면에서는 'docker compose up --build'로 드로겐트와 Chromium만 담은 캔버스 서버를 띄울 수 있어, 공유 캔버스나 방(room) 브리지를 서버에서 호스팅하는 용도로 쓸 수 있다. 여기서 일관되게 강조되는 원칙은 에이전트가 결코 함께 번들되지 않는다는 점이다. 캔버스는 공유하되, 실제 추론과 코드 접근은 언제나 각 사용자의 자체 설정으로 로컬에서 돈다. 팀이 공용 화이트보드를 두더라도 각자의 계정·권한·저장소 경계는 유지되는 셈이다.
실무적 의미와 한계
드로겐트가 흥미로운 이유는 에이전트의 작업 대상을 텍스트 파일에서 시각적 캔버스로 넓히면서도, '자체 설치·자체 로그인'이라는 실무 현실을 존중하기 때문이다. 다이어그램 생성과 수정을 반복하는 설계 단계, 리뷰 중 구조를 함께 그려가며 논의하는 상황에서 손품을 크게 줄일 여지가 있다. 반면 분명한 제약도 있다. 세 가지 CLI 중 하나를 이미 갖춰 로그인해야 하고 헤드리스 크롬 의존성이 붙으므로, 진입 장벽이 아주 낮지는 않다. 또한 시각 편집의 품질은 결국 붙인 에이전트의 시각 이해와 판단에 좌우되며, 공개된 자료만으로는 복잡한 다이어그램에서의 정확도나 성능 특성을 가늠하기 어렵다. 도입을 검토한다면 실제 사용하는 다이어그램 유형으로 소규모 검증을 거친 뒤 팀 워크플로에 편입하는 접근이 안전하다.