Linear MCP 사용 가이드: AI 연동부터 이슈 관리 자동화까지

Linear MCP 서버 주소와 인증 방식

호스팅된 서버에 웹으로 연결하는 Streamable HTTP 방식으로 https://mcp.linear.app/mcp를 사용합니다. 대화형 설정에서는 동적 클라이언트 등록을 지원하는 OAuth 2.1이 클라이언트 등록과 사용자 승인을 처리합니다. 또는 Authorization: Bearer <yourtoken>에 OAuth 토큰이나 Linear API 키를 넣어 요청할 수도 있습니다. Linear MCP 설정 안내

MCP는 여러 어시스턴트가 공통으로 이용하는 서비스 창구라고 생각하면 됩니다. 어시스턴트가 이슈 검색이나 변경 사항 저장처럼 이름이 정해진 작업을 요청하면, Linear 서버는 해당 연결에 허용된 작업을 실행합니다. 프롬프트는 무엇을 할지 전달할 뿐, 추가 권한을 부여하지는 않습니다.

각 방식은 연결의 접근 범위를 제한하는 수단입니다. 프롬프트에 “수정하지 마세요”라고 쓰면 어시스턴트에 지시를 내리는 것이고, 읽기 전용 엔드포인트나 인증 정보를 쓰면 실제로 수행할 수 있는 작업 자체가 제한됩니다. Linear의 접근 권한 옵션

팀에서 쓰는 AI 클라이언트에 연결하기

Claude와 Claude Code

Claude 웹 또는 데스크톱 앱에서 **설정(Settings) → 커넥터(Connectors)**를 열고 Linear를 연결합니다. Linear의 Claude 연동 페이지에서 안내하는 경로입니다.

Claude Code에서는 다음과 같이 설정합니다.

1. 터미널에서 claude mcp add --transport http linear-server https://mcp.linear.app/mcp를 실행합니다.
2. Claude Code 세션을 엽니다.
3. /mcp를 실행하고 인증 절차를 완료합니다.

명령어와 후속 절차 모두 Linear의 Claude 설정 안내에 나와 있습니다.

Cursor

Linear의 기본 안내 문서는 설치 링크를 제공하며, Cursor의 MCP 툴 페이지에서 Linear를 찾도록 안내합니다. Linear 문서의 Cursor 항목에 있는 설치 링크를 이용하면 됩니다.

별도의 Cursor 연동 페이지에서는 다음 수동 설정 방법도 안내합니다.

1. Ctrl/Cmd + Shift + J를 눌러 Cursor 설정을 엽니다.
2. MCP를 선택합니다.
3. Add new global MCP server를 선택합니다.
4. 다음 설정을 추가합니다.

{
  "mcpServers": {
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.linear.app/mcp"]
    }
  }
}

이 설정은 클라이언트와 호스팅된 서버 사이를 연결하는 mcp-remote를 사용합니다. Linear의 Cursor 연동 페이지에 게시된 설정입니다.

Codex CLI와 IDE 확장 프로그램

Linear에 따르면 CLI와 IDE 확장 프로그램은 MCP 설정을 공유합니다.

1. codex mcp add linear --url https://mcp.linear.app/mcp를 실행합니다.
2. 설정 안내에 설명된 Linear 로그인 절차를 따릅니다.
3. 수동으로 설정할 경우, Linear는 ~/.codex/config.toml을 편집한 뒤 codex mcp login linear로 인증하도록 안내합니다.

설정을 복사하기 전에 문서 간 차이를 확인해야 합니다.

Codex 전용 페이지의 수동 서버 설정은 [mcp_servers.linear] 아래에 url = "https://mcp.linear.app/mcp"를 넣는 형태입니다. 여기에는 게시된 설정을 그대로 옮겼지만, 서로 다른 두 기능 플래그를 현재 모든 환경에 필요한 공통 전제 조건으로 보아서는 안 됩니다. Linear의 Codex 연동 안내, 기본 MCP 안내 문서

위에서 설명한 추가·로그인 절차를 사용하면 됩니다. OpenAI의 현재 MCP 안내 문서는 두 기능 플래그를 요구하지 않고 HTTP 서버 설정과 codex mcp login <server-name>을 안내합니다. OpenAI 공식 MCP 문서

ChatGPT

Linear가 실제로 문서에 안내한 절차는 다음과 같습니다.

1. Linear의 ChatGPT 연동 페이지에 있는 링크로 ChatGPT의 커넥터 설정을 엽니다.
2. Linear를 연결합니다.
3. 심층 리서치에서 Linear를 소스로 추가합니다.

Linear는 이 연결을 기존 사용자별 권한을 유지하면서 이슈, 프로젝트, 논의를 참조하는 방법으로 설명합니다. 이 설정을 통한 이슈 생성이나 수정은 문서에 명시되어 있지 않습니다. 리서치와 요약에 활용하고, 아래의 편집 예제에는 쓰기를 지원한다고 문서에 명시된 MCP 클라이언트를 사용합니다. 이는 해당 연결 방식의 범위를 구분하는 설명이며, 모든 ChatGPT 연동에 일괄적으로 적용되는 주장은 아닙니다.

Linear가 공개한 MCP 툴과 역할

툴은 맥락을 조회하는 것과 변경 사항을 저장하는 것으로 나누어 보면 이해하기 쉽습니다. 아래는 Linear가 공개한 자주 사용하는 툴 목록의 식별자와 각 용도입니다. 이 목록은 Slack 연동 페이지에서 동일한 Linear MCP 서버를 Slackbot에 연결하는 항목에 나옵니다. Linear의 툴 목록

Linear의 변경 내역에는 list_cycles, list_issue_labels, list_comments, save_project, save_document도 등장합니다. 사이클 세부 정보, 페이지 단위의 라벨·댓글 조회, 프로젝트 변경, 이니셔티브나 사이클 아래에 문서를 생성하거나 문서의 상위 항목을 바꾸는 기능이 문서화되어 있습니다. 이는 관련 툴을 공개 문서에서 모아 정리한 목록이며, 모든 클라이언트가 개수까지 동일한 고정 툴 목록을 제공한다는 뜻은 아닙니다. 사이클·라벨 툴, 댓글 툴, 프로젝트·문서 툴

오래된 예제에서는 create_issue와 update_issue를 별도로 호출할 수 있습니다. Linear는 이 둘을 **save_issue**로 통합했습니다. 예전 프롬프트를 복사하거나 툴 이름을 기준으로 기능을 구현할 때 이 변경을 반영해야 합니다. Linear의 툴 변경 안내

접근 권한의 범위와 관리자 통제

이 연결은 승인을 받아 워크스페이스 데이터에 접근하는 통로입니다. Linear의 OAuth 용어에서 read는 “사용자 계정에 대한 읽기 접근 권한”, write는 “사용자 계정에 대한 쓰기 접근 권한”을 뜻합니다. 기본 사용자 실행 주체는 앱을 승인한 사람의 명의로 리소스를 생성합니다. Linear OAuth 권한

API 키에 대해 Linear는 “해당 사용자가 접근할 수 있는 데이터에 대한 전체 접근 권한”을 제공하며, 권한과 팀을 제한할 수 있다고 설명합니다. 따라서 접근을 제한한 키와 광범위한 권한을 가진 개인 키 사이에는 실질적인 차이가 있습니다. API 키 권한

통제 방법은 연결의 인증 방식에 따라 달라집니다.

Linear는 앱 승인의 목적을 “워크스페이스와 그 데이터에 접근할 수 있는 앱을 통제하는 것”이라고 설명합니다. 멤버는 설치 과정에서 승인을 요청할 수 있습니다. 키에 대한 통제는 API 키 인증에 적용되며, OAuth 앱 연결을 관리하는 절차를 대신하지는 않습니다. 앱 승인, API 관리

Okta SAML을 사용하는 Enterprise 워크스페이스는 지원되는 Anthropic 클라이언트에 대해 기업 관리형 인증을 사용할 수 있습니다. Linear에 따르면 이 방식은 “기존 Linear 권한을 적용”합니다. 연결마다 사용자가 별도로 승인하게 하는 대신, 관리자가 Okta를 통해 접근을 관리합니다. 기업 관리형 인증

진행 상황만 파악하는 워크플로라면 읽기 전용 접근을 선택합니다. 이슈 분류나 생성에는 필요한 쓰기 권한을 부여하되, 적용 전에 변경 제안을 확인할 수 있게 합니다. 이 검토 단계는 권장하는 업무 절차이며, 모든 클라이언트가 동일한 승인 동작을 강제한다는 뜻은 아닙니다.

실무에 활용할 만한 워크플로 세 가지

쓰기 권한 없이도 가능한 사이클 보고부터 시작합니다. 반복적인 이슈 접수가 많다면 다음 단계로 분류 작업을 도입합니다. 명세서를 이슈로 옮기는 작업은 리드가 이미 확정된 결정을 티켓으로 정리하는 데 시간을 쓰고 있을 때 효과가 있습니다.

아래 예제는 가상의 상황을 바탕으로 구성했습니다. 프롬프트와 기대할 수 있는 결과물의 형태를 보여 주며, 실제 로그인한 환경에서 테스트한 결과는 아닙니다.

새 이슈를 분류하고 검토할 변경안 만들기

엔지니어링 리드는 어시스턴트에게 새로 들어온 제보를 살펴보고, 유사한 기존 이슈를 조회한 뒤, 변경안을 한데 모아 제시하도록 요청할 수 있습니다. 검색과 속성 편집을 반복하는 수고를 줄이면서도 담당자와 우선순위에 대한 결정은 리드가 맡습니다.

입력 예시: 새로 접수된 “내보내기 버튼을 누르면 멈춤” 이슈에는 필터를 적용해 내보내는 동안 브라우저가 응답하지 않는다고 적혀 있습니다. 기존 이슈인 “필터를 적용한 내보내기가 끝나지 않음”도 같은 화면을 설명합니다. 또 다른 제보인 “초대 메일이 도착하지 않음”에는 전송 로그나 재현 절차가 없습니다.

프롬프트:

검토에 도움이 되는 제안 예시:

검토 후 리드는 합의된 라벨과 담당자 변경만 save_issue로 적용하도록 승인하고, 판단이 모호한 제보는 그대로 둘 수 있습니다. 어시스턴트는 영향을 받은 이슈 링크와 변경한 필드의 기록을 반환해야 합니다. 조회와 저장 작업은 Linear의 툴 목록에 나와 있습니다.

별도의 분류 시스템을 만들기 전에 Triage Intelligence와 비교해 봅니다. Linear는 이미 속성 제안과 중복·연관 관계 감지 기능을 제공합니다. 기본 워크플로에서 다루는 범위를 넘어선 맥락이나 규칙이 판단에 필요할 때 맞춤형 MCP 워크플로를 구성할 이유가 생깁니다. Triage Intelligence

요구사항을 지어내지 않고 명세서를 이슈로 전환하기

창업자는 승인된 기능 명세를 바탕으로 이슈 초안을 만들고, 검토를 마친 항목을 Linear에 등록할 수 있습니다. 이 방식의 장점은 일관성입니다. 각 티켓에 근거가 된 요구사항이 담기고, 아직 결정하지 않은 부분도 드러납니다.

명세 예시: “워크스페이스 관리자는 이메일로 멤버를 초대할 수 있습니다. 초대받은 사람은 이메일 링크로 초대를 수락합니다. 관리자는 수락 대기 중인 초대를 취소할 수 있습니다. 결제 변경과 일괄 초대는 범위에 포함하지 않습니다.”

프롬프트:

이슈 분할 제안:

미결 질문: 이미 멤버인 사람의 이메일 주소로 초대하면 어떻게 처리할까요? 초대에 유효 기간이 있나요? 초대를 취소한 뒤 수신자가 링크를 열면 무엇을 보여 줄까요? 제품 책임자가 결정하기 전까지는 질문으로 남겨 둡니다.

승인을 받으면 어시스턴트는 상위·하위 이슈를 생성하고 URL을 반환하며, 생성하지 못한 항목이 있으면 알려 줄 수 있습니다. 하위 이슈 생성은 문서에 명시된 MCP 기능입니다. Linear MCP 변경 내역

어시스턴트는 결정된 내용을 옮겨 적습니다. 제품에 대한 결정은 여전히 제품 책임자의 몫입니다.

사이클 데이터를 바탕으로 주간 보고 작성하기

리드는 사이클의 작업 내역을 바탕으로 각 설명의 근거 링크가 붙은 진행 상황 초안을 만들 수 있습니다. 흩어진 이슈 업데이트를 검증 가능한 보고서로 정리하는 과정이 짧아집니다.

주간 보고와 사이클 요약은 다루는 기간이 다를 수 있습니다. 팀, 사이클, 보고 기간을 명시해 “이번 사이클에 완료”가 어느새 “이번 주에 완료”로 바뀌지 않게 해야 합니다.

자료 예시: “초대 이메일”은 보고 기간 안에 완료(Done)로 표시되었습니다. “초대 수락”은 진행 중(In Progress) 상태입니다. “초대 취소”의 댓글에는 취소된 링크를 열었을 때의 동작에 대한 제품 결정을 기다리느라 구현이 멈춰 있다고 적혀 있습니다.

프롬프트:

초안 예시:

실제 초안에서는 문장마다 해당 이슈 URL을 붙여야 합니다. 이 예제는 의도적으로 완료율이나 출시 여부를 단정하지 않습니다. 사이클·이슈·댓글 조회 기능이 이 워크플로에 필요한 자료를 제공합니다. 사이클·이슈 툴, 댓글 조회

기본 워크플로가 자리 잡은 뒤 확장할 수 있는 업무

댓글 생성은 서버의 문서화된 기능에 포함되며, 프로젝트 툴은 인수인계에 필요한 맥락을 제공합니다. 서버 기능, 프로젝트 툴

비용 효과를 계산할 때는 검토 시간도 포함해야 합니다

영향을 받는 비용은 엔지니어링 업무를 조율하는 데 드는 비용입니다. MCP 도입 전에는 리드가 정보를 찾고, 복사하고, 대조하고, 문서로 정리합니다. 어시스턴트를 연결한 뒤에도 요청 범위를 정하고, 결과를 검토하고, 오류를 고치는 일은 남습니다.

자체 비용을 넣어 다음 손익분기 계산식을 적용해 봅니다.

순가치 = (수작업 준비 시간 − 어시스턴트 활용 시 준비·검토·수정 시간) × 간접비를 포함한 시간당 인건비 − 클라이언트 및 운영의 추가 비용.

아무리 보기 좋은 보고서라도 검증에 더 오래 걸리면 팀의 시간을 절약한 것이 아닙니다. 두 워크플로를 비교할 때 보고 범위를 동일하게 맞추고, 잘못된 편집을 수습하는 시간도 계산합니다. 실제로 채택할 수 있는 결과물 하나를 얻는 데 필요한 조율 업무를 줄이는 것이 목표입니다.

구독 플랜을 고르려면 Linear 요금제를 참고하세요. 이슈 관리 툴 자체를 아직 정하지 않았다면 Linear와 Jira 비교가 선택에 도움이 됩니다. 다른 서비스와의 연결은 추천 MCP 서버 가이드에서 다룹니다.

Linear MCP를 기반으로 만들어 볼 만한 서비스

가장 유망한 출발점은 사이클 진행 보고 초안 서비스입니다. 엔지니어링 리드는 팀별 범위를 지키고, 완료된 작업과 미완료 작업을 구분하며, 근거 이슈까지 담은 일관된 보고서에 비용을 지불할 수 있습니다. 최소한의 유용한 제품은 보고서의 기준을 저장하고, 관련 사이클 데이터를 조회해 편집 가능한 초안을 만듭니다. 예약 실행, 재시도, 전달은 별도로 만드는 애플리케이션이 맡아야 합니다.

관건은 차별화입니다. 일반적인 요약 프롬프트는 쉽게 따라 만들 수 있습니다. 제품이 될 만한 부분은 회사별 보고 규칙, 출처를 추적하는 기능, 검토 절차입니다. 독립적인 구독 서비스를 만들기 전에 팀들이 이런 세부 사항에서 반복적으로 어려움을 겪는지 확인해야 합니다.

맞춤형 이슈 분류 검토 대기열은 더 좁은 범위의 기회입니다. 플랫폼 또는 지원 엔지니어링 리드는 Linear 이슈의 맥락에 자체 업무 배정 정책과 별도 접근 승인을 받은 고객 지원 정보를 결합하는 데 비용을 지불할 수 있습니다. 최소 제품은 필드 변경 제안과 근거, 승인·건너뛰기 동작을 보여 준 뒤 승인된 변경을 적용합니다.

관건은 Linear의 기본 Triage Intelligence와 직접 경쟁한다는 점입니다. 추가 맥락이나 정책으로 인해 판단이 달라지고, 기본 시스템으로는 해당 팀에 필요한 판단을 충분히 처리하기 어려운 경우에만 개발할 이유가 있습니다. 이는 제품 가설이며, 고객이 실제로 거둔 성과를 주장하는 것은 아닙니다.

MCP 연결만으로 해결되지 않는 문제

MCP는 어시스턴트가 작업을 실행할 수 있게 해 줄 뿐, 모호한 요구사항을 결정하거나 불완전한 이슈 데이터를 믿을 만하게 바꿔 주지는 않습니다. Done으로 표시된 티켓은 그 티켓의 상태를 설명하는 근거가 될 수 있습니다. 하지만 그것만으로 고객에게 기능이 제공되었다고 입증할 수는 없습니다.

마찬가지로 Linear 접근을 승인했다고 해서 이슈에 언급된 모든 문서, 저장소, 고객 지원 시스템에 접근할 권한까지 생기는 것은 아닙니다. 그런 자료가 필요한 기능을 만든다면 별도의 접근 권한과 조회 경로를 설계해야 합니다.

새로 설정할 때는 /mcp를 사용합니다. Linear는 /sse를 더 이상 권장하지 않는 대체 연결 방식으로 표시합니다. 이전의 jerhadf 커뮤니티 서버 역시 지원이 중단되었고 더 이상 유지 관리되지 않는다고 명시하며, Linear 공식 서버를 사용하도록 안내합니다. 현재 엔드포인트 안내

다음 월요일에는 엔지니어링 리드가 팀, 사이클, 보고 기간을 정하고 읽기 전용으로 진행 보고 초안을 만들어 보세요. 초안의 설명을 연결된 이슈와 대조하고, 준비에 드는 수고를 기존 방식과 비교합니다. 팀의 검토 절차가 명확해지면 쓰기 작업으로 확장합니다.

팀의 규칙에 맞춰 이런 워크플로를 구축하고 싶다면 AI 자동화 구축 서비스를 이용할 수 있습니다.