2026년 7월 1일, Atlassian은 일상적으로 들리지만 익숙한 그림을 깨는 수치를 발표했습니다. 바로 Rovo MCP가 5백만 호출(calls)을 초과했다는 것입니다. 이 데이터는 Rovo MCP 작업에 대한 회사 자체 블로그에서 나온 자료입니다. 독립적인 릴리스 추적기인 Releasebot 역시 같은 7월에 해당 플랫폼 업데이트를 기록했습니다.

먼저 사실과 화려한 해석을 분리하는 것이 중요합니다. 5백만은 호출 프로토콜의 카운터일 뿐, 5백만 명의 사용자나 5백만 개의 완료된 태스크가 아닙니다. 하지만 이렇게 정확하게 읽어내기도 어려운 이 수치는 하나의 핵심적인 변화를 보여줍니다. 즉, Jira와 Confluence가 사람에 의해 브라우저를 통해 열리는 경우가 아니라, 프로그램 에이전트에 의해 MCP(Model Context Protocol)를 통해 더 자주 열리고 있다는 것입니다. 인간을 위해 설계된 도구가 이제 기계들을 위한 API 계층 역할까지 하게 된 것입니다.

다음은 마케팅 없이 분석하는 내용입니다. Atlassian이 정확히 무엇을 공개했는지, MCP가 원리를 쉽게 설명하면 무엇인지, 코드 상에서 호출이 어떻게 보이는지, 왜 호출 카운터를 돈으로 환산할 수 없는지, 그리고 해외 일부 모델에 직접 접근할 수 없는 러시아의 엔지니어가 이 모든 것을 가지고 무엇을 해야 하는지에 대해 다룹니다.

Atlassian이 정확히 공개한 내용?

Atlassian 데이터에 따르면 두 가지가 언급됩니다. 첫째는 누적량입니다: Rovo MCP가 5백만 호출의 기준점을 초과했습니다. 둘째는 일일 사용량 증가입니다: 회사는 일일 부하가 증가하고 있다고 보고합니다. 원본 자료에서 구체적인 일일 수치, 고객별 분류 또는 Jira 대 Confluence의 비율을 찾지 못했기 때문에 여기에 포함하지 않습니다. 그렇지 않으면 이는 지어낸 이야기가 될 것입니다.

'호출(call)'이라는 단어 뒤에 숨겨진 의미가 있습니다. MCP(Model Context Protocol)는 언어 모델이나 에이전트가 외부 도구에 접근하는 프로토콜입니다. 이 과정에서 사용 가능한 작업 목록을 받고, 해당 작업을 인자(arguments)와 함께 호출하며, 그 결과를 받게 됩니다. Jira와의 에이전트 한 번의 대화—'스프린트 태스크를 찾고, 담당자를 기준으로 필터링하고, 상태를 업데이트하라'—는 여러 개의 개별 호출로 쉽게 전개될 수 있습니다. 따라서 호출 카운터가 실제 사용자 시나리오의 수보다 더 빠르게 증가하는 것입니다.

여기서 첫 번째 실질적인 결론을 얻을 수 있습니다. 5백만이라는 숫자는 비즈니스 결과가 아닌, 해당 패턴의 채택(adoption)을 나타내는 지표입니다. 이 수치는 "에이전트들이 업무 데이터를 대중적으로 다루기 시작했는가?"라는 질문에는 정직하게 답해줍니다. 하지만 "이것이 얼마나 많은 돈을 절약해주었는가?"라는 질문에 대해서는 정직하게 침묵합니다. 고객 데이터 없이는 그 질문에 답할 수 없기 때문입니다.

만약 기업용 위키(wiki)나 트래커(tracker)를 기반으로 내부 에이전트를 구축하고 있다면, 이 지표는 성숙도를 가늠하는 이정표로서 유용합니다. 즉, 프로토콜이 데모 단계를 벗어났음을 의미합니다. 그리고 바로 이 단계에서, 에이전트가 모델 자체에 어떻게 접근하게 될지 차분하게 한 번 계산해 보아야 합니다. 도구(tool)와 에이전트의 두뇌(brain)는 서로 다른 두 부분이며, 두 가지 모두 귀하의 인프라에서 접근 가능해야 하기 때문입니다.

MCP란 무엇이며, 왜 Jira와 Confluence가 에이전트의 도구가 되었는가?

이전의 트래커 통합 방식은 다음과 같았습니다: 개발자가 직접 Jira의 REST API를 감싸는 래퍼(wrapper)를 작성하고, 각 엔드포인트(endpoint)를 기술하며, 응답을 파싱하고, 스키마(schema)가 업데이트될 때마다 이를 수정해야 했습니다. 이러한 구조에서 모델은 눈먼 상태였습니다. 모델은 텍스트를 생성할 수 있을 뿐이었고, 모든 "근육" 작업은 사람이 작성해야 했습니다.

MCP는 이 접근 방식을 뒤집습니다. 도구가 스스로 자신의 작업에 대한 기계 판독 가능한(machine-readable) 설명을 게시합니다: 어떤 동작이 있는지, 어떤 파라미터(parameter)가 있는지, 무엇이 반환되는지를 말입니다. 에이전트는 이러한 MCP 서버에 연결하여 작업 카탈로그를 확인하고, 추론 과정 중에 필요한 작업을 스스로 호출합니다. Jira의 경우 "JQL로 이슈 찾기", "이슈 생성", "상태 변경"과 같은 작업이 해당되며, Confluence의 경우 "페이지 찾기", "콘텐츠 읽기", "노트 생성" 등이 이에 해당합니다.

핵심적인 변화는 인간을 위해 설계된 인터페이스가 이제 인간과 에이전트(Agent) 모두에게 동일하게 접근 가능해졌다는 점입니다. Jira의 동일한 스프린트 보드(Sprint board)가 브라우저를 통한 인간의 눈으로도 열리고, 프로토콜을 통한 호출(Call)로도 열립니다. 이것이 바로 Atlassian의 수치가 증가하는 이유입니다. 업무 데이터 위에서 실행되는 각각의 에이전트 시나리오는 일련의 호출 묶음이기 때문입니다.

그리고 바로 이 지점에 이 수치를 과소평가해서는 안 되는 이유가 숨어 있습니다. 의미 있는 결과 하나를 얻기 위해 5번의 호출이 발생하는 것은 일반적인 모습입니다. 따라서 5백만 회의 호출은 "에이전트가 5백만 개의 유용한 일을 했다"기보다는 "프로토콜이 실무에 적용되기 시작했다"라고 읽는 것이 더 정확합니다.

실제 호출은 어떤 모습인가요?

최소한의 시나리오를 살펴보겠습니다. 에이전트가 Jira에서 스프린트 작업(Task)을 수집하여 Confluence에 관련 노트를 작성하는 경우입니다. 아키텍처 측면에서 당신에게는 두 개의 독립적인 부분이 있습니다. 첫 번째는 에이전트에게 Jira 및 Confluence 도구(Tool)를 제공하는 MCP 서버입니다. 두 번째는 "두뇌" 역할을 하는 언어 모델(Language Model)로, 작업을 읽고 어떤 도구를 호출할지 결정하며 최종 결과를 도출합니다.

모델과 도구는 반드시 동일한 벤더(Vendor)의 제품일 필요는 없습니다. MCP 서버는 데이터 접근을 담당하고, 모델은 도구 사용(Tool use)이 가능하며 당신의 네트워크에서 접근할 수 있는 것이라면 무엇이든 사용할 수 있습니다. 아래는 Claude가 "두뇌" 역할을 하고, 호출은 OpenAI/Anthropic 호환 엔드포인트(Endpoint)를 통해 이루어지는 Python 기반의 간결한 예시입니다. 키(Key)와 base_url만 변경하면 됩니다.

from anthropic import Anthropic

client = Anthropic(
...

역할 분담에 주목하십시오. jira_confluence_tools는 MCP 서버로부터 전달된 작업(Operation)들에 대한 설명입니다. 모델은 스스로 무엇을 어떤 순서로 호출할지 결정하며, 당신의 코드는 호출을 실행하고 그 결과를 다시 대화로 반환합니다. 이러한 각 단계는 Rovo MCP를 통해 이루어진다면 Atlassian의 지표 관점에서 하나의 "호출"이 됩니다.

만약 Rovo가 아니라 자신의 Jira 상에서 작동하는 자체 에이전트가 필요하다면, 방식은 동일합니다. MCP 서버를 구축하고, 모델을 연결한 뒤, "모델이 도구를 요청함 - 코드가 실행함 - 결과가 반환됨"의 루프를 완성하면 됩니다. Rovo는 Atlassian이 이 패턴을 구현한 브랜드 솔루션일 뿐, 이를 구축하는 유일한 방법은 아닙니다.

왜 500만 회의 호출이 500만 개의 작업이나 ROI(투자 대비 효율)를 의미하지 않는가?

이러한 뉴스를 읽을 때 가장 흔히 범하는 오류는 선형적인 재계산입니다. "500만 회의 호출이 발생했으니, 에이전트가 500만 개의 작업을 완료했을 것이고, 따라서 이만큼의 시간이 절약되었을 것이다"라고 생각하는 것이죠. Atlassian의 데이터는 이 단계 중 그 어느 것도 뒷받침하지 않으며, 회사 측에서도 금액 단위의 세부 정보 없이 호출량과 성장 사실만을 제시하고 있습니다.

논리가 어디서 끊어지는지 분석해 보겠습니다. 하나의 의미 있는 시나리오는 여러 번의 호출을 필요로 합니다. 호출 중 일부는 데이터를 변경하는 것이 아니라 읽고 확인하는 과정입니다. 또한 에이전트가 시나리오를 끝까지 완료하지 못하는 경우도 있습니다. 모델이 불필요한 호출을 반복하거나, 잘못된 JQL로 인해 빈 결과를 받거나, 확인 과정에서 루프에 빠질 수 있기 때문입니다. 따라서 "호출"과 "결과"는 서로 다른 단위이며, 그 사이의 계수는 공개되지 않았습니다.

이는 여러분의 자체 보고서에 대한 직접적인 시사점을 줍니다. 만약 Jira 및 Confluence 기반의 에이전트를 구축하고 있다면, 비즈니스 측에 호출 횟수로 보고하지 마십시오. 그것은 내부적인 기술 지표(Technical Metric)일 뿐입니다. 대신 완료된 시나리오 수, 성공적인 실행 비율, 그리고 하나의 유용한 결과를 얻기 위한 토큰 비용을 계산하십시오. 이 세 가지 수치는 의사결정으로 이어지지만, 호출 카운터는 그렇지 않습니다.

또 다른 함정은 비용입니다. 도구(tool)를 호출할 때마다 모델에 대한 요청이 뒤따릅니다. 모델이 결과를 읽고 다음 단계를 결정하기 때문입니다. 즉, 방대한 Confluence 페이지를 대상으로 하는 긴 에이전트 체인(agentic chains)은 곧 토큰(tokens)을 의미하며, 이를 사전에 계산해야 합니다. Atlassian의 호출 지표는 여러분의 비용에 대해 아무것도 말해주지 않습니다. 비용에 대해 말해주는 것은 오직 여러분 자신의 모델 빌링(billing)뿐입니다.

언제 Jira 및 Confluence 기반의 에이전트를 구축해야 하는가?

모든 시나리오가 에이전트를 필요로 하는 것은 아닙니다. 때로는 일반적인 규칙 기반 자동화(automation)만으로 충분하며, 때로는 단 하나의 JQL 필터만으로도 충분합니다. 에이전트는 비정형 텍스트(unstructured text)를 바탕으로 추론(reasoning)이 필요한 경우, 즉 흩어진 정보를 수집하고, 재구성하며, 작업을 문서와 연결해야 하는 경우에 정당성을 얻습니다. 아래는 결정을 돕기 위한 요약 표입니다.

로직은 간단합니다. 작업에 자유 형식의 텍스트와 요약이 많을수록 에이전트의 활용 가치가 높습니다. "이벤트가 발생하면 동작한다"라는 규칙이 명확할수록, 모델과 불필요한 호출 없이 일반적인 자동화가 더 잘 작동합니다. 만약 작업이 단순히 데이터를 추출하는 것에 불과하다면, 에이전트나 모델은 필요 없으며 JQL만으로 충분합니다.

러시아의 특수성에 대해 별도로 언급하자면, 여기서 가장 중요한 실질적인 분기점은 MCP 자체에 있는 것이 아닙니다. 프로토콜은 공개되어 있으며 지리적 위치에 의존하지 않습니다. 진짜 문제는 뇌 역할을 하는 모델에 대한 접근성입니다. 만약 여러분의 에이전트가 해외 모델에 의존하고 있다면, VPN이나 해외 카드 없이도 러시아에서 해당 모델에 안정적으로 도달할 수 있는 방법이 필요합니다. 그렇지 않으면 프로덕션(prod) 환경은 로직 때문이 아니라 네트워크와 결제 문제로 인해 중단될 것입니다.

여기 간단한 기법이 있습니다: 하나의 호환 가능한 엔드포인트(endpoint)를 통해 여러 모델에 대한 액세스를 유지하고, 통합 코드를 다시 작성하지 않고도 가격과 품질에 따라 모델을 전환하는 것입니다. provod.ai는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 채팅에 모아 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 즉, 키(key)와 base_url만 변경하면 에이전트(agent) 코드는 그대로 유지됩니다. 결제는 카드, SBP(Fast Payment System) 또는 계좌 이체를 통해 루블로 가능하며, 회계 처리를 위한 계약서, 인보이스 및 증빙 서류도 제공됩니다. 이때 provod.ai는 자동화 플랫폼 자체를 대체하거나, GigaChat을 제공하거나, 프라이빗(private) 또는 온프레미스(on-prem) 인프라를 대신하거나, 대신 구축을 해주는 것이 아닙니다. 이는 Jira에 대한 액세스가 아니라 모델에 대한 액세스입니다.

단 하룻밤 만에 자신의 에이전트를 연결하는 방법은?

자신의 스탠드(stand)에서 최소 기능 제품(MVP)을 만들기 위한 단계별 계획입니다. 마법 같은 것은 없으며, 모든 것은 도구(tool)와 모델(model)이라는 두 가지 요소를 중심으로 돌아갑니다.

1. Jira 및 Confluence를 위한 MCP 서버를 구축하거나, 이미 Atlassian 생태계에 있다면 Rovo를 사용하세요. 이 단계에서 권한을 확인해야 합니다. 에이전트는 관리자(admin) 계정이 아닌, 최소한의 필요한 권한을 가진 서비스 계정(service account)으로 동작해야 합니다.
2. 도구 사용(tool use)을 지원하는 모델을 선택하고, 해당 모델이 귀하의 네트워크에서 접근 가능한지 확인하세요. 로직을 작성하기 전에 연결성과 결제 상태를 미리 점검하십시오.
3. 사이클을 완성합니다: 모델이 도구를 요청하면 -> 귀하의 코드가 MCP를 통해 호출을 실행하고 -> 결과가 대화로 반환됩니다. 에이전트가 무한 루프에 빠지지 않도록 한 번의 실행당 단계(step) 수를 제한하세요.
4. 한 번의 실행에 사용할 호출(call) 및 토큰(token) 예산을 설정하고 모든 호출을 로깅(logging)하세요. 이것이 Atlassian 지표를 대체할 수 있는 정직한 방법입니다. 귀하에게 필요한 것은 총 카운터가 아니라, 하나의 유용한 결과물을 얻기 위한 비용입니다.
5. 부정적인 케이스(negative cases)에 대해 테스트하세요: 빈 JQL, 액세스 권한이 없는 Confluence 페이지, 너무 큰 문서 등입니다. 에이전트는 답변을 지어내는 것이 아니라 예측 가능한 방식으로 성능이 저하(degrade)되어야 합니다.

관측성 (Observability)에 대해 별도로 말씀드리겠습니다. 매 단계가 하나의 호출(call)이기 때문에, 어떤 도구가 어떤 인자(argument)로 호출되었고 무엇이 반환되었는지에 대한 전체 체인의 트레이스 (trace)가 필요합니다. 이것 없이는 무한 루프, 불필요한 호출, 또는 비용 상승을 디버깅 (debug)할 수 없습니다. 본질적으로 여러분은 Atlassian이 공개 수치를 얻어낸 것과 동일한 텔레메트리 (telemetry)를 직접 재현하게 되는 것입니다.

그리고 보안에 관한 문제입니다. 상태를 변경하고 페이지를 생성할 수 있는 에이전트는 쓰기 권한을 가진 계정입니다. 권한은 최소한으로 제한되어야 하며, 작업은 로그 (log)로 기록되어야 하고, 변경 작업은 이상적으로는 승인을 필요로 해야 합니다. MCP는 접근을 용이하게 하지만, "누가 무엇을 변경할 권한을 갖는가"라는 문제를 해결해주지는 않습니다.