Slack 메시지를 GitHub 이슈로, 그리고 수정까지
Slack에서 평소 말로 버그를 설명하세요. Zero가 GitHub 이슈를 쓰고 담당자를 지정하며, 원인이 한 컴포넌트 안에 있으면 수정과 회귀 테스트를 담은 풀 리퀘스트까지 열어 여러분의 리뷰를 기다립니다.
Zero가 만들어내는 결과물: Slack 메시지에서 리뷰 대기 중인 수정까지
열어서 읽어볼 수 있는 실제 실행 결과입니다. Zero는 한 주치 Slack 버그 제보를 GitHub 이슈로 만들고, 원인을 짚어낼 수 있었던 건은 회귀 테스트를 포함한 풀 리퀘스트까지 이어갔습니다. 리포트에는 diff와, 왜 3건은 고치고 나머지 4건은 등록에 그쳤는지가 적혀 있습니다. 샘플 데이터이지만 형식은 실제 출력 그대로입니다.
에이전트 요약. Zero는 #bugs, #support-escalation, #design-review, #product에서 메시지 24건을 읽었습니다. 9건이 결함을 설명했고 2건은 이미 열린 이슈가 있었으며 7건이 새 GitHub 이슈가 되었습니다. 그중 3건은 수정과 회귀 테스트를 담은 풀 리퀘스트까지 만들어 이슈에 연결했고 CI도 통과했습니다. 나머지 4건은 의도적으로 등록만 했습니다. 공용 날짜 처리, 디자인 토큰, 제품 판단이 필요한 건, 그리고 아직 재현 단계가 없는 건입니다. 검토한 메시지: 24, 9건이 결함을 설명. 생성한 이슈: 7, 모두 Slack 표시 이름으로 담당자 지정. 수정을 담은 PR: 3, 회귀 테스트 포함, 미리뷰 병합 0건.
등록과 수정 전체 리포트 열기Slack에서 GitHub 이슈를 생성한다는 것은 무슨 뜻인가요?
Slack에서 GitHub 이슈를 생성한다는 것은, 대화 중에 누군가 설명한 버그를 스레드를 떠나 다시 입력하지 않고도 저장소의 구조화된 이슈로 바꾸는 것을 뜻합니다. 어려운 부분은 API 호출이 아니라, 명확한 제목을 쓰고 재현 단계와 기대 동작을 구분하고 라벨을 고르고 우선순위를 정하고 적합한 담당자를 찾는 일이었습니다. Zero가 그 일을 합니다. Slack 메시지와 주변 답글을 읽고 이슈 본문을 작성하며, 근거를 설명할 수 있는 라벨과 우선순위를 붙이고, Slack 표시 이름을 GitHub 핸들과 대조해 담당자를 지정한 뒤, 같은 스레드에 이슈 링크를 남겨 제보자가 바로 확인할 수 있게 합니다.
버그 제보가 Slack 스레드에서 묻히는 이유
데모 도중 누군가 버그를 발견하거나, 토요일에 고객이 문의를 보냅니다. 기존 경로는 깁니다. GitHub를 열고, 저장소를 찾고, 형식을 갖춘 이슈를 쓰고, 누군가에게 배정한 뒤, 그 사람이 작업을 잡고 코드를 읽고 수정을 쓸 때까지 기다립니다. 10분이면 될 변경이 세 사람을 거치는 며칠짜리 왕복이 되고, 제보의 절반은 스레드를 끝내 벗어나지 못합니다. 대신 Slack에서 설명하세요. Zero가 재현 단계와 라벨, 담당자를 갖춰 이슈를 만들고, 원인이 좁혀지는 경우에는 수정과 테스트를 담은 풀 리퀘스트까지 진행합니다. 여러분은 리뷰하고 배포하면 됩니다.
Zero가 Slack에서 GitHub 이슈를 생성하는 방식
1단계: 도구 연결하기
2단계: Zero에게 요청하기
3단계: 한 걸음 더 나아가기
이 워크플로를 지탱하는 Slack·GitHub 연동
가운데 에이전트가 있는 Slack-GitHub 연동입니다. Zero는 Slack에서 대화를 읽고 GitHub에 기록을 씁니다. 각 커넥터는 개별적으로 허용되며 워크플로가 실제로 쓰는 범위로 한정되므로, 채널을 읽는 권한이 저장소 쓰기 권한을 의미하는 일은 없습니다.
Slack 연동: Zero가 읽는 대화
필수Zero는 지정한 메시지와 그 주변 답글을 함께 읽기 때문에, 세 번째 답글에서야 나온 맥락도 이슈에 담깁니다. 첨부된 스크린샷을 그대로 옮기고, 제보자의 표시 이름으로 담당자를 파악하며, 메시지 퍼머링크를 보관해 모든 이슈가 제보가 시작된 지점으로 연결되게 합니다. 쓰기는 한 가지뿐입니다. 같은 스레드에 이슈 번호와 링크를 남기는 답글입니다. 다른 채널에 글을 올리거나 DM을 보내거나 남의 메시지를 편집하지 않습니다.
GitHub 연동: Zero가 생성하는 이슈
필수Zero는 지정한 저장소에 이슈를 생성합니다. 제목은 원본 메시지를 복사한 것이 아니라 제보 내용을 바탕으로 작성하며, 설명·재현 단계·기대 동작과 스레드에서 언급된 경우 영향 범위를 포함합니다. 지정한 라벨을 적용하거나 문맥에서 유추하고, 설명 가능한 우선순위를 설정하며, 담당자를 지정합니다. 생성 전에는 같은 증상의 열린 이슈를 검색해 일치하면 새로 만들지 않고 기존 이슈에 댓글을 답니다. 버그를 고칠 수 있는 경우에는 브랜치를 푸시하고 해당 이슈를 닫는 풀 리퀘스트를 열어 리뷰를 요청합니다. 쓰기 권한은 허용한 저장소로 제한되며, 범위는 그게 전부입니다. 이슈, 댓글, 그리고 리뷰를 위해 여는 풀 리퀘스트. 병합, 강제 푸시, 저장소 설정 변경은 하지 않습니다.
Zero, Slack용 GitHub 앱, 자동화 빌더 비교
Slack 메시지의 버그를 GitHub로 옮기는 일은 세 단계입니다. 제보를 붙잡고, 쓸 만한 이슈를 쓰고, 담당자에게 넘기는 것입니다. 기존 선택지는 각각 하나씩만 해결합니다.
Slack용 GitHub 앱
/github를 입력하면 대화 상자가 열리고 제목·본문·라벨·담당자를 직접 채웁니다. 브라우저로 이동하는 수고는 줄지만 이슈를 쓰는 사람은 여전히 본인이고, 대화 도중에 뜨는 입력 폼은 “나중에 등록하지”라는 말을 만드는 바로 그 마찰입니다.
자동화 빌더
노코드 도구는 트리거에 따라 Slack 메시지를 새 이슈로 복사할 수 있습니다. 복사되는 것은 원문이라 이슈는 제보자가 그때 적은 문장을 그대로 물려받고, 라벨·우선순위·담당자 지정·중복 처리 규칙은 채널마다 직접 정의하고 유지해야 합니다.
Zero의 Slack-GitHub 워크플로
Zero는 스레드를 읽고 이슈를 씁니다. 제대로 된 제목, 기대 동작과 분리된 재현 단계, 근거를 설명할 수 있는 라벨과 우선순위, 제보자의 표시 이름에서 찾은 담당자. 원인이 한 컴포넌트 안에 있으면 거기서 멈추지 않고 수정과 회귀 테스트를 담은 풀 리퀘스트를 이슈에 연결해 열고 여러분의 리뷰를 기다립니다. 열린 이슈를 먼저 확인해 중복이면 새로 만들지 않고 댓글을 달며, 스레드에 링크로 답합니다.
더 나은 결과를 위한 팁
자주 묻는 질문
Slack 메시지로 GitHub 이슈를 만들려면 어떻게 하나요?
Slack과 GitHub를 Zero에 연결한 뒤 채널에서 버그를 설명하고 Zero를 멘션하세요. 메시지와 주변 답글을 읽어 제목·재현 단계·기대 동작·라벨·우선순위를 갖춘 이슈를 작성하고, 지정한 저장소에 생성하고, 담당자를 지정하고, 스레드에 이슈 번호와 링크로 답합니다. 폼을 채울 필요가 없습니다.
Slack용 GitHub 앱과 무엇이 다른가요?
GitHub 앱은 채워 넣을 대화 상자를 제공합니다. 제목·본문·라벨·담당자는 직접 씁니다. Zero는 그것들을 대화에서 작성하고, 생성 전에 같은 증상의 기존 이슈를 확인하며, 메시지 하나씩이 아니라 채널 전체를 정기적으로 처리할 수 있습니다.
Zero는 이슈만 등록하나요, 아니면 버그를 고칠 수도 있나요?
둘 다 하며, 무엇을 왜 했는지 밝힙니다. 이슈는 항상 등록합니다. 스레드나 코드가 하나의 컴포넌트를 가리키고 기대 동작이 명확하며 실패하는 테스트를 먼저 쓸 수 있으면, 수정과 그 테스트를 담은 풀 리퀘스트도 열어 이슈에 연결하고 리뷰를 요청합니다. 공용 유틸리티, 디자인 토큰, 제품 판단이 필요한 사안은 변경하지 않고 등록만 합니다. Zero는 병합하지 않습니다. 모든 수정은 여러분이 리뷰하는 풀 리퀘스트로 도착합니다.
Zero가 담당자를 자동으로 지정할 수 있나요?
네. 메시지에서 언급한 이름이나 제보자의 Slack 표시 이름을 저장소의 GitHub 핸들과 대조해 이슈를 지정합니다. 메시지에 담당자를 직접 적는 것이 가장 확실합니다. 아무도 지정되지 않으면 스레드가 가리키는 영역의 담당자로 대체하고, 어떻게 판단했는지 이슈에 적어 둡니다.
중복 GitHub 이슈는 어떻게 막나요?
무엇이든 만들기 전에 같은 증상·영향 범위·표현의 열린 이슈를 검색합니다. 일치하는 것이 있으면 새 Slack 스레드를 제보자와 타임스탬프와 함께 그 이슈의 댓글로 추가하고, 두 번째 이슈를 만드는 대신 Slack에 기존 이슈 링크로 답합니다.
재현 단계가 없는 버그 제보는 어떻게 되나요?
제보가 사라지지 않도록 이슈는 그대로 생성하되 재현 단계가 필요하다는 라벨을 붙이고, Slack 스레드에서 제보자에게 단계를 요청합니다. 그러면 답변이 이미 이슈와 연결된 스레드에 모입니다.
채널 전체의 버그를 정기적으로 등록할 수 있나요?
네. 하나 이상의 채널과 일정을 지정하세요. 예를 들어 매주 금요일 오후 4시입니다. 그 주의 메시지를 읽고 결함을 설명한 건마다 이슈를 만들고, 중복에는 댓글을 달고, 기능 요청과 질문은 건너뛰고, 수행 내용을 보고합니다.
GitHub 대신 Linear나 Jira에서도 되나요?
같은 워크플로 형태는 Zero가 연결된 어떤 트래커에도 적용됩니다. 이 페이지는 GitHub 커넥터를 쓰는 GitHub 경로를 다룹니다. Linear도 같은 방식으로 연결하며, 트래커는 지시문에서 지정합니다.
다음 버그는 Slack을 떠나지 않고 등록하세요
Slack과 GitHub를 연결하고 동료에게 말하듯 버그를 설명하면, Zero가 이슈를 쓰고 담당자를 지정합니다. 원인이 좁혀지는 경우에는 풀 리퀘스트까지 함께 기다리고 있습니다.