8월 17일 전 꺼야 할 스위치, Atlassian AI 데이터 기여

AI 요약

• 무슨 일: Atlassian의 데이터 기여 설정이 5월 19일 롤아웃 완료됐고, 8월 17일부터 AI 개선 데이터 사용 변경이 적용됩니다.
  • Free·Standard는 인앱 데이터 기본 On, Premium·Enterprise는 Off입니다.
• 핵심 경계: Jira 티켓, Confluence 문서, Rovo Chat, Teamwork Graph 연결 데이터가 AI 제품 개선 범위에 걸립니다.
• 실무 영향: 개발팀은 “모델 입력에 넣지 말라”가 아니라 admin.atlassian.com의 조직 기본값을 검토해야 합니다.
• 주의점: Atlassian은 비식별화·집계를 말하지만, 메타데이터 opt-out은 Enterprise에만 열려 있습니다.

Atlassian의 AI 데이터 기여 설정이 2026년 5월 19일 기준으로 관리 콘솔에 모두 롤아웃됐습니다. 적용일은 아직 남아 있습니다. Atlassian은 8월 17일부터 고객의 메타데이터와 인앱 데이터를 "모든 고객을 위한 앱과 AI 경험 개선"에 쓰는 변경을 시행한다고 공지했습니다. 이 문장은 평범한 약관 업데이트처럼 보이지만, 개발팀 입장에서는 Jira 티켓, Confluence 설계 문서, Rovo Chat, Teamwork Graph connector가 어떤 기본값으로 AI 개선 루프에 들어가는지 확인해야 하는 사건입니다.

이번 뉴스가 흥미로운 이유는 Atlassian이 AI 기능을 출시했다는 사실 자체가 아닙니다. 이미 Rovo, Rovo Dev, Teamwork Graph, Rovo MCP server처럼 조직 지식과 에이전트 인터페이스를 연결하는 제품군은 꾸준히 확장되고 있습니다. 진짜 변화는 AI가 업무 데이터를 "현재 조직을 위한 검색과 답변"에만 쓰는 단계를 넘어, 제품 전반의 개선 데이터로 삼는 기본 정책을 공개적으로 정리했다는 점입니다. AI 협업 도구의 경쟁은 모델 성능만의 문제가 아니라, 누가 어떤 업무 그래프를 어떤 기본값으로 학습 가능한 재료로 삼는지의 문제로 이동하고 있습니다.

Atlassian 공식 Trust 페이지가 제시한 일정은 세 단계입니다. 4월 16일 데이터 기여 설정 롤아웃을 시작했고, 5월 19일 설정 롤아웃을 완료했으며, 8월 17일 변경된 데이터 사용과 고객 조건이 실제로 적용됩니다. 즉 지금은 이미 적용된 사후 공지가 아니라, 조직 관리자가 90일가량 설정을 검토할 수 있는 창입니다. 이 시점이 중요한 이유는 데이터 정책의 위험이 코드 배포처럼 테스트 환경에서만 드러나지 않기 때문입니다. 기본값을 잘못 이해한 채 8월을 맞으면, 이후에는 어떤 프로젝트 공간과 어떤 앱이 포함됐는지 추적하는 일이 훨씬 번거로워집니다.

무엇이 기본 On인가

Atlassian 문서의 핵심 표는 플랜별 기본값입니다. Free와 Standard 조직은 메타데이터 기여가 항상 켜져 있고, 인앱 데이터 기여도 On입니다. Premium은 메타데이터가 켜져 있지만 인앱 데이터는 Off입니다. Enterprise도 기본적으로 메타데이터는 On, 인앱 데이터는 Off이지만, Enterprise는 메타데이터 기여를 끌 수 있습니다. 일부 컴플라이언스 요구사항이 있는 조직은 다른 기본값을 볼 수 있다고 덧붙였지만, 일반적인 기본선은 이렇습니다.

이 표에서 개발팀이 놓치기 쉬운 부분은 "최상위 활성 플랜"입니다. Atlassian은 한 조직 안에 여러 앱이 섞여 있을 때 기본값을 최고 활성 플랜 기준으로 정한다고 설명합니다. 예를 들어 Confluence가 Free이고 Jira가 Standard인 단일 조직은 인앱 데이터 기여가 On입니다. 같은 조직에 Premium 앱이나 Enterprise 앱이 섞이면 기본값이 달라질 수 있습니다. 이 구조는 비용 플랜의 문제가 아니라 조직 단위 데이터 정책의 문제입니다. 개발팀이 Jira만 보고 판단하거나, 문서팀이 Confluence만 보고 판단하면 실제 조직 설정을 잘못 이해할 수 있습니다.

인앱 데이터라는 말의 무게

Atlassian이 말하는 인앱 데이터는 추상적인 사용 로그가 아닙니다. 공식 FAQ는 Confluence 페이지 제목과 본문, Jira work item의 제목·설명·댓글, 커스텀 이모지 이름, 커스텀 Jira 또는 Confluence 상태 이름, 커스텀 워크플로 이름을 예로 듭니다. 개발 조직에서 이 데이터는 대개 평범하지 않습니다. 티켓 설명에는 고객 장애 재현 단계가 들어가고, 댓글에는 제품 의사결정의 흔적이 남고, Confluence에는 아키텍처 전환 계획과 보안 검토가 쌓입니다.

물론 Atlassian은 이 데이터를 그대로 공개하거나 원본 그대로 모델 학습에 투입한다고 말하지 않습니다. 공식 설명은 기여된 인앱 데이터와 메타데이터를 비식별화하고 집계한다고 강조합니다. 이름과 이메일처럼 개인을 직접 식별하는 정보는 제거하고, 재식별을 막기 위한 통제를 적용한다는 설명도 있습니다. 하지만 기업 업무 데이터의 민감성은 개인 식별자만의 문제가 아닙니다. 특정 프로젝트의 지연 사유, 특정 고객군의 요구, 내부 서비스 이름, 보안 취약점의 패턴처럼 조직을 직접 지목하지 않아도 경쟁상 의미를 갖는 정보가 많습니다.

여기서 메타데이터의 정의가 논쟁을 부릅니다. Atlassian은 메타데이터를 content attributes와 common patterns로 나눕니다. content attributes에는 Jira story point 수나 Confluence 페이지 복잡도 같은 통계적 특성과 파생값이 포함될 수 있습니다. common patterns에는 검색 쿼리와 결과, Rovo Chat의 대화·프롬프트·응답, 커스텀 구성 데이터에서 여러 고객에게 자주 나타나는 구문·키워드·주제가 포함될 수 있습니다. 문서상으로는 낮은 빈도로 나타나 조직 고유성이 있을 수 있는 데이터는 제외한다고 되어 있습니다.

문제는 이 정의가 개발팀에게 익숙한 "메타데이터"보다 넓다는 점입니다. 파일 크기, 생성 시간, 작성자 같은 껍데기 정보가 아니라, 콘텐츠에서 추출된 패턴과 파생 특성이 포함됩니다. Hacker News 댓글 중 한 사용자는 Atlassian의 메타데이터가 사실상 고객 콘텐츠에서 파생된 데이터 제품에 가깝다고 비판했습니다. 표현은 거칠었지만 지적 자체는 실무적으로 중요합니다. AI 제품에서 데이터 파생물은 원본보다 덜 민감하다고 단정하기 어렵습니다.

Rovo와 Teamwork Graph가 바꾸는 범위

이번 설정은 Jira와 Confluence만의 이야기가 아닙니다. Atlassian은 초기 적용 범위에 Jira, Confluence, Jira Service Management를 넣고, Atlassian Platform 앱인 Rovo, Home, Teams, Projects, Assets, Goals, Analytics, Administration도 포함된다고 설명합니다. 또 조직이 설정한 일부 Teamwork Graph connectors에도 설정이 제공된다고 말합니다. 이 조합은 개발자에게 익숙한 이슈 트래커의 범위를 넘어섭니다.

Rovo가 지향하는 방향은 조직 지식을 검색하고, 요약하고, 에이전트가 업무를 처리하도록 연결하는 것입니다. Teamwork Graph는 사람, 팀, 프로젝트, 목표, 콘텐츠, 앱 사이의 관계를 조직 지식 그래프로 묶습니다. Rovo MCP server까지 고려하면, 외부 AI 클라이언트와 Atlassian 업무 데이터 사이의 연결면도 넓어집니다. 이런 구조에서는 "Jira 티켓 하나"가 독립된 문서가 아니라 사람·프로젝트·목표·대화·커넥터의 그래프 일부가 됩니다.

그래서 이번 변경은 AI 거버넌스 관점에서 더 중요합니다. 과거에는 민감한 문서를 Confluence에 올릴지 말지, Jira 티켓에 고객명을 쓸지 말지 같은 작성 규칙이 중심이었습니다. 이제는 관리 콘솔의 기본값, 앱별 포함·제외, space 단위 제외, connector 단위 제외, 신규 앱 추가 후 30일 검토 같은 운영 절차가 함께 필요합니다. AI 도구를 막느냐 쓰느냐의 문제가 아니라, 업무 그래프가 어떤 데이터 계약 아래에서 쓰이는지 관리해야 하는 단계입니다.

커뮤니티가 화난 지점

Hacker News의 관련 스레드는 600점이 넘는 반응과 100개 이상의 댓글을 모았습니다. 가장 큰 분노는 "기본값"에 있었습니다. Free와 Standard 고객은 인앱 데이터 기여가 기본 On이고, 메타데이터는 끌 수 없습니다. Atlassian은 모든 고객이 인앱 데이터 기여를 opt out할 수 있다고 설명하지만, 관리자가 찾아 들어가 끄는 행동을 해야 한다는 점은 그대로 남습니다.

두 번째 쟁점은 설정의 가시성입니다. HN 원문 작성자는 공식 지원 문서를 링크하면서, 자신들의 인스턴스에서는 해당 설정을 찾을 수 없다고 말했습니다. 댓글에는 Atlassian이 5월까지 Admin portal에 opt-out 기능을 단계적으로 배포한다고 안내했다는 이메일 내용도 공유됐습니다. 이 부분은 5월 19일 롤아웃 완료 공지와 맞물립니다. 오늘 이후 조직 관리자는 실제로 Atlassian Administration → Security → Data contribution 경로를 확인해야 합니다.

세 번째 쟁점은 "AI 개선"이라는 넓은 목적입니다. Atlassian은 이 변경이 더 나은 AI 경험을 만들기 위한 것이라고 설명합니다. 예를 들어 검색 관련성을 개선하고, 고객들이 자주 수행하는 작업을 파악해 더 나은 추천이나 다음 단계를 제공할 수 있다고 말합니다. 하지만 개발팀이 보는 Jira와 Confluence는 단순한 UX 개선 재료가 아닙니다. 로드맵, incident postmortem, 보안 이슈, 고객 계약 관련 문서가 뒤섞이는 업무 원장입니다. 커뮤니티 반응은 이 간극에서 나왔습니다.

AI 기능의 비용은 토큰 가격만이 아닙니다

AI 개발 도구를 평가할 때 우리는 자주 모델 가격, latency, 벤치마크 점수, 컨텍스트 길이를 봅니다. 하지만 기업 AI의 실제 비용은 데이터 경계 설정에서 발생합니다. 누가 설정을 소유하는가, 어떤 기본값이 플랜에 따라 달라지는가, 신규 앱과 커넥터가 추가될 때 얼마 동안 검토할 수 있는가, 메타데이터와 인앱 데이터의 차이를 법무·보안·개발팀이 같은 방식으로 이해하는가가 중요해집니다.

Atlassian 문서에는 신규 앱을 추가하면 기존 데이터 기여 설정을 따른다는 설명이 있습니다. 새 앱의 메타데이터와 인앱 데이터는 30일 뒤 사용되기 시작하며, 그 기간에 검토하고 조정할 수 있다고 합니다. 새 space는 생성 시점부터 메타데이터와 인앱 데이터가 사용된다고 설명합니다. 이 작은 문장이 실무적으로 큽니다. AI 데이터 정책은 일회성 설정이 아니라 앱과 공간이 늘어날 때 반복되는 운영 프로세스가 됩니다.

플랜 변경도 변수입니다. Atlassian은 플랜을 업그레이드하거나 다운그레이드할 때 가능한 한 기존 선택을 유지한다고 설명합니다. 하지만 Enterprise에서 Free, Standard, Premium으로 내려가면 메타데이터 통제 기능을 잃습니다. Enterprise에서 메타데이터를 꺼둔 조직이 하위 플랜으로 이동하면 메타데이터 기여가 켜질 수 있고, 이 경우 알림과 30일 검토 기간을 제공한다고 문서화되어 있습니다. 비용 절감이나 앱 구조 변경이 곧 AI 데이터 통제 변경으로 이어질 수 있다는 뜻입니다.

개발팀이 지금 확인할 것

이번 사안을 과장할 필요는 없습니다. Atlassian이 고객 데이터를 무단 공개한다는 사건이 아니고, 공식 문서상 비식별화·집계·접근 제한·모니터링 같은 보호 장치를 제시하고 있습니다. 동시에 축소해서도 안 됩니다. "비식별화했으니 안전하다"는 한 문장으로 Jira와 Confluence의 업무 문맥을 모두 설명할 수는 없습니다. 특히 AI 에이전트가 조직 지식을 읽고 작업을 수행하는 흐름에서는 데이터 파생물도 경쟁 정보와 운영 정보의 신호를 가질 수 있습니다.

개발팀이 지금 할 일은 세 가지입니다. 첫째, 조직의 최상위 활성 플랜과 실제 기본값을 확인해야 합니다. Free나 Standard를 쓰는 작은 팀일수록 기본 On 상태를 지나치기 쉽습니다. 둘째, Jira 프로젝트, Confluence space, Teamwork Graph connector 중 AI 개선 데이터에서 제외해야 할 범위를 정해야 합니다. 제품 로드맵, 보안 취약점, 고객별 장애 기록, 미공개 계약 정보가 들어가는 공간은 별도 기준이 필요합니다. 셋째, Rovo Chat과 검색 쿼리도 메타데이터 정의 안에 들어갈 수 있다는 점을 사용자 교육에 반영해야 합니다.

이것은 Atlassian만의 문제가 아닙니다. Microsoft 365 Copilot, Google Workspace Gemini, Notion AI, Slack AI, GitHub Copilot Enterprise 모두 같은 방향으로 가고 있습니다. AI가 실무에서 유용해질수록 더 많은 업무 데이터를 필요로 하고, 제품사는 그 데이터를 더 나은 추천, 검색, 에이전트 행동으로 되돌리려 합니다. 차이는 각 회사가 기본값과 통제권을 어떻게 설계하느냐입니다. 이번 Atlassian 사례는 그 기본값이 뉴스가 될 만큼 민감한 단계에 들어왔다는 신호입니다.

기본값의 시대

개발자는 AI 도구를 도입할 때 종종 "어떤 모델을 쓰는가"부터 묻습니다. 이제는 질문을 바꿔야 합니다. 어떤 데이터가 기본적으로 포함되는가, 무엇을 끌 수 있는가, 무엇은 플랜을 올려야만 끌 수 있는가, 새 앱과 connector가 생길 때 기본값은 어떻게 승계되는가를 봐야 합니다. Atlassian의 5월 19일 롤아웃 완료는 이 질문을 미룰 수 없게 만든 이벤트입니다.

8월 17일은 단순한 약관 적용일이 아닙니다. Jira와 Confluence가 AI 시대의 업무 그래프로 재해석되는 날짜입니다. 좋은 AI 경험을 원한다면 데이터가 필요합니다. 하지만 좋은 AI 운영을 원한다면, 데이터가 어디까지 흘러가는지에 대한 기본값과 예외 규칙도 필요합니다. 이번 스위치는 제품 설정 화면에 있지만, 실제로는 개발팀의 데이터 거버넌스 표준을 묻고 있습니다.