DevTools on kastori

GitHub + Jira + Slack — 개발 알림을 한 곳에 모으기

Tue, 09 Jun 2026 00:00:00 +0900

알림이 흩어지면 놓친다

작업하다 보면 이런 일이 생긴다. GitHub Actions가 실패했는데 한참 후에야 알아챈다. Jira 이슈를 Done으로 바꾸는 걸 잊는다. PR을 올려놓고 머지했는지 까먹는다.

Jira, GitHub, 그리고 Slack 세 가지를 연동하면 이 모든 이벤트가 한 곳으로 모인다.

왜 혼자도 유용한가

팀이 없으면 알림이 필요 없을 것 같지만, 혼자일 때도 의미 있는 알림이 있다.

✅ GitHub Actions 실패
 → 배포가 깨졌는데 모르고 있는 상황 방지

✅ Jira 이슈 상태 변경
 → 작업 흐름이 Slack에 타임라인으로 쌓임
 → "이번 주에 뭐 했지?" 를 Slack에서 확인 가능

✅ PR 머지
 → 배포 전 최종 확인

그리고 팀에 합류했을 때 “Slack + Jira + GitHub 연동 경험 있습니다"를 자연스럽게 말할 수 있다.

채널 구성

먼저 Slack에서 채널 두 개면 충분하다.

#notifications ← 자동 알림 전용 (봇 메시지)
나 자신에게 DM ← 메모, 아이디어, 링크 (내가 직접 치는 것들)

알림과 메모를 섞으면 둘 다 묻힌다. 이 분리가 핵심이다.

Jira → Slack 연동

Atlassian 공식 앱은 Jira 마켓플레이스가 아닌 Slack App Directory에 있다.

1. Slack → 앱 추가 → "Jira Cloud" 검색
 → by Atlassian → 추가

2. /jira connect 입력 → Atlassian 계정 로그인

3. 채널 알림 설정:
 Jira 프로젝트 → 상단 탭 "Slack integration"
 → #notifications 채널 선택
 → 이벤트 종류 선택
 ✅ Issue created
 ✅ Issue updated
 ✅ Status is transitioned to

이후 Jira 이슈 상태가 바뀔 때마다 #notifications 로 알림이 온다.

Slack에서 직접 이슈 생성도 가능:
/jira create → 제목, 타입 입력 → Jira에 바로 등록

GitHub → Slack 연동

1. Slack → 앱 추가 → "GitHub" 검색
 → by GitHub → 추가

2. #notifications 채널에서:
 /github signin → GitHub 계정 연결

3. 레포 구독:
 /github subscribe kastori1206/my-project

알림이 너무 많으면 push 알림만 끄면 된다:

/github unsubscribe kastori1206/my-project pushes

연동 후 실제로 오는 알림

[Jira] BLOG-42 상태 변경: To Do → In Progress
[Jira] BLOG-43 "로그인 버그" 새 이슈 생성됨
[GitHub] PR #15 "feat: 댓글 API" opened → main
[GitHub] PR #15 merged ✅
[GitHub] ✅ Build succeeded / ❌ Build failed

GitHub Actions 실패 알림 설정

CI/CD 실패 알림은 Slack GitHub 앱 구독 외에 레포 설정에서도 켤 수 있다.

GitHub 레포 → Settings → Notifications
→ Actions → Email 또는 Slack webhook 추가

간단하게는 Slack 앱 구독 상태에서 Actions 알림이 기본으로 포함된다.

Dependabot 보안 알림

사용 중인 라이브러리에 취약점이 발견되면 알림을 받는다.

GitHub 레포 → Settings → Security
→ Dependabot alerts → Enable
→ 이메일로 자동 발송

시리즈를 마치며

Jira → 할 일을 이슈로 만들고 이력을 남긴다
Git → 브랜치·커밋에 이슈 키를 연결한다
Slack → 모든 이벤트가 한 곳에 모인다

세 가지가 연결되면 “이 코드는 왜 만들었는가”, “언제 배포됐는가”, “어떤 이슈가 해결됐는가” 를 언제든 추적할 수 있다. 혼자 쓰더라도, 팀에 합류했을 때도 이 흐름은 그대로 쓸 수 있다.

Git + Jira — 브랜치·커밋·PR에 이슈 키 연결하기

Sun, 07 Jun 2026 00:00:00 +0900

코드 변경에 이유를 남기는 방법

6개월 전에 작성한 코드를 보면서 “이게 왜 있지?“를 되묻는 경험이 있다면, 이 글이 그 문제를 해결해 준다.

Git 커밋 메시지와 Jira 이슈를 연결하면 코드 한 줄이 어떤 맥락에서 생겼는지 항상 추적할 수 있다.

연동의 핵심: 이슈 키

모든 것은 이슈 키 하나로 연결된다.

이슈 키 형식: {프로젝트 키}-{번호}
예) BLOG-42

이 키를 브랜치명, 커밋 메시지, PR 어디에든 넣으면 Jira가 자동으로 해당 이슈와 연결한다.

브랜치 네이밍

git switch -c feature/BLOG-42-add-comment-api

패턴: {type}/{이슈키}-{설명}

feature/BLOG-42-add-comment-api ← 기능 추가
bugfix/BLOG-37-fix-jwt-expiry ← 버그 수정
refactor/BLOG-55-split-service ← 리팩터링

이슈 키가 앞에 있으면 브랜치 목록에서 어떤 이슈와 연결됐는지 바로 보인다.

커밋 메시지

git commit -m "feat(comment): 댓글 생성 API 구현 BLOG-42"

커밋 끝에 이슈 키를 붙이는 것만으로 Jira가 연결을 감지한다.

조금 더 자세히 쓰고 싶다면:

git commit -m "feat(comment): 댓글 생성 API 구현

- POST /api/comments 엔드포인트 추가
- 댓글 내용 500자 유효성 검증

BLOG-42"

Smart Commits — 커밋 메시지로 Jira 이슈 상태를 자동으로 바꿀 수도 있다.

# 작업 시작 시 이슈를 In Progress로
git commit -m "feat: 댓글 API 작업 시작 BLOG-42 #in-progress"

# 완료 시 Done으로
git commit -m "feat: 댓글 API 완료 BLOG-42 #done"

PR 작성

제목: [BLOG-42] feat(comment): 댓글 생성 API 구현

PR 본문에는 이슈 링크를 추가한다:

## 관련 이슈
- Jira: [BLOG-42](https://your-domain.atlassian.net/browse/BLOG-42)
- Closes BLOG-42

## 변경 내용
- POST /api/comments 엔드포인트 추가
- 댓글 내용 500자 유효성 검증

## 테스트
- [ ] 댓글 생성 정상 응답
- [ ] 빈 내용 검증

Closes BLOG-42를 적으면 PR이 머지될 때 이슈가 자동으로 Done 처리된다.

GitHub for Jira 앱 연동

브랜치·커밋·PR이 Jira 이슈 페이지에서 바로 보이려면 앱 연동이 필요하다.

1. Jira → Apps → 앱 탐색
 → "GitHub for Atlassian" (by Atlassian) 설치

2. GitHub 계정 연결
 → Jira와 다른 구글 계정이어도 무관
 → OAuth 토큰 기반이라 계정 종류 상관없음

3. 연결할 레포 선택 → 승인

연동 후 Jira 이슈 페이지:

Development 패널:
 ├── Branches (1) : feature/BLOG-42-add-comment-api
 ├── Commits (3) : 관련 커밋 목록
 └── Pull Requests : [Open] 댓글 생성 API

이슈 하나에서 관련 코드 변경 전체를 볼 수 있다.

실전 워크플로우 요약

1. Jira에서 이슈 생성 → BLOG-42
2. 브랜치 생성 → feature/BLOG-42-add-comment-api
3. 커밋 → "feat: 구현 BLOG-42"
4. PR → [BLOG-42] feat: 댓글 API / Closes BLOG-42
5. 머지 → 이슈 자동 Done

혼자 쓸 때는 이 흐름을 다 지키기보다 브랜치명 + 커밋에 이슈 키만 챙겨도 충분하다. 나중에 git log에서 이슈 키로 검색하면 그 작업의 전체 맥락을 찾을 수 있다.

다음 편에서는 Slack과 연동해서 Jira + GitHub 알림을 한 곳에 모으는 방법을 다룬다.

Jira, 혼자 써도 되나요? — 1인 개발자의 이슈 트래커 시작하기

Fri, 05 Jun 2026 00:00:00 +0900

“Jira는 팀이 있어야 쓰는 거 아닌가요?”

나도 처음엔 그렇게 생각했다. 스탠드업 미팅, 스프린트 플래닝, 번다운 차트 — 이런 것들이 Jira의 이미지였다.

그런데 막상 쓰기 시작하니 혼자일 때도 충분히 유용했다. 이유는 단순하다. 할 일을 머릿속에서 꺼내는 것, 그리고 내가 뭘 했는지 이력을 남기는 것 — 이 두 가지는 팀이 없어도 필요하다.

무료 플랜으로 충분하다

Jira Free 플랜:

10명 이하 무료 (혼자면 당연히 무료)
프로젝트 수 제한 없음
칸반·스크럼 보드 모두 사용 가능
스토리지 2GB

가입은 atlassian.com/software/jira/free에서 구글 계정으로 바로 된다.

핵심 개념만 알면 된다

처음에 Epic, Story, Task, Bug, Subtask… 이게 다 뭔지 몰라 막혔다. 혼자 쓸 때는 두 가지만 써도 충분하다.

Task → 할 일 단위
Bug → 버그 수정

나머지는 팀에서 쓸 때 배우면 된다.

이슈 키는 나중에 Git 연동에서 핵심이 된다.

프로젝트 키를 "BLOG"로 설정하면
→ 이슈들: BLOG-1, BLOG-2, BLOG-3 ...

짧고 의미 있는 키를 설정하자. 브랜치명과 커밋 메시지에 계속 들어간다.

스크럼 말고 칸반으로 시작하자

스크럼은 1~2주 단위 스프린트를 계획하고 회고하는 방식이다. 팀에서 리듬을 맞출 때 좋다.

혼자라면 칸반이 맞다. 스프린트 없이 할 일이 생기면 추가하고, 끝나면 Done으로 옮기는 흐름이다.

[ To Do ] → [ In Progress ] → [ Done ]

단순하지만 이게 전부다.

이슈 생성 습관

뭔가 하려고 할 때마다 이슈를 먼저 만드는 것이 핵심이다.

제목 규칙:
 [Feature] 댓글 API 구현
 [Bug] 로그아웃 후 토큰 만료 안 되는 문제
 [Refactor] OrderService 트랜잭션 분리
 [Docs] README 업데이트

설명에는 “왜 이 작업이 필요한가"를 한 줄이라도 적어두면, 나중에 git log나 Jira에서 “이게 왜 있지?” 를 답할 수 있다.

상태 관리 습관

작업 시작할 때 → To Do → In Progress
작업 끝났을 때 → In Progress → Done

이것만 지켜도 Jira를 쓰는 이유가 생긴다. 한 달 후에 “5월에 뭐 했지?” 를 Jira에서 Done 필터로 바로 볼 수 있다.

혼자 Jira를 쓰는 진짜 이유

지금: 작업 이력 추적 + 할 일 관리
나중: 팀 합류 시 "Jira 써봤어요" 경험 있음

그리고 브랜치명에 이슈 키를 넣으면
→ "이 코드 왜 만들었지?" 를 Git에서도 추적 가능

다음 편에서는 Git 브랜치와 커밋에 이슈 키를 연결하는 방법을 다룬다.