MCP 실무 활용법 — Jira를 Claude에 붙일 때 알아야 할 것들

MCP가 뭔지부터 쉽게 풀고, Jira를 Claude에 붙이면 어떤 작업 단계가 사라지는지, 어디서 막히는지, 2026년 6월 SSE 종료 이후 달라진 연결 방식까지 공식 문서 기준으로 정리했습니다.

AI에게 업무를 시키려면, 늘 같은 절차가 필요했습니다. Jira 이슈를 복사하고, 회의록을 붙여넣고, “이 내용 바탕으로 정리해줘”라고 부탁하는 것. AI는 똑똑하지만 내 업무 상황을 전혀 모르니까요.

MCP는 바로 그 ‘복붙 노동’을 없애는 표준입니다. 연결 자체는 어렵지 않습니다. 정작 막히는 건 그 다음입니다 — 붙이고 나면 어떤 작업에 써야 할지, 왜 인증이 자꾸 풀리는지가 대부분의 가이드에서 빠져 있습니다.

이 글은 MCP가 뭔지 모르는 분도 읽을 수 있게 개념부터 풀고, Jira를 대표 사례로 삼아 어떤 작업 단계가 실제로 사라지는지와 어디서 막히는지를 MCP 공식 사양과 Atlassian 공식 문서 기준으로 정리했습니다. 막연한 ‘좋다/나쁘다’가 아니라, 구조적으로 무엇이 달라지는지를 담았습니다.

개념부터 쉽게

MCP가 뭐길래 — 60초로 이해하기

MCP는 ‘Model Context Protocol’의 약자입니다. 이름은 어렵지만, 비유 하나면 끝납니다.

MCP는 ‘AI를 위한 USB-C 포트’입니다.

예전에는 기기마다 충전 단자가 제각각이라 케이블을 여러 개 들고 다녔죠. USB-C가 표준이 되면서 하나로 통일됐고요. AI와 도구의 연결도 똑같았습니다. AI가 Jira를 쓰려면 Jira용 연결을, 파일을 읽으려면 파일용 연결을 — 매번 따로 만들어야 했어요. MCP는 그 연결 방식을 하나의 표준 규격으로 통일한 겁니다. 표준 포트가 생기니, AI가 내 도구에 ‘직접 꽂히는’ 게 가능해졌습니다.

그래서 뭐가 달라지나

핵심은 한 문장입니다. AI가 내 일을 ‘말로 거드는’ 단계에서, 내 실제 도구를 직접 읽고 손대는 단계로 넘어갑니다.

MCP 이전의 Claude는 사용자가 붙여넣은 텍스트만 보고 조언했습니다. MCP를 붙인 Claude는 Jira에 직접 접근해 이슈를 검색하고, 요약하고, 새 이슈를 만들고, 상태를 바꿉니다. ‘복붙해서 물어보는 AI’와 ‘내 업무 도구를 직접 만지는 AI’의 차이 — 이게 실무에서 체감되는 지점입니다.

구조는 간단히만 짚겠습니다. 내가 쓰는 AI 앱(예: Claude Desktop)이 ‘클라이언트’, 도구 쪽(Jira·파일 등)을 담당하는 연결 프로그램이 ‘MCP 서버’입니다. 둘이 표준 규격으로 대화합니다. 자세한 구조는 몰라도 쓰는 데 지장 없습니다.

MCP로 붙일 수 있는 것들 (그리고 이 글이 Jira를 고른 이유)

MCP 서버는 도구마다 따로 나와 있습니다. 대표적으로:

• 파일시스템 — 로컬 문서·폴더를 직접 읽고 정리
• GitHub — 이슈·PR·코드 검색과 작성
• Slack — 메시지 검색·요약·전송
• 데이터베이스 — 자연어로 질의하고 결과 받기
• Jira·Confluence — 이슈·문서 검색·요약·생성

즉 MCP는 특정 도구의 기능이 아니라, ‘내가 쓰는 도구들에 AI를 표준으로 꽂는 방식’ 전체를 가리킵니다. 이 글은 그중 공식 문서와 트러블슈팅 자료가 가장 잘 정리되어 있는 Jira를 대표 사례로 풀되, 거기서 나온 원칙이 다른 서버에도 어떻게 적용되는지를 함께 짚겠습니다. 일반 원리를 먼저 말하고, Jira로 구체화하는 방식입니다.

도입 판단 기준

누구에게 권하고, 누구에겐 말리나

판단 기준부터 말하면 ‘조건부 권장’입니다. MCP는 잘 설계된 표준이지만, 모든 업무에 맞지는 않습니다. 특정 도구가 아니라 ‘내 업무에 반복이 있는가’가 기준입니다. 자기 상황을 아래 표에 대입해 보세요.

이런 분께 권합니다	이런 분은 보류하세요
같은 검색·정리·생성을 반복하는 도구가 있다(Jira·문서·코드·DB 등)	그런 반복 작업이 거의 없다
복붙·창 전환 노동이 업무의 큰 비중이다	1초의 지연도 안 되는 실시간성이 핵심이다
초기 2~3주의 설정·인증 삽질을 ‘투자’로 볼 여유가 있다	지금 당장 안정적으로 굴러가야 하고 삽질할 시간이 없다
연결할 도구의 관리자와 권한·허용 설정을 협의할 수 있다(사내 도구라면)	관리자 승인이 막혀 있고 우회가 불가능하다

한 줄로 줄이면 — 반복적인 도구 작업이 많고 초기 세팅을 견딜 수 있다면 가치가 큽니다. 반대라면 지금은 보류가 맞아요. 아래부터는 Jira를 예로 들어, 어떤 단계가 실제로 사라지는지 풀겠습니다.

대표 사례

Jira를 Claude에 붙이면 달라지는 것 (Before / After)

이제 대표 사례입니다. Jira로 보여드리지만, 핵심 흐름 — 한 문장 부탁 → AI가 도구를 직접 호출 → 초안 회수 — 은 GitHub·파일시스템 등 다른 MCP 서버에도 그대로 적용됩니다.

가장 흔한 작업 하나로 설명하겠습니다. 스탠드업 전에 ‘내가 맡은 진행 중 이슈’를 정리하는 일입니다. 구체적으로는 — 현재 스프린트에서 나에게 할당됐고 아직 끝나지 않은 이슈를 모아, 상태별로 묶고, 각각 한 줄 요약을 붙여 보고용 초안을 만드는 것입니다.

Before — MCP 없이

1. Jira에 로그인해 보드를 엽니다.
2. JQL을 직접 작성합니다 — assignee = currentUser() AND sprint in openSprints() AND status != Done. (JQL이 익숙하지 않으면 여기서부터 막힙니다.)
3. 결과 목록을 보고, 이슈를 하나씩 클릭해 상태와 최근 코멘트를 확인합니다.
4. 확인한 내용을 문서로 옮겨 적고, 손으로 요약합니다.
5. 보고 형식에 맞게 다듬습니다.

이슈가 8~10개쯤 되면 창 전환이 반복되고, 작업의 대부분이 단순 옮겨적기가 됩니다.

After — MCP로

Claude에게 한 문장으로 부탁합니다.

이번 스프린트에서 나한테 할당된 미완료 이슈를
상태별로 묶고, 각각 한 줄 요약해서
스탠드업 보고용으로 정리해줘.

그러면 Claude가 내부적으로 jira_jql_search 도구를 호출해 위 JQL에 해당하는 목록을 직접 가져오고, 상태별로 묶어 요약 초안까지 만들어 줍니다. JQL을 외울 필요도, 이슈를 일일이 클릭할 필요도 없어집니다.

물론 초안이 그대로 쓸 만한 상태로 나오지는 않습니다. 요약 톤을 손보거나 빠진 맥락을 더하는 과정은 남습니다. 달라지는 건 시작점입니다 — ‘빈 화면에서 시작’이 아니라 ‘초안에서 다듬기’가 됩니다. 절감 폭은 이슈 개수·보고 형식·검수 기준에 따라 크게 달라지므로, 구체적인 수치는 각자 환경에서 직접 재보는 편이 정확합니다.

트러블슈팅

자주 보고되는 오류와 해결 방법

좋은 점만 적으면 반쪽짜리입니다. Atlassian 공식 트러블슈팅 문서와 커뮤니티에 반복적으로 올라오는 문제를 증상·원인·조치로 정리했습니다. 아래는 OAuth로 연결하는 MCP 원격 서버(Jira·GitHub·Slack 등)에 공통으로 나타나는 오류이며, 예시는 Jira 기준입니다.

증상	원인	조치
잘 쓰다가 몇 시간 뒤 “인증이 필요합니다”가 뜬다	OAuth/SSE 방식은 세션이 주기적으로 만료됨	재인증은 임시 조치. 근본적으로는 Streamable HTTP 엔드포인트 + API 토큰 인증으로 전환(아래 참고)
연결한 도구가 아예 목록에 안 뜬다	커넥터 연결 실패 또는 관리자가 해당 클라이언트를 차단	커넥터 재연결 + 사내 도구라면 관리자에게 허용 도메인 확인
연결은 됐는데 동작이 이상하거나 옛 필드가 나온다	구버전 커뮤니티 서버를 잘못 물림	공식 서버로 교체(Jira라면 Atlassian Rovo)
“그 데이터를 못 찾았다”고 한다	내 계정에 해당 데이터(프로젝트·레포·채널) 접근 권한이 없음	AI 문제가 아님 — 내 계정 권한부터 확인
큰 검색이 중간에 끊긴다	한 번에 너무 많은 항목을 요청	조건을 좁혀(기간·상태·범위 한정) 나눠 요청

경계 긋기

잘 맞는 작업 vs 시간 낭비, 그 경계의 이유

어떤 작업은 분명히 빨라졌고, 어떤 작업은 오히려 더 번거로웠습니다. 중요한 건 ‘왜’ 그 선이 그어지는가예요. 두 가지 원리로 설명됩니다.

원리 1 — 권한은 딱 내 계정만큼

에이전트는 연결한 계정의 권한을 그대로 물려받습니다. 내가 못 보는 데이터(프로젝트·레포·채널)는 AI도 못 봅니다. 그래서 ‘내 권한 안에서 끝나는 작업’은 잘 되고, ‘다른 팀 비공개 데이터까지 긁어와야 하는 작업’은 애초에 불가능합니다. 이건 결함이 아니라 보안 설계입니다. (어떤 MCP 서버든 OAuth로 붙이면 동일합니다.)

원리 2 — 검색·정리엔 강하고, 실시간·시각 작업엔 약하다

Jira를 예로 들면 이렇게 갈립니다(패턴은 다른 서버도 비슷합니다).

잘 맞는 작업:

• JQL 검색·필터링을 말 한마디로 대체 (가장 강력)
• 여러 이슈를 묶어 요약·보고 초안 만들기
• 같은 형식의 이슈 여러 개를 한 번에 생성
• 여러 이슈에 코멘트 일괄 작성

안 맞는 작업:

• 상태가 초 단위로 중요한 실시간 작업 (인증 지연·재인증 리스크)
• 여러 단계를 거치는 복잡한 워크플로 자동화 (중간에 끊기면 어디까지 됐는지 추적이 번거로움)
• 보드 드래그처럼 눈으로 확인하는 작업 — 그냥 Jira UI가 빠름

요컨대 ‘읽고-검색하고-만들고-요약’하는 정적인 작업엔 강하고, ‘실시간·다단계·시각적’인 작업엔 약합니다. 이 경계만 알아도 헛수고를 크게 줄일 수 있어요.

솔직한 한계

기대와 다른 지점 — MCP가 못 하는 일

기대만큼 되지 않는 영역도 분명합니다. 이 부분을 먼저 알고 시작하면 헛수고를 줄일 수 있습니다.

첫째, ‘모든 걸 Claude에서 처리하기’는 현실적이지 않습니다. 보드를 눈으로 훑거나 드래그로 상태를 옮기는 작업은 원래 UI가 압도적으로 빠릅니다. 도구를 대체하는 방향이 아니라, 반복 작업만 떼어내는 방향이 맞습니다.

둘째, ‘하루 종일 켜두고 자동으로 굴리기’도 권하기 어렵습니다. 인증 세션이 주기적으로 만료되는 구조라 장시간 무인 자동화에는 맞지 않습니다. ‘필요할 때 불러 쓰는 비서’ 쪽으로 쓰임을 한정하는 편이 안정적입니다.

이 두 가지는 제품의 결함이라기보다 기대치를 현실에 맞추는 문제입니다. 그리고 이 원칙은 Jira만이 아니라 어떤 MCP 서버에도 똑같이 적용됩니다 — AI에 도구를 통째로 넘기지 말고, 반복되는 한두 작업만 떼어내는 것.

권장 셋업 + 2026 변경점

권장 셋업, 그리고 SSE 종료 이후의 연결 방식

권장 셋업은 단순합니다. 공식 Atlassian Rovo 원격 MCP 서버 + Claude 조합에, 반복 빈도가 높은 작업 한두 개만 고정으로 태우는 방식입니다. 연결 대상을 늘릴수록 인증·권한 문제가 함께 늘어나므로, 범위를 좁게 잡는 편이 안정적입니다.

지금 시작한다면 — 전송 방식부터 확인

여기서 흔히 혼동되는 것이 전송 방식(transport)과 인증 방식(auth)입니다. 둘은 별개이고, 2026년에 바뀐 건 전송 방식 쪽입니다. Atlassian은 기존 HTTP+SSE 전송(https://mcp.atlassian.com/v1/sse)을 폐기하고, 공식 공지를 통해 2026년 6월 30일까지만 하위 호환으로 유지한다고 밝혔습니다. 그 날짜는 이미 지났으므로, 지금 기준으로는 Streamable HTTP 엔드포인트(https://mcp.atlassian.com/v1/mcp)를 써야 합니다.

API 토큰 인증에는 제약도 있습니다. Atlassian 문서 기준으로 OAuth 대비 사용 가능한 도구가 줄어들 수 있고, 토큰이 특정 사이트에 묶이지 않아 클라이언트가 cloudId를 직접 넘겨야 합니다. 참고로 이 6월 30일 시한은 Atlassian(Jira·Confluence) 한정이지만, ‘전송·인증 방식이 안정성을 좌우한다’는 원칙 자체는 모든 원격 MCP 서버에 통합니다.

비개발자도 되나요?

설정을 한 번 만지는 정도는 필요하지만, 코드를 짤 줄 알아야 하는 건 아닙니다. 다만 개인 API 토큰 방식은 email:api_token을 Base64로 인코딩해 Authorization 헤더에 넣어야 하므로, 설정 파일을 직접 편집하는 단계는 거쳐야 합니다. 원클릭으로 끝나는 수준은 아니라고 보는 편이 정확합니다.

자주 묻는 질문

FAQ