출처:
Creating with Rovo: How We Built a Collaborative AI Canvas
작성자:
Alex Knight (Sr. Principal Engineer)
Abhi Kishore
발행일: 2026년 04월 06일
Rovo는 플랫폼의 핵심에 있는 핵심 AI 솔루션입니다.
Teamwork Graph를 통해 Confluence, Jira 및 연결된 앱과 같은 도구 전반에서 내부 및 외부 지식을 검색하고, 필요한 정보를 적절히 찾아 제공합니다.
또한 Jira 이슈부터 Confluence 페이지까지 생태계 전반의 객체를 생성하고 상호작용할 수도 있습니다.
하지만 Rovo에는 아직 완전한 기능을 갖춘 생성 캔버스가 없었습니다:
사람과 AI가 함께 실시간으로 콘텐츠를 공동 생성하고, 반복적으로 개선하며, 정교하게 다듬을 수 있는 협업 공간이 부족했던 것입니다.
이러한 공백이 “Creating content with Rovo”의 출발점이 되었습니다.
Rovo로 창작한다는 핵심 아이디어는 단순합니다:
콘텐츠 생성은 AI와 사용자의 협업이어야 하며, 한쪽이 다른 쪽에 작업을 넘기는 방식이어서는 안 된다는 것입니다.
이 글에서는 Rovo를 활용한 콘텐츠 생성의 내부 과정을 살펴보고, 다음 내용을 다룹니다:
이를 왜 협업형 AI 캔버스로 설계했는지, 그리고 왜 단발성 작성 도구(one-shot writer)가 아닌지를 설명합니다.
페이지, 화이트보드, 데이터베이스 등 다양한 콘텐츠 유형을 안정적으로 처리하는 방법을 다룹니다.
ADF, SVG, CSV 기반 스키마에 대한 기술적 설계 선택을 설명합니다.
Rovo가 풍부한 콘텐츠를 안전하게 생성하고 실시간으로 편집할 수 있도록 하는 스트리밍 인프라 구조를 소개합니다.
핵심 원칙
우리는 단일 제품 안에 고립된 독립형 AI 작성 도구를 만들고자 하지 않았습니다.
Rovo로 콘텐츠를 만드는 기능은 Confluence에서 시작할 수 있지만, 본질적으로 Rovo 위에서 네이티브하게 구축되어 있으며 모든 Rovo 환경에서 접근할 수 있습니다.
콘텐츠 생성은 채팅 경험의 자연스러운 확장처럼 느껴져야 합니다. 사용자는 하나의 대화 안에서 질문하고, 페이지를 공동 작성하고, 화이트보드를 반복적으로 개선하며, 데이터베이스를 정교하게 다듬을 수 있습니다.
이 모든 과정은 동일한 컨텍스트를 이해하는 동일한 AI와 함께 이루어집니다.
그 결과 몇 가지 핵심 설계 원칙이 도출되었습니다:
생성은 채팅 안에서 이루어집니다.
콘텐츠는 Rovo 채팅 내 캔버스에서 시작되며, 원하는 상태가 되면 적절한 공간이나 제품 영역으로 이동할 수 있습니다.
이는 기능이 아니라 플랫폼입니다.
처음부터 이 캔버스는 페이지, 화이트보드, 데이터베이스 등 다양한 콘텐츠 유형을 지원하도록 설계되었으며, 다른 제품으로 확장될 수 있도록 만들어졌습니다.
Jira 작업 항목을 위한 Create with Rovo 기능은 최근 EAP로 출시되었으며 동일한 패턴을 따릅니다.
실시간 스트리밍
사용자는 콘텐츠가 생성되고 편집되는 과정을 실시간으로 확인할 수 있습니다.
이를 통해 협업은 단순한 “생성 후 붙여넣기”가 아니라 살아 있고 반복적으로 발전하는 경험이 됩니다.
기술 구현
상위 수준에서 보면, Rovo의 백엔드는 상위 오케스트레이터(Orchestrator) 에이전트를 중심으로 구성되어 있으며, 이 에이전트는 여러 전문 스킬에 접근할 수 있습니다.
여기에는 크로스 프로덕트 검색(서드파티 제품 포함), Teamwork Graph 검색, Jira 조회 에이전트 등이 포함됩니다.
오케스트레이터는 사용자의 의도에 따라 이러한 스킬들을 호출합니다.
Rovo 기반 콘텐츠 생성을 지원하기 위해, Confluence 전용 생성 및 편집 스킬을 도입했습니다.
이는 다음 역할을 수행하도록 설계된 목적 특화 에이전트입니다:
사용자의 의도를 이해하고,
적절한 콘텐츠 유형과 템플릿을 선택하며,
다운스트림 시스템이 신뢰할 수 있는 구조화된 콘텐츠를 생성합니다.
이 에이전트는 독립적으로 동작하지 않습니다.
Rovo의 전체 컨텍스트를 그대로 상속하며, 여기에는 대화 기록, 연결된 지식 소스, 관련 작업 항목이 포함됩니다.
사용자는 Rovo에게 다음과 같이 요청할 수 있습니다:
“Q3 목표를 기반으로 프로젝트 계획을 생성해줘”
그러면 에이전트는 문서를 생성하기 전에 Teamwork Graph에서 적절한 컨텍스트를 먼저 가져옵니다.
LLM을 활용한 Confluence 콘텐츠 생성
Confluence 콘텐츠 유형은 각각 서로 다른 내부 표현 방식과 제약 조건을 가지고 있습니다:
페이지는 깊은 중첩을 가진 리치 노드 기반 구조를 사용합니다.
화이트보드는 공간 기반 레이아웃과 시각 요소에 의존합니다.
데이터베이스는 스키마와 뷰를 갖춘 테이블 중심 구조입니다.
품질을 극대화하기 위해 우리는 각 콘텐츠 유형에 맞는 적절한 모델과 출력 형식을 찾아야 했습니다.
이를 위해 다양한 LLM과 포맷에 대해 평가를 수행했고, 결국 각 유형에 따라 서로 다른 접근 방식을 적용하게 되었습니다.
이 과정에서는 최신 프론티어 LLM의 역량에 대한 예상치 못한 인사이트도 얻을 수 있었습니다.
페이지 / 라이브 문서
페이지의 경우, 다음과 같은 요구사항이 있었습니다:
패널, 상태, 복잡한 테이블, 매크로 등 다양한 리치 텍스트 요소를 지원하고
편집 과정에서 서식이 손실되지 않도록 합니다
페이지 생성의 경우, LLM이 ADF(중첩 JSON)를 직접 생성하도록 하고, 이를 전용 ADF 복구 라이브러리를 통해 처리합니다.
이 라이브러리는 다음과 같은 역할을 합니다:
일반적인 LLM 출력 문제(유효하지 않거나 스키마를 준수하지 않는 JSON)를 처리하고
에디터에 도달하기 전에 ADF 스키마 준수를 보장합니다
페이지 편집의 경우, LLM이 ADF를 조작할 수 있도록 에디터 스타일의 소규모 명령 집합을 정의했습니다. 예를 들어 다음과 같습니다:
replaceNode (노드 교체)
insertNodeAfter (특정 노드 뒤에 노드 삽입)
removeNode (노드 삭제)
각 도구 호출 내에서 LLM은 ADF를 값으로 생성합니다.
편집은 반성(reflection)을 포함한 에이전틱 루프(agentic loop)로 실행되며, 이는 Atlassian 문서에 특화된 코딩 에이전트와 유사하게 동작합니다.
화이트보드
화이트보드는 공간 기반 레이아웃과 시각적 의미 구조로 인해 또 다른 수준의 복잡성을 가집니다.
다음과 같은 여러 출력 형식을 평가했습니다:
HTML + CSS
WDF (화이트보드 문서 형식 – 내부 JSON 저장 표현 방식)
WDF 위에 구축된 DSL
직접적인 도구 호출
콘텐츠 생성 평가를 위해 대규모 데이터셋을 구축했으며, 사람과 LLM이(출력 스크린샷을 기반으로) 결과를 평가하도록 했습니다.
평가는 시각적 요소, 연결 구조 및 그룹화, 레이아웃 품질을 중심으로 이루어졌습니다.
또한 데이터를 파싱하고 스트리밍할 수 있는 능력도 의사결정에 영향을 주었습니다.
최종적으로 SVG가 가장 우수한 선택으로 결정되었습니다.
LLM은 방대한 데이터로 학습됩니다.
SVG가 사람들이 무한 캔버스 보드를 사고하는 방식(도형, 텍스트, 위치)과 가장 밀접하게 대응되며, LLM이 안정적으로 생성하고 이해할 수 있는 표현 방식이라는 점을 확인했습니다.
화이트보드의 경우, 다음과 같은 요구가 있었습니다:
새로운 보드를 생성할 때 SVG 문서를 생성한 다음,
이를 네이티브 화이트보드 요소로 변환합니다.
이는 거의 SVG를 가져오는(import) 것과 같은 방식입니다.
<svg viewBox="0 0 1200 800" xmlns="http://www.w3.org/2000/svg">
<rect id="background" x="0" y="0" width="1200" height="800" fill="#ffffff"/>
<text id="haiku-title" x="600" y="250" font-size="32" font-weight="bold">
<tspan x="600" dy="0">Haiku</tspan>
</text>
<text id="haiku-text" x="600" y="350" font-size="24" font-style="italic">
<tspan x="600" dy="0">Cherry blossoms fall</tspan>
<tspan x="600" dy="40">Soft petals dance on the breeze</tspan>
<tspan x="600" dy="40">Spring whispers goodbye</tspan>
</text>
<line id="decoration-line" x1="400" y1="520" x2="800" y2="520" stroke="#dfd8fd"/>
<text id="haiku-form" x="600" y="580" text-anchor="middle" font-size="14">
<tspan x="600" dy="0">5 - 7 - 5 syllables</tspan>
</text>
</svg>
LLM이 생성한 청크를 실시간으로 처리하는 과정은 스트리밍 SVG 파서와 제약 조건 해결 알고리즘을 함께 사용해 이루어지며, 요소의 포함 관계를 보장하고 레이아웃 겹침을 해결합니다.
이를 통해 사용자는 화이트보드가 실시간으로 “조립되는” 과정을 볼 수 있습니다.
편집의 경우, 다음과 같은 작업을 수행합니다:
현재 보드의 SVG 표현을 LLM에 제공하며, 라인 번호가 포함됩니다.
또한 다음과 같은 도구들을 제공합니다:
delete_svg
insert_svg
replace_svg (라인 기반)
update_elements_svg (ID 기반)
LLM이 변경 작업을 수행하기 전에 계획을 먼저 정리할 수 있도록 특별한 todo_list 도구를 도입했습니다.
이 단순한 패턴은 복잡한 다단계 편집 작업의 품질을 크게 향상시켰습니다.
todo_list
<todo_list>
모든 스티키 노트를 빨간색으로 변경
모든 스티키 노트를 왼쪽으로 이동
아래에 빨간 스티키를 더 생성
</todo_list>
편집 예시 출력 – TODO 리스트가 항상 먼저 나옵니다.
데이터베이스
데이터베이스는 LLM이 스키마, 뷰, 데이터의 세 개의 CSV로 생성하며, 이를 XML 태그로 감싸 구성됩니다.
이를 통해 스키마, 프레젠테이션(표현), 데이터가 명확하게 분리되고, 스트리밍되는 과정에서도 파싱 가능한 상태로 유지됩니다.
생성 과정에서는 모델이 항상 XML 태그로 감싸진 세 개의 CSV 섹션을 생성합니다:
<fields> – 스키마 정의:
field_name, type, depends_on, configuration<views> – 뷰 설정:
view_name, layout, filters, sorts, hidden_fields<data> – 정의된 필드에 맞는 샘플 행
편집 시에는 모델이 이 표현 방식의 데이터베이스와 사용자의 선택을 함께 입력으로 받고, 그 결과로 두 개의 CSV를 출력합니다:
메타데이터 변경 – 스키마, 뷰, 필터, 정렬
데이터 변경 – 행 추가/수정/삭제
이러한 CSV의 각 행은 하나의 선언적 변경을 나타내며, 이를 다운스트림 코드가 안정적으로 파싱하고 적용할 수 있습니다.
생성된 콘텐츠를 클라이언트로 스트리밍하기
LLM이 무엇을 생성해야 하는지를 결정하는 것은 문제의 절반에 불과했습니다.
나머지 절반은 해당 출력을 프론트엔드로 전달하는 것이었으며, 이는 점진적으로, 실시간으로, 그리고 여러 렌더링 표면에 걸쳐 이루어져야 했습니다.
Rovo 채팅 / Rovo 캔버스 내 콘텐츠 iFrame 통신
Canvas는 전사적으로 공통으로 사용되는 Rovo Chat 플랫폼 컴포넌트를 활용합니다.
단순한 미리보기(preview)를 따로 구현하는 대신, Confluence 메인 경험에서 사용하는 것과 동일한 컴포넌트를 사용해 콘텐츠를 렌더링하며, 이를 iframe에 임베딩합니다.
이를 통해 Canvas는 Confluence의 콘텐츠 객체와 동일한 수준의 기능적 동등성(feature parity)을 갖게 됩니다.
이를 지원하기 위해 LLM 액션을 위한 새로운 스트리밍 API 계약을 정의했습니다:
LLM API는 생성되는 동안 부분 결과를 스트리밍으로 전송합니다.
프론트엔드는 이러한 부분 청크를 수집합니다.
그리고 렌더링이 필요한 콘텐츠 객체에 업데이트를 반영합니다.
프론트엔드 컴포넌트는 이를 통해 스트리밍 형태의 사용자 경험을 제공합니다.
이 기능은 Rovo가 지원하는 모든 환경에서 동작해야 합니다.
Rovo Canvas 내의 생성/편집에서도, Rovo를 통해 Confluence 콘텐츠를 직접 편집할 때와 동일한 명령을 사용했습니다.
Rovo Chat을 통한 Confluence 일반 콘텐츠 편집
iFrame 내부에서 사용자는 텍스트를 선택하고 편집을 요청할 수 있으며, 해당 요청은 iFrame 외부에 있는 Rovo Chat 컴포넌트를 통해 실행되어야 합니다.
따라서 채팅과 콘텐츠 객체 간 양방향 통신 채널(bidirectional communication channel)이 필요하다는 점이 명확해졌습니다:
동일 origin 및 cross-origin 환경에서
서로 다른 JavaScript 컨텍스트 간에도
전송 계층 세부 사항이 애플리케이션 코드로 노출되지 않도록
그 결과 Rovo Bridge API가 탄생했습니다.
이는 로컬 함수 호출을 통해 서로 다른 애플리케이션이 통신할 수 있도록 하는 라이브러리이며, 그 과정에서 하위 전송 계층은 추상화됩니다.
내부 동작 구조:
전송 계층 추상화(Transport abstraction)는 데이터가 실제로 어떻게 전달될지를 결정합니다:
BrowserTransport (postMessage 기반)
DesktopTransport (Electron IPC 기반)
그리고 향후 더 추가될 다양한 방식들
명령은 강한 타입 시스템을 갖춘 Command 패턴을 따르며, 안전성을 보장합니다.
각 명령에는 추적성과 보안을 위해 sender 및 receiver 메타데이터가 포함됩니다.
데이터는 선택된 전송 계층 위에서 JSON-RPC 스펙(JSON-RPC 2.0 Specification )을 기반으로 교환됩니다.
평가 및 모니터링
오프라인 평가(offline eval)는 모든 콘텐츠 유형에 걸친 대규모 데이터셋을 활용해 매일 수행되었습니다.
이 과정에서는 스크린샷 기반의 새로운 평가 방식을 사용했으며, LLM 평가자가 작업 완료 여부뿐 아니라 시각적 품질, 톤, 지식 정확성까지 평가하도록 했습니다.
또한 결과는 항상 사람의 피드백을 기준선으로 삼아 비교되었습니다.
온라인 평가는 실제 고객 및 내부 트래픽에서 성공률과 작업 완료 지표를 추적하여, 고정된 데이터셋과 분리된 현실 세계의 신호를 제공합니다.
실시간 안정성과 품질 모니터링을 위해 자동화된 헬스 체크가 구축되었으며, 에이전틱 플로우(agentic flows)가 올바르게 동작하는지를 검증했습니다.
단순히 상위 API 호출 성공 여부가 아니라, 적절한 서브 에이전트, 도구, 콘텐츠 액션이 정확히 호출되는지를 확인합니다.
이와 더불어 광범위한 신뢰성 모니터링 대시보드와 SLO가 운영되며, 급격한 에러 스파이크와 성능 저하를 감지하는 탐지 시스템도 포함되어 있습니다.
결론
AI를 위한 시스템을 구축하려면 사고방식의 전환이 필요합니다.
업계는 매우 빠르게 변화하고 있으며, 코드·프롬프트·모델 역시 지속적으로 빠르게 진화할 것입니다.
그러나 견고한 평가(evaluation) 체계, 온라인 실험을 위한 정교한 메트릭, 그리고 포괄적인 신뢰성 모니터링이 있어야만 빠른 반복을 안정적으로 수행할 수 있습니다.
Rovo를 활용한 콘텐츠 생성은 새로운 기반 경험이며, 향후 Confluence AI 기능의 핵심 구성 요소로 확장될 것입니다.
이는 시작에 불과합니다.