개발 slecs

디스코드 알림 함수 책임 분리로 유지보수성 개선

목차

discord 알림 시스템의 함수 구조를 정리했다. discord_notify() 안에서 알림 타입 처리를 discord_kind()에 위임하는 방식으로 리팩토링한 작업이다.

왜 이런 변경이 필요했나

처음에는 discord_notify() 한 곳에서 알림 대상을 결정하고, 메시지 포맷을 정하고, 실제 전송까지 모두 처리했을 것 같다. 알림 종류가 많아질수록, 또는 팀 멤버들이 이 코드를 건드릴 때마다 "이 함수는 뭘 하는 건가"라는 혼란이 생긴다. 단일 책임 원칙(Single Responsibility Principle) 관점에서, discord_notify()는 "알림 메커니즘 자체"에만 집중하고, "어떤 타입의 알림인가"라는 판단은 별도 함수에 맡기는 게 훨씬 깔끔하다.

특히 코드리뷰 할 때 자주 마주치는 상황인데, 한 함수에 로직이 많으면 변경할 때 영향 범위를 예측하기 어렵다. 누군가 "새로운 알림 타입을 추가해야 해"라고 PR을 올렸을 때, discord_kind()만 수정하면 되고 discord_notify() 로직은 건드리지 않아도 된다면, 코드 안정성도 높아진다.

구조 변경의 개형

변경 전 변경 후
discord_notify()가 type 판단 + 포맷팅 + 전송 담당 discord_notify()는 전송만, type 판단/포맷은 discord_kind()에 위임
호출부: discord_notify(event_data, type) 호출부: discord_notify() (내부에서 discord_kind() 호출)
알림 로직이 한 덩어리 관심사별로 분리됨

이렇게 하면 다음 패턴이 일반적이다:

# discord_kind() — 알림의 타입/대상/포맷을 결정
def discord_kind(event):
    if event.type == "order":
        return {
            "channel": "#sales",
            "message": format_order_notification(event)
        }
    elif event.type == "error":
        return {
            "channel": "#alerts",
            "message": format_error_notification(event)
        }
    # ... 더 많은 타입 처리

# discord_notify() — 결정된 타입을 실제로 전송
def discord_notify(event):
    notification = discord_kind(event)  # 타입 결정을 위임
    send_to_discord(notification["channel"], notification["message"])

이런 리팩토링의 효과

코드리뷰 입장에서 본다면:
- 새로운 타입을 추가할 때 discord_kind()만 봐도 된다. discord_notify()는 안 봐도 된다.
- 버그가 생기면 원인을 좁혀서 찾을 수 있다. "메시지 포맷이 잘못됐나?" vs "전송 로직이 깨졌나?" 를 구분하기 쉽다.

유지보수 입장에서 본다면:
- 6개월 뒤 누군가 "디스코드 알림에 리액션 추가하고 싶어"라고 하면, discord_kind()에서 리턴 딕셔너리에 "reaction": emoji 필드를 추가하고, discord_notify()에서 그 필드를 읽어 사용하면 된다. 기존 로직은 안 건드린다.

테스트 입장에서 본다면:
- discord_kind()만 단위 테스트하면 타입 판단 로직을 충분히 검증할 수 있다. discord_notify()는 통합 테스트에서 실제 전송을 테스트하면 된다.

주의할 점

이런 리팩토링은 좋지만, 과하면 역효과가 난다. 예를 들어 알림 로직이 정말 간단하고 타입이 2개뿐인데 함수 3개로 쪼개면, 오히려 코드를 읽는 사람이 "왜 이렇게 나눴지?" 하며 여러 파일을 오간다. 함수 분리의 기준은 "변경 가능성"과 "팀의 인지 부하"를 함께 본다.

"언제 함수를 쪼갤까?" = "앞으로 이 부분이 자주 바뀔까? 팀원들이 이해하기 어려울까?"

팀 입장에서의 체크리스트

다음번에 비슷한 상황이 오면 사용할 체크리스트:

  • [ ] discord_notify() 안의 로직이 하나의 목표로 수렴하나? (YES → 그대로 두기)
  • [ ] 타입마다 다르게 처리해야 할 부분이 있나? (YES → 위임 구조 고려)
  • [ ] 신입이 이 코드를 읽을 때 "어느 부분을 수정해야 하나?" 금방 알 수 있나? (NO → 분리 필요)
  • [ ] 함수 분리로 인한 파일 간 이동/호출이 많아지진 않나? (YES → 너무 많이 쪼갠 것 아닌가 재검토)

이 정도로 판단하면, 과한 엔지니어링이 아닌 실용적인 리팩토링이 된다.

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

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

이어보기

댓글 0

첫 댓글 달아줘.