세상에는 번거롭고 불편한 점이 너무 많아요
처음에는 제가 단순히 귀찮음이 많은 사람이라고 생각했어요. 번거로운 작업이 있으면 '누가 대신 해주면 좋겠다'라는 생각을 자주 했던 것 같아요.
하지만 아카데미 활동을 하면서 주변 러너들에게 "효율적인 사람 같다"는 이야기를 여러 번 들었어요. 처음에는 그 말이 크게 와닿지 않았지만, 돌이켜보면 저는 항상 불편한 점을 개선하고 싶어했던 것 같아요. 그래서 타인이 보기에는 효율적인 사람으로 보였을 수도 있겠다는 생각이 들었어요.
심지어 PR을 생성할 때마다 리뷰어를 직접 등록하는 것이 번거롭다는 이유로, CODEOWNERS를 설정해 리뷰어가 자동으로 등록되도록 했죠. 한 번의 클릭을 덜 하게 되었죠.
리뷰 좀 해주세요!!!
애플 디벨로퍼 아카데미에서 오프라인으로 프로젝트를 진행할 때는 탭탭 팀원들과 거의 매일 붙어 작업을 했었습니다. 자연스럽게 서로의 코드를 바로 확인할 수 있었고, 피드백도 빠르게 오갔었죠.
하지만 아카데미를 수료하고 나서 온라인 작업으로 환경이 바뀌면서 상황이 조금 달라졌습니다. 각자 개인 일정과 취업 준비로 인해, 리뷰나 피드백 속도가 점점 느려지기 시작했죠. 결국 팀 전체 개발 속도에도 영향을 주기 시작했습니다.
탭탭 개발팀은 온라인으로 작업이 전환 된 후부터 단톡방을 통해 커뮤니케이션을 하고 있습니다. 자연스럽게 리뷰 요청도 단톡방을 통해 이루어지는 경우가 많았습니다. 하지만, 이조차 점점 번거로워지기 시작했습니다. (채팅 치는 게 생각보다 귀찮거든요... 저 또한 까먹을 때도 있었고요..!)
그래서 저는 이런 생각이 들었어습니다. "PR 리뷰 요청을 자동화하면 훨씬 편하지 않을까?"
저는 평소에도 귀찮음과 불편함을 보면 참지 못하는 성격이거든요. 반복되는 작업이나 비효율적인 흐름을 발견하면, 자연스럽게 개선할 방법을 고민하는 것 같아요. 그렇게 해서 저는 PR 리마인더 도입을 고민하게 되었고, 실제로 적용까지 진행하게 되었습니다.
GithubActions
PR 리마인더를 어떻게 구현할지 고민하던 중, GitHub Actions를 활용하면 자동화가 가능하겠다는 생각이 들었습니다. GithHub Actions는 저장소 이벤트를 기반으로 다양한 작업을 자동으로 수행할 수 있기 때문에, PR 상태를 확인하고 리뷰 요청을 리마인드하는 작업에도 충분히 활용할 수 있을 것이라 판단했기 때문이죠.
물론 처음부터 깃액션을 선택했던 것은 아니였어요. 디스코드 봇을 직접 만들어 알림을 보내는 방식, 단톡방 봇을 직접 만들어 알림을 보내는 방식, 별도의 스케줄링 서버를 구축하는 방법 등도 고려해봤어요. 하지만 이런 방식들은 별도의 서버 운영이 필요하거나 개발 공수, 유지보수 부담이 커질 수 있다는 생각이 들었습니다.
깃액션은 이미 프로젝트와 연동되어있고, 추가적인 인프라 구축 없이도 이벤트 기반 자동화를 구현할 수 있다는 장점이 있습니다. 또한 워크플로우를 코드로 관리할 수 있어 협업과 유지보수 측면에서도 유리하다고 판단했어요.
이러한 이유로 저는 최종적으로 GitHub Actions를 활용해 PR 리마인더를 구축하게 되었습니다.
SMTP? 디스코드 웹훅?
가장 중요한 것은 어떤 플랫폼으로 리마인더를 전달할 것인가였어요. 카카오톡은 팀원들이 가장 자주 확인하는 메신저이기 때문에, 처음에는 단톡방에 직접 PR 리마인더를 보내는 방식을 고민했었죠.
하지만 실제로 구현을 검토해보니, 카톡 자동 메시지 전송에는 인증이나 권한 관련 제약이 존재했고, 카톡 채널(비즈 메시지)도 고민해봤지만 일부 기능은 유료라는 점과 비즈 인증이 필요했기 때문에 다른 방법을 찾아봐야했죠.
탭탭 팀은 디스코드 서버를 함께 운영하고 있었고, 다들 개인 메일 알림도 잘 켜놓는 멋진 팀원들(?)이기 때문에, 디스코드와 개인 메일을 통해 PR 리마인더를 전달하기로 했어요.
최종적으로 디스코드 웹훅과 SMTP를 활용해 알림을 전송하는 방식을 선택하게 되었습니다. 웹훅은 비교적 간단한 설정만으로 디스코드 채널에 메시지를 보낼 수 있었고, SMTP를 이용하면 추가적인 인프라 구축 없이도 개인 메일로 알림을 전달할 수 있다는 장점이 있죠.
수동 리마인더도 있으면 좋겠는데?
자동 리마인더 기능만으로도 충분했지만, 원하는 시점에 직접 리마인더를 보내고 싶은 상황도 있지 않을까? 라는 생각이 들었습니다.
물론 수동으로 리뷰를 요청하고 싶다면 카톡으로 요청하면 되지만.. PR링크를 복사하고, 리뷰 요청 멘트를 작성하고, 다시 전달하는 과정이 생각보다 귀찮게 느껴질 수 있다는 생각이 들었어요. (없는 것 보단 낫잖아)
다행히 깃액션에는 PR 댓글 이벤트를 감지하여 워크플로우를 실행할 수 있었어요. 이를 활용해 특정 명령어를 입력하면 리마인더가 전송되도록 구현했습니다.
/리마인더 "이름" 과 같이 댓글을 작성하면, 해당 사용자의 개인 메일로 PR링크와 함께 리마인더 메시지가 자동으로 전송되도록 구현했어요.
근데 또 이런 생각이 들었어요. 리뷰를 요청해야 하는 대상이 한 명이 아니라 여러 명이라면? 그래서 여러 사용자에게 동시에 리마인더를 전송할 수 있도록 기능을 확장했습니다.
/리마인더 "이름1, 이름2" 와 같이 입력하면, 지정한 여러 사용자에게 리마인더가 한 번에 전송되도록 구현했어요.
24시간 리마인더.. 잘 되는 줄 알았다!
jobs:
pr-review-reminder:
if: github.event_name == 'pull_request'
runs-on: ubuntu-latest
steps:
- name: Wait for 24 hours
run: sleep 86400개발 초기에는 sleep을 활용해 24시간 뒤에 PR 리마인더를 보내는 방식으로 구현 했어요. 하지만 개발을 마무리하고 전체 흐름을 점검하던 도중, 깃액션 환경에서 sleep 명령어는 최대 실행 시간이 제한되어 있다는 사실을 뒤늦게 알게 되었습니다.... (ㅠㅠ)
워크플로우 실행 시간 자체가 제한되어 있어 장시간 대기 방식으로는 24시간 리마인더를 구현하는 것이 사실상 불가능한 것이죠. 이 문제를 해결하기 위해 여러 방법을 고민했습니다. 별도의 스케쥴러 서버를 구축해서 PR 상태를 주기적으로 확인하도록 할까 고민하기도 했고, 현실적으로 타협해서 6시간 뒤에 리마인더를 보내는 방식도 잠시 고려했었죠.
조금 더 자료를 찾아보던 중, 깃액션에서 cron 기반 스케줄링을 활용할 수 있다는 것을 알게 되었어요. cron을 사용하면 특정 시간 간격으로 워크플로우를 실행할 수 있었고, 이를 활용하면 별도의 스케줄러 서버 구축없이 리마인더를 보낼 수 있었죠. 결과적으로 24시간 리마인더 구현을 성공했죠.
but
Events that trigger workflows - GitHub Docs
You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.
docs.github.com
The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
스케줄링 이벤트는 깃액션 워크플로우 작업이 많은 기간에는 지연될 수 있습니다. 로딩 시간이 많아 매 시간마다 시작됩니다. 부하가 충분히 높으면 일부 대기열에 있던 작업들이 삭제될 수 있습니다. 지연 가능성을 줄이려면 작업 흐름을 다른 시간에 진행하도록 스케줄을 잡으세요.
Github Actions Docs를 확인해 보면, "스케줄링 이벤트는 깃액션 워크플로우 작업이 많은 기간에는 지연될 수 있습니다."라는 가이딩이 있습니다. 즉, 원하는 작업이 정확한 시점에 실행되지 않을 수 있다는 한계가 존재한다는 뜻이죠.
이러한 특성 때문에, 자주 호출되어야 하거나 특정 시간에 정확히 실행되어야 하는 작업의 경우에는 cron을 활용한 스케줄링은 적합하지 않죠.
하지만 PR 리마인더의 경우, 실행 시점이 몇 분에서 수십 분 정도 지연되더라도 큰 문제가 발생하지 않는 작업이었습니다. 급한 상황이라면 카톡이나 전화를 통해 충분히 커버할 수 있었고, 실행주기 24시간으로 길다는 점, 수동 리마인더 기능도 구현해 두었기 때문에 안정성 측면에서도 충분히 대응 가능하다고 판단했습니다.
이러한 이유로, 최종적으로 cron 기반 스케줄링을 활용하기로 결정했습니다.
마무리
PR 리마인더를 구현하면서 느낀 점은, 협업에서 발생하는 불편함은 생각보다 쉽게 익숙해지고 당연하게 받아들여지는 것 같아요. 하지만 그 불편함을 조금만 더 들여다보고 개선하려고 시도하면, 생각보다 간단한 자동화로도 협업 경험을 훨씬 좋게 만들 수 있다는 것을 알게된 것 같아요.
GitHub Actions, Webhook, SMTP 등 여러 기술을 활용해 실제 팀 문제를 해결해볼 수 있었던 점도 개인적으로는 의미 있는 경험이었습니다. 무엇보다 "있으면 편하겠는데?", "아.. 귀찮은데 누가 대신 해주는 방법 없나?"라는 생각에서 출발한 작은 기능이 실제로 팀원들에게 도움이 되는 경험을 할 수 있어서 더욱 만족스러웠던 것 같아요.
+ 앞으로 리마인더 기능을 지속적으로 사용해보면서, 실제로 협업 과정에서의 불편함이 얼마나 개선되었는지 지켜볼 예정이에요. 약 한 달 정도 사용한 뒤, 팀원들의 반응과 실제 활용도를 바탕으로 기능의 효과를 다시 정리해보려고 해요.
'탭탭 - TapTap > 개발일지' 카테고리의 다른 글
| [개발일지] 05. UX와 사용성에 대한 나의 고민 (feat. 개발자 시점) (0) | 2026.02.15 |
|---|---|
| [개발일지] 03. 신기하고 재밌는 탭탭 온보딩! 어떻게 구현했을까요? (0) | 2026.01.14 |
| [개발일지] 02. 쉐어 익스텐션에서 탭탭 익스텐션 데이터를 추출하는 방법 (0) | 2026.01.06 |
| [개발일지] 01. TapTap Extension이 NativeApp과 통신하는 방법 (0) | 2026.01.06 |