팀 위키에 공들여 쓴 기획서를, 발표 전날 또 파워포인트로 옮기느라 한 시간을 날린 적 있죠. 그 한 시간은 새 정보를 만든 게 아니에요. 이미 있는 내용을 다른 포맷으로 베껴 적은 노동이에요. 그리고 우리 일과의 절반은 사실 이 베끼기로 채워져 있어요.
2026년 4월 8일, Atlassian이 Confluence에 내놓은 기능 묶음은 바로 이 '포맷 베끼기' 노동을 통째로 겨냥했어요. 그런데 이 발표가 흥미로운 건 Atlassian 때문이 아니에요. 여기서 드러난 업무 도구의 새 문법 때문이에요. 당신이 Confluence를 쓰든 안 쓰든, 오늘부터 적용할 수 있는 문법이요.
당신 일과의 어디가 새고 있나
잠깐 솔직하게 따져봐요. 지난 한 주, 아래 중 몇 개를 했나요?
- 회의록을 정리한 뒤 → 같은 내용으로 발표 슬라이드를 다시 만들었다
- 기획서를 쓴 뒤 → 그 숫자들을 시트에 옮겨 차트를 그렸다
- PRD를 넘긴 뒤 → 디자이너·개발자가 그걸 다시 읽고 프로토타입으로 옮기기를 며칠 기다렸다
전부 원본은 이미 완성됐는데, 그걸 보여주기 위해 같은 정보를 손으로 옮기는 일이에요. 그 옮기는 과정에서 컨텍스트가 새고, 버전이 어긋나고, 시간이 증발해요. Atlassian 자체 데이터로도 비주얼이 있는 Confluence 페이지는 읽히는 비율이 거의 2배인데, 정작 그 비주얼을 만드는 건 가장 미루기 쉬운 잡일이라는 게 함정이죠.
그러니까 진짜 문제는 "문서를 못 써서"가 아니에요. 다 써놓은 문서가 결과물까지 가는 마지막 1마일에서 매번 막히는 것이에요.
Atlassian이 내놓은 답: 문서를 '레이어'로 갈아끼우기
이번 발표의 핵심은 두 가지예요.
① Remix with Rovo (오픈 베타). Confluence 페이지에서 텍스트를 드래그하면 AI가 차트·인포그래픽·스코어카드로 즉시 바꿔줘요. 결정적인 설계는 원본을 절대 건드리지 않는다는 점이에요. 비주얼이 원본 위에 '레이어'처럼 얹히고, 소스 페이지에 자동으로 연결돼요. 마음에 안 들면 레이어만 지우면 끝이라, 원본을 망칠 걱정 없이 마구 실험할 수 있어요.
② 서드파티 파트너 에이전트 3종 (4/13~ 순차 배포). Lovable·Replit·Gamma가 Confluence 안에서 직접 돌아가요. 각각이 처리하는 '마지막 1마일'은 이래요.
- Lovable: 제품 기획서 → 작동하는 UI 프로토타입
- Replit: 기술 문서 → 엔지니어가 포크해서 쓰는 스타터 앱
- Gamma: 회의록·상태 페이지 → 바로 발표 가능한 프레젠테이션
이 에이전트들은 MCP(Model Context Protocol)로 붙어요. 관리자가 Atlassian Administration에서 파트너의 MCP 서버를 켜기만 하면, 코딩 없이 몇 분 안에 팀 Rovo 디렉토리에 에이전트가 나타나요.
왜 'MCP라서' 중요한지는 뒤에서 다시 짚을게요. 일단 핵심은 — Confluence가 '문서 저장소'에서 문서가 결과물로 곧장 변환되는 실행 플랫폼으로 성격이 바뀌었다는 거예요.
| 이 작업이 | 지금까지 (수동 베끼기) | 이제 (한 번에 변환) |
|---|---|---|
| 기획서 → 차트 | 문서 복사 → 시트에 붙여넣기 → 차트 수동 제작 | 텍스트 드래그 → Remix가 차트 자동 생성 (원본 연결 유지) |
| PRD → 프로토타입 | 디자이너에게 전달 → 피그마에서 수일 작업 | Lovable이 PRD 읽고 → 수 분 내 작동 UI |
| 회의록 → 발표자료 | 파워포인트 열기 → 내용 옮기기 → 디자인 정리 | Gamma가 회의록에서 바로 프레젠테이션 |
| 기술 문서 → 앱 | 개발팀에 요청 → 백로그 대기 | Replit이 문서에서 스타터 앱 자동 생성 |
| 공통점: 문서에서 결과물까지 '컨텍스트 유실 없는 원스텝 변환' | ||
Confluence + Rovo를 쓴다면: 오늘의 5단계
이미 환경이 있다면 순서는 간단해요. 막히기 쉬운 지점도 함께 적어둘게요.
- Rovo 활성화부터 확인 (가장 흔한 막힘 지점)
Confluence Cloud + Rovo 라이선스가 있어야 해요. Remix는 Rovo가 켜진 Cloud 고객에게 오픈 베타로 순차 배포 중이라, 버튼이 안 보이면 십중팔구 여기가 원인이에요. - Remix는 '데이터 많은 페이지'로 첫 테스트
에디터 툴바에서 Remix 버튼을 찾고, 표가 많은 페이지나 긴 문서를 골라보세요. 짧은 글로 시작하면 변환의 위력이 안 느껴져요 — 첫인상은 숫자 가득한 문서에서 갈려요. - 파트너 에이전트 켜기 (관리자 권한 필요)
Atlassian Administration → Connected Apps에서 Lovable·Replit·Gamma의 MCP 서버를 활성화하세요. 4월 13일부터 순차 배포돼요. - Rovo Chat에서 자연어로 호출
페이지에서 Rovo Chat을 열고 에이전트를 선택한 뒤, "이 기획서를 Lovable 프로토타입으로 만들어줘"처럼 말로 시키면 돼요. - MCP 스킬 갤러리로 확장
Atlassian의 MCP 스킬 갤러리에서 추가 연동 도구를 둘러보고, 필요하면 자체 에이전트도 만들 수 있어요.
Confluence가 없어도: 오늘 따라 하는 변환 플레이북
여기가 이 글의 진짜 알맹이예요. 위 5단계는 Rovo가 있어야 돌아가지만, 그 안에 깔린 패턴은 도구를 안 가려요. 핵심은 세 가지 원칙이에요.
- '원본 하나'를 단일 소스로 고정하라
회의록이든 기획서든, 결과물의 출발점이 되는 문서를 하나만 정해 두세요. 슬라이드·차트·프로토타입은 전부 그 문서에서 파생되는 것이지, 따로 관리하는 별개 자산이 아니에요. 이게 Remix '레이어' 사상의 핵심이고, 버전 어긋남을 막는 첫 단추예요. - 변환은 사람이 아니라 에이전트에게 위임하라
이미 쓸 수 있는 도구들로 같은 흐름을 만들 수 있어요. Gamma는 단독 제품으로 문서·텍스트를 프레젠테이션으로 바꿔주고, Lovable·Replit도 직접 가입해 기획서/문서를 붙여넣으면 프로토타입·스타터 앱을 만들어줘요. 회의록 → 슬라이드, PRD → 프로토타입을 손으로 옮기지 말고 이 도구들에 통째로 넘기세요. - 도구를 MCP로 엮어 '한 군데서' 호출하라
변환 도구가 흩어져 있으면 결국 또 베끼기가 돼요. MCP를 지원하는 클라이언트(예: Claude 등 MCP 호환 앱)에 쓰는 도구들의 MCP 서버를 연결해 두면, 도구를 옮겨 다니지 않고 한 자리에서 "이 문서로 슬라이드 만들어줘"라고 지시할 수 있어요. Atlassian이 독자 API 대신 MCP를 택한 이유가 바로 이거예요 — 한번 연결해 두면 도구가 바뀌어도 워크플로는 안 바뀌니까요.
정리하면: (1) 원본 문서 하나를 진실의 출처로 고정 → (2) 포맷 변환은 전부 에이전트에 위임 → (3) MCP로 한 곳에서 호출. Confluence는 이 셋을 한 제품 안에 묶었을 뿐, 셋 다 오늘 따로따로도 시작할 수 있어요.
왜 이게 '기능 추가'가 아니라 흐름의 신호인가
'새 플랫폼'에서 '기존 도구 속 에이전트'로
Salesforce가 2024년 Agentforce로 별도 에이전트 플랫폼을 내놓은 뒤, 업계 흐름은 빠르게 뒤집혔어요. "새 AI 플랫폼을 만든다"가 아니라 "이미 쓰는 도구 안에 에이전트를 심는다"로요. Slack은 Slackbot을 AI 에이전트로 탈바꿈시켰고, OpenAI는 Frontier Alliances로 컨설팅 펌과 손잡아 기존 워크플로에 AI를 끼워 넣는 전략을 택했어요. Atlassian도 같은 길이에요 — 2월 Jira에 에이전트를 넣은 데 이어 이제 Confluence까지, 1,600명 감원(약 10%)으로 확보한 자금을 AI에 몰아넣겠다는 선언과 맞물려 있죠. 당신의 업무 도구에도 곧 같은 일이 옵니다. 위 플레이북은 그때 우왕좌왕하지 않기 위한 예행연습이에요.
MCP가 진짜 게임 체인저인 이유
이번 발표에서 가장 저평가된 포인트가 MCP예요. Atlassian이 독자 API가 아니라 오픈 프로토콜을 골랐다는 건, 어떤 파트너든 Atlassian과 양자 계약 없이 에이전트를 만들어 연결할 수 있다는 뜻이에요. Lovable·Replit·Gamma는 시작일 뿐, MCP 채택이 늘수록 Confluence는 '에이전트 허브'가 될 수 있어요. 그리고 같은 논리가 당신에게도 적용돼요 — MCP를 기준으로 도구를 고르면, 특정 벤더에 묶이지 않고도 변환 자동화를 조립할 수 있어요.
고립된 결과물 vs. 워크스페이스 네이티브
Atlassian은 Google Notebook LM과의 차이를 이렇게 못 박았어요. "Notebook LM은 진공 상태에서 작동하지만, Remix는 팀이 이미 쓰는 페이지·권한·구조 안에서 동작한다." 둘 다 '문서를 다른 포맷으로 바꾸는 AI'지만, 결정적 차이는 워크스페이스 네이티브 vs. 독립 환경이에요. Remix 결과물은 Confluence 페이지 안에 살면서 댓글·멘션·실시간 편집이 그대로 이어지지만, Notebook LM 결과물은 원본과 분리되기 쉬워요. 그래서 위 플레이북 1번 원칙 — '원본 하나를 단일 소스로' — 이 중요한 거예요. 변환은 늘려도, 진실의 출처는 늘리지 마세요.
도구가 Confluence든 아니든, 기억할 건 한 줄이에요. 다 쓴 문서를 또 손으로 옮기고 있다면, 그건 이제 사람이 할 일이 아니에요. 이번 주에 가장 자주 베껴 옮긴 문서 하나만 골라, 그 변환을 에이전트에게 넘겨보세요. 마지막 1마일이 사라지는 감각, 거기서부터 시작이에요.
