Atlassian AMP 공개: AI 에이전트의 신원과 권한

Atlassian은 2026년 10월 7일 Team ’26 Europe에서 Agentic Multiplayer Protocol(AMP)을 공개했으며, AI 제품 책임자 Jamil Valliani는 SiliconANGLE과의 인터뷰에서 “This is a multiplayer game”이라고 말했다. 발표의 초점은 AI 에이전트가 개인 대화창에서 만든 결과만 전달하는 대신, 사람이 함께 보는 작업 흐름에 참여하도록 하는 데 있다. 에이전트의 활동 주체와 허용 범위를 드러내겠다는 약속도 여기에 포함된다.

Atlassian의 AMP 제품 설명은 이를 사람과 에이전트의 협업 경험, 기술, 설계 방식의 묶음으로 규정한다. 실시간·비동기 협업, 신원·공유 존재감, 맥락·거버넌스가 서로 연결된 세 계층이다. Jira 작업 항목과 Confluence 문서에서 일이 진행되는 방식부터 외부 에이전트의 접근 권한과 활동 기록까지 포괄한다는 구상이다.

Jira와 Confluence의 작업 안으로 들어오는 에이전트

첫 계층은 에이전트에게 일을 맡기는 장소를 바꾼다. Confluence 문서에서 에이전트를 언급하거나 Jira 댓글에서 작업 방향을 논의하면, 요청과 결과가 팀이 이미 사용하는 맥락에 남는다. Loom 영상으로 화면과 음성 설명을 전달하거나 Atlassian 밖의 도구에서 작업을 이어가는 경로도 제시됐다. 팀원은 완성된 답만 전달받는 대신 어떤 작업에서 요청이 시작됐는지 볼 수 있다.

이 구상에는 동시에 움직이는 작업과 시간이 걸리는 작업이 모두 들어간다. 공동 편집에서는 사람과 에이전트가 같은 페이지를 고치며 각자의 참여 상태를 드러낸다. 비동기 작업에서는 에이전트에게 Jira 작업 항목을 맡기고 진행 상황이나 사람의 입력이 필요한 지점을 작업 흐름에 연결한다. 두 경우 모두 에이전트의 결과가 원래의 문서나 작업 항목으로 돌아와야 다음 담당자가 맥락을 이어받을 수 있다.

로컬 개발 환경도 팀 기록과 연결하려는 대상이다. 터미널이나 IDE에서 실행한 에이전트 세션을 Jira 보드와 Teamwork Graph에 연결하면, 개인 장치에서 진행한 일이 해당 작업 항목과 함께 보일 수 있다. 개발자가 에이전트에게 코드를 맡겼다는 사실만 표시하는 것보다, 어느 작업을 위해 세션이 열렸고 팀의 진행 상태와 어떻게 이어지는지를 보여주는 데 의미가 있다.

이 흐름에서 ‘멀티플레이어’는 에이전트의 동시 실행 수를 뜻하는 말이 아니다. 사람이 문서를 수정하고 에이전트가 같은 작업의 일부를 처리할 때, 팀이 각 참여자의 상태와 기여를 구분할 수 있다는 뜻에 가깝다. 별도 채팅창의 답변을 복사해 붙이면 사라지기 쉬운 요청 맥락과 수정 경로를 공유 작업 안에 남기려는 설계다.

이름은 기여자를, 권한은 행동 범위를 구분한다

신원·공유 존재감 계층은 작업 화면에 나타난 에이전트를 식별하는 문제를 다룬다. Jira 보드, Confluence 화이트보드, 로컬 세션에서 어떤 에이전트가 활동하는지 보이고, 사람과 에이전트가 각각 무엇을 바꿨는지 구분하도록 설계됐다. 문서의 변경 이력에 사람의 이름만 남는 경우와 실제로 수정한 에이전트까지 드러나는 경우는 경위를 파악하는 데 주는 정보가 다르다.

에이전트의 이름은 소유자와도 연결돼야 한다. 어떤 사람이 작업을 시작했는지, 에이전트가 그 사람을 대신해 움직였는지, 독립된 계정으로 행동했는지가 구분돼야 기여 내역을 읽을 수 있다. 화면에 에이전트가 보이는 기능은 활동을 발견하게 해주지만, 그 활동을 허용한 권한의 출처는 실행 방식과 접근 정책이 설명한다.

맥락·거버넌스 계층에서는 Teamwork Graph가 과거 결정, 문서, 작업의 관계를 에이전트에 제공한다. 에이전트가 일을 이해하는 데 필요한 맥락과 실제로 읽거나 수정할 수 있는 범위는 별개의 문제다. Admin Hub의 관리 설정, Atlassian Guard, 데이터 보호 정책은 접근 범위를 정하고 감사 기록은 수행한 행동을 되짚는 수단으로 제시됐다. 조직의 정보를 폭넓게 연결하더라도 허용된 행동까지 자동으로 넓어지는 구조는 아니다.

감사 기록의 실무적 가치는 작업의 결과와 수행 주체를 함께 남기는 데 있다. Jira 항목이 바뀌었다는 사실만으로는 사람이 직접 수정했는지, 에이전트가 사람의 권한으로 실행했는지, 별도 에이전트 계정이 행동했는지 알기 어렵다. 실행 주체와 호출한 사람, 작업 대상이 연결되면 팀은 변경 이후의 검토와 설명을 같은 기록에서 이어갈 수 있다.

MCP는 연결 경로, AMP는 협업의 범위

Atlassian MCP는 외부 AI 도구와 코딩 에이전트가 Atlassian의 도구와 맥락에 접근하는 연결 경로다. AMP는 그 경로를 포함해 에이전트가 팀 작업에 어떻게 나타나고, 어느 권한으로 행동하며, 기여를 어떻게 남길지를 다룬다. MCP로 데이터와 도구에 연결한 것만으로 작업 화면의 존재감이나 에이전트별 소유 관계가 자동으로 정해지는 것은 아니다.

예를 들어 외부 코딩 에이전트가 Jira의 작업 정보를 읽을 수 있다면 연결은 성립한다. 그 세션이 어느 작업 항목에 속하는지 팀에 보이고, 수정 결과가 누구의 요청에서 나왔는지 식별되며, 허용된 범위 안에서 행동하는지는 다른 계층의 문제다. AMP가 Jira 보드의 에이전트 세션과 권한 관리, 감사 기록을 함께 설명하는 이유가 여기에 있다.

이름에 ‘Protocol’이 들어가지만 공개된 AMP 설명은 협업 경험과 플랫폼 기능의 묶음에 초점을 둔다. MCP처럼 외부 개발자가 독립적으로 구현할 수 있는 전송 명세를 중심으로 소개하지는 않는다. 따라서 AMP를 도입한다는 말은 단일 통신 규격을 연결한다는 뜻보다, 에이전트의 작업을 Atlassian의 공유 공간과 관리 체계에 배치한다는 뜻으로 읽는 편이 정확하다.

외부 에이전트까지 포괄한다는 점은 이 구분을 더 중요하게 만든다. 에이전트가 Atlassian 안에서 만들어졌는지 밖에서 실행됐는지와 관계없이, 팀은 같은 작업의 진행 상태를 보고 기여 주체를 알아야 한다. 반면 외부 도구가 접근할 수 있는 정보와 실행할 수 있는 행동은 연결 자체가 아니라 사람의 권한과 조직의 정책으로 제한돼야 한다.

전용 계정과 관리 화면은 제공 상태를 나눠 봐야 한다

AMP의 제품 소개에는 에이전트가 사람의 권한으로 실행되거나 전용 에이전트 계정으로 실행되는 방식이 제시돼 있다. 다만 Atlassian은 플랫폼 발표문에서 에이전트 계정과 비인간 신원 목록을 통한 접근 제어를 곧 추가할 기능으로 설명했다. 소개된 실행 모델과 모든 조직의 관리자가 현재 사용할 수 있는 설정 범위를 동일하게 볼 수는 없다.

사람의 권한으로 실행되는 에이전트는 그 사람에게 허용된 정보와 행동에 영향을 받는다. 별도 계정으로 실행하는 방식에서는 에이전트 자체에 맡길 작업과 접근 범위를 정하는 것이 핵심이다. 어느 방식인지가 기록에 분명히 남아야 같은 변경이라도 ‘누가 지시했는가’와 ‘무엇이 실제로 행동했는가’를 나눠 파악할 수 있다.

비인간 신원 목록은 에이전트뿐 아니라 앱과 서비스 계정도 관리 대상에 올리려는 계획과 이어진다. 여러 도구가 하나의 사람 계정을 공유하면 활동 주체와 권한을 분리해 보기 어렵다. 에이전트별 신원과 접근 정책을 한곳에서 관리하고 필요할 때 접근을 철회할 수 있다면, 팀의 작업 화면에 보이는 활동을 관리자의 통제와 연결할 수 있다.

한국의 Jira·Confluence 운영 조직에도 변화의 기준은 기능 이름보다 기록의 연결 정도다. 개인이 AI에 요청한 뒤 완성된 결과만 문서에 옮기는 흐름에서는 동료가 중간 작업과 책임 주체를 파악하기 어렵다. 에이전트가 작업 항목 안에 나타나고 수정 이력에 식별된다면, 여러 사람이 이어서 처리하는 개발·프로젝트 관리 업무에서 검토할 근거가 더 구체적으로 남는다.

현재 발표가 보여주는 것은 협업 화면, 연결 기술, 신원과 거버넌스를 하나의 방향으로 묶은 설계다. 전용 계정과 비인간 신원 관리가 실제 관리자 설정으로 제공되면, 팀은 Jira에서 보이는 에이전트 활동을 별도 접근 정책과 감사 이력까지 이어서 관리할 수 있게 된다.

함께 읽기: