Claude Code + Linear MCP로 슬랙→티켓→PR 자동화 파이프라인 구축하기

목차

이 글의 배경

이 글은 클로드 코드 토큰 태우기 세션 진행 후기의 시리즈 글이다. 해당 세션에서 소개했던 “슬랙 메시지로부터 비즈니스 로직 티켓 생성하기” 워크플로우를 상세히 다룬다.

외주 개발을 하다 보면 클라이언트와의 커뮤니케이션이 체계적이지 않은 경우가 많다. Jira나 Notion 같은 협업 툴 대신 카톡이나 슬랙 메시지로 요청이 들어온다. 이런 환경에서 어떻게 체계적인 개발 워크플로우를 구축할 수 있을까?

Custom Slash Commands와 Linear MCP를 조합하면 가능하다.

문제 상황: 모호한 요청들

외주 개발에서 흔히 마주하는 상황이다.

[일반적인 외주 개발 커뮤니케이션]

클라이언트: "창식 님 이거 홈페이지가 이상해요."
클라이언트: "로그인이 안 돼요."
클라이언트: "이거 예쁘게 바꿔주세요."
    ↓
개발자: (정보 부족으로 추가 질문)
    ↓
몇 번의 티키타카...
    ↓
개발자: 요구사항 파악 완료
    ↓
개발자: 수동으로 티켓 생성
    ↓
개발자: 구현 시작
    ↓
(반복)

클라이언트는 개발자가 아니다. 어떻게 정보를 전달해야 하는지 모르는 것이 당연하다. 그래서 몇 번의 대화를 주고받으며 “완성도의 윤곽”을 그려야 한다.

문제는 이 과정에서 발생하는 반복 노동이다:

이 모든 과정을 자동화할 수 있다면?

워크플로우 전체 구조

Claude Code의 Custom Slash Commands와 Linear MCP를 조합한 자동화 파이프라인이다.

[자동화된 개발 파이프라인]

슬랙 메시지 (모호한 요청)
    │
    ▼
┌─────────────────────────────────────────┐
│  /new-ticket                            │
│  - 프로젝트 자동 매칭                      │
│  - 레이블 자동 추론 (Bug/Feature/...)      │
│  - 티켓 제목 AI 생성                      │
│  - Linear 티켓 자동 생성                  │
└─────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────┐
│  /work [티켓 ID]                         │
│  - 티켓 조회 & In Progress 변경            │
│  - Plan Mode로 구현 계획 수립              │
│  - 구현 & 검증                            │
│  - ⏸️ 커밋 승인 요청                      │
│  - In Review 변경 & 작업 로그 추가         │
└─────────────────────────────────────────┘
    │
    ▼
┌─────────────────────────────────────────┐
│  /pr [티켓 ID]                           │
│  - 변경 사항 분석                         │
│  - 브랜치 & 커밋 자동 생성                 │
│  - PR 생성                               │
│  - Linear 상태 업데이트                   │
└─────────────────────────────────────────┘
    │
    ▼
✅ 완료

핵심은 Linear MCP다. Claude Code가 Linear API를 직접 호출하여 티켓을 생성하고, 상태를 업데이트하고, 코멘트를 남길 수 있다.

Step 1: 슬랙 메시지 → 티켓 생성 (/new-ticket)

커맨드 개요

슬랙 메시지를 복사해서 붙여넣으면 Linear 티켓이 자동 생성된다.

/new-ticket [프로젝트명] [슬랙 메시지 내용]

사용 예시:

/new-ticket 충book-e 아이디 찾기가 안 됩니다

핵심 워크플로우

# .claude/commands/new-ticket.md (핵심 부분)

## 워크플로우

### 1. 프로젝트 확인
- `mcp__linear-server__list_projects`로 프로젝트 목록 조회
- 첫 번째 인자로 프로젝트 매칭 (이름 포함 검색)

### 2. 레이블 자동 추론
슬랙 메시지 내용을 분석하여 적절한 레이블 결정:
- `Bug`: 오류, 버그, 안됨, 실패, 깨짐 등
- `Feature`: 새 기능, 추가, 구현 등
- `Improvement`: 개선, 변경, 수정 등

### 3. 티켓 제목 생성
슬랙 메시지를 간결한 티켓 제목으로 변환:
- 50자 이내로 요약
- 예: "아이디 찾기가 안 됩니다" → "아이디 찾기 기능 오류 수정"

### 4. 티켓 생성
mcp__linear-server__create_issue({
  title: "<생성된_제목>",
  description: "## 원본 슬랙 메시지\n\n${슬랙_메시지}",
  project: "<매칭된_프로젝트>",
  labels: ["<추론된_레이블>"],
  state: "Todo"
})

실행 결과

✅ Linear 티켓이 생성되었습니다!

📋 티켓 정보:
- 제목: 아이디 찾기 기능 오류 수정
- 프로젝트: 충book-e
- 레이블: Bug
- 담당자: caesiumy
- 상태: Todo

🔗 티켓 URL: https://linear.app/caesiumy/issue/CAE-59/...

⚠️ 티켓 확인은 필수

AI가 생성한 티켓은 반드시 개발자가 확인해야 한다. AI가 슬랙 메시지를 잘못 이해했을 수 있기 때문이다.

확인 포인트:

• 티켓 제목이 문제를 정확히 반영하는가?
• 레이블이 적절한가? (Bug인데 Feature로 분류되진 않았는가?)
• 설명에 누락된 정보가 없는가?

필요하다면 티켓에 직접 추가 정보를 입력한다:

• 재현 단계
• 스크린샷
• 관련 코드 위치
• 참고 자료 링크

AI에게 익숙해져 직접 작성하는 건 귀찮아 보일 수도 있지만, 티켓은 다음 워크플로우 작업에 있어 단일 진실의 원천(Single Source of Truth)이 되어준다. 좋은 티켓이 좋은 코드를 만든다.

이 과정 자체가 메타 프롬프팅이다. 티켓이 곧 다음 단계 AI를 위한 프롬프트가 된다.

Step 2: 티켓 구현 워크플로우 (/work)

커맨드 개요

생성된 티켓을 기반으로 구현부터 커밋까지 자동화한다.

/work [티켓 URL 또는 ID]

사용 예시:

/work CAE-59
# 또는
/work https://linear.app/caesiumy/issue/CAE-59/...

핵심 워크플로우

# .claude/commands/work.md (핵심 부분)

## 워크플로우

### 1. 티켓 조회 및 In Progress 변경
- `mcp__linear-server__get_issue`로 티켓 정보 조회
- `mcp__linear-server__update_issue`로 상태를 "In Progress"로 변경

### 2. 구현 및 검증
- Plan 모드로 구현 계획 수립 (⏸️ 사용자 승인 대기)
- `TodoWrite`로 작업 추적하며 구현 진행
- `pnpm build` 및 `pnpm lint`로 검증

### 3. 커밋 승인 요청 🔴
**중요**: 반드시 사용자에게 커밋 여부 질문!

모든 구현과 검증이 완료되었습니다.

변경된 파일:
- <파일_목록>

검증 결과:
✅ 빌드 성공
✅ 린트 통과

커밋을 진행하시겠습니까?

### 4. In Review 변경 및 작업 로그 추가
커밋 후 자동으로:
- 상태를 "In Review"로 변경
- 작업 로그를 티켓 코멘트로 추가

⚠️ 커밋 전 직접 확인

커밋 승인 요청이 오면, 개발자는 에디터의 소스제어(Git) 탭을 열어 변경 사항을 직접 확인해야 한다:

1. 변경된 파일 목록이 예상과 일치하는가?
2. 각 파일의 diff가 의도한 수정인가?
3. 불필요한 변경이나 삭제가 없는가?

AI가 출력한 “변경된 파일” 목록만 보지 말고, 실제 diff를 눈으로 확인하는 것이 핵심이다.

이 경고를 무시하다가는 무조건 피를 본다…

작업 로그 자동 기록

커밋이 완료되면 Linear 티켓에 자동으로 작업 로그가 남는다.

## 작업 완료 ✅

### 변경 파일
- src/features/auth/find-id.tsx
- src/api/auth.ts

### 주요 수정 사항
- 아이디 찾기 API 호출 로직 수정
- 에러 핸들링 추가

### 검증 결과
- ✅ 빌드 성공
- ✅ 린트 통과
- 변경 라인: +45, -12

### 커밋
- Hash: abc1234
- Branch: fix/find-id-error

이 로그는 디버깅 추적용으로도 유용하다. 나중에 문제가 생겼을 때 어떤 변경이 있었는지 바로 확인할 수 있다.

Step 3: 브랜치 & PR 자동화 (/pr)

커맨드 개요

현재 변경 사항을 기반으로 브랜치 생성부터 PR까지 자동화한다.

/pr [티켓 ID - 선택사항]

핵심 워크플로우

# .claude/commands/pr.md (핵심 부분)

## 워크플로우

### 1. 현재 상태 확인
- `git status`로 변경 사항 확인
- `git diff --stat`로 변경 파일 목록 파악

### 2. 변경 내용 분석 및 커밋 메시지 생성
변경된 파일들을 분석하여:
- 커밋 타입 결정 (feat, fix, refactor 등)
- 커밋 메시지 자동 작성
- 브랜치 이름 생성 (<타입>/<간결한-설명>)

### 3. 사용자 확인 요청 🔴
**중요**: 반드시 사용자에게 확인 요청!

📋 변경 사항 분석 완료

변경된 파일:
<파일_목록>

생성할 브랜치: fix/find-id-error
커밋 메시지: fix: 아이디 찾기 기능 오류 수정 (CAE-59)
PR 대상: main

진행하시겠습니까?

### 4. Git 작업 실행
- 새 브랜치 생성 및 이동
- 커밋 생성
- 원격 저장소에 푸시
- PR 생성

### 5. Linear 상태 업데이트 (티켓 ID가 있는 경우)
- 티켓 상태를 "In Review"로 변경

실행 결과

✅ PR 워크플로우 완료!

📋 작업 결과:
- 브랜치: fix/find-id-error
- 커밋: abc1234
- PR: #42
- Linear: In Review로 업데이트됨

🔗 PR 링크: https://github.com/user/repo/pull/42

메타 프롬프팅의 힘

이 워크플로우의 핵심 인사이트는 티켓 자체가 AI를 위한 프롬프트라는 것이다.

[메타 프롬프팅 구조]

슬랙 메시지 (사람의 언어)
    │
    ▼
/new-ticket
    │
    ▼
Linear 티켓 (구조화된 명세서)
    │  ├── 제목: 명확한 작업 목표
    │  ├── 설명: 원본 요청 + 컨텍스트
    │  └── 레이블: 작업 유형 분류
    │
    ▼
/work
    │
    ▼
AI가 티켓을 읽고 구현

장점:

마무리

핵심은 세 가지다:

1. Linear MCP: Claude Code가 티켓 시스템과 직접 대화
2. Custom Slash Commands: 반복되는 워크플로우 자동화
3. 메타 프롬프팅: 티켓 = AI를 위한 구조화된 프롬프트

[결과]
기존: 슬랙 확인 → 티켓 생성 → 상태 변경 → 구현 → 커밋 → PR → 상태 변경 → 로그 작성
개선: /new-ticket → /work → /pr → 완료

물론 100% 자동화는 아니다. 승인 단계에서 사람의 검토가 필요하다. 하지만 반복 노동을 80% 줄이는 것만으로도 개발 생산성은 확실히 달라진다.

게다가 CLI 도구의 특성을 활용하면 여러 터미널을 열어 병렬로 작업할 수도 있다. 세 개의 티켓을 동시에 처리하는 것도 가능하다. 이렇게 클로드 토큰을 태우면 금방 토큰 소모 한계에 도달하게 된다…

AI Agent에게 전달할 프롬프트

아래 프롬프트를 Claude Code에 복사해서 붙여넣으면, Linear 연동 워크플로우를 자동화하는 커스텀 슬래시 커맨드를 생성한다. 실제 내가 사용하는 커맨드 파일들의 구조를 그대로 반영했다.

Linear MCP를 활용한 개발 워크플로우 자동화 커스텀 슬래시 커맨드를 만들어줘.

## 사전 준비

1. Linear MCP 서버 연결 확인: `/mcp` 명령어로 `linear-server` 연결 상태 확인
2. 커맨드 파일 위치: `.claude/commands/` 디렉토리

## 목표

3개의 커맨드로 슬랙 → 티켓 → 구현 → PR 파이프라인을 자동화한다.

---

## 커맨드 1: /new-ticket

슬랙 메시지를 Linear 티켓으로 자동 변환한다.

### Frontmatter

```yaml
---
argument-hint: <프로젝트명> <슬랙 메시지>
description: 슬랙 메시지 기반 Linear 티켓 생성 (프로젝트 지정, 레이블 자동 추론, 담당자 자동 지정)
allowed-tools: mcp__linear-server__list_projects, mcp__linear-server__list_issue_labels, mcp__linear-server__get_user, mcp__linear-server__create_issue
---
```

### 입력 파싱 규칙

- 첫 번째 단어: 프로젝트 이름 또는 ID (부분 매칭 지원)
- 나머지 전체: 슬랙 메시지 원본

예시:
- `충book-e 아이디 찾기가 안 됩니다` → 프로젝트: "충book-e", 메시지: "아이디 찾기가 안 됩니다"

### 워크플로우

1. **프로젝트 매칭**: `list_projects`로 목록 조회 → 이름 포함 검색 (대소문자 무시)
2. **레이블 자동 추론**: 슬랙 메시지 내용 분석
   - **Bug**: 오류, 버그, 안됨, 안 됨, 실패, 깨짐, 문제, 에러
   - **Feature**: 새 기능, 추가, 구현, 개발, 신규
   - **Improvement**: 개선, 변경, 수정, 업데이트 (기본값)
3. **티켓 제목 생성**: 50자 이내로 요약, 명확하고 행동 지향적으로 작성
4. **담당자 지정**: `get_user("me")`로 현재 사용자 조회
5. **티켓 생성**: `create_issue` 호출

### 결과 출력 포맷

```
✅ Linear 티켓이 생성되었습니다!

📋 티켓 정보:
- 제목: <제목>
- 프로젝트: <프로젝트명>
- 레이블: <레이블>
- 담당자: <사용자명>
- 상태: Todo

🔗 티켓 URL: <URL>
```

---

## 커맨드 2: /work

Linear 티켓 기반으로 구현부터 커밋까지 자동화한다.

### Frontmatter

```yaml
---
argument-hint: <티켓 URL 또는 ID>
description: Linear 티켓 구현 워크플로우 (조회→In Progress→구현→커밋 승인→In Review→로그 추가)
allowed-tools: Bash(git:*), Bash(pnpm:*), mcp__linear-server__get_issue, mcp__linear-server__update_issue, mcp__linear-server__create_comment
---
```

### 티켓 ID 추출 규칙

- URL 형태 (`linear.app/.../issue/XXX-00/`): 정규식 `/issue/([A-Z]+-\d+)/`로 ID 추출
- 단순 ID (`XXX-00`): 그대로 사용

### 워크플로우

1. **티켓 조회 & In Progress**: `get_issue` → `update_issue(state: "In Progress")`
2. **구현**: Plan 모드로 계획 수립 → TodoWrite로 추적하며 구현
3. **검증**: `pnpm build` 및 `pnpm lint` 실행
4. **🔴 커밋 승인 요청**: 반드시 사용자에게 확인!
   ```
   모든 구현과 검증이 완료되었습니다.

   변경된 파일: <목록>
   검증 결과: ✅ 빌드 성공, ✅ 린트 통과

   커밋을 진행하시겠습니까?
   ```
5. **Git 커밋**: Conventional Commits 규칙 준수
   ```
   <타입>: <제목> (<티켓_ID>)

   ## 문제
   <티켓에서 설명된 문제>

   ## 해결
   <구현한 해결 방법>

   ## 변경 파일
   <변경된 파일 목록>

   ## 검증
   <검증 결과>
   ```
6. **In Review & 작업 로그**: 상태 변경 + `create_comment`로 로그 추가

---

## 커맨드 3: /pr

변경 사항 분석 → 브랜치 생성 → PR 자동화.

### Frontmatter

```yaml
---
argument-hint: [티켓 ID] (선택사항)
description: 브랜치 생성 → 푸시 → PR 워크플로우
allowed-tools: Bash(git:*), Bash(gh:*), mcp__linear-server__get_issue, mcp__linear-server__update_issue
---
```

### 워크플로우

1. **상태 확인**: `git status`, `git diff --stat`
2. **변경 분석**: 커밋 타입 결정
3. **브랜치 생성**: `<타입>/<간결한-설명>` (예: `fix/login-error`, `feat/add-search`)
4. **🔴 사용자 확인**: 브랜치명, 커밋 메시지, PR 대상(main) 확인
5. **Git 작업**: `checkout -b` → `add .` → `commit` → `push -u origin`
6. **PR 생성**: `gh pr create --base main`
   ```markdown
   ## Summary
   <변경 사항 요약 1-3줄>

   ## Changes
   <변경된 파일 목록>

   ## Linear Ticket
   <티켓 링크 또는 "N/A">
   ```
7. **Linear 업데이트** (티켓 있는 경우): 상태를 "In Review"로 변경

---

## 핵심 요구사항

### 사용자 승인 시점 (🔴 필수)
1. `/work`: 커밋 진행 전 - 변경 내용과 검증 결과 확인
2. `/pr`: 브랜치 생성 및 PR 진행 전 - 브랜치명과 PR 내용 확인

### Conventional Commits 규칙
| 타입       | 설명         | 예시                           |
| ---------- | ------------ | ------------------------------ |
| `feat`     | 새 기능 추가 | `feat: 검색 기능 구현`         |
| `fix`      | 버그 수정    | `fix: 로그인 오류 해결`        |
| `refactor` | 리팩토링     | `refactor: API 호출 로직 개선` |
| `docs`     | 문서 수정    | `docs: README 업데이트`        |
| `style`    | 포맷팅       | `style: 코드 정렬`             |
| `test`     | 테스트 추가  | `test: 유닛 테스트 추가`       |
| `chore`    | 기타         | `chore: 의존성 업데이트`       |

### 에러 처리
- **프로젝트/티켓 미발견**: 목록 출력 후 재시도 안내
- **API 오류**: 에러 메시지 출력 및 수동 작업 안내
- **Linear 연동 실패**: 경고만 출력, 워크플로우는 계속 진행

---

이제 `.claude/commands/` 디렉토리에 `new-ticket.md`, `work.md`, `pr.md` 파일을 생성해줘.

참고 자료

• Linear MCP

시리즈

• 이전: 클로드 코드 토큰 태우기 세션 진행 후기
• 이전: MCP(Model Context Protocol)로 Figma UI 디자인 그대로 생성하기