안녕하십니까, 오늘 저는 이번 프로젝트를 진행하면서 발생한 변수나 힘들었던 점, 느낀 점 등에 대해 자유롭게 말해보고자 합니다. (프로젝트 회고록은 처음 작성해봐서 ㅇ...이상해도 양해 부탁드리겠습니다 하핳)
프로젝트를 시작하게 된 계기
저는 여러 팀 프로젝트에서 주로 인프라를 맡았고, 특히 클라우드 설정이나 CI/CD 구축을 많이 담당했습니다.
그러던 중 하반기에 "CloudClub" 동아리에 들어가면서 자동화 스터디에 참여하게 되었고, 그 과정에서 ITSM(IT Service Management) 개념을 처음 접했습니다.
ITSM과 관련하여 계속해서 제 머릿속에서는 Jira가 떠올랐고, 마침 자동화 프로젝트를 진행할 사람이 필요하다고 하셔서 바로 지원했습니다.
그러다 문득 예전에 어떤 팀원분이 Jira–Slack–GitHub 자동화 환경을 만들어 준 게 기억났습니다.
그땐 그저
“오, 편한데?”
"와 진짜 신기하다 ㅋㅋㅋ"
정도로만 느꼈는데, 지금 와서 보니 그게 ITSM 워크플로우를 효율적으로 만든 구조였다는 걸 깨달았습니다!
그래서 “그럼 이번엔 내가 직접 Jira ↔ GitHub을 양방향으로 자동화 해보자!”라는 생각으로 시작했습니다 ㅎㅎ
하지만 개발을 시작해보니...
“양방향”이라는 단어가 생각보다 무겁다는 걸 깨닫기까지는 그리 오랜 시간이 걸리지 않았습니다.
기존의 계획은
- Jira에서 이슈 생성 → GitHub Issue/Branch 자동 생성
- GitHub Issue 수정 → Jira 이슈 자동 업데이트
- Jira 이슈 상태 변경 → GitHub Issue/Branch 자동 반영
등과 같은 완벽한 양방향 동기화를 꿈꿨으며 계획했었습니다.
하지만 구현을 진행할수록 점점 계획이 진짜 꿈이었다는 것을 깨닫게 되었습니다.
벽에 부딪힌 순간들
1. Jira Automation은 ‘조직 레벨’ GitHub에서만 지원한다.
구현 초기에 저는 소규모 프로젝트니 GitHub Reop 하나만 파서 간단하게 진행하려고 했습니다.
그래서 프로젝트를 위한 Repo 하나를 생성하고 초기 설정을 모두 다 한 뒤, Jira에서 Repo 연동을 하고 자동화 규칙을 설정하고 최종적으로 "규칙 활성화"를 누르려고 한 순간 어째서인지 제가 연동했던 Repo가 표시되지 않는 것 입니다.
알고보니 Jira의 GitHub Automation은 내부적으로 Atlassian Automation Bot이 GitHub API를 대신 호출하는 구조라 개인 계정에서는 권한 때문에 아예 사용할 수가 없었습니다.
말 그대로 시작부터 헛고생 한거였죠...하핫;
2. 이슈 description 필드가 전송되지 않는 괴현상
이슈를 만들면 summary, priority 같은 값은 잘 오는데
꼭 description만 사라지는 겁니다...도대체 왜...??
원인은 Jira의 내부 저장 순서 였습니다!!!
Jira는 이슈 생성 시
- ID, summary 등 기본 정보 먼저 저장
- description은 나중에 비동기로 별도 저장
- 그런데 Automation 트리거 실행 타이밍은 1번 이후…
그래서 description은 항상 빈 값으로 날아왔던 겁니다 ㅠㅠ
이 문제 때문에 템플릿 시스템도 더 복잡하게 만들 수밖에 없었고 결국 해결하지 못해서 description은 이후의 "Jira Issue 내용 변경 시 → GitHub Issue 내용 업데이트" 기능에 넣을 수 밖에 없었습니다...
3. 양방향 동기화...현실적으로 진짜 효율적일까...?!
작업하면서 이런 상황들을 계속 생각하게 됐습니다.
- “Jira에서 실수로 Done으로 옮겼는데 GitHub Issue도 닫히면 어떡하지?”
- “Jira에서는 상태 바꾸기 너무 쉬운데 GitHub에서는 큰 영향인데…”
- “양쪽에 똑같은 이슈를 유지하는 건 너무 비효율적이지 않나?”
등...프로젝트를 진행하면서 많은 생각이 들었고 결국 이렇게 결론 내렸습니다.
“실제 개발 플로우는 PR 중심이다.
PR이 merge되는 순간에만 Jira를 업데이트하는 게 가장 자연스럽다.”
이제서야 ITSM에서 왜 Jira가 중심이 되는지 이해하게 된 느낌이습니다! (확신 가득)
4. GitHub Webhook → Jira Incoming Webhook 방식은 구조적으로 불가능
마지막 기능인 "GitHub → Jira (PR Merge 시, Jira 자동 "완료" 상태 변경)"을 구현할 때,
처음엔 GitHub Webhook을 활용해 PR 정보를 Jira에 보내는 방식을 채택했으나,
매번 400 에러만 받았습니다.
Missing token
"Jira Incoming Webhook" 은 반드시 X-Automation-Webhook-Token 헤더가 있어야 하는데,
"GitHub Webhook"은 커스텀 헤더를 넣을 수 없습니다.
즉, “URL 뒤에 token=123 을 붙여도 Jira는 절대 인정하지 않는다.”
는 사실을 뒤늦게 깨닫게 된 것입니다...후우
이건 설계의 문제가 아니라 구조적으로 불가능한 방식이었습니다.
4-1. Atlassian 공식 DevOps 공식 가이드
절망하던 중 우연히 "Atlassian 공식 DevOps 공식 가이드"를 발견하게 되었고 스스로 깨닫게 되었습니다. 이전 기능들을 모두 GitHub Actions와 Jira Automation, 그리고 그 외의 다양한 도구들을 복합적으로 사용하여 만들다 보니 "과유불급"이라는 말처럼 제가 너무 복잡하게 구현을 하려고 했던 것을 알게 되었습니다.
바로 "Atlassian 공식 DevOps 공식 가이드"에서 알려주는대로 해보니 설정은 단순했고, 작동은 완벽했습니다.
- GitHub PR이 merge됨
- Jira Development 패널에서 PR 상태가 자동 업데이트
- Jira Automation 규칙에서 “PR merged → Done 전환” 완성
그동안 삽질한 게 무색할 정도로 너무나 깔끔하게 작동했습니다...(현타 x100)
“왜 처음부터 이렇게 안 했지…?”
라는 생각도 잠깐 들었지만, 사실 그 과정에서 얻은 지식과 경험이 훨씬 컸기 때문에 이제는 후회가 되진 않긴 합니다 ㅋㅋㅋㅋ
🌱 마무리하며
이번 프로젝트는 저에게 단순한 자동화 구현을 넘어서, 시스템 간의 철학과 동작 원리를 이해하는 여정이었다고 생각합니다!
초기에 꿈꿨던 “완전한 양방향”은 실전에서는 비효율적이었고,
결국엔 단방향 중심의 안정적 구조가 더 현명한 선택이라는 사실도 깨달았습니다 ㅎㅎ
지금은 이 모든 과정이 너무 소중하고 뜻 깊은 경험이었다고 생각합니다!
실패했던 시도들 하나하나가 현재의 최적의 구조를 만들어주는 발판이었으니까요 :)
긴 글 읽어주셔서 감사합니다 🙏
혹시 이와 비슷한 Jira/GitHub 자동화를 고민 중이라면,
언제든지 댓글 달아주세요!
제가 겪었던 삽질을 조금이라도 줄여드리겠습니다 ㅋㅋ 😄
