Github 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 → 모든 이벤트가 한 곳에 모인다

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

PR을 잘 쓴다는 것 — 작성자와 리뷰어가 모두 편한 코드 리뷰

Mon, 08 Jun 2026 00:00:00 +0900

리뷰어의 입장에서 생각하기

PR을 올리고 “리뷰 부탁드립니다"를 남긴다. 리뷰어는 맥락 없이 diff만 본다. “이게 왜 바뀐 거지?”, “뭘 테스트해야 하지?”, “어디서 실행해볼 수 있지?” — 이 질문들이 드는 PR은 리뷰 시간이 3배가 된다.

좋은 PR은 리뷰어의 이 질문들을 미리 답해놓은 문서다.

PR 크기 — 작을수록 좋다

✅ 이상적인 PR
 - 변경 파일 5~10개 이하
 - 변경 라인 400줄 이하
 - 하나의 목적 (기능 1개, 버그 1개)

❌ 피해야 할 PR
 - "기능 A + 리팩터링 + 의존성 업그레이드" 한 번에
 - 1,000줄 넘는 PR → 리뷰어가 세부 사항을 놓침

큰 기능을 어떻게 쪼개는가: 레이어 단위로 나눈다.

PR 1: Entity + Repository 추가
PR 2: Service 로직 구현
PR 3: Controller + API 엔드포인트
PR 4: 테스트 코드

각 PR이 독립적으로 리뷰·머지 가능하도록 설계하면 리뷰 속도가 빨라진다.

PR 본문 — 리뷰어가 필요한 정보를 모두 담는다

## 변경 사항
Google OAuth2를 통한 소셜 로그인 기능을 구현했습니다.
기존 이메일/비밀번호 로그인과 함께 사용할 수 있습니다.

## 변경 이유
회원가입 과정의 마찰을 줄이기 위해 소셜 로그인을 추가합니다.

## 주요 변경 파일
- `OAuthController.java` — OAuth2 콜백 처리
- `OAuth2UserService.java` — 사용자 정보 조회 및 저장
- `SecurityConfig.java` — OAuth2 설정 추가

## 테스트 방법
1. 로컬 실행 후 `/oauth2/authorization/google` 접속
2. Google 계정으로 로그인
3. 리다이렉트 후 JWT 토큰 발급 확인

## 관련 이슈
Closes #123

코드 리뷰 — 리뷰어 가이드

코멘트 레이블

의견의 강도를 명확히 표현하면 작성자가 우선순위를 잡을 수 있다.

[MUST] → 반드시 수정 필요. 머지 전 해결.
 예: "NPE 발생 가능 [MUST]"

[SHOULD] → 수정을 강하게 권장. 이유 설명.
 예: "이 로직은 Service로 옮기는 게 좋을 것 같습니다 [SHOULD]"

[OPINION] → 개인 의견. 수정 강제 아님.
 예: "저라면 메서드명을 ~로 했을 것 같아요 [OPINION]"

[QUESTION] → 이해를 위한 질문. 비판 아님.
 예: "여기서 왜 synchronized를 쓰셨나요? [QUESTION]"

[PRAISE] → 잘한 부분 칭찬.
 예: "이 패턴 깔끔하네요! [PRAISE]"

리뷰 에티켓

✅ 코드를 비판하지 말고 개선을 제안한다
 "이건 잘못됐어요" → "이렇게 하면 더 나을 것 같습니다"

✅ 질문형으로 작성한다
 "왜 이렇게 했나요?" → "이렇게 한 이유가 있으신가요?"

✅ 칭찬도 남긴다
 좋은 코드를 보면 [PRAISE]로 표현

✅ 24시간 이내에 리뷰한다
 리뷰가 밀리면 PR 작성자의 컨텍스트도 날아간다

머지 전략

GitHub에서 PR 머지 시 세 가지 방법을 제공한다.

Merge commit
 → 머지 커밋 생성. 브랜치 기록 보존.
 → Git Flow에 적합

Squash and merge
 → 브랜치의 모든 커밋을 하나로 합쳐서 머지
 → 커밋 히스토리 깔끔. GitHub Flow에 적합
 → WIP 커밋이 많아도 괜찮음

Rebase and merge
 → 브랜치 커밋들을 main 위로 rebase 후 머지
 → 선형 히스토리 유지

팀이 하나의 전략을 통일해서 쓰는 게 중요하다. 섞어 쓰면 히스토리가 일관성 없어진다.

Draft PR 활용

완성되지 않았지만 피드백을 받고 싶을 때는 Draft PR로 올린다.

PR 생성 시 "Create draft pull request" 선택
→ 머지 불가 상태
→ 완료되면 "Ready for review"로 전환

“WIP:”, “DO NOT MERGE” 같은 제목 접두사 대신 Draft PR을 쓰는 게 GitHub 표준이다.

다음 편에서는 PR이 머지된 후 릴리즈를 어떻게 관리하는지 다룬다.

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 알림을 한 곳에 모으는 방법을 다룬다.