SuperIntern MCP로 버그 트리아지 회의의 결정을 GitHub Issues에 자동 반영하기

주간 버그 트리아지 회의가 끝나는 장면을 떠올려 보세요.

방금 30분 동안 신중하게 판단을 내렸습니다. "이건 P1으로 올리고 다음 마일스톤에 넣자", "이건 needs-repro 라벨을 붙이자", "저건 이미 고쳐졌을 테니 닫자." 그런데 회의가 끝난 시점에 그 결정들은 아직 어디에도 존재하지 않습니다. 누군가 회의록을 다른 화면에 띄워 놓고 GitHub를 열어, 이슈를 하나씩 검색하고, 라벨을 바꾸고, 마일스톤을 설정하고, 담당자를 지정하고, (시간이 남으면, 사실 남는 일이 없지만) 왜 그렇게 결정했는지 코멘트를 남깁니다. 이슈가 20개인 날이면 이 동기화 작업만으로 30분이 사라집니다. 더 나쁜 것은, 이 작업이 미뤄지면 트래커와 팀의 실제 결정이 며칠씩 어긋난 채로 방치되고, 다음 트리아지가 "잠깐, 이거 P1으로 하기로 하지 않았었나?"로 시작된다는 점입니다.

이 가이드에서는 SuperIntern의 MCP와 GitHub의 MCP 서버를 Claude에 연결해, 트리아지 결정을 GitHub 이슈에 반영하는 작업을 프롬프트 하나로 끝내는 방법을 소개합니다. 바로 복사해서 쓸 수 있는 실제 프롬프트 예시도 함께 담았습니다.

⚠️ 이 글은 2026년 8월 시점의 공개 정보와 사용자 피드백을 바탕으로 독자적으로 작성되었습니다.

오늘의 목표: Before / After
작동 원리: 세 가지 역할
설정
데모 1: 트리아지 결정을 이슈에 한 번에 반영하기
데모 2: 구두로 보고된 버그를 중복 확인 후 등록하기
데모 3: 회의와 트래커의 어긋남을 주간 점검하기
일상 운영을 위한 팁
GitHub를 넘어서: 같은 패턴의 확장
FAQ

오늘의 목표: Before / After

Before: 트리아지가 끝나면 누군가 회의록과 GitHub를 오가며 이슈를 하나씩 열어 라벨, 마일스톤, 담당자를 수작업으로 반영합니다. 결정 이유를 기록할 시간은 아무에게도 없어서, 3주 뒤에는 왜 그 이슈가 P1이 되었는지 아무도 기억하지 못합니다.

After: 회의가 끝나면 Claude에게 한 번만 요청합니다. "오늘 트리아지 결정을 GitHub에 반영해 줘." Claude가 회의 요약에서 결정 사항을 읽어 각 이슈를 찾고, 라벨과 마일스톤과 담당자를 업데이트하고, 모든 이슈에 결정 이유와 출처 회의를 코멘트로 남깁니다.

배경을 설명하면, SuperIntern은 봇 없이(botless) 동작하는 데스크톱 앱으로, 통화에 봇이 참가하지 않은 채 전사 기록과 AI 회의 노트를 자동으로 축적합니다. 트리아지 중에는 평소처럼 버그를 놓고 논쟁만 하면 됩니다. 결정 사항은 회의 데이터로 저절로 쌓이므로, 자동화할 일은 GitHub로의 동기화 하나만 남습니다.

SuperIntern

작동 원리: 세 가지 역할

세 참여자가 이 워크플로를 구성합니다.

역할	담당	하는 일
회의 데이터 제공	SuperIntern MCP	전사 기록, 라이브 전사, AI 요약, 회의 노트를 읽기 전용으로 제공
판단과 초안 작성	Claude (AI 클라이언트)	회의 데이터를 읽고 결정 사항을 추출해 이슈와 매칭하고 업데이트 초안을 작성
작업 대상	GitHub (MCP)	이슈 검색, 라벨과 마일스톤 업데이트, 담당자 지정, 코멘트, 신규 이슈 등록

MCP(Model Context Protocol)는 AI 어시스턴트를 외부 도구에 안전하게 연결하기 위한 오픈 표준입니다. SuperIntern의 MCP는 회의 데이터를 AI 클라이언트에 읽기 전용으로 제공하고, GitHub 공식 MCP 서버가 이슈의 검색, 생성, 업데이트를 담당합니다. 즉 GitHub 이슈를 건드리는 것은 Claude이지 SuperIntern이 아닙니다. SuperIntern의 데이터는 MCP를 통해 절대 수정될 수 없고, AI는 본인이 접근 가능한 회의만 볼 수 있으며, 쓰기 작업은 전부 GitHub 쪽에서만 일어납니다. 회의 기록에 아무런 위험 없이 시도해 볼 수 있습니다.

설정

필요한 연결은 정확히 두 개입니다. SuperIntern 쪽은 API 키가 필요 없고 브라우저 로그인만으로 완료됩니다. GitHub는 클라이언트에 따라 브라우저에서 OAuth로 로그인하거나 Personal Access Token을 사용합니다.

1. SuperIntern MCP를 Claude에 연결하기

Claude에서 설정(Settings), 커넥터(Connectors) 순으로 이동해 "커스텀 커넥터 추가"를 선택하고 연결 URL을 등록합니다.

https://mcp.app.super-intern.com/mcp

SuperIntern 로그인 화면이 열리면 로그인하고 승인하면 끝입니다. 플랜 요건(개인 워크스페이스는 Plus 이상, Enterprise는 관리자 활성화 필요)과 Claude Code, Cursor 등 클라이언트별 설정 방법은 MCP 설정 가이드에서 다루고 있습니다.

2. GitHub MCP 서버를 Claude에 연결하기

GitHub는 공식 MCP 서버를 제공합니다. 다만 원격 서버(https://api.githubcopilot.com/mcp/)는 등록된 GitHub App을 통한 OAuth에 의존하는데, Claude의 "커스텀 커넥터 추가" 흐름은 현재 이를 지원하지 않습니다. 대신 공식 설치 가이드의 경로 중 하나로 연결하세요.

Claude Desktop: claude_desktop_config.json에 로컬 GitHub MCP 서버(Docker)를 추가합니다. 처음 사용할 때 브라우저에서 GitHub 로그인(OAuth)이 열리므로 별도로 토큰을 만들 필요가 없습니다
Claude Code: Personal Access Token으로 원격 서버에 연결합니다:

claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

Claude Desktop용 정확한 설정 JSON과 Cursor 등 다른 클라이언트의 절차는 공식 설치 가이드에 있습니다.

연결이 잘 되었는지 확실하지 않다면 먼저 이렇게 물어보세요.

내 최근 SuperIntern 회의 3건과 nanohuman/app의 열려 있는 이슈 3건을 보여줘

둘 다 돌아오면 준비 완료입니다.

데모 1: 트리아지 결정을 이슈에 한 번에 반영하기

가장 자주 쓰는 용도는 트리아지 직후의 일괄 동기화입니다. 트리아지 결정은 대부분 기존 이슈의 상태를 바꾸는 일이므로, 핵심 역량은 새 이슈 생성이 아니라 올바른 이슈를 식별해 업데이트하는 것입니다.

오늘 "Bug triage" 회의의 AI 요약을 가져와서 이슈별 결정 사항을 추출해 줘.
nanohuman/app에서 번호나 설명으로 해당 이슈를 찾아줘.
합의한 우선순위 라벨과 마일스톤을 적용하고, 정한 담당자를 지정해 줘.
각 이슈에 결정 이유와 출처 회의 이름을 코멘트로 남겨줘.
닫기로 한 이슈는 이유를 먼저 코멘트한 다음 닫아줘.

Claude가 요약을 읽고 GitHub를 검색한 뒤 이렇게 보고합니다.

이슈 8건을 업데이트했습니다.\

#482 "탭 전환 시 검색 결과 초기화": P1과 마일스톤 v0.14 추가, Sara에게 할당. 고객 계정 3곳에서 재현되어 우선순위 상향\

#475 "CSV 내보내기 문자 깨짐": P2 추가, 재현 절차 대기 중\

#468 "설정 페이지 툴팁 위치 어긋남": P3와 good first issue 추가\

#441 "구 대시보드 레이아웃 깨짐": v0.13에서 수정 확인, 이유를 코멘트하고 닫음
모든 이슈에 출처로 "Bug triage meeting (Aug 14)"를 인용한 코멘트를 남겼습니다.

Claude가 트리아지 결정을 반영해 업데이트한 GitHub 이슈

핵심은 라벨과 마일스톤만이 아니라 결정 이유가 코멘트로 남는다는 점입니다. 어떤 이슈든 열어 보면 언제, 왜 그 우선순위가 되었는지 추적할 수 있습니다. 3주 뒤에도 "이거 왜 P1이야?"라고 물어볼 일이 없습니다. SuperIntern의 AI 요약이 결정 사항을 깔끔하게 구조화해 주기 때문에 추출 정확도도 안정적으로 유지됩니다.

데모 2: 구두로 보고된 버그를 중복 확인 후 등록하기

트리아지 회의와 스탠드업에는 구두 버그 보고가 가득합니다. "아 맞다, 내보내기 화면이 좀 이상하게 동작하던데요." 그 자리에서 아무도 이슈를 쓰지 않으면 그 보고는 회의록에 묻혀 그대로 사라집니다.

오늘 "Engineering standup"의 전사 기록을 가져와서 버그나 결함에 대한
구두 언급을 전부 목록으로 만들어줘.
nanohuman/app의 기존 이슈와 대조해 줘.
이미 이슈가 있는 건은 회의에서 나온 새로운 맥락을 코멘트로 추가해 줘.
어디에도 없는 보고만 재현 절차를 포함해 신규 이슈로 등록해 줘.
제목은 증상을 설명하는 문장으로 쓰고, 본문에 보고자와 출처 회의를 적어줘.

이 프롬프트는 요약이 아니라 전사 기록을 사용한다는 점에 주목하세요. 구두 버그 보고는 요약에서 빠지기 쉽지만, 전사 기록에는 지나가듯 던진 한마디까지 남아 있습니다. "재현 절차"를 요청하면 Claude가 보고자가 말로 설명한 흐름을 실제 재현 목록으로 재구성해 주므로, 나중에 다시 물어보러 갈 일이 줄어듭니다.

데모 3: 회의와 트래커의 어긋남을 주간 점검하기

회의에서는 "고치기로 했다"고 했는데 이슈는 전혀 움직이지 않았습니다. 혹은 모두가 닫기로 합의한 이슈가 여전히 열려 있습니다. 회의에서 합의한 내용과 GitHub의 실제 상태 사이의 이런 어긋남을 일주일에 한 번 점검하세요. 여러 회의를 한 번에 참조하는 것이야말로 MCP가 잘하는 일입니다.

"Product team" 프로젝트의 이번 주 회의를 전부 가져와서, GitHub 이슈가
언급되었거나 이슈에 대한 결정이 내려진 부분을 모두 찾아줘.
nanohuman/app 이슈의 현재 상태와 비교해 줘.
회의 결정이 아직 반영되지 않은 이슈를 회의 이름, 결정 내용, 현재 상태와
함께 표로 보여줘. 아직 아무것도 반영하지는 말아줘.

이 프롬프트는 의도적으로 변경 없이 표만 먼저 요청합니다. 주간 점검은 그물을 넓게 던지기 때문에 지나가는 발언까지 걸릴 수 있으므로, 표를 검토한 뒤 "이 세 건만 반영해 줘"라고 답하는 2단계 방식이 안전합니다. 매주 금요일에 실행하면 트래커가 팀이 실제로 결정한 내용을 정직하게 비추는 거울로 유지됩니다.

일상 운영을 위한 팁

리포지토리를 명시적으로 지정하세요. 프롬프트에 "nanohuman/app에서"를 넣어두면 멀티 리포 조직에서 다른 리포를 건드리는 실수를 확실히 막을 수 있습니다. 자주 쓰는 리포 이름을 저장된 프롬프트에 박아 두세요.

드라이런으로 시작하세요. 처음 몇 번은 "적용 전에 변경 예정 내역을 먼저 보여줘"를 덧붙이세요. Claude가 회의 속 표현("그 검색 버그")을 실제 이슈에 얼마나 잘 매칭하는지 확인한 뒤에 바로 적용으로 전환하면 속도를 마음껏 누릴 수 있습니다.

이슈 번호를 소리 내어 말하세요. 트리아지 중에 "#482"라고 말하는 팀은 그 번호가 전사 기록에 남아 Claude의 매칭이 거의 완벽해집니다. 트리아지 때 이슈 목록을 화면 공유하고 있다면 이미 자연스럽게 하고 있을 가능성이 높습니다.

라벨 체계를 프롬프트에 고정하세요. "우선순위는 P1/P2/P3, 유형은 bug/enhancement를 사용해"라고 적어두면 체계에 없는 라벨이 실수로 생성되는 일을 막을 수 있습니다.

고유명사는 SuperIntern 쪽에서 개선하세요. 기능명과 화면명이 정확하게 전사될수록 이슈 매칭이 좋아집니다. 자주 나오는 기능명과 팀원 이름을 SuperIntern의 커스텀 사전에 등록하는 데 드는 2분은 충분히 가치가 있습니다.

쓰기는 GitHub에서만 일어납니다. SuperIntern의 데이터는 MCP를 통해 절대 수정되지 않습니다. 동기화가 잘못되면 GitHub 쪽에서 고치면 되고, 원본 회의 기록은 계속 신뢰할 수 있는 원천으로 남습니다. GitHub도 모든 이슈에 자체 변경 이력을 남기므로 감사 관점에서도 안심할 수 있습니다.

GitHub를 넘어서: 같은 패턴의 확장

"SuperIntern MCP가 데이터를 제공하고, Claude가 판단하고, 다른 도구가 작업을 받는다"는 패턴은 GitHub 너머로도 확장됩니다.

다른 트래커: Linear를 쓰는 팀은 Linear 연동 가이드에서 거의 같은 흐름을 따라할 수 있습니다
Slack 공유: 트리아지 요약을 개발 채널로 바로 공유하세요. Slack 연동 가이드를 참고하세요
코드까지 한 번에: SuperIntern MCP를 Claude Code에 연결하면 "트리아지에서 정한 그 P1"에서 회의 논의를 반영한 실제 수정까지 이어집니다. 방법은 스펙에서 코드까지 다룬 글에서 소개합니다

이런 조합을 앞으로도 하나씩, 항상 실제 프롬프트와 함께 다뤄 나가겠습니다.

FAQ

Q. SuperIntern MCP는 무료 플랜에서 쓸 수 있나요?
A. 아니요. 개인 워크스페이스는 Plus 플랜 이상이 필요합니다. Team 플랜 워크스페이스는 그대로 사용할 수 있고, Enterprise에서는 관리자가 워크스페이스 설정에서 "MCP 액세스"를 먼저 활성화해야 합니다.

Q. SuperIntern이 내 GitHub 이슈에 직접 쓰나요?
A. 아니요. 이슈 업데이트, 등록, 코멘트는 모두 Claude가 GitHub MCP 서버를 통해 수행합니다. SuperIntern MCP는 회의 데이터를 읽기 전용으로 제공할 뿐이며, SuperIntern 자체는 외부 도구에 절대 쓰지 않습니다.

Q. AI가 내 회의 노트나 전사 기록을 수정할 수 있나요?
A. 아니요. SuperIntern MCP의 모든 도구는 읽기 전용이며 생성, 수정, 삭제 작업이 존재하지 않습니다. 쓰기는 GitHub 쪽에서만 일어납니다.

Q. 프라이빗 리포지토리에서도 작동하나요?
A. 네. GitHub MCP 서버는 연결에 사용한 자격 증명(OAuth 로그인 또는 Personal Access Token)의 권한으로 동작하므로, 그 자격 증명이 접근할 수 있는 리포지토리를 정확히 커버하고 그 이상은 접근하지 않습니다.

Q. 잘못된 변경을 대량으로 적용해 버리면 어떻게 하나요?
A. 팁 섹션의 드라이런 습관을 활용하세요. "적용 전에 변경 예정 내역을 먼저 보여줘"가 사람의 확인 지점이 됩니다. 잘못된 변경이 들어가더라도 GitHub의 이슈 이력으로 되돌릴 수 있고, SuperIntern의 데이터는 영향을 받지 않습니다.

Q. Claude 외의 AI 클라이언트도 쓸 수 있나요?
A. SuperIntern MCP와 GitHub MCP 서버 모두 Claude Code, Codex, Cursor 같은 MCP 지원 클라이언트에서 작동합니다. 둘 다 연결할 수 있는 클라이언트라면 이 글의 프롬프트를 거의 그대로 실행할 수 있습니다.

트리아지 회의의 가치는 결정을 내리는 것이지, 그 결정을 나중에 GitHub에 옮겨 적는 것이 아닙니다. 결정은 계속 사람이 하고, 옮겨 적기는 넘기세요.

SuperIntern 무료 체험하기

목차