Discord embed 호출을 단일 함수로 통합해 일관성 확보

여러 스크립트에서 반복되고 있던 Discord embed 호출을 하나의 함수로 통합했다. learn-update, publish-progress, traffic-watcher 세 파일에서 각각 raw embed를 만들던 방식을 discord_kind() 함수로 교체한 작업이다.

왜 이 리팩토링이 필요했나

사실 이 작업은 새로운 기능도, 긴급한 버그 수정도 아니었다. 하지만 코드를 보면서 자꾸만 거슬리는 부분이 있었다. Discord 메시지를 보내는 방식이 각 스크립트마다 조금씩 다르게 구현되어 있었기 때문이다.

한 스크립트에서는 embed 포맷을 이렇게 만들고, 다른 스크립트에서는 저렇게 만들고. 각자 자기 방식대로 JSON 구조를 조립하는 식이었다. 겉으로 보면 비슷하지만, 누군가는 색상을 빨강으로, 누군가는 파랑으로 설정하는 식의 미묘한 차이들이 있었다.

이런 상황이 계속되면 결국 문제가 생긴다. Discord API가 업데이트되거나 우리 팀의 embed 스타일 가이드가 바뀌어야 할 때, 변경을 해야 하는 곳이 3곳이 아니라 이상 많아질 것이기 때문이다. 한 곳을 빼먹으면? 일관성이 깨진다.

통합의 의미

discord_kind() 함수는 단순한 헬퍼 함수가 아니다. 이건 팀의 Discord 통합 방식에 대한 하나의 진실(Single Source of Truth)을 만드는 것이다.

예를 들어, 나중에 "모든 알림에 timestamp를 붙이자"는 요구사항이 생기면, 함수 하나만 수정하면 모든 스크립트에 반영된다. 관련된 PR을 3개 올릴 필요도 없고, 코드 리뷰를 3번 할 필요도 없다.

이런 리팩토링이 중요한 이유

팀 규모가 커질수록, 반복되는 패턴을 빨리 함수로 추상화하는 습관이 점점 더 중요해진다. 초기에는 각 개발자가 자기 몫의 코드를 짜면 되겠지 싶지만, 시간이 지나면서 관리해야 할 파일이 늘어나고, 각 파일마다 미묘한 차이가 쌓인다.

이걸 방치하면 나중에는 "어? 이 파일의 embed 포맷이 다르네?" 같은 상황이 반복된다. 버그를 수정하고 테스트하고 배포하는 비용이 선형이 아니라 기하급수적으로 늘어난다. 특히 여러 사람이 유지보수해야 하는 코드라면 더더욱.

회고

이 작업을 하면서 느낀 건, 리팩토링은 "지금 당장 버그가 터지지 않아도" 필요하다는 것이었다. 코드 리뷰를 할 때도 자주 지적했던 부분인데, "이 로직이 3곳에 반복되네요"라는 의견이 자꾸만 나왔다. 그때마다 일관성을 높이는 방향으로 진행했고, 이번 통합은 그 누적된 피드백들을 한 번에 정리한 셈이다.

비슷한 상황에 있다면, 나는 조금 더 적극적으로 이 정도 리팩토링을 추천한다. 특히 같은 외부 시스템(Discord, Slack, 데이터베이스 등)과 상호작용하는 코드들은 더욱 그렇다. 일관성이 곧 버그의 부재로 이어진다는 경험이 반복되었으니까.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.