MCP 실무 활용법: Jira를 Claude에 붙여 3개월 써본 솔직한 정리

MCP가 뭔지부터 쉽게 풀고, 실제로 Jira를 Claude에 붙여 3개월간 업무에 써본 기록. 무엇이 빨라졌고, 어디서 막혔고, 6월 30일 이후 꼭 알아야 할 변화까지 정리했습니다.

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

MCP는 바로 그 ‘복붙 노동’을 없애는 기술입니다. 설치 자체는 5분이면 끝나요. 문제는 그 다음이었습니다 — 깔고 나면 뭘 어디에 써야 할지, 왜 자꾸 인증이 풀리는지, 대부분의 가이드가 다루지 않는 부분이었거든요.

이 글은 MCP가 뭔지 모르는 분도 읽을 수 있게 개념부터 쉽게 풀고, 실제로 제가 Jira를 Claude에 붙여 3개월간 업무에 써본 기록을 정리했습니다. 막연한 ‘좋다/나쁘다’가 아니라, 구체적으로 무엇이 어떻게 바뀌었는지를 담았어요.

개념부터 쉽게

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를 표준으로 꽂는 방식’ 전체를 가리킵니다. 이 글은 그중 제가 3개월간 가장 깊이 써본 Jira를 대표 사례로 풀되, 거기서 얻은 교훈이 다른 서버에도 어떻게 적용되는지를 함께 짚겠습니다. 일반 원리를 먼저 말하고, Jira로 증명하는 식이에요.

3개월 후의 판정

결론부터: 누구에게 권하고, 누구에겐 말리나

3개월 써보고 내린 결론은 ‘조건부 권장’입니다. MCP 자체는 훌륭하지만, 모두에게 맞지는 않았어요. 특정 도구가 아니라 ‘내 업무에 반복이 있는가’가 기준입니다. 자기 상황을 아래 표에 대입해 보세요.

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

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

실제 사례

내가 Jira를 Claude에 붙여 한 일 (Before / After)

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

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

Before — MCP 없이 (제 기준 약 25분)

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

이슈가 8~10개쯤 되면 창 전환만 수십 번이고, 단순 옮겨적기가 대부분이었습니다.

After — MCP로 (제 기준 약 4분)

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

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

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

물론 초안이 100% 완벽하진 않습니다. 요약 톤을 손보거나 빠진 맥락을 한두 줄 더하죠. 그래도 ‘0에서 시작’이 아니라 ‘80%에서 다듬기’라, 체감 시간이 25분에서 4분 안팎으로 줄었습니다.

트러블슈팅

3개월간 막혔던 오류와 정확한 해결

좋은 점만 말하면 거짓말이죠. 실제로 막혔던 지점과 제가 어떻게 빠져나왔는지를 증상·원인·조치로 정리했습니다. 아래는 OAuth로 연결하는 MCP 원격 서버(Jira·GitHub·Slack 등) 공통 오류이고, 예시와 빈도는 제가 가장 많이 겪은 Jira 기준입니다.

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

경계 긋기

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

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

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

에이전트는 제 로그인 권한을 그대로 물려받습니다. 제가 못 보는 데이터(프로젝트·레포·채널)는 AI도 못 봐요. 그래서 ‘내 권한 안에서 끝나는 작업’은 잘 되고, ‘다른 팀 비공개 데이터까지 긁어와야 하는 작업’은 애초에 불가능합니다. 이건 한계라기보다 보안 설계예요 — 오히려 안심되는 부분이고요. (어떤 MCP 서버든 OAuth로 붙이면 동일합니다.)

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

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

잘 맞았던 작업:

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

안 맞았던 작업:

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

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

솔직한 한계

내가 끝내 포기한 것들

기대했지만 접은 것도 있습니다. 솔직히 적는 게 이 글의 신뢰를 지키는 길이라 생각해요.

첫째, ‘모든 걸 Claude에서 처리하기’는 포기했습니다. 초반엔 Jira를 아예 안 열고 다 Claude로 하려 했는데, 보드를 눈으로 훑거나 드래그로 상태를 옮기는 건 UI가 압도적으로 빨랐어요. 도구를 대체하는 게 아니라, 반복 작업만 떼어내는 쪽으로 방향을 틀었습니다.

둘째, ‘하루 종일 켜두고 자동으로 굴리기’도 접었습니다. 인증이 주기적으로 풀리는 구조라(4번 참고) 장시간 무인 자동화엔 아직 안 맞았어요. 그래서 ‘필요할 때 불러 쓰는 비서’로 쓰임을 한정했습니다.

이 두 가지는 기능의 한계라기보다, 제 기대를 현실에 맞춘 과정이었어요. 그리고 이 교훈은 Jira만이 아니라 어떤 MCP 서버에도 똑같이 적용됩니다 — AI에 도구를 통째로 넘기지 말고, 반복되는 한두 작업만 떼어내라는 것.

최종 정착 + 2026

지금 내 워크플로, 그리고 6월 30일 이후의 변화

3개월 뒤 제 셋업은 단순합니다. 공식 Atlassian(Rovo) 원격 MCP 서버 + Claude, 그리고 ‘월요일 스탠드업 정리’와 ‘반복 이슈 생성’ 두 작업만 고정으로 씁니다. 욕심을 줄이니 오히려 안정적이었어요.

지금 시작한다면 — 인증 방식이 핵심

여기가 이 글에서 가장 시의성 있는 부분입니다. 기존 OAuth/SSE 방식은 편하지만 세션이 자주 풀립니다. 그리고 그 SSE 엔드포인트가 2026년 6월 30일 이후 종료됩니다. 즉, 지금 SSE 방식으로 쓰고 있다면 곧 연결이 막혀요.

제가 처음부터 알았다면 OAuth/SSE로 한 달을 고생하지 않았을 겁니다. 지금 시작하는 분은 이 함정을 건너뛸 수 있어요. 참고로 이 6월 30일 시한은 Atlassian(Jira·Confluence) 한정이지만, ‘인증 방식이 안정성을 좌우한다’는 원칙 자체는 모든 원격 MCP 서버에 통합니다.

비개발자도 되나요?

설정을 한 번 만지는 정도는 필요하지만, 코드를 짤 줄 알아야 하는 건 아닙니다. API 토큰을 발급받아 커넥터에 넣는 과정 정도는 감수해야 해요. 요즘은 원클릭 확장으로 더 쉬워진 영역도 있지만, Jira 공식 서버는 아직 인증 설정을 직접 거치는 편입니다.

자주 묻는 질문

FAQ